[Intel-gfx] [PATCH 1/3] drm/i915/icl: track dbuf slice-2 status

[Mahesh Kumar]

This patch adds support to start tracking status of DBUF slices.
This is foundation to introduce support for enabling/disabling second
DBUF slice dynamically for ICL.

Signed-off-by: Mahesh Kumar 
Reviewed-by: James Ausmus 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_display.c|  5 +
 drivers/gpu/drm/i915/intel_pm.c | 20 
 drivers/gpu/drm/i915/intel_runtime_pm.c |  4 
 4 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..e51da42297d8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1184,6 +1184,7 @@ static inline bool skl_ddb_entry_equal(const struct 
skl_ddb_entry *e1,
 struct skl_ddb_allocation {
struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* 
packed/uv */
struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES];
+   uint8_t enabled_slices; /* GEN11 has configurable 2 slices */
 };
 
 struct skl_wm_values {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 415fb8cf2cf4..96a1e6a7f69e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11385,6 +11385,11 @@ static void verify_wm_state(struct drm_crtc *crtc,
skl_ddb_get_hw_state(dev_priv, _ddb);
sw_ddb = _priv->wm.skl_hw.ddb;
 
+   if (INTEL_GEN(dev_priv) >= 11)
+   if (hw_ddb.enabled_slices != sw_ddb->enabled_slices)
+   DRM_ERROR("mismatch in DBUF Slices (expected %u, got 
%u)\n",
+ sw_ddb->enabled_slices,
+ hw_ddb.enabled_slices);
/* planes */
for_each_universal_plane(dev_priv, pipe, plane) {
hw_plane_wm = _wm.planes[plane];
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 19e82aaa9863..3ff37d5ba353 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3567,6 +3567,23 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
return _ilk_disable_lp_wm(dev_priv, WM_DIRTY_LP_ALL);
 }
 
+static uint8_t intel_enabled_dbuf_slices_num(struct drm_i915_private *dev_priv)
+{
+   uint8_t enabled_slices;
+
+   /* Slice 1 will always be enabled */
+   enabled_slices = 1;
+
+   /* Gen prior to GEN11 have only one DBuf slice */
+   if (INTEL_GEN(dev_priv) < 11)
+   return enabled_slices;
+
+   if (I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE)
+   enabled_slices++;
+
+   return enabled_slices;
+}
+
 /*
  * FIXME: We still don't have the proper code detect if we need to apply the 
WA,
  * so assume we'll always need it in order to avoid underruns.
@@ -3832,6 +3849,8 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
 
memset(ddb, 0, sizeof(*ddb));
 
+   ddb->enabled_slices = intel_enabled_dbuf_slices_num(dev_priv);
+
for_each_intel_crtc(_priv->drm, crtc) {
enum intel_display_power_domain power_domain;
enum plane_id plane_id;
@@ -5050,6 +5069,7 @@ skl_copy_wm_for_pipe(struct skl_wm_values *dst,
   sizeof(dst->ddb.y_plane[pipe]));
memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
   sizeof(dst->ddb.plane[pipe]));
+   dst->ddb.enabled_slices = src->ddb.enabled_slices;
 }
 
 static void
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 53ea564f971e..58be542d660b 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2664,6 +2664,8 @@ static void icl_dbuf_enable(struct drm_i915_private 
*dev_priv)
if (!(I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
!(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
DRM_ERROR("DBuf power enable timeout\n");
+   else
+   dev_priv->wm.skl_hw.ddb.enabled_slices = 2;
 }
 
 static void icl_dbuf_disable(struct drm_i915_private *dev_priv)
@@ -2677,6 +2679,8 @@ static void icl_dbuf_disable(struct drm_i915_private 
*dev_priv)
if ((I915_READ(DBUF_CTL_S1) & DBUF_POWER_STATE) ||
(I915_READ(DBUF_CTL_S2) & DBUF_POWER_STATE))
DRM_ERROR("DBuf power disable timeout!\n");
+   else
+   dev_priv->wm.skl_hw.ddb.enabled_slices = 0;
 }
 
 static void icl_mbus_init(struct drm_i915_private *dev_priv)
-- 
2.16.2

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

[Intel-gfx] [PATCH 0/3] Optimize use of DBuf slices

[Mahesh Kumar]

Patches in this series were originally part of series:
https://patchwork.freedesktop.org/series/36993/

Reposting it here after rebase

Mahesh Kumar (3):
  drm/i915/icl: track dbuf slice-2 status
  drm/i915/icl: Enable 2nd DBuf slice only when needed
  drm/i915/icl: update ddb entry start/end mask during hw ddb readout

 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_display.c| 15 ++
 drivers/gpu/drm/i915/intel_drv.h|  6 +++
 drivers/gpu/drm/i915/intel_pm.c | 95 +++--
 drivers/gpu/drm/i915/intel_runtime_pm.c | 69 +++-
 6 files changed, 160 insertions(+), 29 deletions(-)

-- 
2.16.2

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)

[Saarinen, Jani]

+ Jani to comment too

> -Original Message-
> From: Sharma, Shashank
> Sent: torstai 5. huhtikuuta 2018 7.51
> To: intel-gfx@lists.freedesktop.org
> Cc: Saarinen, Jani 
> Subject: RE: ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support
> for LSPCON (rev7)
> 
> As mentioned in my previous mail, these warnings are due to existing driver
> style of macros, and this patch is just matching it.
> 
> Regards
> Shashank
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Thursday, April 5, 2018 10:19 AM
> To: Sharma, Shashank 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for
> LSPCON (rev7)
> 
> == Series Details ==
> 
> Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)
> URL   : https://patchwork.freedesktop.org/series/36068/
> State : warning
> 
> == Summary ==
> 
> $ dim checkpatch origin/drm-tip
> d2c64b6af6c3 drm/i915: Introduce CRTC output format
> e72f33b56e79 drm/i915: Add CRTC output format YCBCR 4:2:0 2717e22e7a1b
> drm/i915: Add CRTC output format YCBCR 4:4:4 16bc5598c50f drm/i915: Check
> LSPCON vendor OUI
> 9391b2185374 drm/i915: Add AVI infoframe support for LSPCON
> e8f2b0c2a460 drm/i915: Write AVI infoframes for MCA LSPCON
> 050b96901334 drm/i915: Write AVI infoframes for Parade LSPCON
> 1e82ce33a750 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
> -:64: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #64: FILE: drivers/gpu/drm/i915/i915_reg.h:8725:
> +#define  TRANS_MSA_SAMPLING_444  (2<<1)
> ^
> 
> -:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
> #65: FILE: drivers/gpu/drm/i915/i915_reg.h:8726:
> +#define  TRANS_MSA_CLRSP_YCBCR   (2<<3)
> ^
> 
> total: 0 errors, 0 warnings, 2 checks, 128 lines checked

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

Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions for NV12

[Srinivas, Vidya]

> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> Sent: Wednesday, April 4, 2018 2:37 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Cc: Lankhorst, Maarten 
> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size restrictions
> for NV12
> 
> Op 04-04-18 om 10:51 schreef Srinivas, Vidya:
> >
> >> -Original Message-
> >> From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
> >> Sent: Wednesday, April 4, 2018 2:18 PM
> >> To: Srinivas, Vidya ; intel-
> >> g...@lists.freedesktop.org
> >> Cc: Lankhorst, Maarten 
> >> Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
> >> restrictions for NV12
> >>
> >> Op 04-04-18 om 10:04 schreef Srinivas, Vidya:
>  -Original Message-
>  From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>  Sent: Wednesday, April 4, 2018 1:28 PM
>  To: Srinivas, Vidya ; intel-
>  g...@lists.freedesktop.org
>  Cc: Lankhorst, Maarten 
>  Subject: Re: [Intel-gfx] [PATCH v19 18/18] drm/i915: Set src size
>  restrictions for NV12
> 
>  Op 02-04-18 om 11:51 schreef Vidya Srinivas:
> > As per display WA 1106, to avoid corruption issues
> > NV12 plane height needs to be multiplier of 4 We expect the src
> > dimensions to be multiplier of 4 We fail the case where src width
> > or height is not multiple of 4 for NV12.
> > We also set the scaler destination height and width to be multiple
> > of 4. Without this, pipe fifo underruns were seen on APL and KBL.
> > We also skip src trunction/adjustments for NV12 case and handle
> > the sizes directly in skl_update_plane
> >
> > Credits-to: Maarten Lankhorst 
> > Signed-off-by: Vidya Srinivas 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_sprite.c | 19 ---
> >  2 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9c58da0..a1f718d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -159,6 +159,8 @@
> >  #define INTEL_I2C_BUS_DVO 1
> >  #define INTEL_I2C_BUS_SDVO 2
> >
> > +#define MULT4(x) ((x + 3) & ~0x03)
> > +
> >  /* these are outputs from the chip - integrated only
> > external chips are via DVO or SDVO output */  enum
> > intel_output_type { diff --git
> > a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index d5dad44..b2292dd 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -255,6 +255,12 @@ skl_update_plane(struct intel_plane *plane,
> > uint32_t src_h = drm_rect_height(_state->base.src) >> 16;
> > unsigned long irqflags;
> >
> > +   if (fb->format->format == DRM_FORMAT_NV12 &&
> > +   ((src_h % 4) != 0 || (src_w % 4) != 0)) {
> > +   DRM_DEBUG_KMS("NV12: src dimensions not
> valid\n");
> > +   return;
> > +   }
> > +
>  You can't do this check in skl_update_plane, it's way too late. It
>  should be rejected in the plane check with -EINVAL, or perhaps in
> >> skl_update_scaler.
> >>> Have done it right from intel_framebuffer_init onwards, have done it
> >>> in skl_update_scaler also In fact it will get rejected in
> >>> framebuffer init and
> >> all these are duplicate checks, can remove them.
> > /* Sizes are 0 based */
> > src_w--;
> > src_h--;
> > @@ -292,9 +298,12 @@ skl_update_plane(struct intel_plane *plane,
> >   PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
>  scaler->mode);
> > I915_WRITE_FW(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
> > I915_WRITE_FW(SKL_PS_WIN_POS(pipe, scaler_id), (crtc_x
>  << 16) | crtc_y);
> > -   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe, scaler_id),
> > - ((crtc_w + 1) << 16)|(crtc_h + 1));
> > -
> > +   if (fb->format->format == DRM_FORMAT_NV12)
> > +   I915_WRITE_FW(SKL_PS_WIN_SZ(pipe,
> scaler_id),
> > + (MULT4(crtc_w) << 16) |
>  MULT4(crtc_h));
>  See the comment above, sizes are 0 based. This will add 1 to the
>  size, so the size is always 1 more than requested.
>  I don't think it would pass plane CRC tests..
> >>> When I align it to mult of 4, 1919 (which was 1920-1) becomes 1920
> back.
> >>> If we don’t do this, I see 

[Intel-gfx] ✗ Fi.CI.BAT: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)

[Patchwork]

== Series Details ==

Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)
URL   : https://patchwork.freedesktop.org/series/36068/
State : warning

== Summary ==

Series 36068v7 YCBCR 4:2:0/4:4:4 output support for LSPCON
https://patchwork.freedesktop.org/api/1.0/series/36068/revisions/7/mbox/

 Possible new issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-7567u)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-kbl-7567u)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-kbl-7567u)

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-glk-j4005) fdo#103359
pass   -> DMESG-WARN (fi-kbl-7567u) fdo#103665
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:430s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:517s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:524s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:512s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:427s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:320s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:224  dwarn:0   dfail:0   fail:1   skip:60  
time:425s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:261  dwarn:4   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:542s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:512s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:517s

e29a10513429cca404e9847a399efbdbb4bdd4bf drm-tip: 2018y-04m-04d-20h-47m-24s UTC 
integration manifest
1e82ce33a750 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
050b96901334 drm/i915: Write AVI infoframes for Parade LSPCON
e8f2b0c2a460 drm/i915: Write AVI infoframes for MCA LSPCON
9391b2185374 drm/i915: Add AVI infoframe support for LSPCON
16bc5598c50f drm/i915: Check LSPCON vendor OUI
2717e22e7a1b drm/i915: Add CRTC output format YCBCR 4:4:4
e72f33b56e79 drm/i915: Add CRTC output format YCBCR 4:2:0
d2c64b6af6c3 drm/i915: Introduce CRTC output format

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)

[Sharma, Shashank]

As mentioned in my previous mail, these warnings are due to existing driver 
style of macros, and this patch is just matching it. 

Regards
Shashank
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Thursday, April 5, 2018 10:19 AM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for 
LSPCON (rev7)

== Series Details ==

Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)
URL   : https://patchwork.freedesktop.org/series/36068/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d2c64b6af6c3 drm/i915: Introduce CRTC output format
e72f33b56e79 drm/i915: Add CRTC output format YCBCR 4:2:0 2717e22e7a1b 
drm/i915: Add CRTC output format YCBCR 4:4:4 16bc5598c50f drm/i915: Check 
LSPCON vendor OUI
9391b2185374 drm/i915: Add AVI infoframe support for LSPCON
e8f2b0c2a460 drm/i915: Write AVI infoframes for MCA LSPCON
050b96901334 drm/i915: Write AVI infoframes for Parade LSPCON
1e82ce33a750 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
-:64: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#64: FILE: drivers/gpu/drm/i915/i915_reg.h:8725:
+#define  TRANS_MSA_SAMPLING_444(2<<1)
  ^

-:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#65: FILE: drivers/gpu/drm/i915/i915_reg.h:8726:
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)
  ^

total: 0 errors, 0 warnings, 2 checks, 128 lines checked

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)

[Patchwork]

== Series Details ==

Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev7)
URL   : https://patchwork.freedesktop.org/series/36068/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d2c64b6af6c3 drm/i915: Introduce CRTC output format
e72f33b56e79 drm/i915: Add CRTC output format YCBCR 4:2:0
2717e22e7a1b drm/i915: Add CRTC output format YCBCR 4:4:4
16bc5598c50f drm/i915: Check LSPCON vendor OUI
9391b2185374 drm/i915: Add AVI infoframe support for LSPCON
e8f2b0c2a460 drm/i915: Write AVI infoframes for MCA LSPCON
050b96901334 drm/i915: Write AVI infoframes for Parade LSPCON
1e82ce33a750 drm/i915: Add YCBCR 4:2:0/4:4:4 support for LSPCON
-:64: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#64: FILE: drivers/gpu/drm/i915/i915_reg.h:8725:
+#define  TRANS_MSA_SAMPLING_444(2<<1)
  ^

-:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#65: FILE: drivers/gpu/drm/i915/i915_reg.h:8726:
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)
  ^

total: 0 errors, 0 warnings, 2 checks, 128 lines checked

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for LSPCON (rev5)

[Sharma, Shashank]

Sent V8 for below two patches, fixing 2 alignment problems. 
Please note: Ignored following 2 warnings in patch 7, to maintain the existing 
driver style for bit macros (also mentioned in the commit message). 

-:64: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#64: FILE: drivers/gpu/drm/i915/i915_reg.h:8725:
+#define  TRANS_MSA_SAMPLING_444(2<<1)
  ^
-:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#65: FILE: drivers/gpu/drm/i915/i915_reg.h:8726:
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)

Regards
Shashank
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org] 
Sent: Tuesday, April 3, 2018 3:10 PM
To: Sharma, Shashank 
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.CHECKPATCH: warning for YCBCR 4:2:0/4:4:4 output support for 
LSPCON (rev5)

== Series Details ==

Series: YCBCR 4:2:0/4:4:4 output support for LSPCON (rev5)
URL   : https://patchwork.freedesktop.org/series/36068/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
093f7ee765f1 drm/i915: Introduce CRTC output format
-:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#87: FILE: drivers/gpu/drm/i915/intel_display.c:10690:
+   DRM_DEBUG_KMS("output format: %s\n",
+  output_formats(pipe_config->output_format));

total: 0 errors, 0 warnings, 1 checks, 139 lines checked
5aad7ff8f693 drm/i915: Add CRTC output format YCBCR 4:2:0 ba253735184f 
drm/i915: Add CRTC output format YCBCR 4:4:4
544b43272930 drm/i915: Check LSPCON vendor OUI
7602c66d2d56 drm/i915: Add AVI infoframe support for LSPCON
d1459992db55 drm/i915: Write AVI infoframes for MCA LSPCON
a03dd8af9824 drm/i915: Write AVI infoframes for Parade LSPCON
-:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#87: FILE: drivers/gpu/drm/i915/intel_lspcon.c:287:
+   DRM_DEBUG_KMS("LSPCON FW not ready, block %d\n",
+  block_count);

total: 0 errors, 0 warnings, 1 checks, 141 lines checked cbb6eaa686ed drm/i915: 
Add YCBCR 4:2:0/4:4:4 support for LSPCON
-:64: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#64: FILE: drivers/gpu/drm/i915/i915_reg.h:8725:
+#define  TRANS_MSA_SAMPLING_444(2<<1)
  ^

-:65: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#65: FILE: drivers/gpu/drm/i915/i915_reg.h:8726:
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)
  ^

total: 0 errors, 0 warnings, 2 checks, 128 lines checked

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

[Intel-gfx] [PATCH v8 7/8] drm/i915: Write AVI infoframes for Parade LSPCON

[Shashank Sharma]

Different LSPCON vendors specify their custom methods to pass
AVI infoframes to the LSPCON chip, so does Parade tech.

This patch adds functions to arrange and write AVI infoframes
into Parade LSPCON chips.

V2: rebase
V3: Added r-b from Maarten
V4: rebase
V5: rebase
V6: rebase
V7: Fixed checkpatch warnings for alignment
V8: Fixed another checkpatch warning for alignment

Cc: Imre Deak 
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Reviewed-by: Maarten Lankhorst 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_lspcon.c | 117 +++-
 1 file changed, 116 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index dcd4885..9b2f32a 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -37,6 +37,12 @@
 #define  LSPCON_MCA_AVI_IF_KICKOFF (1 << 0)
 #define  LSPCON_MCA_AVI_IF_HANDLED (1 << 1)
 
+/* AUX addresses to write Parade AVI IF */
+#define LSPCON_PARADE_AVI_IF_WRITE_OFFSET 0x516
+#define LSPCON_PARADE_AVI_IF_CTRL 0x51E
+#define  LSPCON_PARADE_AVI_IF_KICKOFF (1 << 7)
+#define LSPCON_PARADE_AVI_IF_DATA_SIZE 32
+
 static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
 {
struct intel_digital_port *dig_port =
@@ -240,6 +246,111 @@ static void lspcon_resume_in_pcon_wa(struct intel_lspcon 
*lspcon)
DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
 }
 
+static bool lspcon_parade_fw_ready(struct drm_dp_aux *aux)
+{
+   u8 avi_if_ctrl;
+   u8 retry;
+   ssize_t ret;
+
+   /* Check if LSPCON FW is ready for data */
+   for (retry = 0; retry < 5; retry++) {
+   if (retry)
+   usleep_range(200, 300);
+
+   ret = drm_dp_dpcd_read(aux, LSPCON_PARADE_AVI_IF_CTRL,
+  _if_ctrl, 1);
+   if (ret < 0) {
+   DRM_ERROR("Failed to read AVI IF control\n");
+   return false;
+   }
+
+   if ((avi_if_ctrl & LSPCON_PARADE_AVI_IF_KICKOFF) == 0)
+   return true;
+   }
+
+   DRM_ERROR("Parade FW not ready to accept AVI IF\n");
+   return false;
+}
+
+static bool _lspcon_parade_write_infoframe_blocks(struct drm_dp_aux *aux,
+ uint8_t *avi_buf)
+{
+   u8 avi_if_ctrl;
+   u8 block_count = 0;
+   u8 *data;
+   uint16_t reg;
+   ssize_t ret;
+
+   while (block_count < 4) {
+   if (!lspcon_parade_fw_ready(aux)) {
+   DRM_DEBUG_KMS("LSPCON FW not ready, block %d\n",
+ block_count);
+   return false;
+   }
+
+   reg = LSPCON_PARADE_AVI_IF_WRITE_OFFSET;
+   data = avi_buf + block_count * 8;
+   ret = drm_dp_dpcd_write(aux, reg, data, 8);
+   if (ret < 0) {
+   DRM_ERROR("Failed to write AVI IF block %d\n",
+ block_count);
+   return false;
+   }
+
+   /*
+* Once a block of data is written, we have to inform the FW
+* about this by writing into avi infoframe control register:
+* - set the kickoff bit[7] to 1
+* - write the block no. to bits[1:0]
+*/
+   reg = LSPCON_PARADE_AVI_IF_CTRL;
+   avi_if_ctrl = LSPCON_PARADE_AVI_IF_KICKOFF | block_count;
+   ret = drm_dp_dpcd_write(aux, reg, _if_ctrl, 1);
+   if (ret < 0) {
+   DRM_ERROR("Failed to update (0x%x), block %d\n",
+ reg, block_count);
+   return false;
+   }
+
+   block_count++;
+   }
+
+   DRM_DEBUG_KMS("Wrote AVI IF blocks successfully\n");
+   return true;
+}
+
+static bool _lspcon_write_avi_infoframe_parade(struct drm_dp_aux *aux,
+  const uint8_t *frame,
+  ssize_t len)
+{
+   uint8_t avi_if[LSPCON_PARADE_AVI_IF_DATA_SIZE] = {1, };
+
+   /*
+* Parade's frames contains 32 bytes of data, divided
+* into 4 frames:
+*  Token byte (first byte of first frame, must be non-zero)
+*  HB0 to HB2   from AVI IF (3 bytes header)
+*  PB0 to PB27 from AVI IF (28 bytes data)
+* So it should look like this
+*  first block: ||
+*  next 3 blocks: 
+*/
+
+   if (len > LSPCON_PARADE_AVI_IF_DATA_SIZE - 1) {
+   DRM_ERROR("Invalid length of infoframes\n");
+   return false;
+   }
+
+   

[Intel-gfx] [PATCH v8 1/8] drm/i915: Introduce CRTC output format

[Shashank Sharma]

This patch adds an enum "intel_output_format" to represent
the output format of a particular CRTC. This enum will be
used to produce a RGB/YCBCR4:4:4/YCBCR4:2:0 output format
during the atomic modeset calculations.

V5:
- Created this separate patch to introduce and init output_format.
- Initialize parameters of output_format_str respectively (Jani N).
- Call it intel_output_format than crtc_output_format(Ville).
- Set output format in pipe_config for every encoder (Ville).
- Get rid of extra DRM_DEBUG_KMS during get_pipe_config (Ville)

V6: Rebase
V7: Fixed alignment warnings (checkpatch)
V8: Another check[atch warning for alignment

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_crt.c |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 17 +
 drivers/gpu/drm/i915/intel_dp.c  |  1 +
 drivers/gpu/drm/i915/intel_dp_mst.c  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  8 
 drivers/gpu/drm/i915/intel_dsi.c |  1 +
 drivers/gpu/drm/i915/intel_dvo.c |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c|  1 +
 drivers/gpu/drm/i915/intel_lvds.c|  2 ++
 drivers/gpu/drm/i915/intel_sdvo.c|  1 +
 drivers/gpu/drm/i915/intel_tv.c  |  1 +
 11 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index c0a8805..b42c22d 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -337,6 +337,7 @@ static bool intel_crt_compute_config(struct intel_encoder 
*encoder,
 struct intel_crtc_state *pipe_config,
 struct drm_connector_state *conn_state)
 {
+   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
return true;
 }
 
@@ -345,6 +346,7 @@ static bool pch_crt_compute_config(struct intel_encoder 
*encoder,
   struct drm_connector_state *conn_state)
 {
pipe_config->has_pch_encoder = true;
+   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
 
return true;
 }
@@ -356,6 +358,7 @@ static bool hsw_crt_compute_config(struct intel_encoder 
*encoder,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
 
pipe_config->has_pch_encoder = true;
+   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
 
/* LPT FDI RX only supports 8bpc. */
if (HAS_PCH_LPT(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3acd757..18c3a03 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9324,6 +9324,7 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
}
}
 
+   pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
power_domain_mask |= BIT_ULL(power_domain);
@@ -10652,6 +10653,18 @@ static void snprintf_output_types(char *buf, size_t 
len,
WARN_ON_ONCE(output_types != 0);
 }
 
+static const char * const output_format_str[] = {
+   [INTEL_OUTPUT_FORMAT_INVALID] = "Invalid",
+   [INTEL_OUTPUT_FORMAT_RGB] = "RGB",
+};
+
+static const char *output_formats(enum intel_output_format format)
+{
+   if (format != INTEL_OUTPUT_FORMAT_RGB)
+   format = INTEL_OUTPUT_FORMAT_INVALID;
+   return output_format_str[format];
+}
+
 static void intel_dump_pipe_config(struct intel_crtc *crtc,
   struct intel_crtc_state *pipe_config,
   const char *context)
@@ -10671,6 +10684,9 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
DRM_DEBUG_KMS("output_types: %s (0x%x)\n",
  buf, pipe_config->output_types);
 
+   DRM_DEBUG_KMS("output format: %s\n",
+ output_formats(pipe_config->output_format));
+
DRM_DEBUG_KMS("cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n",
  transcoder_name(pipe_config->cpu_transcoder),
  pipe_config->pipe_bpp, pipe_config->dither);
@@ -11250,6 +11266,7 @@ intel_pipe_config_compare(struct drm_i915_private 
*dev_priv,
PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_vsync_end);
 
PIPE_CONF_CHECK_I(pixel_multiplier);
+   PIPE_CONF_CHECK_I(output_format);
PIPE_CONF_CHECK_BOOL(has_hdmi_sink);
if ((INTEL_GEN(dev_priv) < 8 && !IS_HASWELL(dev_priv)) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4..4eb2fe9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1722,6 +1722,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != PORT_A)

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts 
on hsw (rev2)
URL   : https://patchwork.freedesktop.org/series/41095/
State : failure

== Summary ==

 Possible new issues:

Test gem_cs_tlb:
Subgroup render:
pass   -> INCOMPLETE (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-pwrite:
dmesg-fail -> PASS   (shard-apl)
Subgroup fbc-modesetfrombusy:
pass   -> FAIL   (shard-apl)

 Known issues:

Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
pass   -> FAIL   (shard-apl) fdo#103207
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-toggle:
pass   -> FAIL   (shard-hsw) fdo#102670 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887 +1
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +2
Test kms_plane_multiple:
Subgroup atomic-pipe-a-tiling-x:
pass   -> FAIL   (shard-snb) fdo#103166
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
pass   -> FAIL   (shard-snb) fdo#103925
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3499 pass:1834 dwarn:1   dfail:0   fail:9   skip:1655 
time:12886s
shard-hswtotal:3499 pass:1784 dwarn:1   dfail:0   fail:3   skip:1710 
time:11560s
shard-snbtotal:3429 pass:1350 dwarn:1   dfail:0   fail:4   skip:2073 
time:6880s
Blacklisted hosts:
shard-kbltotal:3374 pass:1893 dwarn:1   dfail:1   fail:6   skip:1471 
time:8906s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts 
on hsw (rev2)
URL   : https://patchwork.freedesktop.org/series/41095/
State : success

== Summary ==

Series 41095v2 series starting with [v3,1/4] drm/i915: Enable edp psr error 
interrupts on hsw
https://patchwork.freedesktop.org/api/1.0/series/41095/revisions/2/mbox/

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-glk-j4005) fdo#103359
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-cfl-s3) fdo#100368

fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:296s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:517s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:521s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:507s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:258  dwarn:0   dfail:0   fail:1   skip:26  
time:549s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:317s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:437s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:440s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:429s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:565s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:533s

e29a10513429cca404e9847a399efbdbb4bdd4bf drm-tip: 2018y-04m-04d-20h-47m-24s UTC 
integration manifest
19bb9639e1a7 drm/i915/psr: Timestamps for PSR entry and exit interrupts.
d117c36f789e drm/i915/psr: Control PSR interrupts via debugfs
a5cf241c72c3 drm/i915: Enable edp psr error interrupts on bdw+
f3b80889ad58 drm/i915: Enable edp psr error interrupts on hsw

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts on hsw (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/4] drm/i915: Enable edp psr error interrupts 
on hsw (rev2)
URL   : https://patchwork.freedesktop.org/series/41095/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f3b80889ad58 drm/i915: Enable edp psr error interrupts on hsw
-:109: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#109: FILE: drivers/gpu/drm/i915/i915_reg.h:4017:
+#define   EDP_PSR_ERROR(1<<2)
  ^

-:110: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#110: FILE: drivers/gpu/drm/i915/i915_reg.h:4018:
+#define   EDP_PSR_POST_EXIT(1<<1)
  ^

-:111: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#111: FILE: drivers/gpu/drm/i915/i915_reg.h:4019:
+#define   EDP_PSR_PRE_ENTRY(1<<0)
  ^

-:120: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#120: FILE: drivers/gpu/drm/i915/i915_reg.h:6830:
+#define DE_EDP_PSR_INT_HSW (1<<19)
  ^

total: 0 errors, 0 warnings, 4 checks, 78 lines checked
a5cf241c72c3 drm/i915: Enable edp psr error interrupts on bdw+
-:158: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#158: FILE: drivers/gpu/drm/i915/intel_display.h:221:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+   for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++)  \
+   for_each_if ((__mask) & (1 << (__t)))

-:158: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__t' - possible 
side-effects?
#158: FILE: drivers/gpu/drm/i915/intel_display.h:221:
+#define for_each_cpu_transcoder_masked(__dev_priv, __t, __mask) \
+   for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++)  \
+   for_each_if ((__mask) & (1 << (__t)))

-:159: CHECK:SPACING: No space is necessary after a cast
#159: FILE: drivers/gpu/drm/i915/intel_display.h:222:
+   for ((__t) = 0; (__t) < I915_MAX_TRANSCODERS; (__t)++)  \

-:160: WARNING:SPACING: space prohibited between function name and open 
parenthesis '('
#160: FILE: drivers/gpu/drm/i915/intel_display.h:223:
+   for_each_if ((__mask) & (1 << (__t)))

total: 1 errors, 1 warnings, 2 checks, 123 lines checked
d117c36f789e drm/i915/psr: Control PSR interrupts via debugfs
19bb9639e1a7 drm/i915/psr: Timestamps for PSR entry and exit interrupts.

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

[Intel-gfx] [PATCH v4 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Dhinakaran Pandiyan]

Interrupts other than the one for AUX errors are required only for debug,
so unmask them via debugfs when the user requests debug.

User can make such a request with
echo 1 > /dri/0/i915_edp_psr_debug

There are no locks to serialize PSR debug enabling from
irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
called only during module initialization/resume and IGT subtests
aren't expected to modify PSR debug at those times, we should be safe.

v2: Unroll loops (Ville)
Avoid resetting error mask bits.

v3: Unmask interrupts in postinstall() if debug was still enabled.
Avoid RMW (Ville)

v4: Avoid extra IMR write introduced in the previous version.(Jose)
Style changes, renames (Jose).

Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 36 ++-
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c | 51 
 drivers/gpu/drm/i915/intel_drv.h|  2 ++
 drivers/gpu/drm/i915/intel_psr.c| 58 +
 5 files changed, 108 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1dba2c451255..025410a08786 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
return 0;
 }
 
+static int
+i915_edp_psr_debug_set(void *data, u64 val)
+{
+   struct drm_i915_private *dev_priv = data;
+
+   if (!CAN_PSR(dev_priv))
+   return -ENODEV;
+
+   DRM_DEBUG_KMS("PSR debug %s\n", enableddisabled(val));
+
+   intel_runtime_pm_get(dev_priv);
+   intel_psr_irq_control(dev_priv, !!val);
+   intel_runtime_pm_put(dev_priv);
+
+   return 0;
+}
+
+static int
+i915_edp_psr_debug_get(void *data, u64 *val)
+{
+   struct drm_i915_private *dev_priv = data;
+
+   if (!CAN_PSR(dev_priv))
+   return -ENODEV;
+
+   *val = READ_ONCE(dev_priv->psr.debug);
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
+   i915_edp_psr_debug_get, i915_edp_psr_debug_set,
+   "%llu\n");
+
 static int i915_sink_crc(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4812,7 +4845,8 @@ static const struct i915_debugfs_files {
{"i915_guc_log_relay", _guc_log_relay_fops},
{"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
{"i915_ipc_status", _ipc_status_fops},
-   {"i915_drrs_ctl", _drrs_ctl_fops}
+   {"i915_drrs_ctl", _drrs_ctl_fops},
+   {"i915_edp_psr_debug", _edp_psr_debug_fops}
 };
 
 int i915_debugfs_register(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..b97ed0cd4ca9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -609,6 +609,7 @@ struct i915_psr {
bool has_hw_tracking;
bool psr2_enabled;
u8 sink_sync_latency;
+   bool debug;
 
void (*enable_source)(struct intel_dp *,
  const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8a894adf2ca1..91b66a52cae5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct 
drm_i915_private *dev_priv,
ironlake_rps_change_irq_handler(dev_priv);
 }
 
-static void hsw_edp_psr_irq_handler(struct drm_i915_private *dev_priv)
-{
-   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
-   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
-   u32 mask = BIT(TRANSCODER_EDP);
-   enum transcoder cpu_transcoder;
-
-   if (INTEL_GEN(dev_priv) >= 8)
-   mask |= BIT(TRANSCODER_A) |
-   BIT(TRANSCODER_B) |
-   BIT(TRANSCODER_C);
-
-   for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, mask) {
-   if (edp_psr_iir & EDP_PSR_ERROR(cpu_transcoder))
-   DRM_DEBUG_KMS("Transcoder %s PSR error\n",
- transcoder_name(cpu_transcoder));
-
-   if (edp_psr_iir & EDP_PSR_PRE_ENTRY(cpu_transcoder)) {
-   DRM_DEBUG_KMS("Transcoder %s PSR prepare entry in 2 
vblanks\n",
- transcoder_name(cpu_transcoder));
-   edp_psr_imr |= EDP_PSR_PRE_ENTRY(cpu_transcoder);
-   }
-
-   if (edp_psr_iir & EDP_PSR_POST_EXIT(cpu_transcoder)) {
-   DRM_DEBUG_KMS("Transcoder %s PSR exit completed\n",
- 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v6,01/12] drm/i915: Correctly handle error path in i915_gem_init_hw

[Patchwork]

== Series Details ==

Series: series starting with [v6,01/12] drm/i915: Correctly handle error path 
in i915_gem_init_hw
URL   : https://patchwork.freedesktop.org/series/41159/
State : failure

== Summary ==

 Possible new issues:

Test gem_eio:
Subgroup execbuf:
pass   -> INCOMPLETE (shard-apl)
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl)
Subgroup throttle:
pass   -> INCOMPLETE (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)

 Known issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl) fdo#103199
Test gem_eio:
Subgroup in-flight-suspend:
pass   -> INCOMPLETE (shard-apl) fdo#103375
Subgroup suspend:
pass   -> INCOMPLETE (shard-apl) fdo#103927 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887 +1
Subgroup plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047

fdo#103199 https://bugs.freedesktop.org/show_bug.cgi?id=103199
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:2701 pass:1404 dwarn:1   dfail:0   fail:6   skip:1274 
time:6843s
shard-hswtotal:3499 pass:1786 dwarn:1   dfail:0   fail:1   skip:1710 
time:11567s
shard-snbtotal:3499 pass:1378 dwarn:1   dfail:0   fail:2   skip:2118 
time:7127s
Blacklisted hosts:
shard-kbltotal:2429 pass:1334 dwarn:4   dfail:0   fail:6   skip:1065 
time:4018s

== Logs ==

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

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/psr: Control PSR interrupts via debugfs

[Pandiyan, Dhinakaran]

On Wed, 2018-04-04 at 00:54 +, Souza, Jose wrote:
> On Tue, 2018-04-03 at 14:24 -0700, Dhinakaran Pandiyan wrote:
> > Interrupts other than the one for AUX errors are required only for
> > debug,
> > so unmask them via debugfs when the user requests debug.
> > 
> > User can make such a request with
> > echo 1 > /dri/0/i915_edp_psr_debug
> > 
> > There are no locks to serialize PSR debug enabling from
> > irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
> > called only during module initialization/resume and IGT subtests
> > aren't expected to modify PSR debug at those times, we should be
> > safe.
> > 
> > v2: Unroll loops (Ville)
> > Avoid resetting error mask bits.
> > 
> > v3: Unmask interrupts in postinstall() if debug was still enabled.
> > Avoid RMW (Ville)
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Cc: Chris Wilson 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 36 +-
> >  drivers/gpu/drm/i915/i915_drv.h |  1 +
> >  drivers/gpu/drm/i915/i915_irq.c | 57 +++--
> > --
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  drivers/gpu/drm/i915/intel_psr.c| 60
> > +
> >  5 files changed, 116 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 1dba2c451255..28f91df5b401 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2690,6 +2690,39 @@ static int i915_edp_psr_status(struct seq_file
> > *m, void *data)
> > return 0;
> >  }
> >  
> > +static int
> > +i915_edp_psr_debug_set(void *data, u64 val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   DRM_DEBUG_KMS("PSR debug %s\n", enableddisabled(val));
> > +
> > +   intel_runtime_pm_get(dev_priv);
> > +   intel_psr_debug_control(dev_priv, !!val);
> > +   intel_runtime_pm_put(dev_priv);
> > +
> > +   return 0;
> > +}
> > +
> > +static int
> > +i915_edp_psr_debug_get(void *data, u64 *val)
> > +{
> > +   struct drm_i915_private *dev_priv = data;
> > +
> > +   if (!CAN_PSR(dev_priv))
> > +   return -ENODEV;
> > +
> > +   *val = READ_ONCE(dev_priv->psr.debug);
> > +   return 0;
> > +}
> > +
> > +DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops,
> > +   i915_edp_psr_debug_get,
> > i915_edp_psr_debug_set,
> > +   "%llu\n");
> > +
> >  static int i915_sink_crc(struct seq_file *m, void *data)
> >  {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -4812,7 +4845,8 @@ static const struct i915_debugfs_files {
> > {"i915_guc_log_relay", _guc_log_relay_fops},
> > {"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
> > {"i915_ipc_status", _ipc_status_fops},
> > -   {"i915_drrs_ctl", _drrs_ctl_fops}
> > +   {"i915_drrs_ctl", _drrs_ctl_fops},
> > +   {"i915_edp_psr_debug", _edp_psr_debug_fops}
> 
> 
> same as bellow, why not i915_edp_psr_int_debug?
> 
> >  };
> >  
> >  int i915_debugfs_register(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 5373b171bb96..b97ed0cd4ca9 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -609,6 +609,7 @@ struct i915_psr {
> > bool has_hw_tracking;
> > bool psr2_enabled;
> > u8 sink_sync_latency;
> > +   bool debug;
> 
> maybe change to a name that gives more information about the use of
> this flag? like int_debug?
> 

Enabling interrupts is one part of enabling PSR debug, that is how I
think of it. We'll probably use the same control to enable other debug
mechanisms as well. At the least to update timestamps from psr_activate
and psr_exit for VLV/CHV.


> >  
> > void (*enable_source)(struct intel_dp *,
> >   const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 8a894adf2ca1..714570955196 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2391,40 +2391,6 @@ static void ilk_display_irq_handler(struct
> > drm_i915_private *dev_priv,
> > ironlake_rps_change_irq_handler(dev_priv);
> >  }
> >  
> > -static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > *dev_priv)
> > -{
> > -   u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > -   u32 edp_psr_imr = I915_READ(EDP_PSR_IMR);
> > -   u32 mask = BIT(TRANSCODER_EDP);
> > -   enum transcoder cpu_transcoder;
> > -
> > -   if (INTEL_GEN(dev_priv) >= 8)
> > -   mask |= BIT(TRANSCODER_A) |
> > -   BIT(TRANSCODER_B) |
> > -   BIT(TRANSCODER_C);
> > -
> > -   

[Intel-gfx] [PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up

[Lyude Paul]

As it turns out, the aux block being off was not the real problem here,
as transition from D3 to D0 is mandated by the DP spec to take a maximum
of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs.
The real problem here is a bit more subtle.

When doing a modeset where the problem of the sink timing out to our
sideband requests when transitioning from D3 to D0 occurs, the timeout
is from the aux block not coming on. However, nothing else times out
other than the initial phy_up message because the DPCD on call in
intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not
the phy_up sideband message. This means that the real fix we need is to
use the DPMS on before sending a phy_up to ensure that the hub is ready
to accept sideband messages.

Signed-off-by: Lyude Paul 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: Laura Abbott 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
Sorry for all the spam guys! This is my last attempt at getting this
patch to actually come up on intel-gfx's patchwork page instead of
dri-devel. I have no idea what is going on with patchwork right now :|,
but maybe removing dri-devel from the CC entirely will help.


 drivers/gpu/drm/i915/intel_ddi.c| 6 +-
 drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..9bd675f73f7b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
 
intel_ddi_init_dp_buf_reg(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen
+* before drm_dp_send_power_updown_phy()
+*/
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..eff9a4eae1f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(_dig_port->base,
-- 
2.14.3

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

[Intel-gfx] [PATCH] [RESEND] drm/i915/dp: Send DPCD ON for MST before phy_up

[Lyude Paul]

As it turns out, the aux block being off was not the real problem here,
as transition from D3 to D0 is mandated by the DP spec to take a maximum
of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs.
The real problem here is a bit more subtle.

When doing a modeset where the problem of the sink timing out to our
sideband requests when transitioning from D3 to D0 occurs, the timeout
is from the aux block not coming on. However, nothing else times out
other than the initial phy_up message because the DPCD on call in
intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not
the phy_up sideband message. This means that the real fix we need is to
use the DPMS on before sending a phy_up to ensure that the hub is ready
to accept sideband messages.

Signed-off-by: Lyude Paul 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: Laura Abbott 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_ddi.c| 6 +-
 drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..9bd675f73f7b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
 
intel_ddi_init_dp_buf_reg(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen
+* before drm_dp_send_power_updown_phy()
+*/
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..eff9a4eae1f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(_dig_port->base,
-- 
2.14.3

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

[Intel-gfx] [PATCH] drm/i915/dp: Send DPCD ON for MST before phy_up

[Lyude Paul]

As it turns out, the aux block being off was not the real problem here,
as transition from D3 to D0 is mandated by the DP spec to take a maximum
of 1ms, whereas we're allowed a 100ms timeframe to respond to ESI irqs.
The real problem here is a bit more subtle.

When doing a modeset where the problem of the sink timing out to our
sideband requests when transitioning from D3 to D0 occurs, the timeout
is from the aux block not coming on. However, nothing else times out
other than the initial phy_up message because the DPCD on call in
intel_ddi_enable_dp() ends up waking up the AUX block on the hub, not
the phy_up sideband message. This means that the real fix we need is to
use the DPMS on before sending a phy_up to ensure that the hub is ready
to accept sideband messages.

Signed-off-by: Lyude Paul 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: Laura Abbott 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_ddi.c| 6 +-
 drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a6672a9abd85..9bd675f73f7b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2324,7 +2324,11 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder, crtc_state);
 
intel_ddi_init_dp_buf_reg(encoder);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   /* for MST, we do DPMS_ON outside of here so that DPMS_ON can happen
+* before drm_dp_send_power_updown_phy()
+*/
+   if (!intel_dp->is_mst)
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index c3de0918ee13..eff9a4eae1f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -223,6 +223,7 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
 
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
drm_dp_send_power_updown_phy(_dp->mst_mgr, connector->port, true);
if (intel_dp->active_mst_links == 0)
intel_dig_port->base.pre_enable(_dig_port->base,
-- 
2.14.3

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix memory leak in intel_hdcp auth

[Patchwork]

== Series Details ==

Series: drm/i915: Fix memory leak in intel_hdcp auth
URL   : https://patchwork.freedesktop.org/series/41163/
State : failure

== Summary ==

Series 41163v1 drm/i915: Fix memory leak in intel_hdcp auth
https://patchwork.freedesktop.org/api/1.0/series/41163/revisions/1/mbox/

 Possible new issues:

Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> INCOMPLETE (fi-bxt-dsi)

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-glk-j4005) fdo#103359
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> FAIL   (fi-skl-guc) fdo#104108

fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:248  pass:219  dwarn:0   dfail:0   fail:0   skip:28 
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:517s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:508s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:423s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:315s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:433s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:504s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-guc   total:285  pass:256  dwarn:0   dfail:0   fail:1   skip:28  
time:409s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:571s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:527s

e29a10513429cca404e9847a399efbdbb4bdd4bf drm-tip: 2018y-04m-04d-20h-47m-24s UTC 
integration manifest
0ec8750b2932 drm/i915: Fix memory leak in intel_hdcp auth

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix memory leak in intel_hdcp auth

[Srivatsa, Anusha]

Thanks for fixing this.


>-Original Message-
>From: Sripada, Radhakrishna
>Sent: Tuesday, April 3, 2018 5:05 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Sripada, Radhakrishna ; Srivatsa, Anusha
>
>Subject: [PATCH 1/2] drm/i915: Fix memory leak in intel_hdcp auth
>
>Static code analysis tool reported memory leak in intel_hdcp_auth_downstream.
>Fixing the memory leak.
>
>Cc: Anusha Srivatsa 
>Signed-off-by: Radhakrishna Sripada 
Reviewed-by: Anusha Srivatsa 
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 14ca5d3057a7..ce771f6c1a5a 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -186,14 +186,18 @@ int intel_hdcp_auth_downstream(struct
>intel_digital_port *intel_dig_port,
>   return -ENOMEM;
>
>   ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
>-  if (ret)
>+  if (ret) {
>+  kfree(ksv_fifo);
>   return ret;
>+  }
>
>   /* Process V' values from the receiver */
>   for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
>   ret = shim->read_v_prime_part(intel_dig_port, i, );
>-  if (ret)
>+  if (ret) {
>+  kfree(ksv_fifo);
>   return ret;
>+  }
>   I915_WRITE(HDCP_SHA_V_PRIME(i), vprime);
>   }
>
>@@ -222,8 +226,10 @@ int intel_hdcp_auth_downstream(struct
>intel_digital_port *intel_dig_port,
>   sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
>
>   ret = intel_write_sha_text(dev_priv, sha_text);
>-  if (ret < 0)
>+  if (ret < 0) {
>+  kfree(ksv_fifo);
>   return ret;
>+  }
>
>   /* Programming guide writes this every 64 bytes */
>   sha_idx += sizeof(sha_text);
>@@ -245,13 +251,18 @@ int intel_hdcp_auth_downstream(struct
>intel_digital_port *intel_dig_port,
>   continue;
>
>   ret = intel_write_sha_text(dev_priv, sha_text);
>-  if (ret < 0)
>+  if (ret < 0) {
>+  kfree(ksv_fifo);
>   return ret;
>+  }
>+
>   sha_leftovers = 0;
>   sha_text = 0;
>   sha_idx += sizeof(sha_text);
>   }
>
>+  kfree(ksv_fifo);
>+
>   /*
>* We need to write BINFO/BSTATUS, and M0 now. Depending on how
>many
>* bytes are leftover from the last ksv, we might be able to fit them
>--
>2.9.3

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

[Intel-gfx] [PATCH v2] drm/i915: Fix memory leak in intel_hdcp auth

[Radhakrishna Sripada]

Static code analysis tool reported memory leak in
intel_hdcp_auth_downstream. Fixing the memory leak.

v2: Rebase, move free to a cleanup label(Jani)

Cc: Jani Nikula 
Cc: Anusha Srivatsa 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 98a9c81e2dc1..2db5da550a1c 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -435,7 +435,7 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
 
ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
if (ret)
-   return ret;
+   goto err;
 
/*
 * When V prime mismatches, DP Spec mandates re-read of
@@ -451,12 +451,15 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
 
if (i == tries) {
DRM_ERROR("V Prime validation failed.(%d)\n", ret);
-   return ret;
+   goto err;
}
 
DRM_DEBUG_KMS("HDCP is enabled (%d downstream devices)\n",
  num_downstream);
-   return 0;
+   ret = 0;
+err:
+   kfree(ksv_fifo);
+   return ret;
 }
 
 /* Implements Part 1 of the HDCP authorization procedure */
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v4] drm: Fix downstream dev count read

[Ramalingam C]

On Thursday 05 April 2018 12:53 AM, Sean Paul wrote:

On Wed, Apr 04, 2018 at 12:07:41PM -0700, Rodrigo Vivi wrote:

On Wed, Apr 04, 2018 at 11:57:42PM +0530, Ramalingam C wrote:

In both HDMI and DP, device count is represented by 6:0 bits of a
register(BInfo/Bstatus)

So macro for bitmasking the device_count is fixed(0x3F->0x7F).

v3:
   Retained the Rb-ed.
v4:
   %s/drm\/i915/drm [rodrigo]


Shouldn't this patch have a "Fixes:" ?

Yes, I think that'd be good.

Will add
Fixes: 495eb7f877ab drm: Add some HDCP related #defines



cc: stable?

It couldn't hurt.

Sorry what is needed here?



I pushed first 3 patches on the series to dinq.
I believe this one here could be there with Dave's ack or
maybe on drm-misc-fixes?

Meh. The severity of this isn't too big, given that I doubt people care _too_
much about plugging in more than 64 HDCP-enabled devices. If you want to drop it
in -misc-next-fixes, I can send it out next week.

While we're asking for a respin, could we add HDCP somewhere in the subject?

will change the sub to
drm: Fix HDCP downstream dev count read

--Ram


Sean


Signed-off-by: Ramalingam C 
cc: Sean Paul 
Reviewed-by: Sean Paul 
---
  include/drm/drm_hdcp.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 562fa7df2637..98e63d870139 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -19,7 +19,7 @@
  #define DRM_HDCP_RI_LEN   2
  #define DRM_HDCP_V_PRIME_PART_LEN 4
  #define DRM_HDCP_V_PRIME_NUM_PARTS5
-#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
  #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)  (x & BIT(3))
  #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)   (x & BIT(7))
  
--

2.7.4



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

Re: [Intel-gfx] [PATCH v4 1/5] i915.rst: Narration overview on GEM + minor reorder to improve narration

[Belgaumkar, Vinay]

On 4/3/2018 3:52 AM, kevin.rogo...@intel.com wrote:

From: Kevin Rogovin 

Add a narration to i915.rst about Intel GEN GPU's: engines,
driver context and relocation.

Signed-off-by: Kevin Rogovin 
---
  Documentation/gpu/i915.rst  | 116 
  drivers/gpu/drm/i915/i915_vma.h |  10 ++--
  2 files changed, 100 insertions(+), 26 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 41dc881b00dc..00f897f67f85 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -249,6 +249,99 @@ Memory Management and Command Submission
  This sections covers all things related to the GEM implementation in the
  i915 driver.
  
+Intel GPU Basics

+
+
+An Intel GPU has multiple engines. There are several engine types.
+
+- RCS engine is for rendering 3D and performing compute, this is named 
`I915_EXEC_RENDER` in user space.
+- BCS is a blitting (copy) engine, this is named `I915_EXEC_BLT` in user space.
+- VCS is a video encode and decode engine, this is named `I915_EXEC_BSD` in 
user space
+- VECS is video enhancement engine, this is named `I915_EXEC_VEBOX` in user 
space.
+- The enumeration `I915_EXEC_DEFAULT` does not refer to specific engine; 
instead it is to be used by user space to specify a default rendering engine 
(for 3D) that may or may not be the same as RCS.
+
+The Intel GPU family is a family of integrated GPU's using Unified
+Memory Access. For having the GPU "do work", user space will feed the
+GPU batch buffers via one of the ioctls `DRM_IOCTL_I915_GEM_EXECBUFFER2`
+or `DRM_IOCTL_I915_GEM_EXECBUFFER2_WR`. Most such batchbuffers will
+instruct the GPU to perform work (for example rendering) and that work
+needs memory from which to read and memory to which to write. All memory
+is encapsulated within GEM buffer objects (usually created with the ioctl
+`DRM_IOCTL_I915_GEM_CREATE`). An ioctl providing a batchbuffer for the GPU
+to create will also list all GEM buffer objects that the batchbuffer reads
+and/or writes. For implementation details of memory management see
+`GEM BO Management Implementation Details`_.
+
+The i915 driver allows user space to create a context via the ioctl
+`DRM_IOCTL_I915_GEM_CONTEXT_CREATE` which is identified by a 32-bit


Context is defined here


+integer. Such a context should be veiwed by user-space as -loosely-
+analogous to the idea of a CPU process of an operating system. The i915
+driver guarantees that commands issued to a fixed context are to be
+executed so that writes of a previously issued command are seen by
+reads of following commands. Actions issued between different contexts
+(even if from the same file descriptor) are NOT given that guarantee
+and the only way to synchornize across contexts (even from the same


s/synchornize/synchronize


+file descriptor) is through the use of fences. At least as far back as
+Gen4, also have that a context carries with it a GPU HW context;
+the HW context is essentially (most of atleast) the state of a GPU.
+In addition to the ordering gaurantees, the kernel will restore GPU
+state via HW context when commands are issued to a context, this saves
+user space the need to restore (most of atleast) the GPU state at the
+start of each batchbuffer. The ioctl `DRM_IOCTL_I915_GEM_CONTEXT_CREATE`
+is used by user space to create a hardware context which is identified


Duplicate of above definition of context?


+by a 32-bit integer. The non-deprecated ioctls to submit batchbuffer
+work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1)
+to identify what context to use with the command.
+
+The GPU has its own memory management and address space. The kernel
+driver maintains the memory translation table for the GPU. For older
+GPUs (i.e. those before Gen8), there is a single global such translation
+table, a global Graphics Translation Table (GTT). For newer generation
+GPUs each context has its own translation table, called Per-Process
+Graphics Translation Table (PPGTT). Of important note, is that although
+PPGTT is named per-process it is actually per context. When user space
+submits a batchbuffer, the kernel walks the list of GEM buffer objects
+used by the batchbuffer and guarantees that not only is the memory of
+each such GEM buffer object resident but it is also present in the
+(PP)GTT. If the GEM buffer object is not yet placed in the (PP)GTT,
+then it is given an address. Two consequences of this are: the kernel
+needs to edit the batchbuffer submitted to write the correct value of
+the GPU address when a GEM BO is assigned a GPU address and the kernel
+might evict a different GEM BO from the (PP)GTT to make address room
+for another GEM BO. Consequently, the ioctls submitting a batchbuffer
+for execution also include a list of all locations within buffers that
+refer to GPU-addresses so that the kernel can edit the buffer correctly.
+This 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with trace: Fixup logic inversion on setting trace_global_clock defaults (rev3)

[Patchwork]

== Series Details ==

Series: series starting with trace: Fixup logic inversion on setting 
trace_global_clock defaults (rev3)
URL   : https://patchwork.freedesktop.org/series/40952/
State : failure

== Summary ==

Applying: trace: Fixup logic inversion on setting trace_global_clock defaults
error: sha1 information is lacking or useless (kernel/trace/trace.c).
error: could not build fake ancestor
Patch failed at 0001 trace: Fixup logic inversion on setting trace_global_clock 
defaults
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

___
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 [v6,01/12] drm/i915: Correctly handle error path in i915_gem_init_hw

[Patchwork]

== Series Details ==

Series: series starting with [v6,01/12] drm/i915: Correctly handle error path 
in i915_gem_init_hw
URL   : https://patchwork.freedesktop.org/series/41159/
State : success

== Summary ==

Series 41159v1 series starting with [v6,01/12] drm/i915: Correctly handle error 
path in i915_gem_init_hw
https://patchwork.freedesktop.org/api/1.0/series/41159/revisions/1/mbox/

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-glk-j4005) fdo#103359

fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:534s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:516s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:521s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:527s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:507s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:410s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:465s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:436s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:430s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:574s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:401s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:518s

e29a10513429cca404e9847a399efbdbb4bdd4bf drm-tip: 2018y-04m-04d-20h-47m-24s UTC 
integration manifest
935985da86a5 HAX: Enable GuC for CI
84d32acff83d drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c
ea3137359cbe drm/i915/uc: Use helper functions to detect fw load status
2811630759e1 drm/i915/uc: Use correct error code for GuC initialization failure
46d163d34342 drm/i915/uc: Fully sanitize uC within intel_uc_fini_hw
ffe83d5f08e5 drm/i915/guc: Restore symmetric doorbell cleanup
d78cbce3429a drm/i915/guc: Ignore dev_priv->gt.awake while disabling submission
02f809bd0ab2 drm/i915: Add i915_gem_fini_hw to i915_reset
254ab376bd38 drm/i915: Add i915_gem_fini_hw to i915_gem_suspend
7c48b9b26215 drm/i915: Introduce i915_gem_fini_hw for symmetry with 
i915_gem_init_hw
3bcf133ff8ff drm/i915: Move i915_gem_fini to i915_gem.c
34610dfa027f drm/i915: Correctly handle error path in i915_gem_init_hw

== Logs ==

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

[Intel-gfx] [PATCH] trace: Fixup logic inversion on setting trace_global_clock defaults

[Chris Wilson]

In commit 932066a15335 ("tracing: Default to using trace_global_clock if
sched_clock is unstable"), the logic for deciding to override the
default clock if unstable was reversed from the earlier posting. I was
trying to reduce the width of the message by using an early return
rather than a if-block, but reverted back to using the if-block and
accidentally left the predicate inverted.

Fixes: 932066a15335 ("tracing: Default to using trace_global_clock if 
sched_clock is unstable")
Signed-off-by: Chris Wilson 
Cc: Steven Rostedt (VMware) 
---
 kernel/trace/trace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 0f47e653ffd8..e18e69183c9a 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -8602,7 +8602,7 @@ late_initcall_sync(clear_boot_tracer);
 __init static int tracing_set_default_clock(void)
 {
/* sched_clock_stable() is determined in late_initcall */
-   if (trace_boot_clock || sched_clock_stable()) {
+   if (!trace_boot_clock && !sched_clock_stable()) {
printk(KERN_WARNING
   "Unstable clock detected, switching default tracing 
clock to \"global\"\n"
   "If you want to keep using the local clock, then add:\n"
-- 
2.16.3

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

[Intel-gfx] ✓ Fi.CI.IGT: success for HDCP1.4 fixes (rev6)

[Patchwork]

== Series Details ==

Series: HDCP1.4 fixes (rev6)
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

 Known issues:

Test drv_selftest:
Subgroup live_gtt:
incomplete -> PASS   (shard-apl) fdo#103927
Test kms_flip:
Subgroup plain-flip-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3498 pass:1834 dwarn:1   dfail:0   fail:7   skip:1655 
time:12876s
shard-hswtotal:3498 pass:1784 dwarn:1   dfail:0   fail:2   skip:1710 
time:11490s
shard-snbtotal:3498 pass:1377 dwarn:1   dfail:0   fail:2   skip:2118 
time:7095s
Blacklisted hosts:
shard-kbltotal:3498 pass:1961 dwarn:1   dfail:0   fail:7   skip:1529 
time:9232s

== Logs ==

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

[Intel-gfx] [PATCH v6 04/12] drm/i915: Add i915_gem_fini_hw to i915_gem_suspend

[Michal Wajdeczko]

By calling i915_gem_init_hw in i915_gem_resume and not calling
i915_gem_fini_hw in i915_gem_suspend we introduced asymmetry
in init_hw/fini_hw calls. Let's fix that.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 701f137..f5ef02d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4986,6 +4986,7 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
 * machines is a good idea, we don't - just in case it leaves the
 * machine in an unusable condition.
 */
+   i915_gem_fini_hw(dev_priv);
intel_uc_sanitize(dev_priv);
i915_gem_sanitize(dev_priv);
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 11/12] drm/i915/uc: Trivial s/dev_priv/i915 in intel_uc.c

[Michal Wajdeczko]

Some functions already use i915 name instead of dev_priv.
Let's rename this param in all remaining functions, except
those that still use legacy macros.

v2: don't forget about function descriptions (Sagar)
v3: rebased

Signed-off-by: Michal Wajdeczko 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_uc.c | 133 
 1 file changed, 66 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index ed39273..ccf75aa 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -50,10 +50,10 @@ static int __intel_uc_reset_hw(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-static int __get_platform_enable_guc(struct drm_i915_private *dev_priv)
+static int __get_platform_enable_guc(struct drm_i915_private *i915)
 {
-   struct intel_uc_fw *guc_fw = _priv->guc.fw;
-   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   struct intel_uc_fw *guc_fw = >guc.fw;
+   struct intel_uc_fw *huc_fw = >huc.fw;
int enable_guc = 0;
 
/* Default is to enable GuC/HuC if we know their firmwares */
@@ -67,11 +67,11 @@ static int __get_platform_enable_guc(struct 
drm_i915_private *dev_priv)
return enable_guc;
 }
 
-static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
+static int __get_default_guc_log_level(struct drm_i915_private *i915)
 {
int guc_log_level;
 
-   if (!HAS_GUC(dev_priv) || !intel_uc_is_using_guc())
+   if (!HAS_GUC(i915) || !intel_uc_is_using_guc())
guc_log_level = GUC_LOG_LEVEL_DISABLED;
else if (IS_ENABLED(CONFIG_DRM_I915_DEBUG) ||
 IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
@@ -86,7 +86,7 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
 
 /**
  * sanitize_options_early - sanitize uC related modparam options
- * @dev_priv: device private
+ * @i915: device private
  *
  * In case of "enable_guc" option this function will attempt to modify
  * it only if it was initially set to "auto(-1)". Default value for this
@@ -101,14 +101,14 @@ static int __get_default_guc_log_level(struct 
drm_i915_private *dev_priv)
  * unless GuC is enabled on given platform and the driver is compiled with
  * debug config when this modparam will default to "enable(1..4)".
  */
-static void sanitize_options_early(struct drm_i915_private *dev_priv)
+static void sanitize_options_early(struct drm_i915_private *i915)
 {
-   struct intel_uc_fw *guc_fw = _priv->guc.fw;
-   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   struct intel_uc_fw *guc_fw = >guc.fw;
+   struct intel_uc_fw *huc_fw = >huc.fw;
 
/* A negative value means "use platform default" */
if (i915_modparams.enable_guc < 0)
-   i915_modparams.enable_guc = __get_platform_enable_guc(dev_priv);
+   i915_modparams.enable_guc = __get_platform_enable_guc(i915);
 
DRM_DEBUG_DRIVER("enable_guc=%d (submission:%s huc:%s)\n",
 i915_modparams.enable_guc,
@@ -119,28 +119,28 @@ static void sanitize_options_early(struct 
drm_i915_private *dev_priv)
if (intel_uc_is_using_guc() && !intel_uc_fw_is_selected(guc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
 "enable_guc", i915_modparams.enable_guc,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "no GuC firmware");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "no GuC firmware");
}
 
/* Verify HuC firmware availability */
if (intel_uc_is_using_huc() && !intel_uc_fw_is_selected(huc_fw)) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
 "enable_guc", i915_modparams.enable_guc,
-!HAS_HUC(dev_priv) ? "no HuC hardware" :
- "no HuC firmware");
+!HAS_HUC(i915) ? "no HuC hardware" :
+ "no HuC firmware");
}
 
/* A negative value means "use platform/config default" */
if (i915_modparams.guc_log_level < 0)
i915_modparams.guc_log_level =
-   __get_default_guc_log_level(dev_priv);
+   __get_default_guc_log_level(i915);
 
if (i915_modparams.guc_log_level > 0 && !intel_uc_is_using_guc()) {
DRM_WARN("Incompatible option detected: %s=%d, %s!\n",
 "guc_log_level", i915_modparams.guc_log_level,
-!HAS_GUC(dev_priv) ? "no GuC hardware" :
- "GuC not enabled");
+!HAS_GUC(i915) ? "no GuC hardware" :
+ "GuC not enabled");
   

[Intel-gfx] [PATCH v6 06/12] drm/i915/guc: Ignore dev_priv->gt.awake while disabling submission

[Michal Wajdeczko]

In next patch we will also try to disable GuC submission during reset
path, where where we don't wait for idle_work to complete.
Remove GEM_BUG_ON to allow new scenario. While here fix order
to match symmetry with enable function.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 9712123..0facfd2 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1261,13 +1261,9 @@ void intel_guc_submission_disable(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
 
-   GEM_BUG_ON(dev_priv->gt.awake); /* GT should be parked first */
-
+   intel_engines_reset_default_submission(dev_priv);
guc_interrupts_release(dev_priv);
guc_clients_doorbell_fini(guc);
-
-   /* Revert back to manual ELSP submission */
-   intel_engines_reset_default_submission(dev_priv);
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 09/12] drm/i915/uc: Use correct error code for GuC initialization failure

[Michal Wajdeczko]

Since commit 6ca9a2beb54a ("drm/i915: Unwind i915_gem_init() failure")
we believed that we correctly handle all errors encountered during
GuC initialization, including special one that indicates request to
run driver with disabled GPU submission (-EIO).

Unfortunately since commit 121981fafe69 ("drm/i915/guc: Combine
enable_guc_loading|submission modparams") we stopped using that
error code to avoid unwanted fallback to execlist submission mode.

In result any GuC initialization failure was treated as non-recoverable
error leading to driver load abort, so we could not even read related
GuC error log to investigate cause of the problem.

Fix that by always returning -EIO on uC hardware related failure.

v2: don't allow -EIO from uc_init
don't call uc_fini[_misc] on -EIO
mark guc fw as failed on hw init failure
prepare uc_fini_hw to run after earlier -EIO

v3: update comments (Sagar)
use sanitize functions on failure in init_hw (Michal)
and also sanitize guc/huc fw in fini_hw (Michal)

v4: rebase
v5: rebase

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_gem.c| 17 ++---
 drivers/gpu/drm/i915/intel_guc.h   |  5 +
 drivers/gpu/drm/i915/intel_uc.c| 15 +++
 drivers/gpu/drm/i915/intel_uc_fw.h |  5 +
 4 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ea00f3e..6ab5f4c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5369,8 +5369,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_init_gt_powersave(dev_priv);
 
ret = intel_uc_init(dev_priv);
-   if (ret)
+   if (ret) {
+   GEM_BUG_ON(ret == -EIO);
goto err_pm;
+   }
 
ret = i915_gem_init_hw(dev_priv);
if (ret)
@@ -5417,7 +5419,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
i915_gem_contexts_lost(dev_priv);
i915_gem_fini_hw(dev_priv);
 err_uc_init:
-   intel_uc_fini(dev_priv);
+   if (ret != -EIO)
+   intel_uc_fini(dev_priv);
 err_pm:
if (ret != -EIO) {
intel_cleanup_gt_powersave(dev_priv);
@@ -5431,15 +5434,15 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(_priv->drm.struct_mutex);
 
-   intel_uc_fini_misc(dev_priv);
-
-   if (ret != -EIO)
+   if (ret != -EIO) {
+   intel_uc_fini_misc(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
+   }
 
if (ret == -EIO) {
/*
-* Allow engine initialisation to fail by marking the GPU as
-* wedged. But we only want to do this where the GPU is angry,
+* Allow engines or uC initialization to fail by marking the GPU
+* as wedged. But we only want to do this when the GPU is angry,
 * for all other failure, such as an allocation failure, bail.
 */
if (!i915_terminally_wedged(_priv->gpu_error)) {
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index f1265e1..c587068 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -176,6 +176,11 @@ static inline int intel_guc_sanitize(struct intel_guc *guc)
return 0;
 }
 
+static inline bool intel_guc_is_loaded(struct intel_guc *guc)
+{
+   return intel_uc_fw_is_loaded(>fw);
+}
+
 static inline void intel_guc_enable_msg(struct intel_guc *guc, u32 mask)
 {
spin_lock_irq(>irq_lock);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 0439966..7862731 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -332,6 +332,8 @@ static void __uc_sanitize(struct drm_i915_private *i915)
intel_huc_sanitize(huc);
intel_guc_sanitize(guc);
 
+   GEM_BUG_ON(intel_guc_is_loaded(guc));
+
__intel_uc_reset_hw(i915);
 }
 
@@ -420,11 +422,13 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * Note that there is no fallback as either user explicitly asked for
 * the GuC or driver default option was to run with the GuC enabled.
 */
-   if (GEM_WARN_ON(ret == -EIO))
-   ret = -EINVAL;
-
dev_err(dev_priv->drm.dev, "GuC initialization failed %d\n", ret);
-   return ret;
+
+   /* Sanitize GuC/HuC to avoid clean-up on wedged */
+   __uc_sanitize(dev_priv);
+
+   /* We want to disable GPU submission but keep KMS alive */
+   return -EIO;
 }
 
 void intel_uc_fini_hw(struct 

[Intel-gfx] [PATCH v6 08/12] drm/i915/uc: Fully sanitize uC within intel_uc_fini_hw

[Michal Wajdeczko]

As we always call intel_uc_sanitize after every call to
intel_uc_fini_hw we may drop redundant call and sanitize
uC from the fini_hw function.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 --
 drivers/gpu/drm/i915/intel_uc.c | 9 +++--
 drivers/gpu/drm/i915/intel_uc.h | 1 -
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f5ef02d..ea00f3e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2998,7 +2998,6 @@ int i915_gem_reset_prepare(struct drm_i915_private 
*dev_priv)
}
 
i915_gem_revoke_fences(dev_priv);
-   intel_uc_sanitize(dev_priv);
 
return err;
 }
@@ -4987,7 +4986,6 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
 * machine in an unusable condition.
 */
i915_gem_fini_hw(dev_priv);
-   intel_uc_sanitize(dev_priv);
i915_gem_sanitize(dev_priv);
 
intel_runtime_pm_put(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 1cffaf7..0439966 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -322,18 +322,13 @@ void intel_uc_fini(struct drm_i915_private *dev_priv)
intel_guc_fini(guc);
 }
 
-void intel_uc_sanitize(struct drm_i915_private *i915)
+static void __uc_sanitize(struct drm_i915_private *i915)
 {
struct intel_guc *guc = >guc;
struct intel_huc *huc = >huc;
 
-   if (!USES_GUC(i915))
-   return;
-
GEM_BUG_ON(!HAS_GUC(i915));
 
-   guc_disable_communication(guc);
-
intel_huc_sanitize(huc);
intel_guc_sanitize(guc);
 
@@ -445,6 +440,8 @@ void intel_uc_fini_hw(struct drm_i915_private *dev_priv)
intel_guc_submission_disable(guc);
 
guc_disable_communication(guc);
+
+   __uc_sanitize(dev_priv);
 }
 
 int intel_uc_suspend(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 25d73ad..64aaf93 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -33,7 +33,6 @@
 void intel_uc_init_mmio(struct drm_i915_private *dev_priv);
 int intel_uc_init_misc(struct drm_i915_private *dev_priv);
 void intel_uc_fini_misc(struct drm_i915_private *dev_priv);
-void intel_uc_sanitize(struct drm_i915_private *dev_priv);
 int intel_uc_init_hw(struct drm_i915_private *dev_priv);
 void intel_uc_fini_hw(struct drm_i915_private *dev_priv);
 int intel_uc_init(struct drm_i915_private *dev_priv);
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 07/12] drm/i915/guc: Restore symmetric doorbell cleanup

[Michal Wajdeczko]

In commit 9192d4fb811e ("drm/i915/guc: Extract doorbell creation
from client allocation") we introduced asymmetry in doorbell cleanup
to avoid warnings due to failed communication with already reset GuC.
As we improved our reset/unload paths, we can restore symmetry in
doorbell cleanup, as GuC should be still active by now.

Suggested-by: Sagar Arun Kamble 
Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Chris Wilson 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 0facfd2..3adac5b 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -848,18 +848,9 @@ static int guc_clients_doorbell_init(struct intel_guc *guc)
 
 static void guc_clients_doorbell_fini(struct intel_guc *guc)
 {
-   /*
-* By the time we're here, GuC has already been reset.
-* Instead of trying (in vain) to communicate with it, let's just
-* cleanup the doorbell HW and our internal state.
-*/
-   if (guc->preempt_client) {
-   __destroy_doorbell(guc->preempt_client);
-   __update_doorbell_desc(guc->preempt_client,
-  GUC_DOORBELL_INVALID);
-   }
-   __destroy_doorbell(guc->execbuf_client);
-   __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID);
+   if (guc->preempt_client)
+   destroy_doorbell(guc->preempt_client);
+   destroy_doorbell(guc->execbuf_client);
 }
 
 /**
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 12/12] HAX: Enable GuC for CI

[Michal Wajdeczko]

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index c963603..53037b5 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 01/12] drm/i915: Correctly handle error path in i915_gem_init_hw

[Michal Wajdeczko]

In function gem_init_hw() we are calling uc_init_hw() but in case
of error later in function, we missed to call matching uc_fini_hw()

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9650a7b..65ba104 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5171,9 +5171,15 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
 
/* Only when the HW is re-initialised, can we replay the requests */
ret = __i915_gem_restart_engines(dev_priv);
+   if (ret)
+   goto cleanup_uc;
 out:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
+
+cleanup_uc:
+   intel_uc_fini_hw(dev_priv);
+   goto out;
 }
 
 static int __intel_engines_record_defaults(struct drm_i915_private *i915)
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 03/12] drm/i915: Introduce i915_gem_fini_hw for symmetry with i915_gem_init_hw

[Michal Wajdeczko]

We have i915_gem_init_hw function that on failure requires some
cleanup in uC and then in other places we were trying to do
such cleanup directly. Let's fix that by adding i915_gem_fini_hw
for nice symmetry with init_hw and call it on cleanup paths.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 13 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 19ed3d4..97f04fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3139,6 +3139,7 @@ void i915_gem_reset_engine(struct intel_engine_cs *engine,
 int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
 void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
 void i915_gem_fini(struct drm_i915_private *dev_priv);
+void i915_gem_fini_hw(struct drm_i915_private *dev_priv);
 void i915_gem_cleanup_engines(struct drm_i915_private *dev_priv);
 int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
   unsigned int flags);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 19d493b..701f137 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5182,6 +5182,15 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
goto out;
 }
 
+void i915_gem_fini_hw(struct drm_i915_private *dev_priv)
+{
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+   intel_uc_fini_hw(dev_priv);
+
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+}
+
 static int __intel_engines_record_defaults(struct drm_i915_private *i915)
 {
struct i915_gem_context *ctx;
@@ -5407,7 +5416,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 err_init_hw:
i915_gem_wait_for_idle(dev_priv, I915_WAIT_LOCKED);
i915_gem_contexts_lost(dev_priv);
-   intel_uc_fini_hw(dev_priv);
+   i915_gem_fini_hw(dev_priv);
 err_uc_init:
intel_uc_fini(dev_priv);
 err_pm:
@@ -5451,7 +5460,7 @@ void i915_gem_fini(struct drm_i915_private *dev_priv)
i915_gem_drain_workqueue(dev_priv);
 
mutex_lock(_priv->drm.struct_mutex);
-   intel_uc_fini_hw(dev_priv);
+   i915_gem_fini_hw(dev_priv);
intel_uc_fini(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 10/12] drm/i915/uc: Use helper functions to detect fw load status

[Michal Wajdeczko]

We don't have to check load status values.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_huc.c | 2 +-
 drivers/gpu/drm/i915/intel_uc.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 2912852..975ae61 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -51,7 +51,7 @@ int intel_huc_auth(struct intel_huc *huc)
u32 status;
int ret;
 
-   if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   if (!intel_uc_fw_is_loaded(>fw))
return -ENOEXEC;
 
vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0,
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 7862731..ed39273 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -459,7 +459,7 @@ int intel_uc_suspend(struct drm_i915_private *i915)
if (!USES_GUC(i915))
return 0;
 
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   if (!intel_guc_is_loaded(guc))
return 0;
 
err = intel_guc_suspend(guc);
@@ -481,7 +481,7 @@ int intel_uc_resume(struct drm_i915_private *i915)
if (!USES_GUC(i915))
return 0;
 
-   if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
+   if (!intel_guc_is_loaded(guc))
return 0;
 
gen9_enable_guc_interrupts(i915);
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 02/12] drm/i915: Move i915_gem_fini to i915_gem.c

[Michal Wajdeczko]

We should keep i915_gem_init/fini functions together for easier
tracking of their symmetry.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 20 
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 20 
 3 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d354627..07e212a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -625,26 +625,6 @@ static bool i915_switcheroo_can_switch(struct pci_dev 
*pdev)
.can_switch = i915_switcheroo_can_switch,
 };
 
-static void i915_gem_fini(struct drm_i915_private *dev_priv)
-{
-   /* Flush any outstanding unpin_work. */
-   i915_gem_drain_workqueue(dev_priv);
-
-   mutex_lock(_priv->drm.struct_mutex);
-   intel_uc_fini_hw(dev_priv);
-   intel_uc_fini(dev_priv);
-   i915_gem_cleanup_engines(dev_priv);
-   i915_gem_contexts_fini(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
-
-   intel_uc_fini_misc(dev_priv);
-   i915_gem_cleanup_userptr(dev_priv);
-
-   i915_gem_drain_freed_objects(dev_priv);
-
-   WARN_ON(!list_empty(_priv->contexts.list));
-}
-
 static int i915_load_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b17..19ed3d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3138,6 +3138,7 @@ void i915_gem_reset_engine(struct intel_engine_cs *engine,
 int __must_check i915_gem_init(struct drm_i915_private *dev_priv);
 int __must_check i915_gem_init_hw(struct drm_i915_private *dev_priv);
 void i915_gem_init_swizzling(struct drm_i915_private *dev_priv);
+void i915_gem_fini(struct drm_i915_private *dev_priv);
 void i915_gem_cleanup_engines(struct drm_i915_private *dev_priv);
 int i915_gem_wait_for_idle(struct drm_i915_private *dev_priv,
   unsigned int flags);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 65ba104..19d493b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5445,6 +5445,26 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
return ret;
 }
 
+void i915_gem_fini(struct drm_i915_private *dev_priv)
+{
+   /* Flush any outstanding unpin_work. */
+   i915_gem_drain_workqueue(dev_priv);
+
+   mutex_lock(_priv->drm.struct_mutex);
+   intel_uc_fini_hw(dev_priv);
+   intel_uc_fini(dev_priv);
+   i915_gem_cleanup_engines(dev_priv);
+   i915_gem_contexts_fini(dev_priv);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   intel_uc_fini_misc(dev_priv);
+   i915_gem_cleanup_userptr(dev_priv);
+
+   i915_gem_drain_freed_objects(dev_priv);
+
+   WARN_ON(!list_empty(_priv->contexts.list));
+}
+
 void i915_gem_init_mmio(struct drm_i915_private *i915)
 {
i915_gem_sanitize(i915);
-- 
1.9.1

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

[Intel-gfx] [PATCH v6 05/12] drm/i915: Add i915_gem_fini_hw to i915_reset

[Michal Wajdeczko]

By calling in i915_reset only i915_gem_init_hw without previous
i915_gem_fini_hw we introduced asymmetry. Let's fix that.

Signed-off-by: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 07e212a..9977adf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1897,6 +1897,8 @@ void i915_reset(struct drm_i915_private *i915)
goto error;
}
 
+   i915_gem_fini_hw(i915);
+
for (i = 0; i < 3; i++) {
ret = intel_gpu_reset(i915, ALL_ENGINES);
if (ret == 0)
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v3] trace: Default to using trace_global_clock if sched_clock is unstable

[Steven Rostedt]

Can you add a patch on top. I already added your patch to my tree.

See branch ftrace/core
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git

-- Steve


On April 4, 2018 4:51:02 PM EDT, Chris Wilson  wrote:
>Across suspend, we may see a very large drift in timestamps if the
>sched
>clock is unstable, prompting the global trace's ringbuffer code to warn
>and suggest switching to the global clock. Preempt this request by
>detecting when the sched clock is unstable (determined during
>late_initcall) and automatically switching the default clock over to
>trace_global_clock.
>
>This should prevent requiring user interaction to resolve warnings such
>as:
>
>Delta way too big! 18446743856563626466 ts=18446744054496180323 write
>stamp = 197932553857
>If you just came from a suspend/resume,
>please switch to the trace global clock:
>echo global > /sys/kernel/debug/tracing/trace_clock
>
>Signed-off-by: Chris Wilson 
>Cc: Steven Rostedt (VMware) 
>---
>v2: Tell the user what's happening and what they can do to correct it.
>v3: Restore the correct logic to switch only if the default trace clock
>(no override) is found to be *not* stable.
>---
> kernel/trace/trace.c | 19 +++
> 1 file changed, 19 insertions(+)
>
>diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>index 13baf85b27d8..a1810b053f65 100644
>--- a/kernel/trace/trace.c
>+++ b/kernel/trace/trace.c
>@@ -41,6 +41,7 @@
> #include 
> #include 
> #include 
>+#include 
> #include 
> 
> #include "trace.h"
>@@ -8505,3 +8506,21 @@ __init static int clear_boot_tracer(void)
> 
> fs_initcall(tracer_init_tracefs);
> late_initcall_sync(clear_boot_tracer);
>+
>+#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
>+__init static int tracing_set_default_clock(void)
>+{
>+  /* sched_clock_stable() is determined in late_initcall */
>+  if (!trace_boot_clock && !sched_clock_stable()) {
>+  printk(KERN_WARNING
>+ "Unstable clock detected, switching default tracing 
>clock to
>\"global\"\n"
>+ "If you want to keep using the local clock, then add:\n"
>+ "  \"trace_clock=local\"\n"
>+ "on the kernel command line\n");
>+  tracing_set_clock(_trace, "global");
>+  }
>+
>+  return 0;
>+}
>+late_initcall_sync(tracing_set_default_clock);
>+#endif

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI] drm/i915/selftests: Add basic sanitychecks for execlists

[Chris Wilson]

Quoting Chris Wilson (2018-04-04 10:33:29)
> Before adding a new feature to execlists submission, we should endeavour
> to cover the baseline behaviour with selftests. So start the ball
> rolling.
> 
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> CC: Michel Thierry 
> Cc: Jeff McGee 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Reviewed-by: Joonas Lahtinen 

Thanks for the review, applied this version that checkpatch is almost
happy with (dear checkpatch, it has to be a rhs so no side effects and
repetition is essential).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

[Chris Wilson]

Quoting Xidong Wang (2018-04-04 08:37:54)
> In eb_lookup_vmas(), the return value of kmem_cache_alloc() is freed
> with kfree(). I think the expected paired function is kmem_cahce_free().
> 
> Signed-off-by: Xidong Wang 

Thank you for the fix; applied.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] trace: Default to using trace_global_clock if sched_clock is unstable

[Chris Wilson]

Across suspend, we may see a very large drift in timestamps if the sched
clock is unstable, prompting the global trace's ringbuffer code to warn
and suggest switching to the global clock. Preempt this request by
detecting when the sched clock is unstable (determined during
late_initcall) and automatically switching the default clock over to
trace_global_clock.

This should prevent requiring user interaction to resolve warnings such
as:

Delta way too big! 18446743856563626466 ts=18446744054496180323 write stamp 
= 197932553857
If you just came from a suspend/resume,
please switch to the trace global clock:
echo global > /sys/kernel/debug/tracing/trace_clock

Signed-off-by: Chris Wilson 
Cc: Steven Rostedt (VMware) 
---
v2: Tell the user what's happening and what they can do to correct it.
v3: Restore the correct logic to switch only if the default trace clock
(no override) is found to be *not* stable.
---
 kernel/trace/trace.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 13baf85b27d8..a1810b053f65 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "trace.h"
@@ -8505,3 +8506,21 @@ __init static int clear_boot_tracer(void)
 
 fs_initcall(tracer_init_tracefs);
 late_initcall_sync(clear_boot_tracer);
+
+#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
+__init static int tracing_set_default_clock(void)
+{
+   /* sched_clock_stable() is determined in late_initcall */
+   if (!trace_boot_clock && !sched_clock_stable()) {
+   printk(KERN_WARNING
+  "Unstable clock detected, switching default tracing 
clock to \"global\"\n"
+  "If you want to keep using the local clock, then add:\n"
+  "  \"trace_clock=local\"\n"
+  "on the kernel command line\n");
+   tracing_set_clock(_trace, "global");
+   }
+
+   return 0;
+}
+late_initcall_sync(tracing_set_default_clock);
+#endif
-- 
2.16.3

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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Ville Syrjälä]

On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 04-04-18 17:50, Ville Syrjälä wrote:
> > On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 30-03-18 15:25, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 30-03-18 14:44, Chris Wilson wrote:
>  Quoting Hans de Goede (2018-03-30 13:37:40)
> > Hi,
> >
> > On 30-03-18 14:30, Chris Wilson wrote:
> >> Quoting Hans de Goede (2018-03-30 13:27:15)
> >>> Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> >>> skipping the first 4k by passing 4096 as start of the address range 
> >>> passed
> >>> to drm_mm_init(). This means that calling drm_mm_reserve_node() to 
> >>> try and
> >>> reserve the firmware framebuffer so that we can inherit it would 
> >>> always
> >>> fail, as the firmware framebuffer starts at address 0.
> >>>
> >>> Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> >>> everything >= gen8") says in its commit message: "This is confirmed 
> >>> to fix
> >>> Skylake screen flickering issues (probably caused by the fact that we
> >>> initialized a ring in the first page of stolen, but I didn't 100% 
> >>> confirm
> >>> this theory)."
> >>>
> >>> Which suggests that it is safe to use the first page for a linear
> >>> framebuffer as the firmware is doing.
> >>>
> >>> This commit always passes 0 as start to drm_mm_init() and works around
> >>> WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> >>> by insuring the start address passed by to 
> >>> drm_mm_insert_node_in_range()
> >>> is always 4k or more. All entry points to i915_gem_stolen.c go through
> >>> i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> >>> objects such as ring-buffers will not be allocated in the first 4k.
> >>>
> >>> The one exception is i915_gem_object_create_stolen_for_preallocated()
> >>> which directly calls drm_mm_reserve_node() which now will be able to
> >>> use the first 4k.
> >>>
> >>> This fixes the i915 driver no longer being able to inherit the 
> >>> firmware
> >>> framebuffer on gen8+, which fixes the video output changing from the
> >>> vendor logo to a black screen as soon as the i915 driver is loaded
> >>> (on systems without fbcon).
> >>
> >> We've been told by the HW guys not to use the first page. (That's my
> >> understanding from every time this gets questioned.)
> >
> > Yet the GOP is happily using the first page. I think we may need to make
> > a difference here between the GPU not using the first page and the
> > display engine/pipeline not using the first page. Note that my patch
> > only influences the inheriting of the initial framebuffer as allocated
> > by the GOP. It does not influence any other allocations from the
> > reserved range, those will still all avoid the first page.
> >
> > Without this patch fastboot / flickerfree support is essentially broken
> > on any gen8+ hardware given that one of the goals of atomic is to be
> > able to do flickerfree transitions I think that this warrants a closer
> > look then just simply saying never use the first page.
> 
>  The concern is what else (i.e. nothing that we allocated ourselves) that
>  may be in the first page...
> >>>
> >>> Given that the GOP has put its framebuffer there at least at boot there
> >>> is nothing there, otherwise it would show up on the display.
> >>>
> >>> We have a whole bunch of code to inherit the BIOS fb in intel_display.c
> >>> and AFAIK that code is there because this inheriting the BIOS fb is
> >>> deemed an important feature. So I'm not happy at all with the handwavy
> >>> best to not touch it answer I'm getting to this patch.
> >>>
> >>> Unless there are some clear answer from the hardware folks which 
> >>> specifically
> >>> say we cannot put a framebuffer there (and then why is the GOP doing it?)
> >>> then I believe that the best way forward here is to get various people to
> >>> test with this patch and the best way to do that is probably to put it
> >>> in next. Note I deliberately did not add a Cc stable.
> >>
> >> To elaborate on this, the excluding of the first 4k of the stolen memory
> >> region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
> >> which in turn causes intel_find_initial_plane_obj() to call
> >> intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
> >> completely turns off the display which leads to a very ugly flickering
> >> of the display at boot (as well as replacing the vendor logo with a
> >> black screen).
> >>
> >> I think we can all agree that this behavior is undesirable and even a
> >> regression in behavior caused by the fix to exclude the first 4k.
> >>
> >> Chris, if my patch is not an acceptable way to fix this, then 

Re: [Intel-gfx] [PATCH v2 1/2] trace: Default to using trace_global_clock if sched_clock is unstable

[Chris Wilson]

Quoting Chris Wilson (2018-03-30 16:01:31)
> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sched clock is unstable (determined during
> late_initcall) and automatically switching the default clock over to
> trace_global_clock.
> 
> This should prevent requiring user interaction to resolve warnings such
> as:
> 
> Delta way too big! 18446743856563626466 ts=18446744054496180323 write 
> stamp = 197932553857
> If you just came from a suspend/resume,
> please switch to the trace global clock:
> echo global > /sys/kernel/debug/tracing/trace_clock
> 
> Signed-off-by: Chris Wilson 
> Cc: Steven Rostedt (VMware) 
> ---
> v2: Tell the user what's happening and what they can do to correct it.
> ---
>  kernel/trace/trace.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 13baf85b27d8..7c155fa879e1 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "trace.h"
> @@ -8505,3 +8506,21 @@ __init static int clear_boot_tracer(void)
>  
>  fs_initcall(tracer_init_tracefs);
>  late_initcall_sync(clear_boot_tracer);
> +
> +#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
> +__init static int tracing_set_default_clock(void)
> +{
> +   /* sched_clock_stable() is determined in late_initcall */
> +   if (trace_boot_clock || sched_clock_stable()) {

Oh flip, I reversed the logic from v1.

I was going to do an early return:

if (trace_boot_clock || sched_clock_stable())
return;

to shift the message to the left slightly, at left it half way.

(I was wondering why CI didn't show the same results as v1!)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/1] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.

If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.

Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.

Changes since v2:
 - Fix patch name, no functional changes
Changes since v3:
 - acks, t-b's

Signed-off-by: Lyude Paul 
Acked-by: Dhinakaran Pandiyan 
Tested-by: Laura Abbott 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
return;
 
if (mode != DRM_MODE_DPMS_ON) {
+   unsigned char data = intel_dp->is_mst ?
+   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
 
-   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
-DP_SET_POWER_D3);
+   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
-- 
2.14.3

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

[Intel-gfx] [PATCH 0/1] Keep AUX on while disabling DPMS for MST

[Lyude Paul]

Resend that was required anyway since I missed some t-b's and some acks.
Trying to figure out what patchwork is doing that's making this patch
not get noticed. Maybe it's the lack of cover letters on the previous
versions of this

Lyude Paul (1):
  drm/i915: Keep AUX block running when disabling DPMS for MST

 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.14.3

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

[Intel-gfx] [PATCH v2][RESEND] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

While enabling/disabling DPMS before link training with MST hubs is
perfectly valid; unfortunately disabling DPMS results in some devices
disabling their AUX CH block as well. For SST this isn't as much of a
problem, but for MST we need to be able to continue handling aux
transactions even when none of the sinks are turned on since it's
possible for us to have a single atomic commit which results in
disabling each downstream sink, followed by subsequently re-enabling
each sink.

If we don't do this, we'll end up stalling any pending ESI interrupts
from the sink for up to 1ms. Unfortunately, dropping ESIs during this
timespan makes it so that link fallback retraining for MST (which I will
be submitting to the ML shortly) fails due to the channel EQ failure
interrupts potentially getting dropped. Additionally, when performing a
modeset that brings the hub status's link status from bad -> good having
ESIs disabled for that long causes us to miss the hub's response to us
trying to start link training as well.

Since any sink with MST is going to support DisplayPort 1.2 anyway, save
us the hassle of trying to wait until the sink comes back up and just
never shut the aux block down.

Changes since v2:
 - Fix patch name, no functional changes

Signed-off-by: Lyude Paul 
Cc: Laura Abbott 
Cc: Dhinakaran Pandiyan 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62f82c4298ac..0479c377981b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, int 
mode)
return;
 
if (mode != DRM_MODE_DPMS_ON) {
+   unsigned char data = intel_dp->is_mst ?
+   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
+
if (downstream_hpd_needs_d0(intel_dp))
return;
 
-   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
-DP_SET_POWER_D3);
+   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
 
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

On Wed, 2018-04-04 at 22:35 +0300, Ville Syrjälä wrote:
> On Wed, Apr 04, 2018 at 03:00:12PM -0400, Lyude Paul wrote:
> > On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > > > While enabling/disabling DPMS before link training with MST hubs
> > > > > > is
> > > > > > perfectly valid; unfortunately disabling DPMS results in some
> > > > > > devices
> > > > > > disabling their AUX CH block as well. For SST this isn't as much
> > > > > > of a
> > > > > > problem, but for MST we need to be able to continue handling aux
> > > > > > transactions even when none of the sinks are turned on since it's
> > > > > > possible for us to have a single atomic commit which results in
> > > > > > disabling each downstream sink, followed by subsequently re-
> > > > > > enabling
> > > > > > each sink.
> > > > > > 
> > > > > > If we don't do this, we'll end up stalling any pending ESI
> > > > > > interrupts
> > > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during
> > > > > > this
> > > > > > timespan makes it so that link fallback retraining for MST (which
> > > > > > I
> > > > > > will
> > > > > > be submitting to the ML shortly) fails due to the channel EQ
> > > > > > failure
> > > > > > interrupts potentially getting dropped. Additionally, when
> > > > > > performing
> > > > > > a
> > > > > > modeset that brings the hub status's link status from bad -> good
> > > > > > having
> > > > > > ESIs disabled for that long causes us to miss the hub's response
> > > > > > to us
> > > > > > trying to start link training as well.
> > > > > > 
> > > > > > Since any sink with MST is going to support DisplayPort 1.2
> > > > > > anyway,
> > > > > > save
> > > > > > us the hassle of trying to wait until the sink comes back up and
> > > > > > just
> > > > > > never shut the aux block down.
> > > > > > 
> > > > > > Changes since v2:
> > > > > >  - Fix patch name, no functional changes
> > > > > > 
> > > > > > Signed-off-by: Lyude Paul 
> > > > > > Cc: Laura Abbott 
> > > > > > Cc: Dhinakaran Pandiyan 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to
> > > > > > enable
> > > > > > MST
> > > > > > hub.")
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 62f82c4298ac..0479c377981b 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > > > *intel_dp,
> > > > > > int mode)
> > > > > > return;
> > > > > >  
> > > > > > if (mode != DRM_MODE_DPMS_ON) {
> > > > > > +   unsigned char data = intel_dp->is_mst ?
> > > > > > +   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > > > 
> > > > > This smells like a workaround for an actual bug somewhere. Why
> > > > > exactly
> > > > > is the slower wakeup or the AUX block a problem for MST but not for
> > > > > SST
> > > > > when the link training is exactly the same for SST and MST?
> > > > 
> > > > I actually thought about this but I still think this is the
> > > > appropriate
> > > > fix.
> > > > So; the real reason for the wakeup not being a problem with SST is
> > > > that
> > > > for
> > > > DPMS on with SST, we actually do a wait to make sure that the hub is
> > > > ready
> > > > before continuing. And yes: I'm fairly sure SST does actually have
> > > > around
> > > > the
> > > > same wakeup time that MST does, but with the wait we do it doesn't
> > > > reallhy
> > > > make a difference. With MST, we could do this but there's a few
> > > > reasons I
> > > > don't think we should:
> > > >  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub
> > > > that
> > > > has
> > > >MST is going to be guaranteed to have this.
> > > >  * Turning off the aux block means that there's a high chance we're
> > > > going
> > > > to
> > > >miss ESIs from sinks
> > > 
> > > And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> > > away if we don't read them within some really short time?
> > 
> > Oh-additionally I did forget to mention that i have actually witnessed the
> > channel eq failures in the ESI getting dropped without this patch.
> 
> Not sure what that means. I don't think there is any sideband messaging
> involved in link training so not sure what is dropped in this case. The
> link status/etc. are just polled directly by the upstream device.
no, no nononono 

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Hans de Goede]

Hi,

On 04-04-18 17:50, Ville Syrjälä wrote:

On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:

Hi,

On 30-03-18 15:25, Hans de Goede wrote:

Hi,

On 30-03-18 14:44, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:37:40)

Hi,

On 30-03-18 14:30, Chris Wilson wrote:

Quoting Hans de Goede (2018-03-30 13:27:15)

Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.

Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."

Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing.

This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.

The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.

This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).


We've been told by the HW guys not to use the first page. (That's my
understanding from every time this gets questioned.)


Yet the GOP is happily using the first page. I think we may need to make
a difference here between the GPU not using the first page and the
display engine/pipeline not using the first page. Note that my patch
only influences the inheriting of the initial framebuffer as allocated
by the GOP. It does not influence any other allocations from the
reserved range, those will still all avoid the first page.

Without this patch fastboot / flickerfree support is essentially broken
on any gen8+ hardware given that one of the goals of atomic is to be
able to do flickerfree transitions I think that this warrants a closer
look then just simply saying never use the first page.


The concern is what else (i.e. nothing that we allocated ourselves) that
may be in the first page...


Given that the GOP has put its framebuffer there at least at boot there
is nothing there, otherwise it would show up on the display.

We have a whole bunch of code to inherit the BIOS fb in intel_display.c
and AFAIK that code is there because this inheriting the BIOS fb is
deemed an important feature. So I'm not happy at all with the handwavy
best to not touch it answer I'm getting to this patch.

Unless there are some clear answer from the hardware folks which specifically
say we cannot put a framebuffer there (and then why is the GOP doing it?)
then I believe that the best way forward here is to get various people to
test with this patch and the best way to do that is probably to put it
in next. Note I deliberately did not add a Cc stable.


To elaborate on this, the excluding of the first 4k of the stolen memory
region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
which in turn causes intel_find_initial_plane_obj() to call
intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
completely turns off the display which leads to a very ugly flickering
of the display at boot (as well as replacing the vendor logo with a
black screen).

I think we can all agree that this behavior is undesirable and even a
regression in behavior caused by the fix to exclude the first 4k.

Chris, if my patch is not an acceptable way to fix this, then how do you
suggest that we fix this?

Digging a bit deeper I found this:

https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol16-workarounds.pdf

Which says:

"WaSkipStolenMemoryFirstPage:

WA to skip the first page of stolen
memory due to sporadic HW write on *CS Idle"

And also about FBC:

"First line of FBC getting corrupted when FBC
compressed frame buffer offset is programmed to
zero. Command streamers are doing flush writes to
base of stolen.
WA: New restriction to program FBC compressed
frame buffer offset to at least 4KB."

So using the first 4kB for the *framebuffer* as done by the GOP will
not cause any major problems (freezes, hangs, etc.), and commit
d43537610470 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") was correct in 

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

On Wed, 2018-04-04 at 22:31 +0300, Ville Syrjälä wrote:
> On Wed, Apr 04, 2018 at 02:59:09PM -0400, Lyude Paul wrote:
> > On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > > > While enabling/disabling DPMS before link training with MST hubs
> > > > > > is
> > > > > > perfectly valid; unfortunately disabling DPMS results in some
> > > > > > devices
> > > > > > disabling their AUX CH block as well. For SST this isn't as much
> > > > > > of a
> > > > > > problem, but for MST we need to be able to continue handling aux
> > > > > > transactions even when none of the sinks are turned on since it's
> > > > > > possible for us to have a single atomic commit which results in
> > > > > > disabling each downstream sink, followed by subsequently re-
> > > > > > enabling
> > > > > > each sink.
> > > > > > 
> > > > > > If we don't do this, we'll end up stalling any pending ESI
> > > > > > interrupts
> > > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during
> > > > > > this
> > > > > > timespan makes it so that link fallback retraining for MST (which
> > > > > > I
> > > > > > will
> > > > > > be submitting to the ML shortly) fails due to the channel EQ
> > > > > > failure
> > > > > > interrupts potentially getting dropped. Additionally, when
> > > > > > performing
> > > > > > a
> > > > > > modeset that brings the hub status's link status from bad -> good
> > > > > > having
> > > > > > ESIs disabled for that long causes us to miss the hub's response
> > > > > > to us
> > > > > > trying to start link training as well.
> > > > > > 
> > > > > > Since any sink with MST is going to support DisplayPort 1.2
> > > > > > anyway,
> > > > > > save
> > > > > > us the hassle of trying to wait until the sink comes back up and
> > > > > > just
> > > > > > never shut the aux block down.
> > > > > > 
> > > > > > Changes since v2:
> > > > > >  - Fix patch name, no functional changes
> > > > > > 
> > > > > > Signed-off-by: Lyude Paul 
> > > > > > Cc: Laura Abbott 
> > > > > > Cc: Dhinakaran Pandiyan 
> > > > > > Cc: Ville Syrjälä 
> > > > > > Cc: sta...@vger.kernel.org
> > > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to
> > > > > > enable
> > > > > > MST
> > > > > > hub.")
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 62f82c4298ac..0479c377981b 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > > > *intel_dp,
> > > > > > int mode)
> > > > > > return;
> > > > > >  
> > > > > > if (mode != DRM_MODE_DPMS_ON) {
> > > > > > +   unsigned char data = intel_dp->is_mst ?
> > > > > > +   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > > > 
> > > > > This smells like a workaround for an actual bug somewhere. Why
> > > > > exactly
> > > > > is the slower wakeup or the AUX block a problem for MST but not for
> > > > > SST
> > > > > when the link training is exactly the same for SST and MST?
> > > > 
> > > > I actually thought about this but I still think this is the
> > > > appropriate
> > > > fix.
> > > > So; the real reason for the wakeup not being a problem with SST is
> > > > that
> > > > for
> > > > DPMS on with SST, we actually do a wait to make sure that the hub is
> > > > ready
> > > > before continuing. And yes: I'm fairly sure SST does actually have
> > > > around
> > > > the
> > > > same wakeup time that MST does, but with the wait we do it doesn't
> > > > reallhy
> > > > make a difference. With MST, we could do this but there's a few
> > > > reasons I
> > > > don't think we should:
> > > >  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub
> > > > that
> > > > has
> > > >MST is going to be guaranteed to have this.
> > > >  * Turning off the aux block means that there's a high chance we're
> > > > going
> > > > to
> > > >miss ESIs from sinks
> > > 
> > > And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> > > away if we don't read them within some really short time?
> > 
> > That's my hypothesis at least. I'm betting that on the fact that when I
> > was
> > implementing MST retraining before we put the intel_dp_check_mst_status()
> > (or
> > whatever it's called) into the dig workqueue, getting the sink to go down
> > and
> > come back up was a lot more unreliable whenever I introduced anything that
> > would block the esi handler for longer then a 

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Ville Syrjälä]

On Wed, Apr 04, 2018 at 03:00:12PM -0400, Lyude Paul wrote:
> On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > > While enabling/disabling DPMS before link training with MST hubs is
> > > > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > > > problem, but for MST we need to be able to continue handling aux
> > > > > transactions even when none of the sinks are turned on since it's
> > > > > possible for us to have a single atomic commit which results in
> > > > > disabling each downstream sink, followed by subsequently re-enabling
> > > > > each sink.
> > > > > 
> > > > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > > > timespan makes it so that link fallback retraining for MST (which I
> > > > > will
> > > > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > > > interrupts potentially getting dropped. Additionally, when performing
> > > > > a
> > > > > modeset that brings the hub status's link status from bad -> good
> > > > > having
> > > > > ESIs disabled for that long causes us to miss the hub's response to us
> > > > > trying to start link training as well.
> > > > > 
> > > > > Since any sink with MST is going to support DisplayPort 1.2 anyway,
> > > > > save
> > > > > us the hassle of trying to wait until the sink comes back up and just
> > > > > never shut the aux block down.
> > > > > 
> > > > > Changes since v2:
> > > > >  - Fix patch name, no functional changes
> > > > > 
> > > > > Signed-off-by: Lyude Paul 
> > > > > Cc: Laura Abbott 
> > > > > Cc: Dhinakaran Pandiyan 
> > > > > Cc: Ville Syrjälä 
> > > > > Cc: sta...@vger.kernel.org
> > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable
> > > > > MST
> > > > > hub.")
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 62f82c4298ac..0479c377981b 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > > *intel_dp,
> > > > > int mode)
> > > > >   return;
> > > > >  
> > > > >   if (mode != DRM_MODE_DPMS_ON) {
> > > > > + unsigned char data = intel_dp->is_mst ?
> > > > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > > 
> > > > This smells like a workaround for an actual bug somewhere. Why exactly
> > > > is the slower wakeup or the AUX block a problem for MST but not for SST
> > > > when the link training is exactly the same for SST and MST?
> > > 
> > > I actually thought about this but I still think this is the appropriate
> > > fix.
> > > So; the real reason for the wakeup not being a problem with SST is that
> > > for
> > > DPMS on with SST, we actually do a wait to make sure that the hub is ready
> > > before continuing. And yes: I'm fairly sure SST does actually have around
> > > the
> > > same wakeup time that MST does, but with the wait we do it doesn't reallhy
> > > make a difference. With MST, we could do this but there's a few reasons I
> > > don't think we should:
> > >  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that
> > > has
> > >MST is going to be guaranteed to have this.
> > >  * Turning off the aux block means that there's a high chance we're going
> > > to
> > >miss ESIs from sinks
> > 
> > And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> > away if we don't read them within some really short time?
> Oh-additionally I did forget to mention that i have actually witnessed the
> channel eq failures in the ESI getting dropped without this patch.

Not sure what that means. I don't think there is any sideband messaging
involved in link training so not sure what is dropped in this case. The
link status/etc. are just polled directly by the upstream device.

> Meaning if
> we miss them, there's a chance the hub may just not choose to send them again
> for whatever reason.
> > 
> > >  * It's faster to keep the aux block on anyway
> > > 
> > > 
> > > > 
> > > > > +
> > > > >   if (downstream_hpd_needs_d0(intel_dp))
> > > > >   return;
> > > > >  
> > > > > - ret = drm_dp_dpcd_writeb(_dp->aux,
> > > > > DP_SET_POWER,
> > > > > -  DP_SET_POWER_D3);
> > > > > + 

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Ville Syrjälä]

On Wed, Apr 04, 2018 at 02:59:09PM -0400, Lyude Paul wrote:
> On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> > On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > > While enabling/disabling DPMS before link training with MST hubs is
> > > > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > > > problem, but for MST we need to be able to continue handling aux
> > > > > transactions even when none of the sinks are turned on since it's
> > > > > possible for us to have a single atomic commit which results in
> > > > > disabling each downstream sink, followed by subsequently re-enabling
> > > > > each sink.
> > > > > 
> > > > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > > > timespan makes it so that link fallback retraining for MST (which I
> > > > > will
> > > > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > > > interrupts potentially getting dropped. Additionally, when performing
> > > > > a
> > > > > modeset that brings the hub status's link status from bad -> good
> > > > > having
> > > > > ESIs disabled for that long causes us to miss the hub's response to us
> > > > > trying to start link training as well.
> > > > > 
> > > > > Since any sink with MST is going to support DisplayPort 1.2 anyway,
> > > > > save
> > > > > us the hassle of trying to wait until the sink comes back up and just
> > > > > never shut the aux block down.
> > > > > 
> > > > > Changes since v2:
> > > > >  - Fix patch name, no functional changes
> > > > > 
> > > > > Signed-off-by: Lyude Paul 
> > > > > Cc: Laura Abbott 
> > > > > Cc: Dhinakaran Pandiyan 
> > > > > Cc: Ville Syrjälä 
> > > > > Cc: sta...@vger.kernel.org
> > > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable
> > > > > MST
> > > > > hub.")
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 62f82c4298ac..0479c377981b 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > > *intel_dp,
> > > > > int mode)
> > > > >   return;
> > > > >  
> > > > >   if (mode != DRM_MODE_DPMS_ON) {
> > > > > + unsigned char data = intel_dp->is_mst ?
> > > > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > > 
> > > > This smells like a workaround for an actual bug somewhere. Why exactly
> > > > is the slower wakeup or the AUX block a problem for MST but not for SST
> > > > when the link training is exactly the same for SST and MST?
> > > 
> > > I actually thought about this but I still think this is the appropriate
> > > fix.
> > > So; the real reason for the wakeup not being a problem with SST is that
> > > for
> > > DPMS on with SST, we actually do a wait to make sure that the hub is ready
> > > before continuing. And yes: I'm fairly sure SST does actually have around
> > > the
> > > same wakeup time that MST does, but with the wait we do it doesn't reallhy
> > > make a difference. With MST, we could do this but there's a few reasons I
> > > don't think we should:
> > >  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that
> > > has
> > >MST is going to be guaranteed to have this.
> > >  * Turning off the aux block means that there's a high chance we're going
> > > to
> > >miss ESIs from sinks
> > 
> > And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> > away if we don't read them within some really short time?
> That's my hypothesis at least. I'm betting that on the fact that when I was
> implementing MST retraining before we put the intel_dp_check_mst_status() (or
> whatever it's called) into the dig workqueue, getting the sink to go down and
> come back up was a lot more unreliable whenever I introduced anything that
> would block the esi handler for longer then a very brief period of time (say,
> 50-100ms?). I've seen some notes elsewhere too that seemed to imply for SST,
> things were pretty sensitive to irq latency (line 1050, intel_dp.c) so it
> wouldn't be terribly surprising if it's the same for MST. At the very least,
> now that we've got the ESI handler running in the dig worker things seem to
> have gotten a /lot/ more reliable now that we can basically go the whole
> modeset without blocking the ESI handler for very long.

Hmm. 

Re: [Intel-gfx] [PATCH v4] drm: Fix downstream dev count read

[Sean Paul]

On Wed, Apr 04, 2018 at 12:07:41PM -0700, Rodrigo Vivi wrote:
> On Wed, Apr 04, 2018 at 11:57:42PM +0530, Ramalingam C wrote:
> > In both HDMI and DP, device count is represented by 6:0 bits of a
> > register(BInfo/Bstatus)
> > 
> > So macro for bitmasking the device_count is fixed(0x3F->0x7F).
> > 
> > v3:
> >   Retained the Rb-ed.
> > v4:
> >   %s/drm\/i915/drm [rodrigo]
> > 
> 
> Shouldn't this patch have a "Fixes:" ?

Yes, I think that'd be good.

> cc: stable?

It couldn't hurt.

> 
> I pushed first 3 patches on the series to dinq.
> I believe this one here could be there with Dave's ack or
> maybe on drm-misc-fixes?

Meh. The severity of this isn't too big, given that I doubt people care _too_
much about plugging in more than 64 HDCP-enabled devices. If you want to drop it
in -misc-next-fixes, I can send it out next week.

While we're asking for a respin, could we add HDCP somewhere in the subject?

Sean

> 
> > Signed-off-by: Ramalingam C 
> > cc: Sean Paul 
> > Reviewed-by: Sean Paul 
> > ---
> >  include/drm/drm_hdcp.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> > index 562fa7df2637..98e63d870139 100644
> > --- a/include/drm/drm_hdcp.h
> > +++ b/include/drm/drm_hdcp.h
> > @@ -19,7 +19,7 @@
> >  #define DRM_HDCP_RI_LEN2
> >  #define DRM_HDCP_V_PRIME_PART_LEN  4
> >  #define DRM_HDCP_V_PRIME_NUM_PARTS 5
> > -#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
> > +#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
> >  #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)   (x & BIT(3))
> >  #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)(x & BIT(7))
> >  
> > -- 
> > 2.7.4
> > 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Sean Paul]

Hi Dave,
After fixing the dim bug, I have a sane pull request for you this week :). Just
one patch again, this time fixing a build warning in hda_intel. Takashi
requested this go through drm-misc as the original switcheroo came through here
too.


drm-misc-next-fixes-2018-04-04:
hda_intel: Don't declare azx PM ops if VGA_SWITCHEROO configured (Lukas)

Cc: Lukas Wunner 
Cc: Takashi Iwai 

Cheers, Sean


The following changes since commit a01c47737a9ca118ab75c6fd6e75739b824de830:

  drm: Fix uabi regression by allowing garbage mode->type from userspace 
(2018-03-23 13:51:12 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-04-04

for you to fetch changes up to 8cd1b5bd70cccda6854088825e725a513ec919c6:

  ALSA: hda - Silence PM ops build warning (2018-03-29 21:47:53 +0200)


hda_intel: Don't declare azx PM ops if VGA_SWITCHEROO configured (Lukas)

Cc: Lukas Wunner 
Cc: Takashi Iwai 


Lukas Wunner (1):
  ALSA: hda - Silence PM ops build warning

 sound/pci/hda/hda_intel.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm: Fix downstream dev count read

[Rodrigo Vivi]

On Wed, Apr 04, 2018 at 11:57:42PM +0530, Ramalingam C wrote:
> In both HDMI and DP, device count is represented by 6:0 bits of a
> register(BInfo/Bstatus)
> 
> So macro for bitmasking the device_count is fixed(0x3F->0x7F).
> 
> v3:
>   Retained the Rb-ed.
> v4:
>   %s/drm\/i915/drm [rodrigo]
> 

Shouldn't this patch have a "Fixes:" ?
cc: stable?

I pushed first 3 patches on the series to dinq.
I believe this one here could be there with Dave's ack or
maybe on drm-misc-fixes?

> Signed-off-by: Ramalingam C 
> cc: Sean Paul 
> Reviewed-by: Sean Paul 
> ---
>  include/drm/drm_hdcp.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index 562fa7df2637..98e63d870139 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -19,7 +19,7 @@
>  #define DRM_HDCP_RI_LEN  2
>  #define DRM_HDCP_V_PRIME_PART_LEN4
>  #define DRM_HDCP_V_PRIME_NUM_PARTS   5
> -#define DRM_HDCP_NUM_DOWNSTREAM(x)   (x & 0x3f)
> +#define DRM_HDCP_NUM_DOWNSTREAM(x)   (x & 0x7f)
>  #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x) (x & BIT(3))
>  #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)  (x & BIT(7))
>  
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP1.4 fixes (rev6)

[Patchwork]

== Series Details ==

Series: HDCP1.4 fixes (rev6)
URL   : https://patchwork.freedesktop.org/series/38978/
State : success

== Summary ==

Series 38978v6 HDCP1.4 fixes
https://patchwork.freedesktop.org/api/1.0/series/38978/revisions/6/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:430s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:536s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:298s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:517s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:520s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:507s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:508s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:594s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:424s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:319s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:421s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:469s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:466s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:527s

8a51883453a91beb0492790d03cd2183eb923c38 drm-tip: 2018y-04m-04d-14h-43m-05s UTC 
integration manifest
be7559a88022 drm: Fix downstream dev count read
8fbba7c290e6 drm/i915: Check hdcp key loadability
cd233eb847df drm/i915: Read Vprime thrice incase of mismatch
34226dc9ea0d drm/i915: Read HDCP R0 thrice in case of mismatch

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > While enabling/disabling DPMS before link training with MST hubs is
> > > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > > problem, but for MST we need to be able to continue handling aux
> > > > transactions even when none of the sinks are turned on since it's
> > > > possible for us to have a single atomic commit which results in
> > > > disabling each downstream sink, followed by subsequently re-enabling
> > > > each sink.
> > > > 
> > > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > > timespan makes it so that link fallback retraining for MST (which I
> > > > will
> > > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > > interrupts potentially getting dropped. Additionally, when performing
> > > > a
> > > > modeset that brings the hub status's link status from bad -> good
> > > > having
> > > > ESIs disabled for that long causes us to miss the hub's response to us
> > > > trying to start link training as well.
> > > > 
> > > > Since any sink with MST is going to support DisplayPort 1.2 anyway,
> > > > save
> > > > us the hassle of trying to wait until the sink comes back up and just
> > > > never shut the aux block down.
> > > > 
> > > > Changes since v2:
> > > >  - Fix patch name, no functional changes
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Cc: Laura Abbott 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Ville Syrjälä 
> > > > Cc: sta...@vger.kernel.org
> > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable
> > > > MST
> > > > hub.")
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 62f82c4298ac..0479c377981b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > *intel_dp,
> > > > int mode)
> > > > return;
> > > >  
> > > > if (mode != DRM_MODE_DPMS_ON) {
> > > > +   unsigned char data = intel_dp->is_mst ?
> > > > +   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > 
> > > This smells like a workaround for an actual bug somewhere. Why exactly
> > > is the slower wakeup or the AUX block a problem for MST but not for SST
> > > when the link training is exactly the same for SST and MST?
> > 
> > I actually thought about this but I still think this is the appropriate
> > fix.
> > So; the real reason for the wakeup not being a problem with SST is that
> > for
> > DPMS on with SST, we actually do a wait to make sure that the hub is ready
> > before continuing. And yes: I'm fairly sure SST does actually have around
> > the
> > same wakeup time that MST does, but with the wait we do it doesn't reallhy
> > make a difference. With MST, we could do this but there's a few reasons I
> > don't think we should:
> >  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that
> > has
> >MST is going to be guaranteed to have this.
> >  * Turning off the aux block means that there's a high chance we're going
> > to
> >miss ESIs from sinks
> 
> And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> away if we don't read them within some really short time?
Oh-additionally I did forget to mention that i have actually witnessed the
channel eq failures in the ESI getting dropped without this patch. Meaning if
we miss them, there's a chance the hub may just not choose to send them again
for whatever reason.
> 
> >  * It's faster to keep the aux block on anyway
> > 
> > 
> > > 
> > > > +
> > > > if (downstream_hpd_needs_d0(intel_dp))
> > > > return;
> > > >  
> > > > -   ret = drm_dp_dpcd_writeb(_dp->aux,
> > > > DP_SET_POWER,
> > > > -DP_SET_POWER_D3);
> > > > +   ret = drm_dp_dpcd_writeb(_dp->aux,
> > > > DP_SET_POWER,
> > > > data);
> > > > } else {
> > > > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > > >  
> > > > -- 
> > > > 2.14.3
> > > 
> > > 
> > 
> > -- 
> > Cheers,
> > Lyude Paul
> 
> 
-- 
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

On Wed, 2018-04-04 at 21:53 +0300, Ville Syrjälä wrote:
> On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> > On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > > While enabling/disabling DPMS before link training with MST hubs is
> > > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > > problem, but for MST we need to be able to continue handling aux
> > > > transactions even when none of the sinks are turned on since it's
> > > > possible for us to have a single atomic commit which results in
> > > > disabling each downstream sink, followed by subsequently re-enabling
> > > > each sink.
> > > > 
> > > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > > timespan makes it so that link fallback retraining for MST (which I
> > > > will
> > > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > > interrupts potentially getting dropped. Additionally, when performing
> > > > a
> > > > modeset that brings the hub status's link status from bad -> good
> > > > having
> > > > ESIs disabled for that long causes us to miss the hub's response to us
> > > > trying to start link training as well.
> > > > 
> > > > Since any sink with MST is going to support DisplayPort 1.2 anyway,
> > > > save
> > > > us the hassle of trying to wait until the sink comes back up and just
> > > > never shut the aux block down.
> > > > 
> > > > Changes since v2:
> > > >  - Fix patch name, no functional changes
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Cc: Laura Abbott 
> > > > Cc: Dhinakaran Pandiyan 
> > > > Cc: Ville Syrjälä 
> > > > Cc: sta...@vger.kernel.org
> > > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable
> > > > MST
> > > > hub.")
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 62f82c4298ac..0479c377981b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > > *intel_dp,
> > > > int mode)
> > > > return;
> > > >  
> > > > if (mode != DRM_MODE_DPMS_ON) {
> > > > +   unsigned char data = intel_dp->is_mst ?
> > > > +   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > > 
> > > This smells like a workaround for an actual bug somewhere. Why exactly
> > > is the slower wakeup or the AUX block a problem for MST but not for SST
> > > when the link training is exactly the same for SST and MST?
> > 
> > I actually thought about this but I still think this is the appropriate
> > fix.
> > So; the real reason for the wakeup not being a problem with SST is that
> > for
> > DPMS on with SST, we actually do a wait to make sure that the hub is ready
> > before continuing. And yes: I'm fairly sure SST does actually have around
> > the
> > same wakeup time that MST does, but with the wait we do it doesn't reallhy
> > make a difference. With MST, we could do this but there's a few reasons I
> > don't think we should:
> >  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that
> > has
> >MST is going to be guaranteed to have this.
> >  * Turning off the aux block means that there's a high chance we're going
> > to
> >miss ESIs from sinks
> 
> And how exactly do we lose irqs? The hub/whatever throws the up req msgs
> away if we don't read them within some really short time?
That's my hypothesis at least. I'm betting that on the fact that when I was
implementing MST retraining before we put the intel_dp_check_mst_status() (or
whatever it's called) into the dig workqueue, getting the sink to go down and
come back up was a lot more unreliable whenever I introduced anything that
would block the esi handler for longer then a very brief period of time (say,
50-100ms?). I've seen some notes elsewhere too that seemed to imply for SST,
things were pretty sensitive to irq latency (line 1050, intel_dp.c) so it
wouldn't be terribly surprising if it's the same for MST. At the very least,
now that we've got the ESI handler running in the dig worker things seem to
have gotten a /lot/ more reliable now that we can basically go the whole
modeset without blocking the ESI handler for very long.
> 
> >  * It's faster to keep the aux block on anyway
> > 
> > 
> > > 
> > > > +
> > > > if (downstream_hpd_needs_d0(intel_dp))
> > > > return;
> > > >  
> > > > -   ret = 

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Ville Syrjälä]

On Wed, Apr 04, 2018 at 02:37:41PM -0400, Lyude Paul wrote:
> On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > While enabling/disabling DPMS before link training with MST hubs is
> > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > problem, but for MST we need to be able to continue handling aux
> > > transactions even when none of the sinks are turned on since it's
> > > possible for us to have a single atomic commit which results in
> > > disabling each downstream sink, followed by subsequently re-enabling
> > > each sink.
> > > 
> > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > timespan makes it so that link fallback retraining for MST (which I will
> > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > interrupts potentially getting dropped. Additionally, when performing a
> > > modeset that brings the hub status's link status from bad -> good having
> > > ESIs disabled for that long causes us to miss the hub's response to us
> > > trying to start link training as well.
> > > 
> > > Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> > > us the hassle of trying to wait until the sink comes back up and just
> > > never shut the aux block down.
> > > 
> > > Changes since v2:
> > >  - Fix patch name, no functional changes
> > > 
> > > Signed-off-by: Lyude Paul 
> > > Cc: Laura Abbott 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Ville Syrjälä 
> > > Cc: sta...@vger.kernel.org
> > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST
> > > hub.")
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 62f82c4298ac..0479c377981b 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > > int mode)
> > >   return;
> > >  
> > >   if (mode != DRM_MODE_DPMS_ON) {
> > > + unsigned char data = intel_dp->is_mst ?
> > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > 
> > This smells like a workaround for an actual bug somewhere. Why exactly
> > is the slower wakeup or the AUX block a problem for MST but not for SST
> > when the link training is exactly the same for SST and MST?
> I actually thought about this but I still think this is the appropriate fix.
> So; the real reason for the wakeup not being a problem with SST is that for
> DPMS on with SST, we actually do a wait to make sure that the hub is ready
> before continuing. And yes: I'm fairly sure SST does actually have around the
> same wakeup time that MST does, but with the wait we do it doesn't reallhy
> make a difference. With MST, we could do this but there's a few reasons I
> don't think we should:
>  * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that has
>MST is going to be guaranteed to have this.
>  * Turning off the aux block means that there's a high chance we're going to
>miss ESIs from sinks

And how exactly do we lose irqs? The hub/whatever throws the up req msgs
away if we don't read them within some really short time?

>  * It's faster to keep the aux block on anyway
> 
> 
> > 
> > > +
> > >   if (downstream_hpd_needs_d0(intel_dp))
> > >   return;
> > >  
> > > - ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > > -  DP_SET_POWER_D3);
> > > + ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > > data);
> > >   } else {
> > >   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > >  
> > > -- 
> > > 2.14.3
> > 
> > 
> -- 
> Cheers,
>   Lyude Paul

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

On Wed, 2018-04-04 at 11:44 -0700, Manasi Navare wrote:
> On Wed, Apr 04, 2018 at 06:34:29PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > > While enabling/disabling DPMS before link training with MST hubs is
> > > perfectly valid; unfortunately disabling DPMS results in some devices
> > > disabling their AUX CH block as well. For SST this isn't as much of a
> > > problem, but for MST we need to be able to continue handling aux
> > > transactions even when none of the sinks are turned on since it's
> > > possible for us to have a single atomic commit which results in
> > > disabling each downstream sink, followed by subsequently re-enabling
> > > each sink.
> > > 
> > > If we don't do this, we'll end up stalling any pending ESI interrupts
> > > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > > timespan makes it so that link fallback retraining for MST (which I will
> > > be submitting to the ML shortly) fails due to the channel EQ failure
> > > interrupts potentially getting dropped. Additionally, when performing a
> > > modeset that brings the hub status's link status from bad -> good having
> > > ESIs disabled for that long causes us to miss the hub's response to us
> > > trying to start link training as well.
> > > 
> > > Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> > > us the hassle of trying to wait until the sink comes back up and just
> > > never shut the aux block down.
> > > 
> > > Changes since v2:
> > >  - Fix patch name, no functional changes
> > > 
> > > Signed-off-by: Lyude Paul 
> > > Cc: Laura Abbott 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: Ville Syrjälä 
> > > Cc: sta...@vger.kernel.org
> > > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable
> > > MST hub.")
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 62f82c4298ac..0479c377981b 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp
> > > *intel_dp, int mode)
> > >   return;
> > >  
> > >   if (mode != DRM_MODE_DPMS_ON) {
> > > + unsigned char data = intel_dp->is_mst ?
> > > + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> > 
> > This smells like a workaround for an actual bug somewhere. Why exactly
> > is the slower wakeup or the AUX block a problem for MST but not for SST
> > when the link training is exactly the same for SST and MST?
> > 
> 
> The problem occurs only in case of MST because the Channel EQ failure is
> notified
> through ESI sideband AUX messages which potentially  can get dropped because
> of disabling
> DPMS. But in case of SST, we detect the channel EQ failure write during the
> EQ TPS sequence
> which happens on the main link.

mhm- that is the big problem it causes, at least with this patchset. I've been
considering maybe looking into probing downstream sinks with remote dpcd reads
to see their link training status, as I think that might actually be the real
reason for why there's this weird difference between the channel eq status in
the esi and the actual link training status of the hub in the dpcd registers
that are shared with SST. but that's for a later date :)
> 
> Manasi
>  
> > > +
> > >   if (downstream_hpd_needs_d0(intel_dp))
> > >   return;
> > >  
> > > - ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > > -  DP_SET_POWER_D3);
> > > + ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > > data);
> > >   } else {
> > >   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> > >  
> > > -- 
> > > 2.14.3
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Manasi Navare]

On Wed, Apr 04, 2018 at 06:34:29PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > While enabling/disabling DPMS before link training with MST hubs is
> > perfectly valid; unfortunately disabling DPMS results in some devices
> > disabling their AUX CH block as well. For SST this isn't as much of a
> > problem, but for MST we need to be able to continue handling aux
> > transactions even when none of the sinks are turned on since it's
> > possible for us to have a single atomic commit which results in
> > disabling each downstream sink, followed by subsequently re-enabling
> > each sink.
> > 
> > If we don't do this, we'll end up stalling any pending ESI interrupts
> > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > timespan makes it so that link fallback retraining for MST (which I will
> > be submitting to the ML shortly) fails due to the channel EQ failure
> > interrupts potentially getting dropped. Additionally, when performing a
> > modeset that brings the hub status's link status from bad -> good having
> > ESIs disabled for that long causes us to miss the hub's response to us
> > trying to start link training as well.
> > 
> > Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> > us the hassle of trying to wait until the sink comes back up and just
> > never shut the aux block down.
> > 
> > Changes since v2:
> >  - Fix patch name, no functional changes
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Laura Abbott 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjälä 
> > Cc: sta...@vger.kernel.org
> > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> > hub.")
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 62f82c4298ac..0479c377981b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, 
> > int mode)
> > return;
> >  
> > if (mode != DRM_MODE_DPMS_ON) {
> > +   unsigned char data = intel_dp->is_mst ?
> > +   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> 
> This smells like a workaround for an actual bug somewhere. Why exactly
> is the slower wakeup or the AUX block a problem for MST but not for SST
> when the link training is exactly the same for SST and MST?
>

The problem occurs only in case of MST because the Channel EQ failure is 
notified
through ESI sideband AUX messages which potentially  can get dropped because of 
disabling
DPMS. But in case of SST, we detect the channel EQ failure write during the EQ 
TPS sequence
which happens on the main link.

Manasi
 
> > +
> > if (downstream_hpd_needs_d0(intel_dp))
> > return;
> >  
> > -   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > -DP_SET_POWER_D3);
> > +   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
> > } else {
> > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> >  
> > -- 
> > 2.14.3
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Lyude Paul]

On Wed, 2018-04-04 at 18:34 +0300, Ville Syrjälä wrote:
> On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> > While enabling/disabling DPMS before link training with MST hubs is
> > perfectly valid; unfortunately disabling DPMS results in some devices
> > disabling their AUX CH block as well. For SST this isn't as much of a
> > problem, but for MST we need to be able to continue handling aux
> > transactions even when none of the sinks are turned on since it's
> > possible for us to have a single atomic commit which results in
> > disabling each downstream sink, followed by subsequently re-enabling
> > each sink.
> > 
> > If we don't do this, we'll end up stalling any pending ESI interrupts
> > from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> > timespan makes it so that link fallback retraining for MST (which I will
> > be submitting to the ML shortly) fails due to the channel EQ failure
> > interrupts potentially getting dropped. Additionally, when performing a
> > modeset that brings the hub status's link status from bad -> good having
> > ESIs disabled for that long causes us to miss the hub's response to us
> > trying to start link training as well.
> > 
> > Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> > us the hassle of trying to wait until the sink comes back up and just
> > never shut the aux block down.
> > 
> > Changes since v2:
> >  - Fix patch name, no functional changes
> > 
> > Signed-off-by: Lyude Paul 
> > Cc: Laura Abbott 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjälä 
> > Cc: sta...@vger.kernel.org
> > Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST
> > hub.")
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 62f82c4298ac..0479c377981b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp,
> > int mode)
> > return;
> >  
> > if (mode != DRM_MODE_DPMS_ON) {
> > +   unsigned char data = intel_dp->is_mst ?
> > +   DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;
> 
> This smells like a workaround for an actual bug somewhere. Why exactly
> is the slower wakeup or the AUX block a problem for MST but not for SST
> when the link training is exactly the same for SST and MST?
I actually thought about this but I still think this is the appropriate fix.
So; the real reason for the wakeup not being a problem with SST is that for
DPMS on with SST, we actually do a wait to make sure that the hub is ready
before continuing. And yes: I'm fairly sure SST does actually have around the
same wakeup time that MST does, but with the wait we do it doesn't reallhy
make a difference. With MST, we could do this but there's a few reasons I
don't think we should:
 * We don't need to. D3_AUX_ON is a part of the 1.2 spec, so any hub that has
   MST is going to be guaranteed to have this.
 * Turning off the aux block means that there's a high chance we're going to
   miss ESIs from sinks
 * It's faster to keep the aux block on anyway


> 
> > +
> > if (downstream_hpd_needs_d0(intel_dp))
> > return;
> >  
> > -   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > -DP_SET_POWER_D3);
> > +   ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> > data);
> > } else {
> > struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
> >  
> > -- 
> > 2.14.3
> 
> 
-- 
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm: Fix downstream dev count read

[Ramalingam C]

In both HDMI and DP, device count is represented by 6:0 bits of a
register(BInfo/Bstatus)

So macro for bitmasking the device_count is fixed(0x3F->0x7F).

v3:
  Retained the Rb-ed.
v4:
  %s/drm\/i915/drm [rodrigo]

Signed-off-by: Ramalingam C 
cc: Sean Paul 
Reviewed-by: Sean Paul 
---
 include/drm/drm_hdcp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index 562fa7df2637..98e63d870139 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -19,7 +19,7 @@
 #define DRM_HDCP_RI_LEN2
 #define DRM_HDCP_V_PRIME_PART_LEN  4
 #define DRM_HDCP_V_PRIME_NUM_PARTS 5
-#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x7f)
 #define DRM_HDCP_MAX_CASCADE_EXCEEDED(x)   (x & BIT(3))
 #define DRM_HDCP_MAX_DEVICE_EXCEEDED(x)(x & BIT(7))
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Rodrigo Vivi]

On Wed, Apr 04, 2018 at 06:50:16PM +0300, Ville Syrjälä wrote:
> On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:
> > Hi,
> > 
> > On 30-03-18 15:25, Hans de Goede wrote:
> > > Hi,
> > > 
> > > On 30-03-18 14:44, Chris Wilson wrote:
> > >> Quoting Hans de Goede (2018-03-30 13:37:40)
> > >>> Hi,
> > >>>
> > >>> On 30-03-18 14:30, Chris Wilson wrote:
> >  Quoting Hans de Goede (2018-03-30 13:27:15)
> > > Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> > > skipping the first 4k by passing 4096 as start of the address range 
> > > passed
> > > to drm_mm_init(). This means that calling drm_mm_reserve_node() to 
> > > try and
> > > reserve the firmware framebuffer so that we can inherit it would 
> > > always
> > > fail, as the firmware framebuffer starts at address 0.
> > >
> > > Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> > > everything >= gen8") says in its commit message: "This is confirmed 
> > > to fix
> > > Skylake screen flickering issues (probably caused by the fact that we
> > > initialized a ring in the first page of stolen, but I didn't 100% 
> > > confirm
> > > this theory)."
> > >
> > > Which suggests that it is safe to use the first page for a linear
> > > framebuffer as the firmware is doing.
> > >
> > > This commit always passes 0 as start to drm_mm_init() and works around
> > > WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> > > by insuring the start address passed by to 
> > > drm_mm_insert_node_in_range()
> > > is always 4k or more. All entry points to i915_gem_stolen.c go through
> > > i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> > > objects such as ring-buffers will not be allocated in the first 4k.
> > >
> > > The one exception is i915_gem_object_create_stolen_for_preallocated()
> > > which directly calls drm_mm_reserve_node() which now will be able to
> > > use the first 4k.
> > >
> > > This fixes the i915 driver no longer being able to inherit the 
> > > firmware
> > > framebuffer on gen8+, which fixes the video output changing from the
> > > vendor logo to a black screen as soon as the i915 driver is loaded
> > > (on systems without fbcon).
> > 
> >  We've been told by the HW guys not to use the first page. (That's my
> >  understanding from every time this gets questioned.)
> > >>>
> > >>> Yet the GOP is happily using the first page. I think we may need to make
> > >>> a difference here between the GPU not using the first page and the
> > >>> display engine/pipeline not using the first page. Note that my patch
> > >>> only influences the inheriting of the initial framebuffer as allocated
> > >>> by the GOP. It does not influence any other allocations from the
> > >>> reserved range, those will still all avoid the first page.
> > >>>
> > >>> Without this patch fastboot / flickerfree support is essentially broken
> > >>> on any gen8+ hardware given that one of the goals of atomic is to be
> > >>> able to do flickerfree transitions I think that this warrants a closer
> > >>> look then just simply saying never use the first page.
> > >>
> > >> The concern is what else (i.e. nothing that we allocated ourselves) that
> > >> may be in the first page...
> > > 
> > > Given that the GOP has put its framebuffer there at least at boot there
> > > is nothing there, otherwise it would show up on the display.
> > > 
> > > We have a whole bunch of code to inherit the BIOS fb in intel_display.c
> > > and AFAIK that code is there because this inheriting the BIOS fb is
> > > deemed an important feature. So I'm not happy at all with the handwavy
> > > best to not touch it answer I'm getting to this patch.
> > > 
> > > Unless there are some clear answer from the hardware folks which 
> > > specifically
> > > say we cannot put a framebuffer there (and then why is the GOP doing it?)
> > > then I believe that the best way forward here is to get various people to
> > > test with this patch and the best way to do that is probably to put it
> > > in next. Note I deliberately did not add a Cc stable.
> > 
> > To elaborate on this, the excluding of the first 4k of the stolen memory
> > region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
> > which in turn causes intel_find_initial_plane_obj() to call
> > intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
> > completely turns off the display which leads to a very ugly flickering
> > of the display at boot (as well as replacing the vendor logo with a
> > black screen).
> > 
> > I think we can all agree that this behavior is undesirable and even a
> > regression in behavior caused by the fix to exclude the first 4k.
> > 
> > Chris, if my patch is not an acceptable way to fix this, then how do you
> > suggest that we fix this?
> > 
> > Digging a 

Re: [Intel-gfx] Linux 4.16 Kernel Boot Crash

[Jaak Ristioja]

Hello, all!

I experience the same issue with a Lenovo ThinkPad T440p (LENOVO
20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to
bisect v4.15..v4.16 but failed.

Best regards,
J

On 04.04.2018 15:36, Jani Nikula wrote:
> On Tue, 03 Apr 2018, Peter Geis  wrote:
>> Good Evening,
>>
>> I have been trying to use the 4.16 kernel source since 4.16-rc3.
>> Every time it booted it crashed upon loading the video drivers.
>> Now with the 4.16 release, it is still occurring, so I felt it prudent 
>> to notify someone.
>>
>> The machine is a Lenovo Yoga 900 80UE-ISK2.
>> It has a i7-6560u CPU with Intel integrated graphics.
> 
> This doesn't seem to have anything to do with Intel graphics. Based on
> the backtraces, adding linux-media and linux-input mailing lists and
> maintainers.
> 
> BR,
> Jani.
> 
> 
>>
>> I have included the kernel log, what format should I submit the vmcore 
>> dump in?
>>
>> Thanks,
>> Peter Geis
>>
>>
>> ---Begin Log---
>>
>> [   43.177394] WARNING: CPU: 1 PID: 711 at 
>> drivers/media/v4l2-core/v4l2-dev.c:945 
>> __video_register_device+0xc99/0x1090 [videodev]
>> [   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
>> hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d 
>> hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger 
>> industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common 
>> hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops 
>> videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
>> hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 
>> snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp 
>> snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic 
>> snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel 
>> snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep 
>> intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi 
>> snd_seq_midi_event snd_rawmidi crct10dif_pclmul
>> [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 
>> snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd 
>> glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds 
>> serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore 
>> ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad 
>> int3400_thermal acpi_thermal_rel intel_pch_thermal 
>> processor_thermal_device mac_hid int340x_thermal_zone mei_me 
>> intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel 
>> vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd 
>> grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp 
>> hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 
>> vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea 
>> sdhci_pci sysfillrect
>> [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid 
>> video pinctrl_sunrisepoint pinctrl_intel
>> [   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
>> [   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
>> [   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
>> [   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
>> [   43.177484] RAX:  RBX: 0005 RCX: 
>> 
>> [   43.177485] RDX: c0c44cc0 RSI:  RDI: 
>> c0c44cc0
>> [   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
>> 8eda1a51f018
>> [   43.177487] R10: 0600 R11: 03b6 R12: 
>> 
>> [   43.177488] R13: 0005 R14: c0c96900 R15: 
>> 8eda1d6d91c0
>> [   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
>> knlGS:
>> [   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
>> [   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
>> 003606e0
>> [   43.177492] Call Trace:
>> [   43.177498]  ? devres_add+0x5f/0x70
>> [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
>> [   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
>> [   43.177507]  driver_probe_device+0x310/0x480
>> [   43.177509]  __device_attach_driver+0x86/0x100
>> [   43.177511]  ? __driver_attach+0xf0/0xf0
>> [   43.177512]  bus_for_each_drv+0x6b/0xb0
>> [   43.177514]  __device_attach+0xdd/0x160
>> [   43.177516]  device_initial_probe+0x13/0x20
>> [   43.177518]  bus_probe_device+0x95/0xa0
>> [   43.177519]  device_add+0x44b/0x680
>> [   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
>> [   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
>> [   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
>> [   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
>> [   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
>> [   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
>> [   43.177547]  ? sysfs_create_link+0x25/0x40
>> [   43.177549]  

Re: [Intel-gfx] Linux 4.16 Kernel Boot Crash

[Peter Geis]

Good Afternoon,

I have been digging into this issue further, and the problem is 
definitely with the media driver.
Rebuilt the kernel with media drivers compiled in vice modular and the 
kernel boots without issue.


The core dump states the crash occurred at 
drivers/media/v4l2-core/v4l2-dev.c, line 945.

This line is checking if the vdev minor is actually free.
There were some significant changes to v4l in 4.16 from 4.15.

Considering the following behavior:
A. It panics if it boots immediately.
B. If booted to recovery for a period of time (~5 mins) then resumed 
booting it boots without issue.
I believe that the module is being loaded before something it is 
dependent on has initialized, causing this issue.


Thank you Jani for pointing out my error, I shouldn't debug at night.

Very Repspectfully,
Peter Geis

On 04/04/2018 09:26 AM, Jaak Ristioja wrote:

Hello, all!

I experience the same issue with a Lenovo ThinkPad T440p (LENOVO
20AN006VMS/20AN006VMS, BIOS GLET90WW (2.44 ) 09/13/2017). I tried to
bisect v4.15..v4.16 but failed.

Best regards,
J

On 04.04.2018 15:36, Jani Nikula wrote:

On Tue, 03 Apr 2018, Peter Geis  wrote:

Good Evening,

I have been trying to use the 4.16 kernel source since 4.16-rc3.
Every time it booted it crashed upon loading the video drivers.
Now with the 4.16 release, it is still occurring, so I felt it prudent
to notify someone.

The machine is a Lenovo Yoga 900 80UE-ISK2.
It has a i7-6560u CPU with Intel integrated graphics.


This doesn't seem to have anything to do with Intel graphics. Based on
the backtraces, adding linux-media and linux-input mailing lists and
maintainers.

BR,
Jani.




I have included the kernel log, what format should I submit the vmcore
dump in?

Thanks,
Peter Geis


---Begin Log---

[   43.177394] WARNING: CPU: 1 PID: 711 at
drivers/media/v4l2-core/v4l2-dev.c:945
__video_register_device+0xc99/0x1090 [videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d
hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger
industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common
hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops
videobuf2_v4l2 videobuf2_common videodev hid_multitouch media
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4
snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp
snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic
snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel
snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep
intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi
snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211
snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd
glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds
serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore
ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad
int3400_thermal acpi_thermal_rel intel_pch_thermal
processor_thermal_device mac_hid int340x_thermal_zone mei_me
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel
vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd
grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp
hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1
vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea
sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid
video pinctrl_sunrisepoint pinctrl_intel
[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX:

[   43.177485] RDX: c0c44cc0 RSI:  RDI:
c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09:
8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12:

[   43.177488] R13: 0005 R14: c0c96900 R15:
8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348()
knlGS:
[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4:
003606e0
[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_eio: Add reset and unwedge stress testing

[Antonio Argenziano]

On 04/04/18 02:58, Tvrtko Ursulin wrote:


On 03/04/2018 19:34, Antonio Argenziano wrote:



On 03/04/18 11:24, Antonio Argenziano wrote:



On 03/04/18 04:36, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Reset and unwedge stress testing is supposed to trigger wedging or 
resets
at incovenient times and then re-use the context so either the 
context or

driver tracking might get confused and break.

v2:
  * Renamed for more sensible naming.
  * Added some comments to explain what the test is doing. (Chris 
Wilson)


Signed-off-by: Tvrtko Ursulin 
---
  tests/gem_eio.c | 74 
+

  1 file changed, 74 insertions(+)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index b7c5047f0816..9599e73db736 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -591,6 +591,74 @@ static void test_inflight_internal(int fd, 
unsigned int wait)

  close(fd);
  }
+/*
+ * Verify that we can submit and execute work after unwedging the GPU.
+ */
+static void test_reset_stress(int fd, unsigned int flags)
+{
+    uint32_t ctx0 = gem_context_create(fd);
+
+    igt_until_timeout(5) {
+    struct drm_i915_gem_execbuffer2 execbuf = { };
+    struct drm_i915_gem_exec_object2 obj = { };
+    uint32_t bbe = MI_BATCH_BUFFER_END;
+    igt_spin_t *hang;
+    unsigned int i;
+    uint32_t ctx;
+
+    gem_quiescent_gpu(fd);
+
+    igt_require(i915_reset_control(flags & TEST_WEDGE ?
+   false : true));
+
+    ctx = context_create_safe(fd);
+
+    /*
+ * Start executing a spin batch with some queued batches
+ * against a different context after it.
+ */


Aren't all batches queued on ctx0? Or is this a reference to the 
check on ctx you have later in the test.


Yes, a mistake in comment text.


+    hang = spin_sync(fd, ctx0, 0);


I think you meant to send this^ on ctx.


Why do you think so? Did you find a different or better way to trigger 
the bug this test is trying to hit?


Nope, I just misunderstood the code :). I thought you were creating ctx 
as 'safe' to be not 'bannable' because you were going to reuse the same 
context across multiple resets and didn't want it to be banned. BTW 
given that this is not the case wouldn't ctx0 be banned after so many 
resets?


Apologies for the cryptic comment,
Antonio.



Regards,

Tvrtko


Antonio.


+
+    obj.handle = gem_create(fd, 4096);
+    gem_write(fd, obj.handle, 0, , sizeof(bbe));
+
+    execbuf.buffers_ptr = to_user_pointer();
+    execbuf.buffer_count = 1;
+    execbuf.rsvd1 = ctx0;
+
+    for (i = 0; i < 10; i++)
+    gem_execbuf(fd, );
+
+    /* Wedge after a small delay. */
+    igt_assert_eq(__check_wait(fd, obj.handle, 100e3), 0);
+
+    /* Unwedge by forcing a reset. */
+    igt_assert(i915_reset_control(true));
+    trigger_reset(fd);
+
+    gem_quiescent_gpu(fd);
+
+    /*
+ * Verify that we are able to submit work after unwedging from
+ * both contexts.
+ */
+    execbuf.rsvd1 = ctx;
+    for (i = 0; i < 5; i++)
+    gem_execbuf(fd, );
+
+    execbuf.rsvd1 = ctx0;
+    for (i = 0; i < 5; i++)
+    gem_execbuf(fd, );
+
+    gem_sync(fd, obj.handle);
+    igt_spin_batch_free(fd, hang);
+    gem_context_destroy(fd, ctx);
+    gem_close(fd, obj.handle);
+    }
+
+    gem_context_destroy(fd, ctx0);
+}
+
  static int fd = -1;
  static void
@@ -635,6 +703,12 @@ igt_main
  igt_subtest("in-flight-suspend")
  test_inflight_suspend(fd);
+    igt_subtest("reset-stress")
+    test_reset_stress(fd, 0);
+
+    igt_subtest("unwedge-stress")
+    test_reset_stress(fd, TEST_WEDGE);
+
  igt_subtest_group {
  const struct {
  unsigned int wait;


___
igt-dev mailing list
igt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

___
igt-dev mailing list
igt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

[Ville Syrjälä]

On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 30-03-18 15:25, Hans de Goede wrote:
> > Hi,
> > 
> > On 30-03-18 14:44, Chris Wilson wrote:
> >> Quoting Hans de Goede (2018-03-30 13:37:40)
> >>> Hi,
> >>>
> >>> On 30-03-18 14:30, Chris Wilson wrote:
>  Quoting Hans de Goede (2018-03-30 13:27:15)
> > Before this commit the WaSkipStolenMemoryFirstPage workaround code was
> > skipping the first 4k by passing 4096 as start of the address range 
> > passed
> > to drm_mm_init(). This means that calling drm_mm_reserve_node() to try 
> > and
> > reserve the firmware framebuffer so that we can inherit it would always
> > fail, as the firmware framebuffer starts at address 0.
> >
> > Commit d43537610470 ("drm/i915: skip the first 4k of stolen memory on
> > everything >= gen8") says in its commit message: "This is confirmed to 
> > fix
> > Skylake screen flickering issues (probably caused by the fact that we
> > initialized a ring in the first page of stolen, but I didn't 100% 
> > confirm
> > this theory)."
> >
> > Which suggests that it is safe to use the first page for a linear
> > framebuffer as the firmware is doing.
> >
> > This commit always passes 0 as start to drm_mm_init() and works around
> > WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
> > by insuring the start address passed by to drm_mm_insert_node_in_range()
> > is always 4k or more. All entry points to i915_gem_stolen.c go through
> > i915_gem_stolen_insert_node_in_range(), so that any newly allocated
> > objects such as ring-buffers will not be allocated in the first 4k.
> >
> > The one exception is i915_gem_object_create_stolen_for_preallocated()
> > which directly calls drm_mm_reserve_node() which now will be able to
> > use the first 4k.
> >
> > This fixes the i915 driver no longer being able to inherit the firmware
> > framebuffer on gen8+, which fixes the video output changing from the
> > vendor logo to a black screen as soon as the i915 driver is loaded
> > (on systems without fbcon).
> 
>  We've been told by the HW guys not to use the first page. (That's my
>  understanding from every time this gets questioned.)
> >>>
> >>> Yet the GOP is happily using the first page. I think we may need to make
> >>> a difference here between the GPU not using the first page and the
> >>> display engine/pipeline not using the first page. Note that my patch
> >>> only influences the inheriting of the initial framebuffer as allocated
> >>> by the GOP. It does not influence any other allocations from the
> >>> reserved range, those will still all avoid the first page.
> >>>
> >>> Without this patch fastboot / flickerfree support is essentially broken
> >>> on any gen8+ hardware given that one of the goals of atomic is to be
> >>> able to do flickerfree transitions I think that this warrants a closer
> >>> look then just simply saying never use the first page.
> >>
> >> The concern is what else (i.e. nothing that we allocated ourselves) that
> >> may be in the first page...
> > 
> > Given that the GOP has put its framebuffer there at least at boot there
> > is nothing there, otherwise it would show up on the display.
> > 
> > We have a whole bunch of code to inherit the BIOS fb in intel_display.c
> > and AFAIK that code is there because this inheriting the BIOS fb is
> > deemed an important feature. So I'm not happy at all with the handwavy
> > best to not touch it answer I'm getting to this patch.
> > 
> > Unless there are some clear answer from the hardware folks which 
> > specifically
> > say we cannot put a framebuffer there (and then why is the GOP doing it?)
> > then I believe that the best way forward here is to get various people to
> > test with this patch and the best way to do that is probably to put it
> > in next. Note I deliberately did not add a Cc stable.
> 
> To elaborate on this, the excluding of the first 4k of the stolen memory
> region causes intel_alloc_initial_plane_obj() from intel_display.c to fail,
> which in turn causes intel_find_initial_plane_obj() to call
> intel_plane_disable_noatomic(intel_crtc, intel_plane); which temporarily
> completely turns off the display which leads to a very ugly flickering
> of the display at boot (as well as replacing the vendor logo with a
> black screen).
> 
> I think we can all agree that this behavior is undesirable and even a
> regression in behavior caused by the fix to exclude the first 4k.
> 
> Chris, if my patch is not an acceptable way to fix this, then how do you
> suggest that we fix this?
> 
> Digging a bit deeper I found this:
> 
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-kbl-vol16-workarounds.pdf
> 
> Which says:
> 
> "WaSkipStolenMemoryFirstPage:
> 
> WA to skip the first page of stolen
> memory due to sporadic HW write on *CS Idle"
> 
> And also about FBC:

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep AUX block running when disabling DPMS for MST

[Ville Syrjälä]

On Mon, Apr 02, 2018 at 05:26:16PM -0400, Lyude Paul wrote:
> While enabling/disabling DPMS before link training with MST hubs is
> perfectly valid; unfortunately disabling DPMS results in some devices
> disabling their AUX CH block as well. For SST this isn't as much of a
> problem, but for MST we need to be able to continue handling aux
> transactions even when none of the sinks are turned on since it's
> possible for us to have a single atomic commit which results in
> disabling each downstream sink, followed by subsequently re-enabling
> each sink.
> 
> If we don't do this, we'll end up stalling any pending ESI interrupts
> from the sink for up to 1ms. Unfortunately, dropping ESIs during this
> timespan makes it so that link fallback retraining for MST (which I will
> be submitting to the ML shortly) fails due to the channel EQ failure
> interrupts potentially getting dropped. Additionally, when performing a
> modeset that brings the hub status's link status from bad -> good having
> ESIs disabled for that long causes us to miss the hub's response to us
> trying to start link training as well.
> 
> Since any sink with MST is going to support DisplayPort 1.2 anyway, save
> us the hassle of trying to wait until the sink comes back up and just
> never shut the aux block down.
> 
> Changes since v2:
>  - Fix patch name, no functional changes
> 
> Signed-off-by: Lyude Paul 
> Cc: Laura Abbott 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Cc: sta...@vger.kernel.org
> Fixes: ad260ab32a4d9 ("drm/i915/dp: Write to SET_POWER dpcd to enable MST 
> hub.")
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62f82c4298ac..0479c377981b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2589,11 +2589,13 @@ void intel_dp_sink_dpms(struct intel_dp *intel_dp, 
> int mode)
>   return;
>  
>   if (mode != DRM_MODE_DPMS_ON) {
> + unsigned char data = intel_dp->is_mst ?
> + DP_SET_POWER_D3_AUX_ON : DP_SET_POWER_D3;

This smells like a workaround for an actual bug somewhere. Why exactly
is the slower wakeup or the AUX block a problem for MST but not for SST
when the link training is exactly the same for SST and MST?

> +
>   if (downstream_hpd_needs_d0(intel_dp))
>   return;
>  
> - ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER,
> -  DP_SET_POWER_D3);
> + ret = drm_dp_dpcd_writeb(_dp->aux, DP_SET_POWER, data);
>   } else {
>   struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
>  
> -- 
> 2.14.3

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

[Intel-gfx] [PATCH i-g-t v6] intel-gpu-top: Rewrite the tool to be safe to use

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

intel-gpu-top is a dangerous tool which can hang machines due unsafe mmio
register access. This patch rewrites it to use only PMU.

Only overall command streamer busyness and GPU global data such as power
and frequencies are included in this new version.

For access to more GPU functional unit level data, an OA metric based tool
like gpu-top should be used instead.

v2:
 * Sort engines by class and instance.
 * Do not wait for one sampling period to display something on screen.
 * Move code out of the asserts. (Rinat Ibragimov)
 * Continuously adapt to terminal size. (Rinat Ibragimov)

v3:
 * Change layout and precision of some field. (Chris Wilson)
 Eero Tamminen:
 * Use more user friendly engine names.
 * Don't error out if a counter is missing.
 * Add IMC read/write bandwidth.
 * Report minimum required kernel version.

v4:
 * Really support 4.16 by skipping of missing engines.
 * Simpler and less hacky float printing.
 * Preserve copyright header. (Antonio Argenziano)
 * Simplify engines_ptr macro. (Rinat Ibragimov)

v5:
 * Get RAPL unit from sysfs.
 * Consolidate sysfs paths with a macro.
 * Tidy error handling by carrying over and reporting errno.
 * Check against console height on all prints.
 * More readable minimum kernel version message. (Eero Tamminen)
 * Column banner for per engine stats. (Eero Tamminen)

v6:
 * Man page update. (Eero Tamminen)

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
Cc: Petri Latvala 
Cc: Eero Tamminen 
Cc: Rinat Ibragimov 
Reviewed-by: Lionel Landwerlin  # v1
Reviewed-by: Chris Wilson  # v0.5
---
 lib/igt_perf.c|6 +
 lib/igt_perf.h|1 +
 man/intel_gpu_top.rst |   41 +-
 tools/Makefile.am |2 +
 tools/intel_gpu_top.c | 1250 +++--
 tools/meson.build |6 +-
 6 files changed, 719 insertions(+), 587 deletions(-)

diff --git a/lib/igt_perf.c b/lib/igt_perf.c
index 99d82ea51c9b..e3dec2cc29c7 100644
--- a/lib/igt_perf.c
+++ b/lib/igt_perf.c
@@ -69,3 +69,9 @@ int igt_perf_open(uint64_t type, uint64_t config)
return _perf_open(type, config, -1,
  PERF_FORMAT_TOTAL_TIME_ENABLED);
 }
+
+int igt_perf_open_group(uint64_t type, uint64_t config, int group)
+{
+   return _perf_open(type, config, group,
+ PERF_FORMAT_TOTAL_TIME_ENABLED | PERF_FORMAT_GROUP);
+}
diff --git a/lib/igt_perf.h b/lib/igt_perf.h
index 614ea5d23fa6..e00718f4769a 100644
--- a/lib/igt_perf.h
+++ b/lib/igt_perf.h
@@ -55,5 +55,6 @@ uint64_t i915_type_id(void);
 int perf_i915_open(uint64_t config);
 int perf_i915_open_group(uint64_t config, int group);
 int igt_perf_open(uint64_t type, uint64_t config);
+int igt_perf_open_group(uint64_t type, uint64_t config, int group);
 
 #endif /* I915_PERF_H */
diff --git a/man/intel_gpu_top.rst b/man/intel_gpu_top.rst
index a5f7175bb1a0..19c712307d28 100644
--- a/man/intel_gpu_top.rst
+++ b/man/intel_gpu_top.rst
@@ -7,9 +7,9 @@ Display a top-like summary of Intel GPU usage
 -
 .. include:: defs.rst
 :Author: IGT Developers 
-:Date: 2016-03-01
+:Date: 2018-04-04
 :Version: |PACKAGE_STRING|
-:Copyright: 2009,2011,2012,2016 Intel Corporation
+:Copyright: 2009,2011,2012,2016,2018 Intel Corporation
 :Manual section: |MANUAL_SECTION|
 :Manual group: |MANUAL_GROUP|
 
@@ -21,42 +21,25 @@ SYNOPSIS
 DESCRIPTION
 ===
 
-**intel_gpu_top** is a tool to display usage information of an Intel GPU. It
-requires root privilege to map the graphics device.
+**intel_gpu_top** is a tool to display usage information on Intel GPU's.
+
+The tool gathers data using perf performance counters (PMU) exposed by i915 
and other platform drivers like RAPL (power) and Uncore IMC (memory bandwidth).
 
 OPTIONS
 ===
 
--s SAMPLES
-Number of samples to acquire per second.
-
--o FILE
-Collect usage statistics to FILE. If file is "-", run non-interactively
-and output statistics to stdout.
-
--e COMMAND
-Execute COMMAND to profile, and leave when it is finished. Note that the
-entire command with all parameters should be included as one parameter.
+-s 
+Refresh period in milliseconds.
 
 -h
-Show usage notes.
+Show help text.
 
-EXAMPLES
-
-
-intel_gpu_top -o "cairo-trace-gvim.log" -s 100 -e "cairo-perf-trace /tmp/gvim"
-Run cairo-perf-trace with /tmp/gvim trace, non-interactively, saving the
-statistics into cairo-trace-gvim.log file, and collecting 100 samples per
-second.
-
-Note that idle units are not displayed, so an entirely idle GPU will only
-display the ring status and header.
+LIMITATIONS
+===
 
-BUGS
-
+* Not all metrics are 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] intel-gpu-top: Rewrite the tool to be safe to use

[Tvrtko Ursulin]

On 04/04/2018 15:23, Eero Tamminen wrote:

Hi,

On 04.04.2018 15:42, Tvrtko Ursulin wrote:

On 04/04/2018 13:15, Eero Tamminen wrote:

I've now tested v5 with old Ubuntu kernel on KBL, and with latest
drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.


Generic test results


* Tool works on all of them

* The new error messages and headings look good

* Idle IMC read amounts correspond to expected values on SNB & HSW.
   The much smaller values on BDW & SKL are due to FBC (how well
   it compresses, naturally depends on screen content).


Unlike I assumed earlier, it's not actually uncore bandwidth.
It's RAM bandwidth, I guess the IMC abbreviation is for something
like Intel/Integrated Memory Controller.

Note that it includes also any memory bandwidth used by CPU, and if
the data fits into LLC, it doesn't show it.

However, knowing whether CPU uses memory bandwidth is actually useful
thing because RAM bandwidth is a shared resource with GPU.  One can
check other tasks bandwidth usage before launching the GPU task.


Hm OK, you managed to explain it. Because in the meantime I have 
observed one oddity with write bandwidth on my headless SkullCanyon 
NUC. It idles around 28MiB/s,


On idle machine, write bandwidth usage should be zero.

What is causing the writes?


It was probably caused by some of the kernel debug options I had set. Or 
maybe disabled dynticks. With fewer debug options and dynticks I cannot 
reproduce that any more.


Regards,

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: throw __must_check at GEM_WARN_ON

[Patchwork]

== Series Details ==

Series: drm/i915: throw __must_check at GEM_WARN_ON
URL   : https://patchwork.freedesktop.org/series/41136/
State : success

== Summary ==

 Known issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-farfromfence:
fail   -> PASS   (shard-apl) fdo#103167
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3498 pass:1834 dwarn:1   dfail:0   fail:7   skip:1655 
time:12845s
shard-hswtotal:3498 pass:1785 dwarn:1   dfail:0   fail:1   skip:1710 
time:11492s
shard-snbtotal:3498 pass:1377 dwarn:1   dfail:0   fail:2   skip:2118 
time:7060s
Blacklisted hosts:
shard-kbltotal:3498 pass:1942 dwarn:19  dfail:1   fail:7   skip:1529 
time:9263s

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] intel-gpu-top: Rewrite the tool to be safe to use

[Eero Tamminen]

Hi,

On 04.04.2018 15:42, Tvrtko Ursulin wrote:

On 04/04/2018 13:15, Eero Tamminen wrote:

I've now tested v5 with old Ubuntu kernel on KBL, and with latest
drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.


Generic test results


* Tool works on all of them

* The new error messages and headings look good

* Idle IMC read amounts correspond to expected values on SNB & HSW.
   The much smaller values on BDW & SKL are due to FBC (how well
   it compresses, naturally depends on screen content).


Unlike I assumed earlier, it's not actually uncore bandwidth.
It's RAM bandwidth, I guess the IMC abbreviation is for something
like Intel/Integrated Memory Controller.

Note that it includes also any memory bandwidth used by CPU, and if
the data fits into LLC, it doesn't show it.

However, knowing whether CPU uses memory bandwidth is actually useful
thing because RAM bandwidth is a shared resource with GPU.  One can
check other tasks bandwidth usage before launching the GPU task.


Hm OK, you managed to explain it. Because in the meantime I have 
observed one oddity with write bandwidth on my headless SkullCanyon NUC. 
It idles around 28MiB/s,


On idle machine, write bandwidth usage should be zero.

What is causing the writes?


while when I load it up with some command 
streamer activity it drops to ~11MiB/s. I don't know, but just feels 
suspect. (Read bandwidth goes from ~215MiB/s at idle to ~4.5GiB/s in my 
load case.)


Is it possible that your test load directly affected whatever task
was causing the writes?  E.g. if the write load and the read load
e.g. both use render pipeline, your read load could slow down
the write load (by "flooding" render pipeline).

The effect could also be indirect. E.g. read bandwidth usage could eat
part of the write bandwidth, as they aren't completely independent
resources.

Or if your test load is very heavy, it could cause TDP limitation
for the whole device, which could drop other tasks a bit.

I would need to know more about what your write load is, to come up
with a good excuse. ;-)


- Eero


BYT & BSW
-

* IMC, power usage and actual(?) freq values are missing.

-> You can get actual freq by polling CAGF register, represented by:
 /sys/class/drm/card0/gt_act_freq_mhz


Yep, this is the i915 internal limitation that we cannot expose this for 
consumption from PMU.




Normally i915 driver maps uncore power usage to GPU power usage,
but BYT is missing that (and ram power usage).  However, RAPL
does report package & core values...


Suggestions
---

Maybe on platforms where RAPL doesn't report "uncore" power usage,
you could just deduct RAPL reported "core" power consumption from
the "package" power consumption, and report that as "GPU" power
usage?  (Or do that in i915 directly)


What are you referring to as "uncore" in the context of RAPL?

Do I understood correctly you suggested to use "energy-pkg - 
energy-cores" when "energy-gpu" is not available? If the former two are 
there both on on BYT and BSW, this sounds okay to me.



You need also to either update the manual, or implement -o and -e


There is a manual, will do!


options for the new version of intel_gpu_top.  CSV output of all
the reported values would be nice.


I would prefer to drop both -o and -e, since this is achievable via perf 
stat. For instance:


perf stat -a -e power/energy-gpu/,i915/rcs0-busy/ -I 1000 -x, 

Gives CSV samples once per second.

On the other hand one argument I can think of to actually do implement 
-o and -e, is that we need to do some extra normalization on some i915 
counters perf tool would not do.


I don't have a feeling if anyone is actually using these options. If 
unlikely, we should probably drop them regardless.



You might mention in manual as an example how to calculate
idle screen update bandwidth, and that it's impacted by:
- PSR (panel self refresh, depends on display supporting it):
   /sys/kernel/debug/dri/0/i915_edp_psr_status
- FBC (frame buffer compression, enabled on newer GENs)
   /sys/kernel/debug/dri/0/i915_fbc_status
- end-to-end RBC (render buffer compression, requires modifiers
   support i.e. GEN9+ GPU and X & Mesa with DRI3 v1.2 [1] support)


Sounds useful for users, but I am a bit wary of feature creep. In this 
specific example I'd want to push it for follow-up work.


Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 1/1] drm/i915:Do not use kfree() to free kmem_cache_alloc() return value

[kbuild test robot]

Hi Xidong,

Thank you for the patch! Yet something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Xidong-Wang/drm-i915-Do-not-use-kfree-to-free-kmem_cache_alloc-return-value/20180404-193341
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x009-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_gem_execbuffer.c: In function 'eb_lookup_vmas':
>> drivers/gpu//drm/i915/i915_gem_execbuffer.c:731:20: error: passing argument 
>> 1 of 'kmem_cache_free' from incompatible pointer type 
>> [-Werror=incompatible-pointer-types]
   kmem_cache_free(lut);
   ^~~
   In file included from include/linux/reservation.h:44:0,
from drivers/gpu//drm/i915/i915_gem_execbuffer.c:30:
   include/linux/slab.h:356:6: note: expected 'struct kmem_cache *' but 
argument is of type 'struct i915_lut_handle *'
void kmem_cache_free(struct kmem_cache *, void *);
 ^~~
>> drivers/gpu//drm/i915/i915_gem_execbuffer.c:731:4: error: too few arguments 
>> to function 'kmem_cache_free'
   kmem_cache_free(lut);
   ^~~
   In file included from include/linux/reservation.h:44:0,
from drivers/gpu//drm/i915/i915_gem_execbuffer.c:30:
   include/linux/slab.h:356:6: note: declared here
void kmem_cache_free(struct kmem_cache *, void *);
 ^~~
   cc1: some warnings being treated as errors

vim +/kmem_cache_free +731 drivers/gpu//drm/i915/i915_gem_execbuffer.c

   685  
   686  static int eb_lookup_vmas(struct i915_execbuffer *eb)
   687  {
   688  struct radix_tree_root *handles_vma = >ctx->handles_vma;
   689  struct drm_i915_gem_object *obj;
   690  unsigned int i;
   691  int err;
   692  
   693  if (unlikely(i915_gem_context_is_closed(eb->ctx)))
   694  return -ENOENT;
   695  
   696  if (unlikely(i915_gem_context_is_banned(eb->ctx)))
   697  return -EIO;
   698  
   699  INIT_LIST_HEAD(>relocs);
   700  INIT_LIST_HEAD(>unbound);
   701  
   702  for (i = 0; i < eb->buffer_count; i++) {
   703  u32 handle = eb->exec[i].handle;
   704  struct i915_lut_handle *lut;
   705  struct i915_vma *vma;
   706  
   707  vma = radix_tree_lookup(handles_vma, handle);
   708  if (likely(vma))
   709  goto add_vma;
   710  
   711  obj = i915_gem_object_lookup(eb->file, handle);
   712  if (unlikely(!obj)) {
   713  err = -ENOENT;
   714  goto err_vma;
   715  }
   716  
   717  vma = i915_vma_instance(obj, eb->vm, NULL);
   718  if (unlikely(IS_ERR(vma))) {
   719  err = PTR_ERR(vma);
   720  goto err_obj;
   721  }
   722  
   723  lut = kmem_cache_alloc(eb->i915->luts, GFP_KERNEL);
   724  if (unlikely(!lut)) {
   725  err = -ENOMEM;
   726  goto err_obj;
   727  }
   728  
   729  err = radix_tree_insert(handles_vma, handle, vma);
   730  if (unlikely(err)) {
 > 731  kmem_cache_free(lut);
   732  goto err_obj;
   733  }
   734  
   735  /* transfer ref to ctx */
   736  vma->open_count++;
   737  list_add(>obj_link, >lut_list);
   738  list_add(>ctx_link, >ctx->handles_list);
   739  lut->ctx = eb->ctx;
   740  lut->handle = handle;
   741  
   742  add_vma:
   743  err = eb_add_vma(eb, i, vma);
   744  if (unlikely(err))
   745  goto err_vma;
   746  
   747  GEM_BUG_ON(vma != eb->vma[i]);
   748  GEM_BUG_ON(vma->exec_flags != >flags[i]);
   749  }
   750  
   751  /* take note of the batch buffer before we might reorder the 
lists */
   752  i = eb_batch_index(eb);
   753  eb->batch = eb->vma[i];
   754  GEM_BUG_ON(eb->batch->exec_flags != >flags[i]);
   755  
   756  /*
   757   * SNA is doing fancy tricks with compressing batch buffers, 
which leads
   758   * 

Re: [Intel-gfx] [PATCH 1/1] drm/i915:Do not use kfree() to free kmem_cache_alloc() return value

[kbuild test robot]

Hi Xidong,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Xidong-Wang/drm-i915-Do-not-use-kfree-to-free-kmem_cache_alloc-return-value/20180404-193341
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:41: sparse: incorrect type in 
>> argument 1 (different base types) @@expected struct kmem_cache 
>> * @@got struct i915_lut_struct kmem_cache * @@
   drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:41:expected struct 
kmem_cache *
   drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:41:got struct 
i915_lut_handle *[assigned] lut
>> drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:40: sparse: not enough 
>> arguments for function kmem_cache_free
   drivers/gpu/drm/i915/i915_gem_execbuffer.c: In function 'eb_lookup_vmas':
   drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:20: error: passing argument 1 
of 'kmem_cache_free' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
   kmem_cache_free(lut);
   ^~~
   In file included from include/linux/reservation.h:44:0,
from drivers/gpu/drm/i915/i915_gem_execbuffer.c:30:
   include/linux/slab.h:356:6: note: expected 'struct kmem_cache *' but 
argument is of type 'struct i915_lut_handle *'
void kmem_cache_free(struct kmem_cache *, void *);
 ^~~
   drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:4: error: too few arguments 
to function 'kmem_cache_free'
   kmem_cache_free(lut);
   ^~~
   In file included from include/linux/reservation.h:44:0,
from drivers/gpu/drm/i915/i915_gem_execbuffer.c:30:
   include/linux/slab.h:356:6: note: declared here
void kmem_cache_free(struct kmem_cache *, void *);
 ^~~
   cc1: some warnings being treated as errors

vim +731 drivers/gpu/drm/i915/i915_gem_execbuffer.c

   685  
   686  static int eb_lookup_vmas(struct i915_execbuffer *eb)
   687  {
   688  struct radix_tree_root *handles_vma = >ctx->handles_vma;
   689  struct drm_i915_gem_object *obj;
   690  unsigned int i;
   691  int err;
   692  
   693  if (unlikely(i915_gem_context_is_closed(eb->ctx)))
   694  return -ENOENT;
   695  
   696  if (unlikely(i915_gem_context_is_banned(eb->ctx)))
   697  return -EIO;
   698  
   699  INIT_LIST_HEAD(>relocs);
   700  INIT_LIST_HEAD(>unbound);
   701  
   702  for (i = 0; i < eb->buffer_count; i++) {
   703  u32 handle = eb->exec[i].handle;
   704  struct i915_lut_handle *lut;
   705  struct i915_vma *vma;
   706  
   707  vma = radix_tree_lookup(handles_vma, handle);
   708  if (likely(vma))
   709  goto add_vma;
   710  
   711  obj = i915_gem_object_lookup(eb->file, handle);
   712  if (unlikely(!obj)) {
   713  err = -ENOENT;
   714  goto err_vma;
   715  }
   716  
   717  vma = i915_vma_instance(obj, eb->vm, NULL);
   718  if (unlikely(IS_ERR(vma))) {
   719  err = PTR_ERR(vma);
   720  goto err_obj;
   721  }
   722  
   723  lut = kmem_cache_alloc(eb->i915->luts, GFP_KERNEL);
   724  if (unlikely(!lut)) {
   725  err = -ENOMEM;
   726  goto err_obj;
   727  }
   728  
   729  err = radix_tree_insert(handles_vma, handle, vma);
   730  if (unlikely(err)) {
 > 731  kmem_cache_free(lut);
   732  goto err_obj;
   733  }
   734  
   735  /* transfer ref to ctx */
   736  vma->open_count++;
   737  list_add(>obj_link, >lut_list);
   738  list_add(>ctx_link, >ctx->handles_list);
   739  lut->ctx = eb->ctx;
   740  lut->handle = handle;
   741  
   742  add_vma:
   743  err = eb_add_vma(eb, i, vma);
   744  if (unlikely(err))
   745  goto err_vma;
   746  
   747  GEM_BUG_ON(vma != eb->vma[i]);
   748  GEM_BUG_ON(vma->exec_flags != 

Re: [Intel-gfx] [PATCH 1/1] drm/i915:Do not use kfree() to free kmem_cache_alloc() return value

[kbuild test robot]

Hi Xidong,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/Xidong-Wang/drm-i915-Do-not-use-kfree-to-free-kmem_cache_alloc-return-value/20180404-193341
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a1-201813 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_gem_execbuffer.c: In function 'eb_lookup_vmas':
>> drivers/gpu//drm/i915/i915_gem_execbuffer.c:731:20: warning: passing 
>> argument 1 of 'kmem_cache_free' from incompatible pointer type
   kmem_cache_free(lut);
   ^
   In file included from include/linux/reservation.h:44:0,
from drivers/gpu//drm/i915/i915_gem_execbuffer.c:30:
   include/linux/slab.h:356:6: note: expected 'struct kmem_cache *' but 
argument is of type 'struct i915_lut_handle *'
void kmem_cache_free(struct kmem_cache *, void *);
 ^
   drivers/gpu//drm/i915/i915_gem_execbuffer.c:731:4: error: too few arguments 
to function 'kmem_cache_free'
   kmem_cache_free(lut);
   ^
   In file included from include/linux/reservation.h:44:0,
from drivers/gpu//drm/i915/i915_gem_execbuffer.c:30:
   include/linux/slab.h:356:6: note: declared here
void kmem_cache_free(struct kmem_cache *, void *);
 ^

vim +/kmem_cache_free +731 drivers/gpu//drm/i915/i915_gem_execbuffer.c

   685  
   686  static int eb_lookup_vmas(struct i915_execbuffer *eb)
   687  {
   688  struct radix_tree_root *handles_vma = >ctx->handles_vma;
   689  struct drm_i915_gem_object *obj;
   690  unsigned int i;
   691  int err;
   692  
   693  if (unlikely(i915_gem_context_is_closed(eb->ctx)))
   694  return -ENOENT;
   695  
   696  if (unlikely(i915_gem_context_is_banned(eb->ctx)))
   697  return -EIO;
   698  
   699  INIT_LIST_HEAD(>relocs);
   700  INIT_LIST_HEAD(>unbound);
   701  
   702  for (i = 0; i < eb->buffer_count; i++) {
   703  u32 handle = eb->exec[i].handle;
   704  struct i915_lut_handle *lut;
   705  struct i915_vma *vma;
   706  
   707  vma = radix_tree_lookup(handles_vma, handle);
   708  if (likely(vma))
   709  goto add_vma;
   710  
   711  obj = i915_gem_object_lookup(eb->file, handle);
   712  if (unlikely(!obj)) {
   713  err = -ENOENT;
   714  goto err_vma;
   715  }
   716  
   717  vma = i915_vma_instance(obj, eb->vm, NULL);
   718  if (unlikely(IS_ERR(vma))) {
   719  err = PTR_ERR(vma);
   720  goto err_obj;
   721  }
   722  
   723  lut = kmem_cache_alloc(eb->i915->luts, GFP_KERNEL);
   724  if (unlikely(!lut)) {
   725  err = -ENOMEM;
   726  goto err_obj;
   727  }
   728  
   729  err = radix_tree_insert(handles_vma, handle, vma);
   730  if (unlikely(err)) {
 > 731  kmem_cache_free(lut);
   732  goto err_obj;
   733  }
   734  
   735  /* transfer ref to ctx */
   736  vma->open_count++;
   737  list_add(>obj_link, >lut_list);
   738  list_add(>ctx_link, >ctx->handles_list);
   739  lut->ctx = eb->ctx;
   740  lut->handle = handle;
   741  
   742  add_vma:
   743  err = eb_add_vma(eb, i, vma);
   744  if (unlikely(err))
   745  goto err_vma;
   746  
   747  GEM_BUG_ON(vma != eb->vma[i]);
   748  GEM_BUG_ON(vma->exec_flags != >flags[i]);
   749  }
   750  
   751  /* take note of the batch buffer before we might reorder the 
lists */
   752  i = eb_batch_index(eb);
   753  eb->batch = eb->vma[i];
   754  GEM_BUG_ON(eb->batch->exec_flags != >flags[i]);
   755  
   756  /*
   757   * SNA is doing fancy tricks with compressing batch buffers, 
which leads
   758   * to negative relocation deltas. Usually that works out ok 
since the
   759   * relocate address is still positive, except when the

Re: [Intel-gfx] [PATCH i-g-t v5] intel-gpu-top: Rewrite the tool to be safe to use

[Rinat Ibragimov]

>Среда,  4 апреля 2018, 12:48 +03:00 от Tvrtko Ursulin :
>
>v5:

Tried this version on Skylake on Linux 4.16, and it works. Engines "busy" metric
behaves as expected. Render/3D goes up when something intensive happens on
a screen. Video goes up when I use VA-API-enabled video players, and increases
when I increase speed there. Blitter is typically at 0%, since I use 
"modesetting" driver.
When using "intel" driver instead, I can see Blitter metric changing too.
Haven't seen VideoEnhance to go over 0%, but that's probably due to the player 
not
using it at all. Power usage and frequency numbers are also having values I'd 
expect.

Output looks neat, and overall it works great. Thanks!


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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] intel-gpu-top: Rewrite the tool to be safe to use

[Tvrtko Ursulin]

Hi,

On 04/04/2018 13:15, Eero Tamminen wrote:

Hi,

I've now tested v5 with old Ubuntu kernel on KBL, and with latest
drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.


Generic test results


* Tool works on all of them

* The new error messages and headings look good

* Idle IMC read amounts correspond to expected values on SNB & HSW.
   The much smaller values on BDW & SKL are due to FBC (how well
   it compresses, naturally depends on screen content).


Hm OK, you managed to explain it. Because in the meantime I have 
observed one oddity with write bandwidth on my headless SkullCanyon NUC. 
It idles around 28MiB/s, while when I load it up with some command 
streamer activity it drops to ~11MiB/s. I don't know, but just feels 
suspect. (Read bandwidth goes from ~215MiB/s at idle to ~4.5GiB/s in my 
load case.)





BYT & BSW
-

* IMC, power usage and actual(?) freq values are missing.

-> You can get actual freq by polling CAGF register, represented by:
 /sys/class/drm/card0/gt_act_freq_mhz


Yep, this is the i915 internal limitation that we cannot expose this for 
consumption from PMU.




Normally i915 driver maps uncore power usage to GPU power usage,
but BYT is missing that (and ram power usage).  However, RAPL
does report package & core values...


Suggestions
---

Maybe on platforms where RAPL doesn't report "uncore" power usage,
you could just deduct RAPL reported "core" power consumption from
the "package" power consumption, and report that as "GPU" power
usage?  (Or do that in i915 directly)


What are you referring to as "uncore" in the context of RAPL?

Do I understood correctly you suggested to use "energy-pkg - 
energy-cores" when "energy-gpu" is not available? If the former two are 
there both on on BYT and BSW, this sounds okay to me.



You need also to either update the manual, or implement -o and -e


There is a manual, will do!


options for the new version of intel_gpu_top.  CSV output of all
the reported values would be nice.


I would prefer to drop both -o and -e, since this is achievable via perf 
stat. For instance:


perf stat -a -e power/energy-gpu/,i915/rcs0-busy/ -I 1000 -x, 

Gives CSV samples once per second.

On the other hand one argument I can think of to actually do implement 
-o and -e, is that we need to do some extra normalization on some i915 
counters perf tool would not do.


I don't have a feeling if anyone is actually using these options. If 
unlikely, we should probably drop them regardless.



You might mention in manual as an example how to calculate
idle screen update bandwidth, and that it's impacted by:
- PSR (panel self refresh, depends on display supporting it):
   /sys/kernel/debug/dri/0/i915_edp_psr_status
- FBC (frame buffer compression, enabled on newer GENs)
   /sys/kernel/debug/dri/0/i915_fbc_status
- end-to-end RBC (render buffer compression, requires modifiers
   support i.e. GEN9+ GPU and X & Mesa with DRI3 v1.2 [1] support)


Sounds useful for users, but I am a bit wary of feature creep. In this 
specific example I'd want to push it for follow-up work.


Regards,

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

Re: [Intel-gfx] Linux 4.16 Kernel Boot Crash

[Jani Nikula]

On Tue, 03 Apr 2018, Peter Geis  wrote:
> Good Evening,
>
> I have been trying to use the 4.16 kernel source since 4.16-rc3.
> Every time it booted it crashed upon loading the video drivers.
> Now with the 4.16 release, it is still occurring, so I felt it prudent 
> to notify someone.
>
> The machine is a Lenovo Yoga 900 80UE-ISK2.
> It has a i7-6560u CPU with Intel integrated graphics.

This doesn't seem to have anything to do with Intel graphics. Based on
the backtraces, adding linux-media and linux-input mailing lists and
maintainers.

BR,
Jani.


>
> I have included the kernel log, what format should I submit the vmcore 
> dump in?
>
> Thanks,
> Peter Geis
>
>
> ---Begin Log---
>
> [   43.177394] WARNING: CPU: 1 PID: 711 at 
> drivers/media/v4l2-core/v4l2-dev.c:945 
> __video_register_device+0xc99/0x1090 [videodev]
> [   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
> hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d 
> hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger 
> industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common 
> hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops 
> videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
> hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 
> snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp 
> snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic 
> snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel 
> snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep 
> intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi 
> snd_seq_midi_event snd_rawmidi crct10dif_pclmul
> [   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 
> snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd 
> glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds 
> serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore 
> ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad 
> int3400_thermal acpi_thermal_rel intel_pch_thermal 
> processor_thermal_device mac_hid int340x_thermal_zone mei_me 
> intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel 
> vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd 
> grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp 
> hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 
> vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea 
> sdhci_pci sysfillrect
> [   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid 
> video pinctrl_sunrisepoint pinctrl_intel
> [   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
> [   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
> [   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
> [   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
> [   43.177484] RAX:  RBX: 0005 RCX: 
> 
> [   43.177485] RDX: c0c44cc0 RSI:  RDI: 
> c0c44cc0
> [   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
> 8eda1a51f018
> [   43.177487] R10: 0600 R11: 03b6 R12: 
> 
> [   43.177488] R13: 0005 R14: c0c96900 R15: 
> 8eda1d6d91c0
> [   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
> knlGS:
> [   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
> [   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
> 003606e0
> [   43.177492] Call Trace:
> [   43.177498]  ? devres_add+0x5f/0x70
> [   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
> [   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
> [   43.177507]  driver_probe_device+0x310/0x480
> [   43.177509]  __device_attach_driver+0x86/0x100
> [   43.177511]  ? __driver_attach+0xf0/0xf0
> [   43.177512]  bus_for_each_drv+0x6b/0xb0
> [   43.177514]  __device_attach+0xdd/0x160
> [   43.177516]  device_initial_probe+0x13/0x20
> [   43.177518]  bus_probe_device+0x95/0xa0
> [   43.177519]  device_add+0x44b/0x680
> [   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
> [   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
> [   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
> [   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
> [   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
> [   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
> [   43.177547]  ? sysfs_create_link+0x25/0x40
> [   43.177549]  driver_probe_device+0x310/0x480
> [   43.177551]  __device_attach_driver+0x86/0x100
> [   43.177553]  ? __driver_attach+0xf0/0xf0
> [   43.177554]  bus_for_each_drv+0x6b/0xb0
> [   43.177556]  __device_attach+0xdd/0x160
> [   43.177558]  device_initial_probe+0x13/0x20
> [   43.177560]  bus_probe_device+0x95/0xa0
> [   43.177561]  device_add+0x44b/0x680
> [   43.177564]  

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/1] drm/i915:Do not use kfree() to free kmem_cache_alloc() return value

[Patchwork]

== Series Details ==

Series: series starting with [1/1] drm/i915:Do not use kfree() to free 
kmem_cache_alloc() return value
URL   : https://patchwork.freedesktop.org/series/41137/
State : failure

== Summary ==

CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
drivers/gpu/drm/i915/i915_gem_execbuffer.c: In function ‘eb_lookup_vmas’:
drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:20: error: passing argument 1 of 
‘kmem_cache_free’ from incompatible pointer type 
[-Werror=incompatible-pointer-types]
kmem_cache_free(lut);
^~~
In file included from ./include/linux/reservation.h:44:0,
 from drivers/gpu/drm/i915/i915_gem_execbuffer.c:30:
./include/linux/slab.h:356:6: note: expected ‘struct kmem_cache *’ but argument 
is of type ‘struct i915_lut_handle *’
 void kmem_cache_free(struct kmem_cache *, void *);
  ^~~
drivers/gpu/drm/i915/i915_gem_execbuffer.c:731:4: error: too few arguments to 
function ‘kmem_cache_free’
kmem_cache_free(lut);
^~~
In file included from ./include/linux/reservation.h:44:0,
 from drivers/gpu/drm/i915/i915_gem_execbuffer.c:30:
./include/linux/slab.h:356:6: note: declared here
 void kmem_cache_free(struct kmem_cache *, void *);
  ^~~
cc1: all warnings being treated as errors
scripts/Makefile.build:324: recipe for target 
'drivers/gpu/drm/i915/i915_gem_execbuffer.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_execbuffer.o] Error 1
scripts/Makefile.build:583: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:583: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:583: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1060: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

Re: [Intel-gfx] [PULL] gvt-fixes for 4.17-rc1

[Joonas Lahtinen]

Quoting Zhenyu Wang (2018-04-03 10:28:35)
> 
> Hi,
> 
> Here's refreshed fixes for 4.17-rc1 with regression one removed,
> contains a few fixes for vfio ioctl and dmabuf interface, properly
> dma unmap for ggtt, etc.

I don't think -Wimplicit-fallthrough will be enabled retroactively, so
I'm don't think we gain anything by including it in -fixes. For further
pull requests, patches like that shouldn't be included.

Pulled as whole, anyway. Thanks.

Regards, Joonas

> 
> thanks
> --
> The following changes since commit d8303075699292008ae5b2c8fc728d455b994c26:
> 
>   drm/i915/gvt: force to set all context control bits from guest (2018-03-19 
> 17:33:30 +0800)
> 
> are available in the Git repository at:
> 
>   https://github.com/intel/gvt-linux tags/gvt-fixes-2018-04-03
> 
> for you to fetch changes up to 10996f802109c83421ca30556cfe36ffc3bebae3:
> 
>   drm/i915/gvt: Add drm_format_mod update (2018-03-30 14:47:20 +0800)
> 
> 
> gvt-fixes-2018-04-03
> 
> - fix unhandled vfio ioctl return value (Gerd)
> - no-op user interrupt for vGPU (Zhipeng)
> - fix ggtt dma unmap (Changbin)
> - fix warning in fb decoder (Xiong)
> - dmabuf drm_format_mod fix (Tina)
> - misc cleanup
> 
> 
> Changbin Du (2):
>   drm/i915/gvt: Missed to cancel dma map for ggtt entries
>   drm/i915/gvt: Cancel dma map when resetting ggtt entries
> 
> Gerd Hoffmann (1):
>   drm/i915/gvt: throw error on unhandled vfio ioctls
> 
> Gustavo A. R. Silva (1):
>   drm/i915/gvt: Mark expected switch fall-through in 
> handle_g2v_notification
> 
> Tina Zhang (1):
>   drm/i915/gvt: Add drm_format_mod update
> 
> Xiong Zhang (2):
>   drm/i915/gvt: Delete redundant error message in fb_decode.c
>   drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display 
> initialization
> 
> Zhipeng Gong (1):
>   drm/i915/gvt: Make MI_USER_INTERRUPT nop in cmd parser
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |  1 +
>  drivers/gpu/drm/i915/gvt/display.c| 10 +++
>  drivers/gpu/drm/i915/gvt/dmabuf.c |  1 +
>  drivers/gpu/drm/i915/gvt/fb_decoder.c | 27 ++
>  drivers/gpu/drm/i915/gvt/gtt.c| 52 
> ++-
>  drivers/gpu/drm/i915/gvt/gtt.h|  2 +-
>  drivers/gpu/drm/i915/gvt/handlers.c   |  1 +
>  drivers/gpu/drm/i915/gvt/kvmgt.c  |  2 +-
>  8 files changed, 69 insertions(+), 27 deletions(-)
> 
> 
> -- 
> Open Source Technology Center, Intel ltd.
> 
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
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: throw __must_check at GEM_WARN_ON

[Patchwork]

== Series Details ==

Series: drm/i915: throw __must_check at GEM_WARN_ON
URL   : https://patchwork.freedesktop.org/series/41136/
State : success

== Summary ==

Series 41136v1 drm/i915: throw __must_check at GEM_WARN_ON
https://patchwork.freedesktop.org/api/1.0/series/41136/revisions/1/mbox/

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:387s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:523s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:518s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:510s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:426s
fi-gdg-551   total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 
time:312s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:473s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:662s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:569s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:255  dwarn:3   dfail:0   fail:1   skip:26  
time:514s

9fc36cf90e2648b9b98713efd56d342281551e50 drm-tip: 2018y-04m-04d-10h-41m-30s UTC 
integration manifest
06c0a462015a drm/i915: throw __must_check at GEM_WARN_ON

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2] intel-gpu-top: Rewrite the tool to be safe to use

[Eero Tamminen]

Hi,

I've now tested v5 with old Ubuntu kernel on KBL, and with latest
drm-tip kernel on SNB, HSW, BYT, BSW and BDW GT & GT3.


Generic test results


* Tool works on all of them

* The new error messages and headings look good

* Idle IMC read amounts correspond to expected values on SNB & HSW.
  The much smaller values on BDW & SKL are due to FBC (how well
  it compresses, naturally depends on screen content).


BYT & BSW
-

* IMC, power usage and actual(?) freq values are missing.

-> You can get actual freq by polling CAGF register, represented by:
/sys/class/drm/card0/gt_act_freq_mhz

Normally i915 driver maps uncore power usage to GPU power usage,
but BYT is missing that (and ram power usage).  However, RAPL
does report package & core values...


Suggestions
---

Maybe on platforms where RAPL doesn't report "uncore" power usage,
you could just deduct RAPL reported "core" power consumption from
the "package" power consumption, and report that as "GPU" power
usage?  (Or do that in i915 directly)


You need also to either update the manual, or implement -o and -e
options for the new version of intel_gpu_top.  CSV output of all
the reported values would be nice.

You might mention in manual as an example how to calculate
idle screen update bandwidth, and that it's impacted by:
- PSR (panel self refresh, depends on display supporting it):
  /sys/kernel/debug/dri/0/i915_edp_psr_status
- FBC (frame buffer compression, enabled on newer GENs)
  /sys/kernel/debug/dri/0/i915_fbc_status
- end-to-end RBC (render buffer compression, requires modifiers
  support i.e. GEN9+ GPU and X & Mesa with DRI3 v1.2 [1] support)


- Eero

[1] Requires building latest git versions of Mesa, libxcb, X server
and few other things, and adding this to X server config:
---
Section "ServerFlags"
Option "Debug" "dmabuf_capable"
EndSection
---


On 03.04.2018 20:18, Tvrtko Ursulin wrote:

On 03/04/2018 15:06, Eero Tamminen wrote:

On 03.04.2018 12:36, Tvrtko Ursulin wrote:

On 29/03/2018 15:30, Eero Tamminen wrote:

[...]

Old tool showed also GPU system memory interface (GAM) busyness.
That was valuable info, and reasonably accurate for stable loads.

Could this tool show also either that information (preferred), or
bandwidth utilized by GPU/CPU/display?

(Latest kernels offer GPU memory bandwidth usage through perf
"uncore_imc" "data_reads" & "date_writes" counters.)


Excellent suggestion and I've added IMC data_reads and data_writes to 
the tool.


Thanks, it looks fine too.  I'm just wondering about the numbers
it's reporting on SKL GT2...

AFAIK IMC counters are for uncore, so I though that they should
correspond to GTI (memory interface to outside of GPU) read and
write HW counter values.  While it seemed in some cases quite close,
in some cases the it showed a lot smaller (2/3) value than expected.

I can understand why reads are sometimes larger, because I think
uncore will include also display engine display content reads.

However, I don't see how uncore writes could be considerably smaller
than the GTI interface write amount.

(GTI interface reports the expected value which corresponds directly
to what my test application is doing (64x blended FullHD layer writes).)

Idle machine read amounts are also much smaller (60-65MB/s) than what
I think display update read should be (1920*1080*4*60Hz = 475MiB/s).

Any ideas for these two discrepancies?


I'm afraid I am not familiar with the uncore IMC, but we could always 
approach its authors?



Is "wait" value supposed to be IO-wait for given engine interface?

I never saw that change from 0%, although IO-wait in top jumped
from 0 to 20-30% with my test GPU load.


No, that is time spent in MI_WAIT_FOR_EVENT.


Could you add that info to the UI?

E.g. just have "MI" on top of the "wait" column.


Like a full header strip? Yeah makes sense, I'll add it.


 > I think not very used in current codebase.

What you're using to validate that it reports correct value?


That would be igt/tests/perf_pmu/event-wait-rcs0.




HW specific test results


BYT:
* Reports "Failed to initialize PMU!" although old intel_gpu_top
   works fine.

HSW GT2,  BDW GT3, SKL GT2 and KBL GT3e seems to work fine except
for the "wait" value.

I never saw blitter engine to do anything, but that's because
modesetting uses just 3D pipeline, and because I couldn't get
Intel DDX to work with rest of latest git version of X / 3D stack.


Thank you for testing this so thoroughly - this was really invaluable 
since I don't have access too such number of platforms. I've tried to 
fix all this in the latest version.


Machines are currently running tests, I'll check these tomorrow.


Thanks!




Kernel version support
--

My HW specific testing above was with drm-tip kernel, but I did one 
test
also with Ubuntu 16.04 v4.4 kernel (which includes v4.6 or v4.8 i915 

[Intel-gfx] [PATCH 1/1] drm/i915:Do not use kfree() to free kmem_cache_alloc() return value

[Xidong Wang]

In eb_lookup_vmas(), lut, the return value of kmem_cache_alloc(), is freed
with kfree().I think the expected paired function is kmem_cache_free().

Signed-off-by: Xidong Wang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8c170db..08fe476 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -728,7 +728,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
 
err = radix_tree_insert(handles_vma, handle, vma);
if (unlikely(err)) {
-   kfree(lut);
+   kmem_cache_free(lut);
goto err_obj;
}
 
-- 
2.7.4


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

[Intel-gfx] [PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

[Xidong Wang]

In eb_lookup_vmas(), the return value of kmem_cache_alloc() is freed
with kfree(). I think the expected paired function is kmem_cahce_free().

Signed-off-by: Xidong Wang 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8c170db..0414228 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -728,7 +728,7 @@ static int eb_lookup_vmas(struct i915_execbuffer *eb)
 
err = radix_tree_insert(handles_vma, handle, vma);
if (unlikely(err)) {
-   kfree(lut);
+   kmem_cache_free(eb->i915->luts, lut);
goto err_obj;
}
 
-- 
2.7.4


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

[Intel-gfx] Linux 4.16 Kernel Boot Crash

[Peter Geis]

Good Evening,

I have been trying to use the 4.16 kernel source since 4.16-rc3.
Every time it booted it crashed upon loading the video drivers.
Now with the 4.16 release, it is still occurring, so I felt it prudent 
to notify someone.


The machine is a Lenovo Yoga 900 80UE-ISK2.
It has a i7-6560u CPU with Intel integrated graphics.

I have included the kernel log, what format should I submit the vmcore 
dump in?


Thanks,
Peter Geis


---Begin Log---

[   43.177394] WARNING: CPU: 1 PID: 711 at 
drivers/media/v4l2-core/v4l2-dev.c:945 
__video_register_device+0xc99/0x1090 [videodev]
[   43.177396] Modules linked in: hid_sensor_custom hid_sensor_als 
hid_sensor_incl_3d hid_sensor_rotation hid_sensor_magn_3d 
hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_trigger 
industrialio_triggered_buffer kfifo_buf joydev hid_sensor_iio_common 
hid_rmi(+) rmi_core industrialio videobuf2_vmalloc videobuf2_memops 
videobuf2_v4l2 videobuf2_common videodev hid_multitouch media 
hid_sensor_hub binfmt_misc nls_iso8859_1 snd_hda_codec_hdmi arc4 
snd_soc_skl snd_soc_skl_ipc snd_hda_ext_core snd_soc_sst_dsp 
snd_soc_sst_ipc snd_hda_codec_realtek snd_soc_acpi snd_hda_codec_generic 
snd_soc_core snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel 
snd_hda_codec intel_rapl snd_hda_core x86_pkg_temp_thermal snd_hwdep 
intel_powerclamp coretemp snd_pcm kvm_intel snd_seq_midi 
snd_seq_midi_event snd_rawmidi crct10dif_pclmul
[   43.177426]  crc32_pclmul ghash_clmulni_intel iwlmvm pcbc mac80211 
snd_seq aesni_intel iwlwifi aes_x86_64 snd_seq_device crypto_simd 
glue_helper cryptd snd_timer intel_cstate intel_rapl_perf input_leds 
serio_raw intel_wmi_thunderbolt snd wmi_bmof cfg80211 soundcore 
ideapad_laptop sparse_keymap idma64 virt_dma tpm_crb acpi_pad 
int3400_thermal acpi_thermal_rel intel_pch_thermal 
processor_thermal_device mac_hid int340x_thermal_zone mei_me 
intel_soc_dts_iosf mei intel_lpss_pci shpchp intel_lpss sch_fq_codel 
vfio_pci nfsd vfio_virqfd parport_pc ppdev auth_rpcgss nfs_acl lockd 
grace lp parport sunrpc ip_tables x_tables autofs4 hid_logitech_hidpp 
hid_logitech_dj hid_generic usbhid kvmgt vfio_mdev mdev vfio_iommu_type1 
vfio kvm irqbypass i915 i2c_algo_bit drm_kms_helper syscopyarea 
sdhci_pci sysfillrect
[   43.177466]  sysimgblt cqhci fb_sys_fops sdhci drm i2c_hid wmi hid 
video pinctrl_sunrisepoint pinctrl_intel

[   43.177474] CPU: 1 PID: 711 Comm: systemd-udevd Not tainted 4.16.0 #1
[   43.177475] Hardware name: LENOVO 80UE/VIUU4, BIOS 2UCN10T 10/14/2016
[   43.177481] RIP: 0010:__video_register_device+0xc99/0x1090 [videodev]
[   43.177482] RSP: :a5c5c231b420 EFLAGS: 00010202
[   43.177484] RAX:  RBX: 0005 RCX: 

[   43.177485] RDX: c0c44cc0 RSI:  RDI: 
c0c44cc0
[   43.177486] RBP: a5c5c231b478 R08: c0c96900 R09: 
8eda1a51f018
[   43.177487] R10: 0600 R11: 03b6 R12: 

[   43.177488] R13: 0005 R14: c0c96900 R15: 
8eda1d6d91c0
[   43.177489] FS:  7fd2d8ef2480() GS:8eda3348() 
knlGS:

[   43.177490] CS:  0010 DS:  ES:  CR0: 80050033
[   43.177491] CR2: 7ffe0a6ad01c CR3: 000456ae2004 CR4: 
003606e0

[   43.177492] Call Trace:
[   43.177498]  ? devres_add+0x5f/0x70
[   43.177502]  rmi_f54_probe+0x437/0x470 [rmi_core]
[   43.177505]  rmi_function_probe+0x25/0x30 [rmi_core]
[   43.177507]  driver_probe_device+0x310/0x480
[   43.177509]  __device_attach_driver+0x86/0x100
[   43.177511]  ? __driver_attach+0xf0/0xf0
[   43.177512]  bus_for_each_drv+0x6b/0xb0
[   43.177514]  __device_attach+0xdd/0x160
[   43.177516]  device_initial_probe+0x13/0x20
[   43.177518]  bus_probe_device+0x95/0xa0
[   43.177519]  device_add+0x44b/0x680
[   43.177522]  rmi_register_function+0x62/0xd0 [rmi_core]
[   43.177525]  rmi_create_function+0x112/0x1a0 [rmi_core]
[   43.177527]  ? rmi_driver_clear_irq_bits+0xc0/0xc0 [rmi_core]
[   43.177530]  rmi_scan_pdt+0xca/0x1a0 [rmi_core]
[   43.177535]  rmi_init_functions+0x5b/0x120 [rmi_core]
[   43.177537]  rmi_driver_probe+0x152/0x3c0 [rmi_core]
[   43.177547]  ? sysfs_create_link+0x25/0x40
[   43.177549]  driver_probe_device+0x310/0x480
[   43.177551]  __device_attach_driver+0x86/0x100
[   43.177553]  ? __driver_attach+0xf0/0xf0
[   43.177554]  bus_for_each_drv+0x6b/0xb0
[   43.177556]  __device_attach+0xdd/0x160
[   43.177558]  device_initial_probe+0x13/0x20
[   43.177560]  bus_probe_device+0x95/0xa0
[   43.177561]  device_add+0x44b/0x680
[   43.177564]  rmi_register_transport_device+0x84/0x100 [rmi_core]
[   43.177568]  rmi_input_configured+0xbf/0x1a0 [hid_rmi]
[   43.177571]  ? input_allocate_device+0xdf/0xf0
[   43.177574]  hidinput_connect+0x4a9/0x37a0 [hid]
[   43.177578]  hid_connect+0x326/0x3d0 [hid]
[   43.177581]  hid_hw_start+0x42/0x70 [hid]
[   43.177583]  rmi_probe+0x115/0x510 [hid_rmi]
[   43.177586]  hid_device_probe+0xd3/0x150 [hid]
[   

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix memory leak in intel_hdcp auth

[Jani Nikula]

On Tue, 03 Apr 2018, Radhakrishna Sripada  
wrote:
> Static code analysis tool reported memory leak in
> intel_hdcp_auth_downstream. Fixing the memory leak.
>
> Cc: Anusha Srivatsa 
> Signed-off-by: Radhakrishna Sripada 
> ---
>  drivers/gpu/drm/i915/intel_hdcp.c | 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 14ca5d3057a7..ce771f6c1a5a 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -186,14 +186,18 @@ int intel_hdcp_auth_downstream(struct 
> intel_digital_port *intel_dig_port,
>   return -ENOMEM;
>  
>   ret = shim->read_ksv_fifo(intel_dig_port, num_downstream, ksv_fifo);
> - if (ret)
> + if (ret) {
> + kfree(ksv_fifo);

Please add an single cleanup label and goto it from all error paths.

BR,
Jani.


>   return ret;
> + }
>  
>   /* Process V' values from the receiver */
>   for (i = 0; i < DRM_HDCP_V_PRIME_NUM_PARTS; i++) {
>   ret = shim->read_v_prime_part(intel_dig_port, i, );
> - if (ret)
> + if (ret) {
> + kfree(ksv_fifo);
>   return ret;
> + }
>   I915_WRITE(HDCP_SHA_V_PRIME(i), vprime);
>   }
>  
> @@ -222,8 +226,10 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
> *intel_dig_port,
>   sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
>  
>   ret = intel_write_sha_text(dev_priv, sha_text);
> - if (ret < 0)
> + if (ret < 0) {
> + kfree(ksv_fifo);
>   return ret;
> + }
>  
>   /* Programming guide writes this every 64 bytes */
>   sha_idx += sizeof(sha_text);
> @@ -245,13 +251,18 @@ int intel_hdcp_auth_downstream(struct 
> intel_digital_port *intel_dig_port,
>   continue;
>  
>   ret = intel_write_sha_text(dev_priv, sha_text);
> - if (ret < 0)
> + if (ret < 0) {
> + kfree(ksv_fifo);
>   return ret;
> + }
> +
>   sha_leftovers = 0;
>   sha_text = 0;
>   sha_idx += sizeof(sha_text);
>   }
>  
> + kfree(ksv_fifo);
> +
>   /*
>* We need to write BINFO/BSTATUS, and M0 now. Depending on how many
>* bytes are leftover from the last ksv, we might be able to fit them

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

Re: [Intel-gfx] [PATCH v4 5/5] i915: add documentation to intel_engine_cs

[Jani Nikula]

On Wed, 04 Apr 2018, Joonas Lahtinen  wrote:
> To be perfectly clear: Are we working towards a clean make htmldocs and
> CI nagging when it gets broken?

I'd like that to be the goal, yes. I'm not sure if anyone's working
towards that.

BR,
Jani.


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value

[Patchwork]

== Series Details ==

Series: drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value
URL   : https://patchwork.freedesktop.org/series/41130/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-random:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-cur-indfb-draw-mmap-gtt:
skip   -> PASS   (shard-hsw)
Subgroup fbc-2p-scndscrn-cur-indfb-draw-mmap-wc:
skip   -> PASS   (shard-hsw)
Subgroup fbc-2p-scndscrn-indfb-plflip-blt:
skip   -> PASS   (shard-hsw)

 Known issues:

Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060 +1
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-pgflip-blt:
pass   -> DMESG-FAIL (shard-apl) fdo#105685
Test kms_vblank:
Subgroup pipe-c-query-forked-busy:
dmesg-warn -> PASS   (shard-hsw) fdo#102614

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#105685 https://bugs.freedesktop.org/show_bug.cgi?id=105685
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614

shard-apltotal:3498 pass:1834 dwarn:1   dfail:1   fail:7   skip:1655 
time:12930s
shard-hswtotal:3498 pass:1783 dwarn:1   dfail:0   fail:3   skip:1710 
time:11523s
shard-snbtotal:3498 pass:1377 dwarn:1   dfail:0   fail:2   skip:2118 
time:7073s
Blacklisted hosts:
shard-kbltotal:3480 pass:1944 dwarn:1   dfail:0   fail:6   skip:1528 
time:9046s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: throw __must_check at GEM_WARN_ON

[Matthew Auld]

GEM_WARN_ON is intended to be used as:

if (GEM_WARN_ON(expr))
...

However this isn't clear since we just wrap WARN_ON, therefore throw a
warning if the result is ignored. For !DRM_I915_DEBUG_GEM builds this
should already be the case.

Suggested-by: Jani Nikula 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index 8922344fc21b..760671119130 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -36,7 +36,14 @@
BUG(); \
} \
} while(0)
-#define GEM_WARN_ON(expr) WARN_ON(expr)
+
+static __always_inline bool __must_check __gem_warn_on(bool v)
+{
+   return WARN_ON(v);
+}
+
+/* To be used as: if (GEM_WARN_ON(expr)) */
+#define GEM_WARN_ON(expr) __gem_warn_on(expr)
 
 #define GEM_DEBUG_DECL(var) var
 #define GEM_DEBUG_EXEC(expr) expr
-- 
2.14.3

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Add basic sanitychecks for execlists (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Add basic sanitychecks for execlists (rev2)
URL   : https://patchwork.freedesktop.org/series/40805/
State : success

== Summary ==

 Possible new issues:

Test kms_cursor_crc:
Subgroup cursor-64x64-random:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-2p-scndscrn-cur-indfb-draw-mmap-gtt:
skip   -> PASS   (shard-hsw)
Subgroup fbc-2p-scndscrn-cur-indfb-draw-mmap-wc:
skip   -> PASS   (shard-hsw)
Subgroup fbc-2p-scndscrn-indfb-plflip-blt:
skip   -> PASS   (shard-hsw)

 Known issues:

Test kms_cursor_legacy:
Subgroup flip-vs-cursor-toggle:
pass   -> FAIL   (shard-hsw) fdo#102670 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_vblank:
Subgroup pipe-c-query-forked-busy:
dmesg-warn -> PASS   (shard-hsw) fdo#102614

fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614

shard-apltotal:3499 pass:1836 dwarn:1   dfail:0   fail:6   skip:1655 
time:12949s
shard-hswtotal:3499 pass:1784 dwarn:1   dfail:0   fail:3   skip:1710 
time:11532s
shard-snbtotal:3499 pass:1378 dwarn:1   dfail:0   fail:2   skip:2118 
time:7035s
Blacklisted hosts:
shard-kbltotal:3499 pass:1941 dwarn:21  dfail:1   fail:8   skip:1528 
time:9387s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value

[Patchwork]

== Series Details ==

Series: drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value
URL   : https://patchwork.freedesktop.org/series/41130/
State : success

== Summary ==

Series 41130v1 drm/i915: Do no use kfree() to free a kmem_cache_alloc() return 
value
https://patchwork.freedesktop.org/api/1.0/series/41130/revisions/1/mbox/

 Possible new issues:

Test gem_exec_gttfill:
Subgroup basic:
skip   -> PASS   (fi-pnv-d510)

 Known issues:

Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
fail   -> PASS   (fi-skl-guc) fdo#103191

fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:538s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:522s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:509s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:511s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:592s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:425s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:316s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:285  pass:259  dwarn:1   dfail:0   fail:1   skip:24  
time:477s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:512s
fi-pnv-d510  total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:665s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:438s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:433s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:565s
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:407s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:536s

1c1f24f54234a760e02c8aac04a5714ae63fa2f0 drm-tip: 2018y-04m-04d-08h-24m-53s UTC 
integration manifest
89b0fef5317c drm/i915: Do no use kfree() to free a kmem_cache_alloc() return 
value

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 5/5] i915: add documentation to intel_engine_cs

[Joonas Lahtinen]

Quoting Jani Nikula (2018-04-04 12:48:55)
> On Wed, 04 Apr 2018, Joonas Lahtinen  wrote:
> > + Jani for Sphinx
> >
> > Quoting Rogovin, Kevin (2018-04-03 17:34:49)
> >> I am somewhat tempted to just drop this patch or add more documentation. 
> >> The function pointers are used in the code common
> >> to the legacy way and LRC way of submitting batchbuffers to the GPU, so 
> >> they should have somekind of contract to what they are
> >> supposed to do... but spelling out that contract might be a bit much...
> >> 
> >> Opinions?
> >
> > No big feelings to either direction, you could add a documentation block
> > for the flow nearby.
> >
> > If the struct members are referred to from documentation blocks, how far
> > are we from generating warnings if a patch renames something that
> > becomes non-existent in .rst or documentation block? (this one for Jani)
> 
> So first of all, the comments here are not kernel-doc comments, just
> regular comments. It's just free text.
> 
> If you want them to be kernel-doc comments, included to some fancy
> generated documentation, you'll have to follow the guide at [1], wrap
> them in /** and */ and add the @member: tag at the start.
> 
> Specifically, struct::member is not a thing. If you want to reference
> documented struct members in kernel-doc comments, you'll need to use
> _name->member or _name.member.

That was known, but thanks for reminding. What I was weighing was what's the
likelihood of noticing if some struct members get renamed in a patch and
the documentation breaks.

To be perfectly clear: Are we working towards a clean make htmldocs and
CI nagging when it gets broken?

Regards, Joonas

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

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

[Joonas Lahtinen]

Quoting Matthew Auld (2018-04-04 13:05:23)
> On 4 April 2018 at 10:13, Joonas Lahtinen
>  wrote:
> > Quoting Jani Nikula (2018-03-19 22:21:31)
> >> On Mon, 19 Mar 2018, Matthew Auld  wrote:
> >> > On 19 March 2018 at 18:17, Chris Wilson  wrote:
> >> >> Quoting Matthew Auld (2018-03-19 18:08:54)
> >> >>> GEM_WARN_ON() was originally intended to be used only as:
> >> >>>
> >> >>>if (GEM_WARN_ON(expr))
> >> >>> ...
> >> >>>
> >> >>> but it just so happens to also work as simply:
> >> >>>
> >> >>>GEM_WARN_ON(expr);
> >> >>>
> >> >>> since it just wraps WARN_ON, which is a little misleading since for
> >> >>> !DRM_I915_DEBUG_GEM builds the second case will actually break the
> >> >>> build. Given that there are some patches floating around which seem to
> >> >>> miss this, it probably makes sense to just make it work for both cases.
> >> >>
> >> >> That really was quite intentional. The only time to use GEM_WARN_ON() is
> >> >> inside an if, otherwise what's the point?
> >> >
> >> > Why wouldn't we want it to behave like WARN_ON? That seems to be what
> >> > people expect, since it does wrap WARN_ON, and we don't always use
> >> > WARN_ON in an if...
> >>
> >> Looking at this, I'm more baffled by GEM_WARN_ON() evaluating to expr on
> >> CONFIG_DRM_I915_DEBUG_GEM=y and 0 otherwise. That's the seriously
> >> misleading part here.
> >>
> >> Are you sure all those if (GEM_WARN_ON(expr)) are to be ignored? I'm no
> >> expert on gem code, but I could be easily persuaded to believe not.
> >>
> >>
> >> BR,
> >> Jani.
> >>
> >> PS. On the original question, if you design GEM_WARN_ON() to be used
> >> within if conditions only, I think you better squeeze in an inline
> >> function with __must_check.
> >
> > Did somebody write a patch for this?
> 
> So just something like:
> 
> inline static bool __must_check __gem_warn_on(bool v)
> {

I wonder if all  GCC versions are smart enough to eliminate code
(if we make this force_inline):

if (!CONFIG_I915_DEBUG_GEM)
return false;

> return WARN_ON(v);
> }

Regards, Joonas

> 
> #define GEM_WARN_ON(expr) __gem_warn_on(expr)
> 
> ?
___
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/selftests: Add basic sanitychecks for execlists (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Add basic sanitychecks for execlists (rev2)
URL   : https://patchwork.freedesktop.org/series/40805/
State : success

== Summary ==

Series 40805v2 drm/i915/selftests: Add basic sanitychecks for execlists
https://patchwork.freedesktop.org/api/1.0/series/40805/revisions/2/mbox/

 Known issues:

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
fail   -> PASS   (fi-skl-guc) fdo#103191
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-bdw-gvtdvmtotal:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  
time:535s
fi-bwr-2160  total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 
time:297s
fi-bxt-dsi   total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  
time:519s
fi-bxt-j4205 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:515s
fi-byt-j1900 total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  
time:518s
fi-byt-n2820 total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  
time:510s
fi-cfl-8700k total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
fi-cfl-s3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-cfl-u total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-cnl-y3total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  
time:586s
fi-elk-e7500 total:285  pass:225  dwarn:1   dfail:0   fail:0   skip:59  
time:431s
fi-gdg-551   total:285  pass:176  dwarn:0   dfail:0   fail:1   skip:108 
time:320s
fi-glk-1 total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-glk-j4005 total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-hsw-4770  total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-ilk-650   total:285  pass:224  dwarn:0   dfail:0   fail:1   skip:60  
time:427s
fi-ivb-3520m total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-ivb-3770  total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  
time:478s
fi-kbl-7567u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-kbl-r total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6260u total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-skl-6700k2total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-guc   total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  
time:431s
fi-skl-gvtdvmtotal:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:242  pass:208  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  
time:403s
Blacklisted hosts:
fi-cnl-psr   total:285  pass:256  dwarn:3   dfail:0   fail:0   skip:26  
time:541s

1c1f24f54234a760e02c8aac04a5714ae63fa2f0 drm-tip: 2018y-04m-04d-08h-24m-53s UTC 
integration manifest
01ee222b6651 drm/i915/selftests: Add basic sanitychecks for execlists

== Logs ==

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_eio: Add reset and unwedge stress testing

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-04-04 10:58:14)
> 
> On 03/04/2018 19:34, Antonio Argenziano wrote:
> > 
> > 
> > On 03/04/18 11:24, Antonio Argenziano wrote:
> >>
> >>
> >> On 03/04/18 04:36, Tvrtko Ursulin wrote:
> >>> From: Tvrtko Ursulin 
> >>>
> >>> Reset and unwedge stress testing is supposed to trigger wedging or 
> >>> resets
> >>> at incovenient times and then re-use the context so either the 
> >>> context or
> >>> driver tracking might get confused and break.
> >>>
> >>> v2:
> >>>   * Renamed for more sensible naming.
> >>>   * Added some comments to explain what the test is doing. (Chris 
> >>> Wilson)
> >>>
> >>> Signed-off-by: Tvrtko Ursulin 
> >>> ---
> >>>   tests/gem_eio.c | 74 
> >>> +
> >>>   1 file changed, 74 insertions(+)
> >>>
> >>> diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> >>> index b7c5047f0816..9599e73db736 100644
> >>> --- a/tests/gem_eio.c
> >>> +++ b/tests/gem_eio.c
> >>> @@ -591,6 +591,74 @@ static void test_inflight_internal(int fd, 
> >>> unsigned int wait)
> >>>   close(fd);
> >>>   }
> >>> +/*
> >>> + * Verify that we can submit and execute work after unwedging the GPU.
> >>> + */
> >>> +static void test_reset_stress(int fd, unsigned int flags)
> >>> +{
> >>> +    uint32_t ctx0 = gem_context_create(fd);
> >>> +
> >>> +    igt_until_timeout(5) {
> >>> +    struct drm_i915_gem_execbuffer2 execbuf = { };
> >>> +    struct drm_i915_gem_exec_object2 obj = { };
> >>> +    uint32_t bbe = MI_BATCH_BUFFER_END;
> >>> +    igt_spin_t *hang;
> >>> +    unsigned int i;
> >>> +    uint32_t ctx;
> >>> +
> >>> +    gem_quiescent_gpu(fd);
> >>> +
> >>> +    igt_require(i915_reset_control(flags & TEST_WEDGE ?
> >>> +   false : true));
> >>> +
> >>> +    ctx = context_create_safe(fd);
> >>> +
> >>> +    /*
> >>> + * Start executing a spin batch with some queued batches
> >>> + * against a different context after it.
> >>> + */
> >>
> >> Aren't all batches queued on ctx0? Or is this a reference to the check 
> >> on ctx you have later in the test.
> 
> Yes, a mistake in comment text.
> 
> >>> +    hang = spin_sync(fd, ctx0, 0);
> > 
> > I think you meant to send this^ on ctx.
> 
> Why do you think so? Did you find a different or better way to trigger 
> the bug this test is trying to hit?

You might need to explain that this test was trying to reproduce a
kernel bug around unwedging you found earlier, and instead managed to
find a similar one. ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

[Matthew Auld]

On 4 April 2018 at 10:13, Joonas Lahtinen
 wrote:
> Quoting Jani Nikula (2018-03-19 22:21:31)
>> On Mon, 19 Mar 2018, Matthew Auld  wrote:
>> > On 19 March 2018 at 18:17, Chris Wilson  wrote:
>> >> Quoting Matthew Auld (2018-03-19 18:08:54)
>> >>> GEM_WARN_ON() was originally intended to be used only as:
>> >>>
>> >>>if (GEM_WARN_ON(expr))
>> >>> ...
>> >>>
>> >>> but it just so happens to also work as simply:
>> >>>
>> >>>GEM_WARN_ON(expr);
>> >>>
>> >>> since it just wraps WARN_ON, which is a little misleading since for
>> >>> !DRM_I915_DEBUG_GEM builds the second case will actually break the
>> >>> build. Given that there are some patches floating around which seem to
>> >>> miss this, it probably makes sense to just make it work for both cases.
>> >>
>> >> That really was quite intentional. The only time to use GEM_WARN_ON() is
>> >> inside an if, otherwise what's the point?
>> >
>> > Why wouldn't we want it to behave like WARN_ON? That seems to be what
>> > people expect, since it does wrap WARN_ON, and we don't always use
>> > WARN_ON in an if...
>>
>> Looking at this, I'm more baffled by GEM_WARN_ON() evaluating to expr on
>> CONFIG_DRM_I915_DEBUG_GEM=y and 0 otherwise. That's the seriously
>> misleading part here.
>>
>> Are you sure all those if (GEM_WARN_ON(expr)) are to be ignored? I'm no
>> expert on gem code, but I could be easily persuaded to believe not.
>>
>>
>> BR,
>> Jani.
>>
>> PS. On the original question, if you design GEM_WARN_ON() to be used
>> within if conditions only, I think you better squeeze in an inline
>> function with __must_check.
>
> Did somebody write a patch for this?

So just something like:

inline static bool __must_check __gem_warn_on(bool v)
{
return WARN_ON(v);
}

#define GEM_WARN_ON(expr) __gem_warn_on(expr)

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 2/2] tests/gem_eio: Add reset and unwedge stress testing

[Tvrtko Ursulin]

On 03/04/2018 19:34, Antonio Argenziano wrote:



On 03/04/18 11:24, Antonio Argenziano wrote:



On 03/04/18 04:36, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Reset and unwedge stress testing is supposed to trigger wedging or 
resets
at incovenient times and then re-use the context so either the 
context or

driver tracking might get confused and break.

v2:
  * Renamed for more sensible naming.
  * Added some comments to explain what the test is doing. (Chris 
Wilson)


Signed-off-by: Tvrtko Ursulin 
---
  tests/gem_eio.c | 74 
+

  1 file changed, 74 insertions(+)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index b7c5047f0816..9599e73db736 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -591,6 +591,74 @@ static void test_inflight_internal(int fd, 
unsigned int wait)

  close(fd);
  }
+/*
+ * Verify that we can submit and execute work after unwedging the GPU.
+ */
+static void test_reset_stress(int fd, unsigned int flags)
+{
+    uint32_t ctx0 = gem_context_create(fd);
+
+    igt_until_timeout(5) {
+    struct drm_i915_gem_execbuffer2 execbuf = { };
+    struct drm_i915_gem_exec_object2 obj = { };
+    uint32_t bbe = MI_BATCH_BUFFER_END;
+    igt_spin_t *hang;
+    unsigned int i;
+    uint32_t ctx;
+
+    gem_quiescent_gpu(fd);
+
+    igt_require(i915_reset_control(flags & TEST_WEDGE ?
+   false : true));
+
+    ctx = context_create_safe(fd);
+
+    /*
+ * Start executing a spin batch with some queued batches
+ * against a different context after it.
+ */


Aren't all batches queued on ctx0? Or is this a reference to the check 
on ctx you have later in the test.


Yes, a mistake in comment text.


+    hang = spin_sync(fd, ctx0, 0);


I think you meant to send this^ on ctx.


Why do you think so? Did you find a different or better way to trigger 
the bug this test is trying to hit?


Regards,

Tvrtko


Antonio.


+
+    obj.handle = gem_create(fd, 4096);
+    gem_write(fd, obj.handle, 0, , sizeof(bbe));
+
+    execbuf.buffers_ptr = to_user_pointer();
+    execbuf.buffer_count = 1;
+    execbuf.rsvd1 = ctx0;
+
+    for (i = 0; i < 10; i++)
+    gem_execbuf(fd, );
+
+    /* Wedge after a small delay. */
+    igt_assert_eq(__check_wait(fd, obj.handle, 100e3), 0);
+
+    /* Unwedge by forcing a reset. */
+    igt_assert(i915_reset_control(true));
+    trigger_reset(fd);
+
+    gem_quiescent_gpu(fd);
+
+    /*
+ * Verify that we are able to submit work after unwedging from
+ * both contexts.
+ */
+    execbuf.rsvd1 = ctx;
+    for (i = 0; i < 5; i++)
+    gem_execbuf(fd, );
+
+    execbuf.rsvd1 = ctx0;
+    for (i = 0; i < 5; i++)
+    gem_execbuf(fd, );
+
+    gem_sync(fd, obj.handle);
+    igt_spin_batch_free(fd, hang);
+    gem_context_destroy(fd, ctx);
+    gem_close(fd, obj.handle);
+    }
+
+    gem_context_destroy(fd, ctx0);
+}
+
  static int fd = -1;
  static void
@@ -635,6 +703,12 @@ igt_main
  igt_subtest("in-flight-suspend")
  test_inflight_suspend(fd);
+    igt_subtest("reset-stress")
+    test_reset_stress(fd, 0);
+
+    igt_subtest("unwedge-stress")
+    test_reset_stress(fd, TEST_WEDGE);
+
  igt_subtest_group {
  const struct {
  unsigned int wait;


___
igt-dev mailing list
igt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

___
igt-dev mailing list
igt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

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