[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve execute_cb struct packing (rev2)

2020-05-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Improve execute_cb struct packing (rev2)
URL   : https://patchwork.freedesktop.org/series/77281/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8537 -> Patchwork_1


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (50 -> 45)
--

  Additional (1): fi-kbl-7560u 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8537 -> Patchwork_1

  CI-20190529: 20190529
  CI_DRM_8537: 05a47cd761c49c3fa87648c30df0fd4d64b0b8c5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_1: c668d9c787ca7c6450cd4c7bb82a68f4c31ac439 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c668d9c787ca drm/i915: Improve execute_cb struct packing

== Logs ==

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


[Intel-gfx] [PATCH i-g-t] lib: Randomise spinner location to reduce relocation risk

2020-05-26 Thread Chris Wilson
Randomise the position of the spinner to reduce the number of
relocations we might require.

Signed-off-by: Chris Wilson 
---
 lib/igt_dummyload.c | 33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index a733bd674..776e97baa 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -82,8 +82,21 @@ emit_recursive_batch(igt_spin_t *spin,
unsigned int nengine;
int fence_fd = -1;
uint32_t *cs, *batch;
+   uint32_t addr;
int i;
 
+   /*
+* Pick a random location for our spinner et al.
+*
+* If available, the kernel will place our objects in our hinted
+* locations and we will avoid having to perform any relocations.
+*
+* It must be a valid location (or else the kernel will be forced
+* to select one for us) and so must be within the GTT and suitably
+* aligned. For simplicity, stick to the low 32bit addresses.
+*/
+   addr = (random() % 1024 + 1024) << 12;
+
nengine = 0;
if (opts->engine == ALL_ENGINES) {
struct intel_execution_engine2 *engine;
@@ -114,6 +127,9 @@ emit_recursive_batch(igt_spin_t *spin,
execbuf->buffer_count++;
cs = batch;
 
+   obj[BATCH].offset = addr;
+   addr += BATCH_SIZE;
+
if (opts->dependency) {
igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN));
 
@@ -152,11 +168,13 @@ emit_recursive_batch(igt_spin_t *spin,
   
spin->poll_handle,
   0, 4096,
   PROT_READ | 
PROT_WRITE);
+   addr += 4096; /* guard page */
+   obj[SCRATCH].offset = addr;
+   addr += 4096;
 
igt_assert_eq(spin->poll[SPIN_POLL_START_IDX], 0);
 
-   /* batch is first */
-   r->presumed_offset = 4096;
+   r->presumed_offset = obj[SCRATCH].offset;
r->target_handle = obj[SCRATCH].handle;
r->offset = sizeof(uint32_t) * 1;
r->delta = sizeof(uint32_t) * SPIN_POLL_START_IDX;
@@ -231,7 +249,7 @@ emit_recursive_batch(igt_spin_t *spin,
spin->condition[0] = 0x;
spin->condition[1] = 0x;
 
-   r->presumed_offset = 0;
+   r->presumed_offset = obj[BATCH].offset;
r->target_handle = obj[BATCH].handle;
r->offset = (cs + 2 - batch) * sizeof(*cs);
r->read_domains = I915_GEM_DOMAIN_COMMAND;
@@ -239,28 +257,29 @@ emit_recursive_batch(igt_spin_t *spin,
 
*cs++ = MI_COND_BATCH_BUFFER_END | MI_DO_COMPARE | 2;
*cs++ = MI_BATCH_BUFFER_END;
-   *cs++ = r->delta;
+   *cs++ = r->presumed_offset + r->delta;
*cs++ = 0;
}
 
/* recurse */
r = [obj[BATCH].relocation_count++];
r->target_handle = obj[BATCH].handle;
+   r->presumed_offset = obj[BATCH].offset;
r->offset = (cs + 1 - batch) * sizeof(*cs);
r->read_domains = I915_GEM_DOMAIN_COMMAND;
r->delta = LOOP_START_OFFSET;
if (gen >= 8) {
*cs++ = MI_BATCH_BUFFER_START | 1 << 8 | 1;
-   *cs++ = r->delta;
+   *cs++ = r->presumed_offset + r->delta;
*cs++ = 0;
} else if (gen >= 6) {
*cs++ = MI_BATCH_BUFFER_START | 1 << 8;
-   *cs++ = r->delta;
+   *cs++ = r->presumed_offset + r->delta;
} else {
*cs++ = MI_BATCH_BUFFER_START | 2 << 6;
if (gen < 4)
r->delta |= 1;
-   *cs = r->delta;
+   *cs = r->presumed_offset + r->delta;
cs++;
}
obj[BATCH].relocs_ptr = to_user_pointer(relocs);
-- 
2.27.0.rc0

___
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: Fix wrong CDCLK adjustment changes

2020-05-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix wrong CDCLK adjustment changes
URL   : https://patchwork.freedesktop.org/series/77654/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8537_full -> Patchwork_17776_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Possible new issues
---

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

### Piglit changes ###

 Possible regressions 

  * spec@glsl-4.30@execution@built-in-functions@cs-op-bitand-not-uvec4-uint 
(NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][1] +7 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/pig-icl-1065g7/spec@glsl-4.30@execution@built-in-functi...@cs-op-bitand-not-uvec4-uint.html

  * spec@glsl-4.30@execution@built-in-functions@cs-op-ne-ivec2-ivec2-using-if 
(NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][2]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/pig-icl-1065g7/spec@glsl-4.30@execution@built-in-functi...@cs-op-ne-ivec2-ivec2-using-if.html

  
New tests
-

  New tests have been introduced between CI_DRM_8537_full and 
Patchwork_17776_full:

### New Piglit tests (9) ###

  * spec@glsl-4.30@execution@built-in-functions@cs-greaterthanequal-uvec3-uvec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-add-mat2x4-mat2x4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-bitand-not-uvec4-uint:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-mult-int-ivec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-ne-ivec2-ivec2-using-if:
- Statuses : 1 crash(s)
- Exec time: [0.39] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-ne-vec3-vec3-using-if:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-rshift-ivec2-uvec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-4.30@execution@built-in-functions@cs-op-selection-bool-uvec2-uvec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-4.30@execution@built-in-functions@cs-op-sub-float-mat2x4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_softpin@noreloc-s3:
- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +1 similar 
issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-kbl6/igt@gem_soft...@noreloc-s3.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-kbl3/igt@gem_soft...@noreloc-s3.html

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / 
[i915#716])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-glk4/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk:  [PASS][7] -> [FAIL][8] ([i915#1119] / [i915#118] / 
[i915#95]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk4/igt@kms_big...@y-tiled-64bpp-rotate-180.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-apl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar 
issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-apl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][11] -> [FAIL][12] ([i915#54]) +2 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][13] -> [FAIL][14] ([i915#1188])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl8/igt@kms_...@bpc-switch-suspend.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/shard-skl4/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes:
- shard-skl:  [PASS][15] -> [INCOMPLETE][16] ([i915#69])
   [15]: 

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77661/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8685c3c6d218 drm/i915/params: don't expose inject_probe_failure in debugfs
4d8a197e487c drm/i915/params: fix i915.fake_lmem_start module param sysfs 
permissions
-:27: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#27: FILE: drivers/gpu/drm/i915/i915_params.c:177:
+i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
"Fake LMEM start offset (default: 0)");

total: 0 errors, 0 warnings, 1 checks, 8 lines checked
af9a802b3b26 drm/i915/params: prevent changing module params runtime
-:48: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#48: FILE: drivers/gpu/drm/i915/i915_params.c:62:
+i915_param_named_unsafe(enable_fbc, int, 0400,
"Enable frame buffer compression for power savings "

-:57: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#57: FILE: drivers/gpu/drm/i915/i915_params.c:70:
+i915_param_named_unsafe(panel_use_ssc, int, 0400,
"Use Spread Spectrum Clock with panels [LVDS/eDP] "

-:66: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#66: FILE: drivers/gpu/drm/i915/i915_params.c:78:
+i915_param_named_unsafe(reset, int, 0400,
"Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset 
[default])");

-:74: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#74: FILE: drivers/gpu/drm/i915/i915_params.c:85:
+i915_param_named(error_capture, bool, 0400,
"Record the GPU state following a hang. "

-:81: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#81: FILE: drivers/gpu/drm/i915/i915_params.c:91:
+i915_param_named_unsafe(enable_hangcheck, bool, 0400,
"Periodically check GPU activity for detecting hangs. "

-:87: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#87: FILE: drivers/gpu/drm/i915/i915_params.c:96:
+i915_param_named_unsafe(enable_psr, int, 0400,
"Enable PSR "

-:99: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#99: FILE: drivers/gpu/drm/i915/i915_params.c:111:
+i915_param_named(fastboot, int, 0400,
"Try to skip unnecessary mode sets at boot time "

-:105: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#105: FILE: drivers/gpu/drm/i915/i915_params.c:116:
+i915_param_named_unsafe(load_detect_test, bool, 0400,
"Force-enable the VGA load detect code for testing (default:false). "

-:110: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#110: FILE: drivers/gpu/drm/i915/i915_params.c:120:
+i915_param_named_unsafe(force_reset_modeset_test, bool, 0400,
"Force a modeset during gpu reset for testing (default:false). "

-:115: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#115: FILE: drivers/gpu/drm/i915/i915_params.c:124:
+i915_param_named_unsafe(invert_brightness, int, 0400,
"Invert backlight brightness "

-:124: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#124: FILE: drivers/gpu/drm/i915/i915_params.c:134:
+i915_param_named(mmio_debug, int, 0400,
"Enable the MMIO debug code for the first N failures (default: off). "

-:137: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#137: FILE: drivers/gpu/drm/i915/i915_params.c:169:
+i915_param_named_unsafe(enable_dp_mst, bool, 0400,
"Enable multi-stream transport (MST) for new DisplayPort sinks. 
(default: true)");

-:146: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#146: FILE: drivers/gpu/drm/i915/i915_params.c:177:
+i915_param_named(enable_dpcd_backlight, int, 0400,
"Enable support for DPCD backlight control"

total: 0 errors, 0 warnings, 13 checks, 115 lines checked
92adebe0d92e drm/i915/params: switch to device specific parameters

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


[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Update inter-engine semaphore detection

2020-05-26 Thread Chris Wilson
The kernel no longer uses semaphores between engines, unless it can do
so by preempting them with timeslices. Update the semaphore-busy to only
run when we expect semaphore usage, i.e. not on bdw/bsw.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1939
Signed-off-by: Chris Wilson 
---
 tests/perf_pmu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index e54a0d47e..e80f730cf 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -822,6 +822,7 @@ sema_busy(int gem_fd,
int fd;
 
igt_require(gem_scheduler_has_semaphores(gem_fd));
+   igt_require(gem_scheduler_has_preemption(gem_fd));
 
fd = open_group(gem_fd,
I915_PMU_ENGINE_SEMA(e->class, e->instance), -1);
-- 
2.27.0.rc0

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


[Intel-gfx] [PATCH i-g-t] lib/i915: Restore hangcheck modparams between tests

2020-05-26 Thread Chris Wilson
The hangcheck/reset modparam has far reaching effects and disables
functionality if switch off. This can surprise a few tests causing them
to skip.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/1929
Signed-off-by: Chris Wilson 
---
 lib/i915/gem.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/i915/gem.c b/lib/i915/gem.c
index 3ef31ed33..45db8a0fd 100644
--- a/lib/i915/gem.c
+++ b/lib/i915/gem.c
@@ -130,6 +130,13 @@ static void reset_device(int i915)
close(dir);
 }
 
+static void restore_params(int i915)
+{
+   /* Re-enable modparams if left clobbered */
+   igt_params_set(i915, "reset", "%u", -1);
+   igt_params_set(i915, "enable_hangcheck", "%u", 1);
+}
+
 void igt_require_gem(int i915)
 {
int err;
@@ -150,6 +157,7 @@ void igt_require_gem(int i915)
 * sequences of batches.
 */
reset_device(i915);
+   restore_params(i915);
restore_defaults(i915);
 
err = 0;
-- 
2.27.0.rc0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume

2020-05-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume
URL   : https://patchwork.freedesktop.org/series/77666/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8539 -> Patchwork_17779


Summary
---

  **SUCCESS**

  No regressions found.

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


Changes
---

  No changes found


Participating hosts (50 -> 44)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8539 -> Patchwork_17779

  CI-20190529: 20190529
  CI_DRM_8539: 6590da76d8c6a2952b3cde70859bad41c59ed444 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17779: f2bb7a370b1aa4fee6d41385fab9a42099942db3 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

f2bb7a370b1a drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume

== Logs ==

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


[Intel-gfx] [CI 4/4] drm/i915/params: switch to device specific parameters

2020-05-26 Thread Jani Nikula
Start using device specific parameters instead of module parameters for
most things. The module parameters become the immutable initial values
for i915 parameters. The device specific parameters in i915->params
start life as a copy of i915_modparams. Any later changes are only
reflected in the debugfs.

The stragglers are:

* i915.force_probe and i915.modeset. Needed before dev_priv is
  available. This is fine because the parameters are read-only and never
  modified.

* i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and
  I915_STATE_WARN_ON would result in massive and ugly churn. This is
  handled by not exposing the parameter via debugfs, and leaving the
  parameter writable in sysfs. This may be fixed up in follow-up work.

* i915.inject_probe_failure. Only makes sense in terms of the module,
  not the device. This is handled by not exposing the parameter via
  debugfs.

Cc: Juha-Pekka Heikkilä 
Cc: Venkata Sandeep Dhanalakota 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_bios.c |  6 ++---
 drivers/gpu/drm/i915/display/intel_crt.c  |  4 ++--
 drivers/gpu/drm/i915/display/intel_csr.c  |  6 ++---
 drivers/gpu/drm/i915/display/intel_display.c  | 12 +-
 .../drm/i915/display/intel_display_debugfs.c  |  2 +-
 .../drm/i915/display/intel_display_power.c| 14 ++--
 drivers/gpu/drm/i915/display/intel_dp.c   |  8 ---
 .../drm/i915/display/intel_dp_aux_backlight.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_fbc.c  | 12 +-
 drivers/gpu/drm/i915/display/intel_lvds.c |  4 ++--
 drivers/gpu/drm/i915/display/intel_opregion.c |  2 +-
 drivers/gpu/drm/i915/display/intel_panel.c|  4 ++--
 drivers/gpu/drm/i915/display/intel_psr.c  |  6 ++---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   |  4 ++--
 .../gpu/drm/i915/gt/intel_engine_heartbeat.c  |  3 ++-
 drivers/gpu/drm/i915/gt/intel_reset.c |  6 ++---
 .../drm/i915/gt/selftest_engine_heartbeat.c   |  6 ++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 15 -
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  4 +++-
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 20 -
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 22 ++-
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_debugfs_params.c|  7 +-
 drivers/gpu/drm/i915/i915_drv.c   |  9 ++--
 drivers/gpu/drm/i915/i915_drv.h   |  5 -
 drivers/gpu/drm/i915/i915_getparam.c  |  2 +-
 drivers/gpu/drm/i915/i915_gpu_error.c |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.c  |  8 +++
 drivers/gpu/drm/i915/intel_region_lmem.c  |  6 ++---
 drivers/gpu/drm/i915/intel_uncore.c   |  8 +++
 30 files changed, 114 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bios.c 
b/drivers/gpu/drm/i915/display/intel_bios.c
index 839124647202..ec8af2b7bf01 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -479,7 +479,7 @@ parse_sdvo_panel_data(struct drm_i915_private *dev_priv,
struct drm_display_mode *panel_fixed_mode;
int index;
 
-   index = i915_modparams.vbt_sdvo_panel_type;
+   index = dev_priv->params.vbt_sdvo_panel_type;
if (index == -2) {
drm_dbg_kms(_priv->drm,
"Ignore SDVO panel mode from BIOS VBT tables.\n");
@@ -829,9 +829,9 @@ parse_edp(struct drm_i915_private *dev_priv, const struct 
bdb_header *bdb)
u8 vswing;
 
/* Don't read from VBT if module parameter has valid value*/
-   if (i915_modparams.edp_vswing) {
+   if (dev_priv->params.edp_vswing) {
dev_priv->vbt.edp.low_vswing =
-   i915_modparams.edp_vswing == 1;
+   dev_priv->params.edp_vswing == 1;
} else {
vswing = (edp->edp_vswing_preemph >> (panel_type * 4)) 
& 0xF;
dev_priv->vbt.edp.low_vswing = vswing == 0;
diff --git a/drivers/gpu/drm/i915/display/intel_crt.c 
b/drivers/gpu/drm/i915/display/intel_crt.c
index 2f5b9a4baafd..5b4510ce5693 100644
--- a/drivers/gpu/drm/i915/display/intel_crt.c
+++ b/drivers/gpu/drm/i915/display/intel_crt.c
@@ -833,7 +833,7 @@ intel_crt_detect(struct drm_connector *connector,
connector->base.id, connector->name,
force);
 
-   if (i915_modparams.load_detect_test) {
+   if (dev_priv->params.load_detect_test) {
wakeref = intel_display_power_get(dev_priv,
  intel_encoder->power_domain);
goto load_detect;
@@ -889,7 +889,7 @@ intel_crt_detect(struct drm_connector *connector,
else if (INTEL_GEN(dev_priv) < 4)
status = 

[Intel-gfx] [CI 3/4] drm/i915/params: prevent changing module params runtime

2020-05-26 Thread Jani Nikula
Only support runtime changes through the debugfs.

i915.verbose_state_checks remains an exception, and is not exposed via
debugfs.

This depends on IGT having been updated to use the debugfs for modifying
the parameters.

Cc: Juha-Pekka Heikkilä 
Cc: Venkata Sandeep Dhanalakota 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.c | 38 +++---
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index a3dde770226d..ace44ad7e6df 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -40,6 +40,15 @@ struct i915_params i915_modparams __read_mostly = {
 #undef MEMBER
 };
 
+/*
+ * Note: As a rule, keep module parameter sysfs permissions read-only
+ * 0400. Runtime changes are only supported through i915 debugfs.
+ *
+ * For any exceptions requiring write access and runtime changes through module
+ * parameter sysfs, prevent debugfs file creation by setting the parameter's
+ * debugfs mode to 0.
+ */
+
 i915_param_named(modeset, int, 0400,
"Use kernel modesetting [KMS] (0=disable, "
"1=on, -1=force vga console preference [default])");
@@ -49,7 +58,7 @@ i915_param_named_unsafe(enable_dc, int, 0400,
"(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
"3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
 
-i915_param_named_unsafe(enable_fbc, int, 0600,
+i915_param_named_unsafe(enable_fbc, int, 0400,
"Enable frame buffer compression for power savings "
"(default: -1 (use per-chip default))");
 
@@ -57,7 +66,7 @@ i915_param_named_unsafe(lvds_channel_mode, int, 0400,
 "Specify LVDS channel mode "
 "(0=probe BIOS [default], 1=single-channel, 2=dual-channel)");
 
-i915_param_named_unsafe(panel_use_ssc, int, 0600,
+i915_param_named_unsafe(panel_use_ssc, int, 0400,
"Use Spread Spectrum Clock with panels [LVDS/eDP] "
"(default: auto from VBT)");
 
@@ -65,25 +74,25 @@ i915_param_named_unsafe(vbt_sdvo_panel_type, int, 0400,
"Override/Ignore selection of SDVO panel mode in the VBT "
"(-2=ignore, -1=auto [default], index in VBT BIOS table)");
 
-i915_param_named_unsafe(reset, int, 0600,
+i915_param_named_unsafe(reset, int, 0400,
"Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset 
[default])");
 
 i915_param_named_unsafe(vbt_firmware, charp, 0400,
"Load VBT from specified file under /lib/firmware");
 
 #if IS_ENABLED(CONFIG_DRM_I915_CAPTURE_ERROR)
-i915_param_named(error_capture, bool, 0600,
+i915_param_named(error_capture, bool, 0400,
"Record the GPU state following a hang. "
"This information in /sys/class/drm/card/error is vital for "
"triaging and debugging hangs.");
 #endif
 
-i915_param_named_unsafe(enable_hangcheck, bool, 0600,
+i915_param_named_unsafe(enable_hangcheck, bool, 0400,
"Periodically check GPU activity for detecting hangs. "
"WARNING: Disabling this can cause system wide hangs. "
"(default: true)");
 
-i915_param_named_unsafe(enable_psr, int, 0600,
+i915_param_named_unsafe(enable_psr, int, 0400,
"Enable PSR "
"(0=disabled, 1=enabled) "
"Default: -1 (use per-chip default)");
@@ -96,22 +105,22 @@ i915_param_named_unsafe(disable_power_well, int, 0400,
"Disable display power wells when possible "
"(-1=auto [default], 0=power wells always on, 1=power wells disabled 
when possible)");
 
-i915_param_named_unsafe(enable_ips, int, 0600, "Enable IPS (default: true)");
+i915_param_named_unsafe(enable_ips, int, 0400, "Enable IPS (default: true)");
 
-i915_param_named(fastboot, int, 0600,
+i915_param_named(fastboot, int, 0400,
"Try to skip unnecessary mode sets at boot time "
"(0=disabled, 1=enabled) "
"Default: -1 (use per-chip default)");
 
-i915_param_named_unsafe(load_detect_test, bool, 0600,
+i915_param_named_unsafe(load_detect_test, bool, 0400,
"Force-enable the VGA load detect code for testing (default:false). "
"For developers only.");
 
-i915_param_named_unsafe(force_reset_modeset_test, bool, 0600,
+i915_param_named_unsafe(force_reset_modeset_test, bool, 0400,
"Force a modeset during gpu reset for testing (default:false). "
"For developers only.");
 
-i915_param_named_unsafe(invert_brightness, int, 0600,
+i915_param_named_unsafe(invert_brightness, int, 0400,
"Invert backlight brightness "
"(-1 force normal, 0 machine defaults, 1 force inversion), please "
"report PCI device ID, subsystem vendor and subsystem device ID "
@@ -121,10 +130,11 @@ i915_param_named_unsafe(invert_brightness, int, 0600,
 i915_param_named(disable_display, bool, 0400,
"Disable display (default: false)");
 
-i915_param_named(mmio_debug, int, 0600,
+i915_param_named(mmio_debug, int, 0400,
"Enable the MMIO debug code for the first N 

[Intel-gfx] [CI 2/4] drm/i915/params: fix i915.fake_lmem_start module param sysfs permissions

2020-05-26 Thread Jani Nikula
fake_lmem_start does not need to be mutable via module param sysfs. It's
only used during driver probe.

Fixes: 1629224324b6 ("drm/i915/lmem: add the fake lmem region")
Cc: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index add00ec1f787..a3dde770226d 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -173,7 +173,7 @@ i915_param_named(enable_gvt, bool, 0400,
 #endif
 
 #if IS_ENABLED(CONFIG_DRM_I915_UNSTABLE_FAKE_LMEM)
-i915_param_named_unsafe(fake_lmem_start, ulong, 0600,
+i915_param_named_unsafe(fake_lmem_start, ulong, 0400,
"Fake LMEM start offset (default: 0)");
 #endif
 
-- 
2.20.1

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


[Intel-gfx] [CI 1/4] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-05-26 Thread Jani Nikula
The parameter only makes sense as a module parameter only.

Fixes: c43c5a8818d4 ("drm/i915/params: add i915 parameters to debugfs")
Cc: Juha-Pekka Heikkilä 
Cc: Venkata Sandeep Dhanalakota 
Reviewed-by: Juha-Pekka Heikkila 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 45323732f099..4f21bfffbf0e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -64,7 +64,7 @@ struct drm_printer;
param(int, mmio_debug, -IS_ENABLED(CONFIG_DRM_I915_DEBUG_MMIO), 0600) \
param(int, edp_vswing, 0, 0400) \
param(unsigned int, reset, 3, 0600) \
-   param(unsigned int, inject_probe_failure, 0, 0600) \
+   param(unsigned int, inject_probe_failure, 0, 0) \
param(int, fastboot, -1, 0600) \
param(int, enable_dpcd_backlight, -1, 0600) \
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
-- 
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 series starting with [1/2] drm/i915: Reorder await_execution before await_request

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Reorder await_execution before 
await_request
URL   : https://patchwork.freedesktop.org/series/77653/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8537_full -> Patchwork_17775_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gen9_exec_parse@allowed-all:
- shard-glk:  [PASS][1] -> [DMESG-WARN][2] ([i915#1436] / 
[i915#716])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-glk6/igt@gen9_exec_pa...@allowed-all.html

  * igt@kms_big_fb@linear-64bpp-rotate-0:
- shard-glk:  [PASS][3] -> [FAIL][4] ([i915#1119] / [i915#118] / 
[i915#95])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk9/igt@kms_big...@linear-64bpp-rotate-0.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-glk8/igt@kms_big...@linear-64bpp-rotate-0.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x42-offscreen:
- shard-skl:  [PASS][5] -> [FAIL][6] ([i915#54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html

  * igt@kms_hdr@bpc-switch-suspend:
- shard-skl:  [PASS][7] -> [FAIL][8] ([i915#1188])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl8/igt@kms_...@bpc-switch-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl8/igt@kms_...@bpc-switch-suspend.html

  * igt@kms_psr@psr2_suspend:
- shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109441]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-iclb2/igt@kms_psr@psr2_suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-iclb4/igt@kms_psr@psr2_suspend.html

  * igt@kms_psr@suspend:
- shard-skl:  [PASS][11] -> [INCOMPLETE][12] ([i915#198])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl7/igt@kms_...@suspend.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl3/igt@kms_...@suspend.html

  * igt@kms_setmode@basic:
- shard-apl:  [PASS][13] -> [FAIL][14] ([i915#31])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-apl3/igt@kms_setm...@basic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-apl6/igt@kms_setm...@basic.html

  
 Possible fixes 

  * igt@i915_suspend@forcewake:
- shard-apl:  [DMESG-WARN][15] ([i915#180]) -> [PASS][16] +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-apl6/igt@i915_susp...@forcewake.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-apl1/igt@i915_susp...@forcewake.html

  * igt@kms_big_fb@y-tiled-64bpp-rotate-0:
- shard-glk:  [FAIL][17] ([i915#1119] / [i915#118] / [i915#95]) -> 
[PASS][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html

  * {igt@kms_flip@flip-vs-suspend@c-dp1}:
- shard-kbl:  [DMESG-WARN][19] ([i915#180]) -> [PASS][20] +4 
similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-kbl1/igt@kms_flip@flip-vs-susp...@c-dp1.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-kbl6/igt@kms_flip@flip-vs-susp...@c-dp1.html

  * {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-dp1}:
- shard-kbl:  [FAIL][21] ([i915#1928]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-dp1.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-kbl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-dp1.html

  * {igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1}:
- shard-skl:  [FAIL][23] ([i915#1928]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/shard-skl2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@c-edp1.html

  * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl:  [FAIL][25] ([fdo#108145] / [i915#265]) -> [PASS][26]
   [25]: 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915/params: don't expose inject_probe_failure in debugfs

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [CI,1/4] drm/i915/params: don't expose 
inject_probe_failure in debugfs
URL   : https://patchwork.freedesktop.org/series/77661/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8539 -> Patchwork_17778


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17778 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17778, 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_17778/index.html

Possible new issues
---

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

### CI changes ###

 Possible regressions 

  * boot:
- fi-kbl-8809g:   [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-kbl-8809g/boot.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-kbl-8809g/boot.html
- fi-icl-y:   [PASS][3] -> [FAIL][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-y/boot.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-y/boot.html
- fi-icl-u2:  [PASS][5] -> [FAIL][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-u2/boot.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-u2/boot.html
- fi-cfl-8109u:   [PASS][7] -> [FAIL][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cfl-8109u/boot.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cfl-8109u/boot.html
- fi-skl-6600u:   [PASS][9] -> [FAIL][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-skl-6600u/boot.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-skl-6600u/boot.html
- fi-cfl-8700k:   [PASS][11] -> [FAIL][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cfl-8700k/boot.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cfl-8700k/boot.html
- fi-icl-dsi: [PASS][13] -> [FAIL][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-dsi/boot.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-dsi/boot.html
- fi-whl-u:   [PASS][15] -> [FAIL][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-whl-u/boot.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-whl-u/boot.html
- fi-cml-u2:  [PASS][17] -> [FAIL][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cml-u2/boot.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cml-u2/boot.html
- fi-skl-6700k2:  [PASS][19] -> [FAIL][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-skl-6700k2/boot.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-skl-6700k2/boot.html
- fi-cfl-guc: [PASS][21] -> [FAIL][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cfl-guc/boot.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cfl-guc/boot.html
- fi-kbl-soraka:  [PASS][23] -> [FAIL][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-kbl-soraka/boot.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-kbl-soraka/boot.html
- fi-icl-guc: [PASS][25] -> [FAIL][26]
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-icl-guc/boot.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-icl-guc/boot.html
- fi-cml-s:   [PASS][27] -> [FAIL][28]
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-cml-s/boot.html
   [28]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-cml-s/boot.html
- fi-skl-lmem:[PASS][29] -> [FAIL][30]
   [29]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-skl-lmem/boot.html
   [30]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-skl-lmem/boot.html
- fi-glk-dsi: [PASS][31] -> [FAIL][32]
   [31]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-glk-dsi/boot.html
   [32]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-glk-dsi/boot.html
- fi-tgl-y:   [PASS][33] -> [FAIL][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-tgl-y/boot.html
   [34]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-tgl-y/boot.html
- fi-kbl-guc: [PASS][35] -> [FAIL][36]
   [35]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/fi-kbl-guc/boot.html
   [36]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17778/fi-kbl-guc/boot.html
- fi-kbl-x1275:   [PASS][37] -> 

[Intel-gfx] [PATCH] drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume

2020-05-26 Thread Chris Wilson
We only restore GLOBAL binds upon resume as we expect these to be pinned
for use by HW, whereas the LOCAL binds can be recreated on demand once
userspace is resumed. For the LOCAL bind to be recreated in the global
GTT, we need to clear its presence flag on deciding not to restore the
mapping upon resume.

Fixes: bf0840cdb304 ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with 
PIN_USER with no-ppgtt")
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 8c275f8588c3..317172ad5ef3 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1161,6 +1161,11 @@ void i915_ggtt_disable_guc(struct i915_ggtt *ggtt)
ggtt->invalidate(ggtt);
 }
 
+static unsigned int clear_bind(struct i915_vma *vma)
+{
+   return atomic_fetch_and(~I915_VMA_BIND_MASK, >flags);
+}
+
 void i915_ggtt_resume(struct i915_ggtt *ggtt)
 {
struct i915_vma *vma;
@@ -1179,10 +1184,9 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
list_for_each_entry(vma, >vm.bound_list, vm_link) {
struct drm_i915_gem_object *obj = vma->obj;
 
-   if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND))
+   if (!(clear_bind(vma) & I915_VMA_GLOBAL_BIND))
continue;
 
-   clear_bit(I915_VMA_GLOBAL_BIND_BIT, __i915_vma_flags(vma));
WARN_ON(i915_vma_bind(vma,
  obj ? obj->cache_level : 0,
  PIN_GLOBAL, NULL));
-- 
2.20.1

___
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/gt: Do not schedule normal requests immediately along virtual

2020-05-26 Thread Tvrtko Ursulin



On 25/05/2020 21:28, Chris Wilson wrote:

When we push a virtual request onto the HW, we update the rq->engine to
point to the physical engine. A request that is then submitted by the
user that waits upon the virtual engine, but along the physical engine
in use, will then see that it is due to be submitted to the same engine
and take a shortcut (and be queued without waiting for the completion
fence). However, the virtual request may be preempted (either by higher
priority users, or by timeslicing) and removed from the physical engine
to be migrated over to one of its siblings. The dependent normal request
however is oblivious to the removal of the virtual request and remains
queued to execute on HW, believing that once it reaches the head of its
queue all of its predecessors will have completed executing!

Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Testcase: igt/gem_exec_balancer/sliced
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc:  # v5.3+
---
  drivers/gpu/drm/i915/i915_request.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c282719ad3ac..51588209bddd 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1074,7 +1074,7 @@ i915_request_await_request(struct i915_request *to, 
struct i915_request *from)
return ret;
}
  
-	if (to->engine == from->engine)

+   if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask)))
ret = i915_sw_fence_await_sw_fence_gfp(>submit,
   >submit,
   I915_FENCE_GFP);



Reviewed-by: Tvrtko Ursulin 

Regards,

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


[Intel-gfx] [PATCH 1/2] drm/i915: Reorder await_execution before await_request

2020-05-26 Thread Chris Wilson
Reorder the code so that we can reuse the await_execution from a special
case in await_request in the next patch.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c | 264 ++--
 1 file changed, 132 insertions(+), 132 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c282719ad3ac..33bbad623e02 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1053,37 +1053,91 @@ emit_semaphore_wait(struct i915_request *to,
 I915_FENCE_GFP);
 }
 
+static bool intel_timeline_sync_has_start(struct intel_timeline *tl,
+ struct dma_fence *fence)
+{
+   return __intel_timeline_sync_is_later(tl,
+ fence->context,
+ fence->seqno - 1);
+}
+
+static int intel_timeline_sync_set_start(struct intel_timeline *tl,
+const struct dma_fence *fence)
+{
+   return __intel_timeline_sync_set(tl, fence->context, fence->seqno - 1);
+}
+
 static int
-i915_request_await_request(struct i915_request *to, struct i915_request *from)
+__i915_request_await_execution(struct i915_request *to,
+  struct i915_request *from,
+  void (*hook)(struct i915_request *rq,
+   struct dma_fence *signal))
 {
-   int ret;
+   int err;
 
-   GEM_BUG_ON(to == from);
-   GEM_BUG_ON(to->timeline == from->timeline);
+   GEM_BUG_ON(intel_context_is_barrier(from->context));
 
-   if (i915_request_completed(from)) {
-   i915_sw_fence_set_error_once(>submit, from->fence.error);
+   /* Submit both requests at the same time */
+   err = __await_execution(to, from, hook, I915_FENCE_GFP);
+   if (err)
+   return err;
+
+   /* Squash repeated depenendices to the same timelines */
+   if (intel_timeline_sync_has_start(i915_request_timeline(to),
+ >fence))
return 0;
+
+   /*
+* Wait until the start of this request.
+*
+* The execution cb fires when we submit the request to HW. But in
+* many cases this may be long before the request itself is ready to
+* run (consider that we submit 2 requests for the same context, where
+* the request of interest is behind an indefinite spinner). So we hook
+* up to both to reduce our queues and keep the execution lag minimised
+* in the worst case, though we hope that the await_start is elided.
+*/
+   err = i915_request_await_start(to, from);
+   if (err < 0)
+   return err;
+
+   /*
+* Ensure both start together [after all semaphores in signal]
+*
+* Now that we are queued to the HW at roughly the same time (thanks
+* to the execute cb) and are ready to run at roughly the same time
+* (thanks to the await start), our signaler may still be indefinitely
+* delayed by waiting on a semaphore from a remote engine. If our
+* signaler depends on a semaphore, so indirectly do we, and we do not
+* want to start our payload until our signaler also starts theirs.
+* So we wait.
+*
+* However, there is also a second condition for which we need to wait
+* for the precise start of the signaler. Consider that the signaler
+* was submitted in a chain of requests following another context
+* (with just an ordinary intra-engine fence dependency between the
+* two). In this case the signaler is queued to HW, but not for
+* immediate execution, and so we must wait until it reaches the
+* active slot.
+*/
+   if (intel_engine_has_semaphores(to->engine) &&
+   !i915_request_has_initial_breadcrumb(to)) {
+   err = __emit_semaphore_wait(to, from, from->fence.seqno - 1);
+   if (err < 0)
+   return err;
}
 
+   /* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
-   ret = i915_sched_node_add_dependency(>sched,
+   err = i915_sched_node_add_dependency(>sched,
 >sched,
-I915_DEPENDENCY_EXTERNAL);
-   if (ret < 0)
-   return ret;
+I915_DEPENDENCY_WEAK);
+   if (err < 0)
+   return err;
}
 
-   if (to->engine == from->engine)
-   ret = i915_sw_fence_await_sw_fence_gfp(>submit,
-  >submit,
- 

[Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

2020-05-26 Thread Chris Wilson
When we push a virtual request onto the HW, we update the rq->engine to
point to the physical engine. A request that is then submitted by the
user that waits upon the virtual engine, but along the physical engine
in use, will then see that it is due to be submitted to the same engine
and take a shortcut (and be queued without waiting for the completion
fence). However, the virtual request may be preempted (either by higher
priority users, or by timeslicing) and removed from the physical engine
to be migrated over to one of its siblings. The dependent normal request
however is oblivious to the removal of the virtual request and remains
queued to execute on HW, believing that once it reaches the head of its
queue all of its predecessors will have completed executing!

v2: Beware restriction of signal->execution_mask prior to submission.

Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Testcase: igt/gem_exec_balancer/sliced
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc:  # v5.3+
---
 drivers/gpu/drm/i915/i915_request.c | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 33bbad623e02..0b07ccc7e9bc 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq,
return 0;
 }
 
+static int
+await_request_submit(struct i915_request *to, struct i915_request *from)
+{
+   /*
+* If we are waiting on a virtual engine, then it may be
+* constrained to execute on a single engine *prior* to submission.
+* When it is submitted, it will be first submitted to the virtual
+* engine and then passed to the physical engine. We cannot allow
+* the waiter to be submitted immediately to the physical engine
+* as it may then bypass the virtual request.
+*/
+   if (to->engine == READ_ONCE(from->engine))
+   return i915_sw_fence_await_sw_fence_gfp(>submit,
+   >submit,
+   I915_FENCE_GFP);
+   else
+   return __i915_request_await_execution(to, from, NULL);
+}
+
 static int
 i915_request_await_request(struct i915_request *to, struct i915_request *from)
 {
@@ -1258,10 +1277,8 @@ i915_request_await_request(struct i915_request *to, 
struct i915_request *from)
return ret;
}
 
-   if (to->engine == READ_ONCE(from->engine))
-   ret = i915_sw_fence_await_sw_fence_gfp(>submit,
-  >submit,
-  I915_FENCE_GFP);
+   if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask)))
+   ret = await_request_submit(to, from);
else
ret = emit_semaphore_wait(to, from, I915_FENCE_GFP);
if (ret < 0)
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH] drm/i915/gt: Force the GT reset on shutdown

2020-05-26 Thread Mika Kuoppala
Chris Wilson  writes:

> Before we return control to the system, and letting it reuse all the
> pages being accessed by HW, we must disable the HW. At the moment, we
> dare not reset the GPU if it will clobber the display, but once we know
> the display has been disabled, we can proceed with the reset as we
> shutdown the module. We know the next user must reinitialise the HW for
> their purpose.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/489
> Signed-off-by: Chris Wilson 
> Cc: sta...@kernel.org

Reviewed-by: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f069551e412f..ebc29b6ee86c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -616,6 +616,11 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
>  void intel_gt_driver_release(struct intel_gt *gt)
>  {
>   struct i915_address_space *vm;
> + intel_wakeref_t wakeref;
> +
> + /* Scrub all HW state upon release */
> + with_intel_runtime_pm(gt->uncore->rpm, wakeref)
> + __intel_gt_reset(gt, ALL_ENGINES);
>  
>   vm = fetch_and_zero(>vm);
>   if (vm) /* FIXME being called twice on error paths :( */
> -- 
> 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] [RFC 02/17] dma-fence: basic lockdep annotations

2020-05-26 Thread Maarten Lankhorst
Op 12-05-2020 om 10:59 schreef Daniel Vetter:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
>   this explicit annotation can be more liberally sprinkled around.
>   With read locks lockdep isn't going to complain if the read-side
>   isn't nested the same way under all circumstances, so ABBA deadlocks
>   are ok. Which they are, since this is an annotation only.
>
> - We're using non-recursive lockdep read lock mode, since in recursive
>   read lock mode lockdep does not catch read side hazards. And we
>   _very_ much want read side hazards to be caught. For full details of
>   this limitation see
>
>   commit e91498589746065e3ae95d9a00b068e525eec34f
>   Author: Peter Zijlstra 
>   Date:   Wed Aug 23 13:13:11 2017 +0200
>
>   locking/lockdep/selftests: Add mixed read-write ABBA tests
>
> - To allow nesting of the read-side explicit annotations we explicitly
>   keep track of the nesting. lock_is_held() allows us to do that.
>
> - The wait-side annotation is a write lock, and entirely done within
>   dma_fence_wait() for everyone by default.
>
> - To be able to freely annotate helper functions I want to make it ok
>   to call dma_fence_begin/end_signalling from soft/hardirq context.
>   First attempt was using the hardirq locking context for the write
>   side in lockdep, but this forces all normal spinlocks nested within
>   dma_fence_begin/end_signalling to be spinlocks. That bollocks.
>
>   The approach now is to simple check in_atomic(), and for these cases
>   entirely rely on the might_sleep() check in dma_fence_wait(). That
>   will catch any wrong nesting against spinlocks from soft/hardirq
>   contexts.
>
> The idea here is that every code path that's critical for eventually
> signalling a dma_fence should be annotated with
> dma_fence_begin/end_signalling. The annotation ideally starts right
> after a dma_fence is published (added to a dma_resv, exposed as a
> sync_file fd, attached to a drm_syncobj fd, or anything else that
> makes the dma_fence visible to other kernel threads), up to and
> including the dma_fence_wait(). Examples are irq handlers, the
> scheduler rt threads, the tail of execbuf (after the corresponding
> fences are visible), any workers that end up signalling dma_fences and
> really anything else. Not annotated should be code paths that only
> complete fences opportunistically as the gpu progresses, like e.g.
> shrinker/eviction code.
>
> The main class of deadlocks this is supposed to catch are:
>
> Thread A:
>
>   mutex_lock(A);
>   mutex_unlock(A);
>
>   dma_fence_signal();
>
> Thread B:
>
>   mutex_lock(A);
>   dma_fence_wait();
>   mutex_unlock(A);
>
> Thread B is blocked on A signalling the fence, but A never gets around
> to that because it cannot acquire the lock A.
>
> Note that dma_fence_wait() is allowed to be nested within
> dma_fence_begin/end_signalling sections. To allow this to happen the
> read lock needs to be upgraded to a write lock, which means that any
> other lock is acquired between the dma_fence_begin_signalling() call and
> the call to dma_fence_wait(), and still held, this will result in an
> immediate lockdep complaint. The only other option would be to not
> annotate such calls, defeating the point. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson 
> Cc: Maarten Lankhorst 
> Cc: Christian König 
> Signed-off-by: Daniel Vetter 
> ---

This is something we definitely need, all drivers need to follow the same 
rules, in order to put some light in the darkness. :)

Reviewed-by: Maarten Lankhorst 

>  drivers/dma-buf/dma-fence.c | 53 +
>  include/linux/dma-fence.h   | 12 +
>  2 files changed, 65 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
>  }
>  EXPORT_SYMBOL(dma_fence_context_alloc);
>  
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map   dma_fence_lockdep_map = {
> + .name = "dma_fence_map"
> +};
> +
> +bool dma_fence_begin_signalling(void)
> +{
> + /* explicitly nesting ... */
> + if (lock_is_held_type(_fence_lockdep_map, 1))
> + return true;
> +
> + /* rely on might_sleep check for soft/hardirq locks */
> + if (in_atomic())
> + return true;
> +
> + /* ... and non-recursive readlock */
> + lock_acquire(_fence_lockdep_map, 

Re: [Intel-gfx] [PATCH v6 00/16] drm/i915: Add support for HDCP 1.4 over MST connectors

2020-05-26 Thread Ramalingam C
On 2020-05-20 at 09:11:38 -0400, Sean Paul wrote:
> On Mon, May 18, 2020 at 12:41 PM Ramalingam C  wrote:
> >
> > On 2020-05-18 at 10:32:09 -0400, Sean Paul wrote:
> > > On Fri, May 15, 2020 at 10:48 AM Ramalingam C  
> > > wrote:
> > > >
> > > > On 2020-04-29 at 15:54:46 -0400, Sean Paul wrote:
> > > > > From: Sean Paul 
> > > > >
> > > > > Changes in v6:
> > > > > -Rebased on -tip
> > > > > -Disabled HDCP over MST on GEN12
> > > > > -Addressed Lyude's review comments in the 
> > > > > QUERY_STREAM_ENCRYPTION_STATUS patch
> > > >
> > > > Sean,
> > > >
> > > > What is the test setup you have used?
> > > >
> > >
> > > Hi Ram,
> > > Thanks for the feedback. To be completely honest it's really
> > > frustrating that I'm just now getting questions and review feedback
> > > (which I've been begging for on IRC) on this review that could have
> > > been addressed ~5 months ago. It's super disruptive to have to keep
> > > switching back to this after a long hiatus and many i915 refactors
> > > complicating my rebases.
> > Hi Sean,
> >
> > As a developer I really feel bad for the delay happened in review.
> > I couldn't spend required time for understanding MST part hence I
> > couldn't review.
> >
> > Just for this series now I have started preparing myself on these topics,
> > hence started reviewing the series.
> >
> > If you are still interested to work on this, I can commit for regular 
> > reviews.
> >
> 
> Thanks Ram. I'm still incentivized to get this in. Once you have had a
> chance to look over the whole series, I'll revise again.
Sean

I have already gone through the whole series when I commented before.
Most of the prepation patches are looking good. I am having questions
on MST HDCP enabling sequence and what is the decision on streams to be
encrypted on the MST HDCP link (all/selective) etc.

Which were posted on 
https://patchwork.freedesktop.org/patch/363798/?series=70393=6

And also, could you please explain the level of testing this series has
gone through?

-Ram
> 
> Sean
> 
> 
> 
> > Thanks,
> > Ram.
> > >
> > > If no one wants this patchset, that's fine, please just let me know so
> > > I don't waste any more time. If Intel is interested, could we please
> > > stop the review trickle and lay out exactly what needs to be done to
> > > get this landed?
> > >
> > > Sean
> > >
> > >
> > > > I am afraid our CI dont have the coverage for MST capability yet to 
> > > > provide
> > > > the functional status of the code.
> > > >
> > > > -Ram.
> > > > >
> > > > > Sean Paul (16):
> > > > >   drm/i915: Fix sha_text population code
> > > > >   drm/i915: Clear the repeater bit on HDCP disable
> > > > >   drm/i915: WARN if HDCP signalling is enabled upon disable
> > > > >   drm/i915: Intercept Aksv writes in the aux hooks
> > > > >   drm/i915: Use the cpu_transcoder in intel_hdcp to toggle HDCP
> > > > > signalling
> > > > >   drm/i915: Factor out hdcp->value assignments
> > > > >   drm/i915: Protect workers against disappearing connectors
> > > > >   drm/i915: Don't fully disable HDCP on a port if multiple pipes are
> > > > > using it
> > > > >   drm/i915: Support DP MST in enc_to_dig_port() function
> > > > >   drm/i915: Use ddi_update_pipe in intel_dp_mst
> > > > >   drm/i915: Factor out HDCP shim functions from dp for use by dp_mst
> > > > >   drm/i915: Plumb port through hdcp init
> > > > >   drm/i915: Add connector to hdcp_shim->check_link()
> > > > >   drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband
> > > > > message
> > > > >   drm/i915: Print HDCP version info for all connectors
> > > > >   drm/i915: Add HDCP 1.4 support for MST connectors
> > > > >
> > > > >  drivers/gpu/drm/drm_dp_mst_topology.c | 142 
> > > > >  drivers/gpu/drm/i915/Makefile |   1 +
> > > > >  drivers/gpu/drm/i915/display/intel_ddi.c  |  29 +-
> > > > >  drivers/gpu/drm/i915/display/intel_ddi.h  |   2 +
> > > > >  .../drm/i915/display/intel_display_debugfs.c  |  21 +-
> > > > >  .../drm/i915/display/intel_display_types.h|  30 +-
> > > > >  drivers/gpu/drm/i915/display/intel_dp.c   | 654 +--
> > > > >  drivers/gpu/drm/i915/display/intel_dp.h   |   9 +
> > > > >  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 743 
> > > > > ++
> > > > >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  19 +
> > > > >  drivers/gpu/drm/i915/display/intel_hdcp.c | 217 +++--
> > > > >  drivers/gpu/drm/i915/display/intel_hdcp.h |   2 +-
> > > > >  drivers/gpu/drm/i915/display/intel_hdmi.c |  25 +-
> > > > >  .../drm/selftests/test-drm_dp_mst_helper.c|  17 +
> > > > >  include/drm/drm_dp_helper.h   |   3 +
> > > > >  include/drm/drm_dp_mst_helper.h   |  44 ++
> > > > >  include/drm/drm_hdcp.h|   3 +
> > > > >  17 files changed, 1235 insertions(+), 726 deletions(-)
> > > > >  create mode 100644 drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > > > >
> > > > > --
> > > > > Sean 

[Intel-gfx] [PATCH v1] drm/i915: Fix wrong CDCLK adjustment changes

2020-05-26 Thread Stanislav Lisovskiy
Previous patch didn't take into account all pipes
but only those in state, which could cause wrong
CDCLK conclcusions and calculations.
Also there was a severe issue with min_cdclk being
assigned to 0 every compare cycle.

Too bad this was found by me only after merge.
This could be also causing the issues in test, however
not clear - anyway marking this as fixing the
"Adjust CDCLK accordingly to our DBuf bw needs".

Signed-off-by: Stanislav Lisovskiy 
Fixes: cd1915460861 ("Adjust CDCLK accordingly to our DBuf bw needs")
---
 drivers/gpu/drm/i915/display/intel_bw.c  | 51 
 drivers/gpu/drm/i915/display/intel_cdclk.c   | 19 +---
 drivers/gpu/drm/i915/display/intel_display.c | 26 +-
 3 files changed, 53 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_bw.c 
b/drivers/gpu/drm/i915/display/intel_bw.c
index a79bd7aeb03b..8096138abecc 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -437,6 +437,7 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
struct intel_crtc *crtc;
int max_bw = 0;
int slice_id;
+   enum pipe pipe;
int i;
 
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
@@ -447,7 +448,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
if (IS_ERR(new_bw_state))
return PTR_ERR(new_bw_state);
 
-   crtc_bw = _bw_state->dbuf_bw[crtc->pipe];
+   old_bw_state = intel_atomic_get_old_bw_state(state);
+
+   crtc_bw = _bw_state->dbuf_bw[pipe];
 
memset(_bw->used_bw, 0, sizeof(crtc_bw->used_bw));
 
@@ -478,6 +481,15 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
for_each_dbuf_slice_in_mask(slice_id, dbuf_mask)
crtc_bw->used_bw[slice_id] += data_rate;
}
+   }
+
+   if (!old_bw_state)
+   return 0;
+
+   for_each_pipe(dev_priv, pipe) {
+   struct intel_dbuf_bw *crtc_bw;
+
+   crtc_bw = _bw_state->dbuf_bw[pipe];
 
for_each_dbuf_slice(slice_id) {
/*
@@ -490,14 +502,9 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state *state)
 */
max_bw += crtc_bw->used_bw[slice_id];
}
-
-   new_bw_state->min_cdclk = max_bw / 64;
-
-   old_bw_state = intel_atomic_get_old_bw_state(state);
}
 
-   if (!old_bw_state)
-   return 0;
+   new_bw_state->min_cdclk = max_bw / 64;
 
if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
int ret = intel_atomic_lock_global_state(_bw_state->base);
@@ -511,34 +518,38 @@ int skl_bw_calc_min_cdclk(struct intel_atomic_state 
*state)
 
 int intel_bw_calc_min_cdclk(struct intel_atomic_state *state)
 {
-   int i;
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   struct intel_bw_state *new_bw_state = NULL;
+   struct intel_bw_state *old_bw_state = NULL;
const struct intel_crtc_state *crtc_state;
struct intel_crtc *crtc;
int min_cdclk = 0;
-   struct intel_bw_state *new_bw_state = NULL;
-   struct intel_bw_state *old_bw_state = NULL;
+   enum pipe pipe;
+   int i;
 
for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
-   struct intel_cdclk_state *cdclk_state;
-
new_bw_state = intel_atomic_get_bw_state(state);
if (IS_ERR(new_bw_state))
return PTR_ERR(new_bw_state);
 
-   cdclk_state = intel_atomic_get_cdclk_state(state);
-   if (IS_ERR(cdclk_state))
-   return PTR_ERR(cdclk_state);
-
-   min_cdclk = max(cdclk_state->min_cdclk[crtc->pipe], min_cdclk);
-
-   new_bw_state->min_cdclk = min_cdclk;
-
old_bw_state = intel_atomic_get_old_bw_state(state);
}
 
if (!old_bw_state)
return 0;
 
+   for_each_pipe(dev_priv, pipe) {
+   struct intel_cdclk_state *cdclk_state;
+
+   cdclk_state = intel_atomic_get_new_cdclk_state(state);
+   if (!cdclk_state)
+   return 0;
+
+   min_cdclk = max(cdclk_state->min_cdclk[pipe], min_cdclk);
+   }
+
+   new_bw_state->min_cdclk = min_cdclk;
+
if (new_bw_state->min_cdclk != old_bw_state->min_cdclk) {
int ret = intel_atomic_lock_global_state(_bw_state->base);
 
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index f9b0fc7317de..08468b121d02 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2084,9 +2084,12 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
 static int 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Reorder await_execution before await_request

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915: Reorder await_execution before 
await_request
URL   : https://patchwork.freedesktop.org/series/77653/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8537 -> Patchwork_17775


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@kms_chamelium@hdmi-crc-fast:
- fi-kbl-7500u:   [PASS][1] -> [DMESG-FAIL][2] ([i915#165])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17775/fi-kbl-7500u/igt@kms_chamel...@hdmi-crc-fast.html

  
  [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165


Participating hosts (50 -> 45)
--

  Additional (1): fi-kbl-7560u 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8537 -> Patchwork_17775

  CI-20190529: 20190529
  CI_DRM_8537: 05a47cd761c49c3fa87648c30df0fd4d64b0b8c5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17775: 95d84329d1e9e74b00a4372c6b5b24a4d5a58d0c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

95d84329d1e9 drm/i915/gt: Do not schedule normal requests immediately along 
virtual
acc962187d69 drm/i915: Reorder await_execution before await_request

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix wrong CDCLK adjustment changes

2020-05-26 Thread Patchwork
== Series Details ==

Series: drm/i915: Fix wrong CDCLK adjustment changes
URL   : https://patchwork.freedesktop.org/series/77654/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8537 -> Patchwork_17776


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][1] -> [SKIP][2] ([fdo#109271])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/fi-kbl-guc/igt@i915_pm_...@module-reload.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/fi-kbl-guc/igt@i915_pm_...@module-reload.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [TIMEOUT][3] ([i915#1288]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8537/fi-glk-dsi/igt@i915_pm_...@module-reload.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17776/fi-glk-dsi/igt@i915_pm_...@module-reload.html

  
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1288]: https://gitlab.freedesktop.org/drm/intel/issues/1288


Participating hosts (50 -> 44)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8537 -> Patchwork_17776

  CI-20190529: 20190529
  CI_DRM_8537: 05a47cd761c49c3fa87648c30df0fd4d64b0b8c5 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5678: c1f30ee09ac2e7eb3e8e90245239731a169a6050 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17776: ac70e0df58bb143436d9fc1229484d87661b4638 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

ac70e0df58bb drm/i915: Fix wrong CDCLK adjustment changes

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915/rkl: Disable PSR2

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915/rkl: Disable PSR2
URL   : https://patchwork.freedesktop.org/series/77676/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3b5607178b4a drm/i915/rkl: Disable PSR2
54e02163a7f7 drm/i915: Add plane damage clips property
af8c4264fa17 drm/i915: Reorder intel_psr2_config_valid()
837cb19aab8f drm/i915: Add PSR2 software tracking registers
-:29: WARNING:LONG_LINE: line over 100 characters
#29: FILE: drivers/gpu/drm/i915/i915_reg.h:4574:
+#define  PSR2_MAN_TRK_CTL_REGION_START_ADDR(val)   
REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK, val)

-:31: WARNING:LONG_LINE: line over 100 characters
#31: FILE: drivers/gpu/drm/i915/i915_reg.h:4576:
+#define  PSR2_MAN_TRK_CTL_REGION_END_ADDR(val) 
REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK, val)

-:63: WARNING:LONG_LINE: line over 100 characters
#63: FILE: drivers/gpu/drm/i915/i915_reg.h:7163:
+#define _PLANE_SEL_FETCH_BASE_1(pipe) _PIPE(pipe, _PLANE_SEL_FETCH_BASE_1_A, 
_PLANE_SEL_FETCH_BASE_1_A)

total: 0 errors, 3 warnings, 0 checks, 87 lines checked
8dcb0cb37119 drm/i915: Implement PSR2 selective fetch
-:565: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#565: FILE: drivers/gpu/drm/i915/i915_params.c:92:
+i915_param_named_unsafe(enable_psr2_sel_fetch, int, 0400,
+   "Enable PSR2 selective fetch "

total: 0 errors, 0 warnings, 1 checks, 488 lines checked
d80c35b30749 drm/i915: Implement PSR2 selective fetch WAs

___
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/6] drm/i915/rkl: Disable PSR2

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915/rkl: Disable PSR2
URL   : https://patchwork.freedesktop.org/series/77676/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8540 -> Patchwork_17781


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@kms_chamelium@dp-crc-fast:
- fi-icl-u2:  [FAIL][1] ([i915#262]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html

  
  [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262


Participating hosts (51 -> 45)
--

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-byt-clapper fi-bdw-samus 


Build changes
-

  * Linux: CI_DRM_8540 -> Patchwork_17781

  CI-20190529: 20190529
  CI_DRM_8540: b02ab97d6794973472bfdf91b62448d9354fd698 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5679: 93639b4e52140826c24da21865e912a280f9aefb @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_17781: d80c35b307494430f7e33f71733ea99e5dc42673 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d80c35b30749 drm/i915: Implement PSR2 selective fetch WAs
8dcb0cb37119 drm/i915: Implement PSR2 selective fetch
837cb19aab8f drm/i915: Add PSR2 software tracking registers
af8c4264fa17 drm/i915: Reorder intel_psr2_config_valid()
54e02163a7f7 drm/i915: Add plane damage clips property
3b5607178b4a drm/i915/rkl: Disable PSR2

== Logs ==

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


[Intel-gfx] [PATCH 2/6] drm/i915: Add plane damage clips property

2020-05-26 Thread José Roberto de Souza
This property will be used by PSR2 software tracking, adding it to
GEN12+.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 4 
 drivers/gpu/drm/i915/display/intel_sprite.c  | 4 
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f40b909952cc..b69878334040 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16476,6 +16477,9 @@ intel_cursor_plane_create(struct drm_i915_private 
*dev_priv,
zpos = RUNTIME_INFO(dev_priv)->num_sprites[pipe] + 1;
drm_plane_create_zpos_immutable_property(>base, zpos);
 
+   if (INTEL_GEN(dev_priv) >= 12)
+   drm_plane_enable_fb_damage_clips(>base);
+
drm_plane_helper_add(>base, _plane_helper_funcs);
 
return cursor;
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 571c36f929bd..8be06cb25999 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -3151,6 +3152,9 @@ skl_universal_plane_create(struct drm_i915_private 
*dev_priv,
 
drm_plane_create_zpos_immutable_property(>base, plane_id);
 
+   if (INTEL_GEN(dev_priv) >= 12)
+   drm_plane_enable_fb_damage_clips(>base);
+
drm_plane_helper_add(>base, _plane_helper_funcs);
 
return plane;
-- 
2.26.2

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


[Intel-gfx] [PATCH 5/6] drm/i915: Implement PSR2 selective fetch

2020-05-26 Thread José Roberto de Souza
All GEN12 platforms supports PSR2 selective fetch but not all GEN12
platforms supports PSR2 hardware tracking(aka RKL).

This feature consists in software program registers with the damaged
area of each plane this way hardware will only fetch from memory those
areas and sent the PSR2 selective update blocks to panel, saving even
more power but to it actually happen userspace needs to send the
damaged areas otherwise it will still fetch the whole plane as
fallback.
As today Gnome3 do not send damaged areas and the only compositor that
I'm aware that sets the damaged areas is Weston.
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/17

So here implementing page flip part, it is still completely missing
frontbuffer modifications, that is why the enable_psr2_sel_fetch
parameter was added.

The plan is to switch all GEN12 platforms to selective fetch when
ready, it will also depend in add some tests sending damaged areas.
I have a hacked version of kms_psr2_su with 3 planes that I can
cleanup and send in a few days(99% of PSR2 selective fetch changes was
done during my free time while bored during quarantine rainy days).

BSpec: 55229
Cc: Ville Syrjälä 
Cc: Imre Deak 
Cc: Gwan-gyeong Mun 
Cc: Rodrigo Vivi 
Cc: Dhinakaran Pandiyan 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c  |   5 +
 .../drm/i915/display/intel_display_debugfs.c  |   3 +
 .../drm/i915/display/intel_display_types.h|  10 +
 drivers/gpu/drm/i915/display/intel_psr.c  | 329 +-
 drivers/gpu/drm/i915/display/intel_psr.h  |  10 +
 drivers/gpu/drm/i915/display/intel_sprite.c   |   2 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_params.c|   5 +
 drivers/gpu/drm/i915/i915_params.h|   1 +
 9 files changed, 352 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b69878334040..984809208c29 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11729,6 +11729,8 @@ static void i9xx_update_cursor(struct intel_plane 
*plane,
if (INTEL_GEN(dev_priv) >= 9)
skl_write_cursor_wm(plane, crtc_state);
 
+   intel_psr2_program_plane_sel_fetch(plane, crtc_state, plane_state);
+
if (plane->cursor.base != base ||
plane->cursor.size != fbc_ctl ||
plane->cursor.cntl != cntl) {
@@ -15115,6 +15117,8 @@ static void commit_pipe_config(struct 
intel_atomic_state *state,
 
if (new_crtc_state->update_pipe)
intel_pipe_fastset(old_crtc_state, new_crtc_state);
+
+   intel_psr2_program_trans_man_trk_ctl(new_crtc_state);
}
 
if (dev_priv->display.atomic_update_watermarks)
@@ -15156,6 +15160,7 @@ static void intel_update_crtc(struct intel_atomic_state 
*state,
intel_color_load_luts(new_crtc_state);
 
intel_pre_plane_update(state, crtc);
+   intel_psr2_sel_fetch_update(state, crtc);
 
if (new_crtc_state->update_pipe)
intel_encoders_update_pipe(state, crtc);
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 70525623bcdf..0f600974462b 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -417,6 +417,9 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
su_blocks = su_blocks >> PSR2_SU_STATUS_SHIFT(frame);
seq_printf(m, "%d\t%d\n", frame, su_blocks);
}
+
+   seq_printf(m, "PSR2 selective fetch: %s\n",
+  enableddisabled(psr->psr2_sel_fetch_enabled));
}
 
 unlock:
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 30b2767578dc..b77a512e5362 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -586,6 +586,13 @@ struct intel_plane_state {
u32 planar_slave;
 
struct drm_intel_sprite_colorkey ckey;
+
+   struct {
+   u32 ctl;
+   u32 pos;
+   u32 offset;
+   u32 size;
+   } psr2_sel_fetch;
 };
 
 struct intel_initial_plane_config {
@@ -931,6 +938,7 @@ struct intel_crtc_state {
 
bool has_psr;
bool has_psr2;
+   bool enable_psr2_sel_fetch;
u32 dc3co_exitline;
 
/*
@@ -1070,6 +1078,8 @@ struct intel_crtc_state {
 
/* For DSB related info */
struct intel_dsb *dsb;
+
+   u32 psr2_sw_man_track_ctl;
 };
 
 enum intel_pipe_crc_source {
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 

[Intel-gfx] [PATCH 4/6] drm/i915: Add PSR2 software tracking registers

2020-05-26 Thread José Roberto de Souza
This registers will be used to implement PSR2 software tracking.

BSpec: 55229
BSpec: 50424
BSpec: 50420
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_reg.h | 68 ++---
 1 file changed, 63 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9d50fe0f375..6f547e459d30 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4566,6 +4566,18 @@ enum {
 #define PSR2_SU_STATUS_MASK(frame) (0x3ff << PSR2_SU_STATUS_SHIFT(frame))
 #define PSR2_SU_STATUS_FRAMES  8
 
+#define _PSR2_MAN_TRK_CTL_A0x60910
+#define _PSR2_MAN_TRK_CTL_EDP  0x6f910
+#define PSR2_MAN_TRK_CTL(tran) _MMIO_TRANS2(tran, 
_PSR2_MAN_TRK_CTL_A)
+#define  PSR2_MAN_TRK_CTL_ENABLE   REG_BIT(31)
+#define  PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK   REG_GENMASK(30, 21)
+#define  PSR2_MAN_TRK_CTL_REGION_START_ADDR(val)   
REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_START_ADDR_MASK, val)
+#define  PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK REG_GENMASK(20, 11)
+#define  PSR2_MAN_TRK_CTL_REGION_END_ADDR(val) 
REG_FIELD_PREP(PSR2_MAN_TRK_CTL_REGION_END_ADDR_MASK, val)
+#define  PSR2_MAN_TRK_CTL_SINGLE_FULL_FRAMEREG_BIT(3)
+#define  PSR2_MAN_TRK_CTL_CONTINUOS_FULL_FRAME REG_BIT(2)
+#define  PSR2_MAN_TRK_CTL_PARTIAL_FRAME_UPDATE REG_BIT(1)
+
 /* VGA port control */
 #define ADPA   _MMIO(0x61100)
 #define PCH_ADPA_MMIO(0xe1100)
@@ -7129,7 +7141,52 @@ enum {
 #define PLANE_COLOR_CTL(pipe, plane)   \
_MMIO_PLANE(plane, _PLANE_COLOR_CTL_1(pipe), _PLANE_COLOR_CTL_2(pipe))
 
-#/* SKL new cursor registers */
+#define _PLANE_SEL_FETCH_BASE_1_A  0x70890
+#define _PLANE_SEL_FETCH_BASE_2_A  0x708B0
+#define _PLANE_SEL_FETCH_BASE_3_A  0x708D0
+#define _PLANE_SEL_FETCH_BASE_4_A  0x708F0
+#define _PLANE_SEL_FETCH_BASE_5_A  0x70920
+#define _PLANE_SEL_FETCH_BASE_6_A  0x70940
+#define _PLANE_SEL_FETCH_BASE_7_A  0x70960
+#define _PLANE_SEL_FETCH_BASE_CUR_A0x70880
+#define _PLANE_SEL_FETCH_BASE_1_B  0x70990
+
+#define _PLANE_SEL_FETCH_BASE_A(plane) _PICK(plane, \
+_PLANE_SEL_FETCH_BASE_1_A, \
+_PLANE_SEL_FETCH_BASE_2_A, \
+_PLANE_SEL_FETCH_BASE_3_A, \
+_PLANE_SEL_FETCH_BASE_4_A, \
+_PLANE_SEL_FETCH_BASE_5_A, \
+_PLANE_SEL_FETCH_BASE_6_A, \
+_PLANE_SEL_FETCH_BASE_7_A, \
+_PLANE_SEL_FETCH_BASE_CUR_A)
+#define _PLANE_SEL_FETCH_BASE_1(pipe) _PIPE(pipe, _PLANE_SEL_FETCH_BASE_1_A, 
_PLANE_SEL_FETCH_BASE_1_A)
+#define PLANE_SEL_FETCH_BASE(pipe, plane) (_PLANE_SEL_FETCH_BASE_1(pipe) - \
+  _PLANE_SEL_FETCH_BASE_1_A + \
+  _PLANE_SEL_FETCH_BASE_A(plane))
+
+#define _PLANE_SEL_FETCH_CTL_1_A   0x70890
+#define PLANE_SEL_FETCH_CTL(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, 
plane) + \
+  _PLANE_SEL_FETCH_CTL_1_A - \
+  _PLANE_SEL_FETCH_BASE_1_A)
+#define PLANE_SET_FETCH_CTL_ENABLE REG_BIT(31)
+
+#define _PLANE_SEL_FETCH_POS_1_A   0x70894
+#define PLANE_SEL_FETCH_POS(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, 
plane) + \
+  _PLANE_SEL_FETCH_POS_1_A - \
+  _PLANE_SEL_FETCH_BASE_1_A)
+
+#define _PLANE_SEL_FETCH_SIZE_1_A  0x70898
+#define PLANE_SEL_FETCH_SIZE(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, 
plane) + \
+   _PLANE_SEL_FETCH_SIZE_1_A - \
+   _PLANE_SEL_FETCH_BASE_1_A)
+
+#define _PLANE_SEL_FETCH_OFFSET_1_A0x7089C
+#define PLANE_SEL_FETCH_OFFSET(pipe, plane) _MMIO(PLANE_SEL_FETCH_BASE(pipe, 
plane) + \
+ _PLANE_SEL_FETCH_OFFSET_1_A - 
\
+ _PLANE_SEL_FETCH_BASE_1_A)
+
+/* SKL new cursor registers */
 #define _CUR_BUF_CFG_A 0x7017c
 #define _CUR_BUF_CFG_B 0x7117c
 #define CUR_BUF_CFG(pipe)  _MMIO_PIPE(pipe, _CUR_BUF_CFG_A, _CUR_BUF_CFG_B)
@@ -7775,11 +7832,12 @@ enum {
 # define CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE (1 << 5)
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
 
-#define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define 

[Intel-gfx] [PATCH 1/6] drm/i915/rkl: Disable PSR2

2020-05-26 Thread José Roberto de Souza
RKL doesn't have PSR2 HW tracking, it was replaced by software/manual
tracking.  The driver is required to track the areas that needs update
and program hardware to send selective updates.

So until the software tracking is implemented, PSR2 needs to be disabled
for platforms without PSR2 HW tracking.

This is part of RKL enabling patches, just cherry-picking here as it
is needed.

BSpec: 50422
BSpec: 50424

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Signed-off-by: José Roberto de Souza 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 15 +++
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_pci.c  |  2 ++
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 4 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index b7a2c102648a..714c590b39f5 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -646,6 +646,21 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   /*
+* Some platforms lack PSR2 HW tracking and instead require manual
+* tracking by software.  In this case, the driver is required to track
+* the areas that need updates and program hardware to send selective
+* updates.
+*
+* So until the software tracking is implemented, PSR2 needs to be
+* disabled for platforms without PSR2 HW tracking.
+*/
+   if (!HAS_PSR_HW_TRACKING(dev_priv)) {
+   drm_dbg_kms(_priv->drm,
+   "No PSR2 HW tracking in the platform\n");
+   return false;
+   }
+
/*
 * DSC and PSR2 cannot be enabled simultaneously. If a requested
 * resolution requires DSC to be enabled, priority is given to DSC
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 98f2c448cd92..146bfd276ce7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1632,6 +1632,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_DDI(dev_priv)   (INTEL_INFO(dev_priv)->display.has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg)
 #define HAS_PSR(dev_priv)   (INTEL_INFO(dev_priv)->display.has_psr)
+#define HAS_PSR_HW_TRACKING(dev_priv) \
+   (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking)
 #define HAS_TRANSCODER(dev_priv, trans) 
((INTEL_INFO(dev_priv)->cpu_transcoder_mask & BIT(trans)) != 0)
 
 #define HAS_RC6(dev_priv)   (INTEL_INFO(dev_priv)->has_rc6)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7e3252fbad8e..709e857a3983 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -536,6 +536,7 @@ static const struct intel_device_info vlv_info = {
.display.has_ddi = 1, \
.has_fpga_dbg = 1, \
.display.has_psr = 1, \
+   .display.has_psr_hw_tracking = 1, \
.display.has_dp_mst = 1, \
.has_rc6p = 0 /* RC6p removed-by HSW */, \
HSW_PIPE_OFFSETS, \
@@ -690,6 +691,7 @@ static const struct intel_device_info skl_gt4_info = {
.display.has_fbc = 1, \
.display.has_hdcp = 1, \
.display.has_psr = 1, \
+   .display.has_psr_hw_tracking = 1, \
.has_runtime_pm = 1, \
.display.has_csr = 1, \
.has_rc6 = 1, \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index c912acd06109..1ada48ef517c 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -147,6 +147,7 @@ enum intel_ppgtt_type {
func(has_modular_fia); \
func(has_overlay); \
func(has_psr); \
+   func(has_psr_hw_tracking); \
func(overlay_needs_physical); \
func(supports_tv);
 
-- 
2.26.2

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


[Intel-gfx] [PATCH 3/6] drm/i915: Reorder intel_psr2_config_valid()

2020-05-26 Thread José Roberto de Souza
Future patches will bring PSR2 selective fetch configuration
validation but most of the configuration checks will be used for HW
tracking and selective fetch so the reoder was necessary.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 50 
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index 714c590b39f5..0c86e9e341a2 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -646,21 +646,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
-   /*
-* Some platforms lack PSR2 HW tracking and instead require manual
-* tracking by software.  In this case, the driver is required to track
-* the areas that need updates and program hardware to send selective
-* updates.
-*
-* So until the software tracking is implemented, PSR2 needs to be
-* disabled for platforms without PSR2 HW tracking.
-*/
-   if (!HAS_PSR_HW_TRACKING(dev_priv)) {
-   drm_dbg_kms(_priv->drm,
-   "No PSR2 HW tracking in the platform\n");
-   return false;
-   }
-
/*
 * DSC and PSR2 cannot be enabled simultaneously. If a requested
 * resolution requires DSC to be enabled, priority is given to DSC
@@ -672,6 +657,12 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
+   if (crtc_state->crc_enabled) {
+   drm_dbg_kms(_priv->drm,
+   "PSR2 not enabled because it would inhibit pipe CRC 
calculation\n");
+   return false;
+   }
+
if (INTEL_GEN(dev_priv) >= 12) {
psr_max_h = 5120;
psr_max_v = 3200;
@@ -686,14 +677,6 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
max_bpp = 24;
}
 
-   if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
-   drm_dbg_kms(_priv->drm,
-   "PSR2 not enabled, resolution %dx%d > max supported 
%dx%d\n",
-   crtc_hdisplay, crtc_vdisplay,
-   psr_max_h, psr_max_v);
-   return false;
-   }
-
if (crtc_state->pipe_bpp > max_bpp) {
drm_dbg_kms(_priv->drm,
"PSR2 not enabled, pipe bpp %d > max supported 
%d\n",
@@ -714,9 +697,26 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
return false;
}
 
-   if (crtc_state->crc_enabled) {
+   /*
+* Some platforms lack PSR2 HW tracking and instead require manual
+* tracking by software.  In this case, the driver is required to track
+* the areas that need updates and program hardware to send selective
+* updates.
+*
+* So until the software tracking is implemented, PSR2 needs to be
+* disabled for platforms without PSR2 HW tracking.
+*/
+   if (!HAS_PSR_HW_TRACKING(dev_priv)) {
drm_dbg_kms(_priv->drm,
-   "PSR2 not enabled because it would inhibit pipe CRC 
calculation\n");
+   "No PSR2 HW tracking in the platform\n");
+   return false;
+   }
+
+   if (crtc_hdisplay > psr_max_h || crtc_vdisplay > psr_max_v) {
+   drm_dbg_kms(_priv->drm,
+   "PSR2 not enabled, resolution %dx%d > max supported 
%dx%d\n",
+   crtc_hdisplay, crtc_vdisplay,
+   psr_max_h, psr_max_v);
return false;
}
 
-- 
2.26.2

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


[Intel-gfx] [PATCH 6/6] drm/i915: Implement PSR2 selective fetch WAs

2020-05-26 Thread José Roberto de Souza
This feature have 3 WAs and as commented WA 14010103792 and
WA 14010254185 conflicts, so leaving the feature disabled in the
affected steppings.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_psr.c | 30 ++--
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_psr.c 
b/drivers/gpu/drm/i915/display/intel_psr.c
index bc2a2e64fe2a..c138ab69fa93 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -518,13 +518,21 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
else
val |= EDP_PSR2_TP2_TIME_2500us;
 
-   if (dev_priv->psr.psr2_sel_fetch_enabled)
+   if (dev_priv->psr.psr2_sel_fetch_enabled) {
+   /* WA 1408330847 */
+   if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+   IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0))
+   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
+DIS_RAM_BYPASS_PSR2_MAN_TRACK,
+DIS_RAM_BYPASS_PSR2_MAN_TRACK);
+
intel_de_write(dev_priv,
   PSR2_MAN_TRK_CTL(dev_priv->psr.transcoder),
   PSR2_MAN_TRK_CTL_ENABLE);
-   else if (HAS_PSR2_SEL_FETCH(dev_priv))
+   } else if (HAS_PSR2_SEL_FETCH(dev_priv)) {
intel_de_write(dev_priv,
   PSR2_MAN_TRK_CTL(dev_priv->psr.transcoder), 0);
+   }
 
/*
 * PSR2 HW is incorrectly using EDP_PSR_TP1_TP3_SEL and BSpec is
@@ -651,6 +659,17 @@ static bool intel_psr2_sel_fetch_config_valid(struct 
intel_dp *intel_dp,
return false;
}
 
+   /*
+* As WA 14010103792 conflicts with WA 14010254185 so disabling PSR2 SW
+* tracking in TGL and RKL A0
+*/
+   if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+   IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)) {
+   drm_dbg_kms(_priv->drm,
+   "PSR2 sel fetch not enabled, feature not working in 
current stepping\n");
+   return false;
+   }
+
if (crtc_state->uapi.async_flip) {
drm_dbg_kms(_priv->drm,
"PSR2 sel fetch not enabled, async flip enabled\n");
@@ -1063,6 +1082,13 @@ static void intel_psr_disable_locked(struct intel_dp 
*intel_dp)
psr_status_mask, 2000))
drm_err(_priv->drm, "Timed out waiting PSR idle state\n");
 
+   /* WA 1408330847 */
+   if (dev_priv->psr.psr2_sel_fetch_enabled &&
+   (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_A0) ||
+IS_RKL_REVID(dev_priv, RKL_REVID_A0, RKL_REVID_A0)))
+   intel_de_rmw(dev_priv, CHICKEN_PAR1_1,
+DIS_RAM_BYPASS_PSR2_MAN_TRACK, 0);
+
/* Disable PSR on Sink */
drm_dp_dpcd_writeb(_dp->aux, DP_PSR_EN_CFG, 0);
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6f547e459d30..2e374e166b2e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7833,6 +7833,7 @@ enum {
 # define CHICKEN3_DGMG_DONE_FIX_DISABLE(1 << 2)
 
 #define CHICKEN_PAR1_1 _MMIO(0x42080)
+#define  DIS_RAM_BYPASS_PSR2_MAN_TRACK (1 << 16)
 #define  SKL_DE_COMPRESSED_HASH_MODE   (1 << 15)
 #define  DPA_MASK_VBLANK_SRD   (1 << 15)
 #define  FORCE_ARB_IDLE_PLANES (1 << 14)
-- 
2.26.2

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


Re: [Intel-gfx] [PATCH v2 0/4] mm/gup, drm/i915: refactor gup_fast, convert to pin_user_pages()

2020-05-26 Thread John Hubbard

On 2020-05-23 02:41, Chris Wilson wrote:

Quoting John Hubbard (2020-05-22 06:19:27)

The purpose of posting this series is to launch a test in the
intel-gfx-ci tree. (The patches have already been merged into Andrew's
linux-mm tree.)

This applies to today's linux.git (note the base-commit tag at the
bottom).

Changes since V1:

* Fixed a bug in the refactoring patch: added FOLL_FAST_ONLY to the
   list of gup_flags *not* to WARN() on. This lead to a failure in the
   first intel-gfx-ci test run [1].

[1] 
https://lore.kernel.org/r/159008745422.32320.5724805750977048...@build.alporthouse.com


Ran this through our CI, warn and subsequent lockup were gone. That

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
t=1590273216; bh=oK85oUq4LCrgTs8kxvJryKE7a7GUQfAveFtGpNOU2dQ=;
h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality:
 Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
 X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
 Content-Transfer-Encoding;
b=QoI4eJbYYVxcoARKgFJdRrxzB/GBPqy5yKIF46/pjR75LEiZvvAX947VBwywSMYhx
 It8aQpMm6kMaF/rxiv0IPBf3tNGxNziWBAAhDXCyNqmvAS5s1HfdQh5ZoYbyDynKbJ
 uF+u9JjBOYo5uTnn3IUaGPRgl/p9k6OhwRhbJ9nYreDwIF1/1pPeo97jwP2jW7AtDf
 xDO5iJhGmwLYHPzRLilgiDdLbNhIGAP1XJ/4t/DByshidOUalduU7HxVQ9IOnysnCw
 QcqSlpyPgx5LkJOvs63gO8n28hHJnoJ4FggNXC3D311lBWRuD7iekdP5WuvmrxUb8N
 rZKwTpl0vJl9w==


Yea! Thanks again for these test runs. I really don't like posting
patches that I can't run-time test, but this CI system mitigates
that pretty well.



lockup is worrying me now, but that doesn't seem to be an issue from
this series.



I do think it's worth following up on. And it seems like it would be
very easy to repro: just hack in a forced failure at the call site of
pin_user_pages_fast_only(), and follow the breadcrumbs.




The i915 changes were simple enough, I would have computed the pin flags
just once (since the readonly bit is static, that would be interesting
if that was allowed to change mid gup :)
Reviewed-by: Chris Wilson 
-Chris



Thanks for the review! And if lifting that check up higher in the call
stack is desired, I'm all in favor of that being done...in a separate
patch. :)

I'm trying to keep a very light touch when converting these call sites.

thanks,
--
John Hubbard
NVIDIA
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/selftests: Fix runtime PM imbalance on error

2020-05-26 Thread Dinghao Liu
When drm_dev_init() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep
the counter balanced. For error paths after this call,
things are the same.

Signed-off-by: Dinghao Liu 
---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 754d0eb6beaa..fdf01461acc6 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -200,6 +200,7 @@ struct drm_i915_private *mock_gem_device(void)
drm_mode_config_cleanup(>drm);
drm_dev_fini(>drm);
 put_device:
+   pm_runtime_put_noidle(>dev);
put_device(>dev);
 err:
return NULL;
-- 
2.17.1

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


Re: [Intel-gfx] [PATCH 35/37] drm/i915/dg1: Load DMC

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:38 -0700, Lucas De Marchi wrote:
> From: Matt Atwood 
> 
> Add support to load DMC v2.0.2 on DG1
> 
> While we're at it, tweak the TGL and RKL firmware size definition to
> follow the convention used in previous platforms. Remove obsolete
> commenting.
> 
> Bpec: 49230
> 
> Cc: Matt Roper 
> Signed-off-by: Matt Atwood 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/display/intel_csr.c | 19 +--
>  1 file changed, 13 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
> b/drivers/gpu/drm/i915/display/intel_csr.c
> index 319932b03e88..1f05876620fe 100644
> --- a/drivers/gpu/drm/i915/display/intel_csr.c
> +++ b/drivers/gpu/drm/i915/display/intel_csr.c
> @@ -38,15 +38,19 @@
>   * low-power state and comes back to normal.
>   */
>  
> -#define GEN12_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE

Why GEN12_CSR_MAX_FW_SIZE was replaced by platform size if the size is still 
the same for all?

> +#define DG1_CSR_PATH "i915/dg1_dmc_ver2_02.bin"
> +#define DG1_CSR_VERSION_REQUIRED CSR_VERSION(2, 2)
> +#define DG1_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE
> +MODULE_FIRMWARE(DG1_CSR_PATH);
>  
>  #define RKL_CSR_PATH "i915/rkl_dmc_ver2_01.bin"
>  #define RKL_CSR_VERSION_REQUIRED CSR_VERSION(2, 1)
> +#define RKL_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE
>  MODULE_FIRMWARE(RKL_CSR_PATH);
>  
>  #define TGL_CSR_PATH "i915/tgl_dmc_ver2_06.bin"
>  #define TGL_CSR_VERSION_REQUIRED CSR_VERSION(2, 6)
> -#define TGL_CSR_MAX_FW_SIZE  0x6000
> +#define TGL_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE
>  MODULE_FIRMWARE(TGL_CSR_PATH);
>  
>  #define ICL_CSR_PATH "i915/icl_dmc_ver1_09.bin"
> @@ -686,15 +690,18 @@ void intel_csr_ucode_init(struct drm_i915_private 
> *dev_priv)
>*/
>   intel_csr_runtime_pm_get(dev_priv);
>  
> - if (IS_ROCKETLAKE(dev_priv)) {
> + if (IS_DG1(dev_priv)) {
> + csr->fw_path = DG1_CSR_PATH;
> + csr->required_version = DG1_CSR_VERSION_REQUIRED;
> + csr->max_fw_size = DG1_CSR_MAX_FW_SIZE;
> + } else if (IS_ROCKETLAKE(dev_priv)) {
>   csr->fw_path = RKL_CSR_PATH;
>   csr->required_version = RKL_CSR_VERSION_REQUIRED;
> - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
> + csr->max_fw_size = RKL_CSR_MAX_FW_SIZE;
>   } else if (INTEL_GEN(dev_priv) >= 12) {
>   csr->fw_path = TGL_CSR_PATH;
>   csr->required_version = TGL_CSR_VERSION_REQUIRED;
> - /* Allow to load fw via parameter using the last known size */
> - csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
> + csr->max_fw_size = TGL_CSR_MAX_FW_SIZE;
>   } else if (IS_GEN(dev_priv, 11)) {
>   csr->fw_path = ICL_CSR_PATH;
>   csr->required_version = ICL_CSR_VERSION_REQUIRED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions

2020-05-26 Thread Lucas De Marchi

On Tue, May 26, 2020 at 10:34:47AM -0700, Jose Souza wrote:

On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:

From: Abdiel Janulgue 

Bspec: 33617, 33617

Cc: José Roberto de Souza 
Cc: Daniele Ceraolo Spurio 
Cc: Stuart Summers 
Cc: Vanshidhar Konda 
Cc: Lucas De Marchi 
Cc: Aravind Iddamsetty 
Cc: Matt Roper 
Signed-off-by: Abdiel Janulgue 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_drv.h  |  7 +++
 drivers/gpu/drm/i915/i915_pci.c  | 12 
 drivers/gpu/drm/i915/intel_device_info.c |  1 +
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 4 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9846205a5e2..382703a6c17d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_ELKHARTLAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
 #define IS_TIGERLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
 #define IS_ROCKETLAKE(dev_priv)IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
+#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
 #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
(INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
 #define IS_BDW_ULT(dev_priv) \
@@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define IS_RKL_REVID(p, since, until) \
(IS_ROCKETLAKE(p) && IS_REVID(p, since, until))

+#define DG1_REVID_A0   0x0
+#define DG1_REVID_B0   0x1
+
+#define IS_DG1_REVID(p, since, until) \
+   (IS_DG1(p) && IS_REVID(p, since, until))
+
 #define IS_LP(dev_priv)(INTEL_INFO(dev_priv)->is_lp)
 #define IS_GEN9_LP(dev_priv)   (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
 #define IS_GEN9_BC(dev_priv)   (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index be52d1b76b2e..e5a851a2dfe7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = {

 #define GEN12_DGFX_FEATURES \
GEN12_FEATURES, \
+   .memory_regions = REGION_SMEM | REGION_LMEM, \


REGION_LMEM should be left here for all GEN12 platforms?


no, this define is GEN12_DGFX_FEATURES. For dgfx, yes... we should leave
lmem region there.

Lucas De Marchi


I guess it will be detected in runtime that TGL and RKL don't have it but would 
be better to not have it in all GEN12 but will let memory experts to
shine in, other than LGTM.



.is_dgfx = 1, \
+   .has_master_unit_irq = 1, \
.has_snoop_pcie = 1

+static const struct intel_device_info intel_dg1_info = {
+   GEN12_DGFX_FEATURES,
+   PLATFORM(INTEL_DG1),
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
+   .require_force_probe = 1,
+   .engine_mask =
+   BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
+   BIT(VCS0) | BIT(VCS2),
+};
+
 #undef GEN
 #undef PLATFORM

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index c245c10c9bee..207244b9a852 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -62,6 +62,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(ELKHARTLAKE),
PLATFORM_NAME(TIGERLAKE),
PLATFORM_NAME(ROCKETLAKE),
+   PLATFORM_NAME(DG1),
 };
 #undef PLATFORM_NAME

diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 4bcaa0d6a9e6..64260faac006 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -81,6 +81,7 @@ enum intel_platform {
/* gen12 */
INTEL_TIGERLAKE,
INTEL_ROCKETLAKE,
+   INTEL_DG1,
INTEL_MAX_PLATFORMS
 };


___
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/gt: Clear LOCAL_BIND from shared GGTT on resume

2020-05-26 Thread Patchwork
== Series Details ==

Series: drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume
URL   : https://patchwork.freedesktop.org/series/77666/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_8539_full -> Patchwork_17779_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_softpin@noreloc-s3:
- shard-apl:  [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +1 similar 
issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-apl6/igt@gem_soft...@noreloc-s3.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-apl6/igt@gem_soft...@noreloc-s3.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-snb:  [PASS][3] -> [INCOMPLETE][4] ([i915#82]) +2 similar 
issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-c-cursor-128x42-offscreen:
- shard-skl:  [PASS][5] -> [FAIL][6] ([i915#54])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-128x42-offscreen.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#300])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-suspend.html
- shard-hsw:  [PASS][9] -> [INCOMPLETE][10] ([i915#61]) +3 similar 
issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-hsw6/igt@kms_cursor_...@pipe-c-cursor-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-hsw1/igt@kms_cursor_...@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
- shard-hsw:  [PASS][11] -> [SKIP][12] ([fdo#109271])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-hsw4/igt@kms_cursor_leg...@cursorb-vs-flipb-toggle.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-hsw6/igt@kms_cursor_leg...@cursorb-vs-flipb-toggle.html

  * igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-skl:  [PASS][13] -> [FAIL][14] ([IGT#5])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) 
+2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

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

  * igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl:  [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-kbl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html

  
 Possible fixes 

  * {igt@gem_ctx_isolation@preservation-s3@rcs0}:
- shard-skl:  [INCOMPLETE][21] ([i915#198]) -> [PASS][22]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl2/igt@gem_ctx_isolation@preservation...@rcs0.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl10/igt@gem_ctx_isolation@preservation...@rcs0.html

  * igt@i915_suspend@fence-restore-tiled2untiled:
- shard-skl:  [INCOMPLETE][23] ([i915#69]) -> [PASS][24]
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8539/shard-skl3/igt@i915_susp...@fence-restore-tiled2untiled.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17779/shard-skl10/igt@i915_susp...@fence-restore-tiled2untiled.html

  * igt@kms_big_fb@x-tiled-64bpp-rotate-0:
- shard-glk:  

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

2020-05-26 Thread Tvrtko Ursulin



On 26/05/2020 10:07, Chris Wilson wrote:

When we push a virtual request onto the HW, we update the rq->engine to
point to the physical engine. A request that is then submitted by the
user that waits upon the virtual engine, but along the physical engine
in use, will then see that it is due to be submitted to the same engine
and take a shortcut (and be queued without waiting for the completion
fence). However, the virtual request may be preempted (either by higher
priority users, or by timeslicing) and removed from the physical engine
to be migrated over to one of its siblings. The dependent normal request
however is oblivious to the removal of the virtual request and remains
queued to execute on HW, believing that once it reaches the head of its
queue all of its predecessors will have completed executing!

v2: Beware restriction of signal->execution_mask prior to submission.

Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Testcase: igt/gem_exec_balancer/sliced
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc:  # v5.3+
---
  drivers/gpu/drm/i915/i915_request.c | 25 +
  1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 33bbad623e02..0b07ccc7e9bc 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq,
return 0;
  }
  
+static int

+await_request_submit(struct i915_request *to, struct i915_request *from)
+{
+   /*
+* If we are waiting on a virtual engine, then it may be
+* constrained to execute on a single engine *prior* to submission.
+* When it is submitted, it will be first submitted to the virtual
+* engine and then passed to the physical engine. We cannot allow
+* the waiter to be submitted immediately to the physical engine
+* as it may then bypass the virtual request.
+*/
+   if (to->engine == READ_ONCE(from->engine))
+   return i915_sw_fence_await_sw_fence_gfp(>submit,
+   >submit,
+   I915_FENCE_GFP);
+   else


When can engines be different and the mask test below brought us here?

Regards,

Tvrtko


+   return __i915_request_await_execution(to, from, NULL);
+}
+
  static int
  i915_request_await_request(struct i915_request *to, struct i915_request *from)
  {
@@ -1258,10 +1277,8 @@ i915_request_await_request(struct i915_request *to, 
struct i915_request *from)
return ret;
}
  
-	if (to->engine == READ_ONCE(from->engine))

-   ret = i915_sw_fence_await_sw_fence_gfp(>submit,
-  >submit,
-  I915_FENCE_GFP);
+   if (is_power_of_2(to->execution_mask | READ_ONCE(from->execution_mask)))
+   ret = await_request_submit(to, from);
else
ret = emit_semaphore_wait(to, from, I915_FENCE_GFP);
if (ret < 0)


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


[Intel-gfx] [PATCH 2/2] drm/i915/mst: filter out the display mode exceed sink's capability

2020-05-26 Thread Lyude Paul
From: Lee Shawn C 

So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.

For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When a HDMI 2.0
monitor connected. Source would retrieve EDID from external
and get max resolution 4k@60fps. DP 1.2 can support 4K@60fps
because it did not surpass DP physical bandwidth limitation.
Do modeset to 4k@60fps, source output display data but MST
docking can't output HDMI properly due to this resolution
already over HDMI 1.4 spec.

Refer to commit  ("drm/dp_mst: Use full_pbn
instead of available_pbn for bandwidth checks").
Source driver should refer to full_pbn to evaluate sink
output capability. And filter out the resolution surpass
sink output limitation.

v2: Using mgr->base.lock to protect full_pbn.
v3: Add ctx lock.
v4:
* s/intel_dp_mst_mode_clock_exceed_pbn_bandwidth/
  intel_dp_mst_mode_clock_exceeds_pbn_bw/
* Use the new drm_connector_helper_funcs.mode_valid_ctx to properly pipe
  down the drm_modeset_acquire_ctx that the probe helpers are using, so
  we can safely grab >base.lock without deadlocking

Cc: Manasi Navare 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Cooper Chiou 
Co-developed-by: Lyude Paul 
Signed-off-by: Lee Shawn C 
Tested-by: Lee Shawn C 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 ++---
 1 file changed, 35 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index d18b406f2a7d2..cf052095ad785 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -610,15 +610,42 @@ static int intel_dp_mst_get_modes(struct drm_connector 
*connector)
return intel_dp_mst_get_ddc_modes(connector);
 }
 
+static int
+intel_dp_mst_mode_clock_exceeds_pbn_bw(struct drm_connector *connector,
+  struct drm_modeset_acquire_ctx *ctx,
+  int clock, int bpp)
+{
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct intel_dp *intel_dp = intel_connector->mst_port;
+   struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
+   struct drm_dp_mst_port *port = (to_intel_connector(connector))->port;
+   int ret = MODE_OK;
+
+   if (!mgr)
+   return ret;
+
+   ret = drm_modeset_lock(>base.lock, ctx);
+   if (ret == -EDEADLK)
+   return ret;
+
+   if (port->full_pbn &&
+   drm_dp_calc_pbn_mode(clock, bpp, false) > port->full_pbn)
+   ret = MODE_CLOCK_HIGH;
+
+   return ret;
+}
+
 static enum drm_mode_status
-intel_dp_mst_mode_valid(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+intel_dp_mst_mode_valid_ctx(struct drm_connector *connector,
+   struct drm_display_mode *mode,
+   struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_connector *intel_connector = to_intel_connector(connector);
struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
int max_rate, mode_rate, max_lanes, max_link_clock;
+   int ret;
 
if (drm_connector_is_unregistered(connector))
return MODE_ERROR;
@@ -632,7 +659,11 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(mode->clock, 18);
 
-   /* TODO - validate mode against available PBN for link */
+   ret = intel_dp_mst_mode_clock_exceeds_pbn_bw(connector, ctx,
+mode->clock, 24);
+   if (ret != MODE_OK)
+   return ret;
+
if (mode->clock < 1)
return MODE_CLOCK_LOW;
 
@@ -671,7 +702,7 @@ intel_dp_mst_detect(struct drm_connector *connector,
 
 static const struct drm_connector_helper_funcs 
intel_dp_mst_connector_helper_funcs = {
.get_modes = intel_dp_mst_get_modes,
-   .mode_valid = intel_dp_mst_mode_valid,
+   .mode_valid_ctx = intel_dp_mst_mode_valid_ctx,
.atomic_best_encoder = intel_mst_atomic_best_encoder,
.atomic_check = intel_dp_mst_atomic_check,
.detect_ctx = intel_dp_mst_detect,
-- 
2.26.2

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


[Intel-gfx] [PATCH 0/2] drm/probe_helper, i915: Validate MST modes against PBN limits

2020-05-26 Thread Lyude Paul
Something we've been missing for a while with drivers that support MST
is being able to prune modes that can't be set due to bandwidth
limitations. So, let's go ahead and add that. This also adds a new hook
that was needed, mode_valid_ctx, so that we can grab additional locks as
needed when validating modes.

Lee Shawn C (1):
  drm/i915/mst: filter out the display mode exceed sink's capability

Lyude Paul (1):
  drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx

 drivers/gpu/drm/drm_crtc_helper_internal.h  |  6 +-
 drivers/gpu/drm/drm_probe_helper.c  | 65 ++---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 39 +++--
 include/drm/drm_modeset_helper_vtables.h| 41 +
 4 files changed, 123 insertions(+), 28 deletions(-)

-- 
2.26.2

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


[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/selftests: Fix runtime PM imbalance on error

2020-05-26 Thread Patchwork
== Series Details ==

Series: drm/i915/selftests: Fix runtime PM imbalance on error
URL   : https://patchwork.freedesktop.org/series/77667/
State : failure

== Summary ==

Applying: drm/i915/selftests: Fix runtime PM imbalance on error
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/selftests/mock_gem_device.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/selftests/mock_gem_device.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/selftests/mock_gem_device.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 drm/i915/selftests: Fix runtime PM imbalance on error
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] [PATCH 09/37] drm/i915: Add has_master_unit_irq flag

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> From: Stuart Summers 
> 
> Add flag to differentiate platforms with and without the master
> IRQ control bit.

Reviewed-by: José Roberto de Souza 

> 
> Signed-off-by: Stuart Summers 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 2 ++
>  drivers/gpu/drm/i915/intel_device_info.h | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index bed12799495b..162b1ead88d3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1580,6 +1580,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
>   (INTEL_INFO(dev_priv)->has_logical_ring_preemption)
>  
> +#define HAS_MASTER_UNIT_IRQ(dev_priv) 
> (INTEL_INFO(dev_priv)->has_master_unit_irq)
> +
>  #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>  
>  #define INTEL_PPGTT(dev_priv) (INTEL_INFO(dev_priv)->ppgtt_type)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index c912acd06109..ced979c9b366 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -121,6 +121,7 @@ enum intel_ppgtt_type {
>   func(has_logical_ring_contexts); \
>   func(has_logical_ring_elsq); \
>   func(has_logical_ring_preemption); \
> + func(has_master_unit_irq); \
>   func(has_pooled_eu); \
>   func(has_rc6); \
>   func(has_rc6p); \
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Update inter-engine semaphore detection

2020-05-26 Thread Tvrtko Ursulin



On 26/05/2020 15:17, Chris Wilson wrote:

The kernel no longer uses semaphores between engines, unless it can do
so by preempting them with timeslices. Update the semaphore-busy to only
run when we expect semaphore usage, i.e. not on bdw/bsw.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1939
Signed-off-by: Chris Wilson 
---
  tests/perf_pmu.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index e54a0d47e..e80f730cf 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -822,6 +822,7 @@ sema_busy(int gem_fd,
int fd;
  
  	igt_require(gem_scheduler_has_semaphores(gem_fd));

+   igt_require(gem_scheduler_has_preemption(gem_fd));
  
  	fd = open_group(gem_fd,

I915_PMU_ENGINE_SEMA(e->class, e->instance), -1);



Test with perhaps too intimate knowledge of i915..

Reviewed-by: Tvrtko Ursulin 

Regards,

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


Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Update inter-engine semaphore detection

2020-05-26 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-05-26 16:58:05)
> 
> On 26/05/2020 15:17, Chris Wilson wrote:
> > The kernel no longer uses semaphores between engines, unless it can do
> > so by preempting them with timeslices. Update the semaphore-busy to only
> > run when we expect semaphore usage, i.e. not on bdw/bsw.
> > 
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1939
> > Signed-off-by: Chris Wilson 
> > ---
> >   tests/perf_pmu.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> > index e54a0d47e..e80f730cf 100644
> > --- a/tests/perf_pmu.c
> > +++ b/tests/perf_pmu.c
> > @@ -822,6 +822,7 @@ sema_busy(int gem_fd,
> >   int fd;
> >   
> >   igt_require(gem_scheduler_has_semaphores(gem_fd));
> > + igt_require(gem_scheduler_has_preemption(gem_fd));
> >   
> >   fd = open_group(gem_fd,
> >   I915_PMU_ENGINE_SEMA(e->class, e->instance), -1);
> > 
> 
> Test with perhaps too intimate knowledge of i915..

iirc, part of the intent of the test was to understand how the kernel's
choice of inter-engine sync would show up in the pmu. The challenge we
have is in declaring the expected outcomes, that requires intimate
knowledge of what the kernel might decide to do.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 18/37] drm/i915/dg1: add support for the master unit interrupt

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> DG1 has master unit interrupt register which is used to indicate the
> correct source of interrupt.
> 

Reviewed-by: José Roberto de Souza 

> Cc: Radhakrishna Sripada 
> Cc: Daniele Spurio Ceraolo 
> Cc: Matt Roper 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  4 +++
>  drivers/gpu/drm/i915/i915_irq.c | 56 +++--
>  drivers/gpu/drm/i915/i915_reg.h |  4 +++
>  3 files changed, 61 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bca036ac6621..4e13f7d7dc5d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -492,6 +492,10 @@ static int i915_interrupt_info(struct seq_file *m, void 
> *data)
>   seq_printf(m, "PCU interrupt enable:\t%08x\n",
>  I915_READ(GEN8_PCU_IER));
>   } else if (INTEL_GEN(dev_priv) >= 11) {
> + if (HAS_MASTER_UNIT_IRQ(dev_priv))
> + seq_printf(m, "Master Unit Interrupt Control:  %08x\n",
> +I915_READ(DG1_MSTR_UNIT_INTR));
> +
>   seq_printf(m, "Master Interrupt Control:  %08x\n",
>  I915_READ(GEN11_GFX_MSTR_IRQ));
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 95996db46939..2e950387c179 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2583,6 +2583,46 @@ static irqreturn_t gen11_irq_handler(int irq, void 
> *arg)
>  gen11_master_intr_enable);
>  }
>  
> +static u32 dg1_master_intr_disable_and_ack(void __iomem * const regs)
> +{
> + u32 val;
> +
> + /* First disable interrupts */
> + raw_reg_write(regs, DG1_MSTR_UNIT_INTR, 0);
> +
> + /* Get the indication levels and ack the master unit */
> + val = raw_reg_read(regs, DG1_MSTR_UNIT_INTR);
> + if (unlikely(!val))
> + return 0;
> +
> + raw_reg_write(regs, DG1_MSTR_UNIT_INTR, val);
> +
> + /*
> +  * Now with master disabled, get a sample of level indications
> +  * for this interrupt and ack them right away - we keep GEN11_MASTER_IRQ
> +  * out as this bit doesn't exist anymore for DG1
> +  */
> + val = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ) & ~GEN11_MASTER_IRQ;
> + if (unlikely(!val))
> + return 0;
> +
> + raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, val);
> +
> + return val;
> +}
> +
> +static inline void dg1_master_intr_enable(void __iomem * const regs)
> +{
> + raw_reg_write(regs, DG1_MSTR_UNIT_INTR, DG1_MSTR_IRQ);
> +}
> +
> +static irqreturn_t dg1_irq_handler(int irq, void *arg)
> +{
> + return __gen11_irq_handler(arg,
> +dg1_master_intr_disable_and_ack,
> +dg1_master_intr_enable);
> +}
> +
>  /* Called from drm generic code, passed 'crtc' which
>   * we use as a pipe index
>   */
> @@ -2917,7 +2957,10 @@ static void gen11_irq_reset(struct drm_i915_private 
> *dev_priv)
>  {
>   struct intel_uncore *uncore = _priv->uncore;
>  
> - gen11_master_intr_disable(dev_priv->uncore.regs);
> + if (HAS_MASTER_UNIT_IRQ(dev_priv))
> + dg1_master_intr_disable_and_ack(dev_priv->uncore.regs);
> + else
> + gen11_master_intr_disable(dev_priv->uncore.regs);
>  
>   gen11_gt_irq_reset(_priv->gt);
>   gen11_display_irq_reset(dev_priv);
> @@ -3511,8 +3554,13 @@ static void gen11_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>  
>   I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE);
>  
> - gen11_master_intr_enable(uncore->regs);
> - POSTING_READ(GEN11_GFX_MSTR_IRQ);
> + if (HAS_MASTER_UNIT_IRQ(dev_priv)) {
> + dg1_master_intr_enable(uncore->regs);
> + POSTING_READ(DG1_MSTR_UNIT_INTR);
> + } else {
> + gen11_master_intr_enable(uncore->regs);
> + POSTING_READ(GEN11_GFX_MSTR_IRQ);
> + }
>  }
>  
>  static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
> @@ -4037,6 +4085,8 @@ static irq_handler_t intel_irq_handler(struct 
> drm_i915_private *dev_priv)
>   else
>   return i8xx_irq_handler;
>   } else {
> + if (HAS_MASTER_UNIT_IRQ(dev_priv))
> + return dg1_irq_handler;
>   if (INTEL_GEN(dev_priv) >= 11)
>   return gen11_irq_handler;
>   else if (INTEL_GEN(dev_priv) >= 8)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 95e903c01b2b..c1fde43867dc 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7651,6 +7651,10 @@ enum {
>  #define  GEN11_GT_DW1_IRQ(1 << 1)
>  #define  GEN11_GT_DW0_IRQ(1 << 0)
>  
> +#define DG1_MSTR_UNIT_INTR  

Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions

2020-05-26 Thread Souza, Jose
On Tue, 2020-05-26 at 10:51 -0700, Lucas De Marchi wrote:
> On Tue, May 26, 2020 at 10:34:47AM -0700, Jose Souza wrote:
> > On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> > > From: Abdiel Janulgue 
> > > 
> > > Bspec: 33617, 33617
> > > 
> > > Cc: José Roberto de Souza 
> > > Cc: Daniele Ceraolo Spurio 
> > > Cc: Stuart Summers 
> > > Cc: Vanshidhar Konda 
> > > Cc: Lucas De Marchi 
> > > Cc: Aravind Iddamsetty 
> > > Cc: Matt Roper 
> > > Signed-off-by: Abdiel Janulgue 
> > > Signed-off-by: Lucas De Marchi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |  7 +++
> > >  drivers/gpu/drm/i915/i915_pci.c  | 12 
> > >  drivers/gpu/drm/i915/intel_device_info.c |  1 +
> > >  drivers/gpu/drm/i915/intel_device_info.h |  1 +
> > >  4 files changed, 21 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index a9846205a5e2..382703a6c17d 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > >  #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
> > >  #define IS_TIGERLAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
> > >  #define IS_ROCKETLAKE(dev_priv)  IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
> > > +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
> > >  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> > >   (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
> > >  #define IS_BDW_ULT(dev_priv) \
> > > @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> > >  #define IS_RKL_REVID(p, since, until) \
> > >   (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
> > > 
> > > +#define DG1_REVID_A0 0x0
> > > +#define DG1_REVID_B0 0x1
> > > +
> > > +#define IS_DG1_REVID(p, since, until) \
> > > + (IS_DG1(p) && IS_REVID(p, since, until))
> > > +
> > >  #define IS_LP(dev_priv)  (INTEL_INFO(dev_priv)->is_lp)
> > >  #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
> > >  #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && 
> > > !IS_LP(dev_priv))
> > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > b/drivers/gpu/drm/i915/i915_pci.c
> > > index be52d1b76b2e..e5a851a2dfe7 100644
> > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = {
> > > 
> > >  #define GEN12_DGFX_FEATURES \
> > >   GEN12_FEATURES, \
> > > + .memory_regions = REGION_SMEM | REGION_LMEM, \
> > 
> > REGION_LMEM should be left here for all GEN12 platforms?
> 
> no, this define is GEN12_DGFX_FEATURES. For dgfx, yes... we should leave
> lmem region there.

Ops.
Also ignore my has_master_unit_irq comment.
Reviewed-by: José Roberto de Souza 

> 
> Lucas De Marchi
> 
> > I guess it will be detected in runtime that TGL and RKL don't have it but 
> > would be better to not have it in all GEN12 but will let memory experts to
> > shine in, other than LGTM.
> > 
> > 
> > >   .is_dgfx = 1, \
> > > + .has_master_unit_irq = 1, \
> > >   .has_snoop_pcie = 1
> > > 
> > > +static const struct intel_device_info intel_dg1_info = {
> > > + GEN12_DGFX_FEATURES,
> > > + PLATFORM(INTEL_DG1),
> > > + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
> > > + .require_force_probe = 1,
> > > + .engine_mask =
> > > + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
> > > + BIT(VCS0) | BIT(VCS2),
> > > +};
> > > +
> > >  #undef GEN
> > >  #undef PLATFORM
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> > > b/drivers/gpu/drm/i915/intel_device_info.c
> > > index c245c10c9bee..207244b9a852 100644
> > > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > > @@ -62,6 +62,7 @@ static const char * const platform_names[] = {
> > >   PLATFORM_NAME(ELKHARTLAKE),
> > >   PLATFORM_NAME(TIGERLAKE),
> > >   PLATFORM_NAME(ROCKETLAKE),
> > > + PLATFORM_NAME(DG1),
> > >  };
> > >  #undef PLATFORM_NAME
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> > > b/drivers/gpu/drm/i915/intel_device_info.h
> > > index 4bcaa0d6a9e6..64260faac006 100644
> > > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > > @@ -81,6 +81,7 @@ enum intel_platform {
> > >   /* gen12 */
> > >   INTEL_TIGERLAKE,
> > >   INTEL_ROCKETLAKE,
> > > + INTEL_DG1,
> > >   INTEL_MAX_PLATFORMS
> > >  };
> > > 
___
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/gt: Do not schedule normal requests immediately along virtual

2020-05-26 Thread Chris Wilson
Quoting Tvrtko Ursulin (2020-05-26 17:00:06)
> 
> On 26/05/2020 10:07, Chris Wilson wrote:
> > When we push a virtual request onto the HW, we update the rq->engine to
> > point to the physical engine. A request that is then submitted by the
> > user that waits upon the virtual engine, but along the physical engine
> > in use, will then see that it is due to be submitted to the same engine
> > and take a shortcut (and be queued without waiting for the completion
> > fence). However, the virtual request may be preempted (either by higher
> > priority users, or by timeslicing) and removed from the physical engine
> > to be migrated over to one of its siblings. The dependent normal request
> > however is oblivious to the removal of the virtual request and remains
> > queued to execute on HW, believing that once it reaches the head of its
> > queue all of its predecessors will have completed executing!
> > 
> > v2: Beware restriction of signal->execution_mask prior to submission.
> > 
> > Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
> > Testcase: igt/gem_exec_balancer/sliced
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc:  # v5.3+
> > ---
> >   drivers/gpu/drm/i915/i915_request.c | 25 +
> >   1 file changed, 21 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_request.c 
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 33bbad623e02..0b07ccc7e9bc 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1237,6 +1237,25 @@ i915_request_await_execution(struct i915_request *rq,
> >   return 0;
> >   }
> >   
> > +static int
> > +await_request_submit(struct i915_request *to, struct i915_request *from)
> > +{
> > + /*
> > +  * If we are waiting on a virtual engine, then it may be
> > +  * constrained to execute on a single engine *prior* to submission.
> > +  * When it is submitted, it will be first submitted to the virtual
> > +  * engine and then passed to the physical engine. We cannot allow
> > +  * the waiter to be submitted immediately to the physical engine
> > +  * as it may then bypass the virtual request.
> > +  */
> > + if (to->engine == READ_ONCE(from->engine))
> > + return i915_sw_fence_await_sw_fence_gfp(>submit,
> > + >submit,
> > + I915_FENCE_GFP);
> > + else
> 
> When can engines be different and the mask test below brought us here?

We change the mask during evaluation of the bond, which is from the
signaler's signaler's execute_cb before the signaler is submitted. So
there will be a period where the from->execution_mask is constrained to
a single engine, but it is still waiting to be queued. Once it is
executed on HW, it will remain on that engine.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 12/37] drm/i915/dg1: Add DG1 PCI IDs

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> From: Abdiel Janulgue 
> 
> Bspec: 44463

Reviewed-by: José Roberto de Souza 

> 
> Cc: Matthew Auld 
> Cc: James Ausmus 
> Cc: Joonas Lahtinen 
> Cc: Matt Roper 
> Signed-off-by: Abdiel Janulgue 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_pci.c | 3 ++-
>  include/drm/i915_pciids.h   | 4 
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index e5a851a2dfe7..f1a3a59093c9 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -879,7 +879,7 @@ static const struct intel_device_info rkl_info = {
>   .has_master_unit_irq = 1, \
>   .has_snoop_pcie = 1
>  
> -static const struct intel_device_info intel_dg1_info = {
> +static const struct intel_device_info dg1_info = {
>   GEN12_DGFX_FEATURES,
>   PLATFORM(INTEL_DG1),
>   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
> @@ -964,6 +964,7 @@ static const struct pci_device_id pciidlist[] = {
>   INTEL_EHL_IDS(_info),
>   INTEL_TGL_12_IDS(_info),
>   INTEL_RKL_IDS(_info),
> + INTEL_DG1_IDS(_info),
>   {0, 0, 0}
>  };
>  MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index bc989de2aac2..f44fe822880d 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -614,4 +614,8 @@
>   INTEL_VGA_DEVICE(0x4C90, info), \
>   INTEL_VGA_DEVICE(0x4C9A, info)
>  
> +/* DG1 */
> +#define INTEL_DG1_IDS(info) \
> + INTEL_VGA_DEVICE(0x4905, info)
> +
>  #endif /* _I915_PCIIDS_H */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> From: Abdiel Janulgue 
> 
> Bspec: 33617, 33617
> 
> Cc: José Roberto de Souza 
> Cc: Daniele Ceraolo Spurio 
> Cc: Stuart Summers 
> Cc: Vanshidhar Konda 
> Cc: Lucas De Marchi 
> Cc: Aravind Iddamsetty 
> Cc: Matt Roper 
> Signed-off-by: Abdiel Janulgue 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  7 +++
>  drivers/gpu/drm/i915/i915_pci.c  | 12 
>  drivers/gpu/drm/i915/intel_device_info.c |  1 +
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  4 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a9846205a5e2..382703a6c17d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
>  #define IS_TIGERLAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
>  #define IS_ROCKETLAKE(dev_priv)  IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
> +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
>  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
>   (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
>  #define IS_BDW_ULT(dev_priv) \
> @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_RKL_REVID(p, since, until) \
>   (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
>  
> +#define DG1_REVID_A0 0x0
> +#define DG1_REVID_B0 0x1
> +
> +#define IS_DG1_REVID(p, since, until) \
> + (IS_DG1(p) && IS_REVID(p, since, until))
> +
>  #define IS_LP(dev_priv)  (INTEL_INFO(dev_priv)->is_lp)
>  #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
>  #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index be52d1b76b2e..e5a851a2dfe7 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = {
>  
>  #define GEN12_DGFX_FEATURES \
>   GEN12_FEATURES, \
> + .memory_regions = REGION_SMEM | REGION_LMEM, \

REGION_LMEM should be left here for all GEN12 platforms?
I guess it will be detected in runtime that TGL and RKL don't have it but would 
be better to not have it in all GEN12 but will let memory experts to
shine in, other than LGTM.


>   .is_dgfx = 1, \
> + .has_master_unit_irq = 1, \
>   .has_snoop_pcie = 1
>  
> +static const struct intel_device_info intel_dg1_info = {
> + GEN12_DGFX_FEATURES,
> + PLATFORM(INTEL_DG1),
> + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
> + .require_force_probe = 1,
> + .engine_mask =
> + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
> + BIT(VCS0) | BIT(VCS2),
> +};
> +
>  #undef GEN
>  #undef PLATFORM
>  
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index c245c10c9bee..207244b9a852 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -62,6 +62,7 @@ static const char * const platform_names[] = {
>   PLATFORM_NAME(ELKHARTLAKE),
>   PLATFORM_NAME(TIGERLAKE),
>   PLATFORM_NAME(ROCKETLAKE),
> + PLATFORM_NAME(DG1),
>  };
>  #undef PLATFORM_NAME
>  
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 4bcaa0d6a9e6..64260faac006 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -81,6 +81,7 @@ enum intel_platform {
>   /* gen12 */
>   INTEL_TIGERLAKE,
>   INTEL_ROCKETLAKE,
> + INTEL_DG1,
>   INTEL_MAX_PLATFORMS
>  };
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 37/37] drm/i915/dg1: Remove SHPD_FILTER_CNT register programming

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:38 -0700, Lucas De Marchi wrote:
> From: Anusha Srivatsa 
> 
> Bspec asks us to remove the special programming of the
> SHPD_FILTER_CNT register which we have been doing since CNP+.
> 
> Bspec: 49305
> 

Reviewed-by: José Roberto de Souza 

> Cc: Matt Roper 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ca35edef492d..d4061d5b4d67 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3274,7 +3274,8 @@ static void icp_hpd_irq_setup(struct drm_i915_private 
> *dev_priv,
>   hotplug_irqs = sde_ddi_mask | sde_tc_mask;
>   enabled_irqs = intel_hpd_enabled_irqs(dev_priv, 
> dev_priv->hotplug.pch_hpd);
>  
> - I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
> + if (INTEL_PCH_TYPE(dev_priv) <= PCH_TGP)
> + I915_WRITE(SHPD_FILTER_CNT, SHPD_FILTER_CNT_500_ADJ);
>  
>   ibx_display_interrupt_update(dev_priv, hotplug_irqs, enabled_irqs);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/37] drm/i915/dg1: add initial DG-1 definitions

2020-05-26 Thread Souza, Jose
On Wed, 2020-05-20 at 17:37 -0700, Lucas De Marchi wrote:
> From: Abdiel Janulgue 
> 
> Bspec: 33617, 33617
> 
> Cc: José Roberto de Souza 
> Cc: Daniele Ceraolo Spurio 
> Cc: Stuart Summers 
> Cc: Vanshidhar Konda 
> Cc: Lucas De Marchi 
> Cc: Aravind Iddamsetty 
> Cc: Matt Roper 
> Signed-off-by: Abdiel Janulgue 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  7 +++
>  drivers/gpu/drm/i915/i915_pci.c  | 12 
>  drivers/gpu/drm/i915/intel_device_info.c |  1 +
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  4 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a9846205a5e2..382703a6c17d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1421,6 +1421,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_ELKHARTLAKE(dev_priv) IS_PLATFORM(dev_priv, INTEL_ELKHARTLAKE)
>  #define IS_TIGERLAKE(dev_priv)   IS_PLATFORM(dev_priv, INTEL_TIGERLAKE)
>  #define IS_ROCKETLAKE(dev_priv)  IS_PLATFORM(dev_priv, INTEL_ROCKETLAKE)
> +#define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
>  #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
>   (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
>  #define IS_BDW_ULT(dev_priv) \
> @@ -1541,6 +1542,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define IS_RKL_REVID(p, since, until) \
>   (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
>  
> +#define DG1_REVID_A0 0x0
> +#define DG1_REVID_B0 0x1
> +
> +#define IS_DG1_REVID(p, since, until) \
> + (IS_DG1(p) && IS_REVID(p, since, until))
> +
>  #define IS_LP(dev_priv)  (INTEL_INFO(dev_priv)->is_lp)
>  #define IS_GEN9_LP(dev_priv) (IS_GEN(dev_priv, 9) && IS_LP(dev_priv))
>  #define IS_GEN9_BC(dev_priv) (IS_GEN(dev_priv, 9) && !IS_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index be52d1b76b2e..e5a851a2dfe7 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -874,9 +874,21 @@ static const struct intel_device_info rkl_info = {
>  
>  #define GEN12_DGFX_FEATURES \
>   GEN12_FEATURES, \
> + .memory_regions = REGION_SMEM | REGION_LMEM, \
>   .is_dgfx = 1, \
> + .has_master_unit_irq = 1, \

Also has_master_unit_irq is wrong, it should be added only to intel_dg1_info, 
TGL don't have DG1_MSTR_UNIT_INTR according to the "drm/i915/dg1: add
support for the master unit interrupt" and BSpec: 50862

>   .has_snoop_pcie = 1
>  
> +static const struct intel_device_info intel_dg1_info = {
> + GEN12_DGFX_FEATURES,
> + PLATFORM(INTEL_DG1),
> + .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D),
> + .require_force_probe = 1,
> + .engine_mask =
> + BIT(RCS0) | BIT(BCS0) | BIT(VECS0) |
> + BIT(VCS0) | BIT(VCS2),
> +};
> +
>  #undef GEN
>  #undef PLATFORM
>  
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index c245c10c9bee..207244b9a852 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -62,6 +62,7 @@ static const char * const platform_names[] = {
>   PLATFORM_NAME(ELKHARTLAKE),
>   PLATFORM_NAME(TIGERLAKE),
>   PLATFORM_NAME(ROCKETLAKE),
> + PLATFORM_NAME(DG1),
>  };
>  #undef PLATFORM_NAME
>  
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 4bcaa0d6a9e6..64260faac006 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -81,6 +81,7 @@ enum intel_platform {
>   /* gen12 */
>   INTEL_TIGERLAKE,
>   INTEL_ROCKETLAKE,
> + INTEL_DG1,
>   INTEL_MAX_PLATFORMS
>  };
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 35/37] drm/i915/dg1: Load DMC

2020-05-26 Thread Lucas De Marchi

On Tue, May 26, 2020 at 10:42:30AM -0700, Jose Souza wrote:

On Wed, 2020-05-20 at 17:38 -0700, Lucas De Marchi wrote:

From: Matt Atwood 

Add support to load DMC v2.0.2 on DG1

While we're at it, tweak the TGL and RKL firmware size definition to
follow the convention used in previous platforms. Remove obsolete
commenting.

Bpec: 49230

Cc: Matt Roper 
Signed-off-by: Matt Atwood 
Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_csr.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_csr.c 
b/drivers/gpu/drm/i915/display/intel_csr.c
index 319932b03e88..1f05876620fe 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -38,15 +38,19 @@
  * low-power state and comes back to normal.
  */

-#define GEN12_CSR_MAX_FW_SIZE  ICL_CSR_MAX_FW_SIZE


Why GEN12_CSR_MAX_FW_SIZE was replaced by platform size if the size is still 
the same for all?


Previous platforms used it per platform rather than gen, so I guess
this is what Matt Atwood intended to do and wrote in the last paragraph
in the commit message.

I think we could go either way... no strong opinion on one vs the other.

Lucas De Marchi




+#define DG1_CSR_PATH   "i915/dg1_dmc_ver2_02.bin"
+#define DG1_CSR_VERSION_REQUIRED   CSR_VERSION(2, 2)
+#define DG1_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE
+MODULE_FIRMWARE(DG1_CSR_PATH);

 #define RKL_CSR_PATH   "i915/rkl_dmc_ver2_01.bin"
 #define RKL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 1)
+#define RKL_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE
 MODULE_FIRMWARE(RKL_CSR_PATH);

 #define TGL_CSR_PATH   "i915/tgl_dmc_ver2_06.bin"
 #define TGL_CSR_VERSION_REQUIRED   CSR_VERSION(2, 6)
-#define TGL_CSR_MAX_FW_SIZE0x6000
+#define TGL_CSR_MAX_FW_SIZEICL_CSR_MAX_FW_SIZE
 MODULE_FIRMWARE(TGL_CSR_PATH);

 #define ICL_CSR_PATH   "i915/icl_dmc_ver1_09.bin"
@@ -686,15 +690,18 @@ void intel_csr_ucode_init(struct drm_i915_private 
*dev_priv)
 */
intel_csr_runtime_pm_get(dev_priv);

-   if (IS_ROCKETLAKE(dev_priv)) {
+   if (IS_DG1(dev_priv)) {
+   csr->fw_path = DG1_CSR_PATH;
+   csr->required_version = DG1_CSR_VERSION_REQUIRED;
+   csr->max_fw_size = DG1_CSR_MAX_FW_SIZE;
+   } else if (IS_ROCKETLAKE(dev_priv)) {
csr->fw_path = RKL_CSR_PATH;
csr->required_version = RKL_CSR_VERSION_REQUIRED;
-   csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
+   csr->max_fw_size = RKL_CSR_MAX_FW_SIZE;
} else if (INTEL_GEN(dev_priv) >= 12) {
csr->fw_path = TGL_CSR_PATH;
csr->required_version = TGL_CSR_VERSION_REQUIRED;
-   /* Allow to load fw via parameter using the last known size */
-   csr->max_fw_size = GEN12_CSR_MAX_FW_SIZE;
+   csr->max_fw_size = TGL_CSR_MAX_FW_SIZE;
} else if (IS_GEN(dev_priv, 11)) {
csr->fw_path = ICL_CSR_PATH;
csr->required_version = ICL_CSR_VERSION_REQUIRED;

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


[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915/rkl: Disable PSR2

2020-05-26 Thread Patchwork
== Series Details ==

Series: series starting with [1/6] drm/i915/rkl: Disable PSR2
URL   : https://patchwork.freedesktop.org/series/77676/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8540_full -> Patchwork_17781_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_17781_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_17781_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_17781_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_workarounds@suspend-resume-fd:
- shard-apl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-apl4/igt@gem_workarou...@suspend-resume-fd.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-apl1/igt@gem_workarou...@suspend-resume-fd.html

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

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process@render:
- shard-skl:  [PASS][4] -> [FAIL][5] ([i915#1528])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@render.html

  * igt@gem_workarounds@suspend-resume-fd:
- shard-kbl:  [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +3 similar 
issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-kbl2/igt@gem_workarou...@suspend-resume-fd.html

  * igt@i915_suspend@sysfs-reader:
- shard-apl:  [PASS][8] -> [DMESG-WARN][9] ([i915#180]) +3 similar 
issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-apl1/igt@i915_susp...@sysfs-reader.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-apl1/igt@i915_susp...@sysfs-reader.html

  * igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#1119] / [i915#118] / 
[i915#95])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-glk5/igt@kms_big...@linear-64bpp-rotate-180.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#54] / [i915#93] / 
[i915#95])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html

  * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#72]) +1 similar issue
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-glk8/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html

  * igt@kms_cursor_legacy@cursorb-vs-flipa-toggle:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#1926] / 
[i915#1927])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-glk7/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-glk9/igt@kms_cursor_leg...@cursorb-vs-flipa-toggle.html

  * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl:  [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265]) 
+1 similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html

  * igt@kms_prop_blob@blob-prop-lifetime:
- shard-hsw:  [PASS][20] -> [DMESG-WARN][21] ([i915#1927])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8540/shard-hsw7/igt@kms_prop_b...@blob-prop-lifetime.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17781/shard-hsw1/igt@kms_prop_b...@blob-prop-lifetime.html

  * igt@kms_psr@no_drrs:
- 

Re: [Intel-gfx] [PATCH 05/12] drm/i915: Improve execute_cb struct packing

2020-05-26 Thread Mika Kuoppala
Chris Wilson  writes:

> Reduce the irq_work llist for attaching the callbacks to the signal for
> both smaller structs (two fewer pointers!) and simpler [debug] code:
>
> Function old new   delta
> irq_execute_cb35  34  -1
> __igt_breadcrumbs_smoketest 16841682  -2
> i915_request_retire 20031996  -7
> __i915_request_create   10471040  -7
> __notify_execute_cb  135 126  -9
> __i915_request_ctor  188 178 -10
> __await_execution.part.constprop 451 440 -11
> igt_wait_request 924 714-210
>
> One minor artifact is that the order of cb exection is reversed. No
> current use cases are affected by that change.
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_request.c | 18 +-
>  drivers/gpu/drm/i915/i915_request.h |  2 +-
>  2 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c 
> b/drivers/gpu/drm/i915/i915_request.c
> index c282719ad3ac..22df5b229aed 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -42,7 +42,6 @@
>  #include "intel_pm.h"
>  
>  struct execute_cb {
> - struct list_head link;
>   struct irq_work work;
>   struct i915_sw_fence *fence;
>   void (*hook)(struct i915_request *rq, struct dma_fence *signal);
> @@ -189,14 +188,14 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
>  
>  static void __notify_execute_cb(struct i915_request *rq)
>  {
> - struct execute_cb *cb;
> + struct execute_cb *cb, *cn;
>  
>   lockdep_assert_held(>lock);
>  
> - if (list_empty(>execute_cb))
> + if (llist_empty(>execute_cb))
>   return;
>  
> - list_for_each_entry(cb, >execute_cb, link)
> + llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
>   irq_work_queue(>work);
>  
>   /*
> @@ -209,7 +208,7 @@ static void __notify_execute_cb(struct i915_request *rq)
>* preempt-to-idle cycle on the target engine, all the while the
>* master execute_cb may refire.
>*/
> - INIT_LIST_HEAD(>execute_cb);
> + rq->execute_cb.first = NULL;
>  }
>  
>  static inline void
> @@ -327,7 +326,7 @@ bool i915_request_retire(struct i915_request *rq)
>   set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
>   __notify_execute_cb(rq);
>   }
> - GEM_BUG_ON(!list_empty(>execute_cb));
> + GEM_BUG_ON(!llist_empty(>execute_cb));
>   spin_unlock_irq(>lock);
>  
>   remove_from_client(rq);
> @@ -395,7 +394,8 @@ __await_execution(struct i915_request *rq,
>   i915_sw_fence_complete(cb->fence);
>   kmem_cache_free(global.slab_execute_cbs, cb);
>   } else {
> - list_add_tail(>link, >execute_cb);
> + cb->work.llnode.next = signal->execute_cb.first;
> + signal->execute_cb.first = >work.llnode;

With this part giving more glues as of why can we do this,
Reviewed-by: Mika Kuoppala 


>   }
>   spin_unlock_irq(>lock);
>  
> @@ -704,7 +704,7 @@ static void __i915_request_ctor(void *arg)
>   rq->file_priv = NULL;
>   rq->capture_list = NULL;
>  
> - INIT_LIST_HEAD(>execute_cb);
> + init_llist_head(>execute_cb);
>  }
>  
>  struct i915_request *
> @@ -794,7 +794,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
>   rq->batch = NULL;
>   GEM_BUG_ON(rq->file_priv);
>   GEM_BUG_ON(rq->capture_list);
> - GEM_BUG_ON(!list_empty(>execute_cb));
> + GEM_BUG_ON(!llist_empty(>execute_cb));
>  
>   /*
>* Reserve space in the ring buffer for all the commands required to
> diff --git a/drivers/gpu/drm/i915/i915_request.h 
> b/drivers/gpu/drm/i915/i915_request.h
> index 8ec7ee4dbadc..5d4709a3dace 100644
> --- a/drivers/gpu/drm/i915/i915_request.h
> +++ b/drivers/gpu/drm/i915/i915_request.h
> @@ -214,7 +214,7 @@ struct i915_request {
>   ktime_t emitted;
>   } duration;
>   };
> - struct list_head execute_cb;
> + struct llist_head execute_cb;
>   struct i915_sw_fence semaphore;
>  
>   /*
> -- 
> 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] [CI] drm/i915: Improve execute_cb struct packing

2020-05-26 Thread Chris Wilson
Reduce the irq_work llist for attaching the callbacks to the signal for
both smaller structs (two fewer pointers!) and simpler [debug] code:

Function old new   delta
irq_execute_cb35  34  -1
__igt_breadcrumbs_smoketest 16841682  -2
i915_request_retire 20031996  -7
__i915_request_create   10471040  -7
__notify_execute_cb  135 126  -9
__i915_request_ctor  188 178 -10
__await_execution.part.constprop 451 440 -11
igt_wait_request 924 714-210

One minor artifact is that the order of cb exection is reversed. No
current use cases are affected by that change.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_request.c | 23 ++-
 drivers/gpu/drm/i915/i915_request.h |  2 +-
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index c282719ad3ac..877eaaccba81 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -42,7 +42,6 @@
 #include "intel_pm.h"
 
 struct execute_cb {
-   struct list_head link;
struct irq_work work;
struct i915_sw_fence *fence;
void (*hook)(struct i915_request *rq, struct dma_fence *signal);
@@ -189,14 +188,14 @@ static void irq_execute_cb_hook(struct irq_work *wrk)
 
 static void __notify_execute_cb(struct i915_request *rq)
 {
-   struct execute_cb *cb;
+   struct execute_cb *cb, *cn;
 
lockdep_assert_held(>lock);
 
-   if (list_empty(>execute_cb))
+   if (llist_empty(>execute_cb))
return;
 
-   list_for_each_entry(cb, >execute_cb, link)
+   llist_for_each_entry_safe(cb, cn, rq->execute_cb.first, work.llnode)
irq_work_queue(>work);
 
/*
@@ -209,7 +208,7 @@ static void __notify_execute_cb(struct i915_request *rq)
 * preempt-to-idle cycle on the target engine, all the while the
 * master execute_cb may refire.
 */
-   INIT_LIST_HEAD(>execute_cb);
+   init_llist_head(>execute_cb);
 }
 
 static inline void
@@ -327,7 +326,7 @@ bool i915_request_retire(struct i915_request *rq)
set_bit(I915_FENCE_FLAG_ACTIVE, >fence.flags);
__notify_execute_cb(rq);
}
-   GEM_BUG_ON(!list_empty(>execute_cb));
+   GEM_BUG_ON(!llist_empty(>execute_cb));
spin_unlock_irq(>lock);
 
remove_from_client(rq);
@@ -357,6 +356,12 @@ void i915_request_retire_upto(struct i915_request *rq)
} while (i915_request_retire(tmp) && tmp != rq);
 }
 
+static void __llist_add(struct llist_node *node, struct llist_head *head)
+{
+   node->next = head->first;
+   head->first = node;
+}
+
 static int
 __await_execution(struct i915_request *rq,
  struct i915_request *signal,
@@ -395,7 +400,7 @@ __await_execution(struct i915_request *rq,
i915_sw_fence_complete(cb->fence);
kmem_cache_free(global.slab_execute_cbs, cb);
} else {
-   list_add_tail(>link, >execute_cb);
+   __llist_add(>work.llnode, >execute_cb);
}
spin_unlock_irq(>lock);
 
@@ -704,7 +709,7 @@ static void __i915_request_ctor(void *arg)
rq->file_priv = NULL;
rq->capture_list = NULL;
 
-   INIT_LIST_HEAD(>execute_cb);
+   init_llist_head(>execute_cb);
 }
 
 struct i915_request *
@@ -794,7 +799,7 @@ __i915_request_create(struct intel_context *ce, gfp_t gfp)
rq->batch = NULL;
GEM_BUG_ON(rq->file_priv);
GEM_BUG_ON(rq->capture_list);
-   GEM_BUG_ON(!list_empty(>execute_cb));
+   GEM_BUG_ON(!llist_empty(>execute_cb));
 
/*
 * Reserve space in the ring buffer for all the commands required to
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 8ec7ee4dbadc..5d4709a3dace 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -214,7 +214,7 @@ struct i915_request {
ktime_t emitted;
} duration;
};
-   struct list_head execute_cb;
+   struct llist_head execute_cb;
struct i915_sw_fence semaphore;
 
/*
-- 
2.20.1

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


Re: [Intel-gfx] [PATCH 04/12] drm/i915/execlists: Shortcircuit queue_prio() for no internal levels

2020-05-26 Thread Mika Kuoppala
Chris Wilson  writes:

> If there are no internal levels and the user priority-shift is zero, we
> can help the compiler eliminate some dead code:
>
> Function old new   delta
> start_timeslice  169 154 -15
> __execlists_submission_tasklet  46964659 -37
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index de5be57ed6d2..3214a4ecc31a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -446,6 +446,9 @@ static int queue_prio(const struct intel_engine_execlists 
> *execlists)
>* we have to flip the index value to become priority.
>*/
>   p = to_priolist(rb);
> + if (!I915_USER_PRIORITY_SHIFT)
> + return p->priority;
> +
>   return ((p->priority + 1) << I915_USER_PRIORITY_SHIFT) - ffs(p->used);
>  }
>  
> -- 
> 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