[Intel-gfx] ✓ Fi.CI.IGT: success for tests/psr: Dump PSR debugfs contents if PSR entry times out. (rev2)

[Patchwork]

== Series Details ==

Series: tests/psr: Dump PSR debugfs contents if PSR entry times out. (rev2)
URL   : https://patchwork.freedesktop.org/series/35254/
State : success

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-hsw) fdo#104218
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +2

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

shard-hswtotal:2689 pass:1523 dwarn:1   dfail:0   fail:10  skip:1154 
time:8933s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8027s
Blacklisted hosts:
shard-apltotal:2690 pass:1664 dwarn:1   dfail:0   fail:23  skip:1001 
time:13314s
shard-kbltotal:2712 pass:1807 dwarn:1   dfail:0   fail:24  skip:880 
time:0s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/psr: Fix register name mess up.

[Dhinakaran Pandiyan]

On Tuesday, December 19, 2017 8:35:20 PM PST Dhinakaran Pandiyan wrote:
> Commit 77affa31722b ("drm/i915/psr: Fix compiler warnings for
> hsw_psr_disable()") swapped status and control registers while fixing
> indentation. The _ctl at the end of the status register name must have to
> led to this.
> 
> Cc: Chris Wilson 
> Cc: Rodrigo Vivi 
Fixes: 77affa31722b ("drm/i915/psr: Fix compiler warnings for 
hsw_psr_disable()")
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c index 095e0a5a8574..863650366425 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -580,7 +580,7 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
>   struct drm_i915_private *dev_priv = to_i915(dev);
> 
>   if (dev_priv->psr.active) {
> - i915_reg_t psr_ctl;
> + i915_reg_t psr_status;
>   u32 psr_status_mask;
> 
>   if (dev_priv->psr.aux_frame_sync)
> @@ -589,24 +589,24 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
> 0);
> 
>   if (dev_priv->psr.psr2_support) {
> - psr_ctl = EDP_PSR2_CTL;
> + psr_status = EDP_PSR2_STATUS_CTL;
>   psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> 
> - I915_WRITE(psr_ctl,
> -I915_READ(psr_ctl) &
> + I915_WRITE(EDP_PSR2_CTL,
> +I915_READ(EDP_PSR2_CTL) &
>  ~(EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE));
> 
>   } else {
> - psr_ctl = EDP_PSR_STATUS_CTL;
> + psr_status = EDP_PSR_STATUS_CTL;
>   psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
> 
> - I915_WRITE(psr_ctl,
> -I915_READ(psr_ctl) & ~EDP_PSR_ENABLE);
> + I915_WRITE(EDP_PSR_CTL,
> +I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
>   }
> 
>   /* Wait till PSR is idle */
>   if (intel_wait_for_register(dev_priv,
> - psr_ctl, psr_status_mask, 0,
> + psr_status, psr_status_mask, 0,
>   2000))
>   DRM_ERROR("Timed out waiting for PSR Idle State\n");


___
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/psr: Fix register name mess up.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Fix register name mess up.
URL   : https://patchwork.freedesktop.org/series/35607/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +1

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

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:10  skip:1164 
time:9417s
shard-snbtotal:2712 pass:1310 dwarn:1   dfail:0   fail:10  skip:1391 
time:8095s
Blacklisted hosts:
shard-apltotal:2712 pass:1688 dwarn:1   dfail:0   fail:22  skip:1001 
time:13807s
shard-kbltotal:2640 pass:1740 dwarn:27  dfail:1   fail:24  skip:847 
time:10817s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7544/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 tests/psr: Dump PSR debugfs contents if PSR entry times out. (rev2)

[Patchwork]

== Series Details ==

Series: tests/psr: Dump PSR debugfs contents if PSR entry times out. (rev2)
URL   : https://patchwork.freedesktop.org/series/35254/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3551
e27ee23e076d drm-tip: 2017y-12m-19d-23h-07m-26s UTC integration manifest

No testlist changes.

Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:503s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:268s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:411s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:435s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:527s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:525s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:498s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:555s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:421s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:625s

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add YCBCR 4:2:0 support for LSPCON

[Sharma, Shashank]

Thanks for the review Maarten,

My comments inline.

Regards
Shashank
On 12/19/2017 12:53 AM, Maarten Lankhorst wrote:

Op 14-11-17 om 16:17 schreef Shashank Sharma:

LSPCON chips are capable of generating YCBCR 4:2:0 outputs, if asked
nicely :). In order to generate YCBCR 4:2:0 outputs, a source must:
- send YCBCR 4:4:4 signals to LSPCON
- program color space as 4:2:0 in AVI infoframes

This will indicate LSPCON FW to start scaling down from YCBCR 4:4:4
and generate YCBCR 4:2:0 output. Unlike HDMI 2.0 native case, as the
scaling is done by LSPCON device, we need not to reserve a scaler for
4:2:0 outputs.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
  drivers/gpu/drm/i915/intel_ddi.c |  8 
  drivers/gpu/drm/i915/intel_display.c | 15 +++
  drivers/gpu/drm/i915/intel_dp.c  |  7 ++-
  drivers/gpu/drm/i915/intel_drv.h |  2 ++
  drivers/gpu/drm/i915/intel_lspcon.c  | 22 ++
  6 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f0f8f60..ea6ef5e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8495,6 +8495,8 @@ enum skl_power_gate {
  #define TRANS_MSA_MISC(tran) _MMIO_TRANS2(tran, _TRANSA_MSA_MISC)
  
  #define  TRANS_MSA_SYNC_CLK		(1<<0)

+#define  TRANS_MSA_SAMPLING_444(2<<1)
+#define  TRANS_MSA_CLRSP_YCBCR (2<<3)
  #define  TRANS_MSA_6_BPC  (0<<5)
  #define  TRANS_MSA_8_BPC  (1<<5)
  #define  TRANS_MSA_10_BPC (2<<5)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9e2ab02..3fd839d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1499,6 +1499,14 @@ void intel_ddi_set_pipe_settings(const struct 
intel_crtc_state *crtc_state)
break;
}
  
+	/*

+* To get YCBCR 420 output from LSPCON, we should send YCBCR 444
+* signals. And as per DP 1.2 spec section 2.3.4.3 while sending
+* YCBCR 444 signals we should program MSA MISC1/0 fields with
+* colorspace information.
+*/
+   if (crtc_state->lspcon_active && crtc_state->ycbcr420)
+   temp |= TRANS_MSA_SAMPLING_444 | TRANS_MSA_CLRSP_YCBCR;
I915_WRITE(TRANS_MSA_MISC(cpu_transcoder), temp);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 737de25..787119b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4638,7 +4638,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 */
need_scaling = src_w != dst_w || src_h != dst_h;
  
-	if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)

+   if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX &&
+   !crtc_state->lspcon_active)
need_scaling = true;
  
  	/*

@@ -8133,9 +8134,15 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
  
  		if (config->ycbcr420) {

-   val |= PIPEMISC_OUTPUT_COLORSPACE_YUV |
-   PIPEMISC_YUV420_ENABLE |
-   PIPEMISC_YUV420_MODE_FULL_BLEND;
+   val |= PIPEMISC_OUTPUT_COLORSPACE_YUV;
+   /*
+* LSPCON doesn't need scaling/blending to be done in
+* pipe. It just needs YCBCR444 input and proper AVI
+* infoframes for 4:2:0 output enabling.
+*/
+   if (!config->lspcon_active)
+   val |= PIPEMISC_YUV420_ENABLE |
+  PIPEMISC_YUV420_MODE_FULL_BLEND;
}
  
  		I915_WRITE(PIPEMISC(intel_crtc->pipe), val);

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fa9e5e6..1d4b669 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1657,8 +1657,13 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_dp->max_link_rate);
  
  	/* LSPCON needs special handling to drive YCBCR420 outputs */

-   if (lspcon->active)
+   if (lspcon->active) {
+   struct drm_connector *connector = _connector->base;
+
pipe_config->lspcon_active = true;
+   pipe_config->ycbcr420 = lspcon_ycbcr420_config(connector,
+  pipe_config);
+   }
  
  	/* No common link rates between source and sink */

WARN_ON(common_len <= 0);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a468dd6..f271967 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ 

[Intel-gfx] [PATCH i-g-t v2] tests/psr: Dump PSR debugfs contents if PSR entry times out.

[Dhinakaran Pandiyan]

(kms_psr_sink_crc:1717) CRITICAL: Failed assertion:
wait_psr_entry()
(kms_psr_sink_crc:1717) CRITICAL: Last errno: 25, Inappropriate ioctl
for device

isn't very useful, the "Enabled" field would have indicated that the
requirements to enable PSR weren't met in this case.

v2: s/Source_OK/Enabled in commit message.(Rodrigo)

Cc: Rodrigo Vivi 
Acked-by: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 tests/kms_psr_sink_crc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 831368b2..c586d6e1 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -223,6 +223,7 @@ static bool wait_psr_entry(data_t *data)
return true;
sleep(1);
}
+   igt_debugfs_dump(data->drm_fd, "i915_edp_psr_status");
return false;
 }
 
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Fix register name mess up.

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Fix register name mess up.
URL   : https://patchwork.freedesktop.org/series/35607/
State : success

== Summary ==

Series 35607v1 drm/i915/psr: Fix register name mess up.
https://patchwork.freedesktop.org/api/1.0/series/35607/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
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-a:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:465s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:264s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:383s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:472s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:519s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:517s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:551s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:410s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:604s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:620s

e27ee23e076d5ac016fec87e3273be9cc91d9b20 drm-tip: 2017y-12m-19d-23h-07m-26s UTC 
integration manifest
48a2e41d0fb0 drm/i915/psr: Fix register name mess up.

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] tests/psr: Dump PSR debugfs contents if PSR entry times out.

[Dhinakaran Pandiyan]

On Tuesday, December 19, 2017 2:02:47 PM PST Rodrigo Vivi wrote:
> On Tue, Dec 12, 2017 at 10:28:35PM +, Dhinakaran Pandiyan wrote:
> > (kms_psr_sink_crc:1717) CRITICAL: Failed assertion:
> > wait_psr_entry()
> > (kms_psr_sink_crc:1717) CRITICAL: Last errno: 25, Inappropriate ioctl
> > for device
> > 
> > isn't very useful, the Source_OK field would have indicated that the
> > requirements to enable PSR weren't met in this case.
> 
> Is this still the case with the source_ok getting killed?

"Enabled:"  will do the same job, conveying whether an attempt to enable PSR 
was made.

> 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> > 
> >  tests/kms_psr_sink_crc.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> > index 831368b2..c586d6e1 100644
> > --- a/tests/kms_psr_sink_crc.c
> > +++ b/tests/kms_psr_sink_crc.c
> > @@ -223,6 +223,7 @@ static bool wait_psr_entry(data_t *data)
> > 
> > return true;
> > 
> > sleep(1);
> > 
> > }
> > 
> > +   igt_debugfs_dump(data->drm_fd, "i915_edp_psr_status");
> 
> anyways seems a good thing to have...
> so, with the commit message modified feel free to use:
> 
> Acked-by: Rodrigo Vivi 
>

Thanks!
 
> > return false;
> >  
> >  }
> 
> ___
> 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 4/5] drm/i915: Write AVI infoframes for Parade LSPCON

[Sharma, Shashank]

Thanks for the review, David.

My comments, inline.


Regards

Shashank


On 12/19/2017 3:43 PM, David Weinehall wrote:

On Mon, Dec 18, 2017 at 08:15:30PM +0100, Maarten Lankhorst wrote:

Op 14-11-17 om 16:17 schreef 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.

Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/i915/intel_lspcon.c | 119 +++-
  1 file changed, 118 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 1ac4c47..77f0687 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 =
@@ -241,6 +247,113 @@ 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++) {
+

Remove this newline.

Why ? this is not accidental.

+   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) {
+

And this one.

Same as above.
- Shashank



+   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;
+   }
+
+   memcpy(_if[1], frame, len);
+
+

[Intel-gfx] [PATCH] drm/i915/psr: Fix register name mess up.

[Dhinakaran Pandiyan]

Commit 77affa31722b ("drm/i915/psr: Fix compiler warnings for
hsw_psr_disable()") swapped status and control registers while fixing
indentation. The _ctl at the end of the status register name must have to
led to this.

Cc: Chris Wilson 
Cc: Rodrigo Vivi 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 095e0a5a8574..863650366425 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -580,7 +580,7 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = to_i915(dev);
 
if (dev_priv->psr.active) {
-   i915_reg_t psr_ctl;
+   i915_reg_t psr_status;
u32 psr_status_mask;
 
if (dev_priv->psr.aux_frame_sync)
@@ -589,24 +589,24 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
0);
 
if (dev_priv->psr.psr2_support) {
-   psr_ctl = EDP_PSR2_CTL;
+   psr_status = EDP_PSR2_STATUS_CTL;
psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
 
-   I915_WRITE(psr_ctl,
-  I915_READ(psr_ctl) &
+   I915_WRITE(EDP_PSR2_CTL,
+  I915_READ(EDP_PSR2_CTL) &
   ~(EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE));
 
} else {
-   psr_ctl = EDP_PSR_STATUS_CTL;
+   psr_status = EDP_PSR_STATUS_CTL;
psr_status_mask = EDP_PSR_STATUS_STATE_MASK;
 
-   I915_WRITE(psr_ctl,
-  I915_READ(psr_ctl) & ~EDP_PSR_ENABLE);
+   I915_WRITE(EDP_PSR_CTL,
+  I915_READ(EDP_PSR_CTL) & ~EDP_PSR_ENABLE);
}
 
/* Wait till PSR is idle */
if (intel_wait_for_register(dev_priv,
-   psr_ctl, psr_status_mask, 0,
+   psr_status, psr_status_mask, 0,
2000))
DRM_ERROR("Timed out waiting for PSR Idle State\n");
 
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Reject CCS modifiers for pipe C on Geminilake

[Patchwork]

== Series Details ==

Series: i915: Reject CCS modifiers for pipe C on Geminilake
URL   : https://patchwork.freedesktop.org/series/35605/
State : success

== Summary ==

Test kms_flip:
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup vblank-vs-modeset-suspend:
pass   -> SKIP   (shard-snb) fdo#102365
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +2

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2712 pass:1536 dwarn:1   dfail:0   fail:11  skip:1164 
time:9397s
shard-snbtotal:2712 pass:1308 dwarn:1   dfail:0   fail:11  skip:1392 
time:8072s
Blacklisted hosts:
shard-apltotal:2712 pass:1688 dwarn:1   dfail:0   fail:22  skip:1001 
time:13961s
shard-kbltotal:2712 pass:1776 dwarn:34  dfail:0   fail:23  skip:879 
time:11069s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7543/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 i915: Reject CCS modifiers for pipe C on Geminilake

[Patchwork]

== Series Details ==

Series: i915: Reject CCS modifiers for pipe C on Geminilake
URL   : https://patchwork.freedesktop.org/series/35605/
State : success

== Summary ==

Series 35605v1 i915: Reject CCS modifiers for pipe C on Geminilake
https://patchwork.freedesktop.org/api/1.0/series/35605/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:502s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:274s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:482s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:261s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:524s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:523s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:552s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:441s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:591s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:634s
fi-ilk-650 failed to collect. IGT log at Patchwork_7543/fi-ilk-650/igt.log

e27ee23e076d5ac016fec87e3273be9cc91d9b20 drm-tip: 2017y-12m-19d-23h-07m-26s UTC 
integration manifest
8ce641ba0f9e i915: Reject CCS modifiers for pipe C on Geminilake

== Logs ==

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

[Intel-gfx] [PATCH] i915: Reject CCS modifiers for pipe C on Geminilake

[Gabriel Krisman Bertazi]

Current code advertises (on the modifiers blob property) support for CCS
modifier for pipe C on GLK, only to reject it later when validating the
request before the atomic commit.

This fixes the tests igt@kms_ccs@pipe-c-*, which should skip on GLK for
pipe C (see bug 104096).

A relevant discussion is archived at:

https://lists.freedesktop.org/archives/intel-gfx/2017-December/150646.html

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104096
Signed-off-by: Gabriel Krisman Bertazi 
Cc: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1f7e312d0d0d..a50a5986af52 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13265,7 +13265,7 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
primary->check_plane = intel_check_primary_plane;
 
-   if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+   if (INTEL_GEN(dev_priv) >= 10) {
intel_primary_formats = skl_primary_formats;
num_formats = ARRAY_SIZE(skl_primary_formats);
modifiers = skl_format_modifiers_ccs;
-- 
2.15.1

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid context dereference inside execlists_submission_tasklet

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid context dereference inside execlists_submission_tasklet
URL   : https://patchwork.freedesktop.org/series/35604/
State : failure

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-64x64-offscreen:
pass   -> SKIP   (shard-snb)
Test pm_rpm:
Subgroup basic-rte:
pass   -> SKIP   (shard-hsw)
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060 +1
Subgroup flip-vs-fences:
pass   -> INCOMPLETE (shard-hsw)
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2701 pass:1527 dwarn:1   dfail:0   fail:12  skip:1160 
time:9244s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:10  skip:1392 
time:8088s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 08:38:10PM +, Hans de Goede wrote:
> Hi,
> 
> On 19-12-17 20:42, Rodrigo Vivi wrote:
> > 
> > On Tue, Dec 19, 2017 at 07:21:13PM +, Hans de Goede wrote:
> > > At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
> > > shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
> > > colors, showing that the panel controller is starting with sampling the
> > > datastream somewhere mid-line. This happens after the first blanking and
> > > re-init of the panel.
> > > 
> > > After looking at drm.debug output I noticed that initially we inherit the
> > > cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
> > > KHz, which turns out to be the cause of this problem, a quick hack to hard
> > > code the cdclk to 33 KHz makes the problem go away.
> > > 
> > > I've tested this on various Bay Trail devices:
> > > -Chuwi Vi8: 800x1280, 33 at boot, requires 33 to work properly
> > > -GP-electronic T701: 1024x600, 33 at boot, works fine with 33
> > > -PEAQ C1010: 1920x1200, 33 at boot, works fine with 33
> > > -PoV mobii-wintab-800w: 800x1280, 33 at boot, works fine with 33
> > > -Asus Transformer-T100TA: 1368x768, 32 at boot, works fine with 32
> > 
> > and lower clock shift the image in all of them?
> 
> No, just on the Chuwi Vi8, the tests was to make sure the higher clock
> does not create problems elsewhere and I was curious what clock the GOP
> was using on other devices. Also hence the "requires 33 to work properly"
> vs "works fine with 33" in the list.
> 
> > > So it seems that the GOP is always using what vlv_calc_cdclk calls
> > > freq_320 as cdclk clock. Also note the comment in vlv_calc_cdclk about
> > > it avoiding 200 Mhz as clock because that causes issues in some cases.
> > > 
> > > This commit extends the "do not use 200 Mhz" workaround with an extra
> > > check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
> > > panel is active.
> > > 
> > > Signed-off-by: Hans de Goede 
> > > ---
> > >   drivers/gpu/drm/i915/intel_cdclk.c | 8 
> > >   1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> > > b/drivers/gpu/drm/i915/intel_cdclk.c
> > > index 9c5ceb98d48f..cfb3f7fb3e1c 100644
> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> > > @@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > intel_crtc_state *crtc_state)
> > >   if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
> > >   min_cdclk = max(2 * 96000, min_cdclk);
> > > + /*
> > > +  * On Valleyview the GOP always uses 32/33 KHz if DSI is used,
> > > +  * using a lower clock causes causes sync issues with some panels.
> > > +  */
> > 
> > Afaik (afai-have-noticed) GOP always use the higher freq and higher rates
> > that panels support with no care about saving any power. So I'm not sure if
> > that should be used as any sort of reference for us.
> > 
> > Note I'm not telling to not add the workaround itself...
> 
> So you're suggesting to change the comment into something like this
> instead ?  :
> 
> /*
>  * On Valleyview some DSI panels loose (v|h)sync when the clock is lower
>  * then 32KHz.
>  */

Yeap... something like that so we don't start counting GOP as the reference in 
the future ;)

> 
> > 
> > > + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> > > + IS_VALLEYVIEW(dev_priv))
> > > + min_cdclk = max(32, min_cdclk);
> > > +
> > >   if (min_cdclk > dev_priv->max_cdclk_freq) {
> > >   DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d 
> > > kHz)\n",
> > > min_cdclk, dev_priv->max_cdclk_freq);
> > > -- 
> > > 2.14.3
> > > 
> 
> Regards,
> 
> Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] lib/i915_pciids.h: synchronize with kernel header

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 10:07:30PM +, Chris Wilson wrote:
> Quoting Rodrigo Vivi (2017-12-19 21:59:43)
> > On Fri, Dec 08, 2017 at 10:06:46PM +, Lucas De Marchi wrote:
> > > This copies include/drm/i915_pciids.h from kernel as of drm-tip:
> > > drm-tip: 2017y-12m-08d-21h-06m-35s UTC + patch adding INTEL_CFL_IDS that
> > > was missing there[1].
> > 
> > Since this tip name is not easily found maybe it would be good to
> > mention latest kernel commit that touched this file.
> > 
> > > The goal is to keep track of the PCI IDs in a
> > > single place (kernel).
> > 
> > good idea.
> > 
> > > 
> > > Right now a simple copy is done to catch up with latest changes there,
> > > although in future it could be more sofisticated pointing the build
> > > system to the external header.
> > 
> > Yeap, a real single place would be awesome.
> 
> Whilst maintaining independence of the igt build itself?

yeap... nevermind...
I was just in another discussion about detection of cnl on vaapi driver
and I realized that the userspace individual detection has its advantages...

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

Re: [Intel-gfx] [PATCH] drm/i915: Avoid setting redundant INIT power domain mask for DC_OFF wells

[Pandiyan, Dhinakaran]

On Tue, 2017-12-19 at 14:01 -0800, Rodrigo Vivi wrote:
> On Tue, Dec 12, 2017 at 09:52:09PM +, Dhinakaran Pandiyan wrote:
> > The POWER_DOMAIN_INIT bit is already set in _POWERWELL_2_POWER_DOMAINS,
> > which is included in _DC_OFF_POWER_DOMAINS. So, avoid setting that again
> > in _DC_OFF_POWER_DOMAINS and shuffle the macros a bit to make it easy to
> > notice relation.
> > 
> > Cc: Imre Deak 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 20 
> >  1 file changed, 8 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 96ab74f3d101..eb4b12989c84 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -1706,11 +1706,10 @@ void intel_display_power_put(struct 
> > drm_i915_private *dev_priv,
> > BIT_ULL(POWER_DOMAIN_PORT_DDI_D_IO) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> >  #define SKL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > -   SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> > BIT_ULL(POWER_DOMAIN_MODESET) | \
> > BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > -   BIT_ULL(POWER_DOMAIN_INIT))
> > +   SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS)
> >  
> >  #define BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS (\
> > BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> > @@ -1728,12 +1727,6 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> > BIT_ULL(POWER_DOMAIN_VGA) | \
> > BIT_ULL(POWER_DOMAIN_GMBUS) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > -#define BXT_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > -   BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > -   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> > -   BIT_ULL(POWER_DOMAIN_MODESET) | \
> > -   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > -   BIT_ULL(POWER_DOMAIN_INIT))
> >  #define BXT_DPIO_CMN_A_POWER_DOMAINS ( \
> > BIT_ULL(POWER_DOMAIN_PORT_DDI_A_LANES) |\
> > BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > @@ -1744,6 +1737,11 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> > BIT_ULL(POWER_DOMAIN_AUX_B) |   \
> > BIT_ULL(POWER_DOMAIN_AUX_C) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > +#define BXT_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > +   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> > +   BIT_ULL(POWER_DOMAIN_MODESET) | \
> > +   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > +   BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS)
> 
> why did you move the entire block below?
> 
Because the DC_OFF domain is at the bottom for every other platform :)

> >  
> >  #define GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS (\
> > BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> > @@ -1788,11 +1786,10 @@ void intel_display_power_put(struct 
> > drm_i915_private *dev_priv,
> > BIT_ULL(POWER_DOMAIN_AUX_C) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> >  #define GLK_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > -   GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> > BIT_ULL(POWER_DOMAIN_MODESET) | \
> > BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > -   BIT_ULL(POWER_DOMAIN_INIT))
> > +   GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS)
> >  
> >  #define CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS (\
> > BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> > @@ -1836,10 +1833,9 @@ void intel_display_power_put(struct drm_i915_private 
> > *dev_priv,
> > BIT_ULL(POWER_DOMAIN_AUX_D) |   \
> > BIT_ULL(POWER_DOMAIN_INIT))
> >  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > -   CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> > BIT_ULL(POWER_DOMAIN_MODESET) | \
> > BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> > -   BIT_ULL(POWER_DOMAIN_INIT))
> > +   CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS)
> >  
> >  static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
> > .sync_hw = i9xx_power_well_sync_hw_noop,
> > -- 
> > 2.11.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for tests/gem_ctx_param: Update invalid param (rev2)

[Patchwork]

== Series Details ==

Series: tests/gem_ctx_param: Update invalid param (rev2)
URL   : https://patchwork.freedesktop.org/series/35438/
State : success

== Summary ==

Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test gem_ctx_param:
Subgroup invalid-param-get:
fail   -> PASS   (shard-snb) fdo#103107 +3
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-snb) fdo#103375
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103107 https://bugs.freedesktop.org/show_bug.cgi?id=103107
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2720 pass:1540 dwarn:1   dfail:0   fail:8   skip:1171 
time:9411s
shard-snbtotal:2720 pass:1311 dwarn:1   dfail:0   fail:9   skip:1399 
time:8061s
Blacklisted hosts:
shard-apltotal:2698 pass:1670 dwarn:1   dfail:0   fail:23  skip:1002 
time:13346s
shard-kbltotal:2673 pass:1764 dwarn:9   dfail:0   fail:23  skip:875 
time:10633s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Introduce a non-blocking power domain for vblank interrupts

[Pandiyan, Dhinakaran]

On Tue, 2017-12-19 at 13:41 -0800, Rodrigo Vivi wrote:
> On Tue, Dec 19, 2017 at 05:26:58AM +, Dhinakaran Pandiyan wrote:
> > When DC states are enabled and PSR is active, the hardware enters DC5/DC6
> > states resulting in frame counter resets. The frame counter resets mess
> > up the vblank counting logic. In order to disable DC states when
> > vblank interrupts are required and to disallow DC states when vblanks
> > interrupts are already enabled, introduce a new VBLANK power domain.
> > Since this power domain reference needs to be acquired and released in
> > atomic context, _vblank_get() and _vblank_put() methods skip the
> > power_domain mutex.
> > 
> > v2: Fix deadlock by switching irqsave spinlock.
> > Implement atomic version of get_if_enabled.
> > Modify power_domain_verify_state to check power well use count and
> > enabled status atomically.
> > Rewrite of intel_power_well_{get,put}
> > 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> 
> + Cc: Imre Deak 
> 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  18 
> >  drivers/gpu/drm/i915/intel_drv.h|   3 +
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 184 
> > +---
> >  3 files changed, 192 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index ddadeb9eaf49..db597c5ebaed 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -397,6 +397,7 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_AUX_C,
> > POWER_DOMAIN_AUX_D,
> > POWER_DOMAIN_GMBUS,
> > +   POWER_DOMAIN_VBLANK,
> > POWER_DOMAIN_MODESET,
> > POWER_DOMAIN_GT_IRQ,
> > POWER_DOMAIN_INIT,
> > @@ -1476,6 +1477,23 @@ struct i915_power_well {
> > bool has_fuses:1;
> > } hsw;
> > };
> > +
> > +   /* Lock to serialize access to count, hw_enabled and ops, used for
> > +* power wells that have supports_atomix_ctx set to True.
> > +*/
> > +   spinlock_t lock;
> > +
> > +   /* Indicates that the get/put methods for this power well can be called
> > +* in atomic contexts, requires .ops to not sleep. This is valid
> > +* only for the DC_OFF power well currently.
> > +*/
> > +   bool supports_atomic_ctx;
> > +
> > +   /* DC_OFF power well was disabled since the last time vblanks were
> > +* disabled.
> > +*/
> > +   bool dc_off_disabled;
> > +
> > const struct i915_power_well_ops *ops;
> >  };
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 48676e99316e..6822118f3c4d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1798,6 +1798,9 @@ bool intel_display_power_get_if_enabled(struct 
> > drm_i915_private *dev_priv,
> > enum intel_display_power_domain domain);
> >  void intel_display_power_put(struct drm_i915_private *dev_priv,
> >  enum intel_display_power_domain domain);
> > +void intel_display_power_vblank_get(struct drm_i915_private *dev_priv,
> > +   bool *needs_restore);
> > +void intel_display_power_vblank_put(struct drm_i915_private *dev_priv);
> >  
> >  static inline void
> >  assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 992caec1fbc4..fc6812ed6137 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -56,6 +56,19 @@ static struct i915_power_well *
> >  lookup_power_well(struct drm_i915_private *dev_priv,
> >   enum i915_power_well_id power_well_id);
> >  
> > +/* Optimize for the case when this is called from atomic contexts,
> > + * although the case is unlikely.
> > + */
> > +#define power_well_lock(power_well, flags) do {\
> > +   if (likely(power_well->supports_atomic_ctx))\
> 
> you mention unlikely on commend and call likely here, why?

It is unlikely that the power well is going to be DC_OFF, but we need to
optimize for that case as it can be called from atomic contexts.

> 
> > +   spin_lock_irqsave(_well->lock, flags);\
> > +   } while (0)
> > +
> > +#define power_well_unlock(power_well, flags) do {  \
> > +   if (likely(power_well->supports_atomic_ctx))\
> > +   spin_unlock_irqrestore(_well->lock, flags);   \
> > +   } while (0)
> > +
> >  const char *
> >  intel_display_power_domain_str(enum intel_display_power_domain domain)
> >  {
> > @@ -126,6 +139,8 @@ intel_display_power_domain_str(enum 
> > intel_display_power_domain domain)

Re: [Intel-gfx] [PATCH] drm/i915: Show if we consider the engine is idle in the GPU error state

[Chris Wilson]

Quoting Chris Wilson (2017-12-19 21:02:15)
> Quoting Rodrigo Vivi (2017-12-19 20:49:54)
> > On Tue, Dec 19, 2017 at 01:14:19PM +, Chris Wilson wrote:
> > > Useful for verifying our bookkeeper when we encounter is knowing whether
> > > we think the engine is idle at the time of the GPU hang.
> > > 
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=104305
> > 
> > Here you mention the hang as "false positive"...
> > if it is a false positive and we have this idle information
> > shouldn't we handle this differently instead of trowing the error
> > information and reseting the GPU?
> 
> I have contemplated skipping the reset if we think the GPU is idle, but
> that does rather assume that we have perfect knowledge and that skipping
> the reset is a good thing. (Though we do differentiate between resets to
> restore hw state and resets to fix a GPU hang already, so maybe it's not
> so bad, the caveat being an explicit request to reset the GPU.) In this
> case, a cursory glance said the engine should be idle (RING_MODE has the
> idle bit, RING_HEAD == RING_TAIL and the last seqno was completed) and I
> wanted to confirm that the driver also thought the engine should have
> been idle. That would leave the question as to why hangcheck thought
> differently, i.e. I'm trying to narrow the cause to a particular piece of
> code.

Thanks for the review, pushed and time to chase up the reporter to see
if he can reproduce on drm-tip.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid context dereference inside execlists_submission_tasklet

[Chris Wilson]

Quoting Michel Thierry (2017-12-19 22:43:57)
> On 12/19/2017 2:09 PM, Chris Wilson wrote:
> > A lesson that has to be relearnt over and over again is that the request
> > does not keep a reference to the context and so we cannot freely
> > dereference the context from inside the execlists_submission_tasklet. In
> > particular, we try to do so in the new GEM_TRACE() so convert those over
> > to the port->context_id we keep for GEM debugging. This means the
> > tracing now depends on DRM_I915_GEM_DEBUG.
> > 
> 
> Even before the port->context_id dependency, I don't think many people 
> would enable DRM_I915_TRACE_GEM without DRM_I915_DEBUG_GEM.

Indeed :)

> > Fixes: bccd3b831185 ("drm/i915: Use trace_printk to provide a death rattle 
> > for GEM")
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104066
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104162
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104242
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104310
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Joonas Lahtinen 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/Kconfig.debug | 2 +-
> >   drivers/gpu/drm/i915/intel_lrc.c   | 6 +++---
> >   2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
> > b/drivers/gpu/drm/i915/Kconfig.debug
> > index fa36491495b1..c846b250b9c4 100644
> > --- a/drivers/gpu/drm/i915/Kconfig.debug
> > +++ b/drivers/gpu/drm/i915/Kconfig.debug
> > @@ -29,7 +29,6 @@ config DRM_I915_DEBUG
> >  select SW_SYNC # signaling validation framework (igt/syncobj*)
> >  select DRM_I915_SW_FENCE_DEBUG_OBJECTS
> >  select DRM_I915_SELFTEST
> > -   select DRM_I915_TRACE_GEM
> >   default n
> >   help
> > Choose this option to turn on extra driver debugging that may 
> > affect
> > @@ -55,6 +54,7 @@ config DRM_I915_TRACE_GEM
> >  bool "Insert extra ftrace output from the GEM internals"
> >  select TRACING
> >  default n
> > +   depends on DRM_I915_DEBUG_GEM
> >  help
> >Enable additional and verbose debugging output that will spam
> >ordinary tests, but may be vital for post-mortem debugging when
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index eee718e3f371..64d49d5054b9 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -449,7 +449,7 @@ static void execlists_submit_ports(struct 
> > intel_engine_cs *engine)
> > 
> >  GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%x\n",
> >engine->name, n,
> > - rq->ctx->hw_id, count,
> > + port[n].context_id, count,
> >rq->global_seqno);
> >  } else {
> >  GEM_BUG_ON(!n);
> > @@ -861,7 +861,7 @@ static void execlists_submission_tasklet(unsigned long 
> > data)
> >   */
> > 
> >  status = READ_ONCE(buf[2 * head]); /* maybe mmio! 
> > */
> > -   GEM_TRACE("%s csb[%dd]: status=0x%08x:0x%08x\n",
> > +   GEM_TRACE("%s csb[%d]: status=0x%08x:0x%08x\n",
> >engine->name, head,
> >status, buf[2*head + 1]);
> > 
> > @@ -905,7 +905,7 @@ static void execlists_submission_tasklet(unsigned long 
> > data)
> >  rq = port_unpack(port, );
> >  GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x\n",
> >engine->name,
> > - rq->ctx->hw_id, count,
> > + port->context_id, count,
> >rq->global_seqno);
> >  GEM_BUG_ON(count == 0);
> >  if (--count == 0) {
> > --
> > 2.15.1
> > 
> 
> Reviewed-by: Michel Thierry 

Thanks, I'm looking forward to seeing how many incompletes now
evaporate.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 3/3] tests/perf_pmu: Verify engine busyness accuracy

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-19 15:45:43)
> +static void debug_error(const char *str, double val, double ref)
> +{
> +   igt_debug("%s=%.2f%% (%.2f/%.2f)\n", str, __error(val, ref), val, 
> ref);
> +}
> +
> +static void log_error(const char *str, double val, double ref)
> +{
> +   debug_error(str, val, ref);
> +   igt_info("%s=%.2f%%\n", str, __error(val, ref));
> +}

Looking at the CI output, these could really do with some explanation.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid context dereference inside execlists_submission_tasklet

[Michel Thierry]

On 12/19/2017 2:09 PM, Chris Wilson wrote:

A lesson that has to be relearnt over and over again is that the request
does not keep a reference to the context and so we cannot freely
dereference the context from inside the execlists_submission_tasklet. In
particular, we try to do so in the new GEM_TRACE() so convert those over
to the port->context_id we keep for GEM debugging. This means the
tracing now depends on DRM_I915_GEM_DEBUG.



Even before the port->context_id dependency, I don't think many people 
would enable DRM_I915_TRACE_GEM without DRM_I915_DEBUG_GEM.



Fixes: bccd3b831185 ("drm/i915: Use trace_printk to provide a death rattle for 
GEM")
References: https://bugs.freedesktop.org/show_bug.cgi?id=104066
References: https://bugs.freedesktop.org/show_bug.cgi?id=104162
References: https://bugs.freedesktop.org/show_bug.cgi?id=104242
References: https://bugs.freedesktop.org/show_bug.cgi?id=104310
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/Kconfig.debug | 2 +-
  drivers/gpu/drm/i915/intel_lrc.c   | 6 +++---
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index fa36491495b1..c846b250b9c4 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -29,7 +29,6 @@ config DRM_I915_DEBUG
 select SW_SYNC # signaling validation framework (igt/syncobj*)
 select DRM_I915_SW_FENCE_DEBUG_OBJECTS
 select DRM_I915_SELFTEST
-   select DRM_I915_TRACE_GEM
  default n
  help
Choose this option to turn on extra driver debugging that may affect
@@ -55,6 +54,7 @@ config DRM_I915_TRACE_GEM
 bool "Insert extra ftrace output from the GEM internals"
 select TRACING
 default n
+   depends on DRM_I915_DEBUG_GEM
 help
   Enable additional and verbose debugging output that will spam
   ordinary tests, but may be vital for post-mortem debugging when
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index eee718e3f371..64d49d5054b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -449,7 +449,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)

 GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%x\n",
   engine->name, n,
- rq->ctx->hw_id, count,
+ port[n].context_id, count,
   rq->global_seqno);
 } else {
 GEM_BUG_ON(!n);
@@ -861,7 +861,7 @@ static void execlists_submission_tasklet(unsigned long data)
  */

 status = READ_ONCE(buf[2 * head]); /* maybe mmio! */
-   GEM_TRACE("%s csb[%dd]: status=0x%08x:0x%08x\n",
+   GEM_TRACE("%s csb[%d]: status=0x%08x:0x%08x\n",
   engine->name, head,
   status, buf[2*head + 1]);

@@ -905,7 +905,7 @@ static void execlists_submission_tasklet(unsigned long data)
 rq = port_unpack(port, );
 GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x\n",
   engine->name,
- rq->ctx->hw_id, count,
+ port->context_id, count,
   rq->global_seqno);
 GEM_BUG_ON(count == 0);
 if (--count == 0) {
--
2.15.1



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

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/dummyload: Support returning output fence

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-19 15:45:41)
> From: Tvrtko Ursulin 
> 
> Support creating spin batches which return an output fence using new
> __igt_spin_batch_new_fence / igt_spin_batch_new_fence API.
> 
> This will be used fromthe perf_pmu@interrupts test to ensure user
> interrupt generation from a batch with controlled duration.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  lib/igt_dummyload.c | 65 
> ++---
>  lib/igt_dummyload.h | 10 +
>  2 files changed, 67 insertions(+), 8 deletions(-)
> 
> diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
> index d19b4e5ea3d2..ef08ad580246 100644
> --- a/lib/igt_dummyload.c
> +++ b/lib/igt_dummyload.c
> @@ -70,9 +70,9 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
> reloc->write_domain = write_domains;
>  }
>  
> -static void emit_recursive_batch(igt_spin_t *spin,
> -int fd, uint32_t ctx, unsigned engine,
> -uint32_t dep)
> +static int emit_recursive_batch(igt_spin_t *spin,
> +   int fd, uint32_t ctx, unsigned engine,
> +   uint32_t dep, bool out_fence)
>  {
>  #define SCRATCH 0
>  #define BATCH 1
> @@ -87,6 +87,7 @@ static void emit_recursive_batch(igt_spin_t *spin,
>  
> nengine = 0;
> if (engine == -1) {
> +   igt_assert_eq(out_fence, false);

Didn't fancy merging the fences together to return a composite out_fence?

> for_each_engine(fd, engine)
> if (engine)
> engines[nengine++] = engine;
> @@ -165,22 +166,31 @@ static void emit_recursive_batch(igt_spin_t *spin,
> execbuf.buffers_ptr = to_user_pointer(obj + (2 - 
> execbuf.buffer_count));
> execbuf.rsvd1 = ctx;
>  
> +   if (out_fence)
> +   execbuf.flags = I915_EXEC_FENCE_OUT;

if (out_fence)
execbuf.flags |= I915_EXEC_FENCE_OUT;

Just to make future changes easier?

Might also be good to insert a igt_require(gem_has_exec_fence(fd)) here
as well. (Or earlier?)

> +igt_spin_t *__igt_spin_batch_new_fence(int fd,
> +  uint32_t ctx,
> +  unsigned engine);
> +
> +igt_spin_t *igt_spin_batch_new_fence(int fd,
> +uint32_t ctx,
> +unsigned engine);

Ok for now, I expect these will mangled into a new spin-batch factory
later on.

With an igt_require(),
Reviewed-by: Chris Wilson 

If you want to merge the N engines' out_fences into one, that would save
me a task.
-Chris

___
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: Avoid context dereference inside execlists_submission_tasklet

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid context dereference inside execlists_submission_tasklet
URL   : https://patchwork.freedesktop.org/series/35604/
State : success

== Summary ==

Series 35604v1 drm/i915: Avoid context dereference inside 
execlists_submission_tasklet
https://patchwork.freedesktop.org/api/1.0/series/35604/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:475s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:470s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:265s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:411s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:389s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:519s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:525s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:503s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:538s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:410s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:590s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:625s

2c8d1d02646400b21aa2d68b9dc61b6cc00f661f drm-tip: 2017y-12m-19d-21h-47m-30s UTC 
integration manifest
6afc86a3f13b drm/i915: Avoid context dereference inside 
execlists_submission_tasklet

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Avoid context dereference inside execlists_submission_tasklet

[Chris Wilson]

A lesson that has to be relearnt over and over again is that the request
does not keep a reference to the context and so we cannot freely
dereference the context from inside the execlists_submission_tasklet. In
particular, we try to do so in the new GEM_TRACE() so convert those over
to the port->context_id we keep for GEM debugging. This means the
tracing now depends on DRM_I915_GEM_DEBUG.

Fixes: bccd3b831185 ("drm/i915: Use trace_printk to provide a death rattle for 
GEM")
References: https://bugs.freedesktop.org/show_bug.cgi?id=104066
References: https://bugs.freedesktop.org/show_bug.cgi?id=104162
References: https://bugs.freedesktop.org/show_bug.cgi?id=104242
References: https://bugs.freedesktop.org/show_bug.cgi?id=104310
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Kconfig.debug | 2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index fa36491495b1..c846b250b9c4 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -29,7 +29,6 @@ config DRM_I915_DEBUG
select SW_SYNC # signaling validation framework (igt/syncobj*)
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
-   select DRM_I915_TRACE_GEM
 default n
 help
   Choose this option to turn on extra driver debugging that may affect
@@ -55,6 +54,7 @@ config DRM_I915_TRACE_GEM
bool "Insert extra ftrace output from the GEM internals"
select TRACING
default n
+   depends on DRM_I915_DEBUG_GEM
help
  Enable additional and verbose debugging output that will spam
  ordinary tests, but may be vital for post-mortem debugging when
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index eee718e3f371..64d49d5054b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -449,7 +449,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
 
GEM_TRACE("%s in[%d]:  ctx=%d.%d, seqno=%x\n",
  engine->name, n,
- rq->ctx->hw_id, count,
+ port[n].context_id, count,
  rq->global_seqno);
} else {
GEM_BUG_ON(!n);
@@ -861,7 +861,7 @@ static void execlists_submission_tasklet(unsigned long data)
 */
 
status = READ_ONCE(buf[2 * head]); /* maybe mmio! */
-   GEM_TRACE("%s csb[%dd]: status=0x%08x:0x%08x\n",
+   GEM_TRACE("%s csb[%d]: status=0x%08x:0x%08x\n",
  engine->name, head,
  status, buf[2*head + 1]);
 
@@ -905,7 +905,7 @@ static void execlists_submission_tasklet(unsigned long data)
rq = port_unpack(port, );
GEM_TRACE("%s out[0]: ctx=%d.%d, seqno=%x\n",
  engine->name,
- rq->ctx->hw_id, count,
+ port->context_id, count,
  rq->global_seqno);
GEM_BUG_ON(count == 0);
if (--count == 0) {
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH i-g-t] lib/i915_pciids.h: synchronize with kernel header

[Chris Wilson]

Quoting Rodrigo Vivi (2017-12-19 21:59:43)
> On Fri, Dec 08, 2017 at 10:06:46PM +, Lucas De Marchi wrote:
> > This copies include/drm/i915_pciids.h from kernel as of drm-tip:
> > drm-tip: 2017y-12m-08d-21h-06m-35s UTC + patch adding INTEL_CFL_IDS that
> > was missing there[1].
> 
> Since this tip name is not easily found maybe it would be good to
> mention latest kernel commit that touched this file.
> 
> > The goal is to keep track of the PCI IDs in a
> > single place (kernel).
> 
> good idea.
> 
> > 
> > Right now a simple copy is done to catch up with latest changes there,
> > although in future it could be more sofisticated pointing the build
> > system to the external header.
> 
> Yeap, a real single place would be awesome.

Whilst maintaining independence of the igt build itself?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2][CI] tests/psr: Test vblank continuity with PSR enabled

[Pandiyan, Dhinakaran]

On Tue, 2017-12-19 at 13:54 -0800, Rodrigo Vivi wrote:
> On Wed, Dec 13, 2017 at 07:23:45PM +, Dhinakaran Pandiyan wrote:
> > PSR allows DMC to put the system to low power states when active, but
> > this can reset the frame counter on some platforms. The frame counter reset
> > leads to a negative diff applied to vblank count. This subtest checks
> > for that.
> > 
> > v2: Some optimizations and data type changes.
> > Cc: Rodrigo Vivi 
> > Cc: Daniel Vetter 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  tests/intel-ci/fast-feedback.testlist |  1 +
> >  tests/kms_psr_sink_crc.c  | 66 
> > +++
> >  2 files changed, 67 insertions(+)
> > 
> > diff --git a/tests/intel-ci/fast-feedback.testlist 
> > b/tests/intel-ci/fast-feedback.testlist
> > index f71a16bc..72338b72 100644
> > --- a/tests/intel-ci/fast-feedback.testlist
> > +++ b/tests/intel-ci/fast-feedback.testlist
> > @@ -247,6 +247,7 @@ igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a
> >  igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b
> >  igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c
> >  igt@kms_psr_sink_crc@psr_basic
> > +igt@kms_psr_sink_crc@vblank
> 
> just a note that we need ack from CI devs
> specially because it introduces some sleeps/waits below
> 
> >  igt@kms_setmode@basic-clone-single-crtc
> >  igt@kms_sink_crc_basic
> >  igt@pm_backlight@basic-brightness
> > diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> > index 83a69f0b..831368b2 100644
> > --- a/tests/kms_psr_sink_crc.c
> > +++ b/tests/kms_psr_sink_crc.c
> > @@ -69,6 +69,7 @@ typedef struct {
> > enum operations op;
> > uint32_t devid;
> > uint32_t crtc_id;
> > +   enum pipe pipe;
> > igt_display_t display;
> > drm_intel_bufmgr *bufmgr;
> > struct igt_fb fb_green, fb_white;
> > @@ -107,6 +108,7 @@ static void setup_output(data_t *data)
> > if (c->connector_type != DRM_MODE_CONNECTOR_eDP)
> > continue;
> >  
> > +   data->pipe = pipe;
> > igt_output_set_pipe(output, pipe);
> > data->crtc_id = output->config.crtc->crtc_id;
> > data->output = output;
> > @@ -285,6 +287,63 @@ static void assert_or_manual(bool condition, const 
> > char *expected)
> > igt_assert(igt_interactive_debug || condition);
> >  }
> >  
> > +static unsigned int get_vblank(int fd, unsigned int pipe)
> > +{
> > +   union drm_wait_vblank vbl;
> > +
> > +   memset(, 0, sizeof(vbl));
> > +   vbl.request.type = DRM_VBLANK_RELATIVE | kmstest_get_vbl_flag(pipe);
> > +   igt_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, );
> > +
> > +   return vbl.reply.sequence;
> > +}
> > +
> > +static void dmc_read_counts(unsigned int fd, unsigned int *count)
> > +{
> > +   char buf[512];
> > +
> > +   igt_debugfs_read(fd, "i915_dmc_info", buf);
> > +   igt_assert_eq(sscanf(strstr(buf, "DC3 -> DC5"), "DC3 -> DC5 count: %u", 
> > [0]),
> > + 1);
> > +   igt_assert_eq(sscanf(strstr(buf, "DC5 -> DC6"), "DC5 -> DC6 count: %u", 
> > [1]),
> > + 1);
> 
> we already have platforms where this counter doesn't exist. We might have 
> platforms
> where even DC3_TO_DC5 is not present or not reliable :/

I can check that the dc_off refcount has gone to zero (from
i915_power_domain_info) and then add a small delay after that.

> 
> > +   igt_debug("DC3->DC5 count=%u, DC5->DC6 count=%u\n", count[0], count[1]);
> > +}
> > +
> > +static void check_vblanks(data_t *data)
> > +{
> > +   unsigned int first_vbl, second_vbl;
> > +   int wait = 30; /* Takes about 2.5 seconds for DC_OFF disable */
> > +   char buf[512];
> > +   bool has_dmc;
> > +
> > +   first_vbl = get_vblank(data->drm_fd, data->pipe);
> > +
> > +   igt_debugfs_read(data->drm_fd, "i915_dmc_info", buf);
> > +   has_dmc = strstr(buf, "fw loaded: yes");
> > +
> > +   if (has_dmc) {
> > +   unsigned int new_dc[2], old_dc[2];
> > +
> > +   dmc_read_counts(data->drm_fd, new_dc);
> > +   do {
> > +   memcpy(old_dc, new_dc, sizeof(new_dc));
> > +   usleep(100 * 1000);
> > +   dmc_read_counts(data->drm_fd, new_dc);
> > +   } while (!memcmp(old_dc, new_dc, sizeof(new_dc)) && --wait);
> > +
> > +   igt_assert_f(wait, "Timed out waiting for DC state transition 
> > 3s.\n");
> > +   } else {
> > +   sleep(3);
> > +   }
> > +
> > +   second_vbl = get_vblank(data->drm_fd, data->pipe);
> > +   igt_debug("vblank count went from %u to %u in %d ms.\n",
> > + first_vbl, second_vbl, has_dmc ? (30 - wait) * 100 : 3000);
> > +
> > +   igt_assert_lt(first_vbl, second_vbl);
> > +}
> > +
> >  static bool drrs_disabled(data_t *data)
> >  {
> > char buf[512];
> > @@ -572,6 +631,13 @@ int main(int argc, char *argv[])
> > }
> > }
> >  
> > +   igt_subtest("vblank") {
> > +   setup_test_plane();
> > +   

Re: [Intel-gfx] [PATCH i-g-t] tests/psr: Dump PSR debugfs contents if PSR entry times out.

[Rodrigo Vivi]

On Tue, Dec 12, 2017 at 10:28:35PM +, Dhinakaran Pandiyan wrote:
>   (kms_psr_sink_crc:1717) CRITICAL: Failed assertion:
>   wait_psr_entry()
>   (kms_psr_sink_crc:1717) CRITICAL: Last errno: 25, Inappropriate ioctl
>   for device
> 
> isn't very useful, the Source_OK field would have indicated that the
> requirements to enable PSR weren't met in this case.

Is this still the case with the source_ok getting killed?

> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  tests/kms_psr_sink_crc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index 831368b2..c586d6e1 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -223,6 +223,7 @@ static bool wait_psr_entry(data_t *data)
>   return true;
>   sleep(1);
>   }
> + igt_debugfs_dump(data->drm_fd, "i915_edp_psr_status");

anyways seems a good thing to have...
so, with the commit message modified feel free to use:

Acked-by: Rodrigo Vivi 

>   return false;
>  }
>  
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Avoid setting redundant INIT power domain mask for DC_OFF wells

[Rodrigo Vivi]

On Tue, Dec 12, 2017 at 09:52:09PM +, Dhinakaran Pandiyan wrote:
> The POWER_DOMAIN_INIT bit is already set in _POWERWELL_2_POWER_DOMAINS,
> which is included in _DC_OFF_POWER_DOMAINS. So, avoid setting that again
> in _DC_OFF_POWER_DOMAINS and shuffle the macros a bit to make it easy to
> notice relation.
> 
> Cc: Imre Deak 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 96ab74f3d101..eb4b12989c84 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1706,11 +1706,10 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   BIT_ULL(POWER_DOMAIN_PORT_DDI_D_IO) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
>  #define SKL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> - SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
>   BIT_ULL(POWER_DOMAIN_MODESET) | \
>   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> - BIT_ULL(POWER_DOMAIN_INIT))
> + SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS)
>  
>  #define BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS (  \
>   BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> @@ -1728,12 +1727,6 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   BIT_ULL(POWER_DOMAIN_VGA) | \
>   BIT_ULL(POWER_DOMAIN_GMBUS) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
> -#define BXT_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> - BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
> - BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> - BIT_ULL(POWER_DOMAIN_MODESET) | \
> - BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> - BIT_ULL(POWER_DOMAIN_INIT))
>  #define BXT_DPIO_CMN_A_POWER_DOMAINS (   \
>   BIT_ULL(POWER_DOMAIN_PORT_DDI_A_LANES) |\
>   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> @@ -1744,6 +1737,11 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   BIT_ULL(POWER_DOMAIN_AUX_B) |   \
>   BIT_ULL(POWER_DOMAIN_AUX_C) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
> +#define BXT_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> + BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
> + BIT_ULL(POWER_DOMAIN_MODESET) | \
> + BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> + BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS)

why did you move the entire block below?

>  
>  #define GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS (  \
>   BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> @@ -1788,11 +1786,10 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   BIT_ULL(POWER_DOMAIN_AUX_C) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
>  #define GLK_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> - GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
>   BIT_ULL(POWER_DOMAIN_MODESET) | \
>   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> - BIT_ULL(POWER_DOMAIN_INIT))
> + GLK_DISPLAY_POWERWELL_2_POWER_DOMAINS)
>  
>  #define CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS (  \
>   BIT_ULL(POWER_DOMAIN_TRANSCODER_A) |\
> @@ -1836,10 +1833,9 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>   BIT_ULL(POWER_DOMAIN_AUX_D) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
>  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
> - CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT_ULL(POWER_DOMAIN_MODESET) | \
>   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
> - BIT_ULL(POWER_DOMAIN_INIT))
> + CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS)
>  
>  static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
>   .sync_hw = i9xx_power_well_sync_hw_noop,
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/vlv: Add cdclk workaround for DSI

[Patchwork]

== Series Details ==

Series: drm/i915/vlv: Add cdclk workaround for DSI
URL   : https://patchwork.freedesktop.org/series/35598/
State : success

== Summary ==

Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:10  skip:1164 
time:9415s
shard-snbtotal:2712 pass:1308 dwarn:2   dfail:0   fail:11  skip:1391 
time:8123s
Blacklisted hosts:
shard-kbltotal:2640 pass:1766 dwarn:1   dfail:0   fail:25  skip:847 
time:10944s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] lib/i915_pciids.h: synchronize with kernel header

[Rodrigo Vivi]

On Fri, Dec 08, 2017 at 10:06:46PM +, Lucas De Marchi wrote:
> This copies include/drm/i915_pciids.h from kernel as of drm-tip:
> drm-tip: 2017y-12m-08d-21h-06m-35s UTC + patch adding INTEL_CFL_IDS that
> was missing there[1].

Since this tip name is not easily found maybe it would be good to
mention latest kernel commit that touched this file.

> The goal is to keep track of the PCI IDs in a
> single place (kernel).

good idea.

> 
> Right now a simple copy is done to catch up with latest changes there,
> although in future it could be more sofisticated pointing the build
> system to the external header.

Yeap, a real single place would be awesome.

> 
> [1] https://patchwork.freedesktop.org/patch/192410/
> 
> Cc: Paulo Zanoni 
> Signed-off-by: Lucas De Marchi 

For the content itself: (with or without modification on commit message)

Reviewed-by: Rodrigo Vivi 

> ---
>  lib/i915_pciids.h | 178 
> ++
>  1 file changed, 111 insertions(+), 67 deletions(-)
> 
> diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
> index 8d6c7270..c65e4489 100644
> --- a/lib/i915_pciids.h
> +++ b/lib/i915_pciids.h
> @@ -118,92 +118,125 @@
>  #define INTEL_IRONLAKE_M_IDS(info) \
>   INTEL_VGA_DEVICE(0x0046, info)
>  
> -#define INTEL_SNB_D_IDS(info) \
> +#define INTEL_SNB_D_GT1_IDS(info) \
>   INTEL_VGA_DEVICE(0x0102, info), \
> - INTEL_VGA_DEVICE(0x0112, info), \
> - INTEL_VGA_DEVICE(0x0122, info), \
>   INTEL_VGA_DEVICE(0x010A, info)
>  
> -#define INTEL_SNB_M_IDS(info) \
> - INTEL_VGA_DEVICE(0x0106, info), \
> +#define INTEL_SNB_D_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x0112, info), \
> + INTEL_VGA_DEVICE(0x0122, info)
> +
> +#define INTEL_SNB_D_IDS(info) \
> + INTEL_SNB_D_GT1_IDS(info), \
> + INTEL_SNB_D_GT2_IDS(info)
> +
> +#define INTEL_SNB_M_GT1_IDS(info) \
> + INTEL_VGA_DEVICE(0x0106, info)
> +
> +#define INTEL_SNB_M_GT2_IDS(info) \
>   INTEL_VGA_DEVICE(0x0116, info), \
>   INTEL_VGA_DEVICE(0x0126, info)
>  
> +#define INTEL_SNB_M_IDS(info) \
> + INTEL_SNB_M_GT1_IDS(info), \
> + INTEL_SNB_M_GT2_IDS(info)
> +
> +#define INTEL_IVB_M_GT1_IDS(info) \
> + INTEL_VGA_DEVICE(0x0156, info) /* GT1 mobile */
> +
> +#define INTEL_IVB_M_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x0166, info) /* GT2 mobile */
> +
>  #define INTEL_IVB_M_IDS(info) \
> - INTEL_VGA_DEVICE(0x0156, info), /* GT1 mobile */ \
> - INTEL_VGA_DEVICE(0x0166, info)  /* GT2 mobile */
> + INTEL_IVB_M_GT1_IDS(info), \
> + INTEL_IVB_M_GT2_IDS(info)
>  
> -#define INTEL_IVB_D_IDS(info) \
> +#define INTEL_IVB_D_GT1_IDS(info) \
>   INTEL_VGA_DEVICE(0x0152, info), /* GT1 desktop */ \
> + INTEL_VGA_DEVICE(0x015a, info)  /* GT1 server */
> +
> +#define INTEL_IVB_D_GT2_IDS(info) \
>   INTEL_VGA_DEVICE(0x0162, info), /* GT2 desktop */ \
> - INTEL_VGA_DEVICE(0x015a, info), /* GT1 server */ \
>   INTEL_VGA_DEVICE(0x016a, info)  /* GT2 server */
>  
> +#define INTEL_IVB_D_IDS(info) \
> + INTEL_IVB_D_GT1_IDS(info), \
> + INTEL_IVB_D_GT2_IDS(info)
> +
>  #define INTEL_IVB_Q_IDS(info) \
>   INTEL_QUANTA_VGA_DEVICE(info) /* Quanta transcode */
>  
> -#define INTEL_HSW_IDS(info) \
> +#define INTEL_HSW_GT1_IDS(info) \
>   INTEL_VGA_DEVICE(0x0402, info), /* GT1 desktop */ \
> - INTEL_VGA_DEVICE(0x0412, info), /* GT2 desktop */ \
> - INTEL_VGA_DEVICE(0x0422, info), /* GT3 desktop */ \
>   INTEL_VGA_DEVICE(0x040a, info), /* GT1 server */ \
> - INTEL_VGA_DEVICE(0x041a, info), /* GT2 server */ \
> - INTEL_VGA_DEVICE(0x042a, info), /* GT3 server */ \
>   INTEL_VGA_DEVICE(0x040B, info), /* GT1 reserved */ \
> - INTEL_VGA_DEVICE(0x041B, info), /* GT2 reserved */ \
> - INTEL_VGA_DEVICE(0x042B, info), /* GT3 reserved */ \
>   INTEL_VGA_DEVICE(0x040E, info), /* GT1 reserved */ \
> - INTEL_VGA_DEVICE(0x041E, info), /* GT2 reserved */ \
> - INTEL_VGA_DEVICE(0x042E, info), /* GT3 reserved */ \
>   INTEL_VGA_DEVICE(0x0C02, info), /* SDV GT1 desktop */ \
> - INTEL_VGA_DEVICE(0x0C12, info), /* SDV GT2 desktop */ \
> - INTEL_VGA_DEVICE(0x0C22, info), /* SDV GT3 desktop */ \
>   INTEL_VGA_DEVICE(0x0C0A, info), /* SDV GT1 server */ \
> - INTEL_VGA_DEVICE(0x0C1A, info), /* SDV GT2 server */ \
> - INTEL_VGA_DEVICE(0x0C2A, info), /* SDV GT3 server */ \
>   INTEL_VGA_DEVICE(0x0C0B, info), /* SDV GT1 reserved */ \
> - INTEL_VGA_DEVICE(0x0C1B, info), /* SDV GT2 reserved */ \
> - INTEL_VGA_DEVICE(0x0C2B, info), /* SDV GT3 reserved */ \
>   INTEL_VGA_DEVICE(0x0C0E, info), /* SDV GT1 reserved */ \
> - INTEL_VGA_DEVICE(0x0C1E, info), /* SDV GT2 reserved */ \
> - INTEL_VGA_DEVICE(0x0C2E, info), /* SDV GT3 reserved */ \
>   INTEL_VGA_DEVICE(0x0A02, info), /* ULT GT1 desktop */ \
> - INTEL_VGA_DEVICE(0x0A12, info), /* ULT GT2 desktop */ \
> - INTEL_VGA_DEVICE(0x0A22, 

Re: [Intel-gfx] [PATCH i-g-t v2][CI] tests/psr: Test vblank continuity with PSR enabled

[Rodrigo Vivi]

On Wed, Dec 13, 2017 at 07:23:45PM +, Dhinakaran Pandiyan wrote:
> PSR allows DMC to put the system to low power states when active, but
> this can reset the frame counter on some platforms. The frame counter reset
> leads to a negative diff applied to vblank count. This subtest checks
> for that.
> 
> v2: Some optimizations and data type changes.
> Cc: Rodrigo Vivi 
> Cc: Daniel Vetter 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  tests/intel-ci/fast-feedback.testlist |  1 +
>  tests/kms_psr_sink_crc.c  | 66 
> +++
>  2 files changed, 67 insertions(+)
> 
> diff --git a/tests/intel-ci/fast-feedback.testlist 
> b/tests/intel-ci/fast-feedback.testlist
> index f71a16bc..72338b72 100644
> --- a/tests/intel-ci/fast-feedback.testlist
> +++ b/tests/intel-ci/fast-feedback.testlist
> @@ -247,6 +247,7 @@ igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a
>  igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b
>  igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c
>  igt@kms_psr_sink_crc@psr_basic
> +igt@kms_psr_sink_crc@vblank

just a note that we need ack from CI devs
specially because it introduces some sleeps/waits below

>  igt@kms_setmode@basic-clone-single-crtc
>  igt@kms_sink_crc_basic
>  igt@pm_backlight@basic-brightness
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index 83a69f0b..831368b2 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -69,6 +69,7 @@ typedef struct {
>   enum operations op;
>   uint32_t devid;
>   uint32_t crtc_id;
> + enum pipe pipe;
>   igt_display_t display;
>   drm_intel_bufmgr *bufmgr;
>   struct igt_fb fb_green, fb_white;
> @@ -107,6 +108,7 @@ static void setup_output(data_t *data)
>   if (c->connector_type != DRM_MODE_CONNECTOR_eDP)
>   continue;
>  
> + data->pipe = pipe;
>   igt_output_set_pipe(output, pipe);
>   data->crtc_id = output->config.crtc->crtc_id;
>   data->output = output;
> @@ -285,6 +287,63 @@ static void assert_or_manual(bool condition, const char 
> *expected)
>   igt_assert(igt_interactive_debug || condition);
>  }
>  
> +static unsigned int get_vblank(int fd, unsigned int pipe)
> +{
> + union drm_wait_vblank vbl;
> +
> + memset(, 0, sizeof(vbl));
> + vbl.request.type = DRM_VBLANK_RELATIVE | kmstest_get_vbl_flag(pipe);
> + igt_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, );
> +
> + return vbl.reply.sequence;
> +}
> +
> +static void dmc_read_counts(unsigned int fd, unsigned int *count)
> +{
> + char buf[512];
> +
> + igt_debugfs_read(fd, "i915_dmc_info", buf);
> + igt_assert_eq(sscanf(strstr(buf, "DC3 -> DC5"), "DC3 -> DC5 count: %u", 
> [0]),
> +   1);
> + igt_assert_eq(sscanf(strstr(buf, "DC5 -> DC6"), "DC5 -> DC6 count: %u", 
> [1]),
> +   1);

we already have platforms where this counter doesn't exist. We might have 
platforms
where even DC3_TO_DC5 is not present or not reliable :/

> + igt_debug("DC3->DC5 count=%u, DC5->DC6 count=%u\n", count[0], count[1]);
> +}
> +
> +static void check_vblanks(data_t *data)
> +{
> + unsigned int first_vbl, second_vbl;
> + int wait = 30; /* Takes about 2.5 seconds for DC_OFF disable */
> + char buf[512];
> + bool has_dmc;
> +
> + first_vbl = get_vblank(data->drm_fd, data->pipe);
> +
> + igt_debugfs_read(data->drm_fd, "i915_dmc_info", buf);
> + has_dmc = strstr(buf, "fw loaded: yes");
> +
> + if (has_dmc) {
> + unsigned int new_dc[2], old_dc[2];
> +
> + dmc_read_counts(data->drm_fd, new_dc);
> + do {
> + memcpy(old_dc, new_dc, sizeof(new_dc));
> + usleep(100 * 1000);
> + dmc_read_counts(data->drm_fd, new_dc);
> + } while (!memcmp(old_dc, new_dc, sizeof(new_dc)) && --wait);
> +
> + igt_assert_f(wait, "Timed out waiting for DC state transition 
> 3s.\n");
> + } else {
> + sleep(3);
> + }
> +
> + second_vbl = get_vblank(data->drm_fd, data->pipe);
> + igt_debug("vblank count went from %u to %u in %d ms.\n",
> +   first_vbl, second_vbl, has_dmc ? (30 - wait) * 100 : 3000);
> +
> + igt_assert_lt(first_vbl, second_vbl);
> +}
> +
>  static bool drrs_disabled(data_t *data)
>  {
>   char buf[512];
> @@ -572,6 +631,13 @@ int main(int argc, char *argv[])
>   }
>   }
>  
> + igt_subtest("vblank") {
> + setup_test_plane();
> + igt_assert(wait_psr_entry());
> + check_vblanks();
> + test_cleanup();
> + }
> +
>   igt_subtest_f("dpms_off_psr_active") {
>   data.test_plane = DRM_PLANE_TYPE_PRIMARY;
>   data.op = RENDER;
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> 

Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal flip subtest.

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 12:20:18AM +, Srivatsa, Anusha wrote:
> 
> 
> >-Original Message-
> >From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of 
> >Daniel
> >Vetter
> >Sent: Thursday, December 14, 2017 2:14 AM
> >To: Srivatsa, Anusha ; Strano, Luis
> >; Latvala, Petri ; Lofstedt,
> >Marta ; Saarinen, Jani 
> >Cc: intel-gfx ; Joseph Garvey
> >
> >Subject: Re: [Intel-gfx] [PATCH i-g-t] igt/kms_rotation_crc: Add horizontal 
> >flip
> >subtest.
> >
> >On Thu, Nov 23, 2017 at 12:05 AM, Anusha Srivatsa 
> >wrote:
> >> From: Joseph Garvey 
> >>
> >> Test that horizontal flip works with supported rotations. Includes a
> >> fix for the unrotated fb which was not being positioned correctly with
> >> portrait and landscape rectangles.
> >>
> >> v2:(from Anusha)
> >> - Change 180 degree rotation to follow the rest, use igt_swap(), make
> >> flip variable a bool. Format the patch correctly (Ville, Petri
> >> Latvala)
> >>
> >> v3: (From Anusha)
> >> - Correct the name of subtests in order to avoid duplication of names
> >> (Arek)
> >>
> >> Signed-off-by: Anusha Srivatsa 
> >> Signed-off-by: Joseph Garvey 
> >> Cc: Ville Syrjälä 
> >> Cc: Petri Latvala 
> >> Cc: Arkadiusz Hiler 
> >
> >I didn't see this patch fly by originally, but now Marta pointed out that 
> >this skips
> >everywhere. We need to rework it.
> >
> >General principle is that in kms tests we should _not_ have any 
> >platform/feature
> >checks encoded in the test. Instead, the testcase should check properties to
> >figure out whether something should work or not.
> >
> >
> >> ---
> >>  lib/igt_kms.c|   2 +-
> >>  lib/igt_kms.h|   5 ++
> >>  tests/kms_rotation_crc.c | 198
> >> +--
> >>  3 files changed, 164 insertions(+), 41 deletions(-)
> >>
> >> diff --git a/lib/igt_kms.c b/lib/igt_kms.c index a572fc6..3034e44
> >> 100644
> >> --- a/lib/igt_kms.c
> >> +++ b/lib/igt_kms.c
> >> @@ -3050,7 +3050,7 @@ void igt_fb_set_size(struct igt_fb *fb,
> >> igt_plane_t *plane,
> >>
> >>  static const char *rotation_name(igt_rotation_t rotation)  {
> >> -   switch (rotation) {
> >> +   switch (rotation & IGT_ROTATION_MASK) {
> >> case IGT_ROTATION_0:
> >> return "0°";
> >> case IGT_ROTATION_90:
> >> diff --git a/lib/igt_kms.h b/lib/igt_kms.h index 8dc118c..b83a828
> >> 100644
> >> --- a/lib/igt_kms.h
> >> +++ b/lib/igt_kms.h
> >> @@ -281,8 +281,13 @@ typedef enum {
> >> IGT_ROTATION_90  = 1 << 1,
> >> IGT_ROTATION_180 = 1 << 2,
> >> IGT_ROTATION_270 = 1 << 3,
> >> +   IGT_REFLECT_X= 1 << 4,
> >> +   IGT_REFLECT_Y= 1 << 5,
> >>  } igt_rotation_t;
> >>
> >> +#define IGT_ROTATION_MASK \
> >> +   (IGT_ROTATION_0 | IGT_ROTATION_90 | IGT_ROTATION_180 |
> >> +IGT_ROTATION_270)
> >> +
> >>  typedef struct {
> >> /*< private >*/
> >> igt_pipe_t *pipe;
> >> diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index
> >> 5aec8fa..9e13667 100644
> >> --- a/tests/kms_rotation_crc.c
> >> +++ b/tests/kms_rotation_crc.c
> >> @@ -32,6 +32,7 @@ typedef struct {
> >> igt_display_t display;
> >> struct igt_fb fb;
> >> struct igt_fb fb_reference;
> >> +   struct igt_fb fb_unrotated;
> >> struct igt_fb fb_modeset;
> >> struct igt_fb fb_flip;
> >> igt_crc_t ref_crc;
> >> @@ -43,8 +44,59 @@ typedef struct {
> >> uint32_t override_fmt;
> >> uint64_t override_tiling;
> >> bool flips;
> >> +   int devid;
> >>  } data_t;
> >>
> >> +typedef struct {
> >> +   float r;
> >> +   float g;
> >> +   float b;
> >> +} rgb_color_t;
> >> +
> >> +static void set_color(rgb_color_t *color, float r, float g, float b)
> >> +{
> >> +   color->r = r;
> >> +   color->g = g;
> >> +   color->b = b;
> >> +}
> >> +
> >> +static void rotate_colors(rgb_color_t *tl, rgb_color_t *tr, rgb_color_t 
> >> *br,
> >> + rgb_color_t *bl, igt_rotation_t rotation) {
> >> +   rgb_color_t bl_tmp, br_tmp, tl_tmp, tr_tmp;
> >> +
> >> +   if (rotation & IGT_REFLECT_X) {
> >> +   igt_swap(*tl, *tr);
> >> +   igt_swap(*bl, *br);
> >> +   }
> >> +
> >> +   if (rotation & IGT_ROTATION_90) {
> >> +   bl_tmp = *bl;
> >> +   br_tmp = *br;
> >> +   tl_tmp = *tl;
> >> +   tr_tmp = *tr;
> >> +   *tl = tr_tmp;
> >> +   *bl = tl_tmp;
> >> +   *tr = br_tmp;
> >> +   *br = bl_tmp;
> >> +   } else if (rotation & 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Implement WaDisableVFclkgate.

[Rodrigo Vivi]

On Sat, Dec 16, 2017 at 12:11:16AM +, Rafael Antognolli wrote:
> This workaround supposedly fixes some hangs in the VF unit.
> 
> Signed-off-by: Rafael Antognolli 
> Reviewed-by: Lucas De Marchi 

Both patches merged to dinq. Thanks for patches and reviews.

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 3 +++
>  drivers/gpu/drm/i915/intel_pm.c | 5 +
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 09bf043c1c2e..a9a6d6698bb1 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3875,6 +3875,9 @@ enum {
>  #define  SARBUNIT_CLKGATE_DIS(1 << 5)
>  #define  RCCUNIT_CLKGATE_DIS (1 << 7)
>  
> +#define UNSLICE_UNIT_LEVEL_CLKGATE   _MMIO(0x9434)
> +#define  VFUNIT_CLKGATE_DIS  (1 << 20)
> +
>  /*
>   * Display engine regs
>   */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a349c4fd51ff..e33842d6bb14 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8448,6 +8448,11 @@ static void cnl_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
>   val |= SARBUNIT_CLKGATE_DIS;
>   I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
> +
> + /* WaDisableVFclkgate:cnl */
> + val = I915_READ(UNSLICE_UNIT_LEVEL_CLKGATE);
> + val |= VFUNIT_CLKGATE_DIS;
> + I915_WRITE(UNSLICE_UNIT_LEVEL_CLKGATE, val);
>  }
>  
>  static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
> -- 
> 2.14.3
> 
> ___
> 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 i-g-t 2/3] tests/perf_pmu: Simplify interrupt testing

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-19 15:45:42)
> From: Tvrtko Ursulin 
> 
> Rather than calibrate and emit nop batches, use a manually signalled chain
> of spinners to generate the desired interrupts.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
> -   /* Unplug the calibrated queue and wait for all the fences */
> -   igt_spin_batch_free(gem_fd, spin);
> -   igt_assert_eq(poll(, 1, 2 * test_duration_ms), 1);
> -   close(pfd.fd);
> +   pfd.fd = spin[i]->out_fence;
> +   igt_spin_batch_set_timeout(spin[i], timeout_ms * 1e6);
> +   igt_assert_eq(poll(, 1, 2 * timeout_ms), 1);

Oh, still with the synchronous behaviour, bleurgh.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_ctx_param: Update invalid param (rev2)

[Patchwork]

== Series Details ==

Series: tests/gem_ctx_param: Update invalid param (rev2)
URL   : https://patchwork.freedesktop.org/series/35438/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3549
cd7e14499b1d drm-tip: 2017y-12m-19d-15h-09m-52s UTC integration manifest

Testlist changes:
+igt@gem_ctx_param@get-priority-new-ctx
+igt@gem_ctx_param@root-set-priority
+igt@gem_ctx_param@root-set-priority-invalid-value
+igt@gem_ctx_param@root-set-priority-overflow-value
+igt@gem_ctx_param@set-priority-invalid-size
+igt@gem_ctx_param@set-priority-not-supported
+igt@gem_ctx_param@user-set-priority
+igt@gem_ctx_param@user-set-priority-invalid-value

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:436s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:499s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:266s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:425s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:395s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:423s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:524s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:466s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:532s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:540s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:414s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:594s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:628s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/perf_pmu: Simplify interrupt testing

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-19 15:45:42)
> From: Tvrtko Ursulin 
> 
> Rather than calibrate and emit nop batches, use a manually signalled chain
> of spinners to generate the desired interrupts.
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
> } while (idle != busy);
>  
> -   /* Install the fences and enable signaling */
> -   igt_assert_eq(poll(, 1, 10), 0);
> +   /* Process the batch queue. */
> +   pfd.events = POLLIN;
> +   for (int i = 0; i < target; i++) {
> +   const unsigned int timeout_ms = test_duration_ms / target;

I think you want
timeout_ms = (i + 1) * test_duration_ms / target;
? Otherwise all the batches have the same relative-to-now timeout (not
relative to the start of the batch).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915: Introduce a non-blocking power domain for vblank interrupts

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 05:26:58AM +, Dhinakaran Pandiyan wrote:
> When DC states are enabled and PSR is active, the hardware enters DC5/DC6
> states resulting in frame counter resets. The frame counter resets mess
> up the vblank counting logic. In order to disable DC states when
> vblank interrupts are required and to disallow DC states when vblanks
> interrupts are already enabled, introduce a new VBLANK power domain.
> Since this power domain reference needs to be acquired and released in
> atomic context, _vblank_get() and _vblank_put() methods skip the
> power_domain mutex.
> 
> v2: Fix deadlock by switching irqsave spinlock.
> Implement atomic version of get_if_enabled.
> Modify power_domain_verify_state to check power well use count and
> enabled status atomically.
> Rewrite of intel_power_well_{get,put}
> 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 

+ Cc: Imre Deak 

> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  18 
>  drivers/gpu/drm/i915/intel_drv.h|   3 +
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 184 
> +---
>  3 files changed, 192 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ddadeb9eaf49..db597c5ebaed 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -397,6 +397,7 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_AUX_C,
>   POWER_DOMAIN_AUX_D,
>   POWER_DOMAIN_GMBUS,
> + POWER_DOMAIN_VBLANK,
>   POWER_DOMAIN_MODESET,
>   POWER_DOMAIN_GT_IRQ,
>   POWER_DOMAIN_INIT,
> @@ -1476,6 +1477,23 @@ struct i915_power_well {
>   bool has_fuses:1;
>   } hsw;
>   };
> +
> + /* Lock to serialize access to count, hw_enabled and ops, used for
> +  * power wells that have supports_atomix_ctx set to True.
> +  */
> + spinlock_t lock;
> +
> + /* Indicates that the get/put methods for this power well can be called
> +  * in atomic contexts, requires .ops to not sleep. This is valid
> +  * only for the DC_OFF power well currently.
> +  */
> + bool supports_atomic_ctx;
> +
> + /* DC_OFF power well was disabled since the last time vblanks were
> +  * disabled.
> +  */
> + bool dc_off_disabled;
> +
>   const struct i915_power_well_ops *ops;
>  };
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 48676e99316e..6822118f3c4d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1798,6 +1798,9 @@ bool intel_display_power_get_if_enabled(struct 
> drm_i915_private *dev_priv,
>   enum intel_display_power_domain domain);
>  void intel_display_power_put(struct drm_i915_private *dev_priv,
>enum intel_display_power_domain domain);
> +void intel_display_power_vblank_get(struct drm_i915_private *dev_priv,
> + bool *needs_restore);
> +void intel_display_power_vblank_put(struct drm_i915_private *dev_priv);
>  
>  static inline void
>  assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 992caec1fbc4..fc6812ed6137 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -56,6 +56,19 @@ static struct i915_power_well *
>  lookup_power_well(struct drm_i915_private *dev_priv,
> enum i915_power_well_id power_well_id);
>  
> +/* Optimize for the case when this is called from atomic contexts,
> + * although the case is unlikely.
> + */
> +#define power_well_lock(power_well, flags) do {  \
> + if (likely(power_well->supports_atomic_ctx))\

you mention unlikely on commend and call likely here, why?

> + spin_lock_irqsave(_well->lock, flags);\
> + } while (0)
> +
> +#define power_well_unlock(power_well, flags) do {\
> + if (likely(power_well->supports_atomic_ctx))\
> + spin_unlock_irqrestore(_well->lock, flags);   \
> + } while (0)
> +
>  const char *
>  intel_display_power_domain_str(enum intel_display_power_domain domain)
>  {
> @@ -126,6 +139,8 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "AUX_D";
>   case POWER_DOMAIN_GMBUS:
>   return "GMBUS";
> + case POWER_DOMAIN_VBLANK:
> + return "VBLANK";
>   case POWER_DOMAIN_INIT:
>   return "INIT";
>   case POWER_DOMAIN_MODESET:
> @@ -141,6 +156,9 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain 

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915/psr: Avoid initializing PSR if there is no sink support.

[Pandiyan, Dhinakaran]

On Tue, 2017-12-19 at 13:29 -0800, Rodrigo Vivi wrote:
> On Tue, Dec 19, 2017 at 05:26:54AM +, Dhinakaran Pandiyan wrote:
> > DPCD read for the eDP is complete by the time intel_psr_init() is
> > called, which means we can avoid initializing PSR structures and state
> > if there is no sink support.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
> >  drivers/gpu/drm/i915/intel_psr.c| 9 +
> >  2 files changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 64e5a263458c..1a7b28f62570 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2532,14 +2532,19 @@ static int i915_edp_psr_status(struct seq_file *m, 
> > void *data)
> > u32 stat[3];
> > enum pipe pipe;
> > bool enabled = false;
> > +   bool sink_support;
> >  
> > if (!HAS_PSR(dev_priv))
> > return -ENODEV;
> >  
> > +   sink_support = dev_priv->psr.sink_support;
> > +   seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> > +   if (!sink_support)
> > +   return 0;
> > +
> > intel_runtime_pm_get(dev_priv);
> >  
> > mutex_lock(_priv->psr.lock);
> > -   seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support));
> > seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
> > seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
> > seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 76339cf387cb..095e0a5a8574 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -503,6 +503,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
> > if (!crtc_state->has_psr)
> > return;
> >  
> > +   if (WARN_ON(!CAN_PSR(dev_priv)))
> > +   return;
> 
> hmm... I believe we will see this warning sooner than later...
> 
> has_psr is not the same as CAN_PSR.

has_psr should not be set in psr_compute_config() unless both source and
sink have PSR. So, the warn_on is if we mess up the state preparation.
> 
> also, btw I didn't like all this crtc_state has_psr x has_psr2. :/
> 
> probably this series could also unify that and clean it up.
> to many has_psr like cases.
> 
> > +
> > WARN_ON(dev_priv->drrs.dp);
> > mutex_lock(_priv->psr.lock);
> > if (dev_priv->psr.enabled) {
> > @@ -633,6 +636,9 @@ void intel_psr_disable(struct intel_dp *intel_dp,
> > if (!old_crtc_state->has_psr)
> > return;
> >  
> > +   if (WARN_ON(!CAN_PSR(dev_priv)))
> > +   return;
> > +
> > mutex_lock(_priv->psr.lock);
> > if (!dev_priv->psr.enabled) {
> > mutex_unlock(_priv->psr.lock);
> > @@ -913,6 +919,9 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
> > dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
> > HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
> >  
> > +   if (!dev_priv->psr.sink_support)
> > +   return;
> > +
> 
> Why not use CAN_PSR here?


So that we have the right MMIO's in case we want to probe the HW with no
sink support. I wasn't what would happen if we reg_read() on PSR
registers without the correct MMIO base.

> 
> > /* Per platform default: all disabled. */
> > if (i915_modparams.enable_psr == -1)
> > i915_modparams.enable_psr = 0;
> > -- 
> > 2.11.0
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/8] drm/i915/psr: Avoid initializing PSR if there is no sink support.

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 05:26:54AM +, Dhinakaran Pandiyan wrote:
> DPCD read for the eDP is complete by the time intel_psr_init() is
> called, which means we can avoid initializing PSR structures and state
> if there is no sink support.
> 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 7 ++-
>  drivers/gpu/drm/i915/intel_psr.c| 9 +
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 64e5a263458c..1a7b28f62570 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2532,14 +2532,19 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
>   u32 stat[3];
>   enum pipe pipe;
>   bool enabled = false;
> + bool sink_support;
>  
>   if (!HAS_PSR(dev_priv))
>   return -ENODEV;
>  
> + sink_support = dev_priv->psr.sink_support;
> + seq_printf(m, "Sink_Support: %s\n", yesno(sink_support));
> + if (!sink_support)
> + return 0;
> +
>   intel_runtime_pm_get(dev_priv);
>  
>   mutex_lock(_priv->psr.lock);
> - seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support));
>   seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 76339cf387cb..095e0a5a8574 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -503,6 +503,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   if (!crtc_state->has_psr)
>   return;
>  
> + if (WARN_ON(!CAN_PSR(dev_priv)))
> + return;

hmm... I believe we will see this warning sooner than later...

has_psr is not the same as CAN_PSR.

also, btw I didn't like all this crtc_state has_psr x has_psr2. :/

probably this series could also unify that and clean it up.
to many has_psr like cases.

> +
>   WARN_ON(dev_priv->drrs.dp);
>   mutex_lock(_priv->psr.lock);
>   if (dev_priv->psr.enabled) {
> @@ -633,6 +636,9 @@ void intel_psr_disable(struct intel_dp *intel_dp,
>   if (!old_crtc_state->has_psr)
>   return;
>  
> + if (WARN_ON(!CAN_PSR(dev_priv)))
> + return;
> +
>   mutex_lock(_priv->psr.lock);
>   if (!dev_priv->psr.enabled) {
>   mutex_unlock(_priv->psr.lock);
> @@ -913,6 +919,9 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>   dev_priv->psr_mmio_base = IS_HASWELL(dev_priv) ?
>   HSW_EDP_PSR_BASE : BDW_EDP_PSR_BASE;
>  
> + if (!dev_priv->psr.sink_support)
> + return;
> +

Why not use CAN_PSR here?

>   /* Per platform default: all disabled. */
>   if (i915_modparams.enable_psr == -1)
>   i915_modparams.enable_psr = 0;
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/3] lib/dummyload: Support returning output fence

[Patchwork]

== Series Details ==

Series: series starting with [1/3] lib/dummyload: Support returning output fence
URL   : https://patchwork.freedesktop.org/series/35589/
State : warning

== Summary ==

Test pm_rpm:
Subgroup system-suspend-modeset:
pass   -> SKIP   (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
pass   -> SKIP   (shard-snb)
Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365

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

shard-hswtotal:2727 pass:1536 dwarn:1   dfail:0   fail:10  skip:1180 
time:9422s
shard-snbtotal:2727 pass:1309 dwarn:1   dfail:0   fail:10  skip:1407 
time:8096s
Blacklisted hosts:
shard-apltotal:2727 pass:1690 dwarn:1   dfail:0   fail:31  skip:1004 
time:13803s
shard-kbltotal:2709 pass:1803 dwarn:4   dfail:0   fail:28  skip:873 
time:10895s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/gem_ctx_param: Update invalid param

[Chris Wilson]

Quoting Antonio Argenziano (2017-12-19 21:16:40)
> Since commit: drm/i915/scheduler: Support user-defined priorities, the
> driver support an extra context param to set context's priority. Add
> tests for that interface and update invalid tests.
> 
> v2:
> - Add arg size validation test. (Chris)
> - Add arg value overflow test. (Chris)
> - Add test for unsupported platforms. (Chris)
> - Feed interface with all priority values and in random order. (Chris)
> 
> Signed-off-by: Antonio Argenziano 
> Cc: Chris Wilson 
> Cc: Michal Winiarski 
> ---
> +   igt_subtest("user-set-priority-invalid-value") {
> +   int prio_values[PRIO_RANGE - USER_PRIO_RANGE];
> +   for (int i = 0; i < (PRIO_RANGE - USER_PRIO_RANGE); 
> i++)
> +   prio_values[i] = i + (MAX_USER_SET_PRIO + 1);
> +   igt_permute_array(prio_values, 
> ARRAY_SIZE(prio_values), igt_exchange_int);
> +
> +   arg.ctx_id = gem_context_create(fd);

So arg.ctx_id points to different contexts depending on which subtests
are run, beside the context leak. But that does also make a good
suggestion that you do want to check both the default context (0) and a
user created context for handling (it may matter not today, but we do
already depend on the equivalence, i.e. that we can probe the default
context to determine support for user contexts). Do you feel like
parameterising the tests yet? :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for lib: Convert sw_sync to use sync_file uapi imported from the kernel

[Patchwork]

== Series Details ==

Series: lib: Convert sw_sync to use sync_file uapi imported from the kernel
URL   : https://patchwork.freedesktop.org/series/35587/
State : failure

== Summary ==

Test kms_atomic:
Subgroup plane_invalid_params_fence:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup basic-flip-c:
pass   -> SKIP   (shard-hsw)
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test kms_plane_multiple:
Subgroup legacy-pipe-a-tiling-x:
pass   -> SKIP   (shard-hsw)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> DMESG-WARN (shard-hsw) fdo#104218
Test gem_exec_schedule:
Subgroup smoketest-bsd1:
skip   -> INCOMPLETE (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623

fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2641 pass:1492 dwarn:2   dfail:0   fail:9   skip:1137 
time:8964s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8082s
Blacklisted hosts:
shard-kbltotal:2712 pass:1808 dwarn:1   dfail:0   fail:24  skip:879 
time:11060s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915/psr: CAN_PSR() macro to check for PSR source and sink support.

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 05:26:53AM +, Dhinakaran Pandiyan wrote:
> The global variable dev_priv->psr.sink_support is set if an eDP sink
> supports PSR. Use this instead of redoing the check with is_edp_psr().
> Combine source and sink support checks into a macro that can be used to
> return early from psr_{invalidate, single_frame_update, flush}.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_psr.c | 19 ---
>  2 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 30f791f89d64..48676e99316e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1760,6 +1760,7 @@ static inline void 
> intel_backlight_device_unregister(struct intel_connector *con
>  
>  
>  /* intel_psr.c */
> +#define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support)

not sure about the "CAN"... but I don't have better suggestion and I believe
it is somehow clear enough...

>  void intel_psr_enable(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state);
>  void intel_psr_disable(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index c4d75e82a1df..76339cf387cb 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -56,14 +56,6 @@
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> -static bool is_edp_psr(struct intel_dp *intel_dp)
> -{
> - if (!intel_dp_is_edp(intel_dp))
> - return false;
> -
> - return intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED;
> -}

I wonder why we haven't done this before in favor of sink_support///
my bad... 

> -
>  static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -358,10 +350,7 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   _state->base.adjusted_mode;
>   int psr_setup_time;
>  
> - if (!HAS_PSR(dev_priv))
> - return;
> -
> - if (!is_edp_psr(intel_dp))
> + if (!CAN_PSR(dev_priv))
>   return;
>  
>   if (!i915_modparams.enable_psr) {
> @@ -794,7 +783,7 @@ void intel_psr_single_frame_update(struct 
> drm_i915_private *dev_priv,
>   enum pipe pipe;
>   u32 val;
>  
> - if (!HAS_PSR(dev_priv))
> + if (!CAN_PSR(dev_priv))
>   return;
>  
>   /*
> @@ -843,7 +832,7 @@ void intel_psr_invalidate(struct drm_i915_private 
> *dev_priv,
>   struct drm_crtc *crtc;
>   enum pipe pipe;
>  
> - if (!HAS_PSR(dev_priv))
> + if (!CAN_PSR(dev_priv))
>   return;
>  
>   mutex_lock(_priv->psr.lock);
> @@ -883,7 +872,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   struct drm_crtc *crtc;
>   enum pipe pipe;
>  
> - if (!HAS_PSR(dev_priv))
> + if (!CAN_PSR(dev_priv))
>   return;

Reviewed-by: Rodrigo Vivi 

>  
>   mutex_lock(_priv->psr.lock);
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt: Exercise creating context with shared GTT (rev2)

[Patchwork]

== Series Details ==

Series: igt: Exercise creating context with shared GTT (rev2)
URL   : https://patchwork.freedesktop.org/series/35406/
State : failure

== Summary ==

Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
pass   -> SKIP   (shard-snb)
pass   -> SKIP   (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test kms_flip:
Subgroup absolute-wf_vblank-interruptible:
pass   -> INCOMPLETE (shard-hsw)
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2712 pass:1510 dwarn:1   dfail:0   fail:10  skip:1190 
time:9132s
shard-snbtotal:2753 pass:1309 dwarn:1   dfail:0   fail:10  skip:1433 
time:8076s
Blacklisted hosts:
shard-apltotal:2753 pass:1686 dwarn:3   dfail:0   fail:22  skip:1042 
time:13913s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/pm_rps: Always allocate spin[0] (rev2)

[Patchwork]

== Series Details ==

Series: igt/pm_rps: Always allocate spin[0] (rev2)
URL   : https://patchwork.freedesktop.org/series/35176/
State : success

== Summary ==

Warning: bzip IGTPW_702/shard-hsw6/results18.json.bz2 wasn't in correct JSON 
format
Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Subgroup flip-vs-modeset-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)

fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2636 pass:1498 dwarn:1   dfail:0   fail:9   skip:1128 
time:9222s
shard-snbtotal:2712 pass:1306 dwarn:3   dfail:0   fail:12  skip:1391 
time:8153s
Blacklisted hosts:
shard-apltotal:2614 pass:1618 dwarn:2   dfail:0   fail:22  skip:971 
time:13098s
shard-kbltotal:2705 pass:1799 dwarn:6   dfail:1   fail:23  skip:875 
time:10751s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Show if we consider the engine is idle in the GPU error state

[Patchwork]

== Series Details ==

Series: drm/i915: Show if we consider the engine is idle in the GPU error state
URL   : https://patchwork.freedesktop.org/series/35581/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test kms_universal_plane:
Subgroup disable-primary-vs-flip-pipe-b:
pass   -> SKIP   (shard-hsw)
Test perf:
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test kms_flip:
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060 +1
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
pass   -> SKIP   (shard-hsw)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365

shard-hswtotal:2712 pass:1532 dwarn:1   dfail:0   fail:12  skip:1167 
time:9296s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8134s

== Logs ==

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

[Intel-gfx] [PATCH i-g-t v2] tests/gem_ctx_param: Update invalid param

[Antonio Argenziano]

Since commit: drm/i915/scheduler: Support user-defined priorities, the
driver support an extra context param to set context's priority. Add
tests for that interface and update invalid tests.

v2:
- Add arg size validation test. (Chris)
- Add arg value overflow test. (Chris)
- Add test for unsupported platforms. (Chris)
- Feed interface with all priority values and in random order. (Chris)

Signed-off-by: Antonio Argenziano 
Cc: Chris Wilson 
Cc: Michal Winiarski 
---
 tests/gem_ctx_param.c | 143 +-
 1 file changed, 142 insertions(+), 1 deletion(-)

diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c
index c20ae1ee..96eb2c3a 100644
--- a/tests/gem_ctx_param.c
+++ b/tests/gem_ctx_param.c
@@ -25,6 +25,7 @@
  */
 
 #include "igt.h"
+#include 
 
 IGT_TEST_DESCRIPTION("Basic test for context set/get param input validation.");
 
@@ -136,11 +137,151 @@ igt_main
gem_context_set_param(fd, );
}
 
+   arg.param = I915_CONTEXT_PARAM_PRIORITY;
+
+#define MAX_USER_SET_PRIO I915_CONTEXT_DEFAULT_PRIORITY /* Current max prio 
for non-root users */
+#define PRIO_RANGE (I915_CONTEXT_MAX_USER_PRIORITY - 
I915_CONTEXT_MIN_USER_PRIORITY)
+#define USER_PRIO_RANGE (MAX_USER_SET_PRIO - I915_CONTEXT_MIN_USER_PRIORITY)
+
+   igt_subtest("set-priority-not-supported") {
+   igt_require(!gem_scheduler_has_ctx_priority(fd));
+
+   arg.ctx_id = ctx;
+   arg.size = 0;
+
+   igt_assert_eq(__gem_context_set_param(fd, ), 
-ENODEV);
+   }
+
+   igt_subtest_group {
+   igt_fixture {
+   igt_require(gem_scheduler_has_ctx_priority(fd));
+   }
+
+   igt_subtest("get-priority-new-ctx") {
+   arg.ctx_id = gem_context_create(fd);
+
+   gem_context_get_param(fd, );
+   igt_assert_eq(arg.value, 0);
+   }
+
+   igt_subtest("set-priority-invalid-size") {
+   arg.ctx_id = ctx;
+   arg.value = 0;
+   arg.size = ~0;
+
+   igt_assert_eq(__gem_context_set_param(fd, ), 
-EINVAL);
+   }
+
+   igt_subtest("root-set-priority") {
+   int prio_values[PRIO_RANGE + 1];
+   for (int i = 0; i < PRIO_RANGE + 1; i++)
+   prio_values[i] = i + 
I915_CONTEXT_MIN_USER_PRIORITY;
+   igt_permute_array(prio_values, ARRAY_SIZE(prio_values), 
igt_exchange_int);
+
+   arg.ctx_id = ctx;
+   arg.size = 0;
+
+   for (int i = 0; i < PRIO_RANGE + 1; i++) {
+   arg.value = prio_values[i];
+   gem_context_set_param(fd, );
+
+   gem_context_get_param(fd, );
+   igt_assert_eq(arg.value, prio_values[i]); /* 
Verify prio was set */
+   }
+   }
+
+   igt_subtest("root-set-priority-invalid-value") {
+   int prio_levels[]
+   = {INT_MIN,
+   I915_CONTEXT_MIN_USER_PRIORITY - 1,
+   I915_CONTEXT_MAX_USER_PRIORITY + 1,
+   INT_MAX}; /* Test space too big pick 
significant values */
+   int old_value;
+   arg.ctx_id = ctx;
+
+   gem_context_get_param(fd, );
+   old_value = arg.value;
+
+   for (int i = 0; i < ARRAY_SIZE(prio_levels); i++) {
+   arg.value = prio_levels[i];
+   igt_assert_eq(__gem_context_set_param(fd, 
), -EINVAL);
+
+   gem_context_get_param(fd, );
+   igt_assert_eq(arg.value, old_value); /* Verify 
prio was not set */
+   }
+   }
+
+   igt_subtest("root-set-priority-overflow-value") {
+   uint64_t prio_values[PRIO_RANGE + 1];
+   for (int i = 0; i < PRIO_RANGE + 1; i++)
+   prio_values[i] = (0x1 << 32) + (i + 
I915_CONTEXT_MIN_USER_PRIORITY);
+   igt_permute_array(prio_values, ARRAY_SIZE(prio_values), 
igt_exchange_int);
+
+   arg.ctx_id = gem_context_create(fd);
+   arg.size = 0;
+
+   for (int i = 0; i < PRIO_RANGE + 1; i++) {
+   arg.value = prio_values[i];
+   igt_assert_eq(__gem_context_set_param(fd, 
), -EINVAL);
+
+   

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915/psr: Kill psr.source_ok flag.

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 05:26:52AM +, Dhinakaran Pandiyan wrote:
> This flag has become redundant since
> commit 4d90f2d507ab ("drm/i915: Start tracking PSR state in crtc state")
> It is set at the same place as psr.enabled, which is also exposed via
> debugfs.
> 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> Signed-off-by: Dhinakaran Pandiyan 

I just hope this doesn't break any igt debugfs parse, but the patch here seems
right way to go, so:

Acked-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 1 -
>  drivers/gpu/drm/i915/i915_drv.h | 1 -
>  drivers/gpu/drm/i915/intel_psr.c| 2 --
>  3 files changed, 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 0ddce72552bf..64e5a263458c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2540,7 +2540,6 @@ static int i915_edp_psr_status(struct seq_file *m, void 
> *data)
>  
>   mutex_lock(_priv->psr.lock);
>   seq_printf(m, "Sink_Support: %s\n", yesno(dev_priv->psr.sink_support));
> - seq_printf(m, "Source_OK: %s\n", yesno(dev_priv->psr.source_ok));
>   seq_printf(m, "Enabled: %s\n", yesno((bool)dev_priv->psr.enabled));
>   seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>   seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1aba5657f5f0..1e4e613e7b41 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1199,7 +1199,6 @@ struct i915_drrs {
>  struct i915_psr {
>   struct mutex lock;
>   bool sink_support;
> - bool source_ok;
>   struct intel_dp *enabled;
>   bool active;
>   struct delayed_work work;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index a1ad85fa5c1a..c4d75e82a1df 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -522,8 +522,6 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>   }
>  
>   dev_priv->psr.psr2_support = crtc_state->has_psr2;
> - dev_priv->psr.source_ok = true;
> -
>   dev_priv->psr.busy_frontbuffer_bits = 0;
>  
>   dev_priv->psr.setup_vsc(intel_dp, crtc_state);
> -- 
> 2.11.0
> 
___
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: Remove pointer indirection for hangcheck_state local

[Patchwork]

== Series Details ==

Series: drm/i915: Remove pointer indirection for hangcheck_state local
URL   : https://patchwork.freedesktop.org/series/35580/
State : success

== Summary ==

Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-snb)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
skip   -> PASS   (shard-snb)
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions-nonblocking:
skip   -> PASS   (shard-snb)
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252 +1
Test kms_flip:
Subgroup vblank-vs-modeset-suspend:
skip   -> PASS   (shard-snb) fdo#102365
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623

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

shard-hswtotal:2712 pass:1536 dwarn:1   dfail:0   fail:11  skip:1164 
time:9429s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8098s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Grab power domain in skl_pipe_wm_get_hw_state()

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 12:16:45PM +, Maarten Lankhorst wrote:
> This should get rid of unclaimed register debug warnings, if
> it still happens we should put this in a intel_crtc->active check..

What if we just call skl_pipe_wm_get_hw_state() on skl_wm_get_hw_state()
if intel_crtc->active ?

-   skl_pipe_wm_get_hw_state(crtc, >wm.skl.optimal);
-if (intel_crtc->active)
-hw->dirty_pipes |= drm_crtc_mask(crtc);

+if (intel_crtc->active) {
+hw->dirty_pipes |= drm_crtc_mask(crtc);
+skl_pipe_wm_get_hw_state(crtc, 
>wm.skl.optimal);
+}

>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104172
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ab6f1b770891..52d157c00535 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5477,6 +5477,11 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
>   int level, max_level;
>   enum plane_id plane_id;
>   uint32_t val;
> + enum intel_display_power_domain power_domain;
> +
> + power_domain = POWER_DOMAIN_PIPE(pipe);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> + return;
>
>   max_level = ilk_wm_max_level(dev_priv);
>
> @@ -5500,10 +5505,9 @@ void skl_pipe_wm_get_hw_state(struct drm_crtc *crtc,
>   skl_wm_level_from_reg_val(val, >trans_wm);
>   }
>
> - if (!intel_crtc->active)
> - return;

but with my way or this way I wonder if we are now changing some expected wm
behavior since on the current version we just skip late if crtc wasn't active.

> -
>   out->linetime = I915_READ(PIPE_WM_LINETIME(pipe));
> +
> + intel_display_power_put(dev_priv, power_domain);
>  }
>
>  void skl_wm_get_hw_state(struct drm_device *dev)
> --
> 2.15.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove pointer indirection for hangcheck_state local

[Chris Wilson]

Quoting Rodrigo Vivi (2017-12-19 20:54:40)
> On Tue, Dec 19, 2017 at 01:09:48PM +, Chris Wilson wrote:
> > Use the local on-stack struct directly rather than hide it behind a
> > pointer. This should be both clearer for the reader and the compiler (we
> > rely on the compiler seeing through the functions to spot uninitialized
> > uses of the local).
> 
> much better!
> 
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/intel_hangcheck.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> > b/drivers/gpu/drm/i915/intel_hangcheck.c
> > index 0acd9dd3ed5c..fe99439aaf39 100644
> > --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> > @@ -429,18 +429,18 @@ static void i915_hangcheck_elapsed(struct work_struct 
> > *work)
> >   intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
> >  
> >   for_each_engine(engine, dev_priv, id) {
> > - struct intel_engine_hangcheck cur_state, *hc = _state;
> > + struct intel_engine_hangcheck hc;
> 
> I wonder if we couldn't move these definition up...

This is the tightest scope for hc, so one argument is to keep it tightly
scope to prevent leakage. Just sometimes the code ends up more readable
without a new set of variables at the start of a block.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Show if we consider the engine is idle in the GPU error state

[Chris Wilson]

Quoting Rodrigo Vivi (2017-12-19 20:49:54)
> On Tue, Dec 19, 2017 at 01:14:19PM +, Chris Wilson wrote:
> > Useful for verifying our bookkeeper when we encounter is knowing whether
> > we think the engine is idle at the time of the GPU hang.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104305
> 
> Here you mention the hang as "false positive"...
> if it is a false positive and we have this idle information
> shouldn't we handle this differently instead of trowing the error
> information and reseting the GPU?

I have contemplated skipping the reset if we think the GPU is idle, but
that does rather assume that we have perfect knowledge and that skipping
the reset is a good thing. (Though we do differentiate between resets to
restore hw state and resets to fix a GPU hang already, so maybe it's not
so bad, the caveat being an explicit request to reset the GPU.) In this
case, a cursory glance said the engine should be idle (RING_MODE has the
idle bit, RING_HEAD == RING_TAIL and the last seqno was completed) and I
wanted to confirm that the driver also thought the engine should have
been idle. That would leave the question as to why hangcheck thought
differently, i.e. I'm trying to narrow the cause to a particular piece of
code.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Remove pointer indirection for hangcheck_state local

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 01:09:48PM +, Chris Wilson wrote:
> Use the local on-stack struct directly rather than hide it behind a
> pointer. This should be both clearer for the reader and the compiler (we
> rely on the compiler seeing through the functions to spot uninitialized
> uses of the local).

much better!

> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_hangcheck.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 0acd9dd3ed5c..fe99439aaf39 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -429,18 +429,18 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>   intel_uncore_arm_unclaimed_mmio_detection(dev_priv);
>  
>   for_each_engine(engine, dev_priv, id) {
> - struct intel_engine_hangcheck cur_state, *hc = _state;
> + struct intel_engine_hangcheck hc;

I wonder if we couldn't move these definition up...

anyways:

Reviewed-by: Rodrigo Vivi 

>   const bool busy = intel_engine_has_waiter(engine);
>  
>   semaphore_clear_deadlocks(dev_priv);
>  
> - hangcheck_load_sample(engine, hc);
> - hangcheck_accumulate_sample(engine, hc);
> - hangcheck_store_sample(engine, hc);
> + hangcheck_load_sample(engine, );
> + hangcheck_accumulate_sample(engine, );
> + hangcheck_store_sample(engine, );
>  
>   if (engine->hangcheck.stalled) {
>   hung |= intel_engine_flag(engine);
> - if (hc->action != ENGINE_DEAD)
> + if (hc.action != ENGINE_DEAD)
>   stuck |= intel_engine_flag(engine);
>   }
>  
> -- 
> 2.15.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Show if we consider the engine is idle in the GPU error state

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 01:14:19PM +, Chris Wilson wrote:
> Useful for verifying our bookkeeper when we encounter is knowing whether
> we think the engine is idle at the time of the GPU hang.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104305

Here you mention the hang as "false positive"...
if it is a false positive and we have this idle information
shouldn't we handle this differently instead of trowing the error
information and reseting the GPU?

Or am I missunderstanding what you meant with "false positive"?

> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Mika Kuoppala 
> Cc: Michal Wajdeczko 

Anyways the info here seems interresting so

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   | 1 +
>  drivers/gpu/drm/i915/i915_gpu_error.c | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1aba5657f5f0..8ca836851365 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -948,6 +948,7 @@ struct i915_gpu_state {
>   struct drm_i915_error_engine {
>   int engine_id;
>   /* Software tracked state */
> + bool idle;
>   bool waiting;
>   int num_waiters;
>   unsigned long hangcheck_timestamp;
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index aba50aa613f1..50feec87c3a3 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -416,6 +416,7 @@ static void error_print_engine(struct 
> drm_i915_error_state_buf *m,
>   int n;
>  
>   err_printf(m, "%s command stream:\n", engine_str(ee->engine_id));
> + err_printf(m, "  IDLE?: %s\n", yesno(ee->idle));
>   err_printf(m, "  START: 0x%08x\n", ee->start);
>   err_printf(m, "  HEAD:  0x%08x [0x%08x]\n", ee->head, ee->rq_head);
>   err_printf(m, "  TAIL:  0x%08x [0x%08x, 0x%08x]\n",
> @@ -1256,6 +1257,7 @@ static void error_record_engine_registers(struct 
> i915_gpu_state *error,
>   ee->hws = I915_READ(mmio);
>   }
>  
> + ee->idle = intel_engine_is_idle(engine);
>   ee->hangcheck_timestamp = engine->hangcheck.action_timestamp;
>   ee->hangcheck_action = engine->hangcheck.action;
>   ee->hangcheck_stalled = engine->hangcheck.stalled;
> -- 
> 2.15.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Hans de Goede]

Hi,

On 19-12-17 20:48, Ville Syrjälä wrote:

On Tue, Dec 19, 2017 at 08:31:07PM +0100, Hans de Goede wrote:

Hi,

I forgot to add a coverletter, anyways what I wanted to put in the
coverletter and not in the commit message is a link to a picture of the
problem this fixes:

https://fedorapeople.org/~jwrdegoede/IMG_20171217_195637.jpg

Note the screen is actually a portrait screen, so the picture is the
right way up. Beside the obvious left shift with wrap-around of the
picture, also all the green in there is supposed to be blue.

Another less clear picture is this one:

https://fedorapeople.org/~jwrdegoede/IMG_20171217_195507.jpg

Again with wrong colors.

###

While working on this I also noticed that the pixelclock as
the driver gets it from the VBT is not the same as the one the
GOP uses, on the tablet in question the VBT says 77000 KHz
and the GOP uses (according to the initial readback) 78125 KHz,
on another tablet I noticed the VBT saying 78125 KHz, where
as the GOP was using 68xxx KHz which came to a refresh-rate
of around 60 Hz, where as the VBT value is 69 Hz IIRC.

Neither of these cause any actual issue (fixing the pixelclock
to match the GOP programmed value does not fix the issue, where
as using the GOP cdclk of 33KHz does).


https://patchwork.freedesktop.org/patch/127189/

I suppose it's unlike that would help here since it's just about the
overlap in dual link mode, but there could be other fail in the DSI
clock code.


Yes that is is not applicable to the Vi8 where I'm seeing the
77000 KHz used by GOP vs 78125 KHz used by i915.

Looking at intel_dsi_vbt_init the pclk on the boards where I'm
seeing an inconsistency is just taken directly from mode->clock,
which in turn is simply dvo_timing->clock * 10.

Again: these different pixel-clocks do not seem to be an issue,
I just noticed this too while looking at the problem best seen
here:

https://fedorapeople.org/~jwrdegoede/IMG_20171217_195637.jpg

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Hans de Goede]

Hi,

On 19-12-17 20:42, Rodrigo Vivi wrote:


On Tue, Dec 19, 2017 at 07:21:13PM +, Hans de Goede wrote:

At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.

After looking at drm.debug output I noticed that initially we inherit the
cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 33 KHz makes the problem go away.

I've tested this on various Bay Trail devices:
-Chuwi Vi8: 800x1280, 33 at boot, requires 33 to work properly
-GP-electronic T701: 1024x600, 33 at boot, works fine with 33
-PEAQ C1010: 1920x1200, 33 at boot, works fine with 33
-PoV mobii-wintab-800w: 800x1280, 33 at boot, works fine with 33
-Asus Transformer-T100TA: 1368x768, 32 at boot, works fine with 32


and lower clock shift the image in all of them?


No, just on the Chuwi Vi8, the tests was to make sure the higher clock
does not create problems elsewhere and I was curious what clock the GOP
was using on other devices. Also hence the "requires 33 to work properly"
vs "works fine with 33" in the list.


So it seems that the GOP is always using what vlv_calc_cdclk calls
freq_320 as cdclk clock. Also note the comment in vlv_calc_cdclk about
it avoiding 200 Mhz as clock because that causes issues in some cases.

This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
panel is active.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_cdclk.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 9c5ceb98d48f..cfb3f7fb3e1c 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
min_cdclk = max(2 * 96000, min_cdclk);
  
+	/*

+* On Valleyview the GOP always uses 32/33 KHz if DSI is used,
+* using a lower clock causes causes sync issues with some panels.
+*/


Afaik (afai-have-noticed) GOP always use the higher freq and higher rates
that panels support with no care about saving any power. So I'm not sure if
that should be used as any sort of reference for us.

Note I'm not telling to not add the workaround itself...


So you're suggesting to change the comment into something like this
instead ?  :

/*
 * On Valleyview some DSI panels loose (v|h)sync when the clock is lower
 * then 32KHz.
 */




+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
+   IS_VALLEYVIEW(dev_priv))
+   min_cdclk = max(32, min_cdclk);
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
  min_cdclk, dev_priv->max_cdclk_freq);
--
2.14.3



Regards,

Hans
___
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: Grab power domain in skl_pipe_wm_get_hw_state()

[Patchwork]

== Series Details ==

Series: drm/i915: Grab power domain in skl_pipe_wm_get_hw_state()
URL   : https://patchwork.freedesktop.org/series/35577/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test kms_flip:
Subgroup wf_vblank-vs-modeset-interruptible:
pass   -> DMESG-WARN (shard-hsw) fdo#102614
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-hsw) fdo#104218
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
dmesg-warn -> PASS   (shard-snb)

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218

shard-hswtotal:2683 pass:1516 dwarn:2   dfail:0   fail:10  skip:1154 
time:9233s
shard-snbtotal:2712 pass:1308 dwarn:1   dfail:0   fail:12  skip:1391 
time:8091s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Ville Syrjälä]

On Tue, Dec 19, 2017 at 08:31:07PM +0100, Hans de Goede wrote:
> Hi,
> 
> I forgot to add a coverletter, anyways what I wanted to put in the
> coverletter and not in the commit message is a link to a picture of the
> problem this fixes:
> 
> https://fedorapeople.org/~jwrdegoede/IMG_20171217_195637.jpg
> 
> Note the screen is actually a portrait screen, so the picture is the
> right way up. Beside the obvious left shift with wrap-around of the
> picture, also all the green in there is supposed to be blue.
> 
> Another less clear picture is this one:
> 
> https://fedorapeople.org/~jwrdegoede/IMG_20171217_195507.jpg
> 
> Again with wrong colors.
> 
> ###
> 
> While working on this I also noticed that the pixelclock as
> the driver gets it from the VBT is not the same as the one the
> GOP uses, on the tablet in question the VBT says 77000 KHz
> and the GOP uses (according to the initial readback) 78125 KHz,
> on another tablet I noticed the VBT saying 78125 KHz, where
> as the GOP was using 68xxx KHz which came to a refresh-rate
> of around 60 Hz, where as the VBT value is 69 Hz IIRC.
> 
> Neither of these cause any actual issue (fixing the pixelclock
> to match the GOP programmed value does not fix the issue, where
> as using the GOP cdclk of 33KHz does).

https://patchwork.freedesktop.org/patch/127189/

I suppose it's unlike that would help here since it's just about the 
overlap in dual link mode, but there could be other fail in the DSI
clock code.


-- 
Ville Syrjälä
Intel OTC
___
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/vlv: Add cdclk workaround for DSI

[Patchwork]

== Series Details ==

Series: drm/i915/vlv: Add cdclk workaround for DSI
URL   : https://patchwork.freedesktop.org/series/35598/
State : success

== Summary ==

Series 35598v1 drm/i915/vlv: Add cdclk workaround for DSI
https://patchwork.freedesktop.org/api/1.0/series/35598/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:477s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:264s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:383s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:427s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:518s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:527s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:442s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:554s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:558s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-cnl-y total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:620s
fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7541/fi-bdw-gvtdvm/igt.log

cd7e14499b1dbbcb6ea97695ebe39e60b5200cc8 drm-tip: 2017y-12m-19d-15h-09m-52s UTC 
integration manifest
72e663cabae3 drm/i915/vlv: Add cdclk workaround for DSI

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Rodrigo Vivi]

On Tue, Dec 19, 2017 at 07:21:13PM +, Hans de Goede wrote:
> At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
> shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
> colors, showing that the panel controller is starting with sampling the
> datastream somewhere mid-line. This happens after the first blanking and
> re-init of the panel.
> 
> After looking at drm.debug output I noticed that initially we inherit the
> cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
> KHz, which turns out to be the cause of this problem, a quick hack to hard
> code the cdclk to 33 KHz makes the problem go away.
> 
> I've tested this on various Bay Trail devices:
> -Chuwi Vi8: 800x1280, 33 at boot, requires 33 to work properly
> -GP-electronic T701: 1024x600, 33 at boot, works fine with 33
> -PEAQ C1010: 1920x1200, 33 at boot, works fine with 33
> -PoV mobii-wintab-800w: 800x1280, 33 at boot, works fine with 33
> -Asus Transformer-T100TA: 1368x768, 32 at boot, works fine with 32

and lower clock shift the image in all of them?

> 
> So it seems that the GOP is always using what vlv_calc_cdclk calls
> freq_320 as cdclk clock. Also note the comment in vlv_calc_cdclk about
> it avoiding 200 Mhz as clock because that causes issues in some cases.
> 
> This commit extends the "do not use 200 Mhz" workaround with an extra
> check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
> panel is active.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/intel_cdclk.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index 9c5ceb98d48f..cfb3f7fb3e1c 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct 
> intel_crtc_state *crtc_state)
>   if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
>   min_cdclk = max(2 * 96000, min_cdclk);
>  
> + /*
> +  * On Valleyview the GOP always uses 32/33 KHz if DSI is used,
> +  * using a lower clock causes causes sync issues with some panels.
> +  */

Afaik (afai-have-noticed) GOP always use the higher freq and higher rates
that panels support with no care about saving any power. So I'm not sure if
that should be used as any sort of reference for us.

Note I'm not telling to not add the workaround itself...

> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> + IS_VALLEYVIEW(dev_priv))
> + min_cdclk = max(32, min_cdclk);
> +
>   if (min_cdclk > dev_priv->max_cdclk_freq) {
>   DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
> min_cdclk, dev_priv->max_cdclk_freq);
> -- 
> 2.14.3
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Hans de Goede]

Hi,

I forgot to add a coverletter, anyways what I wanted to put in the
coverletter and not in the commit message is a link to a picture of the
problem this fixes:

https://fedorapeople.org/~jwrdegoede/IMG_20171217_195637.jpg

Note the screen is actually a portrait screen, so the picture is the
right way up. Beside the obvious left shift with wrap-around of the
picture, also all the green in there is supposed to be blue.

Another less clear picture is this one:

https://fedorapeople.org/~jwrdegoede/IMG_20171217_195507.jpg

Again with wrong colors.

###

While working on this I also noticed that the pixelclock as
the driver gets it from the VBT is not the same as the one the
GOP uses, on the tablet in question the VBT says 77000 KHz
and the GOP uses (according to the initial readback) 78125 KHz,
on another tablet I noticed the VBT saying 78125 KHz, where
as the GOP was using 68xxx KHz which came to a refresh-rate
of around 60 Hz, where as the VBT value is 69 Hz IIRC.

Neither of these cause any actual issue (fixing the pixelclock
to match the GOP programmed value does not fix the issue, where
as using the GOP cdclk of 33KHz does).

Regards,

Hans



On 19-12-17 20:21, Hans de Goede wrote:

At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.

After looking at drm.debug output I noticed that initially we inherit the
cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 33 KHz makes the problem go away.

I've tested this on various Bay Trail devices:
-Chuwi Vi8: 800x1280, 33 at boot, requires 33 to work properly
-GP-electronic T701: 1024x600, 33 at boot, works fine with 33
-PEAQ C1010: 1920x1200, 33 at boot, works fine with 33
-PoV mobii-wintab-800w: 800x1280, 33 at boot, works fine with 33
-Asus Transformer-T100TA: 1368x768, 32 at boot, works fine with 32

So it seems that the GOP is always using what vlv_calc_cdclk calls
freq_320 as cdclk clock. Also note the comment in vlv_calc_cdclk about
it avoiding 200 Mhz as clock because that causes issues in some cases.

This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
panel is active.

Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_cdclk.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 9c5ceb98d48f..cfb3f7fb3e1c 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
min_cdclk = max(2 * 96000, min_cdclk);
  
+	/*

+* On Valleyview the GOP always uses 32/33 KHz if DSI is used,
+* using a lower clock causes causes sync issues with some panels.
+*/
+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
+   IS_VALLEYVIEW(dev_priv))
+   min_cdclk = max(32, min_cdclk);
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
  min_cdclk, dev_priv->max_cdclk_freq);


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

[Intel-gfx] [PATCH] drm/i915/vlv: Add cdclk workaround for DSI

[Hans de Goede]

At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.

After looking at drm.debug output I noticed that initially we inherit the
cdclk of 33 KHz set by the GOP, but after the re-init we picked 27
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 33 KHz makes the problem go away.

I've tested this on various Bay Trail devices:
-Chuwi Vi8: 800x1280, 33 at boot, requires 33 to work properly
-GP-electronic T701: 1024x600, 33 at boot, works fine with 33
-PEAQ C1010: 1920x1200, 33 at boot, works fine with 33
-PoV mobii-wintab-800w: 800x1280, 33 at boot, works fine with 33
-Asus Transformer-T100TA: 1368x768, 32 at boot, works fine with 32

So it seems that the GOP is always using what vlv_calc_cdclk calls
freq_320 as cdclk clock. Also note the comment in vlv_calc_cdclk about
it avoiding 200 Mhz as clock because that causes issues in some cases.

This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 32 KHz (avoiding 27 KHz) when a DSI
panel is active.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 9c5ceb98d48f..cfb3f7fb3e1c 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9)
min_cdclk = max(2 * 96000, min_cdclk);
 
+   /*
+* On Valleyview the GOP always uses 32/33 KHz if DSI is used,
+* using a lower clock causes causes sync issues with some panels.
+*/
+   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
+   IS_VALLEYVIEW(dev_priv))
+   min_cdclk = max(32, min_cdclk);
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
  min_cdclk, dev_priv->max_cdclk_freq);
-- 
2.14.3

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

Re: [Intel-gfx] [-next PATCH 0/4] sysfs and DEVICE_ATTR_

[Jani Nikula]

On Tue, 19 Dec 2017, Joe Perches  wrote:
>  drivers/gpu/drm/i915/i915_sysfs.c  | 12 ++--

For i915,

Acked-by: Jani Nikula 


-- 
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] [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Andy Shevchenko]

On Tue, Dec 19, 2017 at 8:15 PM, Joe Perches  wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
>   xargs perl -i -e 'local $/; while (<>) { 
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g;
>  print;}'

>  drivers/platform/x86/compal-laptop.c | 18 +--

> --- a/drivers/platform/x86/compal-laptop.c
> +++ b/drivers/platform/x86/compal-laptop.c
> @@ -679,18 +679,12 @@ static int bat_writeable_property(struct power_supply 
> *psy,
>  /* == */
>  /* Driver Globals */
>  /* == */
> -static DEVICE_ATTR(wake_up_pme,
> -   0644, wake_up_pme_show, wake_up_pme_store);
> -static DEVICE_ATTR(wake_up_modem,
> -   0644, wake_up_modem_show,   wake_up_modem_store);
> -static DEVICE_ATTR(wake_up_lan,
> -   0644, wake_up_lan_show, wake_up_lan_store);
> -static DEVICE_ATTR(wake_up_wlan,
> -   0644, wake_up_wlan_show,wake_up_wlan_store);
> -static DEVICE_ATTR(wake_up_key,
> -   0644, wake_up_key_show, wake_up_key_store);
> -static DEVICE_ATTR(wake_up_mouse,
> -   0644, wake_up_mouse_show,   wake_up_mouse_store);
> +static DEVICE_ATTR_RW(wake_up_pme);
> +static DEVICE_ATTR_RW(wake_up_modem);
> +static DEVICE_ATTR_RW(wake_up_lan);
> +static DEVICE_ATTR_RW(wake_up_wlan);
> +static DEVICE_ATTR_RW(wake_up_key);
> +static DEVICE_ATTR_RW(wake_up_mouse);

Acked-by: Andy Shevchenko 

for PDx86 bits.

Have to say that while it doesn't change the attributes here, it might
require still to be revisited by security people, if they wish.

-- 
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW

[Joe Perches]

Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.

Done with perl script:

$ git grep -w --name-only DEVICE_ATTR | \
  xargs perl -i -e 'local $/; while (<>) { 
s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g;
 print;}'

Signed-off-by: Joe Perches 
---
 arch/s390/kernel/topology.c  |  3 +--
 arch/tile/kernel/sysfs.c |  2 +-
 drivers/gpu/drm/i915/i915_sysfs.c|  6 ++---
 drivers/platform/x86/compal-laptop.c | 18 +--
 drivers/s390/cio/device.c|  2 +-
 drivers/scsi/lpfc/lpfc_attr.c| 43 
 drivers/thermal/thermal_sysfs.c  |  9 
 drivers/tty/serial/sh-sci.c  |  2 +-
 drivers/usb/host/xhci-dbgcap.c   |  2 +-
 drivers/usb/phy/phy-tahvo.c  |  2 +-
 drivers/video/fbdev/auo_k190x.c  |  4 ++--
 drivers/video/fbdev/w100fb.c |  4 ++--
 lib/test_firmware.c  | 14 +---
 lib/test_kmod.c  | 14 +---
 sound/soc/omap/mcbsp.c   |  4 ++--
 15 files changed, 49 insertions(+), 80 deletions(-)

diff --git a/arch/s390/kernel/topology.c b/arch/s390/kernel/topology.c
index 4d5b65e527b5..4b6e0397f66d 100644
--- a/arch/s390/kernel/topology.c
+++ b/arch/s390/kernel/topology.c
@@ -404,8 +404,7 @@ static ssize_t dispatching_store(struct device *dev,
put_online_cpus();
return rc ? rc : count;
 }
-static DEVICE_ATTR(dispatching, 0644, dispatching_show,
-dispatching_store);
+static DEVICE_ATTR_RW(dispatching);
 
 static ssize_t cpu_polarization_show(struct device *dev,
 struct device_attribute *attr, char *buf)
diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
index 825867c53853..af5024f0fb5a 100644
--- a/arch/tile/kernel/sysfs.c
+++ b/arch/tile/kernel/sysfs.c
@@ -184,7 +184,7 @@ static ssize_t hv_stats_store(struct device *dev,
return n < 0 ? n : count;
 }
 
-static DEVICE_ATTR(hv_stats, 0644, hv_stats_show, hv_stats_store);
+static DEVICE_ATTR_RW(hv_stats);
 
 static int hv_stats_device_add(struct device *dev, struct subsys_interface 
*sif)
 {
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index c74a20b80182..1d0ab8ff5915 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -447,9 +447,9 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
 
 static DEVICE_ATTR(gt_act_freq_mhz, S_IRUGO, gt_act_freq_mhz_show, NULL);
 static DEVICE_ATTR(gt_cur_freq_mhz, S_IRUGO, gt_cur_freq_mhz_show, NULL);
-static DEVICE_ATTR(gt_boost_freq_mhz, S_IRUGO | S_IWUSR, 
gt_boost_freq_mhz_show, gt_boost_freq_mhz_store);
-static DEVICE_ATTR(gt_max_freq_mhz, S_IRUGO | S_IWUSR, gt_max_freq_mhz_show, 
gt_max_freq_mhz_store);
-static DEVICE_ATTR(gt_min_freq_mhz, S_IRUGO | S_IWUSR, gt_min_freq_mhz_show, 
gt_min_freq_mhz_store);
+static DEVICE_ATTR_RW(gt_boost_freq_mhz);
+static DEVICE_ATTR_RW(gt_max_freq_mhz);
+static DEVICE_ATTR_RW(gt_min_freq_mhz);
 
 static DEVICE_ATTR(vlv_rpe_freq_mhz, S_IRUGO, vlv_rpe_freq_mhz_show, NULL);
 
diff --git a/drivers/platform/x86/compal-laptop.c 
b/drivers/platform/x86/compal-laptop.c
index 6bcb750e1865..4f9bc72f0584 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -679,18 +679,12 @@ static int bat_writeable_property(struct power_supply 
*psy,
 /* == */
 /* Driver Globals */
 /* == */
-static DEVICE_ATTR(wake_up_pme,
-   0644, wake_up_pme_show, wake_up_pme_store);
-static DEVICE_ATTR(wake_up_modem,
-   0644, wake_up_modem_show,   wake_up_modem_store);
-static DEVICE_ATTR(wake_up_lan,
-   0644, wake_up_lan_show, wake_up_lan_store);
-static DEVICE_ATTR(wake_up_wlan,
-   0644, wake_up_wlan_show,wake_up_wlan_store);
-static DEVICE_ATTR(wake_up_key,
-   0644, wake_up_key_show, wake_up_key_store);
-static DEVICE_ATTR(wake_up_mouse,
-   0644, wake_up_mouse_show,   wake_up_mouse_store);
+static DEVICE_ATTR_RW(wake_up_pme);
+static DEVICE_ATTR_RW(wake_up_modem);
+static DEVICE_ATTR_RW(wake_up_lan);
+static DEVICE_ATTR_RW(wake_up_wlan);
+static DEVICE_ATTR_RW(wake_up_key);
+static DEVICE_ATTR_RW(wake_up_mouse);
 
 static DEVICE_ATTR(fan1_input,  S_IRUGO, fan_show,  NULL);
 static DEVICE_ATTR(temp1_input, S_IRUGO, temp_cpu,  NULL);
diff --git a/drivers/s390/cio/device.c b/drivers/s390/cio/device.c
index 75a245f38e2e..6eefb67b31f3 100644
--- a/drivers/s390/cio/device.c
+++ b/drivers/s390/cio/device.c
@@ -600,7 +600,7 @@ static ssize_t vpm_show(struct device *dev, struct 
device_attribute *attr,
 static DEVICE_ATTR(devtype, 0444, devtype_show, NULL);
 static DEVICE_ATTR(cutype, 0444, cutype_show, NULL);
 static DEVICE_ATTR(modalias, 0444, modalias_show, 

[Intel-gfx] [-next PATCH 0/4] sysfs and DEVICE_ATTR_

[Joe Perches]

Joe Perches (4):
  sysfs.h: Use octal permissions
  treewide: Use DEVICE_ATTR_RW
  treewide: Use DEVICE_ATTR_RO
  treewide: Use DEVICE_ATTR_WO

 arch/arm/mach-pxa/sharpsl_pm.c |  4 +-
 arch/s390/kernel/smp.c |  2 +-
 arch/s390/kernel/topology.c|  3 +-
 arch/sh/drivers/push-switch.c  |  2 +-
 arch/tile/kernel/sysfs.c   | 12 ++--
 arch/x86/kernel/cpu/microcode/core.c   |  2 +-
 drivers/acpi/device_sysfs.c|  6 +-
 drivers/char/ipmi/ipmi_msghandler.c| 17 +++---
 drivers/gpu/drm/i915/i915_sysfs.c  | 12 ++--
 drivers/input/touchscreen/elants_i2c.c |  2 +-
 drivers/net/ethernet/ibm/ibmvnic.c |  2 +-
 drivers/net/wimax/i2400m/sysfs.c   |  3 +-
 drivers/nvme/host/core.c   | 10 ++--
 drivers/platform/x86/compal-laptop.c   | 18 ++
 drivers/s390/cio/css.c |  8 +--
 drivers/s390/cio/device.c  | 10 ++--
 drivers/s390/crypto/ap_card.c  |  2 +-
 drivers/scsi/hpsa.c| 10 ++--
 drivers/scsi/lpfc/lpfc_attr.c  | 64 --
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |  8 +--
 drivers/thermal/thermal_sysfs.c| 17 +++---
 drivers/tty/serial/sh-sci.c|  2 +-
 drivers/usb/host/xhci-dbgcap.c |  2 +-
 drivers/usb/phy/phy-tahvo.c|  2 +-
 drivers/video/fbdev/auo_k190x.c|  4 +-
 drivers/video/fbdev/w100fb.c   |  4 +-
 include/linux/sysfs.h  | 14 ++---
 lib/test_firmware.c| 14 ++---
 lib/test_kmod.c| 14 ++---
 sound/soc/omap/mcbsp.c |  4 +-
 sound/soc/soc-core.c   |  2 +-
 sound/soc/soc-dapm.c   |  2 +-
 32 files changed, 120 insertions(+), 158 deletions(-)

-- 
2.15.0

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

[Intel-gfx] [-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

[Joe Perches]

Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.

Done with perl script:

$ git grep -w --name-only DEVICE_ATTR | \
  xargs perl -i -e 'local $/; while (<>) { 
s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g;
 print;}'

Signed-off-by: Joe Perches 
---
 arch/arm/mach-pxa/sharpsl_pm.c   |  4 ++--
 arch/sh/drivers/push-switch.c|  2 +-
 arch/tile/kernel/sysfs.c | 10 +-
 drivers/acpi/device_sysfs.c  |  6 +++---
 drivers/char/ipmi/ipmi_msghandler.c  | 17 -
 drivers/gpu/drm/i915/i915_sysfs.c|  6 +++---
 drivers/nvme/host/core.c | 10 +-
 drivers/s390/cio/css.c   |  8 
 drivers/s390/cio/device.c|  8 
 drivers/s390/crypto/ap_card.c|  2 +-
 drivers/scsi/hpsa.c  | 10 +-
 drivers/scsi/lpfc/lpfc_attr.c| 18 --
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c |  8 
 drivers/thermal/thermal_sysfs.c  |  6 +++---
 sound/soc/soc-core.c |  2 +-
 sound/soc/soc-dapm.c |  2 +-
 16 files changed, 58 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 398ba9ba2632..ef9fd9b759cb 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -802,8 +802,8 @@ static ssize_t battery_voltage_show(struct device *dev, 
struct device_attribute
return sprintf(buf, "%d\n", sharpsl_pm.battstat.mainbat_voltage);
 }
 
-static DEVICE_ATTR(battery_percentage, 0444, battery_percentage_show, NULL);
-static DEVICE_ATTR(battery_voltage, 0444, battery_voltage_show, NULL);
+static DEVICE_ATTR_RO(battery_percentage);
+static DEVICE_ATTR_RO(battery_voltage);
 
 extern void (*apm_get_power_status)(struct apm_power_info *);
 
diff --git a/arch/sh/drivers/push-switch.c b/arch/sh/drivers/push-switch.c
index a17181160233..762bc5619910 100644
--- a/arch/sh/drivers/push-switch.c
+++ b/arch/sh/drivers/push-switch.c
@@ -24,7 +24,7 @@ static ssize_t switch_show(struct device *dev,
struct push_switch_platform_info *psw_info = dev->platform_data;
return sprintf(buf, "%s\n", psw_info->name);
 }
-static DEVICE_ATTR(switch, S_IRUGO, switch_show, NULL);
+static DEVICE_ATTR_RO(switch);
 
 static void switch_timer(struct timer_list *t)
 {
diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
index af5024f0fb5a..b09456a3d77a 100644
--- a/arch/tile/kernel/sysfs.c
+++ b/arch/tile/kernel/sysfs.c
@@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev,
 {
return sprintf(page, "%u\n", smp_width);
 }
-static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL);
+static DEVICE_ATTR_RO(chip_width);
 
 static ssize_t chip_height_show(struct device *dev,
struct device_attribute *attr,
@@ -46,7 +46,7 @@ static ssize_t chip_height_show(struct device *dev,
 {
return sprintf(page, "%u\n", smp_height);
 }
-static DEVICE_ATTR(chip_height, 0444, chip_height_show, NULL);
+static DEVICE_ATTR_RO(chip_height);
 
 static ssize_t chip_serial_show(struct device *dev,
struct device_attribute *attr,
@@ -54,7 +54,7 @@ static ssize_t chip_serial_show(struct device *dev,
 {
return get_hv_confstr(page, HV_CONFSTR_CHIP_SERIAL_NUM);
 }
-static DEVICE_ATTR(chip_serial, 0444, chip_serial_show, NULL);
+static DEVICE_ATTR_RO(chip_serial);
 
 static ssize_t chip_revision_show(struct device *dev,
  struct device_attribute *attr,
@@ -62,7 +62,7 @@ static ssize_t chip_revision_show(struct device *dev,
 {
return get_hv_confstr(page, HV_CONFSTR_CHIP_REV);
 }
-static DEVICE_ATTR(chip_revision, 0444, chip_revision_show, NULL);
+static DEVICE_ATTR_RO(chip_revision);
 
 
 static ssize_t type_show(struct device *dev,
@@ -71,7 +71,7 @@ static ssize_t type_show(struct device *dev,
 {
return sprintf(page, "tilera\n");
 }
-static DEVICE_ATTR(type, 0444, type_show, NULL);
+static DEVICE_ATTR_RO(type);
 
 #define HV_CONF_ATTR(name, conf)   \
static ssize_t name ## _show(struct device *dev,\
diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
index a041689e5701..545e91420cde 100644
--- a/drivers/acpi/device_sysfs.c
+++ b/drivers/acpi/device_sysfs.c
@@ -357,7 +357,7 @@ static ssize_t real_power_state_show(struct device *dev,
return sprintf(buf, "%s\n", acpi_power_state_string(state));
 }
 
-static DEVICE_ATTR(real_power_state, 0444, real_power_state_show, NULL);
+static DEVICE_ATTR_RO(real_power_state);
 
 static ssize_t 

[Intel-gfx] ✗ Fi.CI.BAT: warning for overlay: parse tracepoints from sysfs to figure out fields' location (rev6)

[Patchwork]

== Series Details ==

Series: overlay: parse tracepoints from sysfs to figure out fields' location 
(rev6)
URL   : https://patchwork.freedesktop.org/series/35545/
State : warning

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3549
cd7e14499b1d drm-tip: 2017y-12m-19d-15h-09m-52s UTC integration manifest

No testlist changes.

Test kms_force_connector_basic:
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-snb-2520m)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:487s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:262s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:385s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:429s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:478s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:521s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:522s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:247  dwarn:0   dfail:0   fail:0   skip:41  
time:559s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:600s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:626s

== Logs ==

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

[Intel-gfx] [PATCH i-g-t v6] overlay: parse tracepoints from sysfs to figure out fields' location

[Lionel Landwerlin]

With changes going to drm-tip, the tracepoints field locations are
going to change. This change introduces a tracepoint parser (using a
peg parser) which lets us figure out field positions on the fly.

v2: Fix automake build (Lionel)

v3: Make overlay build conditional on peg (Petri)
Make wait_end callback more readable (Chris)
Drop tracepoint_id(), instead parsing from format file (Lionel)

v4: Fix existing configure.ac issue with overlay build (Petri)

v5: Silence unused function (Lionel)

v6: Fix missing double quote in v4 (Lionel)

Signed-off-by: Lionel Landwerlin 
Acked-by: Chris Wilson 
For the build system changes:
Acked-by: Petri Latvala 
---
 configure.ac  |   9 ++-
 overlay/Makefile.am   |   5 ++
 overlay/gpu-perf.c| 164 --
 overlay/meson.build   |  13 +++-
 overlay/tracepoint_format.leg |  35 +
 5 files changed, 186 insertions(+), 40 deletions(-)
 create mode 100644 overlay/tracepoint_format.leg

diff --git a/configure.ac b/configure.ac
index 8740f7a4..7e847574 100644
--- a/configure.ac
+++ b/configure.ac
@@ -146,6 +146,13 @@ if test x"$build_x86" = xyes; then
AS_IF([test x"$LEX" != "x:" -a x"$YACC" != xyacc],
[enable_assembler=yes],
[enable_assembler=no])
+
+   AC_CHECK_TOOL([LEG], [leg])
+   if test x"$LEG" != xleg; then
+   enable_overlay_xvlib="no"
+   enable_overlay_xlib="no"
+   AC_MSG_NOTICE([Failed to find leg, required for overlay, try : 
apt-get install peg])
+   fi
 else
enable_overlay_xvlib="no"
enable_overlay_xlib="no"
@@ -158,7 +165,7 @@ AM_CONDITIONAL(BUILD_ASSEMBLER, [test "x$enable_assembler" 
= xyes])
 
 AM_CONDITIONAL(BUILD_OVERLAY_XVLIB, [test "x$enable_overlay_xvlib" = xyes])
 AM_CONDITIONAL(BUILD_OVERLAY_XLIB, [test "x$enable_overlay_xlib" = xyes])
-AM_CONDITIONAL(BUILD_OVERLAY, [test "x$enable_overlay_xlib" = xyes -o 
"x$enable_overlay_xvlib"])
+AM_CONDITIONAL(BUILD_OVERLAY, [test "x$enable_overlay_xlib" = xyes -o 
"x$enable_overlay_xvlib" = "xyes"])
 if test x$enable_overlay_xvlib = xyes; then
AC_DEFINE(HAVE_OVERLAY_XVLIB, 1, [Enable XV backend])
 fi
diff --git a/overlay/Makefile.am b/overlay/Makefile.am
index fca04cae..0f553b7c 100644
--- a/overlay/Makefile.am
+++ b/overlay/Makefile.am
@@ -1,7 +1,12 @@
 if BUILD_OVERLAY
 bin_PROGRAMS = intel-gpu-overlay
+
+BUILT_SOURCES = tracepoint_format.h
 endif
 
+tracepoint_format.h: tracepoint_format.leg
+   $(LEG) -o $@ $<
+
 AM_CPPFLAGS = -I. -I$(top_srcdir)/include/drm-uapi
 AM_CFLAGS = $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) \
$(CAIRO_CFLAGS) $(OVERLAY_CFLAGS) $(WERROR_CFLAGS) -I$(srcdir)/../lib
diff --git a/overlay/gpu-perf.c b/overlay/gpu-perf.c
index 3d4a9be9..0abd937e 100644
--- a/overlay/gpu-perf.c
+++ b/overlay/gpu-perf.c
@@ -57,39 +57,125 @@ struct sample_event {
uint64_t time;
uint64_t id;
uint32_t raw_size;
-   uint32_t raw_hdr0;
-   uint32_t raw_hdr1;
-   uint32_t raw[0];
+   uint8_t tracepoint_data[0];
 };
 
 enum {
-   DEVICE = 0,
-   CTX,
-   ENGINE,
-   CTX_SEQNO,
-   GLOBAL_SEQNO
+   TP_GEM_REQUEST_ADD,
+   TP_GEM_REQUEST_WAIT_BEGIN,
+   TP_GEM_REQUEST_WAIT_END,
+   TP_FLIP_COMPLETE,
+   TP_GEM_RING_SYNC_TO,
+   TP_GEM_RING_SWITCH_CONTEXT,
+
+   TP_NB
 };
 
-static uint64_t tracepoint_id(const char *sys, const char *name)
+struct tracepoint {
+   const char *name;
+   int event_id;
+
+   struct {
+   char name[128];
+   int offset;
+   int size;
+   int is_signed;
+   } fields[20];
+   int n_fields;
+
+   int device_field;
+   int ctx_field;
+   int ring_field;
+   int seqno_field;
+   int global_seqno_field;
+   int plane_field;
+} tracepoints[TP_NB] = {
+   [TP_GEM_REQUEST_ADD] = { .name = "i915/i915_gem_request_add", },
+   [TP_GEM_REQUEST_WAIT_BEGIN]  = { .name = 
"i915/i915_gem_request_wait_begin", },
+   [TP_GEM_REQUEST_WAIT_END]= { .name = 
"i915/i915_gem_request_wait_end", },
+   [TP_FLIP_COMPLETE]   = { .name = "i915/flip_complete", },
+   [TP_GEM_RING_SYNC_TO]= { .name = "i915/gem_ring_sync_to", },
+   [TP_GEM_RING_SWITCH_CONTEXT] = { .name = 
"i915/gem_ring_switch_context", },
+};
+
+union parser_value {
+char *string;
+int integer;
+};
+
+struct parser_ctx {
+   struct tracepoint *tp;
+   FILE *fp;
+};
+
+#define YY_CTX_LOCAL
+#define YY_CTX_MEMBERS struct parser_ctx ctx;
+#define YYSTYPE union parser_value
+#define YY_LOCAL(T) static __attribute__((unused)) T
+#define YY_PARSE(T) static T
+#define YY_INPUT(yy, buf, result, max) \
+   {   \
+   int c = 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] lib/dummyload: Support returning output fence

[Patchwork]

== Series Details ==

Series: series starting with [1/3] lib/dummyload: Support returning output fence
URL   : https://patchwork.freedesktop.org/series/35589/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3549
cd7e14499b1d drm-tip: 2017y-12m-19d-15h-09m-52s UTC integration manifest

Testlist changes:
+igt@perf_pmu@busy-accuracy-2-bcs0
+igt@perf_pmu@busy-accuracy-2-rcs0
+igt@perf_pmu@busy-accuracy-2-vcs0
+igt@perf_pmu@busy-accuracy-2-vcs1
+igt@perf_pmu@busy-accuracy-2-vecs0
+igt@perf_pmu@busy-accuracy-50-bcs0
+igt@perf_pmu@busy-accuracy-50-rcs0
+igt@perf_pmu@busy-accuracy-50-vcs0
+igt@perf_pmu@busy-accuracy-50-vcs1
+igt@perf_pmu@busy-accuracy-50-vecs0
+igt@perf_pmu@busy-accuracy-98-bcs0
+igt@perf_pmu@busy-accuracy-98-rcs0
+igt@perf_pmu@busy-accuracy-98-vcs0
+igt@perf_pmu@busy-accuracy-98-vcs1
+igt@perf_pmu@busy-accuracy-98-vecs0

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:442s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:393s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:502s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:262s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:420s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:397s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:425s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:517s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:547s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:413s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:598s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:655s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_706/issues.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 lib: Convert sw_sync to use sync_file uapi imported from the kernel

[Patchwork]

== Series Details ==

Series: lib: Convert sw_sync to use sync_file uapi imported from the kernel
URL   : https://patchwork.freedesktop.org/series/35587/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3549
cd7e14499b1d drm-tip: 2017y-12m-19d-15h-09m-52s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989 +1
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:435s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:501s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:276s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:480s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:266s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:391s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:424s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:513s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:533s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:512s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:545s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:413s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:597s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:630s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for overlay: parse tracepoints from sysfs to figure out fields' location (rev5)

[Patchwork]

== Series Details ==

Series: overlay: parse tracepoints from sysfs to figure out fields' location 
(rev5)
URL   : https://patchwork.freedesktop.org/series/35545/
State : failure

== Summary ==

IGT patchset build failed on latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

checking if gcc supports -Werror=write-strings... yes
checking if gcc supports -Werror=address... yes
checking if gcc supports -Werror=int-to-pointer-cast... yes
checking if gcc supports -Werror=pointer-to-int-cast... yes
checking if gcc supports -pedantic... yes
checking if gcc supports -Werror... yes
checking if gcc supports -Werror=attributes... yes
checking whether make supports nested variables... (cached) yes
checking for DRM... yes
checking for PCIACCESS... yes
checking for KMOD... yes
checking for PROCPS... yes
checking for LIBUNWIND... yes
checking for VALGRIND... no
checking for OVERLAY_XVLIB... yes
checking for OVERLAY_XLIB... yes
checking for leg... no
configure: leg command missing, disabling overlay; try : apt-get install peg
./configure: line 21894: syntax error near unexpected token `('
./configure: line 21894: `  as_fn_error $? "Package requirements (cairo >= 
1.12.0) were not met:'

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Exercise creating context with shared GTT (rev2)

[Patchwork]

== Series Details ==

Series: igt: Exercise creating context with shared GTT (rev2)
URL   : https://patchwork.freedesktop.org/series/35406/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3549
cd7e14499b1d drm-tip: 2017y-12m-19d-15h-09m-52s UTC integration manifest

Testlist changes:
+igt@gem_ctx_shared@create-shared-gtt
+igt@gem_ctx_shared@detached-shared-gtt
+igt@gem_ctx_shared@disjoint-timelines
+igt@gem_ctx_shared@exec-shared-gtt-blt
+igt@gem_ctx_shared@exec-shared-gtt-bsd
+igt@gem_ctx_shared@exec-shared-gtt-bsd1
+igt@gem_ctx_shared@exec-shared-gtt-bsd2
+igt@gem_ctx_shared@exec-shared-gtt-default
+igt@gem_ctx_shared@exec-shared-gtt-render
+igt@gem_ctx_shared@exec-shared-gtt-vebox
+igt@gem_ctx_shared@exhaust-shared-gtt
+igt@gem_ctx_shared@exhaust-shared-gtt-lrc
+igt@gem_ctx_shared@q-in-order-blt
+igt@gem_ctx_shared@q-in-order-bsd
+igt@gem_ctx_shared@q-in-order-bsd1
+igt@gem_ctx_shared@q-in-order-bsd2
+igt@gem_ctx_shared@q-in-order-default
+igt@gem_ctx_shared@q-in-order-render
+igt@gem_ctx_shared@q-in-order-vebox
+igt@gem_ctx_shared@q-out-order-blt
+igt@gem_ctx_shared@q-out-order-bsd
+igt@gem_ctx_shared@q-out-order-bsd1
+igt@gem_ctx_shared@q-out-order-bsd2
+igt@gem_ctx_shared@q-out-order-default
+igt@gem_ctx_shared@q-out-order-render
+igt@gem_ctx_shared@q-out-order-vebox
+igt@gem_ctx_shared@q-promotion-blt
+igt@gem_ctx_shared@q-promotion-bsd
+igt@gem_ctx_shared@q-promotion-bsd1
+igt@gem_ctx_shared@q-promotion-bsd2
+igt@gem_ctx_shared@q-promotion-default
+igt@gem_ctx_shared@q-promotion-render
+igt@gem_ctx_shared@q-promotion-vebox
+igt@gem_ctx_shared@q-smoketest-all
+igt@gem_ctx_shared@q-smoketest-blt
+igt@gem_ctx_shared@q-smoketest-bsd
+igt@gem_ctx_shared@q-smoketest-bsd1
+igt@gem_ctx_shared@q-smoketest-bsd2
+igt@gem_ctx_shared@q-smoketest-default
+igt@gem_ctx_shared@q-smoketest-render
+igt@gem_ctx_shared@q-smoketest-vebox

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:437s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:497s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:482s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:265s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:388s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:427s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:478s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:519s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:524s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:555s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:512s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:248  

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/pm_rps: Always allocate spin[0] (rev2)

[Patchwork]

== Series Details ==

Series: igt/pm_rps: Always allocate spin[0] (rev2)
URL   : https://patchwork.freedesktop.org/series/35176/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
da0889bfacff106fb3ecb7049a7a21f78b4b301b igt/kms_frontbuffer_tracking: Access 
via GGTT is not guaranteed to be tracked

with latest DRM-Tip kernel build CI_DRM_3549
cd7e14499b1d drm-tip: 2017y-12m-19d-15h-09m-52s UTC integration manifest

No testlist changes.

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:503s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:263s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:532s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:418s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:397s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:521s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:523s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:531s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:556s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:511s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:417s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:594s
fi-cnl-y total:288  pass:260  dwarn:0   dfail:0   fail:2   skip:26  
time:598s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_702/issues.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: Show if we consider the engine is idle in the GPU error state

[Patchwork]

== Series Details ==

Series: drm/i915: Show if we consider the engine is idle in the GPU error state
URL   : https://patchwork.freedesktop.org/series/35581/
State : success

== Summary ==

Series 35581v1 drm/i915: Show if we consider the engine is idle in the GPU 
error state
https://patchwork.freedesktop.org/api/1.0/series/35581/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:433s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:378s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:494s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:264s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:527s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:427s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:475s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:519s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:528s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:555s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:506s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:612s
fi-ilk-650 failed to collect. IGT log at Patchwork_7540/fi-ilk-650/igt.log

cd7e14499b1dbbcb6ea97695ebe39e60b5200cc8 drm-tip: 2017y-12m-19d-15h-09m-52s UTC 
integration manifest
754aed5237cd drm/i915: Show if we consider the engine is idle in the GPU error 
state

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Optimize event parsing and processing

[John Harrison]

On 12/19/2017 3:15 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

A couple of small optimizations which altogether bring around 30%
improvement in my testing.

1. Do less string processing on tracepoints names and push more of the
check into the if-ladder.

2. Pull out common db key and ctx processing and cache common values in
local vars.

3. Key value pair parsing is faster with a regexp.

4. Avoid sorting the db hash multiple times if possible.

Signed-off-by: Tvrtko Ursulin 
Cc: John Harrison 
---
  scripts/trace.pl | 114 ---
  1 file changed, 49 insertions(+), 65 deletions(-)
---
John please check if this helps with your monster traces before we decide
if it is worth putting this in. Well, there isn't much of a downside
except touching something which works and risking breaking it.

diff --git a/scripts/trace.pl b/scripts/trace.pl
index 98e4a9843a43..5463e1fd1954 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -356,110 +356,91 @@ my $prev_freq = 0;
  my $prev_freq_ts = 0;
  while (<>) {
my @fields;
-   my @tmp;
my $tp_name;
-   my $time;
my %tp;
-   my $key;
+   my ($time, $ctx, $ring, $seqno, $orig_ctx, $key);
  
  	chomp;

@fields = split ' ';
  
+	chop $fields[3];

+   $time = int($fields[3] * 100.0);
+
$tp_name = $fields[4];
-   @tmp = split ':', $tp_name, 2;
-   next unless $tmp[0] eq 'i915';
-   $tp_name = $tmp[1];
-   chop $tp_name;
  
-	chop $fields[3];

-   $time = $fields[3] * 100.0;
splice @fields, 0, 5;
  
  	foreach my $f (@fields) {

-   my @kv = split '=|,', $f;
-
-   $kv[0] = 'global' if $kv[0] eq 'global_seqno';
+   my ($k, $v);
  
-		$tp{$kv[0]} = $kv[1];

+   ($k, $v) = ($f =~ /^(\S+)=(\d+)/);
I recall something about using () selection is slower than using 
pre-defined values. E.g.

  $f =~ m/=/; ($k, $v) = ($`, $');

Or do you specifically need the filtering of only matching numeric values?


+   next unless defined $k;
+   $k = 'global' if $k eq 'global_seqno';
+   $tp{$k} = $v;
}
  
  	next if exists $tp{'ring'} and exists $ignore_ring{$tp{'ring'}};
  
-	if ($tp_name eq 'i915_gem_request_wait_begin') {

-   my %rw;
+   if (exists $tp{'ring'} and exists $tp{'ctx'} and exists $tp{'seqno'}) {
+   $ring = $tp{'ring'};
+   $ctx = $tp{'ctx'};
+   $seqno = $tp{'seqno'};
+
+   $orig_ctx = $ctx;
+   $ctx = sanitize_ctx($ctx, $ring);
+   $key = db_key($ring, $ctx, $seqno);
+   }
  
-		$tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});

-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
+   if ($tp_name eq 'i915:i915_gem_request_wait_begin:') {
+   my %rw;
  
  		next if exists $reqwait{$key};
  
  		$rw{'key'} = $key;

-   $rw{'ring'} = $tp{'ring'};
-   $rw{'seqno'} = $tp{'seqno'};
-   $rw{'ctx'} = $tp{'ctx'};
+   $rw{'ring'} = $ring;
+   $rw{'seqno'} = $seqno;
+   $rw{'ctx'} = $ctx;
$rw{'start'} = $time;
$reqwait{$key} = \%rw;
-   next;
-   } elsif ($tp_name eq 'i915_gem_request_wait_end') {
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
+   } elsif ($tp_name eq 'i915:i915_gem_request_wait_end:') {
next unless exists $reqwait{$key};
  
  		$reqwait{$key}->{'end'} = $time;

-   next;
-   } elsif ($tp_name eq 'i915_gem_request_add') {
-   my $orig_ctx = $tp{'ctx'};
-
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
+   } elsif ($tp_name eq 'i915:i915_gem_request_add:') {
if (exists $queue{$key}) {
$ctxdb{$orig_ctx}++;
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
+   $ctx = sanitize_ctx($ctx, $ring);
This bit originally worked on $orig_ctx not $ctx (i.e., before your 
previous refactoring patch). Which should it be? Will a double 
sanitisation step work as intended? I don't actually hit this line in 
any of the runs I've done.




+   $key = db_key($ring, $ctx, $seqno);
}
  
  		$queue{$key} = $time;

-   next;
-   } elsif ($tp_name eq 'i915_gem_request_submit') {
-   $tp{'ctx'} = sanitize_ctx($tp{'ctx'}, $tp{'ring'});
-   $key = db_key($tp{'ring'}, $tp{'ctx'}, $tp{'seqno'});
-
+   } elsif ($tp_name eq 'i915:i915_gem_request_submit:') {
  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove pointer indirection for hangcheck_state local

[Patchwork]

== Series Details ==

Series: drm/i915: Remove pointer indirection for hangcheck_state local
URL   : https://patchwork.freedesktop.org/series/35580/
State : success

== Summary ==

Series 35580v1 drm/i915: Remove pointer indirection for hangcheck_state local
https://patchwork.freedesktop.org/api/1.0/series/35580/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:275s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:476s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:262s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:425s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:476s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:527s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:439s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:559s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:438s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:584s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:622s
fi-ilk-650 failed to collect. IGT log at Patchwork_7539/fi-ilk-650/igt.log

cd7e14499b1dbbcb6ea97695ebe39e60b5200cc8 drm-tip: 2017y-12m-19d-15h-09m-52s UTC 
integration manifest
44b0b72486e1 drm/i915: Remove pointer indirection for hangcheck_state local

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7539/issues.html
___
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/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Patchwork]

== Series Details ==

Series: drm/syncobj: Stop reusing the same struct file for all syncobj -> fd
URL   : https://patchwork.freedesktop.org/series/35576/
State : success

== Summary ==

Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic:
skip   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup flip-vs-panning-vs-hang-interruptible:
pass   -> DMESG-WARN (shard-snb) fdo#103821
Test gem_eio:
Subgroup in-flight:
dmesg-warn -> PASS   (shard-snb) fdo#104058
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623

fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:10  skip:1164 
time:9432s
shard-snbtotal:2712 pass:1306 dwarn:2   dfail:0   fail:13  skip:1391 
time:8018s
Blacklisted hosts:
shard-apltotal:2712 pass:1687 dwarn:1   dfail:1   fail:22  skip:1001 
time:13769s
shard-kbltotal:2712 pass:1804 dwarn:1   dfail:0   fail:26  skip:881 
time:11151s

== Logs ==

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

[Intel-gfx] [PATCH i-g-t 3/3] tests/perf_pmu: Verify engine busyness accuracy

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

A subtest to verify that the engine busyness is reported with expected
accuracy on platforms where the feature is available.

We test three patterns: 2%, 50% and 98% load per engine.

v2:
 * Use spin batch instead of nop calibration.
 * Various tweaks.

Signed-off-by: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 141 +++
 1 file changed, 141 insertions(+)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 935fee03b253..3ca88bcc6976 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "igt.h"
 #include "igt_core.h"
@@ -983,6 +984,136 @@ test_rc6(int gem_fd)
assert_within_epsilon(busy - prev, 0.0, tolerance);
 }
 
+static uint64_t __pmu_read_single(int fd, uint64_t *ts)
+{
+   uint64_t data[2];
+
+   igt_assert_eq(read(fd, data, sizeof(data)), sizeof(data));
+
+   *ts = data[1];
+
+   return data[0];
+}
+
+static double __error(double val, double ref)
+{
+   return (100.0 * val / ref) - 100.0;
+}
+
+static void debug_error(const char *str, double val, double ref)
+{
+   igt_debug("%s=%.2f%% (%.2f/%.2f)\n", str, __error(val, ref), val, ref);
+}
+
+static void log_error(const char *str, double val, double ref)
+{
+   debug_error(str, val, ref);
+   igt_info("%s=%.2f%%\n", str, __error(val, ref));
+}
+
+static void
+accuracy(int gem_fd, const struct intel_execution_engine2 *e,
+unsigned long target_busy_pct)
+{
+   const unsigned int test_us = 1e6;
+   unsigned long busy_us = 2500;
+   unsigned long idle_us = 100 * (busy_us - target_busy_pct *
+   busy_us / 100) / target_busy_pct;
+   double busy_r;
+   uint64_t val[2];
+   uint64_t ts[2];
+   int fd;
+
+   /* Sampling platforms cannot reach the high accuracy criteria. */
+   igt_require(intel_gen(intel_get_drm_devid(gem_fd)) >= 8);
+
+   while (idle_us < 2500) {
+   busy_us *= 2;
+   idle_us *= 2;
+   }
+
+   assert_within_epsilon((double)busy_us / (busy_us + idle_us),
+   (double)target_busy_pct / 100.0, tolerance);
+
+   /* Emit PWM pattern on the engine from a child. */
+   igt_fork(child, 1) {
+   struct sched_param rt = { .sched_priority = 99 };
+   unsigned long overhead_ns = 0;
+   unsigned long loops;
+   unsigned long i;
+
+   /* We need the best sleep accuracy we can get. */
+   igt_require(sched_setscheduler(0,
+  SCHED_FIFO | SCHED_RESET_ON_FORK,
+  ) == 0);
+
+   /* Measure setup overhead. */
+   loops = test_us / 8000;
+   for (i = 0; i < loops; i++) {
+   struct timespec start = { };
+   igt_spin_t *spin;
+   unsigned int ns;
+
+   igt_nsec_elapsed();
+   spin = igt_spin_batch_new(gem_fd, 0, e2ring(gem_fd, e),
+ 0);
+   igt_spin_batch_end(spin);
+   ns = igt_nsec_elapsed();
+   gem_sync(gem_fd, spin->handle);
+   igt_spin_batch_free(gem_fd, spin);
+   overhead_ns += ns;
+   usleep(1000);
+   }
+
+   overhead_ns /= test_us / loops;
+   igt_debug("spin setup overhead = %luus\n", overhead_ns / 1000);
+   igt_assert(overhead_ns < busy_us * 1000);
+
+   /* Emit PWM busy signal. */
+   loops = test_us / (busy_us + idle_us);
+   for (i = 0; i < loops; i++) {
+   struct timespec start = { };
+   igt_spin_t *spin;
+   unsigned int ns;
+
+   spin = igt_spin_batch_new(gem_fd, 0, e2ring(gem_fd, e),
+ 0);
+   ns = measured_usleep(busy_us - overhead_ns / 1000);
+   igt_spin_batch_end(spin);
+   gem_sync(gem_fd, spin->handle);
+   igt_nsec_elapsed();
+   igt_spin_batch_free(gem_fd, spin);
+   debug_error("busy error", ns, busy_us * 1000);
+   ns = igt_nsec_elapsed();
+
+   if (ns > idle_us * 1000)
+   ns = 0;
+   else
+   ns = idle_us;
+   ns = measured_usleep(ns);
+   debug_error("idle error", ns, idle_us * 1000);
+   }
+   }
+
+   /* Let the child run. */
+   usleep(test_us / 4);
+
+   /* Collect engine busyness for a 

[Intel-gfx] [PATCH i-g-t 1/3] lib/dummyload: Support returning output fence

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Support creating spin batches which return an output fence using new
__igt_spin_batch_new_fence / igt_spin_batch_new_fence API.

This will be used fromthe perf_pmu@interrupts test to ensure user
interrupt generation from a batch with controlled duration.

Signed-off-by: Tvrtko Ursulin 
---
 lib/igt_dummyload.c | 65 ++---
 lib/igt_dummyload.h | 10 +
 2 files changed, 67 insertions(+), 8 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index d19b4e5ea3d2..ef08ad580246 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -70,9 +70,9 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
reloc->write_domain = write_domains;
 }
 
-static void emit_recursive_batch(igt_spin_t *spin,
-int fd, uint32_t ctx, unsigned engine,
-uint32_t dep)
+static int emit_recursive_batch(igt_spin_t *spin,
+   int fd, uint32_t ctx, unsigned engine,
+   uint32_t dep, bool out_fence)
 {
 #define SCRATCH 0
 #define BATCH 1
@@ -87,6 +87,7 @@ static void emit_recursive_batch(igt_spin_t *spin,
 
nengine = 0;
if (engine == -1) {
+   igt_assert_eq(out_fence, false);
for_each_engine(fd, engine)
if (engine)
engines[nengine++] = engine;
@@ -165,22 +166,31 @@ static void emit_recursive_batch(igt_spin_t *spin,
execbuf.buffers_ptr = to_user_pointer(obj + (2 - execbuf.buffer_count));
execbuf.rsvd1 = ctx;
 
+   if (out_fence)
+   execbuf.flags = I915_EXEC_FENCE_OUT;
+   else
+   execbuf.flags = 0;
+
for (i = 0; i < nengine; i++) {
execbuf.flags &= ~ENGINE_MASK;
-   execbuf.flags = engines[i];
-   gem_execbuf(fd, );
+   execbuf.flags |= engines[i];
+   gem_execbuf_wr(fd, );
}
+
+   return out_fence ? (execbuf.rsvd2 >> 32) : -1;
 }
 
-igt_spin_t *
-__igt_spin_batch_new(int fd, uint32_t ctx, unsigned engine, uint32_t dep)
+static igt_spin_t *
+___igt_spin_batch_new(int fd, uint32_t ctx, unsigned engine, uint32_t dep,
+ int out_fence)
 {
igt_spin_t *spin;
 
spin = calloc(1, sizeof(struct igt_spin));
igt_assert(spin);
 
-   emit_recursive_batch(spin, fd, ctx, engine, dep);
+   spin->out_fence = emit_recursive_batch(spin, fd, ctx, engine, dep,
+  out_fence);
igt_assert(gem_bo_busy(fd, spin->handle));
 
pthread_mutex_lock(_lock);
@@ -190,6 +200,12 @@ __igt_spin_batch_new(int fd, uint32_t ctx, unsigned 
engine, uint32_t dep)
return spin;
 }
 
+igt_spin_t *
+__igt_spin_batch_new(int fd, uint32_t ctx, unsigned engine, uint32_t dep)
+{
+   return ___igt_spin_batch_new(fd, ctx, engine, dep, false);
+}
+
 /**
  * igt_spin_batch_new:
  * @fd: open i915 drm file descriptor
@@ -213,6 +229,35 @@ igt_spin_batch_new(int fd, uint32_t ctx, unsigned engine, 
uint32_t dep)
return __igt_spin_batch_new(fd, ctx, engine, dep);
 }
 
+igt_spin_t *
+__igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned engine)
+{
+   return ___igt_spin_batch_new(fd, ctx, engine, 0, true);
+}
+
+/**
+ * igt_spin_batch_new_fence:
+ * @fd: open i915 drm file descriptor
+ * @engine: Ring to execute batch OR'd with execbuf flags. If value is less
+ *  than 0, execute on all available rings.
+ *
+ * Start a recursive batch on a ring. Immediately returns a #igt_spin_t that
+ * contains the batch's handle that can be waited upon. The returned structure
+ * must be passed to igt_spin_batch_free() for post-processing.
+ *
+ * igt_spin_t will contain an output fence associtated with this batch.
+ *
+ * Returns:
+ * Structure with helper internal state for igt_spin_batch_free().
+ */
+igt_spin_t *
+igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned engine)
+{
+   igt_require_gem(fd);
+
+   return __igt_spin_batch_new_fence(fd, ctx, engine);
+}
+
 static void notify(union sigval arg)
 {
igt_spin_t *spin = arg.sival_ptr;
@@ -295,6 +340,10 @@ void igt_spin_batch_free(int fd, igt_spin_t *spin)
gem_munmap(spin->batch, BATCH_SIZE);
 
gem_close(fd, spin->handle);
+
+   if (spin->out_fence >= 0)
+   close(spin->out_fence);
+
free(spin);
 }
 
diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h
index 215425f7c6c0..ffa7e351dea3 100644
--- a/lib/igt_dummyload.h
+++ b/lib/igt_dummyload.h
@@ -35,6 +35,7 @@ typedef struct igt_spin {
timer_t timer;
struct igt_list link;
uint32_t *batch;
+   int out_fence;
 } igt_spin_t;
 
 igt_spin_t *__igt_spin_batch_new(int fd,
@@ -45,6 +46,15 @@ igt_spin_t *igt_spin_batch_new(int fd,
   uint32_t ctx,

[Intel-gfx] [PATCH i-g-t 2/3] tests/perf_pmu: Simplify interrupt testing

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Rather than calibrate and emit nop batches, use a manually signalled chain
of spinners to generate the desired interrupts.

Signed-off-by: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 94 
 1 file changed, 13 insertions(+), 81 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index db7696115a7b..935fee03b253 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -799,94 +799,23 @@ static void cpu_hotplug(int gem_fd)
assert_within_epsilon(val, ref, tolerance);
 }
 
-static unsigned long calibrate_nop(int fd, const uint64_t calibration_us)
-{
-   const uint64_t cal_min_us = calibration_us * 3;
-   const unsigned int tolerance_pct = 10;
-   const uint32_t bbe = MI_BATCH_BUFFER_END;
-   const unsigned int loops = 17;
-   struct drm_i915_gem_exec_object2 obj = {};
-   struct drm_i915_gem_execbuffer2 eb = {
-   .buffer_count = 1, .buffers_ptr = to_user_pointer(),
-   };
-   struct timespec t_begin = { };
-   uint64_t size, last_size, ns;
-
-   igt_nsec_elapsed(_begin);
-
-   size = 256 * 1024;
-   do {
-   struct timespec t_start = { };
-
-   obj.handle = gem_create(fd, size);
-   gem_write(fd, obj.handle, size - sizeof(bbe), ,
- sizeof(bbe));
-   gem_execbuf(fd, );
-   gem_sync(fd, obj.handle);
-
-   igt_nsec_elapsed(_start);
-
-   for (int loop = 0; loop < loops; loop++)
-   gem_execbuf(fd, );
-   gem_sync(fd, obj.handle);
-
-   ns = igt_nsec_elapsed(_start);
-
-   gem_close(fd, obj.handle);
-
-   last_size = size;
-   size = calibration_us * 1000 * size * loops / ns;
-   size = ALIGN(size, sizeof(uint32_t));
-   } while (igt_nsec_elapsed(_begin) / 1000 < cal_min_us ||
-abs(size - last_size) > (size * tolerance_pct / 100));
-
-   return size;
-}
-
 static void
 test_interrupts(int gem_fd)
 {
-   const uint32_t bbe = MI_BATCH_BUFFER_END;
const unsigned int test_duration_ms = 1000;
-   struct drm_i915_gem_exec_object2 obj = { };
-   struct drm_i915_gem_execbuffer2 eb = {
-   .buffers_ptr = to_user_pointer(),
-   .buffer_count = 1,
-   .flags = I915_EXEC_FENCE_OUT,
-   };
-   unsigned long sz;
-   igt_spin_t *spin;
const int target = 30;
+   igt_spin_t *spin[target];
struct pollfd pfd;
uint64_t idle, busy;
int fd;
 
-   sz = calibrate_nop(gem_fd, test_duration_ms * 1000 / target);
gem_quiescent_gpu(gem_fd);
 
fd = open_pmu(I915_PMU_INTERRUPTS);
-   spin = igt_spin_batch_new(gem_fd, 0, 0, 0);
 
-   obj.handle = gem_create(gem_fd, sz);
-   gem_write(gem_fd, obj.handle, sz - sizeof(bbe), , sizeof(bbe));
-
-   pfd.events = POLLIN;
-   pfd.fd = -1;
-   for (int i = 0; i < target; i++) {
-   int new;
-
-   /* Merge all the fences together so we can wait on them all */
-   gem_execbuf_wr(gem_fd, );
-   new = eb.rsvd2 >> 32;
-   if (pfd.fd == -1) {
-   pfd.fd = new;
-   } else {
-   int old = pfd.fd;
-   pfd.fd = sync_fence_merge(old, new);
-   close(old);
-   close(new);
-   }
-   }
+   /* Queue spinning batches. */
+   for (int i = 0; i < target; i++)
+   spin[i] = __igt_spin_batch_new_fence(gem_fd, 0, 0);
 
/* Wait for idle state. */
idle = pmu_read_single(fd);
@@ -896,13 +825,16 @@ test_interrupts(int gem_fd)
idle = pmu_read_single(fd);
} while (idle != busy);
 
-   /* Install the fences and enable signaling */
-   igt_assert_eq(poll(, 1, 10), 0);
+   /* Process the batch queue. */
+   pfd.events = POLLIN;
+   for (int i = 0; i < target; i++) {
+   const unsigned int timeout_ms = test_duration_ms / target;
 
-   /* Unplug the calibrated queue and wait for all the fences */
-   igt_spin_batch_free(gem_fd, spin);
-   igt_assert_eq(poll(, 1, 2 * test_duration_ms), 1);
-   close(pfd.fd);
+   pfd.fd = spin[i]->out_fence;
+   igt_spin_batch_set_timeout(spin[i], timeout_ms * 1e6);
+   igt_assert_eq(poll(, 1, 2 * timeout_ms), 1);
+   igt_spin_batch_free(gem_fd, spin[i]);
+   }
 
/* Check at least as many interrupts has been generated. */
busy = pmu_read_single(fd) - idle;
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH i-g-t v5] overlay: parse tracepoints from sysfs to figure out fields' location

[Lionel Landwerlin]

On 19/12/17 15:15, Chris Wilson wrote:

Quoting Lionel Landwerlin (2017-12-19 14:26:11)

With changes going to drm-tip, the tracepoints field locations are
going to change. This change introduces a tracepoint parser (using a
peg parser) which lets us figure out field positions on the fly.

v2: Fix automake build (Lionel)

v3: Make overlay build conditional on peg (Petri)
 Make wait_end callback more readable (Chris)
 Drop tracepoint_id(), instead parsing from format file (Lionel)

v4: Fix existing configure.ac issue with overlay build (Petri)

v5: Silence unused function (Lionel)

Signed-off-by: Lionel Landwerlin 

For the build system changes:
Acked-by: Petri Latvala 

If it works, it works.
Acked-by: Chris Wilson 

One of the next steps would be failing if the tracepoint doesn't contain
the desired data.
-Chris

It will fail if the parsing fails. Now if someone removes a field from 
the kernel, yeah, we're a bit screwed...


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

Re: [Intel-gfx] [PATCH i-g-t v5] overlay: parse tracepoints from sysfs to figure out fields' location

[Chris Wilson]

Quoting Lionel Landwerlin (2017-12-19 14:26:11)
> With changes going to drm-tip, the tracepoints field locations are
> going to change. This change introduces a tracepoint parser (using a
> peg parser) which lets us figure out field positions on the fly.
> 
> v2: Fix automake build (Lionel)
> 
> v3: Make overlay build conditional on peg (Petri)
> Make wait_end callback more readable (Chris)
> Drop tracepoint_id(), instead parsing from format file (Lionel)
> 
> v4: Fix existing configure.ac issue with overlay build (Petri)
> 
> v5: Silence unused function (Lionel)
> 
> Signed-off-by: Lionel Landwerlin 
> 
> For the build system changes:
> Acked-by: Petri Latvala 

If it works, it works.
Acked-by: Chris Wilson 

One of the next steps would be failing if the tracepoint doesn't contain
the desired data.
-Chris
___
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: Grab power domain in skl_pipe_wm_get_hw_state()

[Patchwork]

== Series Details ==

Series: drm/i915: Grab power domain in skl_pipe_wm_get_hw_state()
URL   : https://patchwork.freedesktop.org/series/35577/
State : success

== Summary ==

Series 35577v1 drm/i915: Grab power domain in skl_pipe_wm_get_hw_state()
https://patchwork.freedesktop.org/api/1.0/series/35577/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:490s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:275s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:500s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:479s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:261s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:417s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:389s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:487s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:514s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:529s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:508s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:547s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:417s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:588s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:627s

1a9d5c66e6def1c7a8b3334abf70f940edc90adb drm-tip: 2017y-12m-19d-14h-25m-30s UTC 
integration manifest
ea5de102287a drm/i915: Grab power domain in skl_pipe_wm_get_hw_state()

== Logs ==

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Add pretty printer for device info flags

[Chris Wilson]

Quoting Patchwork (2017-12-19 15:01:40)
> == Series Details ==
> 
> Series: series starting with [v2,1/3] drm/i915: Add pretty printer for device 
> info flags
> URL   : https://patchwork.freedesktop.org/series/35574/
> State : success
> 
> == Summary ==
> 
> Test gem_tiled_swapping:
> Subgroup non-threaded:
> incomplete -> PASS   (shard-snb) fdo#104218
> Test gem_eio:
> Subgroup in-flight-external:
> incomplete -> PASS   (shard-hsw)
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> pass   -> FAIL   (shard-snb) fdo#101623 +1
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-b:
> skip   -> PASS   (shard-snb) fdo#103375
> Test kms_flip:
> Subgroup plain-flip-fb-recreate-interruptible:
> fail   -> PASS   (shard-hsw) fdo#100368
> Subgroup wf_vblank-vs-dpms:
> dmesg-warn -> PASS   (shard-hsw) fdo#102614
> Test kms_setmode:
> Subgroup basic:
> fail   -> PASS   (shard-hsw) fdo#99912

Thanks for the patches, discarding nearly a whole page from our bloated
driver! It's size is getting scary.

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Convert intel_device_info_dump into pretty printer

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-19 11:43:45)
> Convert intel_device_info_dump into pretty printer to be
> consistent with the rest of the driver code.
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] scripts/trace.pl: Optimize event parsing and processing

[Chris Wilson]

Quoting Tvrtko Ursulin (2017-12-19 11:15:39)
> From: Tvrtko Ursulin 
> 
> A couple of small optimizations which altogether bring around 30%
> improvement in my testing.
> 
> 1. Do less string processing on tracepoints names and push more of the
>check into the if-ladder.
> 
> 2. Pull out common db key and ctx processing and cache common values in
>local vars.
> 
> 3. Key value pair parsing is faster with a regexp.
> 
> 4. Avoid sorting the db hash multiple times if possible.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: John Harrison 
> ---
>  scripts/trace.pl | 114 
> ---
>  1 file changed, 49 insertions(+), 65 deletions(-)
> ---
> John please check if this helps with your monster traces before we decide
> if it is worth putting this in. Well, there isn't much of a downside
> except touching something which works and risking breaking it.

Could you run the same trace and do something like
time trace1 < input > output1.html
time trace2 < input > output2.html
cmp output1.html output2.html
?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: Add pretty printer for device info flags

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Add pretty printer for device 
info flags
URL   : https://patchwork.freedesktop.org/series/35574/
State : success

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104218
Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (shard-snb) fdo#103375
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup wf_vblank-vs-dpms:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2712 pass:1538 dwarn:1   dfail:0   fail:9   skip:1164 
time:9423s
shard-snbtotal:2712 pass:1307 dwarn:1   dfail:0   fail:13  skip:1391 
time:8025s
Blacklisted hosts:
shard-apltotal:2690 pass:1665 dwarn:1   dfail:0   fail:22  skip:1001 
time:13298s

== Logs ==

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

[Intel-gfx] [PATCH igt] lib: Convert sw_sync to use sync_file uapi imported from the kernel

[Chris Wilson]

Similar to how we are now importing the drm uapi directly into igt, we
also would like to have a copy of auxiliary uAPI such as sync_file.

Signed-off-by: Chris Wilson 
---
 include/drm-uapi/Makefile.am |  1 +
 include/drm-uapi/sync_file.h | 98 
 lib/sw_sync.c| 59 ++
 3 files changed, 112 insertions(+), 46 deletions(-)
 create mode 100644 include/drm-uapi/sync_file.h

diff --git a/include/drm-uapi/Makefile.am b/include/drm-uapi/Makefile.am
index f335251bd..c658fcc44 100644
--- a/include/drm-uapi/Makefile.am
+++ b/include/drm-uapi/Makefile.am
@@ -19,6 +19,7 @@ EXTRA_DIST = \
radeon_drm.h \
savage_drm.h \
sis_drm.h \
+   sync_file.h \
tegra_drm.h \
vc4_drm.h \
vgem_drm.h \
diff --git a/include/drm-uapi/sync_file.h b/include/drm-uapi/sync_file.h
new file mode 100644
index 0..b4f2db009
--- /dev/null
+++ b/include/drm-uapi/sync_file.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-1.0+ WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_SYNC_H
+#define _LINUX_SYNC_H
+
+#include 
+#include 
+
+/**
+ * struct sync_merge_data - data passed to merge ioctl
+ * @name:  name of new fence
+ * @fd2:   file descriptor of second fence
+ * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad:   padding for 64-bit alignment, should always be zero
+ */
+struct sync_merge_data {
+   charname[32];
+   __s32   fd2;
+   __s32   fence;
+   __u32   flags;
+   __u32   pad;
+};
+
+/**
+ * struct sync_fence_info - detailed fence information
+ * @obj_name:  name of parent sync_timeline
+* @driver_name:name of driver implementing the parent
+* @status: status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
+ * @timestamp_ns:  timestamp of status change in nanoseconds
+ */
+struct sync_fence_info {
+   charobj_name[32];
+   chardriver_name[32];
+   __s32   status;
+   __u32   flags;
+   __u64   timestamp_ns;
+};
+
+/**
+ * struct sync_file_info - data returned from fence info ioctl
+ * @name:  name of fence
+ * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
+ * @num_fences number of fences in the sync_file
+ * @pad:   padding for 64-bit alignment, should always be zero
+ * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ *  fences in the sync_file
+ */
+struct sync_file_info {
+   charname[32];
+   __s32   status;
+   __u32   flags;
+   __u32   num_fences;
+   __u32   pad;
+
+   __u64   sync_fence_info;
+};
+
+#define SYNC_IOC_MAGIC '>'
+
+/**
+ * Opcodes  0, 1 and 2 were burned during a API change to avoid users of the
+ * old API to get weird errors when trying to handling sync_files. The API
+ * change happened during the de-stage of the Sync Framework when there was
+ * no upstream users available.
+ */
+
+/**
+ * DOC: SYNC_IOC_MERGE - merge two fences
+ *
+ * Takes a struct sync_merge_data.  Creates a new fence containing copies of
+ * the sync_pts in both the calling fd and sync_merge_data.fd2.  Returns the
+ * new fence's fd in sync_merge_data.fence
+ */
+#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
+
+/**
+ * DOC: SYNC_IOC_FILE_INFO - get detailed information on a sync_file
+ *
+ * Takes a struct sync_file_info. If num_fences is 0, the field is updated
+ * with the actual number of fences. If num_fences is > 0, the system will
+ * use the pointer provided on sync_fence_info to return up to num_fences of
+ * struct sync_fence_info, with detailed fence information.
+ */
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
+
+#endif /* _LINUX_SYNC_H */
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
index 9b36dd85c..619049b3e 100644
--- a/lib/sw_sync.c
+++ b/lib/sw_sync.c
@@ -33,6 +33,8 @@
 #include 
 #include 
 
+#include "sync_file.h"
+
 #include "igt_debugfs.h"
 #include "igt_kmod.h"
 #include "sw_sync.h"
@@ -56,41 +58,6 @@ struct int_sync_create_fence_data {
 #define INT_SYNC_IOC_CREATE_FENCE  _IOWR(INT_SYNC_IOC_MAGIC, 0, struct 
int_sync_create_fence_data)
 #define INT_SYNC_IOC_INC   _IOW(INT_SYNC_IOC_MAGIC, 1, __u32)
 
-struct local_sync_merge_data {
-   char name[32];
-
-   __s32 fd2;
-   __s32 fence;
-
-   __u32 flags;
-   __u32 pad;
-};
-
-struct local_sync_fence_info {
-   char obj_name[32];
-   char driver_name[32];
-
-   __s32 status;
-   __u32 flags;

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Fix indentation for intel_ddi_clk_select

[Patchwork]

== Series Details ==

Series: drm/i915: Fix indentation for intel_ddi_clk_select
URL   : https://patchwork.freedesktop.org/series/35570/
State : warning

== Summary ==

Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Subgroup wf_vblank-vs-dpms:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (shard-snb) fdo#103375 +1
Test gem_softpin:
Subgroup noreloc-s3:
pass   -> SKIP   (shard-hsw) fdo#103540
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104218
Test gem_eio:
Subgroup in-flight-external:
incomplete -> PASS   (shard-hsw)
Test kms_atomic_transition:
Subgroup plane-all-transition-nonblocking-fencing:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-size-change:
pass   -> SKIP   (shard-hsw)
Test kms_rmfb:
Subgroup close-fd:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-toggle:
pass   -> SKIP   (shard-hsw)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#104218 https://bugs.freedesktop.org/show_bug.cgi?id=104218
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2712 pass:1532 dwarn:1   dfail:0   fail:9   skip:1170 
time:9183s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8020s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] intel_vbt_decode: Typo fixes

[Jani Nikula]

On Fri, 15 Dec 2017, Adam Jackson  wrote:
> Signed-off-by: Adam Jackson 
> ---
>  tools/intel_vbt_decode.c | 4 ++--
>  tools/intel_vbt_defs.h   | 6 +++---

Hi Adam, thanks for the patch. We've opted to make the kernel copy of
this file the single point of truth, and copy that over verbatim every
once in a while. Please send a patch to
drivers/gpu/drm/i915/intel_vbt_defs.h and it'll trickle over here
eventually when we sync up (or you can send the sync patch too).

Thanks,
Jani.


>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/intel_vbt_decode.c b/tools/intel_vbt_decode.c
> index 9d90c69d..ce7da2c0 100644
> --- a/tools/intel_vbt_decode.c
> +++ b/tools/intel_vbt_decode.c
> @@ -309,8 +309,8 @@ static const struct {
>   { DEVICE_TYPE_COMPOSITE_OUTPUT, "Composite output" },
>   { DEVICE_TYPE_DUAL_CHANNEL, "Dual channel" },
>   { 1 << 7, "Content protection" },
> - { DEVICE_TYPE_HIGH_SPEED_LINK, "High speel link" },
> - { DEVICE_TYPE_LVDS_SINGALING, "LVDS signaling" },
> + { DEVICE_TYPE_HIGH_SPEED_LINK, "High speed link" },
> + { DEVICE_TYPE_LVDS_SIGNALING, "LVDS signaling" },
>   { DEVICE_TYPE_TMDS_DVI_SIGNALING, "TMDS/DVI signaling" },
>   { DEVICE_TYPE_VIDEO_SIGNALING, "Video signaling" },
>   { DEVICE_TYPE_DISPLAYPORT_OUTPUT, "DisplayPort output" },
> diff --git a/tools/intel_vbt_defs.h b/tools/intel_vbt_defs.h
> index 404569c9..e388f9ad 100644
> --- a/tools/intel_vbt_defs.h
> +++ b/tools/intel_vbt_defs.h
> @@ -227,7 +227,7 @@ struct bdb_general_features {
>  #define DEVICE_TYPE_COMPOSITE_OUTPUT (1 << 9)
>  #define DEVICE_TYPE_DUAL_CHANNEL (1 << 8)
>  #define DEVICE_TYPE_HIGH_SPEED_LINK  (1 << 6)
> -#define DEVICE_TYPE_LVDS_SINGALING   (1 << 5)
> +#define DEVICE_TYPE_LVDS_SIGNALING   (1 << 5)
>  #define DEVICE_TYPE_TMDS_DVI_SIGNALING   (1 << 4)
>  #define DEVICE_TYPE_VIDEO_SIGNALING  (1 << 3)
>  #define DEVICE_TYPE_DISPLAYPORT_OUTPUT   (1 << 2)
> @@ -243,7 +243,7 @@ struct bdb_general_features {
>DEVICE_TYPE_MIPI_OUTPUT |  \
>DEVICE_TYPE_COMPOSITE_OUTPUT | \
>DEVICE_TYPE_DUAL_CHANNEL | \
> -  DEVICE_TYPE_LVDS_SINGALING |   \
> +  DEVICE_TYPE_LVDS_SIGNALING |   \
>DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
>DEVICE_TYPE_VIDEO_SIGNALING |  \
>DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \
> @@ -253,7 +253,7 @@ struct bdb_general_features {
>   (DEVICE_TYPE_INTERNAL_CONNECTOR |   \
>DEVICE_TYPE_MIPI_OUTPUT |  \
>DEVICE_TYPE_COMPOSITE_OUTPUT | \
> -  DEVICE_TYPE_LVDS_SINGALING |   \
> +  DEVICE_TYPE_LVDS_SIGNALING |   \
>DEVICE_TYPE_TMDS_DVI_SIGNALING |   \
>DEVICE_TYPE_VIDEO_SIGNALING |  \
>DEVICE_TYPE_DISPLAYPORT_OUTPUT |   \

-- 
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 v2 2/2] kms_content_protection: Add Content Protection test

[Ramalingam C]

Adding few more findings from the IGT usage with kernel solutions.


On Wednesday 13 December 2017 04:07 PM, Ramalingam C wrote:

Sean,

Adding few more observations.


On Thursday 07 December 2017 05:47 AM, Sean Paul wrote:

Pretty simple test:
- initializes the output
- clears the content protection property
- verifies that it clears
- sets the content protection property to desired
- verifies that it transitions to enabled

Does this for both legacy and atomic.

Changes in v2:
- Don't check for i915 gen
- Skip test if Content Protection property is absent

Signed-off-by: Sean Paul 
---
  lib/igt_kms.c  |   3 +-
  lib/igt_kms.h  |   1 +
  tests/Makefile.sources |   1 +
  tests/kms_content_protection.c | 129 
+

  tests/meson.build  |   1 +
  5 files changed, 134 insertions(+), 1 deletion(-)
  create mode 100644 tests/kms_content_protection.c

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 125ecb19..907db694 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -190,7 +190,8 @@ const char 
*igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {

  "scaling mode",
  "CRTC_ID",
  "DPMS",
-    "Broadcast RGB"
+    "Broadcast RGB",
+    "Content Protection"
  };
    /*
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 2a480bf3..93e59dc7 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -118,6 +118,7 @@ enum igt_atomic_connector_properties {
 IGT_CONNECTOR_CRTC_ID,
 IGT_CONNECTOR_DPMS,
 IGT_CONNECTOR_BROADCAST_RGB,
+   IGT_CONNECTOR_CONTENT_PROTECTION,
 IGT_NUM_CONNECTOR_PROPS
  };
  diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 34ca71a0..e0466411 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -179,6 +179,7 @@ TESTS_progs = \
  kms_chv_cursor_fail \
  kms_color \
  kms_concurrent \
+    kms_content_protection\
  kms_crtc_background_color \
  kms_cursor_crc \
  kms_cursor_legacy \
diff --git a/tests/kms_content_protection.c 
b/tests/kms_content_protection.c

new file mode 100644
index ..5d61b257
--- /dev/null
+++ b/tests/kms_content_protection.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright © 2017 Google, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person 
obtaining a
+ * copy of this software and associated documentation files (the 
"Software"),
+ * to deal in the Software without restriction, including without 
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom 
the

+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including 
the next
+ * paragraph) shall be included in all copies or substantial 
portions of the

+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 
EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES 
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 
OTHER DEALINGS

+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test content protection (HDCP)");
+
+typedef struct {
+    int drm_fd;
+    igt_display_t display;
+} data_t;
+
+static bool
+wait_for_prop_value(igt_output_t *output, uint64_t expected)
+{
+    uint64_t val;
+    int i;
+
+    for (i = 0; i < 2000; i++) {
we need 5+Sec to complete the Second part of authentication, in case 
of repeater with max downstream topology.

So we might need to wait for 6000(6Sec) loops!?

+    val = igt_output_get_prop(output,
+  IGT_CONNECTOR_CONTENT_PROTECTION);
+    if (val == expected)
+    return true;
+    usleep(1000);
+    }
+    igt_info("prop_value mismatch %ld != %ld\n", val, expected);
+    return false;
+}
+
+static void
+test_pipe_output(igt_display_t *display, const enum pipe pipe,
+ igt_output_t *output, enum igt_commit_style s)
+{
+    drmModeModeInfo mode;
+    igt_plane_t *primary;
+    struct igt_fb red;
+    bool ret;
+
+    igt_assert(kmstest_get_connector_default_mode(
+    display->drm_fd, output->config.connector, ));
+
+    igt_output_override_mode(output, );
+    igt_output_set_pipe(output, pipe);
+
+    igt_create_color_fb(display->drm_fd, mode.hdisplay, mode.vdisplay,
+    DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE,
+    1.f, 0.f, 0.f, );
+    primary = igt_output_get_plane_type(output, 
DRM_PLANE_TYPE_PRIMARY);

+    igt_plane_set_fb(primary, );
+    igt_display_commit2(display, s);
+
+    igt_output_set_prop_value(output, 
IGT_CONNECTOR_CONTENT_PROTECTION, 0);

+    

[Intel-gfx] [PATCH i-g-t v5] overlay: parse tracepoints from sysfs to figure out fields' location

[Lionel Landwerlin]

With changes going to drm-tip, the tracepoints field locations are
going to change. This change introduces a tracepoint parser (using a
peg parser) which lets us figure out field positions on the fly.

v2: Fix automake build (Lionel)

v3: Make overlay build conditional on peg (Petri)
Make wait_end callback more readable (Chris)
Drop tracepoint_id(), instead parsing from format file (Lionel)

v4: Fix existing configure.ac issue with overlay build (Petri)

v5: Silence unused function (Lionel)

Signed-off-by: Lionel Landwerlin 

For the build system changes:
Acked-by: Petri Latvala 
---
 configure.ac  |   9 ++-
 overlay/Makefile.am   |   5 ++
 overlay/gpu-perf.c| 164 --
 overlay/meson.build   |  13 +++-
 overlay/tracepoint_format.leg |  35 +
 5 files changed, 186 insertions(+), 40 deletions(-)
 create mode 100644 overlay/tracepoint_format.leg

diff --git a/configure.ac b/configure.ac
index 8740f7a4..50c1a024 100644
--- a/configure.ac
+++ b/configure.ac
@@ -146,6 +146,13 @@ if test x"$build_x86" = xyes; then
AS_IF([test x"$LEX" != "x:" -a x"$YACC" != xyacc],
[enable_assembler=yes],
[enable_assembler=no])
+
+   AC_CHECK_TOOL([LEG], [leg])
+   if test "x$LEG" != "xleg"; then
+   AC_MSG_NOTICE([leg command missing, disabling overlay; try : 
apt-get install peg])
+   enable_overlay_xvlib="no"
+   enable_overlay_xlib="no"
+   fi
 else
enable_overlay_xvlib="no"
enable_overlay_xlib="no"
@@ -158,7 +165,7 @@ AM_CONDITIONAL(BUILD_ASSEMBLER, [test "x$enable_assembler" 
= xyes])
 
 AM_CONDITIONAL(BUILD_OVERLAY_XVLIB, [test "x$enable_overlay_xvlib" = xyes])
 AM_CONDITIONAL(BUILD_OVERLAY_XLIB, [test "x$enable_overlay_xlib" = xyes])
-AM_CONDITIONAL(BUILD_OVERLAY, [test "x$enable_overlay_xlib" = xyes -o 
"x$enable_overlay_xvlib"])
+AM_CONDITIONAL(BUILD_OVERLAY, [test "x$enable_overlay_xlib" = xyes -o 
"x$enable_overlay_xvlib" = "xyes])
 if test x$enable_overlay_xvlib = xyes; then
AC_DEFINE(HAVE_OVERLAY_XVLIB, 1, [Enable XV backend])
 fi
diff --git a/overlay/Makefile.am b/overlay/Makefile.am
index fca04cae..0f553b7c 100644
--- a/overlay/Makefile.am
+++ b/overlay/Makefile.am
@@ -1,7 +1,12 @@
 if BUILD_OVERLAY
 bin_PROGRAMS = intel-gpu-overlay
+
+BUILT_SOURCES = tracepoint_format.h
 endif
 
+tracepoint_format.h: tracepoint_format.leg
+   $(LEG) -o $@ $<
+
 AM_CPPFLAGS = -I. -I$(top_srcdir)/include/drm-uapi
 AM_CFLAGS = $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) $(CWARNFLAGS) \
$(CAIRO_CFLAGS) $(OVERLAY_CFLAGS) $(WERROR_CFLAGS) -I$(srcdir)/../lib
diff --git a/overlay/gpu-perf.c b/overlay/gpu-perf.c
index 3d4a9be9..0abd937e 100644
--- a/overlay/gpu-perf.c
+++ b/overlay/gpu-perf.c
@@ -57,39 +57,125 @@ struct sample_event {
uint64_t time;
uint64_t id;
uint32_t raw_size;
-   uint32_t raw_hdr0;
-   uint32_t raw_hdr1;
-   uint32_t raw[0];
+   uint8_t tracepoint_data[0];
 };
 
 enum {
-   DEVICE = 0,
-   CTX,
-   ENGINE,
-   CTX_SEQNO,
-   GLOBAL_SEQNO
+   TP_GEM_REQUEST_ADD,
+   TP_GEM_REQUEST_WAIT_BEGIN,
+   TP_GEM_REQUEST_WAIT_END,
+   TP_FLIP_COMPLETE,
+   TP_GEM_RING_SYNC_TO,
+   TP_GEM_RING_SWITCH_CONTEXT,
+
+   TP_NB
 };
 
-static uint64_t tracepoint_id(const char *sys, const char *name)
+struct tracepoint {
+   const char *name;
+   int event_id;
+
+   struct {
+   char name[128];
+   int offset;
+   int size;
+   int is_signed;
+   } fields[20];
+   int n_fields;
+
+   int device_field;
+   int ctx_field;
+   int ring_field;
+   int seqno_field;
+   int global_seqno_field;
+   int plane_field;
+} tracepoints[TP_NB] = {
+   [TP_GEM_REQUEST_ADD] = { .name = "i915/i915_gem_request_add", },
+   [TP_GEM_REQUEST_WAIT_BEGIN]  = { .name = 
"i915/i915_gem_request_wait_begin", },
+   [TP_GEM_REQUEST_WAIT_END]= { .name = 
"i915/i915_gem_request_wait_end", },
+   [TP_FLIP_COMPLETE]   = { .name = "i915/flip_complete", },
+   [TP_GEM_RING_SYNC_TO]= { .name = "i915/gem_ring_sync_to", },
+   [TP_GEM_RING_SWITCH_CONTEXT] = { .name = 
"i915/gem_ring_switch_context", },
+};
+
+union parser_value {
+char *string;
+int integer;
+};
+
+struct parser_ctx {
+   struct tracepoint *tp;
+   FILE *fp;
+};
+
+#define YY_CTX_LOCAL
+#define YY_CTX_MEMBERS struct parser_ctx ctx;
+#define YYSTYPE union parser_value
+#define YY_LOCAL(T) static __attribute__((unused)) T
+#define YY_PARSE(T) static T
+#define YY_INPUT(yy, buf, result, max) \
+   {   \
+   int c = getc(yy->ctx.fp);   \
+   result = (EOF == c) ? 0 : (*(buf)= c, 1);   

[Intel-gfx] [PATCH igt v2] igt: Exercise creating context with shared GTT

[Chris Wilson]

v2: Test each shared context is its own timeline and allows request
reordering between shared contexts.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Michal Wajdeczko 
---
 include/drm-uapi/sync_file.h |  98 +++
 tests/Makefile.sources   |   1 +
 tests/gem_ctx_shared.c   | 684 +++
 3 files changed, 783 insertions(+)
 create mode 100644 include/drm-uapi/sync_file.h
 create mode 100644 tests/gem_ctx_shared.c

diff --git a/include/drm-uapi/sync_file.h b/include/drm-uapi/sync_file.h
new file mode 100644
index 0..b4f2db009
--- /dev/null
+++ b/include/drm-uapi/sync_file.h
@@ -0,0 +1,98 @@
+/* SPDX-License-Identifier: GPL-1.0+ WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_SYNC_H
+#define _LINUX_SYNC_H
+
+#include 
+#include 
+
+/**
+ * struct sync_merge_data - data passed to merge ioctl
+ * @name:  name of new fence
+ * @fd2:   file descriptor of second fence
+ * @fence: returns the fd of the new fence to userspace
+ * @flags: merge_data flags
+ * @pad:   padding for 64-bit alignment, should always be zero
+ */
+struct sync_merge_data {
+   charname[32];
+   __s32   fd2;
+   __s32   fence;
+   __u32   flags;
+   __u32   pad;
+};
+
+/**
+ * struct sync_fence_info - detailed fence information
+ * @obj_name:  name of parent sync_timeline
+* @driver_name:name of driver implementing the parent
+* @status: status of the fence 0:active 1:signaled <0:error
+ * @flags: fence_info flags
+ * @timestamp_ns:  timestamp of status change in nanoseconds
+ */
+struct sync_fence_info {
+   charobj_name[32];
+   chardriver_name[32];
+   __s32   status;
+   __u32   flags;
+   __u64   timestamp_ns;
+};
+
+/**
+ * struct sync_file_info - data returned from fence info ioctl
+ * @name:  name of fence
+ * @status:status of fence. 1: signaled 0:active <0:error
+ * @flags: sync_file_info flags
+ * @num_fences number of fences in the sync_file
+ * @pad:   padding for 64-bit alignment, should always be zero
+ * @sync_fence_info: pointer to array of structs sync_fence_info with all
+ *  fences in the sync_file
+ */
+struct sync_file_info {
+   charname[32];
+   __s32   status;
+   __u32   flags;
+   __u32   num_fences;
+   __u32   pad;
+
+   __u64   sync_fence_info;
+};
+
+#define SYNC_IOC_MAGIC '>'
+
+/**
+ * Opcodes  0, 1 and 2 were burned during a API change to avoid users of the
+ * old API to get weird errors when trying to handling sync_files. The API
+ * change happened during the de-stage of the Sync Framework when there was
+ * no upstream users available.
+ */
+
+/**
+ * DOC: SYNC_IOC_MERGE - merge two fences
+ *
+ * Takes a struct sync_merge_data.  Creates a new fence containing copies of
+ * the sync_pts in both the calling fd and sync_merge_data.fd2.  Returns the
+ * new fence's fd in sync_merge_data.fence
+ */
+#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
+
+/**
+ * DOC: SYNC_IOC_FILE_INFO - get detailed information on a sync_file
+ *
+ * Takes a struct sync_file_info. If num_fences is 0, the field is updated
+ * with the actual number of fences. If num_fences is > 0, the system will
+ * use the pointer provided on sync_fence_info to return up to num_fences of
+ * struct sync_fence_info, with detailed fence information.
+ */
+#define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info)
+
+#endif /* _LINUX_SYNC_H */
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e4e06d01d..48b3f4625 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -58,6 +58,7 @@ TESTS_progs = \
gem_ctx_create \
gem_ctx_exec \
gem_ctx_param \
+   gem_ctx_shared \
gem_ctx_switch \
gem_ctx_thrash \
gem_double_irq_loop \
diff --git a/tests/gem_ctx_shared.c b/tests/gem_ctx_shared.c
new file mode 100644
index 0..7bc285d79
--- /dev/null
+++ b/tests/gem_ctx_shared.c
@@ -0,0 +1,684 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to 

Re: [Intel-gfx] [PATCH 4/5] drm/atomic: document how to handle driver private objects

[Laurent Pinchart]

Hi Daniel,

On Tuesday, 19 December 2017 16:00:36 EET Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 03:33:57PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 19 December 2017 12:03:55 EET Daniel Vetter wrote:
> > > On Mon, Dec 18, 2017 at 06:13:46PM +0200, Laurent Pinchart wrote:
> > > > On Thursday, 14 December 2017 22:30:53 EET Daniel Vetter wrote:
> > > >> + * Drivers are recommend to wrap these for each type of driver
> > > >> private
> > > >> state
> > > >> + * object they have, filtering on _private_obj.funcs using
> > > >> for_each_if(), at
> > > >> + * least if they want to iterate over all objects of a given type.
> > > >> + *
> > > >> + * An earlier way to handle driver private state was by subclassing
> > > >> struct
> > > >> + * _atomic_state. But since that encourages non-standard ways to
> > > >> implement
> > > >> + * the check/commit split atomic requires (by using e.g. "check and
> > > >> rollback or
> > > >> + * commit instead" of "duplicate state, check, then either commit or
> > > >> release
> > > >> + * duplicated state) it is deprecated in favour of using
> > > >> _private_state.
> > > > 
> > > > This I still don't agree with. I think it still makes sense to
> > > > subclass
> > > > the global state object when you have true global state data. How
> > > > about
> > > > starting by making it a recommendation instead, moving state data
> > > > related
> > > > to driver- specific objects to the new framework, and keeping global
> > > > data
> > > > in the drm_atomic_state subclass ?
> > > 
> > > Converting all the existing drivers over is somewhere on my todo. I'm
> > > also
> > > not really clear what you mean with global data compared to
> > > driver-specific objects ...
> > 
> > I'll take an example related to the rcar-du driver. The hardware groups
> > CRTCs by two and share resources (such as planes) between CRTCs in a
> > group. This is something I currently implement in a convoluted way, and
> > using private objects to handle groups (I already have a group object in
> > my driver) will likely help to model the group state.
> > 
> > On the other hand, if the hardware didn't have groups but shared planes
> > between all CRTCs, the shared resources would be global, and it would make
> > sense to store them in the global state.
> 
> Yeah the private stuff should probably get a hole lot better for singleton
> objects. I still think one global thing overall (and with a state handling
> pattern that's different from everything else) is not a good idea.
> 
> Now it would be fairly easy to generate all the silly boilerplate with a
> macro, but that tends to wreak havoc with cscope and friends, so I'm not
> sure it's a great idea really. I'll probably have better ideas once the
> i915 conversion exists ...

So how about splitting this in two steps then, first deprecating subclassing 
drm_atomic_state to store private object state, and only in a second step also 
deprecating subclassing the structure for global state ?

-- 
Regards,

Laurent Pinchart

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

Re: [Intel-gfx] [PATCH 4/5] drm/atomic: document how to handle driver private objects

[Daniel Vetter]

On Tue, Dec 19, 2017 at 03:33:57PM +0200, Laurent Pinchart wrote:
> On Tuesday, 19 December 2017 12:03:55 EET Daniel Vetter wrote:
> > On Mon, Dec 18, 2017 at 06:13:46PM +0200, Laurent Pinchart wrote:
> > > On Thursday, 14 December 2017 22:30:53 EET Daniel Vetter wrote:
> > >> + * Drivers are recommend to wrap these for each type of driver private
> > >> state
> > >> + * object they have, filtering on _private_obj.funcs using
> > >> for_each_if(), at
> > >> + * least if they want to iterate over all objects of a given type.
> > >> + *
> > >> + * An earlier way to handle driver private state was by subclassing
> > >> struct
> > >> + * _atomic_state. But since that encourages non-standard ways to
> > >> implement
> > >> + * the check/commit split atomic requires (by using e.g. "check and
> > >> rollback or
> > >> + * commit instead" of "duplicate state, check, then either commit or
> > >> release
> > >> + * duplicated state) it is deprecated in favour of using
> > >> _private_state.
> > > 
> > > This I still don't agree with. I think it still makes sense to subclass
> > > the global state object when you have true global state data. How about
> > > starting by making it a recommendation instead, moving state data related
> > > to driver- specific objects to the new framework, and keeping global data
> > > in the drm_atomic_state subclass ?
> > 
> > Converting all the existing drivers over is somewhere on my todo. I'm also
> > not really clear what you mean with global data compared to
> > driver-specific objects ...
> 
> I'll take an example related to the rcar-du driver. The hardware groups CRTCs 
> by two and share resources (such as planes) between CRTCs in a group. This is 
> something I currently implement in a convoluted way, and using private 
> objects 
> to handle groups (I already have a group object in my driver) will likely 
> help 
> to model the group state.
> 
> On the other hand, if the hardware didn't have groups but shared planes 
> between all CRTCs, the shared resources would be global, and it would make 
> sense to store them in the global state.

Yeah the private stuff should probably get a hole lot better for singleton
objects. I still think one global thing overall (and with a state handling
pattern that's different from everything else) is not a good idea.

Now it would be fairly easy to generate all the silly boilerplate with a
macro, but that tends to wreak havoc with cscope and friends, so I'm not
sure it's a great idea really. I'll probably have better ideas once the
i915 conversion exists ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/syncobj: Stop reusing the same struct file for all syncobj -> fd

[Patchwork]

== Series Details ==

Series: drm/syncobj: Stop reusing the same struct file for all syncobj -> fd
URL   : https://patchwork.freedesktop.org/series/35576/
State : success

== Summary ==

Series 35576v1 drm/syncobj: Stop reusing the same struct file for all syncobj 
-> fd
https://patchwork.freedesktop.org/api/1.0/series/35576/revisions/1/mbox/

Test gem_exec_nop:
Subgroup basic-series:
incomplete -> PASS   (fi-snb-2600)
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_psr_sink_crc:
Subgroup psr_basic:
dmesg-warn -> PASS   (fi-skl-6700hq) fdo#101144

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:437s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:275s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:478s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:262s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:385s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:477s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:523s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:523s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:527s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:505s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:444s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:543s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:406s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s

e044c9e03182a12636d79c909d3f272436862be6 drm-tip: 2017y-12m-19d-12h-46m-29s UTC 
integration manifest
3ed6b4d63f32 drm/syncobj: Stop reusing the same struct file for all syncobj -> 
fd

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/5] drm/atomic: document how to handle driver private objects

[Laurent Pinchart]

Hi Daniel,

On Tuesday, 19 December 2017 12:03:55 EET Daniel Vetter wrote:
> On Mon, Dec 18, 2017 at 06:13:46PM +0200, Laurent Pinchart wrote:
> > On Thursday, 14 December 2017 22:30:53 EET Daniel Vetter wrote:
> >> DK put some nice docs into the commit introducing driver private
> >> state, but in the git history alone it'll be lost.
> > 
> > You might want to spell DK's name fully.
> > 
> >> Also, since Ville remove the void* usage it's a good opportunity to
> >> give the driver private stuff some tlc on the doc front.
> >> 
> >> Finally try to explain why the "let's just subclass drm_atomic_state"
> >> approach wasn't the greatest, and annotate all those functions as
> >> deprecated in favour of more standardized driver private states. Also
> >> note where we could/should extend driver private states going forward
> >> (atm neither locking nor synchronization is handled in core/helpers,
> >> which isn't really all that great).
> >> 
> >> Cc: Harry Wentland 
> >> Cc: Dhinakaran Pandiyan 
> >> Cc: Maarten Lankhorst 
> >> Cc: Ville Syrjälä 
> >> Cc: Laurent Pinchart 
> >> Cc: Rob Clark 
> >> Cc: Alex Deucher 
> >> Cc: Ben Skeggs 
> >> Signed-off-by: Daniel Vetter 
> >> ---
> >> 
> >>  Documentation/gpu/drm-kms.rst |  6 ++
> >>  drivers/gpu/drm/drm_atomic.c  | 45 ++---
> >>  include/drm/drm_atomic.h  | 28 +++
> >>  include/drm/drm_mode_config.h |  9 +
> >>  4 files changed, 85 insertions(+), 3 deletions(-)

[snip]

> >> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >> index 37445d50816a..15e1a35c74a8 100644
> >> --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c

[snip]

> >> +/**
> >> + * DOC: handling driver private state
> >> + *
> >> + * Very often the DRM objects exposed to userspace in the atomic
> >> modeset api
> > 
> > s/api/API/
> > 
> >> + * (_connector, _crtc and _plane) do not map neatly to the
> >> + * underlying hardware. Especially for any kind of shared resources
> >> (e.g. shared
> >> + * clocks, scaler units, bandwidth and fifo limits shared among a group
> >> of
> >> + * planes or CRTCs, and so on) it makes sense to model these as
> >> independent
> >> + * objects. Drivers then need to similar state tracking and commit
> >> ordering for
> >> + * such private (since not exposed to userpace) objects as the atomic
> >> core and
> >> + * helpers already provide for connectors, planes and CRTCs.
> >> 
> >> + * To make this easier on drivers the atomic core provides some support
> >> to track
> >> + * driver private state objects using struct _private_obj, with the
> >> + * associated state struct _private_state.
> >> + *
> >> + * Similar to userspace-exposed objects, state structures can be
> >> acquired by
> >> + * calling drm_atomic_get_private_obj_state(). Since this function does
> >> not take
> >> + * care of locking, drivers should wrap it for each type of private
> >> state object
> >> + * they have with the required call to drm_modeset_lock() for the
> >> corresponding
> >> + * _modeset_lock.
> > 
> > This paragraph could benefit from an explanation of what the corresponding
> > drm_modeset_lock is. The rest of the document is pretty clear.
> 
> Hm yeah ... This is also one of those things I'd like to improve in the
> private state stuff: If we add a filed for the lock (a pointer, not the
> lock itself) we could simplify this stuff a lot.

We don't have to fix everything in one go of course, but a small explanation 
of what drivers are supposed to do would be helpful.

> >> + * All private state structures contained in a _atomic_state update
> >> can be
> >> + * iterated using for_each_oldnew_private_obj_in_state(),
> >> + * for_each_old_private_obj_in_state() and
> >> for_each_old_private_obj_in_state().
> > 
> > I think one of those two was meant to be
> > for_each_new_private_obj_in_state().
> 
> Fixed.
> 
> >> + * Drivers are recommend to wrap these for each type of driver private
> >> state
> >> + * object they have, filtering on _private_obj.funcs using
> >> for_each_if(), at
> >> + * least if they want to iterate over all objects of a given type.
> >> + *
> >> + * An earlier way to handle driver private state was by subclassing
> >> struct
> >> + * _atomic_state. But since that encourages non-standard ways to
> >> implement
> >> + * the check/commit split atomic requires (by using e.g. "check and
> >> rollback or
> >> + * commit instead" of "duplicate state, check, then either commit or
> >> release
> >> + * duplicated state) it is deprecated in favour of using
> >> _private_state.
> > 
> > This I still don't agree with. I think it still makes sense to subclass
> > the global state object when you have true