[Intel-gfx] ✗ Fi.CI.IGT: warning for WRPLL fixes for HDMI 2.0 on Cannonlake. (rev3)

2017-11-14 Thread Patchwork
== Series Details ==

Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev3)
URL   : https://patchwork.freedesktop.org/series/33823/
State : warning

== Summary ==

Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-legacy:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
pass   -> SKIP   (shard-hsw)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_flip:
Subgroup vblank-vs-dpms-suspend:
skip   -> PASS   (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-hsw)
Subgroup draw-method-rgb565-blt-xtiled:
skip   -> PASS   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-128x42-random:
skip   -> PASS   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_universal_plane:
Subgroup universal-plane-pipe-a-sanity:
skip   -> PASS   (shard-hsw)
Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-left-edge:
skip   -> PASS   (shard-hsw)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-hsw) fdo#102254

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-hswtotal:2584 pass:1469 dwarn:3   dfail:1   fail:10  skip:1101 
time:9445s
Blacklisted hosts:
shard-apltotal:2584 pass:1619 dwarn:3   dfail:1   fail:24  skip:936 
time:13075s
shard-kbltotal:2565 pass:1703 dwarn:7   dfail:0   fail:25  skip:829 
time:10603s
shard-snbtotal:2567 pass:1184 dwarn:1   dfail:0   fail:12  skip:1369 
time:7569s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7135/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 drm/i915/selftests: Always initialise err (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Always initialise err (rev2)
URL   : https://patchwork.freedesktop.org/series/33822/
State : success

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup vblank-vs-dpms-suspend:
skip   -> PASS   (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-mmap-gtt-untiled:
skip   -> PASS   (shard-hsw)
Subgroup draw-method-rgb565-blt-xtiled:
skip   -> PASS   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-128x42-random:
skip   -> PASS   (shard-hsw)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-hsw) fdo#102254
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_universal_plane:
Subgroup universal-plane-pipe-a-sanity:
skip   -> PASS   (shard-hsw)
Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-left-edge:
skip   -> PASS   (shard-hsw)

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2584 pass:1471 dwarn:3   dfail:1   fail:10  skip:1099 
time:9459s
Blacklisted hosts:
shard-apltotal:2565 pass:1601 dwarn:1   dfail:1   fail:25  skip:936 
time:12865s
shard-kbltotal:2493 pass:1660 dwarn:5   dfail:1   fail:25  skip:801 
time:10171s
shard-snbtotal:2584 pass:1199 dwarn:2   dfail:1   fail:12  skip:1370 
time:7783s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7132/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 series starting with [v4] lib: Attempt to load the module for a missing device (rev4)

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [v4] lib: Attempt to load the module for a missing 
device (rev4)
URL   : https://patchwork.freedesktop.org/series/33774/
State : warning

== Summary ==

Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707 +1
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup flip-vs-dpms-interruptible:
pass   -> DMESG-WARN (shard-hsw)
Subgroup flip-vs-absolute-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2584 pass:1469 dwarn:3   dfail:1   fail:12  skip:1099 
time:9445s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_504/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 drm/i915: Add might_sleep() check to wait_for()

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Add might_sleep() check to wait_for()
URL   : https://patchwork.freedesktop.org/series/33833/
State : success

== Summary ==

Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2584 pass:1469 dwarn:4   dfail:1   fail:11  skip:1099 
time:9341s
Blacklisted hosts:
shard-apltotal:2511 pass:1571 dwarn:1   dfail:1   fail:23  skip:915 
time:12942s
shard-kbltotal:2565 pass:1669 dwarn:37  dfail:1   fail:28  skip:829 
time:10620s
shard-snbtotal:2584 pass:1202 dwarn:1   dfail:1   fail:13  skip:1367 
time:7781s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7131/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 series starting with [1/8] drm/i915/selftests: Increase size for mock ringbuffer

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [1/8] drm/i915/selftests: Increase size for mock 
ringbuffer
URL   : https://patchwork.freedesktop.org/series/33830/
State : success

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)

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

shard-hswtotal:2584 pass:1470 dwarn:4   dfail:1   fail:10  skip:1099 
time:9447s
Blacklisted hosts:
shard-apltotal:2506 pass:1569 dwarn:1   dfail:0   fail:17  skip:917 
time:12173s
shard-kbltotal:2517 pass:1665 dwarn:8   dfail:2   fail:17  skip:823 
time:10141s
shard-snbtotal:2548 pass:1185 dwarn:1   dfail:1   fail:13  skip:1346 
time:7491s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7130/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 WRPLL fixes for HDMI 2.0 on Cannonlake. (rev3)

2017-11-14 Thread Patchwork
== Series Details ==

Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev3)
URL   : https://patchwork.freedesktop.org/series/33823/
State : success

== Summary ==

Series 33823v3 WRPLL fixes for HDMI 2.0 on Cannonlake.
https://patchwork.freedesktop.org/api/1.0/series/33823/revisions/3/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_busy:
Subgroup basic-flip-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-c:
skip   -> PASS   (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-busy-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-hsw-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r) fdo#102332
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-rte:
skip   -> PASS   (fi-hsw-4770r)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-hsw-4770r)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:540s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:274s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/kms_rotation_crc: Add RGB565 90 degree test for gen>9 (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: igt/kms_rotation_crc: Add RGB565 90 degree test for gen>9 (rev2)
URL   : https://patchwork.freedesktop.org/series/33132/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-hsw) fdo#102707 +1
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-legacy:
pass   -> FAIL   (shard-hsw) fdo#102670
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
pass   -> DMESG-WARN (shard-hsw) fdo#103038

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038

shard-hswtotal:2585 pass:1470 dwarn:3   dfail:1   fail:11  skip:1100 
time:9457s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_502/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 WRPLL fixes for HDMI 2.0 on Cannonlake. (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: WRPLL fixes for HDMI 2.0 on Cannonlake. (rev2)
URL   : https://patchwork.freedesktop.org/series/33823/
State : success

== Summary ==

Series 33823v2 WRPLL fixes for HDMI 2.0 on Cannonlake.
https://patchwork.freedesktop.org/api/1.0/series/33823/revisions/2/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_busy:
Subgroup basic-flip-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-c:
skip   -> PASS   (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-busy-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-hsw-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r) fdo#102332
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-rte:
skip   -> PASS   (fi-hsw-4770r)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-hsw-4770r)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:462s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:275s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   

[Intel-gfx] [PATCH] drm/i915/cnl: Simplify dco_fraction calculation.

2017-11-14 Thread Rodrigo Vivi
I confess I never fully understood that previous calculation,
so this is not a "fix". But let's simplify this math
so poor brains like mine can read and make some sense of
it in the future.

v2: Don't follow the spec since that gives invalid
values and it is also confusing. This Ville's
version is much simpler.

Cc: Ville Syrjälä 
Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 361b7102b602..f9651accecc9 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2153,6 +2153,8 @@ static void cnl_wrpll_params_populate(struct 
skl_wrpll_params *params,
  u32 dco_freq, u32 ref_freq,
  int pdiv, int qdiv, int kdiv)
 {
+   u64 dco;
+
switch (kdiv) {
case 1:
params->kdiv = 1;
@@ -2189,9 +2191,10 @@ static void cnl_wrpll_params_populate(struct 
skl_wrpll_params *params,
params->qdiv_ratio = qdiv;
params->qdiv_mode = (qdiv == 1) ? 0 : 1;
 
-   params->dco_integer = div_u64(dco_freq, ref_freq);
-   params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
(uint64_t)ref_freq) -
-   ((uint64_t)params->dco_integer<<15)) * 
0x8000, 0x8000);
+   dco = dco_freq;
+   dco = div_u64(dco << 15, ref_freq);
+   params->dco_integer = dco >> 15;
+   params->dco_fraction = dco & 0x7fff;
 }
 
 static bool
-- 
2.13.6

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for lib: Ask the kernel to quiesce the GPU (rev3)

2017-11-14 Thread Patchwork
== Series Details ==

Series: lib: Ask the kernel to quiesce the GPU (rev3)
URL   : https://patchwork.freedesktop.org/series/31850/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
f370d5903689f37620e006f004a91d6bdeac7c16 lib/i915: Query semaphore status using 
GETPARAM

with latest DRM-Tip kernel build CI_DRM_3346
5f7fd97a513a drm-tip: 2017y-11m-14d-21h-04m-27s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test gem_sync:
Subgroup basic-all:
pass   -> DMESG-FAIL (fi-blb-e6850)
pass   -> FAIL   (fi-pnv-d510)
Test kms_busy:
Subgroup basic-flip-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-c:
skip   -> PASS   (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-busy-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-hsw-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r) fdo#102332
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-kbl-7560u)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-rte:
skip   -> PASS   (fi-hsw-4770r)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-hsw-4770r)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:460s
fi-blb-e6850 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Always initialise err

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Always initialise err
URL   : https://patchwork.freedesktop.org/series/33822/
State : success

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)

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

shard-hswtotal:2584 pass:1471 dwarn:3   dfail:1   fail:10  skip:1099 
time:9456s
Blacklisted hosts:
shard-apltotal:2565 pass:1602 dwarn:1   dfail:1   fail:23  skip:936 
time:12716s
shard-kbltotal:2565 pass:1703 dwarn:6   dfail:1   fail:25  skip:829 
time:10529s
shard-snbtotal:2584 pass:1201 dwarn:2   dfail:1   fail:13  skip:1367 
time:7751s

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915/cnl: Fix wrpll math for higher freqs.

2017-11-14 Thread Rodrigo Vivi
Spec describe all values in MHz. We handle our
clocks in KHz. This includes the best_dco_centrality that was
forgot in the same unity as spec. Consequently we couldn't
get a good divider for high frequenies. Hence HDMI 2.0 wasn't
working.

Spec tells 99 for initial best_dco_centrality meaning the
max value in MHz.
Since we convert dco from MHz to KHz we also need to convert
this initial best_doc_centrality to 99000 or 9
or even better, to the max that its variable allow.

This patch also replaces the use of "* KHz(1)" with the values
directly on KHz to avoid future confusion.

v2: Use U32_MAX instead of random 9 as spec tells. (Ville).

Cc: Ville Syrjälä 
Cc: Shashank Sharma 
Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index fba969cbda37..6cc12abdd39e 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2201,8 +2201,8 @@ cnl_ddi_calculate_wrpll(int clock,
struct skl_wrpll_params *wrpll_params)
 {
u32 afe_clock = clock * 5;
-   u32 dco_min = 7998 * KHz(1);
-   u32 dco_max = 1 * KHz(1);
+   u32 dco_min = 7998000;
+   u32 dco_max = 1000;
u32 dco_mid = (dco_min + dco_max) / 2;
static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
 18, 20, 24, 28, 30, 32,  36,  40,
@@ -2211,7 +2211,7 @@ cnl_ddi_calculate_wrpll(int clock,
 84, 88, 90, 92, 96, 98, 100, 102,
  3,  5,  7,  9, 15, 21 };
u32 dco, best_dco = 0, dco_centrality = 0;
-   u32 best_dco_centrality = 99;
+   u32 best_dco_centrality = U32_MAX; /* Spec meaning of 99 MHz */
int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
 
for (d = 0; d < ARRAY_SIZE(dividers); d++) {
-- 
2.13.6

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


Re: [Intel-gfx] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

2017-11-14 Thread neil k
I tested the patch from Ville Syrjälä's email and it works fine on top of
4.14 for me.

Thanks,
Neil

On Thu, Nov 9, 2017 at 1:16 PM, Eric Anholt  wrote:

> Daniel Vetter  writes:
>
> > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
> >> Ville Syrjälä  writes:
> >>
> >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> >> >> Ville Syrjala  writes:
> >> >>
> >> >> > From: Ville Syrjälä 
> >> >> >
> >> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
> >> >> > and they get somehow confused when they see a non-zero YQ value.
> >> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
> >> >> > RGB range.
> >> >> >
> >> >> > Unfortunately there is no good way to tell whether the sink
> >> >> > designer claims to have read CEA-861-F. The CEA extension block
> >> >> > revision number has generally been stuck at 3 since forever,
> >> >> > and even a very recently manufactured sink might be based on
> >> >> > an old design so the manufacturing date doesn't seem like
> >> >> > something we can use. In lieu of better information let's
> >> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> >> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> >> >> >
> >> >> > The alternative would of course be to always set YQ=0. And if
> >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> >> >> > we'll probably have to do.
> >> >>
> >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an
> HDMI1.4
> >> >> source?
> >> >
> >> > As long as you stick to < 340 MHz modes you shouldn't have to do
> >> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
> >> >
> >> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> >> > to bridges/encoders to filter out most things that aren't supported?
> >>
> >> I had a patch for that at
> >> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
> >> into trouble with 4k monitors.
> >
> > Ack on the clock limiting patch, silly that it's stuck. No idea about
> CEC,
> > better for Hans/Boris I guess.
>
> Thanks!
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/7] drm/i915/cnl: Don't blindly replace qdiv.

2017-11-14 Thread Manasi Navare
On Tue, Nov 14, 2017 at 11:47:57AM -0800, Rodrigo Vivi wrote:
> Accordingly to spec "If Kdiv != 2, then Qdiv must be 1."
> but we already handle qdiv values properly and this case here
> should be spurious. But instead of blindly replacing let's
> warn loudly instead. Because it means something was really
> wrong on initial setup.
> 
> Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: James Ausmus 
> Signed-off-by: Rodrigo Vivi 

Reviewed-by: Manasi Navare 

> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 53f650f56148..bd608f7f2399 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2184,8 +2184,7 @@ static void cnl_wrpll_params_populate(struct 
> skl_wrpll_params *params,
>   WARN(1, "Incorrect PDiv\n");
>   }
>  
> - if (kdiv != 2)
> - qdiv = 1;
> + WARN_ON(kdiv != 2 && qdiv != 1);
>  
>   params->qdiv_ratio = qdiv;
>   params->qdiv_mode = (qdiv == 1) ? 0 : 1;
> -- 
> 2.13.6
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects
URL   : https://patchwork.freedesktop.org/series/33840/
State : warning

== Summary ==

Series 33840v1 drm/i915: Prevent overflow of execbuf.buffer_count and 
num_cliprects
https://patchwork.freedesktop.org/api/1.0/series/33840/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Test kms_busy:
Subgroup basic-flip-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-c:
skip   -> PASS   (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-busy-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-hsw-4770r)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r) fdo#102332
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-rte:
skip   -> PASS   (fi-hsw-4770r)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-hsw-4770r)

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

WARNING: Long output truncated
fi-cnl-y failed to connect after reboot

5f7fd97a513ac1f0b84c61fae3fc83d4432e602c drm-tip: 2017y-11m-14d-21h-04m-27s UTC 
integration manifest
6e76cdcdb645 drm/i915: Prevent overflow of 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/cnl: Write dco_fraction calculation as spec.

2017-11-14 Thread Rodrigo Vivi
On Tue, Nov 14, 2017 at 09:29:57PM +, Rodrigo Vivi wrote:
> On Tue, Nov 14, 2017 at 08:46:38PM +, Ville Syrjälä wrote:
> > On Tue, Nov 14, 2017 at 10:22:27PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 14, 2017 at 11:47:58AM -0800, Rodrigo Vivi wrote:
> > > > I confess I never fully understood that previous calculation,
> > > > so maybe this is cannot be called a "fix". But let's follow
> > > > the math that is written on Spec so we have get more confident
> > > > this is what hardware expect.
> > > >
> > > > Cc: Mika Kahola 
> > > > Cc: Manasi Navare 
> > > > Cc: James Ausmus 
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > index bd608f7f2399..ee690d2f6e54 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > > @@ -2190,8 +2190,8 @@ static void cnl_wrpll_params_populate(struct 
> > > > skl_wrpll_params *params,
> > > > params->qdiv_mode = (qdiv == 1) ? 0 : 1;
> > > >
> > > > params->dco_integer = div_u64(dco_freq, ref_freq);
> > > > -   params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
> > > > (uint64_t)ref_freq) -
> > > > -   
> > > > ((uint64_t)params->dco_integer<<15)) * 0x8000, 0x8000);
> > > > +   params->dco_fraction = (DIV_ROUND_UP_ULL(dco_freq, ref_freq) -
> > > > +   params->dco_integer) * (1 << 15);
> > >
> > > Is dco_freq in khz here? Or hz?
> > >
> > > If khz, the following should work... I think:
> > >
>
> > > unsigned int dco = div_u64((u64)dco_freq << 15, ref_freq * 1000);
> >
> > Actually w/o the *1000 I suppose, for khz.
>
> On python it works apparently:
> * (7998750 << 15)/24000
> 10920960 #"dco"
> * ((7998750 << 15)/24000)>>15
> 333 #int
> * ((7998750 << 15)/24000)&0x7
> 435200 #frac
>
> while on our code we get
> dco = 4584
> so int = 0
> and frac = 4584...
>
> div_u64 not working in float?

oh! u32 << 15 was the issue...

So, with this code:

u64 dco = dco_freq;
dco = div_u64(dco << 15, ref_freq);
params->dco_integer = dco >> 15;
params->dco_fraction = dco & 0x7fff;

we have int 333 as expected and frac 92116 as the orig code.
So it seems the orig code was better after all. Although I'd
still want to clean it up.

But what bothers me now is that python gives a different frac
and also calculator shows this division as 333.28125

nothing seems to make us to get this 28125...

:/

but now that I know how it is all my attempts here lead me to 92116
and it works...

Thanks,
Rodrigo.

>
> also this shows me that while this python gives us the frac 435200
> my current code that follows spec gives frac 32768
> and previous code was giving frac 9216
>
> :/
>
> more thoughts?
>
> >
> > > dco_int = dco >> 15;
> > > dco_frac = dco & 0x7fff;
> > >
> > > >  }
> > > >
> > > >  static bool
> > > > --
> > > > 2.13.6
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > > --
> > > Ville Syrjälä
> > > Intel OTC
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > 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.IGT: success for drm/i915/selftests: Markup __iomem for igt_gem_coherency

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Markup __iomem for igt_gem_coherency
URL   : https://patchwork.freedesktop.org/series/33819/
State : success

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)

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

shard-hswtotal:2584 pass:1471 dwarn:3   dfail:1   fail:10  skip:1099 
time:9446s
Blacklisted hosts:
shard-apltotal:2563 pass:1601 dwarn:1   dfail:0   fail:24  skip:936 
time:12674s
shard-kbltotal:2565 pass:1706 dwarn:5   dfail:0   fail:24  skip:829 
time:10604s
shard-snbtotal:2584 pass:1199 dwarn:2   dfail:1   fail:13  skip:1369 
time:7767s

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Always initialise err (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Always initialise err (rev2)
URL   : https://patchwork.freedesktop.org/series/33822/
State : success

== Summary ==

Series 33822v2 drm/i915/selftests: Always initialise err
https://patchwork.freedesktop.org/api/1.0/series/33822/revisions/2/mbox/

Test kms_busy:
Subgroup basic-flip-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-c:
skip   -> PASS   (fi-hsw-4770r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-gdg-551) fdo#102618
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-after-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-atomic:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-legacy:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-before-cursor-varying-size:
skip   -> PASS   (fi-hsw-4770r)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-modeset:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-flip-vs-wf_vblank:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-plain-flip:
skip   -> PASS   (fi-hsw-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
skip   -> PASS   (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup hang-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
skip   -> PASS   (fi-hsw-4770r) fdo#102332
Subgroup read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-b:
skip   -> PASS   (fi-hsw-4770r)
Subgroup suspend-read-crc-pipe-c:
skip   -> PASS   (fi-hsw-4770r)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> PASS   (fi-hsw-4770r)
Subgroup basic-rte:
skip   -> PASS   (fi-hsw-4770r)
Test prime_vgem:
Subgroup basic-fence-flip:
skip   -> PASS   (fi-hsw-4770r)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:383s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:539s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:275s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:497s
fi-byt-n2820

[Intel-gfx] [resend] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

2017-11-14 Thread Chris Wilson
We check whether the multiplies will overflow prior to calling
kmalloc_array so that we can respond with -EINVAL for the invalid user
arguments rather than treating it as an -ENOMEM that would otherwise
occur. However, as Dan Carpenter pointed out, we did an addition on the
unsigned int prior to passing to kmalloc_array where it would be
promoted to size_t for the calculation, thereby allowing it to overflow
and underallocate.

v2: buffer_count is currently limited to INT_MAX because we treat it as
signaled variable for LUT_HANDLE in eb_lookup_vma

Reported-by: Dan Carpenter 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 33 --
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 435ed95df144..a8dec9abe33d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2074,7 +2074,7 @@ static struct drm_syncobj **
 get_fence_array(struct drm_i915_gem_execbuffer2 *args,
struct drm_file *file)
 {
-   const unsigned int nfences = args->num_cliprects;
+   const size_t nfences = args->num_cliprects;
struct drm_i915_gem_exec_fence __user *user;
struct drm_syncobj **fences;
unsigned int n;
@@ -2083,14 +2083,14 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
if (!(args->flags & I915_EXEC_FENCE_ARRAY))
return NULL;
 
-   if (nfences > SIZE_MAX / sizeof(*fences))
+   if (nfences > SIZE_MAX / max(sizeof(*fences), 2*sizeof(u32)))
return ERR_PTR(-EINVAL);
 
user = u64_to_user_ptr(args->cliprects_ptr);
if (!access_ok(VERIFY_READ, user, nfences * 2 * sizeof(u32)))
return ERR_PTR(-EFAULT);
 
-   fences = kvmalloc_array(args->num_cliprects, sizeof(*fences),
+   fences = kvmalloc_array(nfences, sizeof(*fences),
__GFP_NOWARN | GFP_KERNEL);
if (!fences)
return ERR_PTR(-ENOMEM);
@@ -2462,11 +2462,13 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_i915_gem_execbuffer2 exec2;
struct drm_i915_gem_exec_object *exec_list = NULL;
struct drm_i915_gem_exec_object2 *exec2_list = NULL;
+   const size_t count = args->buffer_count;
unsigned int i;
int err;
 
-   if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
-   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
+   /* Lookups via HANDLE_LUT are limited to INT_MAX (see eb_create()) */
+   if (count < 1 || count > INT_MAX || count > SIZE_MAX / sz - 1) {
+   DRM_DEBUG("execbuf2 with %zd buffers\n", count);
return -EINVAL;
}
 
@@ -2485,9 +2487,9 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
return -EINVAL;
 
/* Copy in the exec list from userland */
-   exec_list = kvmalloc_array(args->buffer_count, sizeof(*exec_list),
+   exec_list = kvmalloc_array(count, sizeof(*exec_list),
   __GFP_NOWARN | GFP_KERNEL);
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 1, sz,
__GFP_NOWARN | GFP_KERNEL);
if (exec_list == NULL || exec2_list == NULL) {
DRM_DEBUG("Failed to allocate exec list for %d buffers\n",
@@ -2498,7 +2500,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
}
err = copy_from_user(exec_list,
 u64_to_user_ptr(args->buffers_ptr),
-sizeof(*exec_list) * args->buffer_count);
+sizeof(*exec_list) * count);
if (err) {
DRM_DEBUG("copy %d exec entries failed %d\n",
  args->buffer_count, err);
@@ -2554,10 +2556,11 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
struct drm_i915_gem_execbuffer2 *args = data;
struct drm_i915_gem_exec_object2 *exec2_list;
struct drm_syncobj **fences = NULL;
+   const size_t count = args->buffer_count;
int err;
 
-   if (args->buffer_count < 1 || args->buffer_count > SIZE_MAX / sz - 1) {
-   DRM_DEBUG("execbuf2 with %d buffers\n", args->buffer_count);
+   if (count < 1 || count > SIZE_MAX / sz - 1) {
+   DRM_DEBUG("execbuf2 with %zd buffers\n", count);
return -EINVAL;
}
 
@@ -2565,17 +2568,17 @@ i915_gem_execbuffer2(struct drm_device *dev, void *data,
return -EINVAL;
 
/* Allocate an extra slot for use by the command parser */
-   exec2_list = kvmalloc_array(args->buffer_count + 1, sz,
+   exec2_list = kvmalloc_array(count + 1, 

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Drop the unbound page cache upon idling

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Drop the unbound page cache upon 
idling
URL   : https://patchwork.freedesktop.org/series/33817/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Subgroup basic-modeset-a:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup render-flip-vs-panning-interruptible:
pass   -> SKIP   (shard-hsw)
Test kms_atomic_interruptible:
Subgroup legacy-pageflip:
pass   -> SKIP   (shard-hsw)
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252 +1

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

shard-hswtotal:2584 pass:1467 dwarn:3   dfail:1   fail:11  skip:1102 
time:9394s
Blacklisted hosts:
shard-apltotal:2584 pass:1621 dwarn:2   dfail:1   fail:24  skip:936 
time:13217s
shard-kbltotal:2565 pass:1704 dwarn:6   dfail:0   fail:25  skip:829 
time:10606s
shard-snbtotal:2584 pass:1210 dwarn:1   dfail:1   fail:13  skip:1359 
time:7705s

== Logs ==

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


Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Always initialise err

2017-11-14 Thread Pandiyan, Dhinakaran
On Tue, 2017-11-14 at 22:33 +, Chris Wilson wrote:
> smatch does not track initialised values as well as gcc, and this
> triggers many warnings by smatch not presented by gcc. Silence smatch by
> initialising the error values to -ENODEV, which we use to denote
> internal errors. (If we see a selftest fail with a silent -ENODEV, we
> know smatch was right!)
> 
> v2: smatch was right about igt_create_vma(), it may unlikely fail on the
> first object allocation which we want to be loud about.
> 

Reviewed-by: Dhinakaran Pandiyan 

> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_context.c  | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  | 8 
>  drivers/gpu/drm/i915/selftests/i915_gem_request.c  | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 6 +++---
>  drivers/gpu/drm/i915/selftests/i915_vma.c  | 2 +-
>  6 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> index 61fcfa2c4dfd..664d1b4f8c69 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> @@ -321,7 +321,7 @@ static int igt_ctx_exec(void *arg)
>   LIST_HEAD(objects);
>   unsigned long ncontexts, ndwords, dw;
>   bool first_shared_gtt = true;
> - int err;
> + int err = -ENODEV;
>  
>   /* Create a few different contexts (with different mm) and write
>* through each ctx/mm using the GPU making sure those writes end
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 581296860539..d9560d8a6cc8 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -699,7 +699,7 @@ static int drunk_hole(struct drm_i915_private *i915,
>   unsigned int *order, count, n;
>   struct i915_vma *vma;
>   u64 hole_size;
> - int err;
> + int err = -ENODEV;
>  
>   hole_size = (hole_end - hole_start) >> size;
>   if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
> @@ -958,7 +958,7 @@ static int exercise_ggtt(struct drm_i915_private *i915,
>   u64 hole_start, hole_end, last = 0;
>   struct drm_mm_node *node;
>   IGT_TIMEOUT(end_time);
> - int err;
> + int err = -ENODEV;
>  
>   mutex_lock(>drm.struct_mutex);
>  restart:
> @@ -1164,7 +1164,7 @@ static int igt_gtt_reserve(void *arg)
>   struct drm_i915_gem_object *obj, *on;
>   LIST_HEAD(objects);
>   u64 total;
> - int err;
> + int err = -ENODEV;
>  
>   /* i915_gem_gtt_reserve() tries to reserve the precise range
>* for the node, and evicts if it has to. So our test checks that
> @@ -1355,7 +1355,7 @@ static int igt_gtt_insert(void *arg)
>   }, *ii;
>   LIST_HEAD(objects);
>   u64 total;
> - int err;
> + int err = -ENODEV;
>  
>   /* i915_gem_gtt_insert() tries to allocate some free space in the GTT
>* to the node, evicting if required.
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> index 9a35ebd5c876..e3871db78beb 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
> @@ -332,7 +332,7 @@ static int live_nop_request(void *arg)
>   struct intel_engine_cs *engine;
>   struct live_test t;
>   unsigned int id;
> - int err;
> + int err = -ENODEV;
>  
>   /* Submit various sized batches of empty requests, to each engine
>* (individually), and wait for the batch to complete. We can check
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
> index 4795877abe56..3000e6a7d82d 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
> @@ -79,7 +79,7 @@ static int igt_sync(void *arg)
>   }, *p;
>   struct intel_timeline *tl;
>   int order, offset;
> - int ret;
> + int ret = -ENODEV;
>  
>   tl = mock_timeline(0);
>   if (!tl)
> diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
> b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
> index bcab3d00a785..47f4ae18a1ef 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
> @@ -333,7 +333,7 @@ static int igt_syncmap_join_below(void *arg)
>  {
>   struct i915_syncmap *sync;
>   unsigned int step, order, idx;
> - int err;
> + int err = -ENODEV;
>  
>   i915_syncmap_init();
>  
> @@ -402,7 +402,7 @@ static int igt_syncmap_neighbours(void *arg)
>   I915_RND_STATE(prng);

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4] lib: Attempt to load the module for a missing device (rev4)

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [v4] lib: Attempt to load the module for a missing 
device (rev4)
URL   : https://patchwork.freedesktop.org/series/33774/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
f370d5903689f37620e006f004a91d6bdeac7c16 lib/i915: Query semaphore status using 
GETPARAM

with latest DRM-Tip kernel build CI_DRM_3345
c46476e24d64 drm-tip: 2017y-11m-14d-17h-03m-32s UTC integration manifest

No testlist changes.

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:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:458s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:556s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:509s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:505s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:496s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:267s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:436s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:425s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:536s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:571s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:545s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:527s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:559s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:424s
Blacklisted hosts:
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:534s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:558s

== Logs ==

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


[Intel-gfx] [PATCH v2] drm/i915/selftests: Always initialise err

2017-11-14 Thread Chris Wilson
smatch does not track initialised values as well as gcc, and this
triggers many warnings by smatch not presented by gcc. Silence smatch by
initialising the error values to -ENODEV, which we use to denote
internal errors. (If we see a selftest fail with a silent -ENODEV, we
know smatch was right!)

v2: smatch was right about igt_create_vma(), it may unlikely fail on the
first object allocation which we want to be loud about.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_gem_context.c  | 2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  | 8 
 drivers/gpu/drm/i915/selftests/i915_gem_request.c  | 2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 2 +-
 drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 6 +++---
 drivers/gpu/drm/i915/selftests/i915_vma.c  | 2 +-
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 61fcfa2c4dfd..664d1b4f8c69 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -321,7 +321,7 @@ static int igt_ctx_exec(void *arg)
LIST_HEAD(objects);
unsigned long ncontexts, ndwords, dw;
bool first_shared_gtt = true;
-   int err;
+   int err = -ENODEV;
 
/* Create a few different contexts (with different mm) and write
 * through each ctx/mm using the GPU making sure those writes end
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 581296860539..d9560d8a6cc8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -699,7 +699,7 @@ static int drunk_hole(struct drm_i915_private *i915,
unsigned int *order, count, n;
struct i915_vma *vma;
u64 hole_size;
-   int err;
+   int err = -ENODEV;
 
hole_size = (hole_end - hole_start) >> size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
@@ -958,7 +958,7 @@ static int exercise_ggtt(struct drm_i915_private *i915,
u64 hole_start, hole_end, last = 0;
struct drm_mm_node *node;
IGT_TIMEOUT(end_time);
-   int err;
+   int err = -ENODEV;
 
mutex_lock(>drm.struct_mutex);
 restart:
@@ -1164,7 +1164,7 @@ static int igt_gtt_reserve(void *arg)
struct drm_i915_gem_object *obj, *on;
LIST_HEAD(objects);
u64 total;
-   int err;
+   int err = -ENODEV;
 
/* i915_gem_gtt_reserve() tries to reserve the precise range
 * for the node, and evicts if it has to. So our test checks that
@@ -1355,7 +1355,7 @@ static int igt_gtt_insert(void *arg)
}, *ii;
LIST_HEAD(objects);
u64 total;
-   int err;
+   int err = -ENODEV;
 
/* i915_gem_gtt_insert() tries to allocate some free space in the GTT
 * to the node, evicting if required.
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
index 9a35ebd5c876..e3871db78beb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
@@ -332,7 +332,7 @@ static int live_nop_request(void *arg)
struct intel_engine_cs *engine;
struct live_test t;
unsigned int id;
-   int err;
+   int err = -ENODEV;
 
/* Submit various sized batches of empty requests, to each engine
 * (individually), and wait for the batch to complete. We can check
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
index 4795877abe56..3000e6a7d82d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
@@ -79,7 +79,7 @@ static int igt_sync(void *arg)
}, *p;
struct intel_timeline *tl;
int order, offset;
-   int ret;
+   int ret = -ENODEV;
 
tl = mock_timeline(0);
if (!tl)
diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
index bcab3d00a785..47f4ae18a1ef 100644
--- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
@@ -333,7 +333,7 @@ static int igt_syncmap_join_below(void *arg)
 {
struct i915_syncmap *sync;
unsigned int step, order, idx;
-   int err;
+   int err = -ENODEV;
 
i915_syncmap_init();
 
@@ -402,7 +402,7 @@ static int igt_syncmap_neighbours(void *arg)
I915_RND_STATE(prng);
IGT_TIMEOUT(end_time);
struct i915_syncmap *sync;
-   int err;
+   int err = -ENODEV;
 
/*
 * Each leaf holds KSYNCMAP seqno. Check that when we create KSYNCMAP
@@ -447,7 +447,7 @@ static int 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add might_sleep() check to wait_for()

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Add might_sleep() check to wait_for()
URL   : https://patchwork.freedesktop.org/series/33833/
State : success

== Summary ==

Series 33833v1 drm/i915: Add might_sleep() check to wait_for()
https://patchwork.freedesktop.org/api/1.0/series/33833/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:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:547s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:498s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:487s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:261s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:438s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:429s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:482s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:539s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:574s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:547s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:465s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:570s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:426s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:534s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:561s
fi-glk-dsi   total:206  pass:183  dwarn:0   dfail:0   fail:0   skip:22 

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
d3bfd81a99b5 drm/i915: Add might_sleep() check to wait_for()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7131/
___
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: Fix kerneldocs for intel_audio.c

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix kerneldocs for intel_audio.c
URL   : https://patchwork.freedesktop.org/series/33816/
State : warning

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-a:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)
Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> FAIL   (shard-hsw) fdo#102332
Test kms_chv_cursor_fail:
Subgroup pipe-c-128x128-top-edge:
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#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2584 pass:1471 dwarn:3   dfail:1   fail:10  skip:1099 
time:9448s
Blacklisted hosts:
shard-apltotal:2565 pass:1602 dwarn:1   dfail:0   fail:25  skip:936 
time:12701s
shard-kbltotal:2517 pass:1644 dwarn:29  dfail:1   fail:23  skip:818 
time:10145s
shard-snbtotal:2567 pass:1185 dwarn:2   dfail:0   fail:12  skip:1367 
time:7595s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7125/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/selftests: Always initialise err

2017-11-14 Thread Pandiyan, Dhinakaran

On Tue, 2017-11-14 at 19:47 +, Chris Wilson wrote:
> smatch does not track initialised values as well as gcc, and this
> triggers many warnings by smatch not presented by gcc. Silence smatch by
> initialising the error values to -ENODEV, which we use to denote
> internal errors. (If we see a selftest fail with a silent -ENODEV, we
> know smatch was right!)
> 

The missed initialization in igt_vma_create() looks genuine.

> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_context.c  | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  | 8 
>  drivers/gpu/drm/i915/selftests/i915_gem_request.c  | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 2 +-
>  drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 6 +++---
>  drivers/gpu/drm/i915/selftests/i915_vma.c  | 2 +-
>  6 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> index 61fcfa2c4dfd..664d1b4f8c69 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> @@ -321,7 +321,7 @@ static int igt_ctx_exec(void *arg)
>   LIST_HEAD(objects);
>   unsigned long ncontexts, ndwords, dw;
>   bool first_shared_gtt = true;
> - int err;
> + int err = -ENODEV;
>  
>   /* Create a few different contexts (with different mm) and write
>* through each ctx/mm using the GPU making sure those writes end
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 581296860539..d9560d8a6cc8 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -699,7 +699,7 @@ static int drunk_hole(struct drm_i915_private *i915,
>   unsigned int *order, count, n;
>   struct i915_vma *vma;
>   u64 hole_size;
> - int err;
> + int err = -ENODEV;

The goto label in this function is also named err, the function does
seem drunk.

>  
>   hole_size = (hole_end - hole_start) >> size;
>   if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))



> diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c 
> b/drivers/gpu/drm/i915/selftests/i915_vma.c
> index 2e86ec136b35..19ad42974431 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> @@ -150,7 +150,7 @@ static int igt_vma_create(void *arg)
>   IGT_TIMEOUT(end_time);
>   LIST_HEAD(contexts);
>   LIST_HEAD(objects);
> - int err;
> + int err = -ENODEV;
>  
>   /* Exercise creating many vma amonst many objections, checking the
>* vma creation and lookup routines.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/selftests: Increase size for mock ringbuffer

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [1/8] drm/i915/selftests: Increase size for mock 
ringbuffer
URL   : https://patchwork.freedesktop.org/series/33830/
State : success

== Summary ==

Series 33830v1 series starting with [1/8] drm/i915/selftests: Increase size for 
mock ringbuffer
https://patchwork.freedesktop.org/api/1.0/series/33830/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:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:454s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:378s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:544s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:273s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:495s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:428s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:440s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:430s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:569s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:545s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:560s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:420s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:533s
fi-cnl-y total:238  pass:213  dwarn:0   dfail:0   fail:0   skip:24 
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:490s

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
ac6b6b22d6f7 drm/i915: Remove i915.semaphores modparam
e06003755318 drm/i915: Move debugfs/i915_semaphore_status to i915_engine_info
fa9569a8802c drm/i915: Disable semaphores on Sandybridge
e72956d9b9f4 drm/i915: Remove obsolete ringbuffer emission for gen8+
24ff3bfeb616 drm/i915: Remove i915.enable_execlists module parameter
a8d9e6d57b70 drm/i915: Automatic i915_switch_context for legacy
1825aaf2e6f1 drm/i915: Make request's wait-for-space explicit
291d85046393 drm/i915/selftests: Increase size for mock ringbuffer

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Add might_sleep() check to wait_for()

2017-11-14 Thread Chris Wilson
We should long past the time of trying to use wait_for() from inside
atomic contexts, so add a might_sleep() check to prevent misuse.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_drv.h | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fd64a5e8ea12..a898ded7efe9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -47,14 +47,11 @@
  * contexts. Note that it's important that we check the condition again after
  * having timed out, since the timeout could be due to preemption or similar 
and
  * we've never had a chance to check the condition before the timeout.
- *
- * TODO: When modesetting has fully transitioned to atomic, the below
- * drm_can_sleep() can be removed and in_atomic()/!in_atomic() asserts
- * added.
  */
 #define _wait_for(COND, US, W) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
int ret__;  \
+   might_sleep();  \
for (;;) {  \
bool expired__ = time_after(jiffies, timeout__);\
if (COND) { \
@@ -65,11 +62,7 @@
ret__ = -ETIMEDOUT; \
break;  \
}   \
-   if ((W) && drm_can_sleep()) {   \
-   usleep_range((W), (W)*2);   \
-   } else {\
-   cpu_relax();\
-   }   \
+   usleep_range((W), (W)*2);   \
}   \
ret__;  \
 })
-- 
2.15.0

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


[Intel-gfx] [PATCH igt] lib: Ask the kernel to quiesce the GPU

2017-11-14 Thread Chris Wilson
Since the introduction of debugfs/i915_drop_caches, we have offered the
ability to wait upon all outstanding batches. This is more efficient and
less error prone (one example is the use of context priorities, we have
to idle at the lowest in order not to jump over any low priority tasks
we want to wait upon) than trying to do it all in userspace. Though we
could if we wanted to, it's just easier to use the existing facility
designed for the purpose -- that we were already partially using!

Note that debugfs/i915_drop_caches has only existed since v4.2.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Petri Latvala 
---
 lib/drmtest.c | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 37cabd58..9fcbbcc9 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -160,35 +160,10 @@ static bool has_known_intel_chipset(int fd)
  */
 void gem_quiescent_gpu(int fd)
 {
-   uint32_t bbe = MI_BATCH_BUFFER_END;
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 obj;
-   unsigned ring;
-
igt_terminate_spin_batches();
 
-   memset(, 0, sizeof(obj));
-   obj.handle = gem_create(fd, 4096);
-   gem_write(fd, obj.handle, 0, , sizeof());
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = to_user_pointer();
-   execbuf.buffer_count = 1;
-
-   for (ring = 0; ring < 1<<6; ring++) {
-   execbuf.flags = ring;
-   __gem_execbuf(fd, );
-   }
-
-   if (gem_has_bsd2(fd)) {
-   execbuf.flags = I915_EXEC_BSD | (2 << 13);
-   __gem_execbuf(fd, );
-   }
-
-   gem_sync(fd, obj.handle);
-   gem_close(fd, obj.handle);
-
-   igt_drop_caches_set(fd, DROP_RETIRE | DROP_IDLE | DROP_FREED);
+   igt_drop_caches_set(fd,
+   DROP_ACTIVE | DROP_RETIRE | DROP_IDLE | DROP_FREED);
 }
 
 /**
-- 
2.15.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 drm/uapi: Validate mode flags/type, and deprecate some of them

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/uapi: Validate mode flags/type, and deprecate some of them
URL   : https://patchwork.freedesktop.org/series/33810/
State : failure

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_atomic_transition:
Subgroup plane-all-modeset-transition-fencing:
pass   -> FAIL   (shard-hsw) fdo#102614
Subgroup plane-all-modeset-transition:
pass   -> FAIL   (shard-hsw)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
fail   -> PASS   (shard-hsw)

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

shard-hswtotal:2584 pass:1469 dwarn:3   dfail:1   fail:12  skip:1099 
time:9480s
Blacklisted hosts:
shard-apltotal:2584 pass:1618 dwarn:2   dfail:1   fail:27  skip:936 
time:13051s
shard-kbltotal:2565 pass:1611 dwarn:92  dfail:5   fail:27  skip:829 
time:10598s
shard-snbtotal:2584 pass:1208 dwarn:1   dfail:1   fail:15  skip:1359 
time:7723s

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 06:44:51PM -0200, Paulo Zanoni wrote:
> Em Ter, 2017-11-14 às 22:34 +0200, Ville Syrjälä escreveu:
> > On Tue, Nov 14, 2017 at 06:12:41PM -0200, Paulo Zanoni wrote:
> > > Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > > > From: Ville Syrjälä 
> > > > 
> > > > Apparently there are some machines that put semi-sensible looking
> > > > values
> > > > into the stolen "reserved" base and size, except those values are
> > > > actually
> > > > outside the stolen memory. There is a bit in the register which
> > > > supposedly could tell us whether the reserved area is even
> > > > enabled or
> > > > not. Let's check for that before we go trusting the base and
> > > > size.
> > > 
> > > If this is such a problem since g4x, why didn't we spot it earlier?
> > > It
> > > would be nice if you could explain in the commit message (or at
> > > least
> > > in this email) what are the consequences you're seeing that made
> > > you
> > > realize about this problem. Did something actually explode? I'm
> > > genuinely curious.
> > 
> > CI is getting ping-ping on the SNB shards. Apparently the BIOS leaves
> > some garbage in the the base+size fields of the register, and
> > sometimes
> > that results in the reserved area landing inside stolen (at which
> > point
> > we just reduce the size of stolen and continue), and sometimes it
> > lands
> > somewhere outside (at which point we just disable stolen entirely).
> > Hence the FBC tests sometimes find enough stolen, sometimes not.
> 
> Couldn't it be that we're failing to read the "size of stolen"
> registers instead of the "stolen reserved stuff" regs? All of the
> stolen registers have a history of controversy...

I think stolen itself looks correct. IIRC it was somewhere above
the 3 GiB mark and neatly inside a e820 reserved region.

The reserved region (at least in the logs I looked at) was somewhere
around the 17 MiB mark, right on top of normal RAM according to e820.
No sane BIOS would put it there.

> 
> 
> > 
> > > 
> > > 
> > > Now talking about the patch itself:
> > > 
> > > If we're going to assume random bits instead of a full-zero in
> > > (possibly) uninitialized stuff, shouldn't we first check bit 1,
> > > which
> > > is supposed to tell us if the whole reg is locked or not?
> > 
> > Not sure we can trust the BIOS to always set the lock bit. I suppose
> > it
> > really should, but I don't recall seeing anything in the docs saying
> > that not setting the lock bit would somehow disable the reserved
> > area.
> 
> The way things are worded, it suggests that if the lock bit is zero,
> everything else could be garbage. Bit 0 is only locked after bit 1 is
> locked. It doesn't make sense to me to trust bit 0 without trusting bit
> 1.

The hardware itself will trust bit 0 without bit 1. I think that's all
that really matters.

> 
> So my understanding is that as long as the enable bit is set the
> > hardware will prevent us from accessing the are, regardless of
> > whether
> > the settings have been locked down or not.
> > 
> > This wouldn't be the first lock bit some BIOS versions forget to set
> > BTW.
> 
> But it could be worth checking this now that you have access to the
> machines that have the random stuff...

Yeah. I guess it might be interesting to see the state of the lock bit
as well. I'll see if I can get someone to grab it for us (/me no longer
has any idea how to access those machines...).

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


[Intel-gfx] [PATCH igt v4] lib: Attempt to load the module for a missing device

2017-11-14 Thread Chris Wilson
If we asked to open a particular chipset and we find no matching device,
try again after attempting to load its module. Previously we only did
this for vgem, which is not automatically probed during boot, but if we
want to leave the module unloaded we have to try harder when we need the
device.

v2: DRIVER_* are already masks (and not shifts). Use a common
driver_open for both /dev/dri/cardX and /dev/dri/renderDX.
v3: Beware making local variables accidentally static scoped.
v4: Beware multiple threads trying and failing to open a device

Signed-off-by: Chris Wilson 
---
 lib/drmtest.c | 97 +++
 1 file changed, 57 insertions(+), 40 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index e6bdbc35..37cabd58 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drmtest.h"
 #include "i915_drm.h"
@@ -235,25 +236,19 @@ static int modprobe(const char *driver)
return igt_kmod_load(driver, "");
 }
 
-/**
- * __drm_open_driver:
- * @chipset: OR'd flags for each chipset to search, eg. #DRIVER_INTEL
- *
- * Open the first DRM device we can find, searching up to 16 device nodes
- *
- * Returns:
- * An open DRM fd or -1 on error
- */
-int __drm_open_driver(int chipset)
+static void modprobe_i915(const char *name)
 {
-   if (chipset & DRIVER_VGEM)
-   modprobe("vgem");
+   /* When loading i915, we also want to load snd-hda et al */
+   igt_i915_driver_load(NULL);
+}
 
+static int __open_device(const char *base, int offset, unsigned int chipset)
+{
for (int i = 0; i < 16; i++) {
char name[80];
int fd;
 
-   sprintf(name, "/dev/dri/card%u", i);
+   sprintf(name, "%s%u", base, i + offset);
fd = open(name, O_RDWR);
if (fd == -1)
continue;
@@ -262,16 +257,13 @@ int __drm_open_driver(int chipset)
has_known_intel_chipset(fd))
return fd;
 
-   if (chipset & DRIVER_VC4 &&
-   is_vc4_device(fd))
+   if (chipset & DRIVER_VC4 && is_vc4_device(fd))
return fd;
 
-   if (chipset & DRIVER_VGEM &&
-   is_vgem_device(fd))
+   if (chipset & DRIVER_VGEM && is_vgem_device(fd))
return fd;
 
-   if (chipset & DRIVER_VIRTIO &&
-   is_virtio_device(fd))
+   if (chipset & DRIVER_VIRTIO && is_virtio_device(fd))
return fd;
 
if (chipset & DRIVER_AMDGPU && is_amd_device(fd))
@@ -287,33 +279,58 @@ int __drm_open_driver(int chipset)
return -1;
 }
 
-static int __drm_open_driver_render(int chipset)
+static int __open_driver(const char *base, int offset, unsigned int chipset)
 {
-   char *name;
-   int i, fd;
-
-   for (i = 128; i < (128 + 16); i++) {
-   int ret;
-
-   ret = asprintf(, "/dev/dri/renderD%u", i);
-   igt_assert(ret != -1);
-
-   fd = open(name, O_RDWR);
-   free(name);
+   static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+   static const struct module {
+   unsigned int bit;
+   const char *module;
+   void (*modprobe)(const char *name);
+   } modules[] = {
+   { DRIVER_AMDGPU, "amdgpu" },
+   { DRIVER_INTEL, "i915", modprobe_i915 },
+   { DRIVER_VC4, "vc4" },
+   { DRIVER_VGEM, "vgem" },
+   { DRIVER_VIRTIO, "virtio-gpu" },
+   {}
+   };
+   int fd;
 
-   if (fd == -1)
-   continue;
+   fd = __open_device(base, offset, chipset);
+   if (fd != -1)
+   return fd;
 
-   if (!is_i915_device(fd) || !has_known_intel_chipset(fd)) {
-   close(fd);
-   fd = -1;
-   continue;
+   pthread_mutex_lock();
+   for (const struct module *m = modules; m->module; m++) {
+   if (chipset & m->bit) {
+   if (m->modprobe)
+   m->modprobe(m->module);
+   else
+   modprobe(m->module);
}
-
-   return fd;
}
+   pthread_mutex_unlock();
 
-   return fd;
+   return __open_device(base, offset, chipset);
+}
+
+/**
+ * __drm_open_driver:
+ * @chipset: OR'd flags for each chipset to search, eg. #DRIVER_INTEL
+ *
+ * Open the first DRM device we can find, searching up to 16 device nodes
+ *
+ * Returns:
+ * An open DRM fd or -1 on error
+ */
+int __drm_open_driver(int chipset)
+{
+   return __open_driver("/dev/dri/card", 0, chipset);
+}
+
+static int __drm_open_driver_render(int chipset)
+{
+   return 

[Intel-gfx] [PATCH 4/8] drm/i915: Remove i915.enable_execlists module parameter

2017-11-14 Thread Chris Wilson
Execlists and legacy ringbuffer submission are no longer feature
comparable (execlists now offer greater functionality that should
overcome their performance hit) and obsoletes the unsafe module
parameter, i.e. comparing the two modes of execution is no longer
useful, so remove the debug tool.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
Reviewed-by: Lionel Landwerlin  #i915_perf.c
---
 drivers/gpu/drm/i915/gvt/render.c   |  3 +-
 drivers/gpu/drm/i915/i915_debugfs.c | 70 -
 drivers/gpu/drm/i915/i915_drv.c |  8 +---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/i915_gem.c | 10 ++---
 drivers/gpu/drm/i915/i915_gem_context.c | 10 +
 drivers/gpu/drm/i915/i915_gem_gtt.c |  4 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 --
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/i915_perf.c|  8 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c  |  8 ++--
 drivers/gpu/drm/i915/intel_gvt.c|  5 ---
 drivers/gpu/drm/i915/intel_lrc.c| 31 ---
 drivers/gpu/drm/i915/intel_lrc.h|  4 --
 14 files changed, 20 insertions(+), 149 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/render.c 
b/drivers/gpu/drm/i915/gvt/render.c
index 6d066cf35478..99d66b4f2965 100644
--- a/drivers/gpu/drm/i915/gvt/render.c
+++ b/drivers/gpu/drm/i915/gvt/render.c
@@ -292,8 +292,7 @@ static void switch_mmio_to_vgpu(struct intel_vgpu *vgpu, 
int ring_id)
 * write.
 */
if (mmio->in_context &&
-   ((ctx_ctrl & inhibit_mask) != inhibit_mask) &&
-   i915_modparams.enable_execlists)
+   (ctx_ctrl & inhibit_mask) != inhibit_mask)
continue;
 
if (mmio->mask)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6ba08b0c1c22..f705e4d7d5a5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1989,75 +1989,6 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static void i915_dump_lrc_obj(struct seq_file *m,
- struct i915_gem_context *ctx,
- struct intel_engine_cs *engine)
-{
-   struct i915_vma *vma = ctx->engine[engine->id].state;
-   struct page *page;
-   int j;
-
-   seq_printf(m, "CONTEXT: %s %u\n", engine->name, ctx->hw_id);
-
-   if (!vma) {
-   seq_puts(m, "\tFake context\n");
-   return;
-   }
-
-   if (vma->flags & I915_VMA_GLOBAL_BIND)
-   seq_printf(m, "\tBound in GGTT at 0x%08x\n",
-  i915_ggtt_offset(vma));
-
-   if (i915_gem_object_pin_pages(vma->obj)) {
-   seq_puts(m, "\tFailed to get pages for context object\n\n");
-   return;
-   }
-
-   page = i915_gem_object_get_page(vma->obj, LRC_STATE_PN);
-   if (page) {
-   u32 *reg_state = kmap_atomic(page);
-
-   for (j = 0; j < 0x600 / sizeof(u32) / 4; j += 4) {
-   seq_printf(m,
-  "\t[0x%04x] 0x%08x 0x%08x 0x%08x 0x%08x\n",
-  j * 4,
-  reg_state[j], reg_state[j + 1],
-  reg_state[j + 2], reg_state[j + 3]);
-   }
-   kunmap_atomic(reg_state);
-   }
-
-   i915_gem_object_unpin_pages(vma->obj);
-   seq_putc(m, '\n');
-}
-
-static int i915_dump_lrc(struct seq_file *m, void *unused)
-{
-   struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
-   struct intel_engine_cs *engine;
-   struct i915_gem_context *ctx;
-   enum intel_engine_id id;
-   int ret;
-
-   if (!i915_modparams.enable_execlists) {
-   seq_printf(m, "Logical Ring Contexts are disabled\n");
-   return 0;
-   }
-
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-
-   list_for_each_entry(ctx, _priv->contexts.list, link)
-   for_each_engine(engine, dev_priv, id)
-   i915_dump_lrc_obj(m, ctx, engine);
-
-   mutex_unlock(>struct_mutex);
-
-   return 0;
-}
-
 static const char *swizzle_string(unsigned swizzle)
 {
switch (swizzle) {
@@ -4820,7 +4751,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_vbt", i915_vbt, 0},
{"i915_gem_framebuffer", i915_gem_framebuffer_info, 0},
{"i915_context_status", i915_context_status, 0},
-   {"i915_dump_lrc", i915_dump_lrc, 0},
{"i915_forcewake_domains", i915_forcewake_domains, 0},

[Intel-gfx] [PATCH 6/8] drm/i915: Disable semaphores on Sandybridge

2017-11-14 Thread Chris Wilson
I should have admitted defeat long ago as there has been a rare but
persistent error on Sandybridge where semaphore signaling did not
propagate to the waiter, leading to a GPU hang.

With the work on fence signaling for v4.9, the impact of using CPU driven
signaling was greatly reduced wrt to the latency of GPU semaphores,
though without logical rings support, the benefit of reordering work to
avoid bubbles is not realised (i.e. as it stands fence signaling is just
a slower, more costly version of HW semaphores; but works more
consistently). As a rough indicator of the difference,

with semaphores:
Sequential (3 engines, 1 processes): average 5.470us per cycle [expected 
4.988us]

w/o semaphores:
Sequential (3 engines, 1 processes): average 15.771us per cycle [expected 
4.923us]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54226
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Acked-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 93bfcaccad6c..01e54c93520b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4997,20 +4997,12 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
 
 bool intel_sanitize_semaphores(struct drm_i915_private *dev_priv, int value)
 {
-   if (INTEL_GEN(dev_priv) < 6)
-   return false;
-
-   /* TODO: make semaphores and Execlists play nicely together */
-   if (HAS_EXECLISTS(dev_priv))
+   if (!IS_GEN7(dev_priv))
return false;
 
if (value >= 0)
return value;
 
-   /* Enable semaphores on SNB when IO remapping is off */
-   if (IS_GEN6(dev_priv) && intel_vtd_active())
-   return false;
-
return true;
 }
 
-- 
2.15.0

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


[Intel-gfx] [PATCH 3/8] drm/i915: Automatic i915_switch_context for legacy

2017-11-14 Thread Chris Wilson
During request construction, after pinning the context we know whether
or not we have to emit a context switch. So move this common operation
from every caller into i915_gem_request_alloc() itself.

v2: Always submit the request if we emitted some commands during request
construction, as typically it also involves changes in global state.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_context.c   |  7 +--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c|  8 
 drivers/gpu/drm/i915/i915_gem_request.c   | 18 +-
 drivers/gpu/drm/i915/i915_perf.c  |  3 +--
 drivers/gpu/drm/i915/intel_ringbuffer.c   |  4 
 drivers/gpu/drm/i915/selftests/huge_pages.c   |  4 
 drivers/gpu/drm/i915/selftests/i915_gem_context.c |  4 
 drivers/gpu/drm/i915/selftests/i915_gem_request.c | 10 --
 drivers/gpu/drm/i915/selftests/intel_hangcheck.c  |  4 
 10 files changed, 20 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a7979b74ce21..d885cf0d2943 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5043,7 +5043,7 @@ static int __intel_engines_record_defaults(struct 
drm_i915_private *i915)
goto out_ctx;
}
 
-   err = i915_switch_context(rq);
+   err = 0;
if (engine->init_context)
err = engine->init_context(rq);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 2db040695035..c1efbaf02bf2 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -842,8 +842,7 @@ int i915_switch_context(struct drm_i915_gem_request *req)
struct intel_engine_cs *engine = req->engine;
 
lockdep_assert_held(>i915->drm.struct_mutex);
-   if (i915_modparams.enable_execlists)
-   return 0;
+   GEM_BUG_ON(i915_modparams.enable_execlists);
 
if (!req->ctx->engine[engine->id].state) {
struct i915_gem_context *to = req->ctx;
@@ -899,7 +898,6 @@ int i915_gem_switch_to_kernel_context(struct 
drm_i915_private *dev_priv)
 
for_each_engine(engine, dev_priv, id) {
struct drm_i915_gem_request *req;
-   int ret;
 
if (engine_has_idle_kernel_context(engine))
continue;
@@ -922,10 +920,7 @@ int i915_gem_switch_to_kernel_context(struct 
drm_i915_private *dev_priv)
 GFP_KERNEL);
}
 
-   ret = i915_switch_context(req);
i915_add_request(req);
-   if (ret)
-   return ret;
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 435ed95df144..85c7e8afe26e 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1115,10 +1115,6 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
if (err)
goto err_request;
 
-   err = i915_switch_context(rq);
-   if (err)
-   goto err_request;
-
err = eb->engine->emit_bb_start(rq,
batch->node.start, PAGE_SIZE,
cache->gen > 5 ? 0 : 
I915_DISPATCH_SECURE);
@@ -1965,10 +1961,6 @@ static int eb_submit(struct i915_execbuffer *eb)
if (err)
return err;
 
-   err = i915_switch_context(eb->request);
-   if (err)
-   return err;
-
if (eb->args->flags & I915_EXEC_GEN7_SOL_RESET) {
err = i915_reset_gen7_sol_offsets(eb->request);
if (err)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index e0d6221022a8..445495f9893c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -624,6 +624,10 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
if (ret)
goto err_unpin;
 
+   ret = intel_ring_wait_for_space(ring, MIN_SPACE_FOR_ADD_REQUEST);
+   if (ret)
+   goto err_unreserve;
+
/* Move the oldest request to the slab-cache (if not in use!) */
req = list_first_entry_or_null(>timeline->requests,
   typeof(*req), link);
@@ -703,10 +707,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
req->reserved_space = MIN_SPACE_FOR_ADD_REQUEST;
GEM_BUG_ON(req->reserved_space < engine->emit_breadcrumb_sz);
 
-   ret = engine->request_alloc(req);
-   if (ret)
-   goto err_ctx;
-
/* Record the position of the start of the 

[Intel-gfx] [PATCH 1/8] drm/i915/selftests: Increase size for mock ringbuffer

2017-11-14 Thread Chris Wilson
We don't actually emit any commands into the ringbuffer, so we set it
very small. However, an upcoming change centralises the wait-for-space
into i915_gem_request_alloc() and that imposes a minimum size upon all
ringbuffers (mock or real) of MIN_SPACE_FOR_ADD_REQUEST. Grow the
mock ringbuffer such that we allocate a single page for the struct+buffer,
satisfying the new condition without wasting too much space.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/mock_engine.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c 
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index 0aafa8a105b8..55c0e2c15782 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -124,9 +124,11 @@ static void mock_submit_request(struct 
drm_i915_gem_request *request)
 
 static struct intel_ring *mock_ring(struct intel_engine_cs *engine)
 {
-   const unsigned long sz = roundup_pow_of_two(sizeof(struct intel_ring));
+   const unsigned long sz = PAGE_SIZE / 2;
struct intel_ring *ring;
 
+   BUILD_BUG_ON(MIN_SPACE_FOR_ADD_REQUEST > sz);
+
ring = kzalloc(sizeof(*ring) + sz, GFP_KERNEL);
if (!ring)
return NULL;
-- 
2.15.0

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


[Intel-gfx] [PATCH 2/8] drm/i915: Make request's wait-for-space explicit

2017-11-14 Thread Chris Wilson
At the start of building a request, we would wait for roughly enough
space to fit the average request (to reduce the likelihood of having to
wait and abort partway through request construction). To achieve we
would try to begin a 0-length command packet, this just adds extra
confusion so make the wait-for-space explicit, as in the next patch we
want to move it from the backend to the i915_gem_request_alloc() so it
can ensure that the wait-for-space is the first operation in building a
new request.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c|  8 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 56 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
 3 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 58d050a9a866..ebd9596fe83b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1180,7 +1180,7 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
 {
struct intel_engine_cs *engine = request->engine;
struct intel_context *ce = >ctx->engine[engine->id];
-   u32 *cs;
+   int ret;
 
GEM_BUG_ON(!ce->pin_count);
 
@@ -1190,9 +1190,9 @@ static int execlists_request_alloc(struct 
drm_i915_gem_request *request)
 */
request->reserved_space += EXECLISTS_REQUEST_SIZE;
 
-   cs = intel_ring_begin(request, 0);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
+   ret = intel_ring_wait_for_space(request->ring, request->reserved_space);
+   if (ret)
+   return ret;
 
/* Note that after this point, we have committed to using
 * this request as it is being used to both track the
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3321b801e77d..12e734b29463 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1578,7 +1578,7 @@ void intel_legacy_submission_resume(struct 
drm_i915_private *dev_priv)
 
 static int ring_request_alloc(struct drm_i915_gem_request *request)
 {
-   u32 *cs;
+   int ret;
 
GEM_BUG_ON(!request->ctx->engine[request->engine->id].pin_count);
 
@@ -1588,37 +1588,24 @@ static int ring_request_alloc(struct 
drm_i915_gem_request *request)
 */
request->reserved_space += LEGACY_REQUEST_SIZE;
 
-   cs = intel_ring_begin(request, 0);
-   if (IS_ERR(cs))
-   return PTR_ERR(cs);
+   ret = intel_ring_wait_for_space(request->ring, request->reserved_space);
+   if (ret)
+   return ret;
 
request->reserved_space -= LEGACY_REQUEST_SIZE;
return 0;
 }
 
-static noinline int wait_for_space(struct drm_i915_gem_request *req,
-  unsigned int bytes)
+static noinline int wait_for_space(struct intel_ring *ring, unsigned int bytes)
 {
-   struct intel_ring *ring = req->ring;
struct drm_i915_gem_request *target;
long timeout;
 
-   lockdep_assert_held(>i915->drm.struct_mutex);
+   lockdep_assert_held(>vma->vm->i915->drm.struct_mutex);
 
if (intel_ring_update_space(ring) >= bytes)
return 0;
 
-   /*
-* Space is reserved in the ringbuffer for finalising the request,
-* as that cannot be allowed to fail. During request finalisation,
-* reserved_space is set to 0 to stop the overallocation and the
-* assumption is that then we never need to wait (which has the
-* risk of failing with EINTR).
-*
-* See also i915_gem_request_alloc() and i915_add_request().
-*/
-   GEM_BUG_ON(!req->reserved_space);
-
list_for_each_entry(target, >request_list, ring_link) {
/* Would completion of this request free enough space? */
if (bytes <= __intel_ring_space(target->postfix,
@@ -1642,6 +1629,22 @@ static noinline int wait_for_space(struct 
drm_i915_gem_request *req,
return 0;
 }
 
+int intel_ring_wait_for_space(struct intel_ring *ring, unsigned int bytes)
+{
+   GEM_BUG_ON(bytes > ring->effective_size);
+   if (unlikely(bytes > ring->effective_size - ring->emit))
+   bytes += ring->size - ring->emit;
+
+   if (unlikely(bytes > ring->space)) {
+   int ret = wait_for_space(ring, bytes);
+   if (unlikely(ret))
+   return ret;
+   }
+
+   GEM_BUG_ON(ring->space < bytes);
+   return 0;
+}
+
 u32 *intel_ring_begin(struct drm_i915_gem_request *req,
  unsigned int num_dwords)
 {
@@ -1681,7 +1684,20 @@ u32 *intel_ring_begin(struct drm_i915_gem_request *req,
}
 
if (unlikely(total_bytes > ring->space)) {
-   int ret = wait_for_space(req, total_bytes);
+   int ret;
+
+   /*
+* Space is 

[Intel-gfx] [PATCH 5/8] drm/i915: Remove obsolete ringbuffer emission for gen8+

2017-11-14 Thread Chris Wilson
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.

To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring  execlists
exec continuous nops on all rings:   1.491us2.223us
exec sequential nops on each ring:  12.508us   53.682us
single nop + sync:   9.272us   30.291us

vblank_mode=0 glxgears:~11000fps   ~9000fps

Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.

We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):

ring  execlists
exec continuous nops on all rings:   n/a1.921us
exec sequential nops on each ring:   n/a   44.621us
single nop + sync:   n/a   21.953us

vblank_mode=0 glxgears:  n/a  ~18500fps

References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson 
Once-upon-a-time-Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  44 +---
 drivers/gpu/drm/i915/i915_drv.h |   2 -
 drivers/gpu/drm/i915/i915_gem.c |   2 +-
 drivers/gpu/drm/i915/i915_gem_context.c |  47 +---
 drivers/gpu/drm/i915/i915_gpu_error.c   |  36 ---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  12 -
 drivers/gpu/drm/i915/intel_hangcheck.c  |  44 +---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 431 +---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  25 +-
 9 files changed, 94 insertions(+), 549 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f705e4d7d5a5..c2375aaecb9a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3241,44 +3241,12 @@ static int i915_semaphore_status(struct seq_file *m, 
void *unused)
return ret;
intel_runtime_pm_get(dev_priv);
 
-   if (IS_BROADWELL(dev_priv)) {
-   struct page *page;
-   uint64_t *seqno;
-
-   page = i915_gem_object_get_page(dev_priv->semaphore->obj, 0);
-
-   seqno = (uint64_t *)kmap_atomic(page);
-   for_each_engine(engine, dev_priv, id) {
-   uint64_t offset;
-
-   seq_printf(m, "%s\n", engine->name);
-
-   seq_puts(m, "  Last signal:");
-   for (j = 0; j < num_rings; j++) {
-   offset = id * I915_NUM_ENGINES + j;
-   seq_printf(m, "0x%08llx (0x%02llx) ",
-  seqno[offset], offset * 8);
-   }
-   seq_putc(m, '\n');
-
-   seq_puts(m, "  Last wait:  ");
-   for (j = 0; j < num_rings; j++) {
-   offset = id + (j * I915_NUM_ENGINES);
-   seq_printf(m, "0x%08llx (0x%02llx) ",
-  seqno[offset], offset * 8);
-   }
-   seq_putc(m, '\n');
-
-   }
-   kunmap_atomic(seqno);
-   } else {
-   seq_puts(m, "  Last signal:");
-   for_each_engine(engine, dev_priv, id)
-   for (j = 0; j < num_rings; j++)
-   seq_printf(m, "0x%08x\n",
-  
I915_READ(engine->semaphore.mbox.signal[j]));
-   seq_putc(m, '\n');
-   }
+   seq_puts(m, "  Last signal:");
+   for_each_engine(engine, dev_priv, id)
+   for (j = 0; j < num_rings; j++)
+   seq_printf(m, "0x%08x\n",
+  I915_READ(engine->semaphore.mbox.signal[j]));
+   seq_putc(m, '\n');
 
intel_runtime_pm_put(dev_priv);
mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 909cd53fa8c4..4172b67a3db0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -942,7 +942,6 @@ struct i915_gpu_state {
u64 fence[I915_MAX_NUM_FENCES];
struct intel_overlay_error_state *overlay;
struct intel_display_error_state *display;
-   struct drm_i915_error_object *semaphore;
 
struct drm_i915_error_engine {
int engine_id;
@@ -2291,7 +2290,6 @@ struct 

[Intel-gfx] [PATCH 8/8] drm/i915: Remove i915.semaphores modparam

2017-11-14 Thread Chris Wilson
Having disabled the broken semaphores on Sandybridge, there is no need
for a modparam any more, so remove it in favour of a simple
HAS_LEGACY_SEMAPHORES() guard.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.c |  7 +--
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/i915_gem.c | 11 ---
 drivers/gpu/drm/i915/i915_gem_context.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  4 ++--
 8 files changed, 7 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index abf1073bee88..2b97ff9a0e4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -321,7 +321,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = USES_PPGTT(dev_priv);
break;
case I915_PARAM_HAS_SEMAPHORES:
-   value = i915_modparams.semaphores;
+   value = HAS_LEGACY_SEMAPHORES(dev_priv);
break;
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
@@ -1061,11 +1061,6 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
i915_modparams.enable_ppgtt);
DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt);
 
-   i915_modparams.semaphores =
-   intel_sanitize_semaphores(dev_priv, i915_modparams.semaphores);
-   DRM_DEBUG_DRIVER("use GPU semaphores? %s\n",
-yesno(i915_modparams.semaphores));
-
intel_uc_sanitize_options(dev_priv);
 
intel_gvt_sanitize_options(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4172b67a3db0..3796dfc9358d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3140,6 +3140,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_BLT(dev_priv)  HAS_ENGINE(dev_priv, BCS)
 #define HAS_VEBOX(dev_priv)HAS_ENGINE(dev_priv, VECS)
 
+#define HAS_LEGACY_SEMAPHORES(dev_priv) IS_GEN7(dev_priv)
+
 #define HAS_LLC(dev_priv)  ((dev_priv)->info.has_llc)
 #define HAS_SNOOP(dev_priv)((dev_priv)->info.has_snoop)
 #define HAS_EDRAM(dev_priv)(!!((dev_priv)->edram_cap & EDRAM_ENABLED))
@@ -3303,8 +3305,6 @@ intel_ggtt_update_needs_vtd_wa(struct drm_i915_private 
*dev_priv)
 int intel_sanitize_enable_ppgtt(struct drm_i915_private *dev_priv,
int enable_ppgtt);
 
-bool intel_sanitize_semaphores(struct drm_i915_private *dev_priv, int value);
-
 /* i915_drv.c */
 void __printf(3, 4)
 __i915_printk(struct drm_i915_private *dev_priv, const char *level,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01e54c93520b..aaf9a05b757e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4995,17 +4995,6 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
return ret;
 }
 
-bool intel_sanitize_semaphores(struct drm_i915_private *dev_priv, int value)
-{
-   if (!IS_GEN7(dev_priv))
-   return false;
-
-   if (value >= 0)
-   return value;
-
-   return true;
-}
-
 static int __intel_engines_record_defaults(struct drm_i915_private *i915)
 {
struct i915_gem_context *ctx;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 0704d9af261b..6ca56e482d79 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -574,7 +574,7 @@ mi_set_context(struct drm_i915_gem_request *req, u32 flags)
enum intel_engine_id id;
const int num_rings =
/* Use an extended w/a on gen7 if signalling from other rings */
-   (i915_modparams.semaphores && IS_GEN7(dev_priv)) ?
+   (HAS_LEGACY_SEMAPHORES(dev_priv) && IS_GEN7(dev_priv)) ?
INTEL_INFO(dev_priv)->num_rings - 1 :
0;
int len;
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index d61c1787c164..3328147b4863 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,10 +46,6 @@ i915_param_named_unsafe(panel_ignore_lid, int, 0600,
"Override lid status (0=autodetect, 1=autodetect disabled [default], "
"-1=force lid closed, -2=force lid open)");
 
-i915_param_named_unsafe(semaphores, int, 0400,
-   "Use semaphores for inter-ring sync "
-   "(default: -1 (use per-chip defaults))");
-
 i915_param_named_unsafe(enable_rc6, int, 0400,
"Enable power-saving render 

[Intel-gfx] [PATCH 7/8] drm/i915: Move debugfs/i915_semaphore_status to i915_engine_info

2017-11-14 Thread Chris Wilson
As the semaphores is just part of the engine, include it with the
general pretty printer universally used for debugging.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 32 
 drivers/gpu/drm/i915/intel_engine_cs.c |  9 +
 2 files changed, 9 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c2375aaecb9a..7637cec50049 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3222,37 +3222,6 @@ static int i915_shrinker_info(struct seq_file *m, void 
*unused)
return 0;
 }
 
-static int i915_semaphore_status(struct seq_file *m, void *unused)
-{
-   struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
-   struct intel_engine_cs *engine;
-   int num_rings = INTEL_INFO(dev_priv)->num_rings;
-   enum intel_engine_id id;
-   int j, ret;
-
-   if (!i915_modparams.semaphores) {
-   seq_puts(m, "Semaphores are disabled\n");
-   return 0;
-   }
-
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
-   intel_runtime_pm_get(dev_priv);
-
-   seq_puts(m, "  Last signal:");
-   for_each_engine(engine, dev_priv, id)
-   for (j = 0; j < num_rings; j++)
-   seq_printf(m, "0x%08x\n",
-  I915_READ(engine->semaphore.mbox.signal[j]));
-   seq_putc(m, '\n');
-
-   intel_runtime_pm_put(dev_priv);
-   mutex_unlock(>struct_mutex);
-   return 0;
-}
-
 static int i915_shared_dplls_info(struct seq_file *m, void *unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4732,7 +4701,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_display_info", i915_display_info, 0},
{"i915_engine_info", i915_engine_info, 0},
{"i915_shrinker_info", i915_shrinker_info, 0},
-   {"i915_semaphore_status", i915_semaphore_status, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
{"i915_wa_registers", i915_wa_registers, 0},
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index db44122c1118..c34e52d44f76 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1715,6 +1715,15 @@ void intel_engine_dump(struct intel_engine_cs *engine, 
struct drm_printer *m)
   I915_READ(RING_MI_MODE(engine->mmio_base)),
   I915_READ(RING_MI_MODE(engine->mmio_base)) & 
(MODE_IDLE) ? " [idle]" : "");
}
+   if (i915_modparams.semaphores) {
+   drm_printf(m, "\tSYNC_0: 0x%08x\n",
+  I915_READ(RING_SYNC_0(engine->mmio_base)));
+   drm_printf(m, "\tSYNC_1: 0x%08x\n",
+  I915_READ(RING_SYNC_1(engine->mmio_base)));
+   if (HAS_VEBOX(dev_priv))
+   drm_printf(m, "\tSYNC_2: 0x%08x\n",
+  I915_READ(RING_SYNC_2(engine->mmio_base)));
+   }
 
rcu_read_unlock();
 
-- 
2.15.0

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


Re: [Intel-gfx] [PATCH 6/7] drm/i915/cnl: Write dco_fraction calculation as spec.

2017-11-14 Thread Rodrigo Vivi
On Tue, Nov 14, 2017 at 08:46:38PM +, Ville Syrjälä wrote:
> On Tue, Nov 14, 2017 at 10:22:27PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 14, 2017 at 11:47:58AM -0800, Rodrigo Vivi wrote:
> > > I confess I never fully understood that previous calculation,
> > > so maybe this is cannot be called a "fix". But let's follow
> > > the math that is written on Spec so we have get more confident
> > > this is what hardware expect.
> > > 
> > > Cc: Mika Kahola 
> > > Cc: Manasi Navare 
> > > Cc: James Ausmus 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > index bd608f7f2399..ee690d2f6e54 100644
> > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > @@ -2190,8 +2190,8 @@ static void cnl_wrpll_params_populate(struct 
> > > skl_wrpll_params *params,
> > >   params->qdiv_mode = (qdiv == 1) ? 0 : 1;
> > >  
> > >   params->dco_integer = div_u64(dco_freq, ref_freq);
> > > - params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
> > > (uint64_t)ref_freq) -
> > > - ((uint64_t)params->dco_integer<<15)) * 
> > > 0x8000, 0x8000);
> > > + params->dco_fraction = (DIV_ROUND_UP_ULL(dco_freq, ref_freq) -
> > > + params->dco_integer) * (1 << 15);
> > 
> > Is dco_freq in khz here? Or hz?
> > 
> > If khz, the following should work... I think:
> > 

> > unsigned int dco = div_u64((u64)dco_freq << 15, ref_freq * 1000);
> 
> Actually w/o the *1000 I suppose, for khz.

On python it works apparently:
* (7998750 << 15)/24000
10920960 #"dco"
* ((7998750 << 15)/24000)>>15
333 #int
* ((7998750 << 15)/24000)&0x7
435200 #frac

while on our code we get
dco = 4584
so int = 0
and frac = 4584...

div_u64 not working in float?

also this shows me that while this python gives us the frac 435200
my current code that follows spec gives frac 32768
and previous code was giving frac 9216

:/

more thoughts?

> 
> > dco_int = dco >> 15;
> > dco_frac = dco & 0x7fff;
> > 
> > >  }
> > >  
> > >  static bool
> > > -- 
> > > 2.13.6
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [CI v6 05/15] drm/i915/guc: Rename intel_guc_loader.c to intel_guc_fw.c

2017-11-14 Thread Ville Syrjälä
On Mon, Oct 16, 2017 at 02:47:14PM +, Michal Wajdeczko wrote:
> Remaining functions in intel_guc_loader.c were focused around
> GuC firmware. Rename them to match object-verb pattern and
> rename file itself.

Error: Cannot open file ../drivers/gpu/drm/i915/intel_guc_loader.c  
   

in trying to build docs.


-- 
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: failure for series starting with [v3] lib: Attempt to load the module for a missing device (rev3)

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [v3] lib: Attempt to load the module for a missing 
device (rev3)
URL   : https://patchwork.freedesktop.org/series/33774/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
f370d5903689f37620e006f004a91d6bdeac7c16 lib/i915: Query semaphore status using 
GETPARAM

with latest DRM-Tip kernel build CI_DRM_3345
c46476e24d64 drm-tip: 2017y-11m-14d-17h-03m-32s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test gem_ctx_basic:
pass   -> FAIL   (fi-bdw-gvtdvm)
Test gem_sync:
Subgroup basic-store-all:
pass   -> FAIL   (fi-ivb-3520m) fdo#17

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:264  dwarn:0   dfail:0   fail:1   skip:24  
time:447s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:389s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:274s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:500s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:490s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:268s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:440s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:259  dwarn:0   dfail:0   fail:1   skip:29  
time:478s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:472s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:537s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:569s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:553s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:461s
fi-snb-2520m total:246  pass:212  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:431s
Blacklisted hosts:
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:532s
fi-cnl-y total:289  pass:261  dwarn:0   dfail:0   fail:1   skip:27  
time:551s
fi-glk-dsi   total:289  pass:154  dwarn:0   dfail:10  fail:4   skip:121 
time:406s

== Logs ==

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


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use ELK stolen memory reserved detection for ILK

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 06:59:21PM -0200, Paulo Zanoni wrote:
> Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > From: Ville Syrjälä 
> > 
> > While I have no solid proof that ILK follows the ELK path when it
> > comes to the stolen memory reserved area, there are some hints that
> > it might be the case. Unfortunately my ILK doesn't have this enabled,
> > and no way to enable it via the BIOS it seems.
> > 
> > So let's have ILK use the ELK code path, and let's toss in a WARN
> > into the code to see if we catch anyone with an ILK that has this
> > enabled to further analyze the situation.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 18 +++---
> >  1 file changed, 11 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 4f9377b5f4ae..1877ae9a1d9b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -300,6 +300,12 @@ static void g4x_get_stolen_reserved(struct
> > drm_i915_private *dev_priv,
> >     return;
> >     }
> >  
> > +   /*
> > +    * Whether ILK really reuses the ELK register for this is
> > unclear.
> > +    * Let's see if we catch anyone with this supposedly enabled
> > on ILK.
> > +    */
> > +   WARN(IS_GEN5(dev_priv), "ILK stolen reserved found?
> > 0x%08x\n", reg_val);
> 
> Since we're going to introduce an unconditional WARN, we may as well
> print the value of GEN6_STOLEN_RESERVED, just in case?

I ruled out the SNB and CTG registers already based on the results on
my ILK. The SNB register doesn't exist at all (gives all 1s) which
makes sense since that entire range of registers seems to have been
introduced with SNB. And the value in the CTG register didn't make
any sense for this. So the ELK register is the only viable candidate
really.

> 
> Also, this will probably scare a lot of users. Maybe minimizing it to
> DRM_ERROR would help. We could also consider expanding the message a
> little bit more and explain that it's there for debugging purposes and
> should be reported back to us?

If it looks too bening people might not bother reporting it ;)

While it is a little nasty to do it this way, I don't really have any
better ideas. Fortunately we can always kill it with cc:stable if/when
we get a report, so it should die off reasonably quickly.

And I guess it might also be the case that no ILK uses this anywhere.
On the ELK here a BIOS update seems to have locked this down entirely
and I can no longer test the modes where it was reserving stolen
for this :(

> 
> I'll let the Maintainers make the decision on whether it's fine to add
> a WARN like that. Please ping them.
> 
> Anyway, just like you, I don't have the documents to back up the claims
> of the patch, so giving a R-B tag is quite hard.
> 
> Acked-by: Paulo Zanoni 

Much appereciated.

> 
> 
> 
> 
> > +
> >     *base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) << 16;
> >  
> >     WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) < *base);
> > @@ -466,14 +472,12 @@ int i915_gem_init_stolen(struct
> > drm_i915_private *dev_priv)
> >     case 3:
> >     break;
> >     case 4:
> > -   if (IS_G4X(dev_priv))
> > -   g4x_get_stolen_reserved(dev_priv,
> > -   _base,
> > _size);
> > -   break;
> > +   if (!IS_G4X(dev_priv))
> > +   break;
> > +   /* fall through */
> >     case 5:
> > -   /* Assume the gen6 maximum for the older platforms.
> > */
> > -   reserved_size = 1024 * 1024;
> > -   reserved_base = stolen_top - reserved_size;
> > +   g4x_get_stolen_reserved(dev_priv,
> > +   _base,
> > _size);
> >     break;
> >     case 6:
> >     gen6_get_stolen_reserved(dev_priv,

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


Re: [Intel-gfx] [PATCH 3/7] drm/i915/cnl: Fix, simplify and unify wrpll variable sizes.

2017-11-14 Thread Manasi Navare
On Tue, Nov 14, 2017 at 11:47:55AM -0800, Rodrigo Vivi wrote:
> - 64 bits is not needed for afe_clock now we don't convert
>   that to Hz.
> - 16 bits is not enough for all dco stuff.
> - unsigned is not relevant/needed for all divisors values.
> 

Yup great catch, DCO stuff needs 3 bytes so we need to define it as
u32.

Reviewed-by: Manasi Navare  Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: James Ausmus 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 30 --
>  1 file changed, 12 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index db7afd314462..fba969cbda37 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2110,10 +2110,8 @@ static bool cnl_ddi_pll_get_hw_state(struct 
> drm_i915_private *dev_priv,
>   return ret;
>  }
>  
> -static void cnl_wrpll_get_multipliers(unsigned int bestdiv,
> -   unsigned int *pdiv,
> -   unsigned int *qdiv,
> -   unsigned int *kdiv)
> +static void cnl_wrpll_get_multipliers(int bestdiv, int *pdiv,
> +   int *qdiv, int *kdiv)
>  {
>   /* even dividers */
>   if (bestdiv % 2 == 0) {
> @@ -2151,9 +2149,9 @@ static void cnl_wrpll_get_multipliers(unsigned int 
> bestdiv,
>   }
>  }
>  
> -static void cnl_wrpll_params_populate(struct skl_wrpll_params *params, 
> uint32_t dco_freq,
> -   uint32_t ref_freq, uint32_t pdiv, 
> uint32_t qdiv,
> -   uint32_t kdiv)
> +static void cnl_wrpll_params_populate(struct skl_wrpll_params *params,
> +   u32 dco_freq, u32 ref_freq,
> +   int pdiv, int qdiv, int kdiv)
>  {
>   switch (kdiv) {
>   case 1:
> @@ -2202,23 +2200,19 @@ cnl_ddi_calculate_wrpll(int clock,
>   struct drm_i915_private *dev_priv,
>   struct skl_wrpll_params *wrpll_params)
>  {
> - uint64_t afe_clock = clock * 5;
> - unsigned int dco_min = 7998 * KHz(1);
> - unsigned int dco_max = 1 * KHz(1);
> - unsigned int dco_mid = (dco_min + dco_max) / 2;
> -
> + u32 afe_clock = clock * 5;
> + u32 dco_min = 7998 * KHz(1);
> + u32 dco_max = 1 * KHz(1);
> + u32 dco_mid = (dco_min + dco_max) / 2;
>   static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
>18, 20, 24, 28, 30, 32,  36,  40,
>42, 44, 48, 50, 52, 54,  56,  60,
>64, 66, 68, 70, 72, 76,  78,  80,
>84, 88, 90, 92, 96, 98, 100, 102,
> 3,  5,  7,  9, 15, 21 };
> - unsigned int d, dco;
> - unsigned int dco_centrality = 0;
> - unsigned int best_dco_centrality = 99;
> - unsigned int best_div = 0;
> - unsigned int best_dco = 0;
> - unsigned int pdiv = 0, qdiv = 0, kdiv = 0;
> + u32 dco, best_dco = 0, dco_centrality = 0;
> + u32 best_dco_centrality = 99;
> + int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
>  
>   for (d = 0; d < ARRAY_SIZE(dividers); d++) {
>   dco = afe_clock * dividers[d];
> -- 
> 2.13.6
> 
___
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/kms_rotation_crc: Add RGB565 90 degree test for gen>9 (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: igt/kms_rotation_crc: Add RGB565 90 degree test for gen>9 (rev2)
URL   : https://patchwork.freedesktop.org/series/33132/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
f370d5903689f37620e006f004a91d6bdeac7c16 lib/i915: Query semaphore status using 
GETPARAM

with latest DRM-Tip kernel build CI_DRM_3345
c46476e24d64 drm-tip: 2017y-11m-14d-17h-03m-32s UTC integration manifest

Testlist changes:
+igt@kms_rotation_crc@primary-rotation-90-y-tiled-16bpp

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:384s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:551s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:274s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:492s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:261s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:439s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:530s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:567s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:518s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:462s
fi-snb-2520m total:246  pass:212  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:432s
Blacklisted hosts:
fi-cfl-s total:289  pass:243  dwarn:14  dfail:0   fail:0   skip:32  
time:555s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:554s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:504s

== Logs ==

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


Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldocs for intel_audio.c

2017-11-14 Thread Pandiyan, Dhinakaran



On Tue, 2017-11-14 at 21:11 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Fix copy/paste fail in kerneldocs for intel_audio_codec_disable().
> 
> Cc: Daniel Vetter 

Reviewed-by: Dhinakaran Pandiyan 

> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_audio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 4705194b1992..f1502a0188eb 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -655,8 +655,8 @@ void intel_audio_codec_enable(struct intel_encoder 
> *encoder,
>  /**
>   * intel_audio_codec_disable - Disable the audio codec for HD audio
>   * @encoder: encoder on which to disable audio
> - * @crtc_state: pointer to the old crtc state.
> - * @conn_state: pointer to the old connector state.
> + * @old_crtc_state: pointer to the old crtc state.
> + * @old_conn_state: pointer to the old connector state.
>   *
>   * The disable sequences must be performed before disabling the transcoder or
>   * port.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use ELK stolen memory reserved detection for ILK

2017-11-14 Thread Paulo Zanoni
Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> From: Ville Syrjälä 
> 
> While I have no solid proof that ILK follows the ELK path when it
> comes to the stolen memory reserved area, there are some hints that
> it might be the case. Unfortunately my ILK doesn't have this enabled,
> and no way to enable it via the BIOS it seems.
> 
> So let's have ILK use the ELK code path, and let's toss in a WARN
> into the code to see if we catch anyone with an ILK that has this
> enabled to further analyze the situation.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 4f9377b5f4ae..1877ae9a1d9b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -300,6 +300,12 @@ static void g4x_get_stolen_reserved(struct
> drm_i915_private *dev_priv,
>   return;
>   }
>  
> + /*
> +  * Whether ILK really reuses the ELK register for this is
> unclear.
> +  * Let's see if we catch anyone with this supposedly enabled
> on ILK.
> +  */
> + WARN(IS_GEN5(dev_priv), "ILK stolen reserved found?
> 0x%08x\n", reg_val);

Since we're going to introduce an unconditional WARN, we may as well
print the value of GEN6_STOLEN_RESERVED, just in case?

Also, this will probably scare a lot of users. Maybe minimizing it to
DRM_ERROR would help. We could also consider expanding the message a
little bit more and explain that it's there for debugging purposes and
should be reported back to us?

I'll let the Maintainers make the decision on whether it's fine to add
a WARN like that. Please ping them.

Anyway, just like you, I don't have the documents to back up the claims
of the patch, so giving a R-B tag is quite hard.

Acked-by: Paulo Zanoni 




> +
>   *base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) << 16;
>  
>   WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) < *base);
> @@ -466,14 +472,12 @@ int i915_gem_init_stolen(struct
> drm_i915_private *dev_priv)
>   case 3:
>   break;
>   case 4:
> - if (IS_G4X(dev_priv))
> - g4x_get_stolen_reserved(dev_priv,
> - _base,
> _size);
> - break;
> + if (!IS_G4X(dev_priv))
> + break;
> + /* fall through */
>   case 5:
> - /* Assume the gen6 maximum for the older platforms.
> */
> - reserved_size = 1024 * 1024;
> - reserved_base = stolen_top - reserved_size;
> + g4x_get_stolen_reserved(dev_priv,
> + _base,
> _size);
>   break;
>   case 6:
>   gen6_get_stolen_reserved(dev_priv,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/7] drm/i915/cnl: Remove useless conversion.

2017-11-14 Thread Manasi Navare
On Tue, Nov 14, 2017 at 11:47:54AM -0800, Rodrigo Vivi wrote:
> No functional change. Just starting the wrpll fixes
> with a clean-up to make units a bit more clear.
> 
> Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: James Ausmus 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 61c684ac47af..db7afd314462 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2198,11 +2198,11 @@ static void cnl_wrpll_params_populate(struct 
> skl_wrpll_params *params, uint32_t
>  }
>  
>  static bool
> -cnl_ddi_calculate_wrpll(int clock /* in Hz */,

Now the clock sent is already in KHz, should we have that in the comment either
in the argument or afe_clock calculation? 
Apart from this nitpick, looks good.

Reviewed-by: Manasi Navare 
 
> +cnl_ddi_calculate_wrpll(int clock,
>   struct drm_i915_private *dev_priv,
>   struct skl_wrpll_params *wrpll_params)
>  {
> - uint64_t afe_clock = clock * 5 / KHz(1); /* clocks in kHz */
> + uint64_t afe_clock = clock * 5;
>   unsigned int dco_min = 7998 * KHz(1);
>   unsigned int dco_max = 1 * KHz(1);
>   unsigned int dco_mid = (dco_min + dco_max) / 2;
> @@ -2255,7 +2255,7 @@ static bool cnl_ddi_hdmi_pll_dividers(struct intel_crtc 
> *crtc,
>  
>   cfgcr0 = DPLL_CFGCR0_HDMI_MODE;
>  
> - if (!cnl_ddi_calculate_wrpll(clock * 1000, dev_priv, _params))
> + if (!cnl_ddi_calculate_wrpll(clock, dev_priv, _params))
>   return false;
>  
>   cfgcr0 |= DPLL_CFGCR0_DCO_FRACTION(wrpll_params.dco_fraction) |
> -- 
> 2.13.6
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for WRPLL fixes for HDMI 2.0 on Cannonlake.

2017-11-14 Thread Patchwork
== Series Details ==

Series: WRPLL fixes for HDMI 2.0 on Cannonlake.
URL   : https://patchwork.freedesktop.org/series/33823/
State : failure

== Summary ==

Series 33823v1 WRPLL fixes for HDMI 2.0 on Cannonlake.
https://patchwork.freedesktop.org/api/1.0/series/33823/revisions/1/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-blb-e6850)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-snb-2520m)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:222  dwarn:1   dfail:0   fail:1   skip:65  
time:377s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:544s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:497s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:432s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:435s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:425s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:529s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:568s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:425s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:522s
fi-cnl-y total:289  pass:261  dwarn:0   dfail:0   fail:1   skip:27  
time:571s
fi-glk-dsi   total:289  pass:257  dwarn:0   dfail:0   fail:2   skip:30  
time:510s

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
6dfe31a79aca drm/i915/cnl: Extend HDMI 2.0 support to CNL.
4f1e96fbf6cc drm/i915/cnl: Write dco_fraction calculation as spec.
67cfd7f598c5 drm/i915/cnl: Don't blindly replace qdiv.
5ebe12a24b29 drm/i915/cnl: Fix wrpll math for higher freqs.
303af54b1923 drm/i915/cnl: Fix, simplify and unify wrpll variable sizes.
03436c82428a drm/i915/cnl: Remove useless conversion.
0e0c097b31c7 drm/i915/cnl: Remove spurious central_freq.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7129/
___
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: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM
URL   : https://patchwork.freedesktop.org/series/33804/
State : success

== Summary ==

shard-hswtotal:2584 pass:1472 dwarn:3   dfail:1   fail:9   skip:1099 
time:9499s
Blacklisted hosts:
shard-apltotal:2522 pass:1577 dwarn:1   dfail:0   fail:22  skip:920 
time:12240s
shard-kbltotal:2534 pass:1680 dwarn:8   dfail:3   fail:25  skip:816 
time:10253s
shard-snbtotal:2584 pass:1203 dwarn:3   dfail:1   fail:12  skip:1365 
time:7820s

== Logs ==

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


Re: [Intel-gfx] [PATCH 6/7] drm/i915/cnl: Write dco_fraction calculation as spec.

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 10:22:27PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 14, 2017 at 11:47:58AM -0800, Rodrigo Vivi wrote:
> > I confess I never fully understood that previous calculation,
> > so maybe this is cannot be called a "fix". But let's follow
> > the math that is written on Spec so we have get more confident
> > this is what hardware expect.
> > 
> > Cc: Mika Kahola 
> > Cc: Manasi Navare 
> > Cc: James Ausmus 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index bd608f7f2399..ee690d2f6e54 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2190,8 +2190,8 @@ static void cnl_wrpll_params_populate(struct 
> > skl_wrpll_params *params,
> > params->qdiv_mode = (qdiv == 1) ? 0 : 1;
> >  
> > params->dco_integer = div_u64(dco_freq, ref_freq);
> > -   params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
> > (uint64_t)ref_freq) -
> > -   ((uint64_t)params->dco_integer<<15)) * 
> > 0x8000, 0x8000);
> > +   params->dco_fraction = (DIV_ROUND_UP_ULL(dco_freq, ref_freq) -
> > +   params->dco_integer) * (1 << 15);
> 
> Is dco_freq in khz here? Or hz?
> 
> If khz, the following should work... I think:
> 
> unsigned int dco = div_u64((u64)dco_freq << 15, ref_freq * 1000);

Actually w/o the *1000 I suppose, for khz.

> dco_int = dco >> 15;
> dco_frac = dco & 0x7fff;
> 
> >  }
> >  
> >  static bool
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Paulo Zanoni
Em Ter, 2017-11-14 às 22:34 +0200, Ville Syrjälä escreveu:
> On Tue, Nov 14, 2017 at 06:12:41PM -0200, Paulo Zanoni wrote:
> > Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > > From: Ville Syrjälä 
> > > 
> > > Apparently there are some machines that put semi-sensible looking
> > > values
> > > into the stolen "reserved" base and size, except those values are
> > > actually
> > > outside the stolen memory. There is a bit in the register which
> > > supposedly could tell us whether the reserved area is even
> > > enabled or
> > > not. Let's check for that before we go trusting the base and
> > > size.
> > 
> > If this is such a problem since g4x, why didn't we spot it earlier?
> > It
> > would be nice if you could explain in the commit message (or at
> > least
> > in this email) what are the consequences you're seeing that made
> > you
> > realize about this problem. Did something actually explode? I'm
> > genuinely curious.
> 
> CI is getting ping-ping on the SNB shards. Apparently the BIOS leaves
> some garbage in the the base+size fields of the register, and
> sometimes
> that results in the reserved area landing inside stolen (at which
> point
> we just reduce the size of stolen and continue), and sometimes it
> lands
> somewhere outside (at which point we just disable stolen entirely).
> Hence the FBC tests sometimes find enough stolen, sometimes not.

Couldn't it be that we're failing to read the "size of stolen"
registers instead of the "stolen reserved stuff" regs? All of the
stolen registers have a history of controversy...


> 
> > 
> > 
> > Now talking about the patch itself:
> > 
> > If we're going to assume random bits instead of a full-zero in
> > (possibly) uninitialized stuff, shouldn't we first check bit 1,
> > which
> > is supposed to tell us if the whole reg is locked or not?
> 
> Not sure we can trust the BIOS to always set the lock bit. I suppose
> it
> really should, but I don't recall seeing anything in the docs saying
> that not setting the lock bit would somehow disable the reserved
> area.

The way things are worded, it suggests that if the lock bit is zero,
everything else could be garbage. Bit 0 is only locked after bit 1 is
locked. It doesn't make sense to me to trust bit 0 without trusting bit
1.

So my understanding is that as long as the enable bit is set the
> hardware will prevent us from accessing the are, regardless of
> whether
> the settings have been locked down or not.
> 
> This wouldn't be the first lock bit some BIOS versions forget to set
> BTW.

But it could be worth checking this now that you have access to the
machines that have the random stuff...


> 
> > 
> > if ((reg_val & 0x3) != 0x3)
> > ignore stolen reserved stuff;
> > 
> > Anyway, this patch without my suggestions is probably better than
> > the
> > current situation so:
> > Reviewed-by: Paulo Zanoni 
> > but please feel investigate the bit 1 thing and CC me on v2 or a
> > possible follow-up patch with conclusions.
> > 
> > 
> > > Cc: Tomi Sarvela 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 30
> > > ++
> > >  drivers/gpu/drm/i915/i915_reg.h|  2 ++
> > >  2 files changed, 32 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > index 03e7abc7e043..44a5dbc8c23b 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > @@ -294,6 +294,12 @@ static void g4x_get_stolen_reserved(struct
> > > drm_i915_private *dev_priv,
> > >    ELK_STOLEN_RESERVED);
> > >   dma_addr_t stolen_top = dev_priv->mm.stolen_base + ggtt-
> > > > stolen_size;
> > > 
> > >  
> > > + if ((reg_val & G4X_STOLEN_RESERVED_ENABLE) == 0) {
> > > + *base = 0;
> > > + *size = 0;
> > > + return;
> > > + }
> > > +
> > >   *base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) <<
> > > 16;
> > >  
> > >   WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) <
> > > *base);
> > > @@ -313,6 +319,12 @@ static void gen6_get_stolen_reserved(struct
> > > drm_i915_private *dev_priv,
> > >  {
> > >   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> > >  
> > > + if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> > > + *base = 0;
> > > + *size = 0;
> > > + return;
> > > + }
> > > +
> > >   *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
> > >  
> > >   switch (reg_val & GEN6_STOLEN_RESERVED_SIZE_MASK) {
> > > @@ -339,6 +351,12 @@ static void gen7_get_stolen_reserved(struct
> > > drm_i915_private *dev_priv,
> > >  {
> > >   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> > >  
> > > + if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> > > + *base = 0;
> > > + *size = 0;
> > > + return;
> > > + }
> 

[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/gem_exec_capture: Exercise readback of userptr (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: igt/gem_exec_capture: Exercise readback of userptr (rev2)
URL   : https://patchwork.freedesktop.org/series/31480/
State : warning

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Subgroup extended-modeset-hang-oldfb-with-reset-render-b:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +2
Test kms_atomic_transition:
Subgroup plane-all-transition-nonblocking-fencing:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_legacy:
Subgroup basic-flip-before-cursor-varying-size:
pass   -> SKIP   (shard-hsw)
Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
pass   -> SKIP   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu:
pass   -> SKIP   (shard-hsw)
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-hsw) fdo#100047

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-hswtotal:2585 pass:1465 dwarn:6   dfail:1   fail:9   skip:1103 
time:9349s

== Logs ==

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


Re: [Intel-gfx] [PATCH 08/10] drm/uapi: Deprecate nonsense kms mode types

2017-11-14 Thread Adam Jackson
On Tue, 2017-11-14 at 20:32 +0200, Ville Syrjala wrote:

> @@ -253,8 +251,11 @@ struct drm_display_mode {
>*  - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
>*
>* Plus a big list of flags which shouldn't be used at all, but are
> -  * still around since these flags are also used in the userspace ABI:
> +  * still around since these flags are also used in the userspace ABI.
> +  * We no longer accept modes with these types though:
>*
> +  *  - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
> +  *unused.

This should suggest _TYPE_DRIVER, I think. The intent with the xfree86
mode type was that "built-in" modes were known quantities of the
hardware, either because the hardware only had one mode or due to
strapping pins or the like. These should be considered "supplied by the
driver" as with EDID-derived modes.

With or without that, patches 2 3 4 and 8 are:

Reviewed-by: Adam Jackson 

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


Re: [Intel-gfx] [PATCH 6/7] drm/i915/cnl: Write dco_fraction calculation as spec.

2017-11-14 Thread Rodrigo Vivi
On Tue, Nov 14, 2017 at 08:22:27PM +, Ville Syrjälä wrote:
> On Tue, Nov 14, 2017 at 11:47:58AM -0800, Rodrigo Vivi wrote:
> > I confess I never fully understood that previous calculation,
> > so maybe this is cannot be called a "fix". But let's follow
> > the math that is written on Spec so we have get more confident
> > this is what hardware expect.
> > 
> > Cc: Mika Kahola 
> > Cc: Manasi Navare 
> > Cc: James Ausmus 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index bd608f7f2399..ee690d2f6e54 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2190,8 +2190,8 @@ static void cnl_wrpll_params_populate(struct 
> > skl_wrpll_params *params,
> > params->qdiv_mode = (qdiv == 1) ? 0 : 1;
> >  
> > params->dco_integer = div_u64(dco_freq, ref_freq);
> > -   params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
> > (uint64_t)ref_freq) -
> > -   ((uint64_t)params->dco_integer<<15)) * 
> > 0x8000, 0x8000);
> > +   params->dco_fraction = (DIV_ROUND_UP_ULL(dco_freq, ref_freq) -
> > +   params->dco_integer) * (1 << 15);
> 
> Is dco_freq in khz here? Or hz?
> 
> If khz, the following should work... I think:

khz

> 
> unsigned int dco = div_u64((u64)dco_freq << 15, ref_freq * 1000);

why to convert ref_freq? isn't this in khz as well already?

> dco_int = dco >> 15;
> dco_frac = dco & 0x7fff;

wow! my first thought was that was more complicated, but eureka,
this should be the right way to go...

Clearly better than spec... like that maximum in the other patch ;)

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Chris Wilson
Quoting Paulo Zanoni (2017-11-14 20:29:49)
> Em Ter, 2017-11-14 às 20:19 +, Chris Wilson escreveu:
> >  Only fbc actually depends on stolen allocation to
> > function, and no one complains if fbc is disabled. (There's a sketch
> > out
> > there that we could use a contiguous allocation for fbc if we run out
> > of
> > stolen.)
> 
> ILK_DPFC_CB_BASE (aka FBC_CFB_BASE these days) needs to be programmed
> as an offset of the base of stolen memory, so you'll need to allocate
> this memory in the region that comes right after stolen, or you'll run
> out of bits to write to the register.
> 
> Also, things such as the "last 8mb bug" of BDW/SKL suggest that maybe
> this wouldn't work.
> 
> Unless, of course, you have some plan to work around this.

Nah, just the stuff I was last looking at (powerctx) were physical.

Being able to disable stolen and recover the memory is still on the
wishlist.
-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 igt/gem_ctx_switch: Do a warmup pass over all contexts (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: igt/gem_ctx_switch: Do a warmup pass over all contexts (rev2)
URL   : https://patchwork.freedesktop.org/series/33515/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-hsw) fdo#102707 +1
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2584 pass:1472 dwarn:3   dfail:1   fail:9   skip:1099 
time:9406s

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/3] drm/i915: Make the report about a bogus stolen reserved area an error

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 06:33:41PM -0200, Paulo Zanoni wrote:
> Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > From: Ville Syrjälä 
> > 
> > Now that we should be properly filtering out the cases when the
> > stolen
> > reserved area is disabled, let's convert the debug message about a
> > misplaced reserved area into an error.
> 
> Worst that could happen is that some unhappy user will notify us that
> we may still be missing something.
> 
> Speaking of that, is CI already able to call our attention to boot
> error messages like this one?

I guess module reload should hit it. Would be nice to have checks for
initial boot errors/warnings too though since there's no guarantee
everything is 100% virgin on module reload.

> 
> Reviewed-by: Paulo Zanoni 
> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 44a5dbc8c23b..4f9377b5f4ae 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -503,9 +503,9 @@ int i915_gem_init_stolen(struct drm_i915_private
> > *dev_priv)
> >     if (reserved_base < dev_priv->mm.stolen_base ||
> >     reserved_base + reserved_size > stolen_top) {
> >     dma_addr_t reserved_top = reserved_base +
> > reserved_size;
> > -   DRM_DEBUG_KMS("Stolen reserved area [%pad - %pad]
> > outside stolen memory [%pad - %pad]\n",
> > -     _base, _top,
> > -     _priv->mm.stolen_base,
> > _top);
> > +   DRM_ERROR("Stolen reserved area [%pad - %pad]
> > outside stolen memory [%pad - %pad]\n",
> > +     _base, _top,
> > +     _priv->mm.stolen_base, _top);
> >     return 0;
> >     }
> >  

-- 
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.IGT: success for dma-buf/fence: Fix lock inversion within dma-fence-array

2017-11-14 Thread Patchwork
== Series Details ==

Series: dma-buf/fence: Fix lock inversion within dma-fence-array
URL   : https://patchwork.freedesktop.org/series/33799/
State : success

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2584 pass:1470 dwarn:4   dfail:1   fail:10  skip:1099 
time:9555s
Blacklisted hosts:
shard-apltotal:2584 pass:1625 dwarn:1   dfail:1   fail:21  skip:936 
time:13488s
shard-kbltotal:2565 pass:1707 dwarn:4   dfail:0   fail:25  skip:828 
time:10541s
shard-snbtotal:2511 pass:1169 dwarn:2   dfail:1   fail:11  skip:1328 
time:7622s

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/7] drm/i915/cnl: Remove spurious central_freq.

2017-11-14 Thread Manasi Navare
Verified this from the Bspec that central frequency should
be left at default at 8400MHz which is value 3 in cfgcr1.central_freq.
Looks good to me.

Reviewed-by: Manasi Navare 

On Tue, Nov 14, 2017 at 11:47:53AM -0800, Rodrigo Vivi wrote:
> "Display software must leave this field at the default value.
> It no longer needs to be configured as part of PLL programming."
> 
> We respect this already and we are setting up the default
> one line below: "DPLL_CFGCR1_CENTRAL_FREQ".
> 
> Also we don't touch anywhere else this central_freq for cnl.
> So let's remove from the final write.
> 
> No functional change. Only a clean-up patch.
> 
> Cc: Manasi Navare 
> Cc: Mika Kahola 
> Cc: James Ausmus 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index be74d4767c8a..61c684ac47af 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2265,7 +2265,6 @@ static bool cnl_ddi_hdmi_pll_dividers(struct intel_crtc 
> *crtc,
>   DPLL_CFGCR1_QDIV_MODE(wrpll_params.qdiv_mode) |
>   DPLL_CFGCR1_KDIV(wrpll_params.kdiv) |
>   DPLL_CFGCR1_PDIV(wrpll_params.pdiv) |
> - wrpll_params.central_freq |
>   DPLL_CFGCR1_CENTRAL_FREQ;
>  
>   memset(_state->dpll_hw_state, 0,
> -- 
> 2.13.6
> 
___
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/2] lib/gt: Mark up engine classes

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] lib/gt: Mark up engine classes
URL   : https://patchwork.freedesktop.org/series/33777/
State : warning

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (shard-hsw) fdo#102707 +1
Test kms_atomic_transition:
Subgroup plane-all-transition-fencing:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-b:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038

shard-hswtotal:2640 pass:1474 dwarn:5   dfail:1   fail:11  skip:1149 
time:9269s

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 06:12:41PM -0200, Paulo Zanoni wrote:
> Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > From: Ville Syrjälä 
> > 
> > Apparently there are some machines that put semi-sensible looking
> > values
> > into the stolen "reserved" base and size, except those values are
> > actually
> > outside the stolen memory. There is a bit in the register which
> > supposedly could tell us whether the reserved area is even enabled or
> > not. Let's check for that before we go trusting the base and size.
> 
> If this is such a problem since g4x, why didn't we spot it earlier? It
> would be nice if you could explain in the commit message (or at least
> in this email) what are the consequences you're seeing that made you
> realize about this problem. Did something actually explode? I'm
> genuinely curious.

CI is getting ping-ping on the SNB shards. Apparently the BIOS leaves
some garbage in the the base+size fields of the register, and sometimes
that results in the reserved area landing inside stolen (at which point
we just reduce the size of stolen and continue), and sometimes it lands
somewhere outside (at which point we just disable stolen entirely).
Hence the FBC tests sometimes find enough stolen, sometimes not.

> 
> 
> Now talking about the patch itself:
> 
> If we're going to assume random bits instead of a full-zero in
> (possibly) uninitialized stuff, shouldn't we first check bit 1, which
> is supposed to tell us if the whole reg is locked or not?

Not sure we can trust the BIOS to always set the lock bit. I suppose it
really should, but I don't recall seeing anything in the docs saying
that not setting the lock bit would somehow disable the reserved area.
So my understanding is that as long as the enable bit is set the
hardware will prevent us from accessing the are, regardless of whether
the settings have been locked down or not.

This wouldn't be the first lock bit some BIOS versions forget to set BTW.

> 
> if ((reg_val & 0x3) != 0x3)
>   ignore stolen reserved stuff;
> 
> Anyway, this patch without my suggestions is probably better than the
> current situation so:
> Reviewed-by: Paulo Zanoni 
> but please feel investigate the bit 1 thing and CC me on v2 or a
> possible follow-up patch with conclusions.
> 
> 
> > Cc: Tomi Sarvela 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 30
> > ++
> >  drivers/gpu/drm/i915/i915_reg.h|  2 ++
> >  2 files changed, 32 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 03e7abc7e043..44a5dbc8c23b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -294,6 +294,12 @@ static void g4x_get_stolen_reserved(struct
> > drm_i915_private *dev_priv,
> >      ELK_STOLEN_RESERVED);
> >     dma_addr_t stolen_top = dev_priv->mm.stolen_base + ggtt-
> > >stolen_size;
> >  
> > +   if ((reg_val & G4X_STOLEN_RESERVED_ENABLE) == 0) {
> > +   *base = 0;
> > +   *size = 0;
> > +   return;
> > +   }
> > +
> >     *base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) << 16;
> >  
> >     WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) < *base);
> > @@ -313,6 +319,12 @@ static void gen6_get_stolen_reserved(struct
> > drm_i915_private *dev_priv,
> >  {
> >     uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> >  
> > +   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> > +   *base = 0;
> > +   *size = 0;
> > +   return;
> > +   }
> > +
> >     *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
> >  
> >     switch (reg_val & GEN6_STOLEN_RESERVED_SIZE_MASK) {
> > @@ -339,6 +351,12 @@ static void gen7_get_stolen_reserved(struct
> > drm_i915_private *dev_priv,
> >  {
> >     uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> >  
> > +   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> > +   *base = 0;
> > +   *size = 0;
> > +   return;
> > +   }
> > +
> >     *base = reg_val & GEN7_STOLEN_RESERVED_ADDR_MASK;
> >  
> >     switch (reg_val & GEN7_STOLEN_RESERVED_SIZE_MASK) {
> > @@ -359,6 +377,12 @@ static void chv_get_stolen_reserved(struct
> > drm_i915_private *dev_priv,
> >  {
> >     uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> >  
> > +   if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> > +   *base = 0;
> > +   *size = 0;
> > +   return;
> > +   }
> > +
> >     *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
> >  
> >     switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
> > @@ -387,6 +411,12 @@ static void bdw_get_stolen_reserved(struct
> > drm_i915_private *dev_priv,
> >     uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
> >     dma_addr_t stolen_top;
> >  
> > +   if 

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Make the report about a bogus stolen reserved area an error

2017-11-14 Thread Paulo Zanoni
Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> From: Ville Syrjälä 
> 
> Now that we should be properly filtering out the cases when the
> stolen
> reserved area is disabled, let's convert the debug message about a
> misplaced reserved area into an error.

Worst that could happen is that some unhappy user will notify us that
we may still be missing something.

Speaking of that, is CI already able to call our attention to boot
error messages like this one?

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 44a5dbc8c23b..4f9377b5f4ae 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -503,9 +503,9 @@ int i915_gem_init_stolen(struct drm_i915_private
> *dev_priv)
>   if (reserved_base < dev_priv->mm.stolen_base ||
>   reserved_base + reserved_size > stolen_top) {
>   dma_addr_t reserved_top = reserved_base +
> reserved_size;
> - DRM_DEBUG_KMS("Stolen reserved area [%pad - %pad]
> outside stolen memory [%pad - %pad]\n",
> -   _base, _top,
> -   _priv->mm.stolen_base,
> _top);
> + DRM_ERROR("Stolen reserved area [%pad - %pad]
> outside stolen memory [%pad - %pad]\n",
> +   _base, _top,
> +   _priv->mm.stolen_base, _top);
>   return 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 tools/error_decode: Print ASCII user buffers (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: tools/error_decode: Print ASCII user buffers (rev2)
URL   : https://patchwork.freedesktop.org/series/33673/
State : warning

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
pass   -> DMESG-WARN (shard-hsw)

fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368

shard-hswtotal:2584 pass:1469 dwarn:5   dfail:1   fail:10  skip:1099 
time:9374s

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Paulo Zanoni
Em Ter, 2017-11-14 às 20:19 +, Chris Wilson escreveu:
> Quoting Paulo Zanoni (2017-11-14 20:12:41)
> > Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > > From: Ville Syrjälä 
> > > 
> > > Apparently there are some machines that put semi-sensible looking
> > > values
> > > into the stolen "reserved" base and size, except those values are
> > > actually
> > > outside the stolen memory. There is a bit in the register which
> > > supposedly could tell us whether the reserved area is even
> > > enabled or
> > > not. Let's check for that before we go trusting the base and
> > > size.
> > 
> > If this is such a problem since g4x, why didn't we spot it earlier?
> > It
> > would be nice if you could explain in the commit message (or at
> > least
> > in this email) what are the consequences you're seeing that made
> > you
> > realize about this problem. Did something actually explode? I'm
> > genuinely curious.
> 
> The consequence is that we disable stolen; the machine keeps on
> working
> quite happily.

Thanks!

>  Only fbc actually depends on stolen allocation to
> function, and no one complains if fbc is disabled. (There's a sketch
> out
> there that we could use a contiguous allocation for fbc if we run out
> of
> stolen.)

ILK_DPFC_CB_BASE (aka FBC_CFB_BASE these days) needs to be programmed
as an offset of the base of stolen memory, so you'll need to allocate
this memory in the region that comes right after stolen, or you'll run
out of bits to write to the register.

Also, things such as the "last 8mb bug" of BDW/SKL suggest that maybe
this wouldn't work.

Unless, of course, you have some plan to work around this.

>  Internal hw functions are oblivious to our qualms about the
> location of stolen and whether some other device is using the same
> physical address for its trampoline.
> -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 lib: Dump /sys/kernel/debug/suspend_stats after suspend failure (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: lib: Dump /sys/kernel/debug/suspend_stats after suspend failure (rev2)
URL   : https://patchwork.freedesktop.org/series/33560/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (shard-hsw) fdo#102707

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

shard-hswtotal:2584 pass:1473 dwarn:2   dfail:1   fail:9   skip:1099 
time:9471s

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Always initialise err

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Always initialise err
URL   : https://patchwork.freedesktop.org/series/33822/
State : success

== Summary ==

Series 33822v1 drm/i915/selftests: Always initialise err
https://patchwork.freedesktop.org/api/1.0/series/33822/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:451s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:536s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:499s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:487s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:427s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:261s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:438s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:475s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:474s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:529s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:569s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:518s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:454s
fi-snb-2520m total:246  pass:212  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:424s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:531s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:486s

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
26ca3ab849d7 drm/i915/selftests: Always initialise err

== Logs ==

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


Re: [Intel-gfx] [PATCH 4/7] drm/i915/cnl: Fix wrpll math for higher freqs.

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 12:09:39PM -0800, Rodrigo Vivi wrote:
> On Tue, Nov 14, 2017 at 08:00:31PM +, Ville Syrjälä wrote:
> > On Tue, Nov 14, 2017 at 11:47:56AM -0800, Rodrigo Vivi wrote:
> > > Spec describe all values in MHz. We handle our
> > > clocks in KHz. This includes the best_dco_centrality that was
> > > forgot in the same unity as spec. Consequently we couldn't
> > > get a good divider for high frequenies. Hence HDMI 2.0 wasn't
> > > working.
> > > 
> > > This patch also replaces the use of "* KHz(1)" with the values
> > > directly on KHz to avoid future confusion.
> > > 
> > > Cc: Shashank Sharma 
> > > Cc: Mika Kahola 
> > > Cc: Manasi Navare 
> > > Cc: James Ausmus 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > index fba969cbda37..53f650f56148 100644
> > > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > > @@ -2201,8 +2201,8 @@ cnl_ddi_calculate_wrpll(int clock,
> > >   struct skl_wrpll_params *wrpll_params)
> > >  {
> > >   u32 afe_clock = clock * 5;
> > > - u32 dco_min = 7998 * KHz(1);
> > > - u32 dco_max = 1 * KHz(1);
> > > + u32 dco_min = 7998000;
> > > + u32 dco_max = 1000;
> > >   u32 dco_mid = (dco_min + dco_max) / 2;
> > >   static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
> > >18, 20, 24, 28, 30, 32,  36,  40,
> > > @@ -2211,7 +2211,7 @@ cnl_ddi_calculate_wrpll(int clock,
> > >84, 88, 90, 92, 96, 98, 100, 102,
> > > 3,  5,  7,  9, 15, 21 };
> > >   u32 dco, best_dco = 0, dco_centrality = 0;
> > > - u32 best_dco_centrality = 99;
> > > + u32 best_dco_centrality = 99000;
> > 
> > UINT_MAX, -1, or ~0 maybe?
> 
> yeap, I considered the max macros, but I didn't want to deviate
> from spec...

Always bothers me to see some kind of 999... decimal max value pulled
out from someone's hat when they obvious thing clearly is just "max
representable value". Feels like someone wasn't thinking 100% when
they wrote the spec :)

Maybe just extend the 9's all the way to the end then? Dunno. I think
I'll just move on from the DDI DPLL code (that apporach has worked
pretty well thus far ;)

> 
> > 
> > >   int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
> > >  
> > >   for (d = 0; d < ARRAY_SIZE(dividers); d++) {
> > > -- 
> > > 2.13.6
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC

-- 
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.IGT: warning for YCBCR 4:2:0 output support for LSPCON

2017-11-14 Thread Patchwork
== Series Details ==

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

== Summary ==

Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-hsw) fdo#102254

fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-hswtotal:2584 pass:1468 dwarn:4   dfail:1   fail:11  skip:1100 
time:9484s
Blacklisted hosts:
shard-apltotal:2565 pass:1603 dwarn:1   dfail:0   fail:23  skip:937 
time:12798s
shard-kbltotal:2495 pass:1631 dwarn:42  dfail:1   fail:24  skip:795 
time:10341s
shard-snbtotal:2584 pass:1206 dwarn:1   dfail:1   fail:13  skip:1363 
time:s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7119/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 drm/i915: Misc. PMIC bus access notifier fixes (rev2)

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Misc. PMIC bus access notifier fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/32274/
State : success

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252

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

shard-hswtotal:2584 pass:1472 dwarn:2   dfail:1   fail:10  skip:1099 
time:9507s
Blacklisted hosts:
shard-apltotal:2565 pass:1602 dwarn:1   dfail:0   fail:24  skip:937 
time:12824s
shard-kbltotal:2554 pass:1665 dwarn:8   dfail:1   fail:24  skip:854 
time:9914s
shard-snbtotal:2584 pass:1201 dwarn:4   dfail:1   fail:13  skip:1365 
time:7815s

== Logs ==

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


Re: [Intel-gfx] [PATCH 6/7] drm/i915/cnl: Write dco_fraction calculation as spec.

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 11:47:58AM -0800, Rodrigo Vivi wrote:
> I confess I never fully understood that previous calculation,
> so maybe this is cannot be called a "fix". But let's follow
> the math that is written on Spec so we have get more confident
> this is what hardware expect.
> 
> Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: James Ausmus 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index bd608f7f2399..ee690d2f6e54 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2190,8 +2190,8 @@ static void cnl_wrpll_params_populate(struct 
> skl_wrpll_params *params,
>   params->qdiv_mode = (qdiv == 1) ? 0 : 1;
>  
>   params->dco_integer = div_u64(dco_freq, ref_freq);
> - params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
> (uint64_t)ref_freq) -
> - ((uint64_t)params->dco_integer<<15)) * 
> 0x8000, 0x8000);
> + params->dco_fraction = (DIV_ROUND_UP_ULL(dco_freq, ref_freq) -
> + params->dco_integer) * (1 << 15);

Is dco_freq in khz here? Or hz?

If khz, the following should work... I think:

unsigned int dco = div_u64((u64)dco_freq << 15, ref_freq * 1000);
dco_int = dco >> 15;
dco_frac = dco & 0x7fff;

>  }
>  
>  static bool
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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.IGT: success for drm/i915: Remove pre-production pooled-EU w/a for Broxton

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Remove pre-production pooled-EU w/a for Broxton
URL   : https://patchwork.freedesktop.org/series/33781/
State : success

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
dmesg-warn -> PASS   (shard-hsw) fdo#103038
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

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

shard-hswtotal:2584 pass:1472 dwarn:2   dfail:1   fail:10  skip:1099 
time:9517s
Blacklisted hosts:
shard-apltotal:2565 pass:1599 dwarn:4   dfail:0   fail:25  skip:936 
time:12856s
shard-kbltotal:2522 pass:1632 dwarn:51  dfail:1   fail:24  skip:812 
time:10258s
shard-snbtotal:2584 pass:1203 dwarn:1   dfail:1   fail:13  skip:1366 
time:7752s

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Chris Wilson
Quoting Paulo Zanoni (2017-11-14 20:12:41)
> Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> > From: Ville Syrjälä 
> > 
> > Apparently there are some machines that put semi-sensible looking
> > values
> > into the stolen "reserved" base and size, except those values are
> > actually
> > outside the stolen memory. There is a bit in the register which
> > supposedly could tell us whether the reserved area is even enabled or
> > not. Let's check for that before we go trusting the base and size.
> 
> If this is such a problem since g4x, why didn't we spot it earlier? It
> would be nice if you could explain in the commit message (or at least
> in this email) what are the consequences you're seeing that made you
> realize about this problem. Did something actually explode? I'm
> genuinely curious.

The consequence is that we disable stolen; the machine keeps on working
quite happily. Only fbc actually depends on stolen allocation to
function, and no one complains if fbc is disabled. (There's a sketch out
there that we could use a contiguous allocation for fbc if we run out of
stolen.) Internal hw functions are oblivious to our qualms about the
location of stolen and whether some other device is using the same
physical address for its trampoline.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] dma-buf/fence: Fix lock inversion within dma-fence-array

2017-11-14 Thread Christian König

Am 14.11.2017 um 17:27 schrieb Chris Wilson:

Ages ago Rob Clark noted,

"Currently with fence-array, we have a potential deadlock situation.  If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on it's array-member fences, so the array-member's lock is acquired
second.

But in the signal path, the array-member's lock is acquired first, and
the array-fence's lock acquired second."

Rob proposed either extensive changes to dma-fence to unnest the
fence-array signaling


BTW: I've looked into this a bit as well to fix lock inversion with the 
GPU scheduler. Long story short: It would be really nice to have, but a 
pain to fix.



, or to defer the signaling onto a workqueue. This
is a more refined version of the later, that should keep the latency
of the fence signaling to a minimum by using an irq-work, which is
executed asap.

Reported-by: Rob Clark 
Suggested-by: Rob Clark 
References: 1476635975-21981-1-git-send-email-robdcl...@gmail.com
Signed-off-by: Chris Wilson 


Reviewed-by: Christian König 


Cc: Rob Clark 
Cc: Gustavo Padovan 
Cc: Sumit Semwal 
Cc: Christian König 
---
  drivers/base/Kconfig  |  1 +
  drivers/dma-buf/dma-fence-array.c | 14 --
  include/linux/dma-fence-array.h   |  3 +++
  3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 2f6614c9a229..2c3cab066871 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -245,6 +245,7 @@ config DMA_SHARED_BUFFER
bool
default n
select ANON_INODES
+   select IRQ_WORK
help
  This option enables the framework for buffer-sharing between
  multiple drivers. A buffer is associated with a file using driver
diff --git a/drivers/dma-buf/dma-fence-array.c 
b/drivers/dma-buf/dma-fence-array.c
index 0350829ba62e..dd1edfb27b61 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -31,6 +31,14 @@ static const char *dma_fence_array_get_timeline_name(struct 
dma_fence *fence)
return "unbound";
  }
  
+static void irq_dma_fence_array_work(struct irq_work *wrk)

+{
+   struct dma_fence_array *array = container_of(wrk, typeof(*array), work);
+
+   dma_fence_signal(>base);
+   dma_fence_put(>base);
+}
+
  static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_cb *cb)
  {
@@ -39,8 +47,9 @@ static void dma_fence_array_cb_func(struct dma_fence *f,
struct dma_fence_array *array = array_cb->array;
  
  	if (atomic_dec_and_test(>num_pending))

-   dma_fence_signal(>base);
-   dma_fence_put(>base);
+   irq_work_queue(>work);
+   else
+   dma_fence_put(>base);
  }
  
  static bool dma_fence_array_enable_signaling(struct dma_fence *fence)

@@ -136,6 +145,7 @@ struct dma_fence_array *dma_fence_array_create(int 
num_fences,
spin_lock_init(>lock);
dma_fence_init(>base, _fence_array_ops, >lock,
   context, seqno);
+   init_irq_work(>work, irq_dma_fence_array_work);
  
  	array->num_fences = num_fences;

atomic_set(>num_pending, signal_on_any ? 1 : num_fences);
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 332a5420243c..bc8940ca280d 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -21,6 +21,7 @@
  #define __LINUX_DMA_FENCE_ARRAY_H
  
  #include 

+#include 
  
  /**

   * struct dma_fence_array_cb - callback helper for fence array
@@ -47,6 +48,8 @@ struct dma_fence_array {
unsigned num_fences;
atomic_t num_pending;
struct dma_fence **fences;
+
+   struct irq_work work;
  };
  
  extern const struct dma_fence_ops dma_fence_array_ops;



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


Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check if the stolen memory "reserved" area is enabled or not

2017-11-14 Thread Paulo Zanoni
Em Qui, 2017-11-02 às 17:17 +0200, Ville Syrjala escreveu:
> From: Ville Syrjälä 
> 
> Apparently there are some machines that put semi-sensible looking
> values
> into the stolen "reserved" base and size, except those values are
> actually
> outside the stolen memory. There is a bit in the register which
> supposedly could tell us whether the reserved area is even enabled or
> not. Let's check for that before we go trusting the base and size.

If this is such a problem since g4x, why didn't we spot it earlier? It
would be nice if you could explain in the commit message (or at least
in this email) what are the consequences you're seeing that made you
realize about this problem. Did something actually explode? I'm
genuinely curious.


Now talking about the patch itself:

If we're going to assume random bits instead of a full-zero in
(possibly) uninitialized stuff, shouldn't we first check bit 1, which
is supposed to tell us if the whole reg is locked or not?

if ((reg_val & 0x3) != 0x3)
ignore stolen reserved stuff;

Anyway, this patch without my suggestions is probably better than the
current situation so:
Reviewed-by: Paulo Zanoni 
but please feel investigate the bit 1 thing and CC me on v2 or a
possible follow-up patch with conclusions.


> Cc: Tomi Sarvela 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 30
> ++
>  drivers/gpu/drm/i915/i915_reg.h|  2 ++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 03e7abc7e043..44a5dbc8c23b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -294,6 +294,12 @@ static void g4x_get_stolen_reserved(struct
> drm_i915_private *dev_priv,
>    ELK_STOLEN_RESERVED);
>   dma_addr_t stolen_top = dev_priv->mm.stolen_base + ggtt-
> >stolen_size;
>  
> + if ((reg_val & G4X_STOLEN_RESERVED_ENABLE) == 0) {
> + *base = 0;
> + *size = 0;
> + return;
> + }
> +
>   *base = (reg_val & G4X_STOLEN_RESERVED_ADDR2_MASK) << 16;
>  
>   WARN_ON((reg_val & G4X_STOLEN_RESERVED_ADDR1_MASK) < *base);
> @@ -313,6 +319,12 @@ static void gen6_get_stolen_reserved(struct
> drm_i915_private *dev_priv,
>  {
>   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
>  
> + if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> + *base = 0;
> + *size = 0;
> + return;
> + }
> +
>   *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
>  
>   switch (reg_val & GEN6_STOLEN_RESERVED_SIZE_MASK) {
> @@ -339,6 +351,12 @@ static void gen7_get_stolen_reserved(struct
> drm_i915_private *dev_priv,
>  {
>   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
>  
> + if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> + *base = 0;
> + *size = 0;
> + return;
> + }
> +
>   *base = reg_val & GEN7_STOLEN_RESERVED_ADDR_MASK;
>  
>   switch (reg_val & GEN7_STOLEN_RESERVED_SIZE_MASK) {
> @@ -359,6 +377,12 @@ static void chv_get_stolen_reserved(struct
> drm_i915_private *dev_priv,
>  {
>   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
>  
> + if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> + *base = 0;
> + *size = 0;
> + return;
> + }
> +
>   *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
>  
>   switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
> @@ -387,6 +411,12 @@ static void bdw_get_stolen_reserved(struct
> drm_i915_private *dev_priv,
>   uint32_t reg_val = I915_READ(GEN6_STOLEN_RESERVED);
>   dma_addr_t stolen_top;
>  
> + if ((reg_val & GEN6_STOLEN_RESERVED_ENABLE) == 0) {
> + *base = 0;
> + *size = 0;
> + return;
> + }
> +
>   stolen_top = dev_priv->mm.stolen_base + ggtt->stolen_size;
>  
>   *base = reg_val & GEN6_STOLEN_RESERVED_ADDR_MASK;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index f0f8f6059652..dc2cbc428d1b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -382,6 +382,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t
> reg)
>  #define GEN8_STOLEN_RESERVED_2M  (1 << 7)
>  #define GEN8_STOLEN_RESERVED_4M  (2 << 7)
>  #define GEN8_STOLEN_RESERVED_8M  (3 << 7)
> +#define GEN6_STOLEN_RESERVED_ENABLE  (1 << 0)
>  
>  /* VGA stuff */
>  
> @@ -3398,6 +3399,7 @@ enum i915_power_well_id {
>  #define ELK_STOLEN_RESERVED  _MMIO(MCHBAR_MIRROR_BASE
> + 0x48)
>  #define G4X_STOLEN_RESERVED_ADDR1_MASK   (0x << 16)
>  #define G4X_STOLEN_RESERVED_ADDR2_MASK   (0xFFF << 4)
> +#define G4X_STOLEN_RESERVED_ENABLE   (1 << 0)
>  

Re: [Intel-gfx] [PATCH 4/7] drm/i915/cnl: Fix wrpll math for higher freqs.

2017-11-14 Thread Rodrigo Vivi
On Tue, Nov 14, 2017 at 08:00:31PM +, Ville Syrjälä wrote:
> On Tue, Nov 14, 2017 at 11:47:56AM -0800, Rodrigo Vivi wrote:
> > Spec describe all values in MHz. We handle our
> > clocks in KHz. This includes the best_dco_centrality that was
> > forgot in the same unity as spec. Consequently we couldn't
> > get a good divider for high frequenies. Hence HDMI 2.0 wasn't
> > working.
> > 
> > This patch also replaces the use of "* KHz(1)" with the values
> > directly on KHz to avoid future confusion.
> > 
> > Cc: Shashank Sharma 
> > Cc: Mika Kahola 
> > Cc: Manasi Navare 
> > Cc: James Ausmus 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index fba969cbda37..53f650f56148 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2201,8 +2201,8 @@ cnl_ddi_calculate_wrpll(int clock,
> > struct skl_wrpll_params *wrpll_params)
> >  {
> > u32 afe_clock = clock * 5;
> > -   u32 dco_min = 7998 * KHz(1);
> > -   u32 dco_max = 1 * KHz(1);
> > +   u32 dco_min = 7998000;
> > +   u32 dco_max = 1000;
> > u32 dco_mid = (dco_min + dco_max) / 2;
> > static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
> >  18, 20, 24, 28, 30, 32,  36,  40,
> > @@ -2211,7 +2211,7 @@ cnl_ddi_calculate_wrpll(int clock,
> >  84, 88, 90, 92, 96, 98, 100, 102,
> >   3,  5,  7,  9, 15, 21 };
> > u32 dco, best_dco = 0, dco_centrality = 0;
> > -   u32 best_dco_centrality = 99;
> > +   u32 best_dco_centrality = 99000;
> 
> UINT_MAX, -1, or ~0 maybe?

yeap, I considered the max macros, but I didn't want to deviate
from spec...

> 
> > int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
> >  
> > for (d = 0; d < ARRAY_SIZE(dividers); d++) {
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> 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/selftests: Markup __iomem for igt_gem_coherency

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Markup __iomem for igt_gem_coherency
URL   : https://patchwork.freedesktop.org/series/33819/
State : success

== Summary ==

Series 33819v1 drm/i915/selftests: Markup __iomem for igt_gem_coherency
https://patchwork.freedesktop.org/api/1.0/series/33819/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:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:457s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:541s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:501s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:497s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:488s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:426s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:440s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:424s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:531s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:468s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:571s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:545s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:554s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:525s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:557s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:495s

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
3122b5bad339 drm/i915/selftests: Markup __iomem for igt_gem_coherency

== Logs ==

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


Re: [Intel-gfx] [PATCH 4/7] drm/i915/cnl: Fix wrpll math for higher freqs.

2017-11-14 Thread Ville Syrjälä
On Tue, Nov 14, 2017 at 11:47:56AM -0800, Rodrigo Vivi wrote:
> Spec describe all values in MHz. We handle our
> clocks in KHz. This includes the best_dco_centrality that was
> forgot in the same unity as spec. Consequently we couldn't
> get a good divider for high frequenies. Hence HDMI 2.0 wasn't
> working.
> 
> This patch also replaces the use of "* KHz(1)" with the values
> directly on KHz to avoid future confusion.
> 
> Cc: Shashank Sharma 
> Cc: Mika Kahola 
> Cc: Manasi Navare 
> Cc: James Ausmus 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index fba969cbda37..53f650f56148 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2201,8 +2201,8 @@ cnl_ddi_calculate_wrpll(int clock,
>   struct skl_wrpll_params *wrpll_params)
>  {
>   u32 afe_clock = clock * 5;
> - u32 dco_min = 7998 * KHz(1);
> - u32 dco_max = 1 * KHz(1);
> + u32 dco_min = 7998000;
> + u32 dco_max = 1000;
>   u32 dco_mid = (dco_min + dco_max) / 2;
>   static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
>18, 20, 24, 28, 30, 32,  36,  40,
> @@ -2211,7 +2211,7 @@ cnl_ddi_calculate_wrpll(int clock,
>84, 88, 90, 92, 96, 98, 100, 102,
> 3,  5,  7,  9, 15, 21 };
>   u32 dco, best_dco = 0, dco_centrality = 0;
> - u32 best_dco_centrality = 99;
> + u32 best_dco_centrality = 99000;

UINT_MAX, -1, or ~0 maybe?

>   int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
>  
>   for (d = 0; d < ARRAY_SIZE(dividers); d++) {
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update name and prototype of GuC submission related functions

2017-11-14 Thread Chris Wilson
Quoting Sagar Arun Kamble (2017-11-14 19:47:05)
> 
> 
> On 11/15/2017 1:01 AM, Chris Wilson wrote:
> > Quoting Michal Wajdeczko (2017-11-14 19:23:24)
> >> On Tue, 14 Nov 2017 19:27:26 +0100, Chris Wilson
> >>  wrote:
> >>
> >>> Quoting Sagar Arun Kamble (2017-11-14 18:19:01)
> 
>  On 11/14/2017 5:53 PM, Michal Wajdeczko wrote:
> > On Mon, 13 Nov 2017 09:48:11 +0100, Sagar Arun Kamble
> >  wrote:
> >> -static void i915_guc_irq_handler(unsigned long data)
> >> +static void intel_guc_irq_handler(unsigned long data)
> > and verbose "guc_submission_handler()" ?
> >
>  Yes. Should we rename irq_tasklet to submission_tasklet?
>  then we can s/intel_lrc_irq_handler/execlists_submission_tasklet and
>  s/i915_guc_irq_handler/guc_submission_tasklet.
>  Again trying to maintain the nomenclature consistency for Execlists and
>  GuC.
> >>> Ok. Do that as a separate (initial) step.
> >> Hmm. By "tasklet" I usually think of "tasklet_struct". Then
> >> "guc_submission_tasklet" suggests that this is another kind
> >> or customized "tasklet" struct. So maybe use full name:
> >>
> >> s/i915_guc_irq_handler/guc_submission_tasklet_func ?
> > Please no. You'll grow to dislike the tautology immensely!
> >
> > struct tasklet tasklet;
> >
> > execlists->tasklet = execlists_submission_tasklet;
> You meant "execlists->tasklet.func =" here right?
> > execlists->tasklet = guc_submission_tasklet;
> >
> > tasklet_schedule(engine->execlists.tasklet) etc
> >
> > is clear to me.
> > -Chris
> Michal wanted to distinguish tasklet func from tasklet.

I don't see the point as I don't find any confusion between a struct and
a function. The tasklet is the function; struct tasklet is
merely its integration to softirq.
-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 series starting with [1/2] drm/i915: Drop the unbound page cache upon idling

2017-11-14 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Drop the unbound page cache upon 
idling
URL   : https://patchwork.freedesktop.org/series/33817/
State : success

== Summary ==

Series 33817v1 series starting with [1/2] drm/i915: Drop the unbound page cache 
upon idling
https://patchwork.freedesktop.org/api/1.0/series/33817/revisions/1/mbox/

Test gem_sync:
Subgroup basic-store-all:
pass   -> FAIL   (fi-ivb-3520m) fdo#17
Test kms_busy:
Subgroup basic-flip-b:
pass   -> FAIL   (fi-gdg-551) fdo#102654
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:458s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:374s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:532s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:274s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:491s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:430s
fi-gdg-551   total:289  pass:177  dwarn:1   dfail:0   fail:2   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:437s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:421s
fi-ivb-3520m total:289  pass:259  dwarn:0   dfail:0   fail:1   skip:29  
time:478s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:471s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:575s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:547s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:559s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:419s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:530s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:569s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:495s

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
37edd581e8ff drm/i915: Remove temporary allocation of dma addresses when 
rotating
9401693bec81 drm/i915: Drop the unbound page cache upon idling

== Logs ==

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


[Intel-gfx] [PATCH 6/7] drm/i915/cnl: Write dco_fraction calculation as spec.

2017-11-14 Thread Rodrigo Vivi
I confess I never fully understood that previous calculation,
so maybe this is cannot be called a "fix". But let's follow
the math that is written on Spec so we have get more confident
this is what hardware expect.

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index bd608f7f2399..ee690d2f6e54 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2190,8 +2190,8 @@ static void cnl_wrpll_params_populate(struct 
skl_wrpll_params *params,
params->qdiv_mode = (qdiv == 1) ? 0 : 1;
 
params->dco_integer = div_u64(dco_freq, ref_freq);
-   params->dco_fraction = div_u64((div_u64((uint64_t)dco_freq<<15, 
(uint64_t)ref_freq) -
-   ((uint64_t)params->dco_integer<<15)) * 
0x8000, 0x8000);
+   params->dco_fraction = (DIV_ROUND_UP_ULL(dco_freq, ref_freq) -
+   params->dco_integer) * (1 << 15);
 }
 
 static bool
-- 
2.13.6

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


[Intel-gfx] [PATCH 2/7] drm/i915/cnl: Remove useless conversion.

2017-11-14 Thread Rodrigo Vivi
No functional change. Just starting the wrpll fixes
with a clean-up to make units a bit more clear.

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 61c684ac47af..db7afd314462 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2198,11 +2198,11 @@ static void cnl_wrpll_params_populate(struct 
skl_wrpll_params *params, uint32_t
 }
 
 static bool
-cnl_ddi_calculate_wrpll(int clock /* in Hz */,
+cnl_ddi_calculate_wrpll(int clock,
struct drm_i915_private *dev_priv,
struct skl_wrpll_params *wrpll_params)
 {
-   uint64_t afe_clock = clock * 5 / KHz(1); /* clocks in kHz */
+   uint64_t afe_clock = clock * 5;
unsigned int dco_min = 7998 * KHz(1);
unsigned int dco_max = 1 * KHz(1);
unsigned int dco_mid = (dco_min + dco_max) / 2;
@@ -2255,7 +2255,7 @@ static bool cnl_ddi_hdmi_pll_dividers(struct intel_crtc 
*crtc,
 
cfgcr0 = DPLL_CFGCR0_HDMI_MODE;
 
-   if (!cnl_ddi_calculate_wrpll(clock * 1000, dev_priv, _params))
+   if (!cnl_ddi_calculate_wrpll(clock, dev_priv, _params))
return false;
 
cfgcr0 |= DPLL_CFGCR0_DCO_FRACTION(wrpll_params.dco_fraction) |
-- 
2.13.6

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


[Intel-gfx] [PATCH 7/7] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

2017-11-14 Thread Rodrigo Vivi
Starting on GLK we support HDMI 2.0. So this patch only
extend the work Shashank has made to GLK to CNL.

v2: The version that compiles :/

Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Manasi Navare 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2d95db64cdf2..96c314a6170a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1235,7 +1235,7 @@ static int intel_hdmi_source_max_tmds_clock(struct 
intel_encoder *encoder)
_priv->vbt.ddi_port_info[encoder->port];
int max_tmds_clock;
 
-   if (IS_GEMINILAKE(dev_priv))
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
max_tmds_clock = 594000;
else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
max_tmds_clock = 30;
@@ -1511,7 +1511,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->lane_count = 4;
 
-   if (scdc->scrambling.supported && IS_GEMINILAKE(dev_priv)) {
+   if (scdc->scrambling.supported && (IS_GEMINILAKE(dev_priv) ||
+  INTEL_GEN(dev_priv) >= 10)) {
if (scdc->scrambling.low_rates)
pipe_config->hdmi_scrambling = true;
 
@@ -2033,7 +2034,7 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
connector->doublescan_allowed = 0;
connector->stereo_allowed = 1;
 
-   if (IS_GEMINILAKE(dev_priv))
+   if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
connector->ycbcr_420_allowed = true;
 
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
-- 
2.13.6

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


[Intel-gfx] [PATCH 5/7] drm/i915/cnl: Don't blindly replace qdiv.

2017-11-14 Thread Rodrigo Vivi
Accordingly to spec "If Kdiv != 2, then Qdiv must be 1."
but we already handle qdiv values properly and this case here
should be spurious. But instead of blindly replacing let's
warn loudly instead. Because it means something was really
wrong on initial setup.

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 53f650f56148..bd608f7f2399 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2184,8 +2184,7 @@ static void cnl_wrpll_params_populate(struct 
skl_wrpll_params *params,
WARN(1, "Incorrect PDiv\n");
}
 
-   if (kdiv != 2)
-   qdiv = 1;
+   WARN_ON(kdiv != 2 && qdiv != 1);
 
params->qdiv_ratio = qdiv;
params->qdiv_mode = (qdiv == 1) ? 0 : 1;
-- 
2.13.6

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


[Intel-gfx] [PATCH 3/7] drm/i915/cnl: Fix, simplify and unify wrpll variable sizes.

2017-11-14 Thread Rodrigo Vivi
- 64 bits is not needed for afe_clock now we don't convert
  that to Hz.
- 16 bits is not enough for all dco stuff.
- unsigned is not relevant/needed for all divisors values.

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 30 --
 1 file changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index db7afd314462..fba969cbda37 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2110,10 +2110,8 @@ static bool cnl_ddi_pll_get_hw_state(struct 
drm_i915_private *dev_priv,
return ret;
 }
 
-static void cnl_wrpll_get_multipliers(unsigned int bestdiv,
- unsigned int *pdiv,
- unsigned int *qdiv,
- unsigned int *kdiv)
+static void cnl_wrpll_get_multipliers(int bestdiv, int *pdiv,
+ int *qdiv, int *kdiv)
 {
/* even dividers */
if (bestdiv % 2 == 0) {
@@ -2151,9 +2149,9 @@ static void cnl_wrpll_get_multipliers(unsigned int 
bestdiv,
}
 }
 
-static void cnl_wrpll_params_populate(struct skl_wrpll_params *params, 
uint32_t dco_freq,
- uint32_t ref_freq, uint32_t pdiv, 
uint32_t qdiv,
- uint32_t kdiv)
+static void cnl_wrpll_params_populate(struct skl_wrpll_params *params,
+ u32 dco_freq, u32 ref_freq,
+ int pdiv, int qdiv, int kdiv)
 {
switch (kdiv) {
case 1:
@@ -2202,23 +2200,19 @@ cnl_ddi_calculate_wrpll(int clock,
struct drm_i915_private *dev_priv,
struct skl_wrpll_params *wrpll_params)
 {
-   uint64_t afe_clock = clock * 5;
-   unsigned int dco_min = 7998 * KHz(1);
-   unsigned int dco_max = 1 * KHz(1);
-   unsigned int dco_mid = (dco_min + dco_max) / 2;
-
+   u32 afe_clock = clock * 5;
+   u32 dco_min = 7998 * KHz(1);
+   u32 dco_max = 1 * KHz(1);
+   u32 dco_mid = (dco_min + dco_max) / 2;
static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
 18, 20, 24, 28, 30, 32,  36,  40,
 42, 44, 48, 50, 52, 54,  56,  60,
 64, 66, 68, 70, 72, 76,  78,  80,
 84, 88, 90, 92, 96, 98, 100, 102,
  3,  5,  7,  9, 15, 21 };
-   unsigned int d, dco;
-   unsigned int dco_centrality = 0;
-   unsigned int best_dco_centrality = 99;
-   unsigned int best_div = 0;
-   unsigned int best_dco = 0;
-   unsigned int pdiv = 0, qdiv = 0, kdiv = 0;
+   u32 dco, best_dco = 0, dco_centrality = 0;
+   u32 best_dco_centrality = 99;
+   int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
 
for (d = 0; d < ARRAY_SIZE(dividers); d++) {
dco = afe_clock * dividers[d];
-- 
2.13.6

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


[Intel-gfx] [PATCH 1/7] drm/i915/cnl: Remove spurious central_freq.

2017-11-14 Thread Rodrigo Vivi
"Display software must leave this field at the default value.
It no longer needs to be configured as part of PLL programming."

We respect this already and we are setting up the default
one line below: "DPLL_CFGCR1_CENTRAL_FREQ".

Also we don't touch anywhere else this central_freq for cnl.
So let's remove from the final write.

No functional change. Only a clean-up patch.

Cc: Manasi Navare 
Cc: Mika Kahola 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index be74d4767c8a..61c684ac47af 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2265,7 +2265,6 @@ static bool cnl_ddi_hdmi_pll_dividers(struct intel_crtc 
*crtc,
DPLL_CFGCR1_QDIV_MODE(wrpll_params.qdiv_mode) |
DPLL_CFGCR1_KDIV(wrpll_params.kdiv) |
DPLL_CFGCR1_PDIV(wrpll_params.pdiv) |
-   wrpll_params.central_freq |
DPLL_CFGCR1_CENTRAL_FREQ;
 
memset(_state->dpll_hw_state, 0,
-- 
2.13.6

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


[Intel-gfx] [PATCH 4/7] drm/i915/cnl: Fix wrpll math for higher freqs.

2017-11-14 Thread Rodrigo Vivi
Spec describe all values in MHz. We handle our
clocks in KHz. This includes the best_dco_centrality that was
forgot in the same unity as spec. Consequently we couldn't
get a good divider for high frequenies. Hence HDMI 2.0 wasn't
working.

This patch also replaces the use of "* KHz(1)" with the values
directly on KHz to avoid future confusion.

Cc: Shashank Sharma 
Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: James Ausmus 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index fba969cbda37..53f650f56148 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2201,8 +2201,8 @@ cnl_ddi_calculate_wrpll(int clock,
struct skl_wrpll_params *wrpll_params)
 {
u32 afe_clock = clock * 5;
-   u32 dco_min = 7998 * KHz(1);
-   u32 dco_max = 1 * KHz(1);
+   u32 dco_min = 7998000;
+   u32 dco_max = 1000;
u32 dco_mid = (dco_min + dco_max) / 2;
static const int dividers[] = {  2,  4,  6,  8, 10, 12,  14,  16,
 18, 20, 24, 28, 30, 32,  36,  40,
@@ -2211,7 +2211,7 @@ cnl_ddi_calculate_wrpll(int clock,
 84, 88, 90, 92, 96, 98, 100, 102,
  3,  5,  7,  9, 15, 21 };
u32 dco, best_dco = 0, dco_centrality = 0;
-   u32 best_dco_centrality = 99;
+   u32 best_dco_centrality = 99000;
int d, best_div = 0, pdiv = 0, qdiv = 0, kdiv = 0;
 
for (d = 0; d < ARRAY_SIZE(dividers); d++) {
-- 
2.13.6

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


[Intel-gfx] [PATCH 0/7] WRPLL fixes for HDMI 2.0 on Cannonlake.

2017-11-14 Thread Rodrigo Vivi
With these fixes and clean-ups around wrpll plus
extending HDMI 2.0 from GLK to CNL we could finally
get a functional HDMI 2.0 display with 4k60Hz.

Thanks,
Rodrigo.

Rodrigo Vivi (7):
  drm/i915/cnl: Remove spurious central_freq.
  drm/i915/cnl: Remove useless conversion.
  drm/i915/cnl: Fix, simplify and unify wrpll variable sizes.
  drm/i915/cnl: Fix wrpll math for higher freqs.
  drm/i915/cnl: Don't blindly replace qdiv.
  drm/i915/cnl: Write dco_fraction calculation as spec.
  drm/i915/cnl: Extend HDMI 2.0 support to CNL.

 drivers/gpu/drm/i915/intel_dpll_mgr.c | 42 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  7 +++---
 2 files changed, 21 insertions(+), 28 deletions(-)

-- 
2.13.6

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


[Intel-gfx] [PATCH] drm/i915/selftests: Always initialise err

2017-11-14 Thread Chris Wilson
smatch does not track initialised values as well as gcc, and this
triggers many warnings by smatch not presented by gcc. Silence smatch by
initialising the error values to -ENODEV, which we use to denote
internal errors. (If we see a selftest fail with a silent -ENODEV, we
know smatch was right!)

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/selftests/i915_gem_context.c  | 2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  | 8 
 drivers/gpu/drm/i915/selftests/i915_gem_request.c  | 2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 2 +-
 drivers/gpu/drm/i915/selftests/i915_syncmap.c  | 6 +++---
 drivers/gpu/drm/i915/selftests/i915_vma.c  | 2 +-
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 61fcfa2c4dfd..664d1b4f8c69 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -321,7 +321,7 @@ static int igt_ctx_exec(void *arg)
LIST_HEAD(objects);
unsigned long ncontexts, ndwords, dw;
bool first_shared_gtt = true;
-   int err;
+   int err = -ENODEV;
 
/* Create a few different contexts (with different mm) and write
 * through each ctx/mm using the GPU making sure those writes end
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 581296860539..d9560d8a6cc8 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -699,7 +699,7 @@ static int drunk_hole(struct drm_i915_private *i915,
unsigned int *order, count, n;
struct i915_vma *vma;
u64 hole_size;
-   int err;
+   int err = -ENODEV;
 
hole_size = (hole_end - hole_start) >> size;
if (hole_size > KMALLOC_MAX_SIZE / sizeof(u32))
@@ -958,7 +958,7 @@ static int exercise_ggtt(struct drm_i915_private *i915,
u64 hole_start, hole_end, last = 0;
struct drm_mm_node *node;
IGT_TIMEOUT(end_time);
-   int err;
+   int err = -ENODEV;
 
mutex_lock(>drm.struct_mutex);
 restart:
@@ -1164,7 +1164,7 @@ static int igt_gtt_reserve(void *arg)
struct drm_i915_gem_object *obj, *on;
LIST_HEAD(objects);
u64 total;
-   int err;
+   int err = -ENODEV;
 
/* i915_gem_gtt_reserve() tries to reserve the precise range
 * for the node, and evicts if it has to. So our test checks that
@@ -1355,7 +1355,7 @@ static int igt_gtt_insert(void *arg)
}, *ii;
LIST_HEAD(objects);
u64 total;
-   int err;
+   int err = -ENODEV;
 
/* i915_gem_gtt_insert() tries to allocate some free space in the GTT
 * to the node, evicting if required.
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_request.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
index 9a35ebd5c876..e3871db78beb 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_request.c
@@ -332,7 +332,7 @@ static int live_nop_request(void *arg)
struct intel_engine_cs *engine;
struct live_test t;
unsigned int id;
-   int err;
+   int err = -ENODEV;
 
/* Submit various sized batches of empty requests, to each engine
 * (individually), and wait for the batch to complete. We can check
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
index 4795877abe56..3000e6a7d82d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
@@ -79,7 +79,7 @@ static int igt_sync(void *arg)
}, *p;
struct intel_timeline *tl;
int order, offset;
-   int ret;
+   int ret = -ENODEV;
 
tl = mock_timeline(0);
if (!tl)
diff --git a/drivers/gpu/drm/i915/selftests/i915_syncmap.c 
b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
index bcab3d00a785..47f4ae18a1ef 100644
--- a/drivers/gpu/drm/i915/selftests/i915_syncmap.c
+++ b/drivers/gpu/drm/i915/selftests/i915_syncmap.c
@@ -333,7 +333,7 @@ static int igt_syncmap_join_below(void *arg)
 {
struct i915_syncmap *sync;
unsigned int step, order, idx;
-   int err;
+   int err = -ENODEV;
 
i915_syncmap_init();
 
@@ -402,7 +402,7 @@ static int igt_syncmap_neighbours(void *arg)
I915_RND_STATE(prng);
IGT_TIMEOUT(end_time);
struct i915_syncmap *sync;
-   int err;
+   int err = -ENODEV;
 
/*
 * Each leaf holds KSYNCMAP seqno. Check that when we create KSYNCMAP
@@ -447,7 +447,7 @@ static int igt_syncmap_compact(void *arg)
 {
struct i915_syncmap *sync;
unsigned int idx, order;
-   int err;
+   int err = -ENODEV;
 

Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update name and prototype of GuC submission related functions

2017-11-14 Thread Sagar Arun Kamble



On 11/15/2017 1:01 AM, Chris Wilson wrote:

Quoting Michal Wajdeczko (2017-11-14 19:23:24)

On Tue, 14 Nov 2017 19:27:26 +0100, Chris Wilson
 wrote:


Quoting Sagar Arun Kamble (2017-11-14 18:19:01)


On 11/14/2017 5:53 PM, Michal Wajdeczko wrote:

On Mon, 13 Nov 2017 09:48:11 +0100, Sagar Arun Kamble
 wrote:

-static void i915_guc_irq_handler(unsigned long data)
+static void intel_guc_irq_handler(unsigned long data)

and verbose "guc_submission_handler()" ?


Yes. Should we rename irq_tasklet to submission_tasklet?
then we can s/intel_lrc_irq_handler/execlists_submission_tasklet and
s/i915_guc_irq_handler/guc_submission_tasklet.
Again trying to maintain the nomenclature consistency for Execlists and
GuC.

Ok. Do that as a separate (initial) step.

Hmm. By "tasklet" I usually think of "tasklet_struct". Then
"guc_submission_tasklet" suggests that this is another kind
or customized "tasklet" struct. So maybe use full name:

s/i915_guc_irq_handler/guc_submission_tasklet_func ?

Please no. You'll grow to dislike the tautology immensely!

struct tasklet tasklet;

execlists->tasklet = execlists_submission_tasklet;

You meant "execlists->tasklet.func =" here right?

execlists->tasklet = guc_submission_tasklet;

tasklet_schedule(engine->execlists.tasklet) etc

is clear to me.
-Chris

Michal wanted to distinguish tasklet func from tasklet.
I thought of naming vfunc as submission_tasklet and component functions 
as execlists/guc_submission_tasklet_func (with michal suggestion).

But that is looking little big i guess.
With Michal's initial suggestion how about below change? (irq_tasklet 
was little misleading for me)


struct tasklet tasklet;

execlists->tasklet.func = execlists_submission_handler;
execlists->tasklet.func = guc_submission_handler;

tasklet_schedule(engine->execlists.tasklet)


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


Re: [Intel-gfx] [PATCH 05/10] drm/modes: Fix description of DRM_MODE_TYPE_USERDEF

2017-11-14 Thread Alex Deucher
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> These days DRM_MODE_TYPE_USERDEF is used to flag modes defined via the
> kernel command line. Update the docs to reflect that fact.
>
> Signed-off-by: Ville Syrjälä 

Acked-by: Alex Deucher 

> ---
>  include/drm/drm_modes.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 09773e766e1f..8ddf7adb98df 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -253,6 +253,7 @@ struct drm_display_mode {
>  *  - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all 
> of
>  *them really. Drivers must set this bit for all modes they create
>  *and expose to userspace.
> +*  - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
>  *
>  * Plus a big list of flags which shouldn't be used at all, but are
>  * still around since these flags are also used in the userspace ABI:
> @@ -262,9 +263,6 @@ struct drm_display_mode {
>  *  - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
>  *which are stuck around for hysterical raisins only. No one has 
> an
>  *idea what they were meant for. Don't use.
> -*  - DRM_MODE_TYPE_USERDEF: Mode defined by userspace, again a 
> vestige
> -*from older kms designs where userspace had to first add a custom
> -*mode to the kernel's mode list before it could use it. Don't 
> use.
>  */
> unsigned int type;
>
> --
> 2.13.6
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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: Fix kerneldocs for intel_audio.c

2017-11-14 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix kerneldocs for intel_audio.c
URL   : https://patchwork.freedesktop.org/series/33816/
State : success

== Summary ==

Series 33816v1 drm/i915: Fix kerneldocs for intel_audio.c
https://patchwork.freedesktop.org/api/1.0/series/33816/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:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:447s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:379s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:525s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-byt-j1900 total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  
time:494s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:259s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:437s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:530s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:567s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:548s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:558s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:426s
Blacklisted hosts:
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:527s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:581s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:492s
fi-byt-n2820 failed to connect after reboot

c46476e24d6432b5792ef63596a985848d122d50 drm-tip: 2017y-11m-14d-17h-03m-32s UTC 
integration manifest
be64da101cc3 drm/i915: Fix kerneldocs for intel_audio.c

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update name and prototype of GuC submission related functions

2017-11-14 Thread Chris Wilson
Quoting Michal Wajdeczko (2017-11-14 19:23:24)
> On Tue, 14 Nov 2017 19:27:26 +0100, Chris Wilson  
>  wrote:
> 
> > Quoting Sagar Arun Kamble (2017-11-14 18:19:01)
> >>
> >>
> >> On 11/14/2017 5:53 PM, Michal Wajdeczko wrote:
> >> > On Mon, 13 Nov 2017 09:48:11 +0100, Sagar Arun Kamble
> >> >  wrote:
> >> >> -static void i915_guc_irq_handler(unsigned long data)
> >> >> +static void intel_guc_irq_handler(unsigned long data)
> >> >
> >> > and verbose "guc_submission_handler()" ?
> >> >
> >> Yes. Should we rename irq_tasklet to submission_tasklet?
> >> then we can s/intel_lrc_irq_handler/execlists_submission_tasklet and
> >> s/i915_guc_irq_handler/guc_submission_tasklet.
> >> Again trying to maintain the nomenclature consistency for Execlists and  
> >> GuC.
> >
> > Ok. Do that as a separate (initial) step.
> 
> Hmm. By "tasklet" I usually think of "tasklet_struct". Then
> "guc_submission_tasklet" suggests that this is another kind
> or customized "tasklet" struct. So maybe use full name:
> 
> s/i915_guc_irq_handler/guc_submission_tasklet_func ?

Please no. You'll grow to dislike the tautology immensely!

struct tasklet tasklet;

execlists->tasklet = execlists_submission_tasklet;
execlists->tasklet = guc_submission_tasklet;

tasklet_schedule(engine->execlists.tasklet) etc

is clear to me.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update name and prototype of GuC submission related functions

2017-11-14 Thread Michal Wajdeczko
On Tue, 14 Nov 2017 19:27:26 +0100, Chris Wilson  
 wrote:



Quoting Sagar Arun Kamble (2017-11-14 18:19:01)



On 11/14/2017 5:53 PM, Michal Wajdeczko wrote:
> On Mon, 13 Nov 2017 09:48:11 +0100, Sagar Arun Kamble
>  wrote:
>> -static void i915_guc_irq_handler(unsigned long data)
>> +static void intel_guc_irq_handler(unsigned long data)
>
> and verbose "guc_submission_handler()" ?
>
Yes. Should we rename irq_tasklet to submission_tasklet?
then we can s/intel_lrc_irq_handler/execlists_submission_tasklet and
s/i915_guc_irq_handler/guc_submission_tasklet.
Again trying to maintain the nomenclature consistency for Execlists and  
GuC.


Ok. Do that as a separate (initial) step.


Hmm. By "tasklet" I usually think of "tasklet_struct". Then
"guc_submission_tasklet" suggests that this is another kind
or customized "tasklet" struct. So maybe use full name:

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


Re: [Intel-gfx] [PATCH 01/10] drm/modes: Move 3D stereo flag check into drm_mode_validate_basic()

2017-11-14 Thread Alex Deucher
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> Currently we don't sanity check the 3D stereo flags for modes filled out
> by the kernel. Move the check from drm_mode_convert_umode() into
> drm_mode_validate_basic() so that we get the same check going both ways.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_modes.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 4a3f68a33844..1a72883b836e 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1036,6 +1036,9 @@ EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
>  enum drm_mode_status
>  drm_mode_validate_basic(const struct drm_display_mode *mode)
>  {
> +   if ((mode->flags & DRM_MODE_FLAG_3D_MASK) > DRM_MODE_FLAG_3D_MAX)
> +   return MODE_BAD;
> +
> if (mode->clock == 0)
> return MODE_CLOCK_LOW;
>
> @@ -1574,9 +1577,6 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
> goto out;
> }
>
> -   if ((in->flags & DRM_MODE_FLAG_3D_MASK) > DRM_MODE_FLAG_3D_MAX)
> -   goto out;
> -
> out->clock = in->clock;
> out->hdisplay = in->hdisplay;
> out->hsync_start = in->hsync_start;
> --
> 2.13.6
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 08/10] drm/uapi: Deprecate nonsense kms mode types

2017-11-14 Thread Alex Deucher
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> BUILTIN, CRTC_C, CLOCK_C, and DEFULT mode types are unused. Let's
> refuse to generate them or accept them from userspace either. A
> cursory check didn't reveal any userspace code that would depend
> on these.
>
> Cc: Jose Abreu 
> Cc: Adam Jackson 
> Cc: Keith Packard 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Alex Deucher 

> ---
>  include/drm/drm_modes.h |  7 ---
>  include/uapi/drm/drm_mode.h | 14 +-
>  2 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 99dd815269e9..7ac61858b54e 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -242,8 +242,6 @@ struct drm_display_mode {
>  * A bitmask of flags, mostly about the source of a mode. Possible 
> flags
>  * are:
>  *
> -*  - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
> -*unused.
>  *  - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
>  *resolution of an LCD panel. There should only be one preferred
>  *mode per connector at any given time.
> @@ -253,8 +251,11 @@ struct drm_display_mode {
>  *  - DRM_MODE_TYPE_USERDEF: Mode defined via kernel command line
>  *
>  * Plus a big list of flags which shouldn't be used at all, but are
> -* still around since these flags are also used in the userspace ABI:
> +* still around since these flags are also used in the userspace ABI.
> +* We no longer accept modes with these types though:
>  *
> +*  - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
> +*unused.
>  *  - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
>  *DRM_MODE_TYPE_PREFERRED instead.
>  *  - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index a7cded1c43e8..eb9b68c7c218 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -38,19 +38,15 @@ extern "C" {
>  #define DRM_DISPLAY_MODE_LEN   32
>  #define DRM_PROP_NAME_LEN  32
>
> -#define DRM_MODE_TYPE_BUILTIN  (1<<0)
> -#define DRM_MODE_TYPE_CLOCK_C  ((1<<1) | DRM_MODE_TYPE_BUILTIN)
> -#define DRM_MODE_TYPE_CRTC_C   ((1<<2) | DRM_MODE_TYPE_BUILTIN)
> +#define DRM_MODE_TYPE_BUILTIN  (1<<0) /* deprecated */
> +#define DRM_MODE_TYPE_CLOCK_C  ((1<<1) | DRM_MODE_TYPE_BUILTIN) /* 
> deprecated */
> +#define DRM_MODE_TYPE_CRTC_C   ((1<<2) | DRM_MODE_TYPE_BUILTIN) /* 
> deprecated */
>  #define DRM_MODE_TYPE_PREFERRED(1<<3)
> -#define DRM_MODE_TYPE_DEFAULT  (1<<4)
> +#define DRM_MODE_TYPE_DEFAULT  (1<<4) /* deprecated */
>  #define DRM_MODE_TYPE_USERDEF  (1<<5)
>  #define DRM_MODE_TYPE_DRIVER   (1<<6)
>
> -#define DRM_MODE_TYPE_ALL  (DRM_MODE_TYPE_BUILTIN |\
> -DRM_MODE_TYPE_CLOCK_C |\
> -DRM_MODE_TYPE_CRTC_C | \
> -DRM_MODE_TYPE_PREFERRED |  \
> -DRM_MODE_TYPE_DEFAULT |\
> +#define DRM_MODE_TYPE_ALL  (DRM_MODE_TYPE_PREFERRED |  \
>  DRM_MODE_TYPE_USERDEF |\
>  DRM_MODE_TYPE_DRIVER)
>
> --
> 2.13.6
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/selftests: Markup __iomem for igt_gem_coherency

2017-11-14 Thread Chris Wilson
Silence sparse warnings by using __iomem markup and io accessors.

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

diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c
index 35d778d70626..7a0d1e17c1ad 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c
@@ -33,7 +33,7 @@ static int cpu_set(struct drm_i915_gem_object *obj,
 {
unsigned int needs_clflush;
struct page *page;
-   typeof(v) *map;
+   u32 *map;
int err;
 
err = i915_gem_obj_prepare_shmem_write(obj, _clflush);
@@ -59,7 +59,7 @@ static int cpu_get(struct drm_i915_gem_object *obj,
 {
unsigned int needs_clflush;
struct page *page;
-   typeof(v) map;
+   u32 *map;
int err;
 
err = i915_gem_obj_prepare_shmem_read(obj, _clflush);
@@ -82,7 +82,7 @@ static int gtt_set(struct drm_i915_gem_object *obj,
   u32 v)
 {
struct i915_vma *vma;
-   typeof(v) *map;
+   u32 __iomem *map;
int err;
 
err = i915_gem_object_set_to_gtt_domain(obj, true);
@@ -98,7 +98,7 @@ static int gtt_set(struct drm_i915_gem_object *obj,
if (IS_ERR(map))
return PTR_ERR(map);
 
-   map[offset / sizeof(*map)] = v;
+   iowrite32(v, [offset / sizeof(*map)]);
i915_vma_unpin_iomap(vma);
 
return 0;
@@ -109,7 +109,7 @@ static int gtt_get(struct drm_i915_gem_object *obj,
   u32 *v)
 {
struct i915_vma *vma;
-   typeof(v) map;
+   u32 __iomem *map;
int err;
 
err = i915_gem_object_set_to_gtt_domain(obj, false);
@@ -125,7 +125,7 @@ static int gtt_get(struct drm_i915_gem_object *obj,
if (IS_ERR(map))
return PTR_ERR(map);
 
-   *v = map[offset / sizeof(*map)];
+   *v = ioread32([offset / sizeof(*map)]);
i915_vma_unpin_iomap(vma);
 
return 0;
@@ -135,7 +135,7 @@ static int wc_set(struct drm_i915_gem_object *obj,
  unsigned long offset,
  u32 v)
 {
-   typeof(v) *map;
+   u32 *map;
int err;
 
err = i915_gem_object_set_to_wc_domain(obj, true);
@@ -156,7 +156,7 @@ static int wc_get(struct drm_i915_gem_object *obj,
  unsigned long offset,
  u32 *v)
 {
-   typeof(v) map;
+   u32 *map;
int err;
 
err = i915_gem_object_set_to_wc_domain(obj, false);
-- 
2.15.0

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


Re: [Intel-gfx] [PATCH 07/10] drm/modes: Kill DRM_MODE_TYPE_CLOCK_CRTC_C define

2017-11-14 Thread Alex Deucher
On Tue, Nov 14, 2017 at 1:32 PM, Ville Syrjala
 wrote:
> From: Ville Syrjälä 
>
> No idea what the DRM_MODE_TYPE_CLOCK_CRTC_C define is supposed to
> achieve. Totally unused so kill if off.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Alex Deucher 

> ---
>  include/drm/drm_modes.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index 8ddf7adb98df..99dd815269e9 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -131,9 +131,6 @@ enum drm_mode_status {
> MODE_ERROR = -1
>  };
>
> -#define DRM_MODE_TYPE_CLOCK_CRTC_C (DRM_MODE_TYPE_CLOCK_C | \
> -   DRM_MODE_TYPE_CRTC_C)
> -
>  #define DRM_MODE(nm, t, c, hd, hss, hse, ht, hsk, vd, vss, vse, vt, vs, f) \
> .name = nm, .status = 0, .type = (t), .clock = (c), \
> .hdisplay = (hd), .hsync_start = (hss), .hsync_end = (hse), \
> --
> 2.13.6
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 06/10] drm/modes: Kill off the oddball DRM_MODE_TYPE_CRTC_C vs. DRM_MODE_TYPE_BUILTIN handling

2017-11-14 Thread Alex Deucher
On Tue, Nov 14, 2017 at 1:43 PM, Chris Wilson  wrote:
> Quoting Ville Syrjala (2017-11-14 18:32:54)
>> From: Ville Syrjälä 
>>
>> For some reason drm_mode_set_crtcinfo() does nothing of the mode has
> s/of/if/

With the typo fixed:
Reviewed-by: Alex Deucher 

>
>> the DRM_MODE_TYPE_BUILTIN flag set without the other bit from
>> DRM_MODE_TYPE_CRTC_C also set. I have zero idea what that is supposed
>> to achieve, but since we have no users for neither flag bit let's kill
>> this nonsense off.
>>
>> Signed-off-by: Ville Syrjälä 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


  1   2   3   >