Re: [Intel-gfx] mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

2019-07-04 Thread Andrew Morton
On Thu, 04 Jul 2019 22:22:41 -0700 Joe Perches  wrote:

> > So when comparing a zero-length file with a non-existent file, diff
> > produces no output.
> 
> Why use the -N option ?
> 
> $ diff --help
> [...]
>   -N, --new-file  treat absent files as empty
> 
> otherwise
> 
> $ cd $(mktemp -d -p .)
> $ touch x
> $ diff -u x y
> diff: y: No such file or directory

Without -N diff fails and exits with an error.  -N does what's desired
as long as the non-missing file isn't empty.


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for + diff-sucks.patch added to -mm tree

2019-07-04 Thread Patchwork
== Series Details ==

Series: + diff-sucks.patch added to -mm tree
URL   : https://patchwork.freedesktop.org/series/63251/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
cdf723d72139 + diff-sucks.patch added to -mm tree
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#22: 
*** Remember to use Documentation/process/submit-checklist.rst when testing 
your code ***

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

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

Re: [Intel-gfx] mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

2019-07-04 Thread Joe Perches
On Thu, 2019-07-04 at 22:09 -0700, Andrew Morton wrote:
> diff(1) doesn't seem to know how to handle a zero-length file.
> 
> y:/home/akpm> mkdir foo
> y:/home/akpm> cd foo
> y:/home/akpm/foo> touch x
> y:/home/akpm/foo> diff -uN x y
> y:/home/akpm/foo> date > x
> y:/home/akpm/foo> diff -uN x y
> --- x   2019-07-04 21:58:37.815028211 -0700
> +++ y   1969-12-31 16:00:00.0 -0800
> @@ -1 +0,0 @@
> -Thu Jul  4 21:58:37 PDT 2019
> 
> So when comparing a zero-length file with a non-existent file, diff
> produces no output.

Why use the -N option ?

$ diff --help
[...]
  -N, --new-file  treat absent files as empty

otherwise

$ cd $(mktemp -d -p .)
$ touch x
$ diff -u x y
diff: y: No such file or directory


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

2019-07-04 Thread Patchwork
== Series Details ==

Series: mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)
URL   : https://patchwork.freedesktop.org/series/63249/
State : failure

== Summary ==

Applying: mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)
error: sha1 information is lacking or useless (y).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

2019-07-04 Thread Andrew Morton
On Fri, 5 Jul 2019 13:14:35 +1000 Stephen Rothwell  
wrote:

> > I checked next-20190704 tag.
> > 
> > I see the empty file
> > drivers/gpu/drm/i915/oa/Makefile
> > 
> > Did someone delete it?
> 
> Commit
> 
>   5ed7a0cf3394 ("drm/i915: Move OA files to separate folder")
> 
> from the drm-intel tree seems to have created it as an empty file.

hrm.

diff(1) doesn't seem to know how to handle a zero-length file.

y:/home/akpm> mkdir foo
y:/home/akpm> cd foo
y:/home/akpm/foo> touch x
y:/home/akpm/foo> diff -uN x y
y:/home/akpm/foo> date > x
y:/home/akpm/foo> diff -uN x y
--- x   2019-07-04 21:58:37.815028211 -0700
+++ y   1969-12-31 16:00:00.0 -0800
@@ -1 +0,0 @@
-Thu Jul  4 21:58:37 PDT 2019

So when comparing a zero-length file with a non-existent file, diff
produces no output.


This'll make things happy.  And I guess it should be done to protect
all the valuable intellectual property in that file.

--- /dev/null
+++ a/drivers/gpu/drm/i915/oa/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
_

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

[Intel-gfx] + diff-sucks.patch added to -mm tree

2019-07-04 Thread akpm

The patch titled
 Subject: diff sucks
has been added to the -mm tree.  Its filename is
 diff-sucks.patch

This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/diff-sucks.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/diff-sucks.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
  reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing 
your code ***

The -mm tree is included into linux-next and is updated
there every 3-4 working days

--
From: Andrew Morton 
Subject: diff sucks

Cc: Masahiro Yamada 
Cc: Randy Dunlap 
Cc: Mark Brown 
Cc: Michal Wajdeczko 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Intel Graphics 
Cc: Chris Wilson 
Cc: Stephen Rothwell 
Signed-off-by: Andrew Morton 
---

 drivers/gpu/drm/i915/oa/Makefile |1 +
 1 file changed, 1 insertion(+)

--- /dev/null
+++ a/drivers/gpu/drm/i915/oa/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
_

Patches currently in -mm which might be from a...@linux-foundation.org are

scripts-spellingtxt-drop-sepc-from-the-misspelling-list-fix.patch
ocfs2-add-locking-filter-debugfs-file-fix.patch
ocfs2-clear-zero-in-unaligned-direct-io-checkpatch-fixes.patch
mm.patch
include-linux-pfn_th-remove-pfn_t_to_virt.patch
mm-swap-use-rbtree-for-swap_extent-fix.patch
mm-gup-speed-up-check_and_migrate_cma_pages-on-huge-page-fix.patch
mm-vmscanc-add-checks-for-incorrect-handling-of-current-reclaim_state.patch
proc-use-down_read_killable-mmap_sem-for-proc-pid-map_files-fix.patch
mm-oom_killer-add-task-uid-to-info-message-on-an-oom-kill-fix.patch
mm-thp-make-transhuge_vma_suitable-available-for-anonymous-thp-fix.patch
vmcore-add-a-kernel-parameter-novmcoredd-fix.patch
vmcore-add-a-kernel-parameter-novmcoredd-fix-fix.patch
rbtree-avoid-generating-code-twice-for-the-cached-versions-checkpatch-fixes.patch
coda-add-hinting-support-for-partial-file-caching-fix.patch
selftests-ptrace-add-a-test-case-for-ptrace_get_syscall_info-checkpatch-fixes.patch
resource-fix-locking-in-find_next_iomem_res-fix.patch
linux-next-rejects.patch
linux-next-git-rejects.patch
diff-sucks.patch
mm-section-numbers-use-the-type-unsigned-long-fix.patch
proc-sysctl-add-shared-variables-for-range-check-fix-2-fix.patch
proc-sysctl-add-shared-variables-for-range-check-fix-4.patch
drivers-tty-serial-sh-scic-suppress-warning.patch
kernel-forkc-export-kernel_thread-to-modules.patch

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Modular FIA

2019-07-04 Thread Patchwork
== Series Details ==

Series: Modular FIA
URL   : https://patchwork.freedesktop.org/series/63175/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6405_full -> Patchwork_13521_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@close-race:
- shard-skl:  [PASS][1] -> [DMESG-FAIL][2] ([fdo#111063])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-skl9/igt@gem_b...@close-race.html
- shard-iclb: [PASS][3] -> [DMESG-FAIL][4] ([fdo#111063])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb6/igt@gem_b...@close-race.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-iclb2/igt@gem_b...@close-race.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-iclb6/igt@gem_exec_balan...@smoke.html

  * igt@gem_pwrite@big-cpu-forwards:
- shard-apl:  [PASS][7] -> [INCOMPLETE][8] ([fdo#103927])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl5/igt@gem_pwr...@big-cpu-forwards.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-apl8/igt@gem_pwr...@big-cpu-forwards.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl6/igt@gem_workarou...@suspend-resume-context.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-apl3/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_selftest@mock_fence:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb6/igt@i915_selftest@mock_fence.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-iclb7/igt@i915_selftest@mock_fence.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][13] -> [FAIL][14] ([fdo#105767])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145] / [fdo#110403])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][19] -> [FAIL][20] ([fdo#108145])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][23] -> [FAIL][24] ([fdo#99912])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl4/igt@kms_setm...@basic.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-apl8/igt@kms_setm...@basic.html

  * igt@perf@blocking:
- shard-skl:  [PASS][25] -> [FAIL][26] ([fdo#110728])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl1/igt@p...@blocking.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13521/shard-skl10/igt@p...@blocking.html

  
 Possible 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: make new intel_tc.c use uncore accessors

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: make new intel_tc.c use uncore 
accessors
URL   : https://patchwork.freedesktop.org/series/63174/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6405_full -> Patchwork_13519_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-glk:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-glk7/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-glk9/igt@gem_b...@close-race.html

  * igt@i915_selftest@mock_requests:
- shard-skl:  [PASS][3] -> [DMESG-WARN][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@i915_selftest@mock_requests.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-skl1/igt@i915_selftest@mock_requests.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@close-race:
- shard-skl:  [PASS][5] -> [DMESG-FAIL][6] ([fdo#111063])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@gem_b...@close-race.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-skl1/igt@gem_b...@close-race.html

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

  * igt@gem_tiled_swapping@non-threaded:
- shard-glk:  [PASS][9] -> [DMESG-WARN][10] ([fdo#108686] / 
[fdo#110853])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-glk4/igt@gem_tiled_swapp...@non-threaded.html

  * igt@i915_suspend@debugfs-reader:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 
similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl8/igt@i915_susp...@debugfs-reader.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-apl6/igt@i915_susp...@debugfs-reader.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x128-sliding:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb8/igt@kms_cursor_...@pipe-c-cursor-128x128-sliding.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-iclb7/igt@kms_cursor_...@pipe-c-cursor-128x128-sliding.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([fdo#110741])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_flip@modeset-vs-vblank-race:
- shard-glk:  [PASS][17] -> [FAIL][18] ([fdo#103060])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-glk2/igt@kms_f...@modeset-vs-vblank-race.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-glk8/igt@kms_f...@modeset-vs-vblank-race.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13519/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  

Re: [Intel-gfx] mmotm 2019-07-04-15-01 uploaded (gpu/drm/i915/oa/)

2019-07-04 Thread Stephen Rothwell
Hi Masahiro,

On Fri, 5 Jul 2019 12:05:49 +0900 Masahiro Yamada 
 wrote:
>
> On Fri, Jul 5, 2019 at 10:09 AM Randy Dunlap  wrote:
> >
> > I get a lot of these but don't see/know what causes them:
> >
> > ../scripts/Makefile.build:42: ../drivers/gpu/drm/i915/oa/Makefile: No such 
> > file or directory
> > make[6]: *** No rule to make target '../drivers/gpu/drm/i915/oa/Makefile'.  
> > Stop.
> > ../scripts/Makefile.build:498: recipe for target 'drivers/gpu/drm/i915/oa' 
> > failed
> > make[5]: *** [drivers/gpu/drm/i915/oa] Error 2
> > ../scripts/Makefile.build:498: recipe for target 'drivers/gpu/drm/i915' 
> > failed
> >  
> 
> I checked next-20190704 tag.
> 
> I see the empty file
> drivers/gpu/drm/i915/oa/Makefile
> 
> Did someone delete it?

Commit

  5ed7a0cf3394 ("drm/i915: Move OA files to separate folder")

from the drm-intel tree seems to have created it as an empty file.

-- 
Cheers,
Stephen Rothwell


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Add support for DPLL4 (v10)

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/ehl: Add support for DPLL4 (v10)
URL   : https://patchwork.freedesktop.org/series/63171/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6405_full -> Patchwork_13517_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-snb:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-snb4/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-snb6/igt@gem_b...@close-race.html

  * igt@runner@aborted:
- shard-snb:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-snb6/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@close-race:
- shard-iclb: [PASS][4] -> [DMESG-FAIL][5] ([fdo#111063])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb6/igt@gem_b...@close-race.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-iclb7/igt@gem_b...@close-race.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][6] -> [DMESG-WARN][7] ([fdo#108566]) +5 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl6/igt@gem_workarou...@suspend-resume-context.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-apl3/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_pm_rpm@gem-execbuf-stress:
- shard-hsw:  [PASS][8] -> [INCOMPLETE][9] ([fdo#103540] / 
[fdo#107803] / [fdo#107807])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-hsw7/igt@i915_pm_...@gem-execbuf-stress.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-hsw8/igt@i915_pm_...@gem-execbuf-stress.html

  * igt@i915_suspend@sysfs-reader:
- shard-skl:  [PASS][10] -> [INCOMPLETE][11] ([fdo#104108])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl10/igt@i915_susp...@sysfs-reader.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-skl8/igt@i915_susp...@sysfs-reader.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  [PASS][12] -> [FAIL][13] ([fdo#105363])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@kms_f...@flip-vs-expired-vblank.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-skl:  [PASS][14] -> [INCOMPLETE][15] ([fdo#109507])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render:
- shard-iclb: [PASS][16] -> [FAIL][17] ([fdo#103167]) +1 similar 
issue
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-iclb: [PASS][18] -> [INCOMPLETE][19] ([fdo#107713] / 
[fdo#110042])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-iclb3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][20] -> [FAIL][21] ([fdo#108145])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13517/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_plane_lowres@pipe-a-tiling-y:
- shard-iclb: [PASS][22] -> [FAIL][23] ([fdo#103166])
   [22]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Random plane stuff

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Random plane stuff
URL   : https://patchwork.freedesktop.org/series/63165/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6405_full -> Patchwork_13515_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-iclb6/igt@gem_exec_balan...@smoke.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl6/igt@gem_workarou...@suspend-resume-context.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-apl4/igt@gem_workarou...@suspend-resume-context.html

  * igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding:
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb1/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-iclb7/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw:  [PASS][7] -> [FAIL][8] ([fdo#105767])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([fdo#103355])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-atomic-transitions.html

  * igt@kms_flip@flip-vs-suspend:
- shard-hsw:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103540])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-hsw5/igt@kms_f...@flip-vs-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-hsw8/igt@kms_f...@flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +3 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#108145])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +3 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-iclb3/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- shard-skl:  [PASS][21] -> [INCOMPLETE][22] ([fdo#104108])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl9/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13515/shard-skl9/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html

  
 Possible fixes 

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-apl:  [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +2 
similar issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl5/igt@kms_f...@flip-vs-suspend-interruptible.html
   [24]: 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/i915/gem: Defer obj->base.resv fini until RCU callback (rev2)

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [v2] drm/i915/gem: Defer obj->base.resv fini until 
RCU callback (rev2)
URL   : https://patchwork.freedesktop.org/series/63160/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6405_full -> Patchwork_13514_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@gem_tiled_swapping@non-threaded:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108686])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl4/igt@gem_tiled_swapp...@non-threaded.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html

  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-glk:  [PASS][5] -> [FAIL][6] ([fdo#105363])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-glk7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-glk8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw:  [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-hsw7/igt@kms_f...@flip-vs-suspend-interruptible.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +4 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl2/igt@kms_frontbuffer_track...@fbc-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-apl4/igt@kms_frontbuffer_track...@fbc-suspend.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +3 similar 
issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#108145] / [fdo#110403])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#108145])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html

  * igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +3 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-iclb7/igt@kms_psr@psr2_primary_mmap_cpu.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][19] -> [FAIL][20] ([fdo#99912])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl4/igt@kms_setm...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-apl8/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [DMESG-WARN][21] ([fdo#108566]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-apl5/igt@gem_...@in-flight-suspend.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13514/shard-apl7/igt@gem_...@in-flight-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite:
- shard-iclb: [FAIL][23] ([fdo#103167]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6405/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html
   [24]: 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915: Check caller held wakerefs in assert_forcewakes_active

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/4] drm/i915: Check caller held wakerefs in 
assert_forcewakes_active
URL   : https://patchwork.freedesktop.org/series/63151/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13512_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-glk:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk7/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-glk4/igt@gem_b...@close-race.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@gem_workarounds@suspend-resume:
- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([fdo#104108])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl8/igt@gem_workarou...@suspend-resume.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-skl3/igt@gem_workarou...@suspend-resume.html

  * igt@i915_pm_rpm@i2c:
- shard-hsw:  [PASS][7] -> [FAIL][8] ([fdo#104097])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw7/igt@i915_pm_...@i2c.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-hsw8/igt@i915_pm_...@i2c.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +4 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-apl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103166])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-iclb1/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][17] -> [FAIL][18] ([fdo#99912])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl1/igt@kms_setm...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-apl1/igt@kms_setm...@basic.html
- shard-kbl:  [PASS][19] -> [FAIL][20] ([fdo#99912])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl4/igt@kms_setm...@basic.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-kbl2/igt@kms_setm...@basic.html

  * igt@tools_test@tools_test:
- shard-glk:  [PASS][21] -> [SKIP][22] ([fdo#109271])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk7/igt@tools_test@tools_test.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13512/shard-glk8/igt@tools_test@tools_test.html

  
 Possible fixes 

  * igt@gem_busy@close-race:
- shard-skl:  [DMESG-FAIL][23] ([fdo#111063]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_b...@close-race.html
   [24]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/overlay: Stash the kernel context on initialisation (rev2)

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/overlay: Stash the kernel context 
on initialisation (rev2)
URL   : https://patchwork.freedesktop.org/series/63240/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6418 -> Patchwork_13537


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-guc: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-kbl-guc/igt@i915_selftest@live_hangcheck.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_close_race@basic-threads:
- fi-icl-u3:  [PASS][3] -> [INCOMPLETE][4] ([fdo#107713])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@gem_close_r...@basic-threads.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-icl-u3/igt@gem_close_r...@basic-threads.html

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@i915_pm_rpm@module-reload:
- fi-icl-dsi: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / 
[fdo#108840])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-dsi/igt@i915_pm_...@module-reload.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-icl-dsi/igt@i915_pm_...@module-reload.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7567u:   [PASS][9] -> [FAIL][10] ([fdo#109485])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-kbl-7567u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * {igt@gem_ctx_switch@legacy-render}:
- fi-icl-guc: [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-WARN][13] -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

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

  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485


Participating hosts (52 -> 47)
--

  Additional (3): fi-byt-j1900 fi-apl-guc fi-skl-6600u 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6418 -> Patchwork_13537

  CI_DRM_6418: 8749bcfaad7e8dad4f73c137223d4005d16bce23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5084: 9f45069f9b5136d07e053d8086e8df51e14332eb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13537: d86c8897351dc2d2d27825f774614109c86d6bf6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13537/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hangcheck: Look at instdone for all engines (rev2)

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/hangcheck: Look at instdone for all engines (rev2)
URL   : https://patchwork.freedesktop.org/series/61843/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13511_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-10ms:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([fdo#111055])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk8/igt@gem_...@in-flight-10ms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-glk9/igt@gem_...@in-flight-10ms.html

  * igt@gem_eio@in-flight-suspend:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl1/igt@gem_...@in-flight-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-apl6/igt@gem_...@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-iclb8/igt@gem_exec_balan...@smoke.html

  * igt@gem_softpin@noreloc-s3:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#103313])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl2/igt@gem_soft...@noreloc-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-kbl7/igt@gem_soft...@noreloc-s3.html

  * igt@i915_pm_rpm@i2c:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([fdo#104097])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw7/igt@i915_pm_...@i2c.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-hsw4/igt@i915_pm_...@i2c.html

  * igt@i915_pm_rpm@system-suspend-execbuf:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([fdo#104108] / 
[fdo#107807])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl8/igt@i915_pm_...@system-suspend-execbuf.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-skl1/igt@i915_pm_...@system-suspend-execbuf.html

  * igt@kms_flip@plain-flip-ts-check:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#100368])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl8/igt@kms_f...@plain-flip-ts-check.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-skl3/igt@kms_f...@plain-flip-ts-check.html

  * igt@kms_frontbuffer_tracking@fbc-badstride:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb8/igt@kms_frontbuffer_track...@fbc-badstride.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-iclb4/igt@kms_frontbuffer_track...@fbc-badstride.html

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- shard-skl:  [PASS][17] -> [INCOMPLETE][18] ([fdo#104108])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-skl9/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-x.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-iclb4/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-iclb8/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][25] -> [FAIL][26] ([fdo#99912])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl1/igt@kms_setm...@basic.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13511/shard-apl6/igt@kms_setm...@basic.html
- shard-kbl:  [PASS][27] -> [FAIL][28] ([fdo#99912])
   [27]: 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Show instdone for each engine in debugfs

2019-07-04 Thread Matthew Auld
On Thu, 4 Jul 2019 at 21:05, Chris Wilson  wrote:
>
> Although polling each engine quickly is preferable as it should give us
> a sample of each engine at roughly the same time, keep it simple and
> just sample the engine as print out the debug state.

as we

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_create: Show number of pages cleared

2019-07-04 Thread Matthew Auld
On Tue, 2 Jul 2019 at 19:58, Chris Wilson  wrote:
>
> Just a little bit of feedback at the end of an otherwise quiet 20s.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/selftests: Be engine agnostic

2019-07-04 Thread Chris Wilson
When using MI operations, we do not care which engine we use, so use
them all where possible, and where inconvenient double check we have the
engine we selected at random.

v2: Drop the local copy of engine->sseu to avoid an unchecked deref

Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   | 42 +++
 .../i915/gem/selftests/i915_gem_coherency.c   |  3 ++
 .../drm/i915/gem/selftests/i915_gem_context.c | 15 ---
 .../drm/i915/gem/selftests/i915_gem_mman.c| 25 ++-
 4 files changed, 59 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 2154cdee4ab3..86eed4c3ae2b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1422,6 +1422,9 @@ static int igt_ppgtt_pin_update(void *arg)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
unsigned int flags = PIN_USER | PIN_OFFSET_FIXED;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   unsigned int n;
int first, last;
int err;
 
@@ -1519,11 +1522,20 @@ static int igt_ppgtt_pin_update(void *arg)
 * land in the now stale 2M page.
 */
 
-   err = gpu_write(vma, ctx, dev_priv->engine[RCS0], 0, 0xdeadbeaf);
-   if (err)
-   goto out_unpin;
+   n = 0;
+   for_each_engine(engine, dev_priv, id) {
+   if (!intel_engine_can_store_dword(engine))
+   continue;
 
-   err = cpu_check(obj, 0, 0xdeadbeaf);
+   err = gpu_write(vma, ctx, engine, n++, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
+   while (n--) {
+   err = cpu_check(obj, n, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
 
 out_unpin:
i915_vma_unpin(vma);
@@ -1599,8 +1611,11 @@ static int igt_shrink_thp(void *arg)
struct drm_i915_private *i915 = ctx->i915;
struct i915_address_space *vm = ctx->vm ?: >ggtt.vm;
struct drm_i915_gem_object *obj;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
struct i915_vma *vma;
unsigned int flags = PIN_USER;
+   unsigned int n;
int err;
 
/*
@@ -1636,9 +1651,15 @@ static int igt_shrink_thp(void *arg)
if (err)
goto out_unpin;
 
-   err = gpu_write(vma, ctx, i915->engine[RCS0], 0, 0xdeadbeaf);
-   if (err)
-   goto out_unpin;
+   n = 0;
+   for_each_engine(engine, i915, id) {
+   if (!intel_engine_can_store_dword(engine))
+   continue;
+
+   err = gpu_write(vma, ctx, engine, n++, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
 
i915_vma_unpin(vma);
 
@@ -1663,7 +1684,12 @@ static int igt_shrink_thp(void *arg)
if (err)
goto out_close;
 
-   err = cpu_check(obj, 0, 0xdeadbeaf);
+   while (n--) {
+   err = cpu_check(obj, n, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
+
 
 out_unpin:
i915_vma_unpin(vma);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 8f22d3f18422..861f32be7d46 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -250,6 +250,9 @@ static bool needs_mi_store_dword(struct drm_i915_private 
*i915)
if (i915_terminally_wedged(i915))
return false;
 
+   if (!HAS_ENGINE(i915, RCS0))
+   return false;
+
return intel_engine_can_store_dword(i915->engine[RCS0]);
 }
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index a23c6df9b9f4..df1bf05dd106 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1019,7 +1019,6 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
   unsigned int flags)
 {
struct intel_engine_cs *engine = i915->engine[RCS0];
-   struct intel_sseu default_sseu = engine->sseu;
struct drm_i915_gem_object *obj;
struct i915_gem_context *ctx;
struct intel_context *ce;
@@ -1027,26 +1026,26 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
struct drm_file *file;
int ret;
 
-   if (INTEL_GEN(i915) < 9)
+   if (INTEL_GEN(i915) < 9 || !engine)
return 0;
 
if (!RUNTIME_INFO(i915)->sseu.has_slice_pg)
return 0;
 
-   if (hweight32(default_sseu.slice_mask) < 2)
+   if (hweight32(engine->sseu.slice_mask) < 2)
return 0;
 
/*
 * Gen11 VME friendly 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/overlay: Stash the kernel context on initialisation

2019-07-04 Thread Matthew Auld
On Thu, 4 Jul 2019 at 21:05, Chris Wilson  wrote:
>
> Simplify runtime request creation by storing the context we need to use
> during initialisation. This allows us to remove one more hardcoded
> engine lookup.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915/selftests: Be engine agnostic

2019-07-04 Thread Matthew Auld
On Thu, 4 Jul 2019 at 21:05, Chris Wilson  wrote:
>
> When using MI operations, we do not care which engine we use, so use
> them all where possible, and where inconvenient double check we have the
> engine we selected at random.
>
> Signed-off-by: Chris Wilson 



>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> index a23c6df9b9f4..ecb59f14ec01 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
> @@ -1027,7 +1027,7 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
> struct drm_file *file;
> int ret;
>
> -   if (INTEL_GEN(i915) < 9)
> +   if (INTEL_GEN(i915) < 9 || !engine)
> return 0;

We already dereferenced engine above.

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gtt: Mark the freed page table entries with scratch

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/gtt: Mark the freed page table entries with scratch
URL   : https://patchwork.freedesktop.org/series/63241/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6418 -> Patchwork_13536


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-x1275:   [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-x1275/igt@i915_selftest@live_hangcheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/fi-kbl-x1275/igt@i915_selftest@live_hangcheck.html

  * igt@runner@aborted:
- fi-kbl-x1275:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/fi-kbl-x1275/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_addfb_basic@bo-too-small:
- fi-icl-u3:  [PASS][4] -> [DMESG-WARN][5] ([fdo#107724])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@kms_addfb_ba...@bo-too-small.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/fi-icl-u3/igt@kms_addfb_ba...@bo-too-small.html

  
 Possible fixes 

  * {igt@gem_ctx_switch@legacy-render}:
- fi-icl-guc: [INCOMPLETE][6] ([fdo#107713]) -> [PASS][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html

  * igt@gem_exec_create@basic:
- fi-icl-u3:  [DMESG-WARN][8] ([fdo#107724]) -> [PASS][9] +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@gem_exec_cre...@basic.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/fi-icl-u3/igt@gem_exec_cre...@basic.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-WARN][10] -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

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

  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045


Participating hosts (52 -> 47)
--

  Additional (3): fi-byt-j1900 fi-apl-guc fi-skl-6600u 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6418 -> Patchwork_13536

  CI_DRM_6418: 8749bcfaad7e8dad4f73c137223d4005d16bce23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5084: 9f45069f9b5136d07e053d8086e8df51e14332eb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13536: 9ce6db8f4b00e73190b2f17037c3a8171a47b761 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

9ce6db8f4b00 drm/i915/gtt: Mark the freed page table entries with scratch

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13536/
___
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: Show support for accurate sw PMU busyness tracking

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Show support for accurate sw PMU busyness tracking
URL   : https://patchwork.freedesktop.org/series/63144/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13510_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@bcs0-s3:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#108566])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl3/igt@gem_ctx_isolat...@bcs0-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-apl7/igt@gem_ctx_isolat...@bcs0-s3.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@gem_softpin@noreloc-s3:
- shard-snb:  [PASS][5] -> [DMESG-WARN][6] ([fdo#102365])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-snb6/igt@gem_soft...@noreloc-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-snb7/igt@gem_soft...@noreloc-s3.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([fdo#104108])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl5/igt@gem_workarou...@suspend-resume-context.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-skl8/igt@gem_workarou...@suspend-resume-context.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][9] -> [DMESG-WARN][10] ([fdo#103313])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl7/igt@kms_f...@flip-vs-suspend-interruptible.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-kbl2/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_flip_tiling@flip-x-tiled:
- shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#108303])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb8/igt@kms_flip_til...@flip-x-tiled.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-iclb7/igt@kms_flip_til...@flip-x-tiled.html

  * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +8 similar 
issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-iclb6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103166])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-x.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-iclb4/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-iclb7/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
- shard-kbl:  [PASS][21] -> [FAIL][22] ([fdo#99912])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl4/igt@kms_setm...@basic.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-kbl1/igt@kms_setm...@basic.html

  * igt@tools_test@sysfs_l3_parity:
- shard-hsw:  [PASS][23] -> [SKIP][24] ([fdo#109271])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw5/igt@tools_test@sysfs_l3_parity.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-hsw7/igt@tools_test@sysfs_l3_parity.html

  
 Possible fixes 

  * igt@gem_busy@close-race:
- shard-skl:  [DMESG-FAIL][25] ([fdo#111063]) -> [PASS][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_b...@close-race.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13510/shard-skl10/igt@gem_b...@close-race.html
- shard-iclb: 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Drain the freedlists between exec passes

2019-07-04 Thread Matthew Auld
On Thu, 4 Jul 2019 at 17:53, Chris Wilson  wrote:
>
> During the context execution tests, we issue a lot of work and discard a
> lot of objects without releasing the lock and allowing the background
> reaper to free those objects. Insert a small break between each pass to
> flush the worker.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Mark the freed page table entries with scratch

2019-07-04 Thread Matthew Auld
On Thu, 4 Jul 2019 at 21:17, Chris Wilson  wrote:
>
> On unwinding the allocation error path and having freed the page table
> entry, it is imperative that we mark it as scratch.
>
> <4> [416.075569] general protection fault:  [#1] PREEMPT SMP PTI
> <4> [416.075801] CPU: 0 PID: 2385 Comm: kworker/u2:11 Tainted: G U
> 5.2.0-rc7-CI-Patchwork_13534+ #1
> <4> [416.076162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> <4> [416.076522] Workqueue: i915 __i915_vm_release [i915]
> <4> [416.076754] RIP: 0010:gen8_ppgtt_cleanup_3lvl+0x58/0xb0 [i915]
> <4> [416.077023] Code: 81 e2 04 fe ff ff 81 c2 ff 01 00 00 4c 8d 74 d6 58 4d 
> 8b 65 00 4d 3b a7 28 02 00 00 74 40 49 8d 5c 24 50 49 81 c4 50 10 00 00 <48> 
> 8b 2b 49 3b af 20 02 00 00 74 13 4c 89 ff 48 89 ee e8 01 fb ff
> <4> [416.077445] RSP: 0018:c946bd98 EFLAGS: 00010206
> <4> [416.077625] RAX: 0001 RBX: 6b6b6b6b6b6b6bbb RCX: 
> 8b4b56d5
> <4> [416.077838] RDX: 01ff RSI: 88805a578008 RDI: 
> 88805bd0efc8
> <4> [416.078167] RBP: 88805bd0efc8 R08: 04e42b93 R09: 
> 0001
> <4> [416.078381] R10:  R11: 888077a1b0b8 R12: 
> 6b6b6b6b6b6b7bbb
> <4> [416.078594] R13: 88805a578058 R14: 88805a579058 R15: 
> 88805bd0efc8
> <4> [416.078815] FS:  () GS:88807da0() 
> knlGS:
> <4> [416.079395] CS:  0010 DS:  ES:  CR0: 80050033
> <4> [416.079851] CR2: 56160fec2b14 CR3: 71bbc003 CR4: 
> 003606f0
> <4> [416.080388] Call Trace:
> <4> [416.080828]  gen8_ppgtt_cleanup+0x64/0x100 [i915]
> <4> [416.081399]  __i915_vm_release+0xfc/0x1d0 [i915]
>
> Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
> allocation")
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gtt: Mark the freed page table entries with scratch

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/gtt: Mark the freed page table entries with scratch
URL   : https://patchwork.freedesktop.org/series/63241/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
9ce6db8f4b00 drm/i915/gtt: Mark the freed page table entries with scratch
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#10: 
<4> [416.075801] CPU: 0 PID: 2385 Comm: kworker/u2:11 Tainted: G U  
  5.2.0-rc7-CI-Patchwork_13534+ #1

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

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/overlay: Stash the kernel context on initialisation

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/overlay: Stash the kernel context 
on initialisation
URL   : https://patchwork.freedesktop.org/series/63240/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6418 -> Patchwork_13535


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_basic@create-close:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1 
similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@gem_ba...@create-close.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/fi-icl-u3/igt@gem_ba...@create-close.html

  * igt@kms_busy@basic-flip-c:
- fi-skl-gvtdvm:  [PASS][3] -> [DMESG-WARN][4] ([fdo#105541])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-skl-gvtdvm/igt@kms_b...@basic-flip-c.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/fi-skl-gvtdvm/igt@kms_b...@basic-flip-c.html

  
 Possible fixes 

  * {igt@gem_ctx_switch@legacy-render}:
- fi-icl-guc: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/fi-icl-guc/igt@gem_ctx_swi...@legacy-render.html

  * igt@gem_exec_create@basic:
- fi-icl-u3:  [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@gem_exec_cre...@basic.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/fi-icl-u3/igt@gem_exec_cre...@basic.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-WARN][9] -> [PASS][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724


Participating hosts (52 -> 47)
--

  Additional (3): fi-byt-j1900 fi-apl-guc fi-skl-6600u 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6418 -> Patchwork_13535

  CI_DRM_6418: 8749bcfaad7e8dad4f73c137223d4005d16bce23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5084: 9f45069f9b5136d07e053d8086e8df51e14332eb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13535: 75611c6f9139c72f4884bd91cb97edf9d8da1390 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13535/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

75611c6f9139 drm/i915: Show instdone for each engine in debugfs
3e7907603299 drm/i915/selftests: Be engine agnostic
8f8e84cc4c9d drm/i915/overlay: Stash the kernel context on initialisation

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/gtt: Mark the freed page table entries with scratch

2019-07-04 Thread Chris Wilson
On unwinding the allocation error path and having freed the page table
entry, it is imperative that we mark it as scratch.

<4> [416.075569] general protection fault:  [#1] PREEMPT SMP PTI
<4> [416.075801] CPU: 0 PID: 2385 Comm: kworker/u2:11 Tainted: G U  
  5.2.0-rc7-CI-Patchwork_13534+ #1
<4> [416.076162] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
<4> [416.076522] Workqueue: i915 __i915_vm_release [i915]
<4> [416.076754] RIP: 0010:gen8_ppgtt_cleanup_3lvl+0x58/0xb0 [i915]
<4> [416.077023] Code: 81 e2 04 fe ff ff 81 c2 ff 01 00 00 4c 8d 74 d6 58 4d 8b 
65 00 4d 3b a7 28 02 00 00 74 40 49 8d 5c 24 50 49 81 c4 50 10 00 00 <48> 8b 2b 
49 3b af 20 02 00 00 74 13 4c 89 ff 48 89 ee e8 01 fb ff
<4> [416.077445] RSP: 0018:c946bd98 EFLAGS: 00010206
<4> [416.077625] RAX: 0001 RBX: 6b6b6b6b6b6b6bbb RCX: 
8b4b56d5
<4> [416.077838] RDX: 01ff RSI: 88805a578008 RDI: 
88805bd0efc8
<4> [416.078167] RBP: 88805bd0efc8 R08: 04e42b93 R09: 
0001
<4> [416.078381] R10:  R11: 888077a1b0b8 R12: 
6b6b6b6b6b6b7bbb
<4> [416.078594] R13: 88805a578058 R14: 88805a579058 R15: 
88805bd0efc8
<4> [416.078815] FS:  () GS:88807da0() 
knlGS:
<4> [416.079395] CS:  0010 DS:  ES:  CR0: 80050033
<4> [416.079851] CR2: 56160fec2b14 CR3: 71bbc003 CR4: 
003606f0
<4> [416.080388] Call Trace:
<4> [416.080828]  gen8_ppgtt_cleanup+0x64/0x100 [i915]
<4> [416.081399]  __i915_vm_release+0xfc/0x1d0 [i915]

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
allocation")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
Another day, another error path fix.
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9756f1b670e9..57db2d7270c5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1491,6 +1491,7 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space 
*vm,
spin_lock(>lock);
if (atomic_dec_and_test(>used)) {
gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
+   pdp->entry[pdpe] = vm->scratch_pd;
GEM_BUG_ON(!atomic_read(>used));
atomic_dec(>used);
GEM_BUG_ON(alloc);
@@ -1567,6 +1568,7 @@ static int gen8_ppgtt_alloc_4lvl(struct 
i915_address_space *vm,
spin_lock(>lock);
if (atomic_dec_and_test(>used)) {
gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
+   pml4->entry[pml4e] = vm->scratch_pdp;
GEM_BUG_ON(alloc);
alloc = pdp; /* defer the free until after the lock */
}
-- 
2.20.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Order assert forcewake test

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Order assert forcewake test
URL   : https://patchwork.freedesktop.org/series/63238/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6418 -> Patchwork_13534


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / 
[fdo#109100])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-icl-guc/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_render_linear_blits@basic:
- fi-icl-u3:  [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@gem_render_linear_bl...@basic.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-icl-u3/igt@gem_render_linear_bl...@basic.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#109485])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_exec_create@basic:
- fi-icl-u3:  [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1 
similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u3/igt@gem_exec_cre...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-icl-u3/igt@gem_exec_cre...@basic.html

  * igt@i915_selftest@live_hangcheck:
- fi-kbl-7500u:   [DMESG-WARN][11] -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-kbl-7500u/igt@i915_selftest@live_hangcheck.html

  * igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][13] ([fdo#111046 ]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6418/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111046 ]: https://bugs.freedesktop.org/show_bug.cgi?id=111046 


Participating hosts (52 -> 47)
--

  Additional (3): fi-byt-j1900 fi-apl-guc fi-skl-6600u 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6418 -> Patchwork_13534

  CI_DRM_6418: 8749bcfaad7e8dad4f73c137223d4005d16bce23 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5084: 9f45069f9b5136d07e053d8086e8df51e14332eb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13534: 6e21ad8c6118423e5b62cac1c8148be22b21cae4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13534/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 

[Intel-gfx] [PATCH 3/3] drm/i915: Show instdone for each engine in debugfs

2019-07-04 Thread Chris Wilson
Although polling each engine quickly is preferable as it should give us
a sample of each engine at roughly the same time, keep it simple and
just sample the engine as print out the debug state.

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

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index fa8ff2704b6e..3e4f58f19362 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1076,8 +1076,6 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct intel_engine_cs *engine;
-   u64 acthd[I915_NUM_ENGINES];
-   struct intel_instdone instdone;
intel_wakeref_t wakeref;
enum intel_engine_id id;
 
@@ -1092,13 +1090,6 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
return 0;
}
 
-   with_intel_runtime_pm(_priv->runtime_pm, wakeref) {
-   for_each_engine(engine, dev_priv, id)
-   acthd[id] = intel_engine_get_active_head(engine);
-
-   intel_engine_get_instdone(dev_priv->engine[RCS0], );
-   }
-
if (timer_pending(_priv->gpu_error.hangcheck_work.timer))
seq_printf(m, "Hangcheck active, timer fires in %dms\n",
   
jiffies_to_msecs(dev_priv->gpu_error.hangcheck_work.timer.expires -
@@ -1110,23 +1101,25 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
 
seq_printf(m, "GT active? %s\n", yesno(dev_priv->gt.awake));
 
-   for_each_engine(engine, dev_priv, id) {
-   seq_printf(m, "%s: %d ms ago\n",
-  engine->name,
-  jiffies_to_msecs(jiffies -
-   
engine->hangcheck.action_timestamp));
+   with_intel_runtime_pm(_priv->runtime_pm, wakeref) {
+   for_each_engine(engine, dev_priv, id) {
+   struct intel_instdone instdone;
 
-   seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
-  (long long)engine->hangcheck.acthd,
-  (long long)acthd[id]);
+   seq_printf(m, "%s: %d ms ago\n",
+  engine->name,
+  jiffies_to_msecs(jiffies -
+   
engine->hangcheck.action_timestamp));
 
-   if (engine->id == RCS0) {
-   seq_puts(m, "\tinstdone read =\n");
+   seq_printf(m, "\tACTHD = 0x%08llx [current 0x%08llx]\n",
+  (long long)engine->hangcheck.acthd,
+  intel_engine_get_active_head(engine));
+
+   intel_engine_get_instdone(engine, );
 
+   seq_puts(m, "\tinstdone read =\n");
i915_instdone_info(dev_priv, m, );
 
seq_puts(m, "\tinstdone accu =\n");
-
i915_instdone_info(dev_priv, m,
   >hangcheck.instdone);
}
-- 
2.20.1

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

[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Be engine agnostic

2019-07-04 Thread Chris Wilson
When using MI operations, we do not care which engine we use, so use
them all where possible, and where inconvenient double check we have the
engine we selected at random.

Signed-off-by: Chris Wilson 
---
 .../gpu/drm/i915/gem/selftests/huge_pages.c   | 42 +++
 .../i915/gem/selftests/i915_gem_coherency.c   |  3 ++
 .../drm/i915/gem/selftests/i915_gem_context.c |  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c| 25 ++-
 4 files changed, 53 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c 
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 2154cdee4ab3..86eed4c3ae2b 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1422,6 +1422,9 @@ static int igt_ppgtt_pin_update(void *arg)
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
unsigned int flags = PIN_USER | PIN_OFFSET_FIXED;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   unsigned int n;
int first, last;
int err;
 
@@ -1519,11 +1522,20 @@ static int igt_ppgtt_pin_update(void *arg)
 * land in the now stale 2M page.
 */
 
-   err = gpu_write(vma, ctx, dev_priv->engine[RCS0], 0, 0xdeadbeaf);
-   if (err)
-   goto out_unpin;
+   n = 0;
+   for_each_engine(engine, dev_priv, id) {
+   if (!intel_engine_can_store_dword(engine))
+   continue;
 
-   err = cpu_check(obj, 0, 0xdeadbeaf);
+   err = gpu_write(vma, ctx, engine, n++, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
+   while (n--) {
+   err = cpu_check(obj, n, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
 
 out_unpin:
i915_vma_unpin(vma);
@@ -1599,8 +1611,11 @@ static int igt_shrink_thp(void *arg)
struct drm_i915_private *i915 = ctx->i915;
struct i915_address_space *vm = ctx->vm ?: >ggtt.vm;
struct drm_i915_gem_object *obj;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
struct i915_vma *vma;
unsigned int flags = PIN_USER;
+   unsigned int n;
int err;
 
/*
@@ -1636,9 +1651,15 @@ static int igt_shrink_thp(void *arg)
if (err)
goto out_unpin;
 
-   err = gpu_write(vma, ctx, i915->engine[RCS0], 0, 0xdeadbeaf);
-   if (err)
-   goto out_unpin;
+   n = 0;
+   for_each_engine(engine, i915, id) {
+   if (!intel_engine_can_store_dword(engine))
+   continue;
+
+   err = gpu_write(vma, ctx, engine, n++, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
 
i915_vma_unpin(vma);
 
@@ -1663,7 +1684,12 @@ static int igt_shrink_thp(void *arg)
if (err)
goto out_close;
 
-   err = cpu_check(obj, 0, 0xdeadbeaf);
+   while (n--) {
+   err = cpu_check(obj, n, 0xdeadbeaf);
+   if (err)
+   goto out_unpin;
+   }
+
 
 out_unpin:
i915_vma_unpin(vma);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 8f22d3f18422..861f32be7d46 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -250,6 +250,9 @@ static bool needs_mi_store_dword(struct drm_i915_private 
*i915)
if (i915_terminally_wedged(i915))
return false;
 
+   if (!HAS_ENGINE(i915, RCS0))
+   return false;
+
return intel_engine_can_store_dword(i915->engine[RCS0]);
 }
 
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index a23c6df9b9f4..ecb59f14ec01 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -1027,7 +1027,7 @@ __igt_ctx_sseu(struct drm_i915_private *i915,
struct drm_file *file;
int ret;
 
-   if (INTEL_GEN(i915) < 9)
+   if (INTEL_GEN(i915) < 9 || !engine)
return 0;
 
if (!RUNTIME_INFO(i915)->sseu.has_slice_pg)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index 9b05bef15023..b95fdc2b6bfc 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -328,7 +328,8 @@ next_tiling: ;
 static int make_obj_busy(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct i915_request *rq;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
struct i915_vma *vma;
int err;
 
@@ -340,17 +341,21 @@ static int make_obj_busy(struct 

[Intel-gfx] [PATCH 1/3] drm/i915/overlay: Stash the kernel context on initialisation

2019-07-04 Thread Chris Wilson
Simplify runtime request creation by storing the context we need to use
during initialisation. This allows us to remove one more hardcoded
engine lookup.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/display/intel_overlay.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c 
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 21339b7f6a3e..07929726b780 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -175,6 +175,7 @@ struct overlay_registers {
 
 struct intel_overlay {
struct drm_i915_private *i915;
+   struct intel_context *context;
struct intel_crtc *crtc;
struct i915_vma *vma;
struct i915_vma *old_vma;
@@ -239,9 +240,7 @@ static int intel_overlay_do_wait_request(struct 
intel_overlay *overlay,
 
 static struct i915_request *alloc_request(struct intel_overlay *overlay)
 {
-   struct intel_engine_cs *engine = overlay->i915->engine[RCS0];
-
-   return i915_request_create(engine->kernel_context);
+   return i915_request_create(overlay->context);
 }
 
 /* overlay needs to be disable in OCMD reg */
@@ -1359,11 +1358,16 @@ void intel_overlay_setup(struct drm_i915_private 
*dev_priv)
if (!HAS_OVERLAY(dev_priv))
return;
 
+   if (!HAS_ENGINE(dev_priv, RCS0))
+   return;
+
overlay = kzalloc(sizeof(*overlay), GFP_KERNEL);
if (!overlay)
return;
 
overlay->i915 = dev_priv;
+   overlay->context = dev_priv->engine[RCS0]->kernel_context;
+   GEM_BUG_ON(!overlay->context);
 
overlay->color_key = 0x0101fe;
overlay->color_key_enabled = true;
-- 
2.20.1

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

[Intel-gfx] [PATCH] drm/i915: Order assert forcewake test

2019-07-04 Thread Chris Wilson
Read the current value before computing the expected to ensure that if
the timer does complete early (against our will), it should not cause a
false positive.

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

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2042c94c9cc9..c83bfaae377f 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -760,14 +760,15 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
 */
local_irq_disable();
for_each_fw_domain_masked(domain, fw_domains, uncore, tmp) {
+   unsigned int actual = READ_ONCE(domain->wake_count);
unsigned int expect = 1;
 
if (hrtimer_active(>timer) && READ_ONCE(domain->active))
expect++; /* pending automatic release */
 
-   if (WARN(domain->wake_count < expect,
+   if (WARN(actual < expect,
 "Expected domain %d to be held awake by caller, 
count=%d\n",
-domain->id, domain->wake_count))
+domain->id, actual))
break;
}
local_irq_enable();
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: fix include order in intel_tc.*

2019-07-04 Thread Imre Deak
On Thu, Jul 04, 2019 at 07:56:09PM +0200, Michal Wajdeczko wrote:
> On Thu, 04 Jul 2019 19:43:12 +0200, Imre Deak  wrote:
> 
> > On Thu, Jul 04, 2019 at 07:21:38PM +0200, Michal Wajdeczko wrote:
> > > On Thu, 04 Jul 2019 02:06:47 +0200, Lucas De Marchi
> > >  wrote:
> > > 
> > > > Make intel_tc.h the first include so we guarantee it's self-contained.
> > > > Sort the rest. Same principle applies for includes in the header.
> > > >
> > > > Signed-off-by: Lucas De Marchi 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_tc.c | 5 +++--
> > > >  drivers/gpu/drm/i915/display/intel_tc.h | 5 +++--
> > > >  2 files changed, 6 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > index 1a9dd32fb0a5..e6e6163c1232 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > > @@ -3,10 +3,11 @@
> > > >   * Copyright © 2019 Intel Corporation
> > > >   */
> > > > +#include "intel_tc.h"
> > > > +
> > > > +#include "i915_drv.h"
> > > 
> > > this master header will likely include everything, so while
> > > your .h is now self-contained, .c remains unclean
> > > 
> > > >  #include "intel_display.h"
> > > >  #include "intel_dp_mst.h"
> > > > -#include "i915_drv.h"
> > > > -#include "intel_tc.h"
> > > > static const char *tc_port_mode_name(enum tc_port_mode mode)
> > > >  {
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> > > > b/drivers/gpu/drm/i915/display/intel_tc.h
> > > > index 0d8411d4a91d..45ae30537b78 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_tc.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> > > > @@ -6,10 +6,11 @@
> > > >  #ifndef __INTEL_TC_H__
> > > >  #define __INTEL_TC_H__
> > > > -#include 
> > > > -#include 
> > > >  #include "intel_drv.h"
> > > 
> > > are you sure you want this giant header to be included here?
> > > note that it will #include almost everything (i915_drv.h too)
> > > and may introduce hard to resolve circular dependencies
> > > 
> > > > +#include 
> > > 
> > > we don't need mutex definitions here in current header file
> > > 
> > > > +#include 
> > > > +
> > > 
> > > so you need only above types.h and then add forward decl for:
> > > 
> > > struct intel_digital_port;
> > 
> > Both the mutex and intel_digital_port definitions are needed by
> > intel_tc_port_ref_held() in this header.
> 
> oops, sorry, didn't scroll down to see intel_tc_port_ref_held() inline.
> 
> but wait, it is used only once in intel_display_power.c so
> maybe this inline can be moved to one of the .c file ?

Imo a simple function is ok as inline and it should be defined with the
rest of TypeC functions.

> also, maybe it's time to move struct intel_digital_port definition
> out of intel_drv.h ?

Not sure what would be a good division, it's used by a few
platforms/output types. But yea, sounds like a good idea as a follow-up.

>
> > > 
> > > >  bool intel_tc_port_connected(struct intel_digital_port *dig_port);
> > > >  u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
> > > >  int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > > > *dig_port);
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Dump w/a lists on all engines (rev2)

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Dump w/a lists on all engines 
(rev2)
URL   : https://patchwork.freedesktop.org/series/63140/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6417 -> Patchwork_13533


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_workarounds@basic-read:
- fi-icl-dsi: [PASS][1] -> [SKIP][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-dsi/igt@gem_workarou...@basic-read.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-icl-dsi/igt@gem_workarou...@basic-read.html
- fi-cml-u2:  [PASS][3] -> [SKIP][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-cml-u2/igt@gem_workarou...@basic-read.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-cml-u2/igt@gem_workarou...@basic-read.html
- fi-cml-u:   [PASS][5] -> [SKIP][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-cml-u/igt@gem_workarou...@basic-read.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-cml-u/igt@gem_workarou...@basic-read.html
- fi-icl-u3:  [PASS][7] -> [SKIP][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-u3/igt@gem_workarou...@basic-read.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-icl-u3/igt@gem_workarou...@basic-read.html
- fi-icl-u2:  [PASS][9] -> [SKIP][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-u2/igt@gem_workarou...@basic-read.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-icl-u2/igt@gem_workarou...@basic-read.html

  
 Warnings 

  * igt@gem_workarounds@basic-read:
- fi-hsw-4770r:   [SKIP][11] ([fdo#109271]) -> [FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-hsw-4770r/igt@gem_workarou...@basic-read.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-hsw-4770r/igt@gem_workarou...@basic-read.html
- fi-snb-2600:[SKIP][13] ([fdo#109271]) -> [FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-snb-2600/igt@gem_workarou...@basic-read.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-snb-2600/igt@gem_workarou...@basic-read.html
- fi-ivb-3770:[SKIP][15] ([fdo#109271]) -> [FAIL][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-ivb-3770/igt@gem_workarou...@basic-read.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-ivb-3770/igt@gem_workarou...@basic-read.html
- fi-byt-n2820:   [SKIP][17] ([fdo#109271]) -> [FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-byt-n2820/igt@gem_workarou...@basic-read.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-byt-n2820/igt@gem_workarou...@basic-read.html
- fi-hsw-4770:[SKIP][19] ([fdo#109271]) -> [FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-hsw-4770/igt@gem_workarou...@basic-read.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-hsw-4770/igt@gem_workarou...@basic-read.html
- fi-byt-j1900:   [SKIP][21] ([fdo#109271]) -> [FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-byt-j1900/igt@gem_workarou...@basic-read.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-byt-j1900/igt@gem_workarou...@basic-read.html
- fi-gdg-551: [SKIP][23] ([fdo#109271]) -> [FAIL][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-gdg-551/igt@gem_workarou...@basic-read.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-gdg-551/igt@gem_workarou...@basic-read.html
- fi-blb-e6850:   [SKIP][25] ([fdo#109271]) -> [FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-blb-e6850/igt@gem_workarou...@basic-read.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-blb-e6850/igt@gem_workarou...@basic-read.html
- fi-elk-e7500:   [SKIP][27] ([fdo#109271]) -> [FAIL][28]
   [27]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-elk-e7500/igt@gem_workarou...@basic-read.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13533/fi-elk-e7500/igt@gem_workarou...@basic-read.html
- 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Drain the freedlists between exec passes

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Drain the freedlists between exec passes
URL   : https://patchwork.freedesktop.org/series/63233/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6417 -> Patchwork_13532


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13532/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_mmap_gtt@basic-write:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-u3/igt@gem_mmap_...@basic-write.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13532/fi-icl-u3/igt@gem_mmap_...@basic-write.html

  
 Possible fixes 

  * igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm:  [DMESG-FAIL][3] ([fdo#111056]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13532/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][5] ([fdo#109635 ]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13532/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-bxt-dsi/igt@kms_f...@basic-flip-vs-dpms.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13532/fi-bxt-dsi/igt@kms_f...@basic-flip-vs-dpms.html

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

  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#111056]: https://bugs.freedesktop.org/show_bug.cgi?id=111056


Participating hosts (55 -> 45)
--

  Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq 
fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-icl-y fi-icl-dsi fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6417 -> Patchwork_13532

  CI_DRM_6417: 913b87462bcd3c69df2d1ba44d7a9055a49c5dff @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5083: 4d710ea530aca69304df37191802476f406746ca @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13532: 60660d2b4fcf8ccb494c78519db3de03d45c7cf4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13532/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

60660d2b4fcf drm/i915/selftests: Drain the freedlists between exec passes

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Dump w/a lists on all engines (rev2)

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Dump w/a lists on all engines 
(rev2)
URL   : https://patchwork.freedesktop.org/series/63140/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ed6225abf6d0 drm/i915: Dump w/a lists on all engines
-:48: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#48: FILE: drivers/gpu/drm/i915/i915_debugfs.c:2983:
+   seq_printf(m, "\n");

total: 0 errors, 1 warnings, 0 checks, 35 lines checked
2ef3c37cd666 drm/i915/gt: Pull engine w/a initialisation into common

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

Re: [Intel-gfx] [PATCH v7 10/11] drm/hdcp: update content protection property with uevent

2019-07-04 Thread Ramalingam C
On 2019-07-04 at 14:14:19 +0300, Pekka Paalanen wrote:
> On Tue,  7 May 2019 21:57:44 +0530
> Ramalingam C  wrote:
> 
> > drm function is defined and exported to update a connector's
> > content protection property state and to generate a uevent along
> > with it.
> > 
> > Need ACK for the uevent from userspace consumer.
> > 
> > v2:
> >   Update only when state is different from old one.
> > v3:
> >   KDoc is added [Daniel]
> > 
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_hdcp.c | 32 
> >  include/drm/drm_hdcp.h |  2 ++
> >  2 files changed, 34 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> > index 75402463466b..f29b7abda51f 100644
> > --- a/drivers/gpu/drm/drm_hdcp.c
> > +++ b/drivers/gpu/drm/drm_hdcp.c
> > @@ -372,6 +372,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
> >   *
> >   * The content protection will be set to 
> > _connector_state.content_protection
> >   *
> > + * When kernel triggered content protection state change like 
> > DESIRED->ENABLED
> > + * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to 
> > update
> > + * the content protection state of a connector.
Here we indicated that drm_hdcp_update_content_protection() used for
kernel triggered content protection state change.
> > + *
> >   * Returns:
> >   * Zero on success, negative errno on failure.
> >   */
> > @@ -412,3 +416,31 @@ int drm_connector_attach_content_protection_property(
> > return 0;
> >  }
> >  EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
> > +
> > +/**
> > + * drm_hdcp_update_content_protection - Updates the content protection 
> > state
> > + * of a connector
> > + *
> > + * @connector: drm_connector on which content protection state needs an 
> > update
> > + * @val: New state of the content protection property
> > + *
> > + * This function can be used by display drivers, to update the kernel 
> > triggered
> > + * content protection state change of a drm_connector.This function update 
> > the
These lines also indicate that this function is used for kernel
triggered content protection state change of a drm_connector.

-Ram
> > + * new state of the property into the connector's state and generate an 
> > uevent
> > + * to notify the userspace.
> > + */
> > +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> > +   u64 val)
> > +{
> 
> Hi,
> 
> don't you need to ensure that 'val' cannot be UNDESIRED?
@ https://patchwork.freedesktop.org/patch/303909/?series=57232=9
caller(I915) of this function is ensuring that.

-Ram
> 
> > +   struct drm_device *dev = connector->dev;
> > +   struct drm_connector_state *state = connector->state;
> > +
> > +   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> > +   if (state->content_protection == val)
> > +   return;
> > +
> > +   state->content_protection = val;
> > +   drm_sysfs_connector_status_event(connector,
> > +dev->mode_config.content_protection_property);
> > +}
> > +EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> > diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> > index 2970abdfaf12..dd864ac9ce85 100644
> > --- a/include/drm/drm_hdcp.h
> > +++ b/include/drm/drm_hdcp.h
> > @@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
> >  u8 *ksvs, u32 ksv_count);
> >  int drm_connector_attach_content_protection_property(
> > struct drm_connector *connector, bool hdcp_content_type);
> > +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> > +   u64 val);
> >  #endif
> 
> This patch is missing all UAPI documentation.
> 
> Particularly important is the detail that the kernel will not send an
> event corresponding to userspace explicitly setting "Content
> Protection" to "Undesired". That is what you explained to me in the
> Weston MR !48, but I don't actually see it in the code here. It would
> be best to enforce that in the shared DRM code.
> 
> 
> Thanks,
> pq


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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: fix include order in intel_tc.*

2019-07-04 Thread Michal Wajdeczko

On Thu, 04 Jul 2019 19:43:12 +0200, Imre Deak  wrote:


On Thu, Jul 04, 2019 at 07:21:38PM +0200, Michal Wajdeczko wrote:

On Thu, 04 Jul 2019 02:06:47 +0200, Lucas De Marchi
 wrote:

> Make intel_tc.h the first include so we guarantee it's self-contained.
> Sort the rest. Same principle applies for includes in the header.
>
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 5 +++--
>  drivers/gpu/drm/i915/display/intel_tc.h | 5 +++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 1a9dd32fb0a5..e6e6163c1232 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -3,10 +3,11 @@
>   * Copyright © 2019 Intel Corporation
>   */
> +#include "intel_tc.h"
> +
> +#include "i915_drv.h"

this master header will likely include everything, so while
your .h is now self-contained, .c remains unclean

>  #include "intel_display.h"
>  #include "intel_dp_mst.h"
> -#include "i915_drv.h"
> -#include "intel_tc.h"
> static const char *tc_port_mode_name(enum tc_port_mode mode)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> b/drivers/gpu/drm/i915/display/intel_tc.h
> index 0d8411d4a91d..45ae30537b78 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.h
> +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> @@ -6,10 +6,11 @@
>  #ifndef __INTEL_TC_H__
>  #define __INTEL_TC_H__
> -#include 
> -#include 
>  #include "intel_drv.h"

are you sure you want this giant header to be included here?
note that it will #include almost everything (i915_drv.h too)
and may introduce hard to resolve circular dependencies

> +#include 

we don't need mutex definitions here in current header file

> +#include 
> +

so you need only above types.h and then add forward decl for:

struct intel_digital_port;


Both the mutex and intel_digital_port definitions are needed by
intel_tc_port_ref_held() in this header.


oops, sorry, didn't scroll down to see intel_tc_port_ref_held() inline.

but wait, it is used only once in intel_display_power.c so
maybe this inline can be moved to one of the .c file ?

also, maybe it's time to move struct intel_digital_port definition
out of intel_drv.h ?





>  bool intel_tc_port_connected(struct intel_digital_port *dig_port);
>  u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
>  int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> *dig_port);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gtt: pde entry encoding is identical

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
URL   : https://patchwork.freedesktop.org/series/63229/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6417 -> Patchwork_13531


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_create@basic-files:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / 
[fdo#109100])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html

  * igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850:   [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html

  * igt@i915_selftest@live_contexts:
- fi-skl-iommu:   [PASS][5] -> [INCOMPLETE][6] ([fdo#111050])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-skl-iommu/igt@i915_selftest@live_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-skl-iommu/igt@i915_selftest@live_contexts.html

  * igt@i915_selftest@live_hangcheck:
- fi-icl-u3:  [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / 
[fdo#108569])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-icl-u3/igt@i915_selftest@live_hangcheck.html

  * igt@prime_vgem@basic-busy-default:
- fi-icl-u3:  [PASS][9] -> [DMESG-WARN][10] ([fdo#107724])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-icl-u3/igt@prime_v...@basic-busy-default.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-icl-u3/igt@prime_v...@basic-busy-default.html

  
 Possible fixes 

  * igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm:  [DMESG-FAIL][11] ([fdo#111056]) -> [PASS][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html

  * igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u:   [FAIL][13] ([fdo#109635 ]) -> [PASS][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html

  * igt@kms_flip@basic-flip-vs-dpms:
- fi-bxt-dsi: [INCOMPLETE][15] ([fdo#103927]) -> [PASS][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6417/fi-bxt-dsi/igt@kms_f...@basic-flip-vs-dpms.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/fi-bxt-dsi/igt@kms_f...@basic-flip-vs-dpms.html

  
  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
  [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635 
  [fdo#111050]: https://bugs.freedesktop.org/show_bug.cgi?id=111050
  [fdo#111056]: https://bugs.freedesktop.org/show_bug.cgi?id=111056


Participating hosts (55 -> 47)
--

  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6417 -> Patchwork_13531

  CI_DRM_6417: 913b87462bcd3c69df2d1ba44d7a9055a49c5dff @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5083: 4d710ea530aca69304df37191802476f406746ca @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13531: ecf8477bcfc1cc28e3fa459db02f11c45a4c2ecb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13531/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: fix include order in intel_tc.*

2019-07-04 Thread Imre Deak
On Thu, Jul 04, 2019 at 07:21:38PM +0200, Michal Wajdeczko wrote:
> On Thu, 04 Jul 2019 02:06:47 +0200, Lucas De Marchi
>  wrote:
> 
> > Make intel_tc.h the first include so we guarantee it's self-contained.
> > Sort the rest. Same principle applies for includes in the header.
> > 
> > Signed-off-by: Lucas De Marchi 
> > ---
> >  drivers/gpu/drm/i915/display/intel_tc.c | 5 +++--
> >  drivers/gpu/drm/i915/display/intel_tc.h | 5 +++--
> >  2 files changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index 1a9dd32fb0a5..e6e6163c1232 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -3,10 +3,11 @@
> >   * Copyright © 2019 Intel Corporation
> >   */
> > +#include "intel_tc.h"
> > +
> > +#include "i915_drv.h"
> 
> this master header will likely include everything, so while
> your .h is now self-contained, .c remains unclean
> 
> >  #include "intel_display.h"
> >  #include "intel_dp_mst.h"
> > -#include "i915_drv.h"
> > -#include "intel_tc.h"
> > static const char *tc_port_mode_name(enum tc_port_mode mode)
> >  {
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> > b/drivers/gpu/drm/i915/display/intel_tc.h
> > index 0d8411d4a91d..45ae30537b78 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> > @@ -6,10 +6,11 @@
> >  #ifndef __INTEL_TC_H__
> >  #define __INTEL_TC_H__
> > -#include 
> > -#include 
> >  #include "intel_drv.h"
> 
> are you sure you want this giant header to be included here?
> note that it will #include almost everything (i915_drv.h too)
> and may introduce hard to resolve circular dependencies
> 
> > +#include 
> 
> we don't need mutex definitions here in current header file
> 
> > +#include 
> > +
> 
> so you need only above types.h and then add forward decl for:
> 
> struct intel_digital_port;

Both the mutex and intel_digital_port definitions are needed by 
intel_tc_port_ref_held() in this header.

> 
> >  bool intel_tc_port_connected(struct intel_digital_port *dig_port);
> >  u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
> >  int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > *dig_port);
> ___
> 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 v7 09/11] drm: uevent for connector status change

2019-07-04 Thread Ramalingam C
On 2019-07-04 at 14:12:27 +0300, Pekka Paalanen wrote:
> On Tue,  7 May 2019 21:57:43 +0530
> Ramalingam C  wrote:
> 
> > DRM API for generating uevent for a status changes of connector's
> > property.
> > 
> > This uevent will have following details related to the status change:
> > 
> >   HOTPLUG=1, CONNECTOR= and PROPERTY=
> > 
> > Need ACK from this uevent from userspace consumer.
> > 
> > v2:
> >   Minor fixes at KDoc comments [Daniel]
> > v3:
> >   Check the property is really attached with connector [Daniel]
> > 
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_sysfs.c | 35 +++
> >  include/drm/drm_sysfs.h |  5 -
> >  2 files changed, 39 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> > index 18b1ac442997..63fa951a20db 100644
> > --- a/drivers/gpu/drm/drm_sysfs.c
> > +++ b/drivers/gpu/drm/drm_sysfs.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >  #include "drm_internal.h"
> > +#include "drm_crtc_internal.h"
> >  
> >  #define to_drm_minor(d) dev_get_drvdata(d)
> >  #define to_drm_connector(d) dev_get_drvdata(d)
> > @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> >   * Send a uevent for the DRM device specified by @dev.  Currently we only
> >   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> >   * deal with other types of events.
> > + *
> > + * Any new uapi should be using the drm_sysfs_connector_status_event()
> > + * for uevents on connector status change.
> >   */
> >  void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  {
> > @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> >  }
> >  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
> >  
> > +/**
> > + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> > + * property status change
> > + * @connector: connector on which property status changed
> > + * @property: connector property whoes status changed.
> > + *
> > + * Send a uevent for the DRM device specified by @dev.  Currently we
> > + * set HOTPLUG=1 and connector id along with the attached property id
> > + * related to the status change.
> > + */
This is the kernel doc added for drm_sysfs_connector_status_event()
similar to drm_sysfs_hotplug_event()

-Ram
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > + struct drm_property *property)
> > +{
> > +   struct drm_device *dev = connector->dev;
> > +   char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> > +   char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> > +
> > +   WARN_ON(!drm_mode_obj_find_prop_id(>base,
> > +  property->base.id));
> > +
> > +   snprintf(conn_id, ARRAY_SIZE(conn_id),
> > +"CONNECTOR=%u", connector->base.id);
> > +   snprintf(prop_id, ARRAY_SIZE(prop_id),
> > +"PROPERTY=%u", property->base.id);
> > +
> > +   DRM_DEBUG("generating connector status event\n");
> > +
> > +   kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
> > +}
> > +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> > +
> >  static void drm_sysfs_release(struct device *dev)
> >  {
> > kfree(dev);
> > diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> > index 4f311e836cdc..d454ef617b2c 100644
> > --- a/include/drm/drm_sysfs.h
> > +++ b/include/drm/drm_sysfs.h
> > @@ -4,10 +4,13 @@
> >  
> >  struct drm_device;
> >  struct device;
> > +struct drm_connector;
> > +struct drm_property;
> >  
> >  int drm_class_device_register(struct device *dev);
> >  void drm_class_device_unregister(struct device *dev);
> >  
> >  void drm_sysfs_hotplug_event(struct drm_device *dev);
> > -
> > +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> > + struct drm_property *property);
> >  #endif
> 
> Hi,
> 
> this patch is completely missing the UAPI documentation.
> 
> Weston in
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
> does have good looking code to parse this event.
> 
> 
> Thanks,
> pq


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

Re: [Intel-gfx] [PATCH v7 07/11] drm: Add Content protection type property

2019-07-04 Thread Ramalingam C
On 2019-07-04 at 14:11:59 +0300, Pekka Paalanen wrote:
> On Tue,  7 May 2019 21:57:41 +0530
> Ramalingam C  wrote:
> 
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentication.
> > 
> > Type of the stream is decided by the protected content providers.
> > Type 0 content can be rendered on any HDCP protected display wires.
> > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > 
> > So when a userspace sets this property to Type 1 and starts the HDCP
> > enable, kernel will honour it only if HDCP2.2 authentication is through
> > for type 1. Else HDCP enable will be failed.
> > 
> > Need ACK for this new conenctor property from userspace consumer.
> > 
> > v2:
> >   cp_content_type is replaced with content_protection_type [daniel]
> >   check at atomic_set_property is removed [Maarten]
> > v3:
> >   %s/content_protection_type/hdcp_content_type [Pekka]
> > v4:
> >   property is created for the first requested connector and then reused.
> > [Danvet]
> > v5:
> >   kernel doc nits addressed [Daniel]
> >   Rebased as part of patch reordering.
> > 
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_atomic_uapi.c |  4 
> >  drivers/gpu/drm/drm_connector.c   | 18 
> >  drivers/gpu/drm/drm_hdcp.c| 36 ++-
> >  drivers/gpu/drm/i915/intel_hdcp.c |  4 +++-
> >  include/drm/drm_connector.h   |  7 ++
> >  include/drm/drm_hdcp.h|  2 +-
> >  include/drm/drm_mode_config.h |  6 ++
> >  include/uapi/drm/drm_mode.h   |  4 
> >  8 files changed, 78 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 4131e669785a..a85f3ccfe699 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -738,6 +738,8 @@ static int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> > return -EINVAL;
> > }
> > state->content_protection = val;
> > +   } else if (property == config->hdcp_content_type_property) {
> > +   state->hdcp_content_type = val;
> > } else if (property == connector->colorspace_property) {
> > state->colorspace = val;
> > } else if (property == config->writeback_fb_id_property) {
> > @@ -816,6 +818,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> > *connector,
> > *val = state->scaling_mode;
> > } else if (property == config->content_protection_property) {
> > *val = state->content_protection;
> > +   } else if (property == config->hdcp_content_type_property) {
> > +   *val = state->hdcp_content_type;
> > } else if (property == config->writeback_fb_id_property) {
> > /* Writeback framebuffer is one-shot, write and forget */
> > *val = 0;
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 764c7903edf6..de9e06583e8c 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> 
> Hi,
> 
> below I have some comments and questions before I can say whether
> https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
> adheres to this specification.
> 
> > @@ -955,6 +955,24 @@ static const struct drm_prop_enum_list 
> > hdmi_colorspaces[] = {
> >   *   the value transitions from ENABLED to DESIRED. This signifies the link
> >   *   is no longer protected and userspace should take appropriate action
> >   *   (whatever that might be).
> > + * HDCP Content Type:
> > + * This property is used by the userspace to configure the kernel with
> > + * to be displayed stream's content type. Content Type of a stream is
> > + * decided by the owner of the stream, as HDCP Type0 or HDCP Type1.
> > + *
> > + * The value of the property can be one the below:
> > + *   - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> 
> If this doc is meant as the UAPI doc, it needs to use the string names
> for enum property values, not the C language definitions (integers).
kernel documentation for all other properties followed this way. We
could add string associated to the enum state too for this property.
> 
> > + * HDCP Type0 streams can be transmitted on a link which is
> > + * encrypted with HDCP 1.4 or HDCP 2.2.
> 
> This wording forbids using any future HDCP version for type0.
We could change it to HDCP1.4 and higher version of HDCP.
> 
> > + *   - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> > + * HDCP Type1 streams can be transmitted on a link which is
> > + * encrypted only with HDCP 2.2.
> 
> This wording forbids using any future HDCP version for type1.
As of now type 1 is only on HDCP2.2 encrypted link, as no higher version is
available. But as similar to Type 0 we could assume that 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/gtt: pde entry encoding is identical

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
URL   : https://patchwork.freedesktop.org/series/63229/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/gtt: pde entry encoding is identical
-O:drivers/gpu/drm/i915/i915_gem_gtt.c:1608:9: warning: expression using 
sizeof(void)
-O:drivers/gpu/drm/i915/i915_gem_gtt.c:1608:9: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:1575:9: warning: expression using 
sizeof(void)
+drivers/gpu/drm/i915/i915_gem_gtt.c:1575:9: warning: expression using 
sizeof(void)

Commit: drm/i915/gtt: Tear down setup and cleanup macros for page dma
Okay!

Commit: drm/i915/gtt: Setup phys pages for 3lvl pdps
Okay!

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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/gtt: pde entry encoding is identical

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
URL   : https://patchwork.freedesktop.org/series/63229/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3d60e2b75e24 drm/i915/gtt: pde entry encoding is identical
-:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pd' - possible side-effects?
#58: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:777:
+#define init_pd(vm, pd, to) {  \
+   GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
+   fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
+   memset_p((pd)->entry, (to), 512);   \
 }

-:58: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'to' - possible side-effects?
#58: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:777:
+#define init_pd(vm, pd, to) {  \
+   GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
+   fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
+   memset_p((pd)->entry, (to), 512);   \
 }

-:91: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pd' - possible side-effects?
#91: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:804:
+#define set_pd_entry(pd, pde, to)  ({ \
+   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
+   atomic_inc(&(pd)->used);   \
+})

-:96: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pd' - possible side-effects?
#96: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:809:
+#define clear_pd_entry(pd, pde, to) ({  \
+   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
+   atomic_dec(>used);   \
+})

total: 0 errors, 0 warnings, 4 checks, 272 lines checked
d1cf7c577159 drm/i915/gtt: Tear down setup and cleanup macros for page dma
ecf8477bcfc1 drm/i915/gtt: Setup phys pages for 3lvl pdps

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gtt: Defer the free for alloc error paths

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/gtt: Defer the free for alloc error paths
URL   : https://patchwork.freedesktop.org/series/63127/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13508_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_busy@close-race:
- shard-snb:  [PASS][1] -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-snb7/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-snb7/igt@gem_b...@close-race.html

  * igt@runner@aborted:
- shard-kbl:  NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-kbl7/igt@run...@aborted.html
- shard-snb:  NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-snb7/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#110854])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@gem_workarounds@suspend-resume-context:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +2 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl6/igt@gem_workarou...@suspend-resume-context.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-apl5/igt@gem_workarou...@suspend-resume-context.html

  * igt@i915_suspend@forcewake:
- shard-kbl:  [PASS][9] -> [INCOMPLETE][10] ([fdo#103665])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl6/igt@i915_susp...@forcewake.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-kbl6/igt@i915_susp...@forcewake.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x21-random:
- shard-apl:  [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl8/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-apl2/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html

  * igt@kms_flip@2x-plain-flip-fb-recreate:
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#100368])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk1/igt@kms_f...@2x-plain-flip-fb-recreate.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-glk4/igt@kms_f...@2x-plain-flip-fb-recreate.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#105363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +5 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-iclb6/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar 
issues
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13508/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][23] -> [FAIL][24] ([fdo#99912])
   [23]: 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: fix include order in intel_tc.*

2019-07-04 Thread Michal Wajdeczko
On Thu, 04 Jul 2019 02:06:47 +0200, Lucas De Marchi  
 wrote:



Make intel_tc.h the first include so we guarantee it's self-contained.
Sort the rest. Same principle applies for includes in the header.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_tc.c | 5 +++--
 drivers/gpu/drm/i915/display/intel_tc.h | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_tc.c  
b/drivers/gpu/drm/i915/display/intel_tc.c

index 1a9dd32fb0a5..e6e6163c1232 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -3,10 +3,11 @@
  * Copyright © 2019 Intel Corporation
  */
+#include "intel_tc.h"
+
+#include "i915_drv.h"


this master header will likely include everything, so while
your .h is now self-contained, .c remains unclean


 #include "intel_display.h"
 #include "intel_dp_mst.h"
-#include "i915_drv.h"
-#include "intel_tc.h"
static const char *tc_port_mode_name(enum tc_port_mode mode)
 {
diff --git a/drivers/gpu/drm/i915/display/intel_tc.h  
b/drivers/gpu/drm/i915/display/intel_tc.h

index 0d8411d4a91d..45ae30537b78 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.h
+++ b/drivers/gpu/drm/i915/display/intel_tc.h
@@ -6,10 +6,11 @@
 #ifndef __INTEL_TC_H__
 #define __INTEL_TC_H__
-#include 
-#include 
 #include "intel_drv.h"


are you sure you want this giant header to be included here?
note that it will #include almost everything (i915_drv.h too)
and may introduce hard to resolve circular dependencies


+#include 


we don't need mutex definitions here in current header file


+#include 
+


so you need only above types.h and then add forward decl for:

struct intel_digital_port;


 bool intel_tc_port_connected(struct intel_digital_port *dig_port);
 u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
 int intel_tc_port_fia_max_lane_count(struct intel_digital_port  
*dig_port);

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

[Intel-gfx] [PATCH] drm/i915/selftests: Drain the freedlists between exec passes

2019-07-04 Thread Chris Wilson
During the context execution tests, we issue a lot of work and discard a
lot of objects without releasing the lock and allowing the background
reaper to free those objects. Insert a small break between each pass to
flush the worker.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index a23c6df9b9f4..91d13f019265 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -562,6 +562,8 @@ static int igt_ctx_exec(void *arg)
mock_file_free(i915, file);
if (err)
return err;
+
+   i915_gem_drain_freed_objects(i915);
}
 
return 0;
@@ -672,6 +674,10 @@ static int igt_shared_ctx_exec(void *arg)
 
dw += rem;
}
+
+   mutex_unlock(>drm.struct_mutex);
+   i915_gem_drain_freed_objects(i915);
+   mutex_lock(>drm.struct_mutex);
}
 out_test:
if (igt_live_test_end())
-- 
2.20.1

___
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: Check caller held wakerefs in assert_forcewakes_active

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Check caller held wakerefs in assert_forcewakes_active
URL   : https://patchwork.freedesktop.org/series/63125/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13507_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@close-race:
- shard-hsw:  [PASS][1] -> [DMESG-FAIL][2] ([fdo#111063])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw4/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-hsw1/igt@gem_b...@close-race.html

  * igt@gem_eio@reset-stress:
- shard-snb:  [PASS][3] -> [FAIL][4] ([fdo#109661])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-snb7/igt@gem_...@reset-stress.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-snb2/igt@gem_...@reset-stress.html

  * igt@i915_pm_rpm@i2c:
- shard-hsw:  [PASS][5] -> [FAIL][6] ([fdo#104097])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw7/igt@i915_pm_...@i2c.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-hsw5/igt@i915_pm_...@i2c.html

  * igt@i915_pm_rpm@modeset-stress-extra-wait:
- shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / 
[fdo#108840])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb3/igt@i915_pm_...@modeset-stress-extra-wait.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb7/igt@i915_pm_...@modeset-stress-extra-wait.html

  * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk:  [PASS][9] -> [FAIL][10] ([fdo#105363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-glk3/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl:  [PASS][11] -> [DMESG-WARN][12] ([fdo#103313])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl7/igt@kms_f...@flip-vs-suspend-interruptible.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-kbl6/igt@kms_f...@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu:
- shard-hsw:  [PASS][13] -> [SKIP][14] ([fdo#109271])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw5/igt@kms_frontbuffer_track...@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-hsw7/igt@kms_frontbuffer_track...@fbc-2p-primscrn-pri-indfb-draw-mmap-cpu.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +7 similar 
issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb4/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-iclb4/igt@kms_psr@psr2_sprite_plane_move.html

  
 Possible fixes 

  * igt@gem_busy@close-race:
- shard-skl:  [DMESG-FAIL][21] ([fdo#111063]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_b...@close-race.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl10/igt@gem_b...@close-race.html

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  [INCOMPLETE][23] ([fdo#104108] / [fdo#107773]) -> 
[PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_soft...@noreloc-s3.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13507/shard-skl7/igt@gem_soft...@noreloc-s3.html

  * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic:
- shard-glk:  [FAIL][25] ([fdo#104873]) -> [PASS][26]
   [25]: 

[Intel-gfx] [PATCH i-g-t 1/3] uapi/i915: Sync to bf73fc0fa9cf

2019-07-04 Thread Chris Wilson
Pull in i915_drm.h up to commit bf73fc0fa9cf ("drm/i915: Show support for
accurate sw PMU busyness tracking") for the new cap bits.

Signed-off-by: Chris Wilson 
---
 include/drm-uapi/i915_drm.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index 761517f15..c4d52102e 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -521,6 +521,7 @@ typedef struct drm_i915_irq_wait {
 #define   I915_SCHEDULER_CAP_PRIORITY  (1ul << 1)
 #define   I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
 #define   I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
+#define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
 
 #define I915_PARAM_HUC_STATUS   42
 
-- 
2.20.1

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

[Intel-gfx] [PATCH i-g-t 2/3] lib/i915: Report I915_SCHEDULER_CAP_ENGINE_BUSY_STATS

2019-07-04 Thread Chris Wilson
Hook the new capability bit alongside the existing scheduler reporting.

Signed-off-by: Chris Wilson 
---
 lib/i915/gem_scheduler.c | 15 +++
 lib/i915/gem_scheduler.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/lib/i915/gem_scheduler.c b/lib/i915/gem_scheduler.c
index 1ea910387..1beb85dec 100644
--- a/lib/i915/gem_scheduler.c
+++ b/lib/i915/gem_scheduler.c
@@ -118,6 +118,19 @@ bool gem_scheduler_has_semaphores(int fd)
I915_SCHEDULER_CAP_SEMAPHORES;
 }
 
+/**
+ * gem_scheduler_has_engine_busy_stats:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to query whether the driver supports reporting accurate
+ * per-engine utilisation.
+ */
+bool gem_scheduler_has_engine_busy_stats(int fd)
+{
+   return gem_scheduler_capability(fd) &
+   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS;
+}
+
 /**
  * gem_scheduler_print_capability:
  * @fd: open i915 drm file descriptor
@@ -138,4 +151,6 @@ void gem_scheduler_print_capability(int fd)
igt_info(" - With preemption enabled\n");
if (caps & I915_SCHEDULER_CAP_SEMAPHORES)
igt_info(" - With HW semaphores enabled\n");
+   if (caps & I915_SCHEDULER_CAP_ENGINE_BUSY_STATS)
+   igt_info(" - With engine busy statistics\n");
 }
diff --git a/lib/i915/gem_scheduler.h b/lib/i915/gem_scheduler.h
index f9049d128..14bd4cac4 100644
--- a/lib/i915/gem_scheduler.h
+++ b/lib/i915/gem_scheduler.h
@@ -31,6 +31,7 @@ bool gem_scheduler_enabled(int fd);
 bool gem_scheduler_has_ctx_priority(int fd);
 bool gem_scheduler_has_preemption(int fd);
 bool gem_scheduler_has_semaphores(int fd);
+bool gem_scheduler_has_engine_busy_stats(int fd);
 void gem_scheduler_print_capability(int fd);
 
 #endif /* GEM_SCHEDULER_H */
-- 
2.20.1

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

[Intel-gfx] [PATCH i-g-t 3/3] perf_pmu: Refine requirement testing for engine-busy-stats

2019-07-04 Thread Chris Wilson
Now that we report whether the accurate per-engine utilisation
statistics are available (albeit via the scheduler caps) put it to to
use to selectively enable the high accuracy tests where we expect it to
work.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 72b9166af..c3573b7a1 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1468,7 +1468,7 @@ test_enable_race(int gem_fd, const struct 
intel_execution_engine2 *e)
struct drm_i915_gem_execbuffer2 eb = { };
int fd;
 
-   igt_require(gem_has_execlists(gem_fd));
+   igt_require(gem_scheduler_has_engine_busy_stats(gem_fd));
igt_require(gem_context_has_engine(gem_fd, 0, e->flags));
 
obj.handle = gem_create(gem_fd, 4096);
@@ -1538,7 +1538,7 @@ accuracy(int gem_fd, const struct intel_execution_engine2 
*e,
int fd;
 
/* Sampling platforms cannot reach the high accuracy criteria. */
-   igt_require(gem_has_execlists(gem_fd));
+   igt_require(gem_scheduler_has_engine_busy_stats(gem_fd));
 
/* Aim for approximately 100 iterations for calibration */
cycle_us = min_test_us / target_iters;
-- 
2.20.1

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

Re: [Intel-gfx] [PATCH v4 4/5] drm/i915: Transition port type checks to phy checks

2019-07-04 Thread kbuild test robot
Hi Matt,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190704]
[cannot apply to v5.2-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matt-Roper/EHL-port-programming/20190704-143105
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-6) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/display/intel_display_power.c: In function 
'icl_tc_port_assert_ref_held':
>> drivers/gpu/drm/i915/display/intel_display_power.c:490:36: error: 
>> incompatible type for argument 1 of 'intel_port_to_phy'
  enum phy phy = intel_port_to_phy(encoder->port);
   ^~~
   In file included from drivers/gpu/drm/i915/i915_drv.h:67:0,
from drivers/gpu/drm/i915/display/intel_display_power.c:11:
   drivers/gpu/drm/i915/display/intel_display.h:378:10: note: expected 'struct 
drm_i915_private *' but argument is of type 'enum port'
enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
 ^
>> drivers/gpu/drm/i915/display/intel_display_power.c:490:18: error: too few 
>> arguments to function 'intel_port_to_phy'
  enum phy phy = intel_port_to_phy(encoder->port);
 ^
   In file included from drivers/gpu/drm/i915/i915_drv.h:67:0,
from drivers/gpu/drm/i915/display/intel_display_power.c:11:
   drivers/gpu/drm/i915/display/intel_display.h:378:10: note: declared here
enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port);
 ^

vim +/intel_port_to_phy +490 drivers/gpu/drm/i915/display/intel_display_power.c

   474  
   475  static void icl_tc_port_assert_ref_held(struct drm_i915_private 
*dev_priv,
   476  struct i915_power_well 
*power_well)
   477  {
   478  enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
   479  struct intel_digital_port *dig_port = NULL;
   480  struct intel_encoder *encoder;
   481  
   482  /* Bypass the check if all references are released 
asynchronously */
   483  if (power_well_async_ref_count(dev_priv, power_well) ==
   484  power_well->count)
   485  return;
   486  
   487  aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
   488  
   489  for_each_intel_encoder(_priv->drm, encoder) {
 > 490  enum phy phy = intel_port_to_phy(encoder->port);
   491  
   492  if (!intel_phy_is_tc(dev_priv, phy))
   493  continue;
   494  
   495  /* We'll check the MST primary port */
   496  if (encoder->type == INTEL_OUTPUT_DP_MST)
   497  continue;
   498  
   499  dig_port = enc_to_dig_port(>base);
   500  if (WARN_ON(!dig_port))
   501  continue;
   502  
   503  if (dig_port->aux_ch != aux_ch) {
   504  dig_port = NULL;
   505  continue;
   506  }
   507  
   508  break;
   509  }
   510  
   511  if (WARN_ON(!dig_port))
   512  return;
   513  
   514  WARN_ON(!intel_tc_port_ref_held(dig_port));
   515  }
   516  

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


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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gtt: pde entry encoding is identical

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-07-04 16:44:05)
>> +#define set_pd_entry(pd, pde, to)  ({ \
>> +   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
>> +   atomic_inc(&(pd)->used);   \
>
> inc before write so that you have a nice onion with clear.
>
>> +})
>> +
>> +#define clear_pd_entry(pd, pde, to) ({  \
>
> You want to pull the GEM_BUG_ON here so that is tightly coupled with the
> atomic_dec -- it's an underflow check.

I think I tried that but found out that when we free the ppgtt,
we want to be fast and don't care about the counts matching.

Well, that could be made to match tho. I will take a look.

-Mika

>
>> +   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
>> +   atomic_dec(>used);   \
>> +})
>
> I would have preferred these as inlines (even if means "passing" an
> extra arg), but let's see what the next two patches bring.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: Turn on GuC/HuC auto mode

2019-07-04 Thread Chris Wilson
Quoting Michal Wajdeczko (2019-07-03 14:02:51)
> On Wed, 03 Jul 2019 13:40:06 +0200, Chris Wilson  
>  wrote:
> 
> > Quoting Michal Wajdeczko (2019-07-03 12:36:40)
> >> GuC firmware is now mature, so let it run by default.
> >> Note that today GuC is only used for HuC authentication.
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=110617 ?
> 
> Above bug was found on suspicious kernel with old GuC 9.39:
> 
> [2.381803] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin  
> (version 2.0)
> [2.386316] [drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin  
> (version 9.39)
> [2.438318] [drm:intel_huc_auth] *ERROR* HuC: Firmware not verified  
> 0x6000
> [2.445235] [drm:intel_huc_auth] *ERROR* HuC: Authentication failed -110
> [2.451975] i915 :00:02.0: GuC initialization failed -110
> 
> while results from try-bot [1] with 33.0.0 on KBL are looking fine:
> 
> [3.854084] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin  
> (version 2.0)
> [3.865419] [drm] GuC: Loaded firmware i915/kbl_guc_33.0.0.bin (version  
> 33.0)
> [3.876243] i915 :00:02.0: GuC submission disabled
> [3.876245] i915 :00:02.0: HuC enabled
> 
> Note that newer GuC fixes other known issue [2] that has similar signature:
> 
> [160.168623] [drm:intel_huc_auth [i915]] *ERROR* HuC: Firmware not  
> verified -110
> [160.168839] [drm:intel_huc_auth [i915]] *ERROR* HuC: Authentication  
> failed -110
> [160.169159] [drm:i915_gem_init_hw [i915]] *ERROR* Enabling uc failed  
> (-110)

Pushed the switch to the new GuC version, but I am deferring the
decision to enable-by-default to someone in MAINTAINERS. Probably Joonas
if he survives his swim with the fishes.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/gen11: Start distinguishing 'phy' from 'port'

2019-07-04 Thread Lucas De Marchi

On Thu, Jul 04, 2019 at 06:09:04PM +0300, Ville Syrjälä wrote:

On Thu, Jul 04, 2019 at 07:54:26AM -0700, Lucas De Marchi wrote:

On Thu, Jul 04, 2019 at 12:18:11PM +0300, Ville Syrjälä wrote:
>On Wed, Jul 03, 2019 at 04:37:32PM -0700, Matt Roper wrote:
>> Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
>> Because of this, both the bspec documentation and our i915 code has used
>> the term "port" when talking about either DDI's or PHY's; it was always
>> easy to tell what terms like "Port A" were referring to from the
>> context.
>>
>> Unfortunately this is starting to break down now that EHL allows PHY-A
>> to be driven by either DDI-A or DDI-D.  Is a setup with DDI-D driving
>> PHY-A considered "Port A" or "Port D?"  The answer depends on which
>> register we're working with, and even the bspec doesn't do a great job
>> of clarifying this.
>>
>> Let's try to be more explicit about whether we're talking about the DDI
>> or the PHY on gen11+ by using 'port' to refer to the DDI and creating a
>> new 'enum phy' namespace to refer to the PHY in use.
>>
>> This patch just adds the new PHY namespace, new phy-based versions of
>> intel_port_is_*(), and a helper to convert a port to a PHY.
>> Transitioning various areas of the code over to using the PHY namespace
>> will be done in subsequent patches to make review easier.  We'll remove
>> the intel_port_is_*() functions at the end of the series when we
>> transition all callers over to using the PHY-based versions.
>>
>> v2:
>>  - Convert a few more 'port' uses to 'phy.' (Sparse)
>>
>> v3:
>>  - Switch DDI_CLK_SEL() back to 'port.' (Jose)
>>  - Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY
>>for its bit definitions, even though the register description is
>>given in terms of DDI.
>>  - To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using
>>port and create separate ICL+ definitions that work in terms of PHY.
>>
>> v4:
>>  - Rebase and resolve conflicts with Imre's TC series.
>>  - This patch now just adds the namespace and a few convenience
>>functions; the important changes are now split out into separate
>>patches to make review easier.
>>
>> Suggested-by: Ville Syrjala 
>> Cc: José Roberto de Souza 
>> Cc: Lucas De Marchi 
>> Cc: Ville Syrjälä 
>> Cc: Imre Deak 
>> Cc: Jani Nikula 
>> Signed-off-by: Matt Roper 
>> ---
>>  drivers/gpu/drm/i915/display/intel_display.c | 32 +++-
>>  drivers/gpu/drm/i915/display/intel_display.h | 16 ++
>>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>>  3 files changed, 49 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
>> index 919f5ac844c8..4a85abef93e7 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -6663,6 +6663,20 @@ bool intel_port_is_combophy(struct drm_i915_private 
*dev_priv, enum port port)
>>return false;
>>  }
>>
>> +bool intel_phy_is_combo(struct drm_i915_private *dev_priv, enum phy phy)
>> +{
>> +  if (phy == PHY_NONE)
>> +  return false;
>> +
>> +  if (IS_ELKHARTLAKE(dev_priv))
>> +  return phy <= PHY_C;
>> +
>> +  if (INTEL_GEN(dev_priv) >= 11)
>> +  return phy <= PHY_B;
>> +
>> +  return false;
>> +}
>> +
>>  bool intel_port_is_tc(struct drm_i915_private *dev_priv, enum port port)
>>  {
>>if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
>> @@ -6671,9 +6685,25 @@ bool intel_port_is_tc(struct drm_i915_private 
*dev_priv, enum port port)
>>return false;
>>  }
>>
>> +bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
>> +{
>> +  if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
>> +  return phy >= PHY_C && phy <= PHY_F;
>> +
>> +  return false;
>> +}
>> +
>> +enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
>> +{
>> +  if (IS_ELKHARTLAKE(i915) && port == PORT_D)
>> +  return PHY_A;
>> +
>> +  return (enum phy)port;
>> +}
>> +
>>  enum tc_port intel_port_to_tc(struct drm_i915_private *dev_priv, enum port 
port)
>>  {
>> -  if (!intel_port_is_tc(dev_priv, port))
>> +  if (!intel_phy_is_tc(dev_priv, intel_port_to_phy(dev_priv, port)))
>>return PORT_TC_NONE;
>>
>>return port - PORT_C;
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
>> index d296556ed82e..d53285fb883f 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display.h
>> @@ -228,6 +228,21 @@ struct intel_link_m_n {
>>u32 link_n;
>>  };
>>
>> +enum phy {
>> +  PHY_NONE = -1,
>> +
>> +  PHY_A = 0,
>> +  PHY_B,
>> +  PHY_C,
>> +  PHY_D,
>> +  PHY_E,
>> +  PHY_F,
>> +
>> +  I915_MAX_PHYS
>> +};
>
>I was pondering if we could 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gtt: pde entry encoding is identical

2019-07-04 Thread Chris Wilson
Quoting Mika Kuoppala (2019-07-04 16:44:05)
> +#define set_pd_entry(pd, pde, to)  ({ \
> +   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
> +   atomic_inc(&(pd)->used);   \

inc before write so that you have a nice onion with clear.

> +})
> +
> +#define clear_pd_entry(pd, pde, to) ({  \

You want to pull the GEM_BUG_ON here so that is tightly coupled with the
atomic_dec -- it's an underflow check.

> +   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
> +   atomic_dec(>used);   \
> +})

I would have preferred these as inlines (even if means "passing" an
extra arg), but let's see what the next two patches bring.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/guc: Upgrade to GuC 33.0.0

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/guc: Upgrade to GuC 33.0.0
URL   : https://patchwork.freedesktop.org/series/63123/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13506_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_busy@close-race:
- shard-kbl:  [PASS][1] -> [DMESG-FAIL][2] ([fdo#111063])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl6/igt@gem_b...@close-race.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-kbl2/igt@gem_b...@close-race.html
- shard-apl:  [PASS][3] -> [DMESG-FAIL][4] ([fdo#111063])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl8/igt@gem_b...@close-race.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-apl7/igt@gem_b...@close-race.html

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +9 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-kbl2/igt@gem_ctx_isolat...@rcs0-s3.html
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +8 
similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-apl3/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#110854])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@i915_pm_rc6_residency@rc6-accuracy:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#110933])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-iclb8/igt@i915_pm_rc6_reside...@rc6-accuracy.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [PASS][13] -> [FAIL][14] ([fdo#104873])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-glk:  [PASS][15] -> [FAIL][16] ([fdo#105363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk3/igt@kms_f...@flip-vs-expired-vblank.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-glk7/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@plain-flip-fb-recreate-interruptible:
- shard-skl:  [PASS][17] -> [FAIL][18] ([fdo#100368])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl10/igt@kms_f...@plain-flip-fb-recreate-interruptible.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-skl3/igt@kms_f...@plain-flip-fb-recreate-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw:
- shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar 
issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-iclb5/igt@kms_psr2...@frontbuffer.html

  * igt@kms_psr@psr2_sprite_plane_move:
- shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar 
issues
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-iclb5/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
- shard-kbl:  [PASS][25] -> [FAIL][26] ([fdo#99912])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl4/igt@kms_setm...@basic.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13506/shard-kbl3/igt@kms_setm...@basic.html

  * igt@perf_pmu@rc6:
- 

[Intel-gfx] [PATCH 1/3] drm/i915/gtt: pde entry encoding is identical

2019-07-04 Thread Mika Kuoppala
For all page directory entries, the pde encoding is
identical. Don't compilicate call sites with different
versions of doing the same thing. We check the existence of
physical page before writing the entry into it. This further
generalizes the pd so that manipulation in callsites will be
identical, removing the need to handle pdps differently for gen8.

v2: squash
v3: inc/dec with set/clear (Chris)

Cc: Chris Wilson 
Cc: Matthew Auld 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 137 +++-
 drivers/gpu/drm/i915/i915_gem_gtt.h |   3 -
 2 files changed, 52 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9756f1b670e9..4709948a6c0e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -211,10 +211,10 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
 }
 
-static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
- const enum i915_cache_level level)
+static u64 gen8_pde_encode(const dma_addr_t addr,
+  const enum i915_cache_level level)
 {
-   gen8_pde_t pde = _PAGE_PRESENT | _PAGE_RW;
+   u64 pde = _PAGE_PRESENT | _PAGE_RW;
pde |= addr;
if (level != I915_CACHE_NONE)
pde |= PPAT_CACHED_PDE;
@@ -223,9 +223,6 @@ static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
return pde;
 }
 
-#define gen8_pdpe_encode gen8_pde_encode
-#define gen8_pml4e_encode gen8_pde_encode
-
 static u64 snb_pte_encode(dma_addr_t addr,
  enum i915_cache_level level,
  u32 flags)
@@ -777,24 +774,43 @@ static void free_pd(struct i915_address_space *vm,
kfree(pd);
 }
 
-static void init_pd_with_page(struct i915_address_space *vm,
- struct i915_page_directory * const pd,
- struct i915_page_table *pt)
-{
-   fill_px(vm, pd, gen8_pde_encode(px_dma(pt), I915_CACHE_LLC));
-   memset_p(pd->entry, pt, 512);
+#define init_pd(vm, pd, to) {  \
+   GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
+   fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
+   memset_p((pd)->entry, (to), 512);   \
 }
 
-static void init_pd(struct i915_address_space *vm,
-   struct i915_page_directory * const pd,
-   struct i915_page_directory * const to)
+static void __write_dma_entry(struct i915_page_dma * const pdma,
+ const unsigned short pde,
+ const u64 encoded_entry)
 {
-   GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));
+   u64 *vaddr;
 
-   fill_px(vm, pd, gen8_pdpe_encode(px_dma(to), I915_CACHE_LLC));
-   memset_p(pd->entry, to, 512);
+   vaddr = kmap_atomic(pdma->page);
+   vaddr[pde] = encoded_entry;
+   kunmap_atomic(vaddr);
 }
 
+static inline void
+__write_pd_entry(struct i915_page_directory * const pd,
+const unsigned short pde,
+struct i915_page_dma * const to,
+u64 (*encode)(const dma_addr_t, const enum i915_cache_level))
+{
+   pd->entry[pde] = to;
+   __write_dma_entry(px_base(pd), pde, encode(to->daddr, I915_CACHE_LLC));
+}
+
+#define set_pd_entry(pd, pde, to)  ({ \
+   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
+   atomic_inc(&(pd)->used);   \
+})
+
+#define clear_pd_entry(pd, pde, to) ({  \
+   __write_pd_entry((pd), (pde), px_base(to), gen8_pde_encode); \
+   atomic_dec(>used);   \
+})
+
 /*
  * PDE TLBs are a pain to invalidate on GEN8+. When we modify
  * the page table structures, we mark them dirty so that
@@ -824,18 +840,6 @@ static bool gen8_ppgtt_clear_pt(const struct 
i915_address_space *vm,
return !atomic_sub_return(num_entries, >used);
 }
 
-static void gen8_ppgtt_set_pde(struct i915_address_space *vm,
-  struct i915_page_directory *pd,
-  struct i915_page_table *pt,
-  unsigned int pde)
-{
-   gen8_pde_t *vaddr;
-
-   vaddr = kmap_atomic_px(pd);
-   vaddr[pde] = gen8_pde_encode(px_dma(pt), I915_CACHE_LLC);
-   kunmap_atomic(vaddr);
-}
-
 static bool gen8_ppgtt_clear_pd(struct i915_address_space *vm,
struct i915_page_directory *pd,
u64 start, u64 length)
@@ -853,11 +857,8 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space 
*vm,
 
spin_lock(>lock);
if (!atomic_read(>used)) {
-   gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
-   pd->entry[pde] = vm->scratch_pt;
-
   

[Intel-gfx] [PATCH 3/3] drm/i915/gtt: Setup phys pages for 3lvl pdps

2019-07-04 Thread Mika Kuoppala
If we setup backing phys page for 3lvl pdps, even they
are not used, we lose 5 pages per ppgtt.

Trading this memory on bsw, we gain more common code paths for all
gen8+ directory manipulation. And those paths are now void of checks
for page directory type, making the hot paths faster.

v2: don't shortcut vm (Chris)

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 77 +++--
 1 file changed, 50 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 84e119d7a5fc..b9422d592e8c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -758,22 +758,14 @@ static struct i915_page_directory *alloc_pd(struct 
i915_address_space *vm)
return pd;
 }
 
-static inline bool pd_has_phys_page(const struct i915_page_directory * const 
pd)
-{
-   return pd->base.page;
-}
-
 static void free_pd(struct i915_address_space *vm,
struct i915_page_directory *pd)
 {
-   if (likely(pd_has_phys_page(pd)))
-   cleanup_page_dma(vm, >base);
-
+   cleanup_page_dma(vm, >base);
kfree(pd);
 }
 
 #define init_pd(vm, pd, to) {  \
-   GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
memset_p((pd)->entry, (to), 512);   \
 }
@@ -1595,6 +1587,50 @@ static void ppgtt_init(struct i915_ppgtt *ppgtt, struct 
intel_gt *gt)
ppgtt->vm.vma_ops.clear_pages = clear_pages;
 }
 
+static void init_pd_n(struct i915_address_space *vm,
+ struct i915_page_directory *pd,
+ struct i915_page_directory *to,
+ const unsigned int entries)
+{
+   const u64 daddr = gen8_pde_encode(px_dma(to), I915_CACHE_LLC);
+   u64 * const vaddr = kmap_atomic(pd->base.page);
+
+   memset64(vaddr, daddr, entries);
+   kunmap_atomic(vaddr);
+
+   memset_p(pd->entry, to, entries);
+}
+
+static struct i915_page_directory *
+gen8_alloc_top_pd(struct i915_address_space *vm)
+{
+   struct i915_page_directory *pd;
+
+   if (i915_vm_is_4lvl(vm)) {
+   pd = alloc_pd(vm);
+   if (!IS_ERR(pd))
+   init_pd(vm, pd, vm->scratch_pdp);
+
+   return pd;
+   }
+
+   /* 3lvl */
+   pd = __alloc_pd();
+   if (!pd)
+   return ERR_PTR(-ENOMEM);
+
+   pd->entry[GEN8_3LVL_PDPES] = NULL;
+
+   if (unlikely(setup_page_dma(vm, >base))) {
+   kfree(pd);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   init_pd_n(vm, pd, vm->scratch_pd, GEN8_3LVL_PDPES);
+
+   return pd;
+}
+
 /*
  * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP registers
  * with a net effect resembling a 2-level page table in normal x86 terms. Each
@@ -1631,34 +1667,21 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct 
drm_i915_private *i915)
if (err)
goto err_free;
 
-   ppgtt->pd = __alloc_pd();
-   if (!ppgtt->pd) {
-   err = -ENOMEM;
+   ppgtt->pd = gen8_alloc_top_pd(>vm);
+   if (IS_ERR(ppgtt->pd)) {
+   err = PTR_ERR(ppgtt->pd);
goto err_free_scratch;
}
 
if (i915_vm_is_4lvl(>vm)) {
-   err = setup_page_dma(>vm, >pd->base);
-   if (err)
-   goto err_free_pdp;
-
-   init_pd(>vm, ppgtt->pd, ppgtt->vm.scratch_pdp);
-
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc_4lvl;
ppgtt->vm.insert_entries = gen8_ppgtt_insert_4lvl;
ppgtt->vm.clear_range = gen8_ppgtt_clear_4lvl;
} else {
-   /*
-* We don't need to setup dma for top level pdp, only
-* for entries. So point entries to scratch.
-*/
-   memset_p(ppgtt->pd->entry, ppgtt->vm.scratch_pd,
-GEN8_3LVL_PDPES);
-
if (intel_vgpu_active(i915)) {
err = gen8_preallocate_top_level_pdp(ppgtt);
if (err)
-   goto err_free_pdp;
+   goto err_free_pd;
}
 
ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc_3lvl;
@@ -1673,7 +1696,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct 
drm_i915_private *i915)
 
return ppgtt;
 
-err_free_pdp:
+err_free_pd:
free_pd(>vm, ppgtt->pd);
 err_free_scratch:
gen8_free_scratch(>vm);
-- 
2.17.1

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

[Intel-gfx] [PATCH 2/3] drm/i915/gtt: Tear down setup and cleanup macros for page dma

2019-07-04 Thread Mika Kuoppala
We don't use common codepaths to setup and cleanup page
directories vs page tables. So their setup and cleanup macros
are of no use.

Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4709948a6c0e..84e119d7a5fc 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -594,8 +594,6 @@ static void cleanup_page_dma(struct i915_address_space *vm,
 
 #define kmap_atomic_px(px) kmap_atomic(px_base(px)->page)
 
-#define setup_px(vm, px) setup_page_dma((vm), px_base(px))
-#define cleanup_px(vm, px) cleanup_page_dma((vm), px_base(px))
 #define fill_px(vm, px, v) fill_page_dma((vm), px_base(px), (v))
 #define fill32_px(vm, px, v) fill_page_dma_32((vm), px_base(px), (v))
 
@@ -697,7 +695,7 @@ static struct i915_page_table *alloc_pt(struct 
i915_address_space *vm)
if (unlikely(!pt))
return ERR_PTR(-ENOMEM);
 
-   if (unlikely(setup_px(vm, pt))) {
+   if (unlikely(setup_page_dma(vm, >base))) {
kfree(pt);
return ERR_PTR(-ENOMEM);
}
@@ -709,7 +707,7 @@ static struct i915_page_table *alloc_pt(struct 
i915_address_space *vm)
 
 static void free_pt(struct i915_address_space *vm, struct i915_page_table *pt)
 {
-   cleanup_px(vm, pt);
+   cleanup_page_dma(vm, >base);
kfree(pt);
 }
 
@@ -752,7 +750,7 @@ static struct i915_page_directory *alloc_pd(struct 
i915_address_space *vm)
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
 
-   if (unlikely(setup_px(vm, pd))) {
+   if (unlikely(setup_page_dma(vm, >base))) {
kfree(pd);
return ERR_PTR(-ENOMEM);
}
@@ -769,7 +767,7 @@ static void free_pd(struct i915_address_space *vm,
struct i915_page_directory *pd)
 {
if (likely(pd_has_phys_page(pd)))
-   cleanup_px(vm, pd);
+   cleanup_page_dma(vm, >base);
 
kfree(pd);
 }
@@ -1640,7 +1638,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct 
drm_i915_private *i915)
}
 
if (i915_vm_is_4lvl(>vm)) {
-   err = setup_px(>vm, ppgtt->pd);
+   err = setup_page_dma(>vm, >pd->base);
if (err)
goto err_free_pdp;
 
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/gen11: Start distinguishing 'phy' from 'port'

2019-07-04 Thread Ville Syrjälä
On Thu, Jul 04, 2019 at 07:54:26AM -0700, Lucas De Marchi wrote:
> On Thu, Jul 04, 2019 at 12:18:11PM +0300, Ville Syrjälä wrote:
> >On Wed, Jul 03, 2019 at 04:37:32PM -0700, Matt Roper wrote:
> >> Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
> >> Because of this, both the bspec documentation and our i915 code has used
> >> the term "port" when talking about either DDI's or PHY's; it was always
> >> easy to tell what terms like "Port A" were referring to from the
> >> context.
> >>
> >> Unfortunately this is starting to break down now that EHL allows PHY-A
> >> to be driven by either DDI-A or DDI-D.  Is a setup with DDI-D driving
> >> PHY-A considered "Port A" or "Port D?"  The answer depends on which
> >> register we're working with, and even the bspec doesn't do a great job
> >> of clarifying this.
> >>
> >> Let's try to be more explicit about whether we're talking about the DDI
> >> or the PHY on gen11+ by using 'port' to refer to the DDI and creating a
> >> new 'enum phy' namespace to refer to the PHY in use.
> >>
> >> This patch just adds the new PHY namespace, new phy-based versions of
> >> intel_port_is_*(), and a helper to convert a port to a PHY.
> >> Transitioning various areas of the code over to using the PHY namespace
> >> will be done in subsequent patches to make review easier.  We'll remove
> >> the intel_port_is_*() functions at the end of the series when we
> >> transition all callers over to using the PHY-based versions.
> >>
> >> v2:
> >>  - Convert a few more 'port' uses to 'phy.' (Sparse)
> >>
> >> v3:
> >>  - Switch DDI_CLK_SEL() back to 'port.' (Jose)
> >>  - Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY
> >>for its bit definitions, even though the register description is
> >>given in terms of DDI.
> >>  - To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using
> >>port and create separate ICL+ definitions that work in terms of PHY.
> >>
> >> v4:
> >>  - Rebase and resolve conflicts with Imre's TC series.
> >>  - This patch now just adds the namespace and a few convenience
> >>functions; the important changes are now split out into separate
> >>patches to make review easier.
> >>
> >> Suggested-by: Ville Syrjala 
> >> Cc: José Roberto de Souza 
> >> Cc: Lucas De Marchi 
> >> Cc: Ville Syrjälä 
> >> Cc: Imre Deak 
> >> Cc: Jani Nikula 
> >> Signed-off-by: Matt Roper 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_display.c | 32 +++-
> >>  drivers/gpu/drm/i915/display/intel_display.h | 16 ++
> >>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >>  3 files changed, 49 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> index 919f5ac844c8..4a85abef93e7 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> @@ -6663,6 +6663,20 @@ bool intel_port_is_combophy(struct drm_i915_private 
> >> *dev_priv, enum port port)
> >>return false;
> >>  }
> >>
> >> +bool intel_phy_is_combo(struct drm_i915_private *dev_priv, enum phy phy)
> >> +{
> >> +  if (phy == PHY_NONE)
> >> +  return false;
> >> +
> >> +  if (IS_ELKHARTLAKE(dev_priv))
> >> +  return phy <= PHY_C;
> >> +
> >> +  if (INTEL_GEN(dev_priv) >= 11)
> >> +  return phy <= PHY_B;
> >> +
> >> +  return false;
> >> +}
> >> +
> >>  bool intel_port_is_tc(struct drm_i915_private *dev_priv, enum port port)
> >>  {
> >>if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
> >> @@ -6671,9 +6685,25 @@ bool intel_port_is_tc(struct drm_i915_private 
> >> *dev_priv, enum port port)
> >>return false;
> >>  }
> >>
> >> +bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
> >> +{
> >> +  if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
> >> +  return phy >= PHY_C && phy <= PHY_F;
> >> +
> >> +  return false;
> >> +}
> >> +
> >> +enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
> >> +{
> >> +  if (IS_ELKHARTLAKE(i915) && port == PORT_D)
> >> +  return PHY_A;
> >> +
> >> +  return (enum phy)port;
> >> +}
> >> +
> >>  enum tc_port intel_port_to_tc(struct drm_i915_private *dev_priv, enum 
> >> port port)
> >>  {
> >> -  if (!intel_port_is_tc(dev_priv, port))
> >> +  if (!intel_phy_is_tc(dev_priv, intel_port_to_phy(dev_priv, port)))
> >>return PORT_TC_NONE;
> >>
> >>return port - PORT_C;
> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
> >> b/drivers/gpu/drm/i915/display/intel_display.h
> >> index d296556ed82e..d53285fb883f 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_display.h
> >> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> >> @@ -228,6 +228,21 @@ struct intel_link_m_n {
> >>u32 link_n;
> >>  };
> >>
> >> +enum phy {
> >> +  PHY_NONE = -1,
> >> +
> >> +  PHY_A = 0,
> >> +  PHY_B,
> >> +  PHY_C,
> >> +  PHY_D,
> >> 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Rework some interrupt handling functions to take intel_gt

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Rework some interrupt handling 
functions to take intel_gt
URL   : https://patchwork.freedesktop.org/series/63225/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6413 -> Patchwork_13530


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13530/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live_sanitycheck:
- fi-icl-u3:  [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1 
similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6413/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13530/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][3] -> [FAIL][4] ([fdo#109485])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6413/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13530/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  
 Possible fixes 

  * igt@gem_mmap_gtt@basic-write-gtt:
- fi-icl-u3:  [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6413/fi-icl-u3/igt@gem_mmap_...@basic-write-gtt.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13530/fi-icl-u3/igt@gem_mmap_...@basic-write-gtt.html

  * igt@i915_selftest@live_contexts:
- fi-skl-iommu:   [INCOMPLETE][7] ([fdo#111050]) -> [PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6413/fi-skl-iommu/igt@i915_selftest@live_contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13530/fi-skl-iommu/igt@i915_selftest@live_contexts.html

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

  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111050]: https://bugs.freedesktop.org/show_bug.cgi?id=111050


Participating hosts (52 -> 46)
--

  Additional (2): fi-icl-guc fi-bsw-n3050 
  Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks 
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6413 -> Patchwork_13530

  CI_DRM_6413: e34db06fa7ab85da62d786e2803dcef578f93360 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5083: 4d710ea530aca69304df37191802476f406746ca @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13530: 8ed894be4e53a4d6a7e9a91f33f64d34151a63a2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13530/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

8ed894be4e53 drm/i915: Move dev_priv->pm_i{m, e}r into intel_gt
190cc43f6a60 drm/i915: Remove some legacy mmio accessors from interrupt handling
570169d12f55 drm/i915: Rework some interrupt handling functions to take intel_gt

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/gen11: Start distinguishing 'phy' from 'port'

2019-07-04 Thread Lucas De Marchi

On Thu, Jul 04, 2019 at 12:18:11PM +0300, Ville Syrjälä wrote:

On Wed, Jul 03, 2019 at 04:37:32PM -0700, Matt Roper wrote:

Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
Because of this, both the bspec documentation and our i915 code has used
the term "port" when talking about either DDI's or PHY's; it was always
easy to tell what terms like "Port A" were referring to from the
context.

Unfortunately this is starting to break down now that EHL allows PHY-A
to be driven by either DDI-A or DDI-D.  Is a setup with DDI-D driving
PHY-A considered "Port A" or "Port D?"  The answer depends on which
register we're working with, and even the bspec doesn't do a great job
of clarifying this.

Let's try to be more explicit about whether we're talking about the DDI
or the PHY on gen11+ by using 'port' to refer to the DDI and creating a
new 'enum phy' namespace to refer to the PHY in use.

This patch just adds the new PHY namespace, new phy-based versions of
intel_port_is_*(), and a helper to convert a port to a PHY.
Transitioning various areas of the code over to using the PHY namespace
will be done in subsequent patches to make review easier.  We'll remove
the intel_port_is_*() functions at the end of the series when we
transition all callers over to using the PHY-based versions.

v2:
 - Convert a few more 'port' uses to 'phy.' (Sparse)

v3:
 - Switch DDI_CLK_SEL() back to 'port.' (Jose)
 - Add a code comment clarifying why DPCLKA_CFGCR0_ICL needs to use PHY
   for its bit definitions, even though the register description is
   given in terms of DDI.
 - To avoid confusion, switch CNL's DPCLKA_CFGCR0 defines back to using
   port and create separate ICL+ definitions that work in terms of PHY.

v4:
 - Rebase and resolve conflicts with Imre's TC series.
 - This patch now just adds the namespace and a few convenience
   functions; the important changes are now split out into separate
   patches to make review easier.

Suggested-by: Ville Syrjala 
Cc: José Roberto de Souza 
Cc: Lucas De Marchi 
Cc: Ville Syrjälä 
Cc: Imre Deak 
Cc: Jani Nikula 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_display.c | 32 +++-
 drivers/gpu/drm/i915/display/intel_display.h | 16 ++
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 919f5ac844c8..4a85abef93e7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6663,6 +6663,20 @@ bool intel_port_is_combophy(struct drm_i915_private 
*dev_priv, enum port port)
return false;
 }

+bool intel_phy_is_combo(struct drm_i915_private *dev_priv, enum phy phy)
+{
+   if (phy == PHY_NONE)
+   return false;
+
+   if (IS_ELKHARTLAKE(dev_priv))
+   return phy <= PHY_C;
+
+   if (INTEL_GEN(dev_priv) >= 11)
+   return phy <= PHY_B;
+
+   return false;
+}
+
 bool intel_port_is_tc(struct drm_i915_private *dev_priv, enum port port)
 {
if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
@@ -6671,9 +6685,25 @@ bool intel_port_is_tc(struct drm_i915_private *dev_priv, 
enum port port)
return false;
 }

+bool intel_phy_is_tc(struct drm_i915_private *dev_priv, enum phy phy)
+{
+   if (INTEL_GEN(dev_priv) >= 11 && !IS_ELKHARTLAKE(dev_priv))
+   return phy >= PHY_C && phy <= PHY_F;
+
+   return false;
+}
+
+enum phy intel_port_to_phy(struct drm_i915_private *i915, enum port port)
+{
+   if (IS_ELKHARTLAKE(i915) && port == PORT_D)
+   return PHY_A;
+
+   return (enum phy)port;
+}
+
 enum tc_port intel_port_to_tc(struct drm_i915_private *dev_priv, enum port 
port)
 {
-   if (!intel_port_is_tc(dev_priv, port))
+   if (!intel_phy_is_tc(dev_priv, intel_port_to_phy(dev_priv, port)))
return PORT_TC_NONE;

return port - PORT_C;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index d296556ed82e..d53285fb883f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -228,6 +228,21 @@ struct intel_link_m_n {
u32 link_n;
 };

+enum phy {
+   PHY_NONE = -1,
+
+   PHY_A = 0,
+   PHY_B,
+   PHY_C,
+   PHY_D,
+   PHY_E,
+   PHY_F,
+
+   I915_MAX_PHYS
+};


I was pondering if we could eventually do something like:

enum phy {
PHY_COMBO_A = 0,
PHY_COMBO_B,
...

PHY_TC_1,
PHY_TC_2,
...
};

and probably also add encoder->phy so we can contain
that port<->phy mapping logic in the encoder init.
I think that should work more or less fine since I
don't think PHY_TC_1 needs to have any specific value.


that's not true. All TC registers are based off the TC phy number.
Hence all the conversion we do 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Flush the workqueue before draining

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915: Flush the workqueue before draining
URL   : https://patchwork.freedesktop.org/series/63117/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13505_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@gem_eio@in-flight-10ms:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl8/igt@gem_...@in-flight-10ms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-apl6/igt@gem_...@in-flight-10ms.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_isolation@bcs0-s3:
- shard-skl:  [PASS][3] -> [INCOMPLETE][4] ([fdo#104108]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl6/igt@gem_ctx_isolat...@bcs0-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-skl6/igt@gem_ctx_isolat...@bcs0-s3.html

  * igt@gem_ctx_isolation@rcs0-s3:
- shard-apl:  [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html

  * igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#110854])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@gem_exec_balan...@smoke.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-iclb5/igt@gem_exec_balan...@smoke.html

  * igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- shard-hsw:  [PASS][9] -> [FAIL][10] ([fdo#103355])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-hsw1/igt@kms_cursor_leg...@cursor-vs-flip-atomic.html

  * igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk:  [PASS][11] -> [FAIL][12] ([fdo#105363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk7/igt@kms_f...@2x-flip-vs-expired-vblank.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-glk6/igt@kms_f...@2x-flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-expired-vblank:
- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#105363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html

  * igt@kms_flip@flip-vs-modeset-interruptible:
- shard-snb:  [PASS][15] -> [INCOMPLETE][16] ([fdo#105411])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-snb4/igt@kms_f...@flip-vs-modeset-interruptible.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-snb1/igt@kms_f...@flip-vs-modeset-interruptible.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +5 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / 
[fdo#110042])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-iclb8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr2...@frontbuffer.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13505/shard-iclb5/igt@kms_psr2...@frontbuffer.html

  * 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915: Rework some interrupt handling functions to take intel_gt

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Rework some interrupt handling 
functions to take intel_gt
URL   : https://patchwork.freedesktop.org/series/63225/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
570169d12f55 drm/i915: Rework some interrupt handling functions to take intel_gt
-:12: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do 
not match 
#12: 
Co-developed-by: Paulo Zanoni 
Signed-off-by: Tvrtko Ursulin 
total: 0 errors, 1 warnings, 0 checks, 269 lines checked
190cc43f6a60 drm/i915: Remove some legacy mmio accessors from interrupt handling
-:11: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do 
not match 
#11: 
Co-developed-by: Paulo Zanoni 
Signed-off-by: Tvrtko Ursulin 
total: 0 errors, 1 warnings, 0 checks, 136 lines checked
8ed894be4e53 drm/i915: Move dev_priv->pm_i{m, e}r into intel_gt
-:10: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do 
not match 
#10: 
Co-developed-by: Paulo Zanoni 
Signed-off-by: Tvrtko Ursulin 
total: 0 errors, 1 warnings, 0 checks, 342 lines checked

___
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/gem: Defer obj->base.resv fini until RCU callback

2019-07-04 Thread Chris Wilson
Quoting Mika Kuoppala (2019-07-04 15:18:40)
> Chris Wilson  writes:
> 
> > Quoting Mika Kuoppala (2019-07-04 14:53:09)
> >> Chris Wilson  writes:
> >> > +static void shmem_release(struct drm_i915_gem_object *obj)
> >> > +{
> >> > + fput(obj->base.filp);
> >> 
> >> We lose the check for filp existence. But as internal
> >> ops have their own mechanics, we should always have the filp.
> >
> > Exactly. drm_gem_object should not have filp anymore.
> 
> ..for internal objects.

I mean the struct drm_gem_object should not include a struct file *filp
anymore as not all subclasses are shmem based. And where people want to
use it, it raises more questions than answers.
-Chris
___
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/gem: Defer obj->base.resv fini until RCU callback

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-07-04 14:53:09)
>> Chris Wilson  writes:
>> 
>> > Since reservation_object_fini() does an immediate free, rather than
>> > kfree_rcu as normal, we have to delay the release until after the RCU
>> > grace period has elapsed (i.e. from the rcu cleanup callback) so that we
>> > can rely on the RCU protected access to the fences while the object is a
>> > zombie.
>> >
>> > i915_gem_busy_ioctl relies on having an RCU barrier to protect the
>> > reservation in order to avoid having to take a reference and strong
>> > memory barriers.
>> 
>> Ok so for gem busy to be able to operate on a 'to be freed' object
>> we need to keep the reservation object alive?
>
> Yup. It could equally be kept alive if resv_obj_fini used kfree_rcu()
> instead, but we already need an RCU barrier for our object lookup so
> might as well use one stone for both birds.
>
>> > Fixes: c03467ba40f7 ("drm/i915/gem: Free pages before rcu-freeing the 
>> > object")
>> > Testcase: igt/gem_busy/close-race
>> > Signed-off-by: Chris Wilson 
>> > Cc: Matthew Auld 
>> > ---
>> >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ++-
>> >  drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 7 +++
>> >  2 files changed, 9 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
>> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > index d3e96f09c6b7..0dced4a20e20 100644
>> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> > @@ -152,6 +152,7 @@ static void __i915_gem_free_object_rcu(struct rcu_head 
>> > *head)
>> >   container_of(head, typeof(*obj), rcu);
>> >   struct drm_i915_private *i915 = to_i915(obj->base.dev);
>> >  
>> > + reservation_object_fini(>base._resv);
>> >   i915_gem_object_free(obj);
>> >  
>> >   GEM_BUG_ON(!atomic_read(>mm.free_count));
>> > @@ -198,7 +199,7 @@ static void __i915_gem_free_objects(struct 
>> > drm_i915_private *i915,
>> >   if (obj->base.import_attach)
>> >   drm_prime_gem_destroy(>base, NULL);
>> >  
>> > - drm_gem_object_release(>base);
>> > + drm_gem_free_mmap_offset(>base);
>> >  
>> >   /* But keep the pointer alive for RCU-protected lookups */
>> >   call_rcu(>rcu, __i915_gem_free_object_rcu);
>> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
>> > b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> > index 19d9ecdb2894..d2a1158868e7 100644
>> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
>> > @@ -414,6 +414,11 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
>> >   return 0;
>> >  }
>> >  
>> > +static void shmem_release(struct drm_i915_gem_object *obj)
>> > +{
>> > + fput(obj->base.filp);
>> 
>> We lose the check for filp existence. But as internal
>> ops have their own mechanics, we should always have the filp.
>
> Exactly. drm_gem_object should not have filp anymore.

..for internal objects.

>
>> We lose a warn for dma_buf existence tho.
>
> Good. Let me hand you a tiny violin ;)

Let's see how it plays out.

Reviewed-by: Mika Kuoppala 

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: move intel_ddi_set_fia_lane_count to intel_tc.c

2019-07-04 Thread Imre Deak
On Wed, Jul 03, 2019 at 05:06:48PM -0700, Lucas De Marchi wrote:
> PORT_TX_DFLEXDPMLE1 is a FIA register so move it to intel_tc.c where we
> access other FIA registers. In Tiger Lake we have multiple/modular FIAs
> so it makes sense to start moving all access to their registers to a
> common place.
> 
> While at it, make it clear that we will only ever call this function
> for ports with TC phy. Previously we were relying on tc_mode being
> TC_PORT_TBT_ALT for combo phy ports. However it's confusing since in
> this same function we have checks for is_tc_port. Also, if we manage to
> make each phy access only their own field, we may in future add them as
> a union inside intel_digital_port.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 49 
>  drivers/gpu/drm/i915/display/intel_tc.c  | 31 +++
>  drivers/gpu/drm/i915/display/intel_tc.h  |  2 +
>  3 files changed, 40 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index a4172595c8d8..f6d60b71da7a 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3594,37 +3594,6 @@ static void intel_ddi_update_pipe(struct intel_encoder 
> *encoder,
>   intel_hdcp_disable(to_intel_connector(conn_state->connector));
>  }
>  
> -static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
> -  const struct intel_crtc_state 
> *pipe_config,
> -  enum port port)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> - u32 val = I915_READ(PORT_TX_DFLEXDPMLE1);
> - bool lane_reversal = dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
> -
> - WARN_ON(lane_reversal && dig_port->tc_mode != TC_PORT_LEGACY);
> -
> - val &= ~DFLEXDPMLE1_DPMLETC_MASK(tc_port);
> - switch (pipe_config->lane_count) {
> - case 1:
> - val |= (lane_reversal) ? DFLEXDPMLE1_DPMLETC_ML3(tc_port) :
> - DFLEXDPMLE1_DPMLETC_ML0(tc_port);
> - break;
> - case 2:
> - val |= (lane_reversal) ? DFLEXDPMLE1_DPMLETC_ML3_2(tc_port) :
> - DFLEXDPMLE1_DPMLETC_ML1_0(tc_port);
> - break;
> - case 4:
> - val |= DFLEXDPMLE1_DPMLETC_ML3_0(tc_port);
> - break;
> - default:
> - MISSING_CASE(pipe_config->lane_count);
> - }
> - I915_WRITE(PORT_TX_DFLEXDPMLE1, val);
> -}
> -
>  static void
>  intel_ddi_update_prepare(struct intel_atomic_state *state,
>struct intel_encoder *encoder,
> @@ -3657,7 +3626,6 @@ intel_ddi_pre_pll_enable(struct intel_encoder *encoder,
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
>   bool is_tc_port = intel_port_is_tc(dev_priv, encoder->port);
> - enum port port = encoder->port;
>  
>   if (is_tc_port)
>   intel_tc_port_get_link(dig_port, crtc_state->lane_count);
> @@ -3666,18 +3634,15 @@ intel_ddi_pre_pll_enable(struct intel_encoder 
> *encoder,
>   intel_display_power_get(dev_priv,
>   
> intel_ddi_main_link_aux_domain(dig_port));
>  
> - if (IS_GEN9_LP(dev_priv))
> + if (is_tc_port && dig_port->tc_mode != TC_PORT_TBT_ALT)
> + /*
> +  * Program the lane count for static/dynamic connections on
> +  * Type-C ports.  Skip this step for TBT.
> +  */
> + intel_tc_port_set_fia_lane_count(dig_port, 
> crtc_state->lane_count);
> + else if (IS_GEN9_LP(dev_priv))
>   bxt_ddi_phy_set_lane_optim_mask(encoder,
>   
> crtc_state->lane_lat_optim_mask);
> -
> - /*
> -  * Program the lane count for static/dynamic connections on Type-C 
> ports.
> -  * Skip this step for TBT.
> -  */
> - if (dig_port->tc_mode == TC_PORT_TBT_ALT)
> - return;
> -
> - intel_ddi_set_fia_lane_count(encoder, crtc_state, port);
>  }
>  
>  static void
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index e6e6163c1232..ba6932f48e90 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -68,6 +68,37 @@ int intel_tc_port_fia_max_lane_count(struct 
> intel_digital_port *dig_port)
>   }
>  }
>  
> +void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> +   int required_lanes)
> +{
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + enum tc_port tc_port = intel_port_to_tc(i915, 

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gem: Defer obj->base.resv fini until RCU callback

2019-07-04 Thread Chris Wilson
Quoting Mika Kuoppala (2019-07-04 14:53:09)
> Chris Wilson  writes:
> 
> > Since reservation_object_fini() does an immediate free, rather than
> > kfree_rcu as normal, we have to delay the release until after the RCU
> > grace period has elapsed (i.e. from the rcu cleanup callback) so that we
> > can rely on the RCU protected access to the fences while the object is a
> > zombie.
> >
> > i915_gem_busy_ioctl relies on having an RCU barrier to protect the
> > reservation in order to avoid having to take a reference and strong
> > memory barriers.
> 
> Ok so for gem busy to be able to operate on a 'to be freed' object
> we need to keep the reservation object alive?

Yup. It could equally be kept alive if resv_obj_fini used kfree_rcu()
instead, but we already need an RCU barrier for our object lookup so
might as well use one stone for both birds.

> > Fixes: c03467ba40f7 ("drm/i915/gem: Free pages before rcu-freeing the 
> > object")
> > Testcase: igt/gem_busy/close-race
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ++-
> >  drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 7 +++
> >  2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index d3e96f09c6b7..0dced4a20e20 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -152,6 +152,7 @@ static void __i915_gem_free_object_rcu(struct rcu_head 
> > *head)
> >   container_of(head, typeof(*obj), rcu);
> >   struct drm_i915_private *i915 = to_i915(obj->base.dev);
> >  
> > + reservation_object_fini(>base._resv);
> >   i915_gem_object_free(obj);
> >  
> >   GEM_BUG_ON(!atomic_read(>mm.free_count));
> > @@ -198,7 +199,7 @@ static void __i915_gem_free_objects(struct 
> > drm_i915_private *i915,
> >   if (obj->base.import_attach)
> >   drm_prime_gem_destroy(>base, NULL);
> >  
> > - drm_gem_object_release(>base);
> > + drm_gem_free_mmap_offset(>base);
> >  
> >   /* But keep the pointer alive for RCU-protected lookups */
> >   call_rcu(>rcu, __i915_gem_free_object_rcu);
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > index 19d9ecdb2894..d2a1158868e7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> > @@ -414,6 +414,11 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
> >   return 0;
> >  }
> >  
> > +static void shmem_release(struct drm_i915_gem_object *obj)
> > +{
> > + fput(obj->base.filp);
> 
> We lose the check for filp existence. But as internal
> ops have their own mechanics, we should always have the filp.

Exactly. drm_gem_object should not have filp anymore.

> We lose a warn for dma_buf existence tho.

Good. Let me hand you a tiny violin ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Extend BT2020 support in iCSC and fixes (rev5)

2019-07-04 Thread Shankar, Uma


>-Original Message-
>From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
>Sent: Wednesday, July 3, 2019 12:31 AM
>To: Shankar, Uma 
>Cc: intel-gfx@lists.freedesktop.org
>Subject: ✓ Fi.CI.IGT: success for Extend BT2020 support in iCSC and fixes 
>(rev5)
>
>== Series Details ==
>
>Series: Extend BT2020 support in iCSC and fixes (rev5)
>URL   : https://patchwork.freedesktop.org/series/60480/
>State : success

Hi Ville,
Can you please help merge this series. 

2 patches in series is already Rb'ed by you. I have addressed the comment in
the 3rd patch as well.

Thanks & Regards,
Uma Shankar

>== Summary ==
>
>CI Bug Log - changes from CI_DRM_6379_full -> Patchwork_13466_full
>
>
>Summary
>---
>
>  **SUCCESS**
>
>  No regressions found.
>
>
>
>Known issues
>
>
>  Here are the changes found in Patchwork_13466_full that come from known 
> issues:
>
>### IGT changes ###
>
> Issues hit 
>
>  * igt@gem_softpin@noreloc-s3:
>- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 
> similar issue
>   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>apl2/igt@gem_soft...@noreloc-s3.html
>   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>apl3/igt@gem_soft...@noreloc-s3.html
>
>  * igt@i915_suspend@sysfs-reader:
>- shard-kbl:  [PASS][3] -> [INCOMPLETE][4] ([fdo#103665] / 
> [fdo#108767])
>   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>kbl2/igt@i915_susp...@sysfs-reader.html
>   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>kbl1/igt@i915_susp...@sysfs-reader.html
>
>  * igt@kms_cursor_crc@pipe-b-cursor-256x256-onscreen:
>- shard-hsw:  [PASS][5] -> [INCOMPLETE][6] ([fdo#103540])
>   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>hsw7/igt@kms_cursor_...@pipe-b-cursor-256x256-onscreen.html
>   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>hsw6/igt@kms_cursor_...@pipe-b-cursor-256x256-onscreen.html
>
>  * igt@kms_flip@flip-vs-expired-vblank-interruptible:
>- shard-skl:  [PASS][7] -> [FAIL][8] ([fdo#105363])
>   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
>   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html
>
>  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite:
>- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +4 similar 
> issues
>   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html
>   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html
>
>  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
>- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([fdo#104108])
>   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>skl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
>   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
>
>  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
>- shard-skl:  [PASS][13] -> [FAIL][14] ([fdo#108145] / 
> [fdo#110403])
>   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
>   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>skl6/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
>
>  * igt@kms_psr@psr2_sprite_mmap_gtt:
>- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441])
>   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html
>   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>iclb3/igt@kms_psr@psr2_sprite_mmap_gtt.html
>
>  * igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
>- shard-glk:  [PASS][17] -> [DMESG-FAIL][18] ([fdo#105763] / 
> [fdo#106538])
>   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>glk7/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html
>   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>glk1/igt@kms_rotation_...@multiplane-rotation-cropping-bottom.html
>
>
> Possible fixes 
>
>  * igt@i915_selftest@mock_requests:
>- shard-skl:  [INCOMPLETE][19] ([fdo#110550]) -> [PASS][20]
>   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6379/shard-
>skl9/igt@i915_selftest@mock_requests.html
>   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13466/shard-
>skl4/igt@i915_selftest@mock_requests.html
>
>  * igt@i915_suspend@debugfs-reader:
>- shard-kbl:  [DMESG-WARN][21] 

Re: [Intel-gfx] [PATCH 2/4] drm/i915: fix include order in intel_tc.*

2019-07-04 Thread Imre Deak
On Wed, Jul 03, 2019 at 05:06:47PM -0700, Lucas De Marchi wrote:
> Make intel_tc.h the first include so we guarantee it's self-contained.
> Sort the rest. Same principle applies for includes in the header.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 5 +++--
>  drivers/gpu/drm/i915/display/intel_tc.h | 5 +++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 1a9dd32fb0a5..e6e6163c1232 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -3,10 +3,11 @@
>   * Copyright © 2019 Intel Corporation
>   */
>  
> +#include "intel_tc.h"

I get your point to keep the self-contained check work even without the
header test files, but I'm not sure if we need that, since there is the
header test file approach in place. I haven't seen this done anywhere
else, so we shouldn't make an exception here either imo.

+Jani for that.

Fixing the rest of my ABC screw-up looks ok.

> +
> +#include "i915_drv.h"
>  #include "intel_display.h"
>  #include "intel_dp_mst.h"
> -#include "i915_drv.h"
> -#include "intel_tc.h"
>  
>  static const char *tc_port_mode_name(enum tc_port_mode mode)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.h 
> b/drivers/gpu/drm/i915/display/intel_tc.h
> index 0d8411d4a91d..45ae30537b78 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.h
> +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> @@ -6,10 +6,11 @@
>  #ifndef __INTEL_TC_H__
>  #define __INTEL_TC_H__
>  
> -#include 
> -#include 
>  #include "intel_drv.h"
>  
> +#include 
> +#include 
> +
>  bool intel_tc_port_connected(struct intel_digital_port *dig_port);
>  u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
>  int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port);
> -- 
> 2.21.0
> 
___
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/gem: Defer obj->base.resv fini until RCU callback

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Since reservation_object_fini() does an immediate free, rather than
> kfree_rcu as normal, we have to delay the release until after the RCU
> grace period has elapsed (i.e. from the rcu cleanup callback) so that we
> can rely on the RCU protected access to the fences while the object is a
> zombie.
>
> i915_gem_busy_ioctl relies on having an RCU barrier to protect the
> reservation in order to avoid having to take a reference and strong
> memory barriers.

Ok so for gem busy to be able to operate on a 'to be freed' object
we need to keep the reservation object alive?

>
> Fixes: c03467ba40f7 ("drm/i915/gem: Free pages before rcu-freeing the object")
> Testcase: igt/gem_busy/close-race
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_object.c | 3 ++-
>  drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 7 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index d3e96f09c6b7..0dced4a20e20 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -152,6 +152,7 @@ static void __i915_gem_free_object_rcu(struct rcu_head 
> *head)
>   container_of(head, typeof(*obj), rcu);
>   struct drm_i915_private *i915 = to_i915(obj->base.dev);
>  
> + reservation_object_fini(>base._resv);
>   i915_gem_object_free(obj);
>  
>   GEM_BUG_ON(!atomic_read(>mm.free_count));
> @@ -198,7 +199,7 @@ static void __i915_gem_free_objects(struct 
> drm_i915_private *i915,
>   if (obj->base.import_attach)
>   drm_prime_gem_destroy(>base, NULL);
>  
> - drm_gem_object_release(>base);
> + drm_gem_free_mmap_offset(>base);
>  
>   /* But keep the pointer alive for RCU-protected lookups */
>   call_rcu(>rcu, __i915_gem_free_object_rcu);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 19d9ecdb2894..d2a1158868e7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -414,6 +414,11 @@ shmem_pwrite(struct drm_i915_gem_object *obj,
>   return 0;
>  }
>  
> +static void shmem_release(struct drm_i915_gem_object *obj)
> +{
> + fput(obj->base.filp);

We lose the check for filp existence. But as internal
ops have their own mechanics, we should always have the filp.

We lose a warn for dma_buf existence tho.
-Mika

> +}
> +
>  const struct drm_i915_gem_object_ops i915_gem_shmem_ops = {
>   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE |
>I915_GEM_OBJECT_IS_SHRINKABLE,
> @@ -424,6 +429,8 @@ const struct drm_i915_gem_object_ops i915_gem_shmem_ops = 
> {
>   .writeback = shmem_writeback,
>  
>   .pwrite = shmem_pwrite,
> +
> + .release = shmem_release,
>  };
>  
>  static int create_shmem(struct drm_i915_private *i915,
> -- 
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm/i915: make new intel_tc.c use uncore accessors

2019-07-04 Thread Imre Deak
On Wed, Jul 03, 2019 at 04:59:57PM -0700, Lucas De Marchi wrote:
> Let's make the just created intel_tc.c already follow the trend of using
> i915 instead of dev_priv and calling the intel_uncore_*() functions.
> 
> Signed-off-by: Lucas De Marchi 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 57 ++---
>  1 file changed, 31 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 53103a9aa8a7..1a9dd32fb0a5 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -24,11 +24,12 @@ static const char *tc_port_mode_name(enum tc_port_mode 
> mode)
>  
>  u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> + struct intel_uncore *uncore = >uncore;
>   u32 lane_mask;
>  
> - lane_mask = I915_READ(PORT_TX_DFLEXDPSP);
> + lane_mask = intel_uncore_read(uncore, PORT_TX_DFLEXDPSP);
>  
>   WARN_ON(lane_mask == 0x);
>  
> @@ -38,7 +39,7 @@ u32 intel_tc_port_get_lane_mask(struct intel_digital_port 
> *dig_port)
>  
>  int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>   intel_wakeref_t wakeref;
>   u32 lane_mask;
>  
> @@ -46,7 +47,7 @@ int intel_tc_port_fia_max_lane_count(struct 
> intel_digital_port *dig_port)
>   return 4;
>  
>   lane_mask = 0;
> - with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
>   lane_mask = intel_tc_port_get_lane_mask(dig_port);
>  
>   switch (lane_mask) {
> @@ -89,12 +90,13 @@ static void tc_port_fixup_legacy_flag(struct 
> intel_digital_port *dig_port,
>  
>  static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> + struct intel_uncore *uncore = >uncore;
>   u32 mask = 0;
>   u32 val;
>  
> - val = I915_READ(PORT_TX_DFLEXDPSP);
> + val = intel_uncore_read(uncore, PORT_TX_DFLEXDPSP);
>  
>   if (val == 0x) {
>   DRM_DEBUG_KMS("Port %s: PHY in TCCOLD, nothing connected\n",
> @@ -107,7 +109,7 @@ static u32 tc_port_live_status_mask(struct 
> intel_digital_port *dig_port)
>   if (val & TC_LIVE_STATE_TC(tc_port))
>   mask |= BIT(TC_PORT_DP_ALT);
>  
> - if (I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port))
> + if (intel_uncore_read(uncore, SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port))
>   mask |= BIT(TC_PORT_LEGACY);
>  
>   /* The sink can be connected only in a single mode. */
> @@ -119,11 +121,12 @@ static u32 tc_port_live_status_mask(struct 
> intel_digital_port *dig_port)
>  
>  static bool icl_tc_phy_status_complete(struct intel_digital_port *dig_port)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> + struct intel_uncore *uncore = >uncore;
>   u32 val;
>  
> - val = I915_READ(PORT_TX_DFLEXDPPMS);
> + val = intel_uncore_read(uncore, PORT_TX_DFLEXDPPMS);
>   if (val == 0x) {
>   DRM_DEBUG_KMS("Port %s: PHY in TCCOLD, assuming not complete\n",
> dig_port->tc_port_name);
> @@ -136,11 +139,12 @@ static bool icl_tc_phy_status_complete(struct 
> intel_digital_port *dig_port)
>  static bool icl_tc_phy_set_safe_mode(struct intel_digital_port *dig_port,
>bool enable)
>  {
> - struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + enum tc_port tc_port = intel_port_to_tc(i915, dig_port->base.port);
> + struct intel_uncore *uncore = >uncore;
>   u32 val;
>  
> - val = I915_READ(PORT_TX_DFLEXDPCSSS);
> + val = intel_uncore_read(uncore, PORT_TX_DFLEXDPCSSS);
>   if (val == 0x) {
>   

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Handle double alloc failures

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/gtt: Handle double alloc failures
URL   : https://patchwork.freedesktop.org/series/63223/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6410 -> Patchwork_13529


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_module_load@reload-no-display:
- fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-dsi/igt@i915_module_l...@reload-no-display.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/fi-icl-dsi/igt@i915_module_l...@reload-no-display.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][3] -> [FAIL][4] ([fdo#103167])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  * igt@prime_vgem@basic-fence-mmap:
- fi-icl-u3:  [PASS][5] -> [DMESG-WARN][6] ([fdo#107724])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/fi-icl-u3/igt@prime_v...@basic-fence-mmap.html

  
 Possible fixes 

  * igt@gem_basic@create-close:
- fi-icl-u3:  [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1 
similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u3/igt@gem_ba...@create-close.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/fi-icl-u3/igt@gem_ba...@create-close.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724


Participating hosts (53 -> 46)
--

  Additional (1): fi-skl-6260u 
  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-byt-clapper fi-bdw-samus fi-cml-u 


Build changes
-

  * Linux: CI_DRM_6410 -> Patchwork_13529

  CI_DRM_6410: 813df7e0ee11d1a97f45462bd48eaa3757c8c813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5082: f7c51e6fbf8da0784b64a1edaee5266aa9b9f829 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13529: e417d74d8e553d43457eeb828696409466376b6a @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

e417d74d8e55 drm/i915/gtt: Handle double alloc failures

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13529/
___
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: Flush the workqueue before draining

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-07-04 11:22:17)
>> Chris Wilson  writes:
>> 
>> > Trying to drain a workqueue while we may still be adding to it from
>> > background tasks is, according to kernel/workqueue.c, verboten. So, add
>> > a flush_workqueue() at the start of our cleanup procedure.
>> 
>> I don't get it. drain_workqueue does it's own flushing.
>
> Ordering is important here. The problem with drain_workqueue() is that
> is forbids us from adding more tasks into the workqueue as it drains, so
> before we drain we must plug.
>
> It's just adding more hammers. Eventually it'll break.

If so, then we just increase passes? :)

Ok, I was going to say we don't add to free work from
any of it's handlers.

But then realized this is not about the free list handling,
even tho the freed objects is drained along.

And yes, drain only handles flushing for it's chain.

Reviewed-by: Mika Kuoppala 

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

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Handle double alloc failures

2019-07-04 Thread Chris Wilson
Quoting Matthew Auld (2019-07-04 13:27:07)
> On Thu, 4 Jul 2019 at 11:43, Chris Wilson  wrote:
> >
> > Matthew pointed out that we could face a double failure with concurrent
> > allocations/frees, and so the assumption that the local var alloc was
> > NULL was fraught with danger. Rather than complicate the error paths too
> > much to add a second local for a second free, just do the second free
> > earlier on the unwind path.
> >
> > Reported-by: Matthew Auld 
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> 
> I quite liked your previous pattern:
> 
> @@ -1442,6 +1442,7 @@ static int gen8_ppgtt_alloc_pdp(struct
> i915_address_space *vm,
>  {
> struct i915_page_directory *pd, *alloc = NULL;
> u64 from = start;
> +   bool free = false;
> unsigned int pdpe;
> int ret = 0;
> 
> @@ -1489,10 +1490,11 @@ static int gen8_ppgtt_alloc_pdp(struct
> i915_address_space *vm,
> gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
> GEM_BUG_ON(!atomic_read(>used));
> atomic_dec(>used);
> -   GEM_BUG_ON(alloc);
> -   alloc = pd; /* defer the free to after the lock */
> +   free = true;
> }
> spin_unlock(>lock);
> +   if (free)
> +   free_pd(vm, pd);
>  unwind:
> gen8_ppgtt_clear_pdp(vm, pdp, from, start - from);
>  out:
> 
> Anyway,
> Reviewed-by: Matthew Auld 

I'm sure Mika is dying to rewrite these anyway, we can see what
solution he comes up with. :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gtt: Handle double alloc failures

2019-07-04 Thread Matthew Auld
On Thu, 4 Jul 2019 at 11:43, Chris Wilson  wrote:
>
> Matthew pointed out that we could face a double failure with concurrent
> allocations/frees, and so the assumption that the local var alloc was
> NULL was fraught with danger. Rather than complicate the error paths too
> much to add a second local for a second free, just do the second free
> earlier on the unwind path.
>
> Reported-by: Matthew Auld 
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 

I quite liked your previous pattern:

@@ -1442,6 +1442,7 @@ static int gen8_ppgtt_alloc_pdp(struct
i915_address_space *vm,
 {
struct i915_page_directory *pd, *alloc = NULL;
u64 from = start;
+   bool free = false;
unsigned int pdpe;
int ret = 0;

@@ -1489,10 +1490,11 @@ static int gen8_ppgtt_alloc_pdp(struct
i915_address_space *vm,
gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
GEM_BUG_ON(!atomic_read(>used));
atomic_dec(>used);
-   GEM_BUG_ON(alloc);
-   alloc = pd; /* defer the free to after the lock */
+   free = true;
}
spin_unlock(>lock);
+   if (free)
+   free_pd(vm, pd);
 unwind:
gen8_ppgtt_clear_pdp(vm, pdp, from, start - from);
 out:

Anyway,
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 2/3] drm/i915: Remove some legacy mmio accessors from interrupt handling

2019-07-04 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Mostly in gen11 interrupt handling and a couple neighbouring functions
which were easy since uncore local was already available.

Signed-off-by: Paulo Zanoni 
Co-developed-by: Paulo Zanoni 
Signed-off-by: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 75 +
 1 file changed, 39 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cb9cc9ceac2e..09df7e61815e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3479,12 +3479,12 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
struct intel_uncore *uncore = _priv->uncore;
 
if (IS_CHERRYVIEW(dev_priv))
-   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
+   intel_uncore_write(uncore, DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
else
-   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
+   intel_uncore_write(uncore, DPINVGTT, DPINVGTT_STATUS_MASK);
 
i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
-   I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
+   intel_uncore_write(uncore, PORT_HOTPLUG_STAT, 
I915_READ(PORT_HOTPLUG_STAT));
 
i9xx_pipestat_irq_reset(dev_priv);
 
@@ -3531,11 +3531,11 @@ static void ironlake_irq_reset(struct drm_i915_private 
*dev_priv)
 
GEN3_IRQ_RESET(uncore, DE);
if (IS_GEN(dev_priv, 7))
-   I915_WRITE(GEN7_ERR_INT, 0x);
+   intel_uncore_write(uncore, GEN7_ERR_INT, 0x);
 
if (IS_HASWELL(dev_priv)) {
-   I915_WRITE(EDP_PSR_IMR, 0x);
-   I915_WRITE(EDP_PSR_IIR, 0x);
+   intel_uncore_write(uncore, EDP_PSR_IMR, 0x);
+   intel_uncore_write(uncore, EDP_PSR_IIR, 0x);
}
 
gen5_gt_irq_reset(dev_priv);
@@ -3575,8 +3575,8 @@ static void gen8_irq_reset(struct drm_i915_private 
*dev_priv)
 
gen8_gt_irq_reset(dev_priv);
 
-   I915_WRITE(EDP_PSR_IMR, 0x);
-   I915_WRITE(EDP_PSR_IIR, 0x);
+   intel_uncore_write(uncore, EDP_PSR_IMR, 0x);
+   intel_uncore_write(uncore, EDP_PSR_IIR, 0x);
 
for_each_pipe(dev_priv, pipe)
if (intel_display_power_is_enabled(dev_priv,
@@ -3593,23 +3593,23 @@ static void gen8_irq_reset(struct drm_i915_private 
*dev_priv)
 
 static void gen11_gt_irq_reset(struct intel_gt *gt)
 {
-   struct drm_i915_private *dev_priv = gt->i915;
+   struct intel_uncore *uncore = gt->uncore;
 
/* Disable RCS, BCS, VCS and VECS class engines. */
-   I915_WRITE(GEN11_RENDER_COPY_INTR_ENABLE, 0);
-   I915_WRITE(GEN11_VCS_VECS_INTR_ENABLE,0);
+   intel_uncore_write(uncore, GEN11_RENDER_COPY_INTR_ENABLE, 0);
+   intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE,0);
 
/* Restore masks irqs on RCS, BCS, VCS and VECS engines. */
-   I915_WRITE(GEN11_RCS0_RSVD_INTR_MASK,   ~0);
-   I915_WRITE(GEN11_BCS_RSVD_INTR_MASK,~0);
-   I915_WRITE(GEN11_VCS0_VCS1_INTR_MASK,   ~0);
-   I915_WRITE(GEN11_VCS2_VCS3_INTR_MASK,   ~0);
-   I915_WRITE(GEN11_VECS0_VECS1_INTR_MASK, ~0);
-
-   I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
-   I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
-   I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0);
-   I915_WRITE(GEN11_GUC_SG_INTR_MASK,  ~0);
+   intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK,   ~0);
+   intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK,~0);
+   intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK,   ~0);
+   intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK,   ~0);
+   intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK, ~0);
+
+   intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
+   intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK,  ~0);
+   intel_uncore_write(uncore, GEN11_GUC_SG_INTR_ENABLE, 0);
+   intel_uncore_write(uncore, GEN11_GUC_SG_INTR_MASK,  ~0);
 }
 
 static void gen11_irq_reset(struct drm_i915_private *dev_priv)
@@ -3621,10 +3621,10 @@ static void gen11_irq_reset(struct drm_i915_private 
*dev_priv)
 
gen11_gt_irq_reset(_priv->gt);
 
-   I915_WRITE(GEN11_DISPLAY_INT_CTL, 0);
+   intel_uncore_write(uncore, GEN11_DISPLAY_INT_CTL, 0);
 
-   I915_WRITE(EDP_PSR_IMR, 0x);
-   I915_WRITE(EDP_PSR_IIR, 0x);
+   intel_uncore_write(uncore, EDP_PSR_IMR, 0x);
+   intel_uncore_write(uncore, EDP_PSR_IIR, 0x);
 
for_each_pipe(dev_priv, pipe)
if (intel_display_power_is_enabled(dev_priv,
@@ -4227,21 +4227,24 @@ static void gen8_irq_postinstall(struct 
drm_i915_private *dev_priv)
 
 static void gen11_gt_irq_postinstall(struct intel_gt *gt)
 {
-   struct 

[Intel-gfx] [CI 1/3] drm/i915: Rework some interrupt handling functions to take intel_gt

2019-07-04 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Some interrupt handling functions already have gt in their names
suggesting them as obvious candidates to make them take struct intel_gt
instead of i915.

Signed-off-by: Paulo Zanoni 
Co-developed-by: Paulo Zanoni 
Signed-off-by: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_irq.c | 88 +
 1 file changed, 46 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b5724ad38bf5..cb9cc9ceac2e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -305,17 +305,17 @@ void i915_hotplug_interrupt_update(struct 
drm_i915_private *dev_priv,
 }
 
 static u32
-gen11_gt_engine_identity(struct drm_i915_private * const i915,
+gen11_gt_engine_identity(struct intel_gt *gt,
 const unsigned int bank, const unsigned int bit);
 
-static bool gen11_reset_one_iir(struct drm_i915_private * const i915,
+static bool gen11_reset_one_iir(struct intel_gt *gt,
const unsigned int bank,
const unsigned int bit)
 {
-   void __iomem * const regs = i915->uncore.regs;
+   void __iomem * const regs = gt->uncore->regs;
u32 dw;
 
-   lockdep_assert_held(>irq_lock);
+   lockdep_assert_held(>i915->irq_lock);
 
dw = raw_reg_read(regs, GEN11_GT_INTR_DW(bank));
if (dw & BIT(bit)) {
@@ -323,7 +323,7 @@ static bool gen11_reset_one_iir(struct drm_i915_private * 
const i915,
 * According to the BSpec, DW_IIR bits cannot be cleared without
 * first servicing the Selector & Shared IIR registers.
 */
-   gen11_gt_engine_identity(i915, bank, bit);
+   gen11_gt_engine_identity(gt, bank, bit);
 
/*
 * We locked GT INT DW by reading it. If we want to (try
@@ -528,7 +528,7 @@ void gen11_reset_rps_interrupts(struct drm_i915_private 
*dev_priv)
 {
spin_lock_irq(_priv->irq_lock);
 
-   while (gen11_reset_one_iir(dev_priv, 0, GEN11_GTPM))
+   while (gen11_reset_one_iir(_priv->gt, 0, GEN11_GTPM))
;
 
dev_priv->gt_pm.rps.pm_iir = 0;
@@ -555,7 +555,7 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
WARN_ON_ONCE(rps->pm_iir);
 
if (INTEL_GEN(dev_priv) >= 11)
-   WARN_ON_ONCE(gen11_reset_one_iir(dev_priv, 0, GEN11_GTPM));
+   WARN_ON_ONCE(gen11_reset_one_iir(_priv->gt, 0, GEN11_GTPM));
else
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
 
@@ -635,7 +635,7 @@ void gen9_disable_guc_interrupts(struct drm_i915_private 
*dev_priv)
 void gen11_reset_guc_interrupts(struct drm_i915_private *i915)
 {
spin_lock_irq(>irq_lock);
-   gen11_reset_one_iir(i915, 0, GEN11_GUC);
+   gen11_reset_one_iir(>gt, 0, GEN11_GUC);
spin_unlock_irq(>irq_lock);
 }
 
@@ -646,7 +646,7 @@ void gen11_enable_guc_interrupts(struct drm_i915_private 
*dev_priv)
u32 events = REG_FIELD_PREP(ENGINE1_MASK,
GEN11_GUC_INTR_GUC2HOST);
 
-   WARN_ON_ONCE(gen11_reset_one_iir(dev_priv, 0, GEN11_GUC));
+   WARN_ON_ONCE(gen11_reset_one_iir(_priv->gt, 0, GEN11_GUC));
I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, events);
I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~events);
dev_priv->guc.interrupts.enabled = true;
@@ -3033,14 +3033,14 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
 }
 
 static u32
-gen11_gt_engine_identity(struct drm_i915_private * const i915,
+gen11_gt_engine_identity(struct intel_gt *gt,
 const unsigned int bank, const unsigned int bit)
 {
-   void __iomem * const regs = i915->uncore.regs;
+   void __iomem * const regs = gt->uncore->regs;
u32 timeout_ts;
u32 ident;
 
-   lockdep_assert_held(>irq_lock);
+   lockdep_assert_held(>i915->irq_lock);
 
raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));
 
@@ -3067,9 +3067,11 @@ gen11_gt_engine_identity(struct drm_i915_private * const 
i915,
 }
 
 static void
-gen11_other_irq_handler(struct drm_i915_private * const i915,
-   const u8 instance, const u16 iir)
+gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
+   const u16 iir)
 {
+   struct drm_i915_private *i915 = gt->i915;
+
if (instance == OTHER_GUC_INSTANCE)
return gen11_guc_irq_handler(i915, iir);
 
@@ -3081,13 +3083,13 @@ gen11_other_irq_handler(struct drm_i915_private * const 
i915,
 }
 
 static void
-gen11_engine_irq_handler(struct drm_i915_private * const i915,
-const u8 class, const u8 instance, const u16 iir)
+gen11_engine_irq_handler(struct intel_gt *gt, const u8 

[Intel-gfx] [CI 3/3] drm/i915: Move dev_priv->pm_i{m, e}r into intel_gt

2019-07-04 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

PM interrupts belong to the GT so move the variables to be inside
struct intel_gt.

Signed-off-by: Paulo Zanoni 
Co-developed-by: Paulo Zanoni 
Signed-off-by: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Reviewed-by: Chris Wilson 
Acked-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_gt_types.h   |   3 +
 drivers/gpu/drm/i915/gt/intel_ringbuffer.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.h|   2 -
 drivers/gpu/drm/i915/i915_irq.c| 121 +++--
 drivers/gpu/drm/i915/i915_irq.h|   4 +-
 5 files changed, 71 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index c03e56628ee2..37da428bef62 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -55,6 +55,9 @@ struct intel_gt {
ktime_t last_init_time;
 
struct i915_vma *scratch;
+
+   u32 pm_imr;
+   u32 pm_ier;
 };
 
 #endif /* __INTEL_GT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index f804ec35037d..b33cfc56f623 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -1040,14 +1040,14 @@ hsw_vebox_irq_enable(struct intel_engine_cs *engine)
/* Flush/delay to ensure the RING_IMR is active before the GT IMR */
ENGINE_POSTING_READ(engine, RING_IMR);
 
-   gen6_unmask_pm_irq(engine->i915, engine->irq_enable_mask);
+   gen6_unmask_pm_irq(engine->gt, engine->irq_enable_mask);
 }
 
 static void
 hsw_vebox_irq_disable(struct intel_engine_cs *engine)
 {
ENGINE_WRITE(engine, RING_IMR, ~0);
-   gen6_mask_pm_irq(engine->i915, engine->irq_enable_mask);
+   gen6_mask_pm_irq(engine->gt, engine->irq_enable_mask);
 }
 
 static int
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1a25813292cd..29c94c38ecc6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1403,8 +1403,6 @@ struct drm_i915_private {
u32 de_irq_mask[I915_MAX_PIPES];
};
u32 gt_irq_mask;
-   u32 pm_imr;
-   u32 pm_ier;
u32 pm_rps_events;
u32 pm_guc_events;
u32 pipestat_irq_mask[I915_MAX_PIPES];
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 09df7e61815e..7c5ba5cbea34 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -409,50 +409,54 @@ static i915_reg_t gen6_pm_iir(struct drm_i915_private 
*dev_priv)
return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
 }
 
-static void write_pm_imr(struct drm_i915_private *dev_priv)
+static void write_pm_imr(struct intel_gt *gt)
 {
+   struct drm_i915_private *i915 = gt->i915;
+   struct intel_uncore *uncore = gt->uncore;
+   u32 mask = gt->pm_imr;
i915_reg_t reg;
-   u32 mask = dev_priv->pm_imr;
 
-   if (INTEL_GEN(dev_priv) >= 11) {
+   if (INTEL_GEN(i915) >= 11) {
reg = GEN11_GPM_WGBOXPERF_INTR_MASK;
/* pm is in upper half */
mask = mask << 16;
-   } else if (INTEL_GEN(dev_priv) >= 8) {
+   } else if (INTEL_GEN(i915) >= 8) {
reg = GEN8_GT_IMR(2);
} else {
reg = GEN6_PMIMR;
}
 
-   I915_WRITE(reg, mask);
-   POSTING_READ(reg);
+   intel_uncore_write(uncore, reg, mask);
+   intel_uncore_posting_read(uncore, reg);
 }
 
-static void write_pm_ier(struct drm_i915_private *dev_priv)
+static void write_pm_ier(struct intel_gt *gt)
 {
+   struct drm_i915_private *i915 = gt->i915;
+   struct intel_uncore *uncore = gt->uncore;
+   u32 mask = gt->pm_ier;
i915_reg_t reg;
-   u32 mask = dev_priv->pm_ier;
 
-   if (INTEL_GEN(dev_priv) >= 11) {
+   if (INTEL_GEN(i915) >= 11) {
reg = GEN11_GPM_WGBOXPERF_INTR_ENABLE;
/* pm is in upper half */
mask = mask << 16;
-   } else if (INTEL_GEN(dev_priv) >= 8) {
+   } else if (INTEL_GEN(i915) >= 8) {
reg = GEN8_GT_IER(2);
} else {
reg = GEN6_PMIER;
}
 
-   I915_WRITE(reg, mask);
+   intel_uncore_write(uncore, reg, mask);
 }
 
 /**
  * snb_update_pm_irq - update GEN6_PMIMR
- * @dev_priv: driver private
+ * @gt: gt for the interrupts
  * @interrupt_mask: mask of interrupt bits to update
  * @enabled_irq_mask: mask of interrupt bits to enable
  */
-static void snb_update_pm_irq(struct drm_i915_private *dev_priv,
+static void snb_update_pm_irq(struct intel_gt *gt,
  u32 interrupt_mask,
  u32 enabled_irq_mask)
 {
@@ -460,37 +464,37 @@ static void snb_update_pm_irq(struct drm_i915_private 
*dev_priv,
 
WARN_ON(enabled_irq_mask & ~interrupt_mask);
 
-   

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4] drm/i915: Check caller held wakerefs in assert_forcewakes_active (rev4)

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [v4] drm/i915: Check caller held wakerefs in 
assert_forcewakes_active (rev4)
URL   : https://patchwork.freedesktop.org/series/63151/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6410 -> Patchwork_13528


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850:   [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html

  * igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3:  [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html

  * igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm:  [PASS][5] -> [DMESG-FAIL][6] ([fdo#111056])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html

  * igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u:   [PASS][7] -> [FAIL][8] ([fdo#109485])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][9] -> [FAIL][10] ([fdo#103167])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_basic@create-close:
- fi-icl-u3:  [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u3/igt@gem_ba...@create-close.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/fi-icl-u3/igt@gem_ba...@create-close.html

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

  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
  [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
  [fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
  [fdo#111056]: https://bugs.freedesktop.org/show_bug.cgi?id=111056


Participating hosts (53 -> 47)
--

  Additional (1): fi-skl-6260u 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6410 -> Patchwork_13528

  CI_DRM_6410: 813df7e0ee11d1a97f45462bd48eaa3757c8c813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5082: f7c51e6fbf8da0784b64a1edaee5266aa9b9f829 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13528: d908fd21005b833ddaa86924f41ba924409d65ba @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13528/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

d908fd21005b drm/i915/gt: Ignore forcewake acquisition for posting_reads
3140e61abb7b drm/i915/gt: Assume we hold forcewake for execlists resume
06ea77af838e drm/i915/gt: Use caller provided forcewake for 
intel_mocs_init_engine
0aa347b229cd drm/i915: Check caller held wakerefs in assert_forcewakes_active

== Logs ==

For more details see: 

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Rework some interrupt handling functions to take intel_gt

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Rework some interrupt handling 
functions to take intel_gt
URL   : https://patchwork.freedesktop.org/series/63116/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6404_full -> Patchwork_13504_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-apl:  [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +7 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-apl4/igt@i915_susp...@fence-restore-tiled2untiled.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_flip@absolute-wf_vblank:
- shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb6/igt@kms_flip@absolute-wf_vblank.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-iclb1/igt@kms_flip@absolute-wf_vblank.html

  * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-indfb-draw-mmap-gtt:
- shard-hsw:  [PASS][7] -> [INCOMPLETE][8] ([fdo#103540])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-hsw5/igt@kms_frontbuffer_track...@fbc-2p-primscrn-pri-indfb-draw-mmap-gtt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-hsw4/igt@kms_frontbuffer_track...@fbc-2p-primscrn-pri-indfb-draw-mmap-gtt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([fdo#104108])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-skl10/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103166])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-x.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar 
issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-iclb4/igt@kms_psr@psr2_primary_page_flip.html

  * igt@kms_setmode@basic:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([fdo#99912])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-kbl4/igt@kms_setm...@basic.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-kbl4/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@gem_busy@close-race:
- shard-skl:  [DMESG-FAIL][19] ([fdo#111063]) -> [PASS][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_b...@close-race.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-skl8/igt@gem_b...@close-race.html

  * igt@gem_softpin@noreloc-s3:
- shard-skl:  [INCOMPLETE][21] ([fdo#104108] / [fdo#107773]) -> 
[PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-skl1/igt@gem_soft...@noreloc-s3.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-skl8/igt@gem_soft...@noreloc-s3.html

  * igt@kms_cursor_legacy@2x-flip-vs-cursor-atomic:
- shard-glk:  [FAIL][23] ([fdo#104873]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6404/shard-glk2/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13504/shard-glk7/igt@kms_cursor_leg...@2x-flip-vs-cursor-atomic.html

  * 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: debugs logs for sink related failures

2019-07-04 Thread Patchwork
== Series Details ==

Series: drm/i915/hdcp: debugs logs for sink related failures
URL   : https://patchwork.freedesktop.org/series/63217/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_6410 -> Patchwork_13527


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13527/

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2:  [PASS][1] -> [FAIL][2] ([fdo#103167])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13527/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html

  
 Possible fixes 

  * igt@gem_basic@create-close:
- fi-icl-u3:  [DMESG-WARN][3] ([fdo#107724]) -> [PASS][4] +1 
similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6410/fi-icl-u3/igt@gem_ba...@create-close.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13527/fi-icl-u3/igt@gem_ba...@create-close.html

  
  [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
  [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724


Participating hosts (53 -> 45)
--

  Additional (1): fi-skl-6260u 
  Missing(9): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks 
fi-bsw-cyan fi-gdg-551 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6410 -> Patchwork_13527

  CI_DRM_6410: 813df7e0ee11d1a97f45462bd48eaa3757c8c813 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5082: f7c51e6fbf8da0784b64a1edaee5266aa9b9f829 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13527: b8ccc745fb9141d1fdea49231856456adf779fa1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13527/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux commits ==

b8ccc745fb91 drm/i915/hdcp: debugs logs for sink related failures

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13527/
___
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/gtt: Defer the free for alloc error paths

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Mika Kuoppala (2019-07-04 11:58:38)
>> Chris Wilson  writes:
>> 
>> > Quoting Matthew Auld (2019-07-04 11:28:18)
>> >> On 03/07/2019 18:19, Chris Wilson wrote:
>> >> > If we hit an error while allocating the page tables, we have to unwind
>> >> > the incomplete updates, and wish to free the unused pd. However, we are
>> >> > not allowed to be hoding the spinlock at that point, and so must use the
>> >> 
>> >> holding
>> >> 
>> >> > later free to defer it until after we drop the lock.
>> >> > 
>> >> > <3> [414.363795] BUG: sleeping function called from invalid context at 
>> >> > drivers/gpu/drm/i915/i915_gem_gtt.c:472
>> >> > <3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: 
>> >> > i915_selftest
>> >> > <4> [414.364406] 3 locks held by i915_selftest/3905:
>> >> > <4> [414.364408]  #0: 34fe8aa8 (>mutex){}, at: 
>> >> > device_driver_attach+0x18/0x50
>> >> > <4> [414.364415]  #1: 6bd8a560 (>struct_mutex){+.+.}, at: 
>> >> > igt_ctx_exec+0xb7/0x410 [i915]
>> >> > <4> [414.364476]  #2: 3dfdc766 (&(>lock)->rlock){+.+.}, at: 
>> >> > gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
>> >> > <3> [414.364529] Preemption disabled at:
>> >> > <4> [414.364530] [<>] 0x0
>> >> > <4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U  
>> >> >   5.2.0-rc7-CI-CI_DRM_6403+ #1
>> >> > <4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
>> >> > BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
>> >> > <4> [414.364699] Call Trace:
>> >> > <4> [414.364704]  dump_stack+0x67/0x9b
>> >> > <4> [414.364708]  ___might_sleep+0x167/0x250
>> >> > <4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
>> >> > <4> [414.364852]  free_pd+0xf/0x20 [i915]
>> >> > <4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
>> >> > <4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
>> >> > <4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
>> >> > <4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
>> >> > <4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]
>> >> > 
>> >> > Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation 
>> >> > for allocation")
>> >> > Signed-off-by: Chris Wilson 
>> >> > Cc: Matthew Auld 
>> >> > Cc: Mika Kuoppala 
>> >> > ---
>> >> >   drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
>> >> >   1 file changed, 4 insertions(+), 2 deletions(-)
>> >> > 
>> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
>> >> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> > index 9e76347e039e..1065753e86fb 100644
>> >> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> > @@ -1489,7 +1489,8 @@ static int gen8_ppgtt_alloc_pdp(struct 
>> >> > i915_address_space *vm,
>> >> >   gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
>> >> >   GEM_BUG_ON(!atomic_read(>used));
>> >> >   atomic_dec(>used);
>> >> > - free_pd(vm, pd);
>> >> > + GEM_BUG_ON(alloc);
>> >> 
>> >> Pretty sure it's possible for alloc != NULL at this point...two threads, 
>> >> one is late to the party, we are unlucky and hit the unwind_pd path. No?
>> >
>> > Hmm. I was thinking we would only get here on an alloc failure path, but
>> > yeah, the BUG_ON was a case for doubt.
>> 
>> Am I staring at the wrong spot then. I thought the atomic_inc(_used)
>> saves us.
>
> It's on another entry in our table. So we threads A|B fighting over
> pdpe:0 and B|C fighting over pdpe:1, and if B loses the first race and
> the race with C results in an error...

/o\

I do see it now, thanks.
-MIka
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 10/11] drm/hdcp: update content protection property with uevent

2019-07-04 Thread Pekka Paalanen
On Tue,  7 May 2019 21:57:44 +0530
Ramalingam C  wrote:

> drm function is defined and exported to update a connector's
> content protection property state and to generate a uevent along
> with it.
> 
> Need ACK for the uevent from userspace consumer.
> 
> v2:
>   Update only when state is different from old one.
> v3:
>   KDoc is added [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_hdcp.c | 32 
>  include/drm/drm_hdcp.h |  2 ++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
> index 75402463466b..f29b7abda51f 100644
> --- a/drivers/gpu/drm/drm_hdcp.c
> +++ b/drivers/gpu/drm/drm_hdcp.c
> @@ -372,6 +372,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
>   *
>   * The content protection will be set to 
> _connector_state.content_protection
>   *
> + * When kernel triggered content protection state change like 
> DESIRED->ENABLED
> + * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to 
> update
> + * the content protection state of a connector.
> + *
>   * Returns:
>   * Zero on success, negative errno on failure.
>   */
> @@ -412,3 +416,31 @@ int drm_connector_attach_content_protection_property(
>   return 0;
>  }
>  EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
> +
> +/**
> + * drm_hdcp_update_content_protection - Updates the content protection state
> + * of a connector
> + *
> + * @connector: drm_connector on which content protection state needs an 
> update
> + * @val: New state of the content protection property
> + *
> + * This function can be used by display drivers, to update the kernel 
> triggered
> + * content protection state change of a drm_connector. This function update 
> the
> + * new state of the property into the connector's state and generate an 
> uevent
> + * to notify the userspace.
> + */
> +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> + u64 val)
> +{

Hi,

don't you need to ensure that 'val' cannot be UNDESIRED?

> + struct drm_device *dev = connector->dev;
> + struct drm_connector_state *state = connector->state;
> +
> + WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> + if (state->content_protection == val)
> + return;
> +
> + state->content_protection = val;
> + drm_sysfs_connector_status_event(connector,
> +  dev->mode_config.content_protection_property);
> +}
> +EXPORT_SYMBOL(drm_hdcp_update_content_protection);
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index 2970abdfaf12..dd864ac9ce85 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
>u8 *ksvs, u32 ksv_count);
>  int drm_connector_attach_content_protection_property(
>   struct drm_connector *connector, bool hdcp_content_type);
> +void drm_hdcp_update_content_protection(struct drm_connector *connector,
> + u64 val);
>  #endif

This patch is missing all UAPI documentation.

Particularly important is the detail that the kernel will not send an
event corresponding to userspace explicitly setting "Content
Protection" to "Undesired". That is what you explained to me in the
Weston MR !48, but I don't actually see it in the code here. It would
be best to enforce that in the shared DRM code.


Thanks,
pq


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

Re: [Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change

2019-07-04 Thread Pekka Paalanen
On Tue,  7 May 2019 21:57:43 +0530
Ramalingam C  wrote:

> DRM API for generating uevent for a status changes of connector's
> property.
> 
> This uevent will have following details related to the status change:
> 
>   HOTPLUG=1, CONNECTOR= and PROPERTY=
> 
> Need ACK from this uevent from userspace consumer.
> 
> v2:
>   Minor fixes at KDoc comments [Daniel]
> v3:
>   Check the property is really attached with connector [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_sysfs.c | 35 +++
>  include/drm/drm_sysfs.h |  5 -
>  2 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index 18b1ac442997..63fa951a20db 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include "drm_internal.h"
> +#include "drm_crtc_internal.h"
>  
>  #define to_drm_minor(d) dev_get_drvdata(d)
>  #define to_drm_connector(d) dev_get_drvdata(d)
> @@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
>   * Send a uevent for the DRM device specified by @dev.  Currently we only
>   * set HOTPLUG=1 in the uevent environment, but this could be expanded to
>   * deal with other types of events.
> + *
> + * Any new uapi should be using the drm_sysfs_connector_status_event()
> + * for uevents on connector status change.
>   */
>  void drm_sysfs_hotplug_event(struct drm_device *dev)
>  {
> @@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_sysfs_hotplug_event);
>  
> +/**
> + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> + * property status change
> + * @connector: connector on which property status changed
> + * @property: connector property whoes status changed.
> + *
> + * Send a uevent for the DRM device specified by @dev.  Currently we
> + * set HOTPLUG=1 and connector id along with the attached property id
> + * related to the status change.
> + */
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +   struct drm_property *property)
> +{
> + struct drm_device *dev = connector->dev;
> + char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
> + char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> +
> + WARN_ON(!drm_mode_obj_find_prop_id(>base,
> +property->base.id));
> +
> + snprintf(conn_id, ARRAY_SIZE(conn_id),
> +  "CONNECTOR=%u", connector->base.id);
> + snprintf(prop_id, ARRAY_SIZE(prop_id),
> +  "PROPERTY=%u", property->base.id);
> +
> + DRM_DEBUG("generating connector status event\n");
> +
> + kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
> +}
> +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
> +
>  static void drm_sysfs_release(struct device *dev)
>  {
>   kfree(dev);
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 4f311e836cdc..d454ef617b2c 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -4,10 +4,13 @@
>  
>  struct drm_device;
>  struct device;
> +struct drm_connector;
> +struct drm_property;
>  
>  int drm_class_device_register(struct device *dev);
>  void drm_class_device_unregister(struct device *dev);
>  
>  void drm_sysfs_hotplug_event(struct drm_device *dev);
> -
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> +   struct drm_property *property);
>  #endif

Hi,

this patch is completely missing the UAPI documentation.

Weston in
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
does have good looking code to parse this event.


Thanks,
pq


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

Re: [Intel-gfx] [PATCH v7 07/11] drm: Add Content protection type property

2019-07-04 Thread Pekka Paalanen
On Tue,  7 May 2019 21:57:41 +0530
Ramalingam C  wrote:

> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
> 
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
> 
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
> 
> Need ACK for this new conenctor property from userspace consumer.
> 
> v2:
>   cp_content_type is replaced with content_protection_type [daniel]
>   check at atomic_set_property is removed [Maarten]
> v3:
>   %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
>   property is created for the first requested connector and then reused.
>   [Danvet]
> v5:
>   kernel doc nits addressed [Daniel]
>   Rebased as part of patch reordering.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_uapi.c |  4 
>  drivers/gpu/drm/drm_connector.c   | 18 
>  drivers/gpu/drm/drm_hdcp.c| 36 ++-
>  drivers/gpu/drm/i915/intel_hdcp.c |  4 +++-
>  include/drm/drm_connector.h   |  7 ++
>  include/drm/drm_hdcp.h|  2 +-
>  include/drm/drm_mode_config.h |  6 ++
>  include/uapi/drm/drm_mode.h   |  4 
>  8 files changed, 78 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 4131e669785a..a85f3ccfe699 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -738,6 +738,8 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   return -EINVAL;
>   }
>   state->content_protection = val;
> + } else if (property == config->hdcp_content_type_property) {
> + state->hdcp_content_type = val;
>   } else if (property == connector->colorspace_property) {
>   state->colorspace = val;
>   } else if (property == config->writeback_fb_id_property) {
> @@ -816,6 +818,8 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->scaling_mode;
>   } else if (property == config->content_protection_property) {
>   *val = state->content_protection;
> + } else if (property == config->hdcp_content_type_property) {
> + *val = state->hdcp_content_type;
>   } else if (property == config->writeback_fb_id_property) {
>   /* Writeback framebuffer is one-shot, write and forget */
>   *val = 0;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 764c7903edf6..de9e06583e8c 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c

Hi,

below I have some comments and questions before I can say whether
https://gitlab.freedesktop.org/wayland/weston/merge_requests/48
adheres to this specification.

> @@ -955,6 +955,24 @@ static const struct drm_prop_enum_list 
> hdmi_colorspaces[] = {
>   * the value transitions from ENABLED to DESIRED. This signifies the link
>   * is no longer protected and userspace should take appropriate action
>   * (whatever that might be).
> + * HDCP Content Type:
> + *   This property is used by the userspace to configure the kernel with
> + *   to be displayed stream's content type. Content Type of a stream is
> + *   decided by the owner of the stream, as HDCP Type0 or HDCP Type1.
> + *
> + *   The value of the property can be one the below:
> + * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0

If this doc is meant as the UAPI doc, it needs to use the string names
for enum property values, not the C language definitions (integers).

> + *   HDCP Type0 streams can be transmitted on a link which is
> + *   encrypted with HDCP 1.4 or HDCP 2.2.

This wording forbids using any future HDCP version for type0.

> + * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> + *   HDCP Type1 streams can be transmitted on a link which is
> + *   encrypted only with HDCP 2.2.

This wording forbids using any future HDCP version for type1.

> + *
> + *   Note that the HDCP Content Type property is specific to HDCP 2.2, and
> + *   defaults to type 0. It is only exposed by drivers supporting HDCP 2.2

Not possible with a future HDCP version greater than 2.2?

Is it intended to be possible to add more content types in the future?

> + *   If content type is changed when content_protection is not UNDESIRED,
> + *   then kernel will disable the HDCP and re-enable with new type in the
> + *   same atomic commit

Ok, very good to mention this.

>   *
>   * max bpc:
>   *   

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gtt: Defer the free for alloc error paths

2019-07-04 Thread Chris Wilson
Quoting Mika Kuoppala (2019-07-04 11:58:38)
> Chris Wilson  writes:
> 
> > Quoting Matthew Auld (2019-07-04 11:28:18)
> >> On 03/07/2019 18:19, Chris Wilson wrote:
> >> > If we hit an error while allocating the page tables, we have to unwind
> >> > the incomplete updates, and wish to free the unused pd. However, we are
> >> > not allowed to be hoding the spinlock at that point, and so must use the
> >> 
> >> holding
> >> 
> >> > later free to defer it until after we drop the lock.
> >> > 
> >> > <3> [414.363795] BUG: sleeping function called from invalid context at 
> >> > drivers/gpu/drm/i915/i915_gem_gtt.c:472
> >> > <3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: 
> >> > i915_selftest
> >> > <4> [414.364406] 3 locks held by i915_selftest/3905:
> >> > <4> [414.364408]  #0: 34fe8aa8 (>mutex){}, at: 
> >> > device_driver_attach+0x18/0x50
> >> > <4> [414.364415]  #1: 6bd8a560 (>struct_mutex){+.+.}, at: 
> >> > igt_ctx_exec+0xb7/0x410 [i915]
> >> > <4> [414.364476]  #2: 3dfdc766 (&(>lock)->rlock){+.+.}, at: 
> >> > gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
> >> > <3> [414.364529] Preemption disabled at:
> >> > <4> [414.364530] [<>] 0x0
> >> > <4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U   
> >> >  5.2.0-rc7-CI-CI_DRM_6403+ #1
> >> > <4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> >> > BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> >> > <4> [414.364699] Call Trace:
> >> > <4> [414.364704]  dump_stack+0x67/0x9b
> >> > <4> [414.364708]  ___might_sleep+0x167/0x250
> >> > <4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
> >> > <4> [414.364852]  free_pd+0xf/0x20 [i915]
> >> > <4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
> >> > <4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
> >> > <4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
> >> > <4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
> >> > <4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]
> >> > 
> >> > Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation 
> >> > for allocation")
> >> > Signed-off-by: Chris Wilson 
> >> > Cc: Matthew Auld 
> >> > Cc: Mika Kuoppala 
> >> > ---
> >> >   drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
> >> >   1 file changed, 4 insertions(+), 2 deletions(-)
> >> > 
> >> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> >> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> > index 9e76347e039e..1065753e86fb 100644
> >> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> > @@ -1489,7 +1489,8 @@ static int gen8_ppgtt_alloc_pdp(struct 
> >> > i915_address_space *vm,
> >> >   gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
> >> >   GEM_BUG_ON(!atomic_read(>used));
> >> >   atomic_dec(>used);
> >> > - free_pd(vm, pd);
> >> > + GEM_BUG_ON(alloc);
> >> 
> >> Pretty sure it's possible for alloc != NULL at this point...two threads, 
> >> one is late to the party, we are unlucky and hit the unwind_pd path. No?
> >
> > Hmm. I was thinking we would only get here on an alloc failure path, but
> > yeah, the BUG_ON was a case for doubt.
> 
> Am I staring at the wrong spot then. I thought the atomic_inc(_used)
> saves us.

It's on another entry in our table. So we threads A|B fighting over
pdpe:0 and B|C fighting over pdpe:1, and if B loses the first race and
the race with C results in an error...
-Chris
___
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/gtt: Defer the free for alloc error paths

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Matthew Auld (2019-07-04 11:28:18)
>> On 03/07/2019 18:19, Chris Wilson wrote:
>> > If we hit an error while allocating the page tables, we have to unwind
>> > the incomplete updates, and wish to free the unused pd. However, we are
>> > not allowed to be hoding the spinlock at that point, and so must use the
>> 
>> holding
>> 
>> > later free to defer it until after we drop the lock.
>> > 
>> > <3> [414.363795] BUG: sleeping function called from invalid context at 
>> > drivers/gpu/drm/i915/i915_gem_gtt.c:472
>> > <3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: 
>> > i915_selftest
>> > <4> [414.364406] 3 locks held by i915_selftest/3905:
>> > <4> [414.364408]  #0: 34fe8aa8 (>mutex){}, at: 
>> > device_driver_attach+0x18/0x50
>> > <4> [414.364415]  #1: 6bd8a560 (>struct_mutex){+.+.}, at: 
>> > igt_ctx_exec+0xb7/0x410 [i915]
>> > <4> [414.364476]  #2: 3dfdc766 (&(>lock)->rlock){+.+.}, at: 
>> > gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
>> > <3> [414.364529] Preemption disabled at:
>> > <4> [414.364530] [<>] 0x0
>> > <4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U 
>> >5.2.0-rc7-CI-CI_DRM_6403+ #1
>> > <4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
>> > BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
>> > <4> [414.364699] Call Trace:
>> > <4> [414.364704]  dump_stack+0x67/0x9b
>> > <4> [414.364708]  ___might_sleep+0x167/0x250
>> > <4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
>> > <4> [414.364852]  free_pd+0xf/0x20 [i915]
>> > <4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
>> > <4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
>> > <4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
>> > <4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
>> > <4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]
>> > 
>> > Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
>> > allocation")
>> > Signed-off-by: Chris Wilson 
>> > Cc: Matthew Auld 
>> > Cc: Mika Kuoppala 
>> > ---
>> >   drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
>> >   1 file changed, 4 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
>> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> > index 9e76347e039e..1065753e86fb 100644
>> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> > @@ -1489,7 +1489,8 @@ static int gen8_ppgtt_alloc_pdp(struct 
>> > i915_address_space *vm,
>> >   gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
>> >   GEM_BUG_ON(!atomic_read(>used));
>> >   atomic_dec(>used);
>> > - free_pd(vm, pd);
>> > + GEM_BUG_ON(alloc);
>> 
>> Pretty sure it's possible for alloc != NULL at this point...two threads, 
>> one is late to the party, we are unlucky and hit the unwind_pd path. No?
>
> Hmm. I was thinking we would only get here on an alloc failure path, but
> yeah, the BUG_ON was a case for doubt.

Am I staring at the wrong spot then. I thought the atomic_inc(_used)
saves us.

-Mika


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

Re: [Intel-gfx] [PATCH] drm: allow render capable master with DRM_AUTH ioctls

2019-07-04 Thread Michel Dänzer
On 2019-07-03 7:10 p.m., Emil Velikov wrote:
> From: Emil Velikov 
> 
> There are cases (in mesa and applications) where one would open the
> primary node without properly authenticating the client.
> 
> Sometimes we don't check if the authentication succeeds, but there's
> also cases we simply forget to do it.
> 
> The former was a case for Mesa where it did not not check the return
> value of drmGetMagic() [1]. That was fixed recently although, there's
> the question of older drivers or other apps that exbibit this behaviour.
> 
> While omitting the call results in issues as seen in [2] and [3].
> 
> In the libva case, libva itself doesn't authenticate the DRM client and
> the vaGetDisplayDRM documentation doesn't mention if the app should
> either.
> 
> As of today, the official vainfo utility doesn't authenticate.
> 
> To workaround issues like these, some users resort to running their apps
> under sudo. Which admittedly isn't always a good idea.
> 
> Since any DRIVER_RENDER driver has sufficient isolation between clients,
> we can use that, for unauthenticated [primary node] ioctls that require
> DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW.
> 
> v2:
> - Rework/simplify if check (Daniel V)
> - Add examples to commit messages, elaborate. (Daniel V)
> 
> v3:
> - Use single unlikely (Daniel V)
> 
> v4:
> - Reapply patch, check for amdgpu/radeon inline.
> 
> [1] 
> https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136
> [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html
> [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1
> Testcase: igt/core_unauth_vs_render
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Daniel Vetter 
> Signed-off-by: Emil Velikov 
> Reviewed-by: Daniel Vetter 

As discussed on IRC, IMHO this change requires more justification.

The system I'm writing this on has vainfo 2.4.0 installed, which opens a
render node and works fine without this change.

Similarly, if kmscube hasn't been fixed to use a render node yet, surely
it easily can.

You're asserting that the problem is wide-spread, and that fixing all
broken userspace isn't feasible, but I haven't seen any evidence
supporting that.

Since this change is essentially a workaround for broken userspace which
can never have worked, and has the potential of subverting the ongoing
transition from using primary nodes to render nodes in userspace code,
there needs to be evidence supporting that the benefit outweighs the risk.


-- 
Earthling Michel Dänzer   |  https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 04/11] drm: revocation check at drm subsystem

2019-07-04 Thread Pekka Paalanen
On Tue,  7 May 2019 21:57:38 +0530
Ramalingam C  wrote:

> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
> 
> SRM table is parsed and stored at drm_hdcp.c, with functions exported
> for the services for revocation check from drivers (which
> implements the HDCP authentication)
> 
> This patch handles the HDCP1.4 and 2.2 versions of SRM table.
> 
> v2:
>   moved the uAPI to request_firmware_direct() [Daniel]
> v3:
>   kdoc added. [Daniel]
>   srm_header unified and bit field definitions are removed. [Daniel]
>   locking improved. [Daniel]
>   vrl length violation is fixed. [Daniel]
> v4:
>   s/__swab16/be16_to_cpu [Daniel]
>   be24_to_cpu is done through a global func [Daniel]
>   Unused variables are removed. [Daniel]
>   unchecked return values are dropped from static funcs [Daniel]
> 
> Signed-off-by: Ramalingam C 
> Acked-by: Satyeshwar Singh 
> Reviewed-by: Daniel Vetter 
> ---
>  Documentation/gpu/drm-kms-helpers.rst |   6 +
>  drivers/gpu/drm/Makefile  |   2 +-
>  drivers/gpu/drm/drm_hdcp.c| 333 ++
>  drivers/gpu/drm/drm_internal.h|   4 +
>  drivers/gpu/drm/drm_sysfs.c   |   2 +
>  include/drm/drm_hdcp.h|  24 ++
>  6 files changed, 370 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/drm_hdcp.c
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 14102ae035dc..0fe726a6ee67 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -181,6 +181,12 @@ Panel Helper Reference
>  .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
> :export:
>  
> +HDCP Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
> +   :export:
> +
>  Display Port Helper Functions Reference
>  ===
>  

...

> +/**
> + * drm_hdcp_check_ksvs_revoked - Check the revoked status of the IDs
> + *
> + * @drm_dev: drm_device for which HDCP revocation check is requested
> + * @ksvs: List of KSVs (HDCP receiver IDs)
> + * @ksv_count: KSV count passed in through @ksvs
> + *
> + * This function reads the HDCP System renewability Message(SRM Table)
> + * from userspace as a firmware and parses it for the revoked HDCP
> + * KSVs(Receiver IDs) detected by DCP LLC. Once the revoked KSVs are known,
> + * revoked state of the KSVs in the list passed in by display drivers are
> + * decided and response is sent.
> + *
> + * SRM should be presented in the name of "display_hdcp_srm.bin".
> + *
> + * Returns:
> + * TRUE on any of the KSV is revoked, else FALSE.

Hi,

this does not seem to be specifying the file format. Since this file is
expected to be provided by vendors and not the driver developers AFAIU,
I think the file format counts as UAPI and needs to be explicitly and
unambiguously specified. Especially as the file or the file format are
not tied to a specific DRM driver or any driver. A searchable reference
to a particular revision of a public specification document could
suffice if such exists.

This doc comment is only kernel internal API. I would also expect UAPI
documentation for the same reason as above.

The Weston work[1] does not validate the UAPI added in this patch.


[1] https://gitlab.freedesktop.org/wayland/weston/merge_requests/48

Thanks,
pq

> + */
> +bool drm_hdcp_check_ksvs_revoked(struct drm_device *drm_dev, u8 *ksvs,
> +  u32 ksv_count)
> +{
> + u32 rev_ksv_cnt, cnt, i, j;
> + u8 *rev_ksv_list;
> +
> + if (!srm_data)
> + return false;
> +
> + mutex_lock(_data->mutex);
> + drm_hdcp_request_srm(drm_dev);
> +
> + rev_ksv_cnt = srm_data->revoked_ksv_cnt;
> + rev_ksv_list = srm_data->revoked_ksv_list;
> +
> + /* If the Revoked ksv list is empty */
> + if (!rev_ksv_cnt || !rev_ksv_list) {
> + mutex_unlock(_data->mutex);
> + return false;
> + }
> +
> + for  (cnt = 0; cnt < ksv_count; cnt++) {
> + rev_ksv_list = srm_data->revoked_ksv_list;
> + for (i = 0; i < rev_ksv_cnt; i++) {
> + for (j = 0; j < DRM_HDCP_KSV_LEN; j++)
> + if (ksvs[j] != rev_ksv_list[j]) {
> + break;
> + } else if (j == (DRM_HDCP_KSV_LEN - 1)) {
> + DRM_DEBUG("Revoked KSV is ");
> + drm_hdcp_print_ksv(ksvs);
> + mutex_unlock(_data->mutex);
> + return true;
> + }
> + /* Move the offset to next KSV in the revoked list */
> + rev_ksv_list += DRM_HDCP_KSV_LEN;
> + }
> +
> + /* Iterate to next ksv_offset */
> + ksvs += 

[Intel-gfx] [PATCH] drm/i915/gtt: Handle double alloc failures

2019-07-04 Thread Chris Wilson
Matthew pointed out that we could face a double failure with concurrent
allocations/frees, and so the assumption that the local var alloc was
NULL was fraught with danger. Rather than complicate the error paths too
much to add a second local for a second free, just do the second free
earlier on the unwind path.

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

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1065753e86fb..9756f1b670e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1484,6 +1484,10 @@ static int gen8_ppgtt_alloc_pdp(struct 
i915_address_space *vm,
goto out;
 
 unwind_pd:
+   if (alloc) {
+   free_pd(vm, alloc);
+   alloc = NULL;
+   }
spin_lock(>lock);
if (atomic_dec_and_test(>used)) {
gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
@@ -1556,6 +1560,10 @@ static int gen8_ppgtt_alloc_4lvl(struct 
i915_address_space *vm,
goto out;
 
 unwind_pdp:
+   if (alloc) {
+   free_pd(vm, alloc);
+   alloc = NULL;
+   }
spin_lock(>lock);
if (atomic_dec_and_test(>used)) {
gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
-- 
2.20.1

___
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/gtt: Defer the free for alloc error paths

2019-07-04 Thread Chris Wilson
Quoting Matthew Auld (2019-07-04 11:28:18)
> On 03/07/2019 18:19, Chris Wilson wrote:
> > If we hit an error while allocating the page tables, we have to unwind
> > the incomplete updates, and wish to free the unused pd. However, we are
> > not allowed to be hoding the spinlock at that point, and so must use the
> 
> holding
> 
> > later free to defer it until after we drop the lock.
> > 
> > <3> [414.363795] BUG: sleeping function called from invalid context at 
> > drivers/gpu/drm/i915/i915_gem_gtt.c:472
> > <3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: 
> > i915_selftest
> > <4> [414.364406] 3 locks held by i915_selftest/3905:
> > <4> [414.364408]  #0: 34fe8aa8 (>mutex){}, at: 
> > device_driver_attach+0x18/0x50
> > <4> [414.364415]  #1: 6bd8a560 (>struct_mutex){+.+.}, at: 
> > igt_ctx_exec+0xb7/0x410 [i915]
> > <4> [414.364476]  #2: 3dfdc766 (&(>lock)->rlock){+.+.}, at: 
> > gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
> > <3> [414.364529] Preemption disabled at:
> > <4> [414.364530] [<>] 0x0
> > <4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U  
> >   5.2.0-rc7-CI-CI_DRM_6403+ #1
> > <4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> > BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> > <4> [414.364699] Call Trace:
> > <4> [414.364704]  dump_stack+0x67/0x9b
> > <4> [414.364708]  ___might_sleep+0x167/0x250
> > <4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
> > <4> [414.364852]  free_pd+0xf/0x20 [i915]
> > <4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
> > <4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
> > <4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
> > <4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
> > <4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]
> > 
> > Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
> > allocation")
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > Cc: Mika Kuoppala 
> > ---
> >   drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 9e76347e039e..1065753e86fb 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -1489,7 +1489,8 @@ static int gen8_ppgtt_alloc_pdp(struct 
> > i915_address_space *vm,
> >   gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
> >   GEM_BUG_ON(!atomic_read(>used));
> >   atomic_dec(>used);
> > - free_pd(vm, pd);
> > + GEM_BUG_ON(alloc);
> 
> Pretty sure it's possible for alloc != NULL at this point...two threads, 
> one is late to the party, we are unlucky and hit the unwind_pd path. No?

Hmm. I was thinking we would only get here on an alloc failure path, but
yeah, the BUG_ON was a case for doubt.

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

Re: [Intel-gfx] [PATCH] drm/i915: Move the renderstate setup under gt/

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> The render state is used to initialise the default RCS context, and only
> used during early setup from within the gt code. As such, it makes a
> good candidate for placing within gt/, even if it is not yet entirely
> clean of our GEM heritage.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/Makefile | 15 -
>  .../gen6_renderstate.c}   |  0
>  .../gen7_renderstate.c}   |  0

Mistakes were made in past. Painful reminder.


>  .../gen8_renderstate.c}   |  0
>  .../gen9_renderstate.c}   |  0

I seek atonement on playing my part that gen10
did not materialize.

Patch is,
Reviewed-by: Mika Kuoppala 

>  drivers/gpu/drm/i915/gt/intel_lrc.c   |  6 ++--
>  .../intel_renderstate.c}  |  9 +++---
>  .../gpu/drm/i915/{ => gt}/intel_renderstate.h | 10 --
>  drivers/gpu/drm/i915/gt/intel_ringbuffer.c|  7 ++---
>  drivers/gpu/drm/i915/i915_gem_render_state.h  | 31 ---
>  10 files changed, 25 insertions(+), 53 deletions(-)
>  rename drivers/gpu/drm/i915/{intel_renderstate_gen6.c => 
> gt/gen6_renderstate.c} (100%)
>  rename drivers/gpu/drm/i915/{intel_renderstate_gen7.c => 
> gt/gen7_renderstate.c} (100%)
>  rename drivers/gpu/drm/i915/{intel_renderstate_gen8.c => 
> gt/gen8_renderstate.c} (100%)
>  rename drivers/gpu/drm/i915/{intel_renderstate_gen9.c => 
> gt/gen9_renderstate.c} (100%)
>  rename drivers/gpu/drm/i915/{i915_gem_render_state.c => 
> gt/intel_renderstate.c} (96%)
>  rename drivers/gpu/drm/i915/{ => gt}/intel_renderstate.h (91%)
>  delete mode 100644 drivers/gpu/drm/i915/i915_gem_render_state.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 82c49ad16361..d3ada3134328 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -78,14 +78,22 @@ gt-y += \
>   gt/intel_gt_pm.o \
>   gt/intel_hangcheck.o \
>   gt/intel_lrc.o \
> + gt/intel_renderstate.o \
>   gt/intel_reset.o \
>   gt/intel_ringbuffer.o \
>   gt/intel_mocs.o \
>   gt/intel_sseu.o \
>   gt/intel_timeline.o \
>   gt/intel_workarounds.o
> +# autogenerated null render state
> +gt-y += \
> + gt/gen6_renderstate.o \
> + gt/gen7_renderstate.o \
> + gt/gen8_renderstate.o \
> + gt/gen9_renderstate.o
>  gt-$(CONFIG_DRM_I915_SELFTEST) += \
>   gt/mock_engine.o
> +
>  i915-y += $(gt-y)
>  
>  # GEM (Graphics Execution Management) code
> @@ -123,7 +131,6 @@ i915-y += \
> i915_gem_fence_reg.o \
> i915_gem_gtt.o \
> i915_gem.o \
> -   i915_gem_render_state.o \
> i915_globals.o \
> i915_query.o \
> i915_request.o \
> @@ -144,12 +151,6 @@ i915-y += intel_uc.o \
> intel_huc.o \
> intel_huc_fw.o
>  
> -# autogenerated null render state
> -i915-y += intel_renderstate_gen6.o \
> -   intel_renderstate_gen7.o \
> -   intel_renderstate_gen8.o \
> -   intel_renderstate_gen9.o
> -
>  # modesetting core code
>  obj-y += display/
>  i915-y += \
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen6.c 
> b/drivers/gpu/drm/i915/gt/gen6_renderstate.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_renderstate_gen6.c
> rename to drivers/gpu/drm/i915/gt/gen6_renderstate.c
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen7.c 
> b/drivers/gpu/drm/i915/gt/gen7_renderstate.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_renderstate_gen7.c
> rename to drivers/gpu/drm/i915/gt/gen7_renderstate.c
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen8.c 
> b/drivers/gpu/drm/i915/gt/gen8_renderstate.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_renderstate_gen8.c
> rename to drivers/gpu/drm/i915/gt/gen8_renderstate.c
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen9.c 
> b/drivers/gpu/drm/i915/gt/gen9_renderstate.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_renderstate_gen9.c
> rename to drivers/gpu/drm/i915/gt/gen9_renderstate.c
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 1e85e04c58c4..f5b09b29f50e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -135,13 +135,13 @@
>  
>  #include "gem/i915_gem_context.h"
>  
> -#include "gt/intel_gt.h"
>  #include "i915_drv.h"
> -#include "i915_gem_render_state.h"
>  #include "i915_vgpu.h"
>  #include "intel_engine_pm.h"
> +#include "intel_gt.h"
>  #include "intel_lrc_reg.h"
>  #include "intel_mocs.h"
> +#include "intel_renderstate.h"
>  #include "intel_reset.h"
>  #include "intel_workarounds.h"
>  
> @@ -2677,7 +2677,7 @@ static int gen8_init_rcs_context(struct i915_request 
> *rq)
>   if (ret)
>   DRM_ERROR("MOCS failed to program: expect performance 
> issues.\n");
>  
> - return 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gtt: Defer the free for alloc error paths

2019-07-04 Thread Matthew Auld

On 03/07/2019 18:19, Chris Wilson wrote:

If we hit an error while allocating the page tables, we have to unwind
the incomplete updates, and wish to free the unused pd. However, we are
not allowed to be hoding the spinlock at that point, and so must use the


holding


later free to defer it until after we drop the lock.

<3> [414.363795] BUG: sleeping function called from invalid context at 
drivers/gpu/drm/i915/i915_gem_gtt.c:472
<3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: 
i915_selftest
<4> [414.364406] 3 locks held by i915_selftest/3905:
<4> [414.364408]  #0: 34fe8aa8 (>mutex){}, at: 
device_driver_attach+0x18/0x50
<4> [414.364415]  #1: 6bd8a560 (>struct_mutex){+.+.}, at: 
igt_ctx_exec+0xb7/0x410 [i915]
<4> [414.364476]  #2: 3dfdc766 (&(>lock)->rlock){+.+.}, at: 
gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
<3> [414.364529] Preemption disabled at:
<4> [414.364530] [<>] 0x0
<4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U  
  5.2.0-rc7-CI-CI_DRM_6403+ #1
<4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
<4> [414.364699] Call Trace:
<4> [414.364704]  dump_stack+0x67/0x9b
<4> [414.364708]  ___might_sleep+0x167/0x250
<4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
<4> [414.364852]  free_pd+0xf/0x20 [i915]
<4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
<4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
<4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
<4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
<4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]

Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
allocation")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9e76347e039e..1065753e86fb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1489,7 +1489,8 @@ static int gen8_ppgtt_alloc_pdp(struct i915_address_space 
*vm,
gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
GEM_BUG_ON(!atomic_read(>used));
atomic_dec(>used);
-   free_pd(vm, pd);
+   GEM_BUG_ON(alloc);


Pretty sure it's possible for alloc != NULL at this point...two threads, 
one is late to the party, we are unlucky and hit the unwind_pd path. No?



+   alloc = pd; /* defer the free to after the lock */
}
spin_unlock(>lock);
  unwind:
@@ -1558,7 +1559,8 @@ static int gen8_ppgtt_alloc_4lvl(struct 
i915_address_space *vm,
spin_lock(>lock);
if (atomic_dec_and_test(>used)) {
gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
-   free_pd(vm, pdp);
+   GEM_BUG_ON(alloc);
+   alloc = pdp; /* defer the free until after the lock */
}
spin_unlock(>lock);
  unwind:


___
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: Flush the workqueue before draining

2019-07-04 Thread Chris Wilson
Quoting Mika Kuoppala (2019-07-04 11:22:17)
> Chris Wilson  writes:
> 
> > Trying to drain a workqueue while we may still be adding to it from
> > background tasks is, according to kernel/workqueue.c, verboten. So, add
> > a flush_workqueue() at the start of our cleanup procedure.
> 
> I don't get it. drain_workqueue does it's own flushing.

Ordering is important here. The problem with drain_workqueue() is that
is forbids us from adding more tasks into the workqueue as it drains, so
before we drain we must plug.

It's just adding more hammers. Eventually it'll break.
-Chris
___
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: Flush the workqueue before draining

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> Trying to drain a workqueue while we may still be adding to it from
> background tasks is, according to kernel/workqueue.c, verboten. So, add
> a flush_workqueue() at the start of our cleanup procedure.

I don't get it. drain_workqueue does it's own flushing.
-Mika

>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9d132c9d17b0..d2f9af3a16dc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2472,6 +2472,7 @@ static inline void i915_gem_drain_workqueue(struct 
> drm_i915_private *i915)
>*/
>   int pass = 3;
>   do {
> + flush_workqueue(i915->wq);
>   rcu_barrier();
>   i915_gem_drain_freed_objects(i915);
>   } while (--pass);
> -- 
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915: Check caller held wakerefs in assert_forcewakes_active

2019-07-04 Thread Chris Wilson
The intent of the assert is to document that the caller took the
appropriate wakerefs for the function. However, as Tvrtko pointed out,
we simply check whether the fw_domains are active and may be confused by
the auto wakeref which may be dropped between the check and use. Let's
be more careful in the assert and check that each fw_domain has an
explicit caller wakeref above and beyond the automatic wakeref.

v2: Fix spelling for config DRM_I915_DEBUG_RUNTIME_PM
v3: Timer may still be active after we drop the autowakeref, we need to
check domain->active instead.
v4: The timer checks domain->active, but we still need to check the
timer. (This is starting to look weird...)

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

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 68d54e126d79..2042c94c9cc9 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -738,6 +738,12 @@ void assert_forcewakes_inactive(struct intel_uncore 
*uncore)
 void assert_forcewakes_active(struct intel_uncore *uncore,
  enum forcewake_domains fw_domains)
 {
+   struct intel_uncore_forcewake_domain *domain;
+   unsigned int tmp;
+
+   if (!IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM))
+   return;
+
if (!uncore->funcs.force_wake_get)
return;
 
@@ -747,6 +753,24 @@ void assert_forcewakes_active(struct intel_uncore *uncore,
WARN(fw_domains & ~uncore->fw_domains_active,
 "Expected %08x fw_domains to be active, but %08x are off\n",
 fw_domains, fw_domains & ~uncore->fw_domains_active);
+
+   /*
+* Check that the caller has an explicit wakeref and we don't mistake
+* it for the auto wakeref.
+*/
+   local_irq_disable();
+   for_each_fw_domain_masked(domain, fw_domains, uncore, tmp) {
+   unsigned int expect = 1;
+
+   if (hrtimer_active(>timer) && READ_ONCE(domain->active))
+   expect++; /* pending automatic release */
+
+   if (WARN(domain->wake_count < expect,
+"Expected domain %d to be held awake by caller, 
count=%d\n",
+domain->id, domain->wake_count))
+   break;
+   }
+   local_irq_enable();
 }
 
 /* We give fast paths for the really cool registers */
-- 
2.20.1

___
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/gtt: Defer the free for alloc error paths

2019-07-04 Thread Mika Kuoppala
Chris Wilson  writes:

> If we hit an error while allocating the page tables, we have to unwind
> the incomplete updates, and wish to free the unused pd. However, we are
> not allowed to be hoding the spinlock at that point, and so must use the
> later free to defer it until after we drop the lock.
>
> <3> [414.363795] BUG: sleeping function called from invalid context at 
> drivers/gpu/drm/i915/i915_gem_gtt.c:472
> <3> [414.364167] in_atomic(): 1, irqs_disabled(): 0, pid: 3905, name: 
> i915_selftest
> <4> [414.364406] 3 locks held by i915_selftest/3905:
> <4> [414.364408]  #0: 34fe8aa8 (>mutex){}, at: 
> device_driver_attach+0x18/0x50
> <4> [414.364415]  #1: 6bd8a560 (>struct_mutex){+.+.}, at: 
> igt_ctx_exec+0xb7/0x410 [i915]
> <4> [414.364476]  #2: 3dfdc766 (&(>lock)->rlock){+.+.}, at: 
> gen8_ppgtt_alloc_pdp+0x448/0x540 [i915]
> <3> [414.364529] Preemption disabled at:
> <4> [414.364530] [<>] 0x0
> <4> [414.364696] CPU: 0 PID: 3905 Comm: i915_selftest Tainted: G U
> 5.2.0-rc7-CI-CI_DRM_6403+ #1
> <4> [414.364698] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> <4> [414.364699] Call Trace:
> <4> [414.364704]  dump_stack+0x67/0x9b
> <4> [414.364708]  ___might_sleep+0x167/0x250
> <4> [414.364777]  vm_free_page+0x24/0xc0 [i915]
> <4> [414.364852]  free_pd+0xf/0x20 [i915]
> <4> [414.364897]  gen8_ppgtt_alloc_pdp+0x489/0x540 [i915]
> <4> [414.364946]  gen8_ppgtt_alloc_4lvl+0x8e/0x2e0 [i915]
> <4> [414.364992]  ppgtt_bind_vma+0x2e/0x60 [i915]
> <4> [414.365039]  i915_vma_bind+0xe8/0x2c0 [i915]
> <4> [414.365088]  __i915_vma_do_pin+0xa1/0xd20 [i915]
>
> Fixes: 1d1b5490b91c ("drm/i915/gtt: Replace struct_mutex serialisation for 
> allocation")
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
> Cc: Mika Kuoppala 

From another thread,

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 9e76347e039e..1065753e86fb 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1489,7 +1489,8 @@ static int gen8_ppgtt_alloc_pdp(struct 
> i915_address_space *vm,
>   gen8_ppgtt_set_pdpe(pdp, vm->scratch_pd, pdpe);
>   GEM_BUG_ON(!atomic_read(>used));
>   atomic_dec(>used);
> - free_pd(vm, pd);
> + GEM_BUG_ON(alloc);
> + alloc = pd; /* defer the free to after the lock */
>   }
>   spin_unlock(>lock);
>  unwind:
> @@ -1558,7 +1559,8 @@ static int gen8_ppgtt_alloc_4lvl(struct 
> i915_address_space *vm,
>   spin_lock(>lock);
>   if (atomic_dec_and_test(>used)) {
>   gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
> - free_pd(vm, pdp);
> + GEM_BUG_ON(alloc);
> + alloc = pdp; /* defer the free until after the lock */
>   }
>   spin_unlock(>lock);
>  unwind:
> -- 
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3] drm/i915: Check caller held wakerefs in assert_forcewakes_active (rev3)

2019-07-04 Thread Patchwork
== Series Details ==

Series: series starting with [v3] drm/i915: Check caller held wakerefs in 
assert_forcewakes_active (rev3)
URL   : https://patchwork.freedesktop.org/series/63151/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_6408 -> Patchwork_13526


Summary
---

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@runner@aborted:
- fi-bdw-gvtdvm:  NOTRUN -> [FAIL][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-bdw-gvtdvm/igt@run...@aborted.html
- fi-bxt-j4205:   NOTRUN -> [FAIL][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-bxt-j4205/igt@run...@aborted.html
- fi-whl-u:   NOTRUN -> [FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-whl-u/igt@run...@aborted.html
- fi-cml-u2:  NOTRUN -> [FAIL][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-cml-u2/igt@run...@aborted.html
- fi-cml-u:   NOTRUN -> [FAIL][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-cml-u/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][6]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-bxt-dsi/igt@run...@aborted.html
- fi-bsw-n3050:   NOTRUN -> [FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-bsw-n3050/igt@run...@aborted.html
- fi-bsw-kefka:   NOTRUN -> [FAIL][8]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-bsw-kefka/igt@run...@aborted.html
- fi-apl-guc: NOTRUN -> [FAIL][9]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-apl-guc/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][10]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-bdw-5557u/igt@run...@aborted.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850:   [PASS][11] -> [INCOMPLETE][12] ([fdo#107718])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6408/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html

  
 Warnings 

  * igt@runner@aborted:
- fi-icl-dsi: [FAIL][13] ([fdo#110586] / [k.org#203557]) -> 
[FAIL][14] ([fdo#109593] / [fdo#110676])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6408/fi-icl-dsi/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/fi-icl-dsi/igt@run...@aborted.html

  
  [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
  [fdo#109593]: https://bugs.freedesktop.org/show_bug.cgi?id=109593
  [fdo#110586]: https://bugs.freedesktop.org/show_bug.cgi?id=110586
  [fdo#110676]: https://bugs.freedesktop.org/show_bug.cgi?id=110676
  [k.org#203557]: https://bugzilla.kernel.org/show_bug.cgi?id=203557


Participating hosts (53 -> 45)
--

  Additional (2): fi-kbl-r fi-cml-u 
  Missing(10): fi-kbl-soraka fi-icl-u4 fi-ilk-m540 fi-hsw-4200u 
fi-byt-squawks fi-bsw-cyan fi-icl-u3 fi-icl-y fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_6408 -> Patchwork_13526

  CI_DRM_6408: ee60427a5d560ee44370d88f70db1497df9df979 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5082: f7c51e6fbf8da0784b64a1edaee5266aa9b9f829 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_13526: 97bc735ef3f8882aa40bd093a14616a26beccbd3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Kernel 32bit build ==

Warning: Kernel 32bit buildtest failed:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13526/build_32bit.log

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)
  Building modules, stage 2.
  MODPOST 112 modules
ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1287: recipe for target 'modules' failed
make: *** [modules] Error 2


== Linux 

  1   2   >