[Intel-gfx] ✗ Fi.CI.IGT: failure for igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch (rev2)

[Patchwork]

== Series Details ==

Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch 
(rev2)
URL   : https://patchwork.freedesktop.org/series/34780/
State : failure

== Summary ==

Test pm_rpm:
Subgroup drm-resources-equal:
pass   -> SKIP   (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb-blt-xtiled:
pass   -> SKIP   (shard-hsw)
Test drv_selftest:
Subgroup mock_sanitycheck:
dmesg-warn -> PASS   (shard-hsw) fdo#102707 +2
Test gem_userptr_blits:
Subgroup map-fixed-invalidate-gup:
pass   -> INCOMPLETE (shard-hsw)
Test gem_busy:
Subgroup close-race:
pass   -> INCOMPLETE (shard-snb) fdo#103829
pass   -> FAIL   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-hsw) fdo#104009

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

shard-hswtotal:2630 pass:1516 dwarn:1   dfail:0   fail:11  skip:1101 
time:9314s
shard-snbtotal:2591 pass:1274 dwarn:1   dfail:0   fail:12  skip:1303 
time:7991s
Blacklisted hosts:
shard-apltotal:2663 pass:1691 dwarn:1   dfail:0   fail:22  skip:949 
time:13810s
shard-kbltotal:2630 pass:1771 dwarn:12  dfail:3   fail:25  skip:818 
time:10712s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_582/shards.html
___
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/2] drm/i915: Implement WaDisableVFclkgate.

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.
URL   : https://patchwork.freedesktop.org/series/34785/
State : failure

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (shard-hsw) fdo#102707 +1
Test kms_flip:
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
pass   -> INCOMPLETE (shard-hsw)

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

shard-hswtotal:2639 pass:1527 dwarn:1   dfail:0   fail:11  skip:1098 
time:9005s
shard-snbtotal:2663 pass:1308 dwarn:2   dfail:0   fail:12  skip:1341 
time:8147s
Blacklisted hosts:
shard-apltotal:2663 pass:1692 dwarn:1   dfail:0   fail:21  skip:949 
time:13674s
shard-kbltotal:2588 pass:1750 dwarn:1   dfail:0   fail:22  skip:815 
time:10592s

== Logs ==

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

[Intel-gfx] Updated drm-intel-testing

[Rodrigo Vivi]

Hi all,

The following changes tagged drm-intel-testing-2017-12-01:

drm-intel-next-2017-12-01:

- Init clock gate fix (Ville)
- Execlists event handling corrections (Chris, Michel)
- Improvements on GPU Cache invalidation and context switch (Chris)
- More perf OA changes (Lionel)
- More selftests improvements and fixes (Chris, Matthew)
- Clean-up on modules parameters (Chris)
- Clean-up around old ringbuffer submission and hw semaphore on old platforms 
(Chris)
- More Cannonlake stabilization effort (David, James)
- Display planes clean-up and improvements (Ville)
- New PMU interface for perf queries... (Tvrtko)
- ... and other subsequent PMU changes and fixes (Tvrtko, Chris)
- Remove success dmesg noise from rotation (Chris)
- New DMC for Kabylake (Anusha)
- Fixes around atomic commits (Daniel)
- GuC updates and fixes (Sagar, Michal, Chris)
- Couple gmbus/i2c fixes (Ville)
- Use exponential backoff for all our wait_for() (Chris)
- Fixes for i915/fbdev (Chris)
- Backlight fixes (Arnd)
- Updates on shrinker (Chris)
- Make Hotplug enable more robuts (Chris)
- Disable huge pages (TPH) on lack of a needed workaround (Joonas)
- New GuC images for SKL, KBL, BXT (Sagar)
- Add HW Workaround for Geminilake performance (Valtteri)
- Fixes for PPS timings (Imre)
- More IPS fixes (Maarten)
- Many fixes for Display Port on gen2-gen4 (Ville)
- Retry GPU reset making the recover from hang more robust (Chris)

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/perf_pmu: Tighten semaphore-wait measurement

[Patchwork]

== Series Details ==

Series: igt/perf_pmu: Tighten semaphore-wait measurement
URL   : https://patchwork.freedesktop.org/series/34786/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3435
5cac595012ce drm-tip: 2017y-12m-01d-23h-12m-37s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (fi-hsw-4770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:449s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:520s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:506s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:494s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-hsw-4770  total:109  pass:100  dwarn:0   dfail:0   fail:0   skip:8  
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:264s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:393s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:525s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:541s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:446s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:545s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:423s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:602s
fi-glk-dsi   total:68   pass:59   dwarn:0   dfail:0   fail:0   skip:8  

== Logs ==

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

[Intel-gfx] [PATCH igt] igt/perf_pmu: Tighten semaphore-wait measurement

[Chris Wilson]

Record the before/after semaphore-wait values around the sleep to try to
reduce the inaccuracy from scheduler delays. Previously, the samples
were taken before submitting the batch and then after synchronising its
completion. The measurement will then be the total that the semaphore
was being sampled, but with the extra syscalls intervening may have
drifted from the sleep duration. To further reduce the disparity, wait
for the batch to start executing before taking our samples.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104013
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 tests/perf_pmu.c | 54 --
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index cb59bf5d..e872f4e5 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -355,13 +355,13 @@ no_sema(int gem_fd, const struct intel_execution_engine2 
*e, bool busy)
 static void
 sema_wait(int gem_fd, const struct intel_execution_engine2 *e)
 {
-   struct drm_i915_gem_relocation_entry reloc = { };
-   struct drm_i915_gem_execbuffer2 eb = { };
-   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc[2] = {};
+   struct drm_i915_gem_exec_object2 obj[2] = {};
+   struct drm_i915_gem_execbuffer2 eb = {};
uint32_t bb_handle, obj_handle;
unsigned long slept;
uint32_t *obj_ptr;
-   uint32_t batch[6];
+   uint32_t batch[16];
uint64_t val[2];
int fd;
 
@@ -378,28 +378,35 @@ sema_wait(int gem_fd, const struct 
intel_execution_engine2 *e)
 
obj_ptr = gem_mmap__wc(gem_fd, obj_handle, 0, 4096, PROT_WRITE);
 
-   batch[0] = MI_SEMAPHORE_WAIT |
+   batch[0] = MI_STORE_DWORD_IMM;
+   batch[1] = sizeof(*obj_ptr);
+   batch[2] = 0;
+   batch[3] = 1;
+   batch[4] = MI_SEMAPHORE_WAIT |
   MI_SEMAPHORE_POLL |
   MI_SEMAPHORE_SAD_GTE_SDD;
-   batch[1] = 1;
-   batch[2] = 0x0;
-   batch[3] = 0x0;
-   batch[4] = MI_NOOP;
-   batch[5] = MI_BATCH_BUFFER_END;
+   batch[5] = 1;
+   batch[6] = 0x0;
+   batch[7] = 0x0;
+   batch[8] = MI_BATCH_BUFFER_END;
 
gem_write(gem_fd, bb_handle, 0, batch, sizeof(batch));
 
-   reloc.target_handle = obj_handle;
-   reloc.offset = 2 * sizeof(uint32_t);
-   reloc.read_domains = I915_GEM_DOMAIN_RENDER;
+   reloc[0].target_handle = obj_handle;
+   reloc[0].offset = 1 * sizeof(uint32_t);
+   reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
+   reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
+   reloc[0].delta = sizeof(*obj_ptr);
 
-   memset(obj, 0, sizeof(obj));
+   reloc[1].target_handle = obj_handle;
+   reloc[1].offset = 6 * sizeof(uint32_t);
+   reloc[1].read_domains = I915_GEM_DOMAIN_RENDER;
 
obj[0].handle = obj_handle;
 
obj[1].handle = bb_handle;
-   obj[1].relocation_count = 1;
-   obj[1].relocs_ptr = to_user_pointer();
+   obj[1].relocation_count = 2;
+   obj[1].relocs_ptr = to_user_pointer(reloc);
 
eb.buffer_count = 2;
eb.buffers_ptr = to_user_pointer(obj);
@@ -413,18 +420,21 @@ sema_wait(int gem_fd, const struct 
intel_execution_engine2 *e)
 
fd = open_pmu(I915_PMU_ENGINE_SEMA(e->class, e->instance));
 
-   val[0] = pmu_read_single(fd);
-
gem_execbuf(gem_fd, );
+   do { /* wait for the batch to start executing */
+   usleep(5e3);
+   } while (!obj_ptr[1]);
+   usleep(5e3); /* wait for the register sampling */
 
+   val[0] = pmu_read_single(fd);
slept = measured_usleep(batch_duration_ns / 1000);
+   val[1] = pmu_read_single(fd);
+   igt_debug("slept %.3fms, sampled %.3fms\n",
+ slept*1e-6, (val[1] - val[0])*1e-6);
 
-   *obj_ptr = 1;
-
+   obj_ptr[0] = 1;
gem_sync(gem_fd, bb_handle);
 
-   val[1] = pmu_read_single(fd);
-
munmap(obj_ptr, 4096);
gem_close(gem_fd, obj_handle);
gem_close(gem_fd, bb_handle);
-- 
2.15.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch (rev2)

[Patchwork]

== Series Details ==

Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch 
(rev2)
URL   : https://patchwork.freedesktop.org/series/34780/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3435
5cac595012ce drm-tip: 2017y-12m-01d-23h-12m-37s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:448s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:527s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:483s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:373s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:268s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:394s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:490s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:531s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:598s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:547s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:524s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:547s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:418s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:616s
fi-glk-dsi   total:287  pass:257  dwarn:0   dfail:0   fail:0   skip:29 

== Logs ==

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

Re: [Intel-gfx] [PATCH v5] drm/i915: Restore GT performance in headless mode with DMC loaded

[Rogozhkin, Dmitry V]

On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote:
> > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > +   (HAS_CSR(dev_priv) && IS_GEN9(dev_priv) && !
> IS_SKYLAKE(dev_priv))
> 
> Nitpick: could be just !IS_SKYLAKE(), but works in the above way too.
> For all other platforms the GT_IRQ domain won't be mapped making
> display_power_get/put on those just a domain ref inc/dec, otherwise a
> nop.

Why not +&& !IS_BROXTON(dev_priv) by the way?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Implement WaDisableVFclkgate.
URL   : https://patchwork.freedesktop.org/series/34785/
State : success

== Summary ==

Series 34785v1 series starting with [1/2] drm/i915: Implement 
WaDisableVFclkgate.
https://patchwork.freedesktop.org/api/1.0/series/34785/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:517s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:486s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:370s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:262s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:390s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:485s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:534s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:545s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:548s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:414s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:608s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:491s

5cac595012ce8ad67dfa837982ead06fe9535bad drm-tip: 2017y-12m-01d-23h-12m-37s UTC 
integration manifest
645347857d80 drm/i915: Implement WaDisableEarlyEOT.
a5569960b691 drm/i915: Implement WaDisableVFclkgate.

== Logs ==

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

Re: [Intel-gfx] [PATCH v5] drm/i915: Restore GT performance in headless mode with DMC loaded

[Rogozhkin, Dmitry V]

On Thu, 2017-11-30 at 13:19 +0200, Imre Deak wrote:
> On Thu, Nov 30, 2017 at 09:45:25AM +, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-11-30 09:18:20)
> > > From: Tvrtko Ursulin 
> > > 
> > > It seems that the DMC likes to transition between the DC states a lot when
> > > there are no connected displays (no active power domains) during command
> > > submission.
> > > 
> > > This activity on DC states has a negative impact on the performance of the
> > > chip with huge latencies observed in the interrupt handlers and elsewhere.
> > > Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
> > > eight.
> > > 
> > > Work around it by introducing a new power domain named,
> > > POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
> > > held for the duration of command submission activity.
> > > 
> > > v2:
> > >  * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
> > >  * Protect macro body with braces. (Jani Nikula)
> > > 
> > > v3:
> > >  * Add dedicated power domain for clarity. (Chris, Imre)
> > >  * Commit message and comment text updates.
> > >  * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
> > >firmware release.
> > > 
> > > v4:
> > >  * Power domain should be inner to device runtime pm. (Chris)
> > >  * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
> > >  * Handle async DMC loading by moving the GT_IRQ power domain logic into
> > >intel_runtime_pm. (Daniel, Chris)
> > >  * Include small core GEN9 as well. (Imre)
> > > 
> > > v5
> > >  * Special handling for async DMC load is not needed since on failure the
> > >power domain reference is kept permanently taken. (Imre)
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
> > > Testcase: igt/gem_exec_nop/headless
> > > Cc: Imre Deak 
> > > Acked-by: Chris Wilson  (v2)
> > > Cc: Chris Wilson 
> > > Cc: Dmitry Rogozhkin 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h |  4 
> > >  drivers/gpu/drm/i915/i915_gem.c |  3 +++
> > >  drivers/gpu/drm/i915/i915_gem_request.c | 14 ++
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 14 ++
> > >  4 files changed, 35 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index bddd65839f60..59cf11dd5d3b 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -398,6 +398,7 @@ enum intel_display_power_domain {
> > > POWER_DOMAIN_AUX_D,
> > > POWER_DOMAIN_GMBUS,
> > > POWER_DOMAIN_MODESET,
> > > +   POWER_DOMAIN_GT_IRQ,
> > > POWER_DOMAIN_INIT,
> > >  
> > > POWER_DOMAIN_NUM,
> > > @@ -3285,6 +3286,9 @@ intel_info(const struct drm_i915_private *dev_priv)
> > >  #define GT_FREQUENCY_MULTIPLIER 50
> > >  #define GEN9_FREQ_SCALER 3
> > >  
> > > +#define NEEDS_CSR_GT_PERF_WA(dev_priv) \
> > > +   (HAS_CSR(dev_priv) && IS_GEN9(dev_priv) && !IS_SKYLAKE(dev_priv))
> 
> Nitpick: could be just !IS_SKYLAKE(), but works in the above way too.
> For all other platforms the GT_IRQ domain won't be mapped making
> display_power_get/put on those just a domain ref inc/dec, otherwise a
> nop.

Folks, is my understanding correct that once SKL DMC will be merged we
just remove !IS_SKYLAKE from the above check to get the performance fix
for SKL and nothing more changes in the patch? I am asking because there
is a need to have SKL patch on the plate already to verify the fix
sooner rather than later. From this perspective, can we have one more
patch in the series dedicated to fix SKL right now? After all, SKL DMC
is available in drm-firmware already, those who need can try it.

> 
> > > +
> > >  #include "i915_trace.h"
> > >  
> > >  static inline bool intel_vtd_active(void)
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 354b0546a191..c6067cba1dca 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -3381,6 +3381,9 @@ i915_gem_idle_work_handler(struct work_struct *work)
> > >  
> > > if (INTEL_GEN(dev_priv) >= 6)
> > > gen6_rps_idle(dev_priv);
> > > +
> > > +   intel_display_power_put(dev_priv, POWER_DOMAIN_GT_IRQ);
> > > +
> > > intel_runtime_pm_put(dev_priv);
> > >  out_unlock:
> > > mutex_unlock(_priv->drm.struct_mutex);
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > > b/drivers/gpu/drm/i915/i915_gem_request.c
> > > index a90bdd26571f..c28a4ceb016d 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > > @@ -252,6 +252,20 @@ static void mark_busy(struct drm_i915_private *i915)
> > > 

[Intel-gfx] [PATCH 2/2] drm/i915: Implement WaDisableEarlyEOT.

[Rafael Antognolli]

There seems to be another clock gating issue which the workaround is
described as:

   "WA: Set 0xE4F0[1] = 1 to disable Early EOT of thread."

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/i915/i915_reg.h| 1 +
 drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1358ce1513f6..0f07f5900a6f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8145,6 +8145,7 @@ enum {
 #define   PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE(1<<8)
 #define   STALL_DOP_GATING_DISABLE (1<<5)
 #define   THROTTLE_12_5(7<<2)
+#define   DISABLE_EARLY_EOT(1<<1)
 
 #define GEN7_ROW_CHICKEN2  _MMIO(0xe4f4)
 #define GEN7_ROW_CHICKEN2_GT2  _MMIO(0xf4f4)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 86d4c85c8725..bf581a0bb789 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1272,6 +1272,9 @@ static int cnl_init_workarounds(struct intel_engine_cs 
*engine)
if (ret)
return ret;
 
+   /* WaDisableEarlyEOT:cnl */
+   WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, DISABLE_EARLY_EOT);
+
return 0;
 }
 
-- 
2.13.6

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

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

[Rafael Antognolli]

This workaround supposedly fixes some hangs in the VF unit.

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 5 +
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 09bf043c1c2e..1358ce1513f6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3875,6 +3875,9 @@ enum {
 #define  SARBUNIT_CLKGATE_DIS  (1 << 5)
 #define  RCCUNIT_CLKGATE_DIS   (1 << 7)
 
+#define UNSLICE_UNIT_LEVEL_CLOCK   _MMIO(0x9434)
+#define  VFUNIT_CLKGATE_DIS(1 << 20)
+
 /*
  * Display engine regs
  */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 67f326230a7e..87b9bdee48e5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8446,6 +8446,11 @@ static void cnl_init_clock_gating(struct 
drm_i915_private *dev_priv)
if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0))
val |= SARBUNIT_CLKGATE_DIS;
I915_WRITE(SLICE_UNIT_LEVEL_CLKGATE, val);
+
+   /* WaDisableVFclkgate:cnl */
+   val = I915_READ(UNSLICE_UNIT_LEVEL_CLOCK);
+   val |= VFUNIT_CLKGATE_DIS;
+   I915_WRITE(UNSLICE_UNIT_LEVEL_CLOCK, val);
 }
 
 static void cfl_init_clock_gating(struct drm_i915_private *dev_priv)
-- 
2.13.6

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

[Intel-gfx] [PATCH igt v2] igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch

[Chris Wilson]

In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise infinity.

v2: Be respectful to UP!

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103829
Signed-off-by: Chris Wilson 
---
 tests/gem_busy.c | 259 +--
 1 file changed, 156 insertions(+), 103 deletions(-)

diff --git a/tests/gem_busy.c b/tests/gem_busy.c
index 2b88270b..3290b0d8 100644
--- a/tests/gem_busy.c
+++ b/tests/gem_busy.c
@@ -21,10 +21,16 @@
  * IN THE SOFTWARE.
  */
 
+#include 
+#include 
+#include 
+
 #include "igt.h"
 #include "igt_rand.h"
+#include "igt_vgem.h"
 
 #define LOCAL_EXEC_NO_RELOC (1<<11)
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
 
 /* Exercise the busy-ioctl, ensuring the ABI is never broken */
 IGT_TEST_DESCRIPTION("Basic check of busy-ioctl ABI.");
@@ -59,80 +65,6 @@ static void __gem_busy(int fd,
*read = busy.busy >> 16;
 }
 
-static uint32_t busy_blt(int fd)
-{
-   const int gen = intel_gen(intel_get_drm_devid(fd));
-   const int has_64bit_reloc = gen >= 8;
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 object[2];
-   struct drm_i915_gem_relocation_entry reloc[200], *r;
-   uint32_t *map;
-   int factor = 100;
-   int i = 0;
-
-   memset(object, 0, sizeof(object));
-   object[0].handle = gem_create(fd, 1024*1024);
-   object[1].handle = gem_create(fd, 4096);
-
-   r = memset(reloc, 0, sizeof(reloc));
-   map = gem_mmap__cpu(fd, object[1].handle, 0, 4096, PROT_WRITE);
-   gem_set_domain(fd, object[1].handle,
-  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
-
-#define COPY_BLT_CMD   (2<<29|0x53<<22|0x6)
-#define BLT_WRITE_ALPHA(1<<21)
-#define BLT_WRITE_RGB  (1<<20)
-   while (factor--) {
-   /* XY_SRC_COPY */
-   map[i++] = COPY_BLT_CMD | BLT_WRITE_ALPHA | BLT_WRITE_RGB;
-   if (has_64bit_reloc)
-   map[i-1] += 2;
-   map[i++] = 0xcc << 16 | 1 << 25 | 1 << 24 | (4*1024);
-   map[i++] = 0;
-   map[i++] = 256 << 16 | 1024;
-
-   r->offset = i * sizeof(uint32_t);
-   r->target_handle = object[0].handle;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = I915_GEM_DOMAIN_RENDER;
-   r++;
-   map[i++] = 0;
-   if (has_64bit_reloc)
-   map[i++] = 0;
-
-   map[i++] = 0;
-   map[i++] = 4096;
-
-   r->offset = i * sizeof(uint32_t);
-   r->target_handle = object[0].handle;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = 0;
-   r++;
-   map[i++] = 0;
-   if (has_64bit_reloc)
-   map[i++] = 0;
-   }
-   map[i++] = MI_BATCH_BUFFER_END;
-   igt_assert(i <= 4096/sizeof(uint32_t));
-   igt_assert(r - reloc <= ARRAY_SIZE(reloc));
-   munmap(map, 4096);
-
-   object[1].relocs_ptr = to_user_pointer(reloc);
-   object[1].relocation_count = r - reloc;
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = to_user_pointer(object);
-   execbuf.buffer_count = 2;
-   if (gen >= 6)
-   execbuf.flags = I915_EXEC_BLT;
-   gem_execbuf(fd, );
-   igt_assert(gem_bo_busy(fd, object[0].handle));
-
-   igt_debug("Created busy handle %d\n", object[0].handle);
-   gem_close(fd, object[1].handle);
-   return object[0].handle;
-}
-
 static bool exec_noop(int fd,
  uint32_t *handles,
  unsigned ring,
@@ -167,6 +99,7 @@ static bool still_busy(int fd, uint32_t handle)
 static void semaphore(int fd, unsigned ring, uint32_t flags)
 {
uint32_t bbe = MI_BATCH_BUFFER_END;
+   igt_spin_t *spin;
uint32_t handle[3];
uint32_t read, write;
uint32_t active;
@@ -179,7 +112,8 @@ static void semaphore(int fd, unsigned ring, uint32_t flags)
gem_write(fd, handle[BATCH], 0, , sizeof(bbe));
 
/* Create a long running batch which we can use to hog the GPU */
-   handle[BUSY] = busy_blt(fd);
+   handle[BUSY] = gem_create(fd, 4096);
+   spin = igt_spin_batch_new(fd, 0, ring, handle[BUSY]);
 
/* Queue a batch after the busy, it should block and remain "busy" */
igt_assert(exec_noop(fd, handle, ring | flags, false));
@@ -208,6 +142,7 @@ static void semaphore(int fd, unsigned ring, uint32_t flags)
 
/* Check that our long batch was long enough */
igt_assert(still_busy(fd, handle[BUSY]));
+   igt_spin_batch_free(fd, spin);
 
/* And make 

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch

[Patchwork]

== Series Details ==

Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch
URL   : https://patchwork.freedesktop.org/series/34780/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3434
d872b1714457 drm-tip: 2017y-12m-01d-21h-08m-31s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test gem_busy:
Subgroup basic-hang-default:
pass   -> INCOMPLETE (fi-bdw-gvtdvm)
pass   -> INCOMPLETE (fi-skl-gvtdvm)
Test gem_exec_reloc:
Subgroup basic-cpu-read-active:
pass   -> FAIL   (fi-gdg-551) fdo#102582

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:11   pass:10   dwarn:0   dfail:0   fail:0   skip:0  
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:533s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:496s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:478s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:177  dwarn:1   dfail:0   fail:2   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:545s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:259s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:396s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:489s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:528s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:601s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:460s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:552s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:11   pass:10   dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:562s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:421s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:615s
fi-cnl-y total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:551s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for IGT/tests/firmware: Test firmware loading by reading debugfs

[Patchwork]

== Series Details ==

Series: IGT/tests/firmware: Test firmware loading by reading debugfs
URL   : https://patchwork.freedesktop.org/series/34778/
State : warning

== Summary ==

Test gem_busy:
Subgroup close-race:
fail   -> PASS   (shard-snb) fdo#103829
Test kms_cursor_crc:
Subgroup cursor-256x256-onscreen:
pass   -> SKIP   (shard-snb)
Test kms_vblank:
Subgroup wait-idle:
pass   -> SKIP   (shard-snb)
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104009 +1
Test kms_flip:
Subgroup flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#103829 https://bugs.freedesktop.org/show_bug.cgi?id=103829
fdo#104009 https://bugs.freedesktop.org/show_bug.cgi?id=104009
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2664 pass:1536 dwarn:1   dfail:0   fail:11  skip:1116 
time:9527s
shard-snbtotal:2621 pass:1280 dwarn:1   dfail:0   fail:13  skip:1326 
time:7763s
Blacklisted hosts:
shard-apltotal:2664 pass:1686 dwarn:2   dfail:0   fail:26  skip:949 
time:13724s
shard-kbltotal:2664 pass:1790 dwarn:14  dfail:1   fail:25  skip:834 
time:10889s

== Logs ==

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

[Intel-gfx] [PATCH igt] igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch

[Chris Wilson]

In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise infinity.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103829
Signed-off-by: Chris Wilson 
---
 tests/gem_busy.c | 248 +--
 1 file changed, 151 insertions(+), 97 deletions(-)

diff --git a/tests/gem_busy.c b/tests/gem_busy.c
index 2b88270b..4d8cd9c6 100644
--- a/tests/gem_busy.c
+++ b/tests/gem_busy.c
@@ -21,10 +21,16 @@
  * IN THE SOFTWARE.
  */
 
+#include 
+#include 
+#include 
+
 #include "igt.h"
 #include "igt_rand.h"
+#include "igt_vgem.h"
 
 #define LOCAL_EXEC_NO_RELOC (1<<11)
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
 
 /* Exercise the busy-ioctl, ensuring the ABI is never broken */
 IGT_TEST_DESCRIPTION("Basic check of busy-ioctl ABI.");
@@ -59,80 +65,6 @@ static void __gem_busy(int fd,
*read = busy.busy >> 16;
 }
 
-static uint32_t busy_blt(int fd)
-{
-   const int gen = intel_gen(intel_get_drm_devid(fd));
-   const int has_64bit_reloc = gen >= 8;
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 object[2];
-   struct drm_i915_gem_relocation_entry reloc[200], *r;
-   uint32_t *map;
-   int factor = 100;
-   int i = 0;
-
-   memset(object, 0, sizeof(object));
-   object[0].handle = gem_create(fd, 1024*1024);
-   object[1].handle = gem_create(fd, 4096);
-
-   r = memset(reloc, 0, sizeof(reloc));
-   map = gem_mmap__cpu(fd, object[1].handle, 0, 4096, PROT_WRITE);
-   gem_set_domain(fd, object[1].handle,
-  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
-
-#define COPY_BLT_CMD   (2<<29|0x53<<22|0x6)
-#define BLT_WRITE_ALPHA(1<<21)
-#define BLT_WRITE_RGB  (1<<20)
-   while (factor--) {
-   /* XY_SRC_COPY */
-   map[i++] = COPY_BLT_CMD | BLT_WRITE_ALPHA | BLT_WRITE_RGB;
-   if (has_64bit_reloc)
-   map[i-1] += 2;
-   map[i++] = 0xcc << 16 | 1 << 25 | 1 << 24 | (4*1024);
-   map[i++] = 0;
-   map[i++] = 256 << 16 | 1024;
-
-   r->offset = i * sizeof(uint32_t);
-   r->target_handle = object[0].handle;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = I915_GEM_DOMAIN_RENDER;
-   r++;
-   map[i++] = 0;
-   if (has_64bit_reloc)
-   map[i++] = 0;
-
-   map[i++] = 0;
-   map[i++] = 4096;
-
-   r->offset = i * sizeof(uint32_t);
-   r->target_handle = object[0].handle;
-   r->read_domains = I915_GEM_DOMAIN_RENDER;
-   r->write_domain = 0;
-   r++;
-   map[i++] = 0;
-   if (has_64bit_reloc)
-   map[i++] = 0;
-   }
-   map[i++] = MI_BATCH_BUFFER_END;
-   igt_assert(i <= 4096/sizeof(uint32_t));
-   igt_assert(r - reloc <= ARRAY_SIZE(reloc));
-   munmap(map, 4096);
-
-   object[1].relocs_ptr = to_user_pointer(reloc);
-   object[1].relocation_count = r - reloc;
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = to_user_pointer(object);
-   execbuf.buffer_count = 2;
-   if (gen >= 6)
-   execbuf.flags = I915_EXEC_BLT;
-   gem_execbuf(fd, );
-   igt_assert(gem_bo_busy(fd, object[0].handle));
-
-   igt_debug("Created busy handle %d\n", object[0].handle);
-   gem_close(fd, object[1].handle);
-   return object[0].handle;
-}
-
 static bool exec_noop(int fd,
  uint32_t *handles,
  unsigned ring,
@@ -167,6 +99,7 @@ static bool still_busy(int fd, uint32_t handle)
 static void semaphore(int fd, unsigned ring, uint32_t flags)
 {
uint32_t bbe = MI_BATCH_BUFFER_END;
+   igt_spin_t *spin;
uint32_t handle[3];
uint32_t read, write;
uint32_t active;
@@ -179,7 +112,8 @@ static void semaphore(int fd, unsigned ring, uint32_t flags)
gem_write(fd, handle[BATCH], 0, , sizeof(bbe));
 
/* Create a long running batch which we can use to hog the GPU */
-   handle[BUSY] = busy_blt(fd);
+   handle[BUSY] = gem_create(fd, 4096);
+   spin = igt_spin_batch_new(fd, 0, ring, handle[BUSY]);
 
/* Queue a batch after the busy, it should block and remain "busy" */
igt_assert(exec_noop(fd, handle, ring | flags, false));
@@ -208,6 +142,7 @@ static void semaphore(int fd, unsigned ring, uint32_t flags)
 
/* Check that our long batch was long enough */
igt_assert(still_busy(fd, handle[BUSY]));
+   igt_spin_batch_free(fd, spin);
 
/* And make sure it becomes idle again */
 

Re: [Intel-gfx] [IGT] IGT/tests/firmware: Test firmware loading by reading debugfs

[Rodrigo Vivi]

On Fri, Dec 01, 2017 at 09:40:35PM +, Anusha Srivatsa wrote:
> Read debugfs and sysfs entries to check for GuC
> loading conditions.
> 
> The patch is still WIP. Once all check conditions are
> covered, it can be extended to huc debugfs file too.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  tests/Makefile.sources |  1 +
>  tests/test_firmware.c  | 96 
> ++
>  2 files changed, 97 insertions(+)
>  create mode 100644 tests/test_firmware.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 0f4e39a..841fc54 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -234,6 +234,7 @@ TESTS_progs = \
>   template \
>   tools_test \
>   vgem_basic \
> + test_firmware \

note that igt tests names are meaningful... _

so probably better to use fw_basic

>   vgem_slow \

and also they are more or less sorted out here...
but you added on the middle of a vgem group...

>   $(NULL)
>  
> diff --git a/tests/test_firmware.c b/tests/test_firmware.c
> new file mode 100644
> index 000..a5d621a
> --- /dev/null
> +++ b/tests/test_firmware.c
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright © 2013 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors: Anusha Srivatsa
> + *
> + */
> +
> +#include "igt.h"
> +#include "stdio.h"
> +#include "stdlib.h"
> +#include "igt_sysfs.h"
> +#include "igt_debugfs.h"
> +#include "i915_drm.h"
> +#include "fcntl.h"
> +
> +IGT_TEST_DESCRIPTION("Read contents of debugfs to check for firmware 
> status.");
> +
> +static void guc_load(int drm_fd, int debugfs, int gen)
> +{
> + char firmware_buf[250];
> + float fw_version_wanted;
> + float fw_version_found;
> + int ret;
> + int enable_guc_loading;
> + FILE *fp;
> +
> + igt_skip_on_f(gen < 6,
> +   "GuC not available on platforms prior to Skylake\n");
> +
> + igt_sysfs_scanf(debugfs, "i915_enable_guc_loading", "%d", 
> _guc_loading);
> + igt_skip_on_f(!(enable_guc_loading < 1), "GuC loading not enabled\n");
> +
> + ret = igt_debugfs_open(drm_fd, "i915_guc_load_status", O_RDONLY);
> + fp = fdopen(ret, "r");
> + igt_fail_on_f(ret < 0, "Not able to open the debugfs file\n");
> +
> + igt_debugfs_read(drm_fd, "i915_guc_load_status", firmware_buf);
> +
> + fseek(fp, 99, SEEK_CUR);

This is risky/fragile imo... any small change on debugfs this will break...

Have you consider the new kernel seftest thing to make the tests inside
kernel itself without need for parse this debugfs interface?

> + fscanf(fp, "%f", _version_wanted);
> + fseek(fp, 119, SEEK_SET);
> + fscanf(fp, "%f", _version_found);
> +
> + igt_fail_on_f((fw_version_wanted != fw_version_found),
> +   "Firmware version found not the version wanted\n");
> + igt_fail_on_f(strstr(firmware_buf, "fetch: NONE"),
> +   "Firmware not fetched\n");
> + igt_fail_on_f(strstr(firmware_buf, "fetch: SUCCESS") &&
> +   strstr(firmware_buf, "load: NONE "),
> +   "Firmware not loaded\n");
> +}
> +
> +int drm_fd;
> +int debugfs;
> +int gen;
> +
> +igt_main
> +{
> + igt_skip_on_simulation();
> + igt_fixture {
> + drm_fd = drm_open_driver(DRIVER_INTEL);
> + igt_require(drm_fd >= 0);
> +
> + debugfs = igt_debugfs_dir(drm_fd);
> + gen = intel_gen(intel_get_drm_devid(drm_fd));
> + }
> +
> + igt_subtest("guc-load-test")
> + guc_load(drm_fd, debugfs, gen);
> +
> + igt_success();
> +
> + igt_fixture {
> + close(debugfs);
> + close(drm_fd);
> + }
> +}
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list

[Intel-gfx] ✓ Fi.CI.BAT: success for IGT/tests/firmware: Test firmware loading by reading debugfs

[Patchwork]

== Series Details ==

Series: IGT/tests/firmware: Test firmware loading by reading debugfs
URL   : https://patchwork.freedesktop.org/series/34778/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3434
d872b1714457 drm-tip: 2017y-12m-01d-21h-08m-31s UTC integration manifest

Testlist changes:
+igt@test_firmware@guc-load-test

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:440s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:389s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:532s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:512s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:478s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:270s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:546s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:357s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:397s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:531s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:532s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:544s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:549s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:417s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:606s
fi-cnl-y total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:559s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s

== Logs ==

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

[Intel-gfx] [IGT] IGT/tests/firmware: Test firmware loading by reading debugfs

[Anusha Srivatsa]

Read debugfs and sysfs entries to check for GuC
loading conditions.

The patch is still WIP. Once all check conditions are
covered, it can be extended to huc debugfs file too.

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 tests/Makefile.sources |  1 +
 tests/test_firmware.c  | 96 ++
 2 files changed, 97 insertions(+)
 create mode 100644 tests/test_firmware.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0f4e39a..841fc54 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -234,6 +234,7 @@ TESTS_progs = \
template \
tools_test \
vgem_basic \
+   test_firmware \
vgem_slow \
$(NULL)
 
diff --git a/tests/test_firmware.c b/tests/test_firmware.c
new file mode 100644
index 000..a5d621a
--- /dev/null
+++ b/tests/test_firmware.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright © 2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors: Anusha Srivatsa
+ *
+ */
+
+#include "igt.h"
+#include "stdio.h"
+#include "stdlib.h"
+#include "igt_sysfs.h"
+#include "igt_debugfs.h"
+#include "i915_drm.h"
+#include "fcntl.h"
+
+IGT_TEST_DESCRIPTION("Read contents of debugfs to check for firmware status.");
+
+static void guc_load(int drm_fd, int debugfs, int gen)
+{
+   char firmware_buf[250];
+   float fw_version_wanted;
+   float fw_version_found;
+   int ret;
+   int enable_guc_loading;
+   FILE *fp;
+
+   igt_skip_on_f(gen < 6,
+ "GuC not available on platforms prior to Skylake\n");
+
+   igt_sysfs_scanf(debugfs, "i915_enable_guc_loading", "%d", 
_guc_loading);
+   igt_skip_on_f(!(enable_guc_loading < 1), "GuC loading not enabled\n");
+
+   ret = igt_debugfs_open(drm_fd, "i915_guc_load_status", O_RDONLY);
+   fp = fdopen(ret, "r");
+   igt_fail_on_f(ret < 0, "Not able to open the debugfs file\n");
+
+   igt_debugfs_read(drm_fd, "i915_guc_load_status", firmware_buf);
+
+   fseek(fp, 99, SEEK_CUR);
+   fscanf(fp, "%f", _version_wanted);
+   fseek(fp, 119, SEEK_SET);
+   fscanf(fp, "%f", _version_found);
+
+   igt_fail_on_f((fw_version_wanted != fw_version_found),
+ "Firmware version found not the version wanted\n");
+   igt_fail_on_f(strstr(firmware_buf, "fetch: NONE"),
+ "Firmware not fetched\n");
+   igt_fail_on_f(strstr(firmware_buf, "fetch: SUCCESS") &&
+ strstr(firmware_buf, "load: NONE "),
+ "Firmware not loaded\n");
+}
+
+int drm_fd;
+int debugfs;
+int gen;
+
+igt_main
+{
+   igt_skip_on_simulation();
+   igt_fixture {
+   drm_fd = drm_open_driver(DRIVER_INTEL);
+   igt_require(drm_fd >= 0);
+
+   debugfs = igt_debugfs_dir(drm_fd);
+   gen = intel_gen(intel_get_drm_devid(drm_fd));
+   }
+
+   igt_subtest("guc-load-test")
+   guc_load(drm_fd, debugfs, gen);
+
+   igt_success();
+
+   igt_fixture {
+   close(debugfs);
+   close(drm_fd);
+   }
+}
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 6/7] drm/i915: expose command stream timestamp frequency to userspace

[Lionel Landwerlin]

On 01/12/17 20:02, Paulo Zanoni wrote:

Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:

We use to have this fixed per generation, but starting with CNL
userspace
cannot tell just off the PCI ID. Let's make this information
available. This
is particularly useful for performance monitoring where much of the
normalization work is done using those timestamps (this include
pipeline
statistics in both GL & Vulkan as well as OA reports).

v2: Use variables for 24MHz/19.2MHz values (Ewelina)
 Renamed function & coding style (Sagar)

v3: Fix frequency read on Broadwell (Sagar)
 Fix missing divide by 4 on <= gen4 (Sagar)

Signed-off-by: Lionel Landwerlin 
Tested-by: Rafael Antognolli 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |   2 +
  drivers/gpu/drm/i915/i915_drv.c  |   3 +
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/i915_reg.h  |  21 ++
  drivers/gpu/drm/i915/intel_device_info.c | 107
+++
  include/uapi/drm/i915_drm.h  |   6 ++
  6 files changed, 141 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 533ba096b9a6..57485f29d7c9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3245,6 +3245,8 @@ static int i915_engine_info(struct seq_file *m,
void *unused)
       yesno(dev_priv->gt.awake));
    seq_printf(m, "Global active requests: %d\n",
       dev_priv->gt.active_requests);
+   seq_printf(m, "CS timestamp frequency: %llu Hz\n",
+      dev_priv->info.cs_timestamp_frequency);
  
  	p = drm_seq_file_printer(m);

    for_each_engine(engine, dev_priv, id)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index d97fe9c9439a..dbd04d5f75ee 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -419,6 +419,9 @@ static int i915_getparam(struct drm_device *dev,
void *data,
    if (!value)
    return -ENODEV;
    break;
+   case I915_PARAM_CS_TIMESTAMP_FREQUENCY:
+   value = INTEL_INFO(dev_priv)-

cs_timestamp_frequency;

+   break;
    default:
    DRM_DEBUG("Unknown parameter %d\n", param->param);
    return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 9f26c34e0e52..ebc49ca58eb7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -885,6 +885,8 @@ struct intel_device_info {
    /* Slice/subslice/EU info */
    struct sseu_dev_info sseu;
  
+	u64 cs_timestamp_frequency;

+
    struct color_luts {
    u16 degamma_lut_size;
    u16 gamma_lut_size;
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 7aa7dc0c336b..ec9faa11e305 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1119,9 +1119,24 @@ static inline bool
i915_mmio_reg_valid(i915_reg_t reg)
  
  /* RPM unit config (Gen8+) */

  #define RPM_CONFIG0   _MMIO(0x0D00)
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT 3
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK  (1 <<
GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ  0
+#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ1
+#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT   1
+#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK(0x3 <<
GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
+
  #define RPM_CONFIG1   _MMIO(0x0D04)
  #define  GEN10_GT_NOA_ENABLE  (1 << 9)
  
+/* GPM unit config (Gen9+) */

+#define CTC_MODE   _MMIO(0xA26C)
+#define  CTC_SOURCE_PARAMETER_MASK 1
+#define  CTC_SOURCE_CRYSTAL_CLOCK  0
+#define  CTC_SOURCE_DIVIDE_LOGIC   1
+#define  CTC_SHIFT_PARAMETER_SHIFT 1
+#define  CTC_SHIFT_PARAMETER_MASK  (0x3 <<
CTC_SHIFT_PARAMETER_SHIFT)
+
  /* RCP unit config (Gen8+) */
  #define RCP_CONFIG_MMIO(0x0D08)
  
@@ -8866,6 +8881,12 @@ enum skl_power_gate {

  #define ILK_TIMESTAMP_HI  _MMIO(0x70070)
  #define IVB_TIMESTAMP_CTR _MMIO(0x44070)
  
+#define GEN9_TIMESTAMP_OVERRIDE_MMIO

(0x44074)
+#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_SHIFT  0
+#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_MASK   0x3f
f
+#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT  
12
+#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK   
(0xf << 12)
+
  #define _PIPE_FRMTMSTMP_A 0x70048
  #define PIPE_FRMTMSTMP(pipe)  \
    _MMIO_PIPE2(pipe, _PIPE_FRMTMSTMP_A)
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index db03d179fc85..78bf7374fbdd 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

[Ville Syrjälä]

On Fri, Dec 01, 2017 at 02:17:19PM -0500, Sean Paul wrote:
> On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä
>  wrote:
> > On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
> >> Once the Aksv is available in the PCH, we need to get it on the wire to
> >> the receiver via DDC. The hardware doesn't allow us to read the value
> >> directly, so we need to tell GMBUS to source the Aksv internally and
> >> send it to the right offset on the receiver.
> >>
> >> The way we do this is to initiate an indexed write where the index is
> >> the Aksv register offset. We write dummy values to GMBUS3 as if we were
> >> sending the key, and the hardware slips in the "real" values when it
> >> goes out.
> >>
> >> Changes in v2:
> >> - None
> >>
> >> Signed-off-by: Sean Paul 
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
> >>  drivers/gpu/drm/i915/intel_i2c.c | 54 
> >> ++--
> >>  3 files changed, 48 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 36bb4927484a..10f740c9e571 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -4043,6 +4043,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
> >> *dev_priv);
> >>  extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
> >>  extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
> >>unsigned int pin);
> >> +extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
> >>
> >>  extern struct i2c_adapter *
> >>  intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int 
> >> pin);
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 6dca305ccbf7..8b71a20882ca 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -3040,6 +3040,7 @@ enum i915_power_well_id {
> >>  # define GPIO_DATA_PULLUP_DISABLE(1 << 13)
> >>
> >>  #define GMBUS0   _MMIO(dev_priv->gpio_mmio_base + 
> >> 0x5100) /* clock/port select */
> >> +#define   GMBUS_AKSV_SELECT  (1<<11)
> >>  #define   GMBUS_RATE_100KHZ  (0<<8)
> >>  #define   GMBUS_RATE_50KHZ   (1<<8)
> >>  #define   GMBUS_RATE_400KHZ  (2<<8) /* reserved on Pineview */
> >> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> >> b/drivers/gpu/drm/i915/intel_i2c.c
> >> index eb5827110d8f..c01156bf0f27 100644
> >> --- a/drivers/gpu/drm/i915/intel_i2c.c
> >> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> >> @@ -30,6 +30,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include "intel_drv.h"
> >>  #include 
> >>  #include "i915_drv.h"
> >> @@ -373,7 +374,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, 
> >> struct i2c_msg *msg,
> >>
> >>  static int
> >>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
> >> -unsigned short addr, u8 *buf, unsigned int len)
> >> +unsigned short addr, u8 *buf, unsigned int len,
> >> +u32 gmbus1_index)
> >>  {
> >>   unsigned int chunk_size = len;
> >>   u32 val, loop;
> >> @@ -386,7 +388,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private 
> >> *dev_priv,
> >>
> >>   I915_WRITE_FW(GMBUS3, val);
> >>   I915_WRITE_FW(GMBUS1,
> >> -   GMBUS_CYCLE_WAIT |
> >> +   gmbus1_index | GMBUS_CYCLE_WAIT |
> >> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
> >> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> >> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> >> @@ -409,7 +411,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private 
> >> *dev_priv,
> >>  }
> >>
> >>  static int
> >> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
> >> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
> >> +  u32 gmbus1_index)
> >>  {
> >>   u8 *buf = msg->buf;
> >>   unsigned int tx_size = msg->len;
> >> @@ -419,7 +422,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> >> struct i2c_msg *msg)
> >>   do {
> >>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
> >>
> >> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
> >> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
> >> +  gmbus1_index);
> >>   if (ret)
> >>   return ret;
> >>
> >> @@ -470,7 +474,8 @@ gmbus_xfer_index_read(struct drm_i915_private 
> >> *dev_priv, struct i2c_msg *msgs)
> >>  }
> >>
> >>  static int
> >> -do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
> >> +do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
> >> +   u32 gmbus0_source, u32 gmbus1_index)
> >>  {
> >>   

Re: [Intel-gfx] [PATCH 6/7] drm/i915: expose command stream timestamp frequency to userspace

[Paulo Zanoni]

Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:
> We use to have this fixed per generation, but starting with CNL
> userspace
> cannot tell just off the PCI ID. Let's make this information
> available. This
> is particularly useful for performance monitoring where much of the
> normalization work is done using those timestamps (this include
> pipeline
> statistics in both GL & Vulkan as well as OA reports).
> 
> v2: Use variables for 24MHz/19.2MHz values (Ewelina)
> Renamed function & coding style (Sagar)
> 
> v3: Fix frequency read on Broadwell (Sagar)
> Fix missing divide by 4 on <= gen4 (Sagar)
> 
> Signed-off-by: Lionel Landwerlin 
> Tested-by: Rafael Antognolli 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |   2 +
>  drivers/gpu/drm/i915/i915_drv.c  |   3 +
>  drivers/gpu/drm/i915/i915_drv.h  |   2 +
>  drivers/gpu/drm/i915/i915_reg.h  |  21 ++
>  drivers/gpu/drm/i915/intel_device_info.c | 107
> +++
>  include/uapi/drm/i915_drm.h  |   6 ++
>  6 files changed, 141 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 533ba096b9a6..57485f29d7c9 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3245,6 +3245,8 @@ static int i915_engine_info(struct seq_file *m,
> void *unused)
>      yesno(dev_priv->gt.awake));
>   seq_printf(m, "Global active requests: %d\n",
>      dev_priv->gt.active_requests);
> + seq_printf(m, "CS timestamp frequency: %llu Hz\n",
> +    dev_priv->info.cs_timestamp_frequency);
>  
>   p = drm_seq_file_printer(m);
>   for_each_engine(engine, dev_priv, id)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index d97fe9c9439a..dbd04d5f75ee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -419,6 +419,9 @@ static int i915_getparam(struct drm_device *dev,
> void *data,
>   if (!value)
>   return -ENODEV;
>   break;
> + case I915_PARAM_CS_TIMESTAMP_FREQUENCY:
> + value = INTEL_INFO(dev_priv)-
> >cs_timestamp_frequency;
> + break;
>   default:
>   DRM_DEBUG("Unknown parameter %d\n", param->param);
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 9f26c34e0e52..ebc49ca58eb7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -885,6 +885,8 @@ struct intel_device_info {
>   /* Slice/subslice/EU info */
>   struct sseu_dev_info sseu;
>  
> + u64 cs_timestamp_frequency;
> +
>   struct color_luts {
>   u16 degamma_lut_size;
>   u16 gamma_lut_size;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 7aa7dc0c336b..ec9faa11e305 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1119,9 +1119,24 @@ static inline bool
> i915_mmio_reg_valid(i915_reg_t reg)
>  
>  /* RPM unit config (Gen8+) */
>  #define RPM_CONFIG0  _MMIO(0x0D00)
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT   3
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK(1 <<
> GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ0
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ  1
> +#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT 1
> +#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK  (0x3 <<
> GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
> +
>  #define RPM_CONFIG1  _MMIO(0x0D04)
>  #define  GEN10_GT_NOA_ENABLE  (1 << 9)
>  
> +/* GPM unit config (Gen9+) */
> +#define CTC_MODE _MMIO(0xA26C)
> +#define  CTC_SOURCE_PARAMETER_MASK 1
> +#define  CTC_SOURCE_CRYSTAL_CLOCK0
> +#define  CTC_SOURCE_DIVIDE_LOGIC 1
> +#define  CTC_SHIFT_PARAMETER_SHIFT   1
> +#define  CTC_SHIFT_PARAMETER_MASK(0x3 <<
> CTC_SHIFT_PARAMETER_SHIFT)
> +
>  /* RCP unit config (Gen8+) */
>  #define RCP_CONFIG   _MMIO(0x0D08)
>  
> @@ -8866,6 +8881,12 @@ enum skl_power_gate {
>  #define ILK_TIMESTAMP_HI _MMIO(0x70070)
>  #define IVB_TIMESTAMP_CTR_MMIO(0x44070)
>  
> +#define GEN9_TIMESTAMP_OVERRIDE  _MMIO
> (0x44074)
> +#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_SHIFT0
> +#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_MASK 0x3f
> f
> +#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT
> 12
> +#define  GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK 
> (0xf << 12)
> +
>  #define _PIPE_FRMTMSTMP_A0x70048
>  #define PIPE_FRMTMSTMP(pipe) \
>   _MMIO_PIPE2(pipe, _PIPE_FRMTMSTMP_A)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> 

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

[Sean Paul]

On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä
 wrote:
> On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
>> Once the Aksv is available in the PCH, we need to get it on the wire to
>> the receiver via DDC. The hardware doesn't allow us to read the value
>> directly, so we need to tell GMBUS to source the Aksv internally and
>> send it to the right offset on the receiver.
>>
>> The way we do this is to initiate an indexed write where the index is
>> the Aksv register offset. We write dummy values to GMBUS3 as if we were
>> sending the key, and the hardware slips in the "real" values when it
>> goes out.
>>
>> Changes in v2:
>> - None
>>
>> Signed-off-by: Sean Paul 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>>  drivers/gpu/drm/i915/intel_i2c.c | 54 
>> ++--
>>  3 files changed, 48 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 36bb4927484a..10f740c9e571 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -4043,6 +4043,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
>> *dev_priv);
>>  extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
>>  extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
>>unsigned int pin);
>> +extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
>>
>>  extern struct i2c_adapter *
>>  intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int 
>> pin);
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 6dca305ccbf7..8b71a20882ca 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -3040,6 +3040,7 @@ enum i915_power_well_id {
>>  # define GPIO_DATA_PULLUP_DISABLE(1 << 13)
>>
>>  #define GMBUS0   _MMIO(dev_priv->gpio_mmio_base + 
>> 0x5100) /* clock/port select */
>> +#define   GMBUS_AKSV_SELECT  (1<<11)
>>  #define   GMBUS_RATE_100KHZ  (0<<8)
>>  #define   GMBUS_RATE_50KHZ   (1<<8)
>>  #define   GMBUS_RATE_400KHZ  (2<<8) /* reserved on Pineview */
>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
>> b/drivers/gpu/drm/i915/intel_i2c.c
>> index eb5827110d8f..c01156bf0f27 100644
>> --- a/drivers/gpu/drm/i915/intel_i2c.c
>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
>> @@ -30,6 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include "intel_drv.h"
>>  #include 
>>  #include "i915_drv.h"
>> @@ -373,7 +374,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, 
>> struct i2c_msg *msg,
>>
>>  static int
>>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>> -unsigned short addr, u8 *buf, unsigned int len)
>> +unsigned short addr, u8 *buf, unsigned int len,
>> +u32 gmbus1_index)
>>  {
>>   unsigned int chunk_size = len;
>>   u32 val, loop;
>> @@ -386,7 +388,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>>
>>   I915_WRITE_FW(GMBUS3, val);
>>   I915_WRITE_FW(GMBUS1,
>> -   GMBUS_CYCLE_WAIT |
>> +   gmbus1_index | GMBUS_CYCLE_WAIT |
>> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
>> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
>> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
>> @@ -409,7 +411,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>>  }
>>
>>  static int
>> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
>> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
>> +  u32 gmbus1_index)
>>  {
>>   u8 *buf = msg->buf;
>>   unsigned int tx_size = msg->len;
>> @@ -419,7 +422,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
>> struct i2c_msg *msg)
>>   do {
>>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
>>
>> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
>> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
>> +  gmbus1_index);
>>   if (ret)
>>   return ret;
>>
>> @@ -470,7 +474,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
>> struct i2c_msg *msgs)
>>  }
>>
>>  static int
>> -do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
>> +do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
>> +   u32 gmbus0_source, u32 gmbus1_index)
>>  {
>>   struct intel_gmbus *bus = container_of(adapter,
>>  struct intel_gmbus,
>> @@ -480,7 +485,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct 
>> i2c_msg *msgs, int num)
>>   int ret = 0;
>>
>>  retry:
>> - I915_WRITE_FW(GMBUS0, bus->reg0);
>> + 

Re: [Intel-gfx] [PATCH i-g-t v5 6/6] tests/kms_ccs: Test case for wrong aux buffer stride size

[Ben Widawsky]

On 17-11-15 17:37:01, Gabriel Krisman Bertazi wrote:

Two scenarios tested:
 - unaligned stride
 - Stride too small

Since v4:
- Fix SIGFPE if width <= 1024 (Arkadiusz Hiler/Ville Syrjälä)
- Add test for pitches[1]=0 (Ville Syrjälä)

Signed-off-by: Gabriel Krisman Bertazi 


[snip]

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

Re: [Intel-gfx] [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

[Ville Syrjälä]

On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
> Once the Aksv is available in the PCH, we need to get it on the wire to
> the receiver via DDC. The hardware doesn't allow us to read the value
> directly, so we need to tell GMBUS to source the Aksv internally and
> send it to the right offset on the receiver.
> 
> The way we do this is to initiate an indexed write where the index is
> the Aksv register offset. We write dummy values to GMBUS3 as if we were
> sending the key, and the hardware slips in the "real" values when it
> goes out.
> 
> Changes in v2:
> - None
> 
> Signed-off-by: Sean Paul 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_reg.h  |  1 +
>  drivers/gpu/drm/i915/intel_i2c.c | 54 
> ++--
>  3 files changed, 48 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 36bb4927484a..10f740c9e571 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -4043,6 +4043,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
> *dev_priv);
>  extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
>  extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
>unsigned int pin);
> +extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
>  
>  extern struct i2c_adapter *
>  intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6dca305ccbf7..8b71a20882ca 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3040,6 +3040,7 @@ enum i915_power_well_id {
>  # define GPIO_DATA_PULLUP_DISABLE(1 << 13)
>  
>  #define GMBUS0   _MMIO(dev_priv->gpio_mmio_base + 
> 0x5100) /* clock/port select */
> +#define   GMBUS_AKSV_SELECT  (1<<11)
>  #define   GMBUS_RATE_100KHZ  (0<<8)
>  #define   GMBUS_RATE_50KHZ   (1<<8)
>  #define   GMBUS_RATE_400KHZ  (2<<8) /* reserved on Pineview */
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index eb5827110d8f..c01156bf0f27 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "intel_drv.h"
>  #include 
>  #include "i915_drv.h"
> @@ -373,7 +374,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
> i2c_msg *msg,
>  
>  static int
>  gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
> -unsigned short addr, u8 *buf, unsigned int len)
> +unsigned short addr, u8 *buf, unsigned int len,
> +u32 gmbus1_index)
>  {
>   unsigned int chunk_size = len;
>   u32 val, loop;
> @@ -386,7 +388,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  
>   I915_WRITE_FW(GMBUS3, val);
>   I915_WRITE_FW(GMBUS1,
> -   GMBUS_CYCLE_WAIT |
> +   gmbus1_index | GMBUS_CYCLE_WAIT |
> (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
> (addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -409,7 +411,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
>  }
>  
>  static int
> -gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
> +gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
> +  u32 gmbus1_index)
>  {
>   u8 *buf = msg->buf;
>   unsigned int tx_size = msg->len;
> @@ -419,7 +422,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msg)
>   do {
>   len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
>  
> - ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
> + ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
> +  gmbus1_index);
>   if (ret)
>   return ret;
>  
> @@ -470,7 +474,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
> struct i2c_msg *msgs)
>  }
>  
>  static int
> -do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
> +do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
> +   u32 gmbus0_source, u32 gmbus1_index)
>  {
>   struct intel_gmbus *bus = container_of(adapter,
>  struct intel_gmbus,
> @@ -480,7 +485,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   int ret = 0;
>  
>  retry:
> - I915_WRITE_FW(GMBUS0, bus->reg0);
> + I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
>  
>   for (; i < num; i += inc) {
>   inc = 1;
> @@ -490,7 +495,8 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct 

Re: [Intel-gfx] [PATCH v2 0/8] drm/i915: Implement HDCP

[Sean Paul]

On Fri, Dec 1, 2017 at 1:47 PM, Hans Verkuil  wrote:
> Hi Sean,
>
> On 12/01/2017 06:20 PM, Sean Paul wrote:
>> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
>> list I set out in the first version (Annotated below for convenience).
>>
>> The big changes to take note of in v2 is locking. To account for atomic 
>> async +
>> the property's mutability, I'm using a dedicated mutex and moved property
>> setting on the kernel side to the worker. I think this is actually a lot 
>> easier
>> to read, and it opens the door to future improvements such as not doing the
>> enable/disable via modeset.
>>
>> TODO:
>> - DONE: Add kerneldoc for property
>> - DONE: Fix '//' comments
>> - DONE: Change to MIT license
>> - DONE: Improve documentation on drm_intel_hdcp_shim
>> - DONE: Fix async commit locking (ie: don't use connection_mutex)
>> - DONE: Don't change connector->state in enable, defer to worker
>> - Rebase on Ville's gmbus fixes (thanks Ville)
>>   - Looks like these haven't landed, but I've rebased on drm-intel-next
>> - Add igt coverage for the feature.
>>   - Working on this now
>
> Looking at this patch series it seems that there is no drm support to get the
> BKSV from the i915, right? If you want to use the i915 (or any HDMI/DP output)
> in a repeater scenario then userspace has to be able to obtain that 
> information
> so it can be added to the BKSV of the HDMI receiver.
>

Hi Hans,
Repeater support is implemented in intel_hdcp_auth_downstream()

> For the record, the V4L2 subsystem used by HDMI receivers doesn't support HDCP
> yet, although patches exist.
>
> I can understand that you are not (yet) adding repeater support, but it should
> be documented somewhere in the patch series that this is not there yet and
> that a standard DRM API would be needed to obtain the BKSV from the 
> transmitter.
>
> Second question: has this been tested with a MST hub?
>

No, MST is not supported at the moment (there's a TODO in the code)

Sean

> Regards,
>
> Hans
>
>>
>> Thanks!
>>
>> Sean
>>
>> Sean Paul (8):
>>   drm: Fix link-status kerneldoc line lengths
>>   drm/i915: Add more control to wait_for routines
>>   drm: Add Content Protection property
>>   drm: Add some HDCP related #defines
>>   drm/i915: Add HDCP framework + base implementation
>>   drm/i915: Add function to output Aksv over GMBUS
>>   drm/i915: Implement HDCP for HDMI
>>   drm/i915: Implement HDCP for DisplayPort
>>
>>  drivers/gpu/drm/drm_atomic.c|   8 +
>>  drivers/gpu/drm/drm_connector.c |  80 -
>>  drivers/gpu/drm/drm_sysfs.c |   1 +
>>  drivers/gpu/drm/i915/Makefile   |   1 +
>>  drivers/gpu/drm/i915/i915_drv.h |   1 +
>>  drivers/gpu/drm/i915/i915_reg.h |  85 +
>>  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>>  drivers/gpu/drm/i915/intel_ddi.c|  64 
>>  drivers/gpu/drm/i915/intel_dp.c | 245 -
>>  drivers/gpu/drm/i915/intel_drv.h|  98 +-
>>  drivers/gpu/drm/i915/intel_hdcp.c   | 684 
>> 
>>  drivers/gpu/drm/i915/intel_hdmi.c   | 254 +
>>  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
>>  drivers/gpu/drm/i915/intel_uncore.c |  23 +-
>>  drivers/gpu/drm/i915/intel_uncore.h |  14 +-
>>  include/drm/drm_connector.h |  16 +
>>  include/drm/drm_dp_helper.h |  17 +
>>  include/drm/drm_hdcp.h  |  56 +++
>>  include/uapi/drm/drm_mode.h |   4 +
>>  19 files changed, 1697 insertions(+), 34 deletions(-)
>>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>>  create mode 100644 include/drm/drm_hdcp.h
>>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 0/8] drm/i915: Implement HDCP

[Hans Verkuil]

Hi Sean,

On 12/01/2017 06:20 PM, Sean Paul wrote:
> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
> list I set out in the first version (Annotated below for convenience).
> 
> The big changes to take note of in v2 is locking. To account for atomic async 
> +
> the property's mutability, I'm using a dedicated mutex and moved property
> setting on the kernel side to the worker. I think this is actually a lot 
> easier
> to read, and it opens the door to future improvements such as not doing the
> enable/disable via modeset.
> 
> TODO:
> - DONE: Add kerneldoc for property
> - DONE: Fix '//' comments
> - DONE: Change to MIT license
> - DONE: Improve documentation on drm_intel_hdcp_shim
> - DONE: Fix async commit locking (ie: don't use connection_mutex)
> - DONE: Don't change connector->state in enable, defer to worker
> - Rebase on Ville's gmbus fixes (thanks Ville)
>   - Looks like these haven't landed, but I've rebased on drm-intel-next
> - Add igt coverage for the feature.
>   - Working on this now

Looking at this patch series it seems that there is no drm support to get the
BKSV from the i915, right? If you want to use the i915 (or any HDMI/DP output)
in a repeater scenario then userspace has to be able to obtain that information
so it can be added to the BKSV of the HDMI receiver.

For the record, the V4L2 subsystem used by HDMI receivers doesn't support HDCP
yet, although patches exist.

I can understand that you are not (yet) adding repeater support, but it should
be documented somewhere in the patch series that this is not there yet and
that a standard DRM API would be needed to obtain the BKSV from the transmitter.

Second question: has this been tested with a MST hub?

Regards,

Hans

> 
> Thanks!
> 
> Sean
> 
> Sean Paul (8):
>   drm: Fix link-status kerneldoc line lengths
>   drm/i915: Add more control to wait_for routines
>   drm: Add Content Protection property
>   drm: Add some HDCP related #defines
>   drm/i915: Add HDCP framework + base implementation
>   drm/i915: Add function to output Aksv over GMBUS
>   drm/i915: Implement HDCP for HDMI
>   drm/i915: Implement HDCP for DisplayPort
> 
>  drivers/gpu/drm/drm_atomic.c|   8 +
>  drivers/gpu/drm/drm_connector.c |  80 -
>  drivers/gpu/drm/drm_sysfs.c |   1 +
>  drivers/gpu/drm/i915/Makefile   |   1 +
>  drivers/gpu/drm/i915/i915_drv.h |   1 +
>  drivers/gpu/drm/i915/i915_reg.h |  85 +
>  drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>  drivers/gpu/drm/i915/intel_ddi.c|  64 
>  drivers/gpu/drm/i915/intel_dp.c | 245 -
>  drivers/gpu/drm/i915/intel_drv.h|  98 +-
>  drivers/gpu/drm/i915/intel_hdcp.c   | 684 
> 
>  drivers/gpu/drm/i915/intel_hdmi.c   | 254 +
>  drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
>  drivers/gpu/drm/i915/intel_uncore.c |  23 +-
>  drivers/gpu/drm/i915/intel_uncore.h |  14 +-
>  include/drm/drm_connector.h |  16 +
>  include/drm/drm_dp_helper.h |  17 +
>  include/drm/drm_hdcp.h  |  56 +++
>  include/uapi/drm/drm_mode.h |   4 +
>  19 files changed, 1697 insertions(+), 34 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>  create mode 100644 include/drm/drm_hdcp.h
> 

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

Re: [Intel-gfx] [PATCH v7 0/7] drm/fbdev: Panel orientation connector property support

[Bartlomiej Zolnierkiewicz]

On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote:
> Here is v7 of my series to add a "panel orientation" property to
> the drm-connector for the LCD panel to let userspace know about LCD
> panels which are not mounted upright, as well as detecting upside-down
> panels without needing quirks (like we do for 90 degree rotated screens).
> 
> Bartlomiej, can we please have your Acked-by for merging patches 1,
> 6 and 7 through the drm tree?

Acked-by: Bartlomiej Zolnierkiewicz 

Given that you add (can be in a incremental patch) a comment to:

  drivers/gpu/drm/drm_panel_orientation_quirks.c [ at the top ]

and

  drivers/gpu/drm/Kconfig [ to config DRM_PANEL_ORIENTATION_QUIRKS ]

explaining that the code in question is shared with fbdev/efifb (so
hopefully people will be careful and not try to make this code DRM
specific at some point in a future). 

> New in v7:
> -Fix embarrassing build error in efifb due to me only rebuilding modules
>  after cleanups from v6
> 
> New in v6:
> -Fix / reference kernel-doc comments
> -Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
> -Move i915 dsi hardware rotation state read-out to intel_dsi_init()
> 
> New in v5:
> -Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
> -drm_fb_helper: Only use hardware (crtc primary plane) rotation for
>  180 degrees for now as 9-/270 degrees rotation requires special handling
> 
> New in v4:
> -Fix drm_fb_helper code setting an invalid rotation value on the primary
>  plane of disabled/unused crtcs (caught by Fi.CI)
> 
> New in v3:
> -As requested by Daniel v3 moves the quirks over from the fbdev
>  subsys to the drm subsys. I've done this by simpy starting with a copy of
>  the quirk table and eventually removing the fbdev version.
> 
> The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
> are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
> discussed previously the plan is to merge all 7 patches through the
> drm tree.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

[Sean Paul]

On Fri, Dec 1, 2017 at 12:57 PM, Chris Wilson  wrote:
> Quoting Chris Wilson (2017-12-01 17:55:15)
>> Quoting Sean Paul (2017-12-01 17:48:17)
>> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson  
>> > wrote:
>> > > The current wait_for() is a little more complicated nowadays (variable
>> > > W).
>> > >
>> >
>> > Hmm, am I based off the wrong tree? I'm using drm-intel-next.
>>
>> drm-intel-next is what was sent as a PR; drm-intel-next-queued is always
>> current. To be sure CI, doesn't complain about merge conflicts, base on
>> drm-tip.
>

A, i forgot about -queued. ok, will rebase.

> Speaking of CI, do you have any instructions on how we might set up a
> test system?

I'm working on an igt test for the property now.

>  Just needs a compatible monitor and some test code?

Yep. For testing, I exposed the property via sysfs and fiddle with it that way.

> Could chamelium or something like that be used as a validator?

You would have to implement the receiver side of HDCP on chamelium in
order for this to work. So, probably not.

Sean

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

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

[Chris Wilson]

Quoting Chris Wilson (2017-12-01 17:55:15)
> Quoting Sean Paul (2017-12-01 17:48:17)
> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson  
> > wrote:
> > > The current wait_for() is a little more complicated nowadays (variable
> > > W).
> > >
> > 
> > Hmm, am I based off the wrong tree? I'm using drm-intel-next.
> 
> drm-intel-next is what was sent as a PR; drm-intel-next-queued is always
> current. To be sure CI, doesn't complain about merge conflicts, base on
> drm-tip.

Speaking of CI, do you have any instructions on how we might set up a
test system? Just needs a compatible monitor and some test code?
Could chamelium or something like that be used as a validator?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

[Chris Wilson]

Quoting Sean Paul (2017-12-01 17:48:17)
> On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson  
> wrote:
> > Quoting Sean Paul (2017-12-01 17:20:24)
> >>  /**
> >> - * _wait_for - magic (register) wait macro
> >> + * __wait_for - magic wait macro
> >>   *
> >> - * Does the right thing for modeset paths when run under kdgb or similar 
> >> atomic
> >> - * contexts. Note that it's important that we check the condition again 
> >> after
> >> + * Macro to help avoid open coding check/wait/timeout patterns, will do 
> >> the
> >> + * right think wrt to choosing msleep vs usleep_range based on how long 
> >> the wait
> >> + * interval is. Note that it's important that we check the condition 
> >> again after
> >>   * having timed out, since the timeout could be due to preemption or 
> >> similar and
> >>   * we've never had a chance to check the condition before the timeout.
> >>   */
> >> -#define _wait_for(COND, US, W) ({ \
> >> +#define __wait_for(OP, COND, US, W) ({ \
> >> unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
> >> int ret__;  \
> >> might_sleep();  \
> >> for (;;) {  \
> >> bool expired__ = time_after(jiffies, timeout__);\
> >> +   OP; \
> >> if (COND) { \
> >> ret__ = 0;  \
> >> break;  \
> >> @@ -62,11 +64,16 @@
> >> ret__ = -ETIMEDOUT; \
> >> break;  \
> >> }   \
> >> -   usleep_range((W), (W) * 2); \
> >> +   if (W > (20 * 1000))\
> >> +   msleep(W / 1000);   \
> >> +   else\
> >> +   usleep_range((W), (W) * 2); \
> >
> > The current wait_for() is a little more complicated nowadays (variable
> > W).
> >
> 
> Hmm, am I based off the wrong tree? I'm using drm-intel-next.

drm-intel-next is what was sent as a PR; drm-intel-next-queued is always
current. To be sure CI, doesn't complain about merge conflicts, base on
drm-tip.

> > Are ms intervals going to be that common? Using a state-machine springs
> > to mind, but you could argue that msleep() is just a yield. Using msleep
> > though is going to leave D processes visible and a bump in load :|
> >
> 
> Probably uncommon, but at the very least, I need one. I wouldn't feel
> comfortable handling such a large wait using usleep_range.

We can use the constants to remove the predicate for when it never will
be needed, so it's not an issue -- either wait will produce a long
uninterruptible sleep.  It's just if that we were to frequently hit that
long sleep, there would be some push back against using wait_for() on that
path as no one likes an "idle" system with load 1.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

[Sean Paul]

On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson  wrote:
> Quoting Sean Paul (2017-12-01 17:20:24)
>>  /**
>> - * _wait_for - magic (register) wait macro
>> + * __wait_for - magic wait macro
>>   *
>> - * Does the right thing for modeset paths when run under kdgb or similar 
>> atomic
>> - * contexts. Note that it's important that we check the condition again 
>> after
>> + * Macro to help avoid open coding check/wait/timeout patterns, will do the
>> + * right think wrt to choosing msleep vs usleep_range based on how long the 
>> wait
>> + * interval is. Note that it's important that we check the condition again 
>> after
>>   * having timed out, since the timeout could be due to preemption or 
>> similar and
>>   * we've never had a chance to check the condition before the timeout.
>>   */
>> -#define _wait_for(COND, US, W) ({ \
>> +#define __wait_for(OP, COND, US, W) ({ \
>> unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
>> int ret__;  \
>> might_sleep();  \
>> for (;;) {  \
>> bool expired__ = time_after(jiffies, timeout__);\
>> +   OP; \
>> if (COND) { \
>> ret__ = 0;  \
>> break;  \
>> @@ -62,11 +64,16 @@
>> ret__ = -ETIMEDOUT; \
>> break;  \
>> }   \
>> -   usleep_range((W), (W) * 2); \
>> +   if (W > (20 * 1000))\
>> +   msleep(W / 1000);   \
>> +   else\
>> +   usleep_range((W), (W) * 2); \
>
> The current wait_for() is a little more complicated nowadays (variable
> W).
>

Hmm, am I based off the wrong tree? I'm using drm-intel-next.

> Are ms intervals going to be that common? Using a state-machine springs
> to mind, but you could argue that msleep() is just a yield. Using msleep
> though is going to leave D processes visible and a bump in load :|
>

Probably uncommon, but at the very least, I need one. I wouldn't feel
comfortable handling such a large wait using usleep_range.

Sean

>> }   \
>> ret__;  \
>>  })
>>
>> +#define _wait_for(COND, US, W) __wait_for(;,(COND), US, W)
>> +
>>  #define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 1000)
>>
>>  /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
>> b/drivers/gpu/drm/i915/intel_uncore.c
>> index b4621271e7a2..c851b0c0602d 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
>> drm_i915_private *dev_priv,
>>  }
>>
>>  /**
>> - * intel_wait_for_register - wait until register matches expected state
>> + * __intel_wait_for_register - wait until register matches expected state
>>   * @dev_priv: the i915 device
>>   * @reg: the register to read
>>   * @mask: mask to apply to register value
>>   * @value: expected value
>> - * @timeout_ms: timeout in millisecond
>> + * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
>> + * @slow_timeout_ms: slow timeout in millisecond
>> + * @out_value: optional placeholder to hold registry value
>>   *
>>   * This routine waits until the target register @reg contains the expected
>>   * @value after applying the @mask, i.e. it waits until ::
>> @@ -1786,15 +1788,18 @@ int __intel_wait_for_register_fw(struct 
>> drm_i915_private *dev_priv,
>>   *
>>   * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
>>   */
>> -int intel_wait_for_register(struct drm_i915_private *dev_priv,
>> +int __intel_wait_for_register(struct drm_i915_private *dev_priv,
>> i915_reg_t reg,
>> u32 mask,
>> u32 value,
>> -   unsigned int timeout_ms)
>> +   unsigned int fast_timeout_us,
>> +   unsigned int slow_timeout_ms,
>> +   u32 *out_value)
>>  {
>> unsigned fw =
>> intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
>> int ret;
>> +   

Re: [Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

[Chris Wilson]

Quoting Sean Paul (2017-12-01 17:20:24)
>  /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
>   *
> - * Does the right thing for modeset paths when run under kdgb or similar 
> atomic
> - * contexts. Note that it's important that we check the condition again after
> + * Macro to help avoid open coding check/wait/timeout patterns, will do the
> + * right think wrt to choosing msleep vs usleep_range based on how long the 
> wait
> + * interval is. Note that it's important that we check the condition again 
> after
>   * having timed out, since the timeout could be due to preemption or similar 
> and
>   * we've never had a chance to check the condition before the timeout.
>   */
> -#define _wait_for(COND, US, W) ({ \
> +#define __wait_for(OP, COND, US, W) ({ \
> unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
> int ret__;  \
> might_sleep();  \
> for (;;) {  \
> bool expired__ = time_after(jiffies, timeout__);\
> +   OP; \
> if (COND) { \
> ret__ = 0;  \
> break;  \
> @@ -62,11 +64,16 @@
> ret__ = -ETIMEDOUT; \
> break;  \
> }   \
> -   usleep_range((W), (W) * 2); \
> +   if (W > (20 * 1000))\
> +   msleep(W / 1000);   \
> +   else\
> +   usleep_range((W), (W) * 2); \

The current wait_for() is a little more complicated nowadays (variable
W).

Are ms intervals going to be that common? Using a state-machine springs
to mind, but you could argue that msleep() is just a yield. Using msleep
though is going to leave D processes visible and a bump in load :|

> }   \
> ret__;  \
>  })
>  
> +#define _wait_for(COND, US, W) __wait_for(;,(COND), US, W)
> +
>  #define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 1000)
>  
>  /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b4621271e7a2..c851b0c0602d 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
> drm_i915_private *dev_priv,
>  }
>  
>  /**
> - * intel_wait_for_register - wait until register matches expected state
> + * __intel_wait_for_register - wait until register matches expected state
>   * @dev_priv: the i915 device
>   * @reg: the register to read
>   * @mask: mask to apply to register value
>   * @value: expected value
> - * @timeout_ms: timeout in millisecond
> + * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
> + * @slow_timeout_ms: slow timeout in millisecond
> + * @out_value: optional placeholder to hold registry value
>   *
>   * This routine waits until the target register @reg contains the expected
>   * @value after applying the @mask, i.e. it waits until ::
> @@ -1786,15 +1788,18 @@ int __intel_wait_for_register_fw(struct 
> drm_i915_private *dev_priv,
>   *
>   * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
>   */
> -int intel_wait_for_register(struct drm_i915_private *dev_priv,
> +int __intel_wait_for_register(struct drm_i915_private *dev_priv,
> i915_reg_t reg,
> u32 mask,
> u32 value,
> -   unsigned int timeout_ms)
> +   unsigned int fast_timeout_us,
> +   unsigned int slow_timeout_ms,
> +   u32 *out_value)
>  {
> unsigned fw =
> intel_uncore_forcewake_for_reg(dev_priv, reg, FW_REG_READ);
> int ret;
> +   u32 reg_value;
>  
> might_sleep();
>  
> @@ -1803,14 +1808,18 @@ int intel_wait_for_register(struct drm_i915_private 
> *dev_priv,
>  
> ret = __intel_wait_for_register_fw(dev_priv,
>reg, mask, value,
> -  2, 0, NULL);
> +  fast_timeout_us, 

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Mask previous DDI - PLL mapping

[Rodrigo Vivi]

On Fri, Dec 01, 2017 at 02:17:00AM +, James Ausmus wrote:
> Without masking out the old value, we can end up pointing the DDI to a
> disabled PLL, which makes the system fall over. Mask out the previous
> value before setting the PLL to DDI mapping.
> 
> This can be observed by running igt/testdisplay with both an eDP and
> HDMI/DP output active.
> 
> v2: Add the Bugzilla link
> 
> Fixes: 555e38d273172 ("drm/i915/cnl: DDI - PLL mapping")
> Testcase: igt/testdisplay
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103997
> Cc: Rodrigo Vivi 
> Cc: Matt Atwood 
> Signed-off-by: James Ausmus 


Reviewed-by: Rodrigo Vivi 
Tested-by: Rodrigo Vivi 
Bug-introduced-by: Rodrigo Vivi  :)

Thanks a lot for the patch! merging asap...

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index eff3b51872eb..123a3253453f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2098,6 +2098,7 @@ static void intel_ddi_clk_select(struct intel_encoder 
> *encoder,
>   if (IS_CANNONLAKE(dev_priv)) {
>   /* Configure DPCLKA_CFGCR0 to map the DPLL to the DDI. */
>   val = I915_READ(DPCLKA_CFGCR0);
> + val &= ~DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
>   val |= DPCLKA_CFGCR0_DDI_CLK_SEL(pll->id, port);
>   I915_WRITE(DPCLKA_CFGCR0, val);
>  
> -- 
> 2.15.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement HDCP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Implement HDCP (rev2)
URL   : https://patchwork.freedesktop.org/series/34671/
State : failure

== Summary ==

Applying: drm: Fix link-status kerneldoc line lengths
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/drm_connector.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/drm_connector.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_connector.c
Patch failed at 0001 drm: Fix link-status kerneldoc line lengths
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] [PATCH v2 8/8] drm/i915: Implement HDCP for DisplayPort

[Sean Paul]

This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.

Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the rest
of it.

Changes in v2:
- Moved intel_hdcp_check_link out of intel_dp_check_link and only call
  it on short pulse. Since intel_hdcp_check_link does its own locking,
  this ensures we don't deadlock when intel_dp_check_link is called
  holding connection_mutex.
- Rebased on drm-intel-next

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_dp.c | 245 ++--
 1 file changed, 238 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc61f38b131d..b237cac822fa 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -36,7 +36,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -1025,10 +1027,29 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp 
*intel_dp,
   DP_AUX_CH_CTL_SYNC_PULSE_SKL(32);
 }
 
+static uint32_t intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
+ bool has_aux_irq,
+ int send_bytes,
+ uint32_t aux_clock_divider,
+ bool aksv_write)
+{
+   uint32_t val = 0;
+
+   if (aksv_write) {
+   send_bytes += 5;
+   val |= DP_AUX_CH_CTL_AUX_AKSV_SELECT;
+   }
+
+   return val | intel_dp->get_aux_send_ctl(intel_dp,
+   has_aux_irq,
+   send_bytes,
+   aux_clock_divider);
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
-   uint8_t *recv, int recv_size)
+   uint8_t *recv, int recv_size, bool aksv_write)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv =
@@ -1088,10 +1109,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
}
 
while ((aux_clock_divider = intel_dp->get_aux_clock_divider(intel_dp, 
clock++))) {
-   u32 send_ctl = intel_dp->get_aux_send_ctl(intel_dp,
- has_aux_irq,
- send_bytes,
- aux_clock_divider);
+   u32 send_ctl = intel_dp_get_aux_send_ctl(intel_dp,
+has_aux_irq,
+send_bytes,
+aux_clock_divider,
+aksv_write);
 
/* Must try at least 3 times according to DP spec */
for (try = 0; try < 5; try++) {
@@ -1228,7 +1250,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (msg->buffer)
memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
 
@@ -1250,7 +1273,8 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
if (WARN_ON(rxsize > 20))
return -E2BIG;
 
-   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize);
+   ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf, rxsize,
+ false);
if (ret > 0) {
msg->reply = rxbuf[0] >> 4;
/*
@@ -4373,6 +4397,9 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
drm_kms_helper_hotplug_event(_priv->drm);
}
 
+   /* Short pulse can signify loss of hdcp authentication */
+   intel_hdcp_check_link(intel_dp->attached_connector);
+
return true;
 }
 
@@ -4963,6 +4990,203 @@ void intel_dp_encoder_suspend(struct intel_encoder 
*intel_encoder)
pps_unlock(intel_dp);
 }
 
+static
+int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
+   u8 *an)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(_dig_port->base.base);
+   uint8_t txbuf[4], rxbuf[2], reply = 0;
+   ssize_t dpcd_ret;
+   int ret;
+
+   /* Output An first, that's 

[Intel-gfx] [PATCH v2 7/8] drm/i915: Implement HDCP for HDMI

[Sean Paul]

This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.

Nothing too special, just a bunch of DDC reads/writes.

Changes in v2:
- Rebased on drm-intel-next

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_reg.h   |   1 +
 drivers/gpu/drm/i915/intel_ddi.c  |  50 
 drivers/gpu/drm/i915/intel_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c | 254 ++
 4 files changed, 307 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b71a20882ca..8ffcd6466084 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8447,6 +8447,7 @@ enum skl_power_gate {
 #define  TRANS_DDI_EDP_INPUT_A_ONOFF   (4<<12)
 #define  TRANS_DDI_EDP_INPUT_B_ONOFF   (5<<12)
 #define  TRANS_DDI_EDP_INPUT_C_ONOFF   (6<<12)
+#define  TRANS_DDI_HDCP_SIGNALLING (1<<9)
 #define  TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
 #define  TRANS_DDI_HDMI_SCRAMBLER_CTS_ENABLE (1<<7)
 #define  TRANS_DDI_HDMI_SCRAMBLER_RESET_FREQ (1<<6)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c784f086bf72..bc31b64b50e6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1615,6 +1615,56 @@ void intel_ddi_disable_transcoder_func(struct 
drm_i915_private *dev_priv,
I915_WRITE(reg, val);
 }
 
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp &= ~TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder)
+{
+   struct drm_device *dev = intel_encoder->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   enum pipe pipe = 0;
+   int ret = 0;
+   uint32_t tmp;
+
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   intel_encoder->power_domain))
+   return -ENXIO;
+
+   if (!intel_encoder->get_hw_state(intel_encoder, )) {
+   ret = -EIO;
+   goto out;
+   }
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe));
+   tmp |= TRANS_DDI_HDCP_SIGNALLING;
+   I915_WRITE(TRANS_DDI_FUNC_CTL(pipe), tmp);
+out:
+   intel_display_power_put(dev_priv, intel_encoder->power_domain);
+   return ret;
+}
+
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector)
 {
struct drm_device *dev = intel_connector->base.dev;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 109143a579e4..9e8c4e563c67 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1378,6 +1378,8 @@ void intel_ddi_compute_min_voltage_level(struct 
drm_i915_private *dev_priv,
 u32 bxt_signal_levels(struct intel_dp *intel_dp);
 uint32_t ddi_signal_levels(struct intel_dp *intel_dp);
 u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
+int intel_ddi_enable_hdcp_signalling(struct intel_encoder *intel_encoder);
+int intel_ddi_disable_hdcp_signalling(struct intel_encoder *intel_encoder);
 
 unsigned int intel_fb_align_height(const struct drm_framebuffer *fb,
   int plane, unsigned int height);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9d5e72728475..322073e03b7a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "intel_drv.h"
 #include 
@@ -873,6 +874,252 @@ void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi 
*hdmi, bool enable)
 adapter, enable);
 }
 
+static int intel_hdmi_hdcp_read(struct intel_digital_port *intel_dig_port,
+   unsigned int offset, void *buffer, size_t size)
+{
+   struct intel_hdmi *hdmi = _dig_port->hdmi;
+   struct drm_i915_private *dev_priv =
+   intel_dig_port->base.base.dev->dev_private;
+   struct i2c_adapter *adapter = intel_gmbus_get_adapter(dev_priv,
+ hdmi->ddc_bus);
+   int ret;
+   u8 start = offset & 0xff;
+   struct i2c_msg msgs[] = {
+   {
+  

[Intel-gfx] [PATCH v2 6/8] drm/i915: Add function to output Aksv over GMBUS

[Sean Paul]

Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.

The way we do this is to initiate an indexed write where the index is
the Aksv register offset. We write dummy values to GMBUS3 as if we were
sending the key, and the hardware slips in the "real" values when it
goes out.

Changes in v2:
- None

Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_i2c.c | 54 ++--
 3 files changed, 48 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 36bb4927484a..10f740c9e571 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4043,6 +4043,7 @@ extern int intel_setup_gmbus(struct drm_i915_private 
*dev_priv);
 extern void intel_teardown_gmbus(struct drm_i915_private *dev_priv);
 extern bool intel_gmbus_is_valid_pin(struct drm_i915_private *dev_priv,
 unsigned int pin);
+extern int intel_gmbus_output_aksv(struct i2c_adapter *adapter);
 
 extern struct i2c_adapter *
 intel_gmbus_get_adapter(struct drm_i915_private *dev_priv, unsigned int pin);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6dca305ccbf7..8b71a20882ca 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3040,6 +3040,7 @@ enum i915_power_well_id {
 # define GPIO_DATA_PULLUP_DISABLE  (1 << 13)
 
 #define GMBUS0 _MMIO(dev_priv->gpio_mmio_base + 0x5100) /* 
clock/port select */
+#define   GMBUS_AKSV_SELECT(1<<11)
 #define   GMBUS_RATE_100KHZ(0<<8)
 #define   GMBUS_RATE_50KHZ (1<<8)
 #define   GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index eb5827110d8f..c01156bf0f27 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -373,7 +374,8 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg,
 
 static int
 gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
-  unsigned short addr, u8 *buf, unsigned int len)
+  unsigned short addr, u8 *buf, unsigned int len,
+  u32 gmbus1_index)
 {
unsigned int chunk_size = len;
u32 val, loop;
@@ -386,7 +388,7 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 
I915_WRITE_FW(GMBUS3, val);
I915_WRITE_FW(GMBUS1,
- GMBUS_CYCLE_WAIT |
+ gmbus1_index | GMBUS_CYCLE_WAIT |
  (chunk_size << GMBUS_BYTE_COUNT_SHIFT) |
  (addr << GMBUS_SLAVE_ADDR_SHIFT) |
  GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
@@ -409,7 +411,8 @@ gmbus_xfer_write_chunk(struct drm_i915_private *dev_priv,
 }
 
 static int
-gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg)
+gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
+u32 gmbus1_index)
 {
u8 *buf = msg->buf;
unsigned int tx_size = msg->len;
@@ -419,7 +422,8 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct 
i2c_msg *msg)
do {
len = min(tx_size, GMBUS_BYTE_COUNT_MAX);
 
-   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len);
+   ret = gmbus_xfer_write_chunk(dev_priv, msg->addr, buf, len,
+gmbus1_index);
if (ret)
return ret;
 
@@ -470,7 +474,8 @@ gmbus_xfer_index_read(struct drm_i915_private *dev_priv, 
struct i2c_msg *msgs)
 }
 
 static int
-do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num)
+do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num,
+ u32 gmbus0_source, u32 gmbus1_index)
 {
struct intel_gmbus *bus = container_of(adapter,
   struct intel_gmbus,
@@ -480,7 +485,7 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
int ret = 0;
 
 retry:
-   I915_WRITE_FW(GMBUS0, bus->reg0);
+   I915_WRITE_FW(GMBUS0, gmbus0_source | bus->reg0);
 
for (; i < num; i += inc) {
inc = 1;
@@ -490,7 +495,8 @@ do_gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
*msgs, int num)
} else if (msgs[i].flags & I2C_M_RD) {
ret = gmbus_xfer_read(dev_priv, [i], 0);
} else {
-   ret = gmbus_xfer_write(dev_priv, [i]);
+

[Intel-gfx] [PATCH v2 3/8] drm: Add Content Protection property

[Sean Paul]

This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.

The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED: Userspace requests that the driver enable protection
- ENABLED: Once the driver has authenticated the link, it sets this value

The driver is responsible for downgrading ENABLED to DESIRED if the link becomes
unprotected. The driver should also maintain the desiredness of protection
across hotplug/dpms/suspend.

If this looks familiar, I posted [1] this 3 years ago. We have been using this
in ChromeOS across exynos, mediatek, and rockchip over that time.

Changes in v2:
 - Pimp kerneldoc for content_protection_property (Daniel)
 - Drop sysfs attribute

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 

[1] https://lists.freedesktop.org/archives/dri-devel/2014-December/073336.html
---
 drivers/gpu/drm/drm_atomic.c|  8 +
 drivers/gpu/drm/drm_connector.c | 71 +
 drivers/gpu/drm/drm_sysfs.c |  1 +
 include/drm/drm_connector.h | 16 ++
 include/uapi/drm/drm_mode.h |  4 +++
 5 files changed, 100 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c2da5585e201..676025d755b2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1196,6 +1196,12 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->picture_aspect_ratio = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
+   } else if (property == connector->content_protection_property) {
+   if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
+   DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
+   return -EINVAL;
+   }
+   state->content_protection = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1275,6 +1281,8 @@ drm_atomic_connector_get_property(struct drm_connector 
*connector,
*val = state->picture_aspect_ratio;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
+   } else if (property == connector->content_protection_property) {
+   *val = state->content_protection;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f14b48e6e839..8626aa8f485e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -698,6 +698,13 @@ static const struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+{ DRM_MODE_CONTENT_PROTECTION_OFF, "Off" },
+{ DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+{ DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
 /**
  * DOC: standard connector properties
  *
@@ -764,6 +771,34 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  *  after modeset, the kernel driver may set this to "BAD" and issue a
  *  hotplug uevent. Drivers should update this value using
  *  drm_mode_connector_set_link_status_property().
+ * Content Protection:
+ * This property is used by userspace to request the kernel protect future
+ * content communicated over the link. When requested, kernel will apply
+ * the appropriate means of protection (most often HDCP), and use the
+ * property to tell userspace the protection is active.
+ *
+ * The value of this property can be one of the following:
+ *
+ * - DRM_MODE_CONTENT_PROTECTION_OFF = 0
+ * The link is not protected, content is transmitted in the clear.
+ * - DRM_MODE_CONTENT_PROTECTION_DESIRED = 1
+ * Userspace has requested content protection, but the link is not
+ * currently protected. When in this state, kernel should enable
+ * Content Protection as soon as possible.
+ * - DRM_MODE_CONTENT_PROTECTION_ENABLED = 2
+ * Userspace has requested content protection, and the link is
+ * protected. Only the driver can set the property to this value.
+ * If userspace attempts to set to ENABLED, kernel will return
+ * -EINVAL.
+ *
+ * A few guidelines:
+ *
+ * - DESIRED state 

[Intel-gfx] [PATCH v2 5/8] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.

Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.

Changes in v2:
- Don't open code wait_fors (Chris)
- drm_hdcp.c under MIT license (Daniel)
- Move intel_hdcp_disable() call above ddi_disable (Ram)
- Fix // comments (I wore a cone of shame for 12 hours to atone) (Daniel)
- Justify intel_hdcp_shim with comments (Daniel)
- Fixed async locking issues by adding hdcp_mutex (Daniel)
- Don't alter connector_state in enable/disable (Daniel)

Cc: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ramalingam C 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_reg.h |  83 +
 drivers/gpu/drm/i915/intel_atomic.c |  26 +-
 drivers/gpu/drm/i915/intel_ddi.c|  14 +
 drivers/gpu/drm/i915/intel_drv.h|  79 +
 drivers/gpu/drm/i915/intel_hdcp.c   | 684 
 6 files changed, 885 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index c3649ec5b041..120a0bb73c49 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -106,6 +106,7 @@ i915-y += intel_audio.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
  intel_frontbuffer.o \
+ intel_hdcp.o \
  intel_hotplug.o \
  intel_modes.o \
  intel_overlay.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 96c80fa0fcac..6dca305ccbf7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8031,6 +8031,7 @@ enum {
 #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT   8
 #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT   16
 #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT   24
+#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
 #define   SKL_PCODE_CDCLK_CONTROL  0x7
 #define SKL_CDCLK_PREPARE_FOR_CHANGE   0x3
 #define SKL_CDCLK_READY_FOR_CHANGE 0x1
@@ -8332,6 +8333,88 @@ enum skl_power_gate {
 #define  SKL_PW_TO_PG(pw)  ((pw) - SKL_DISP_PW_1 + SKL_PG1)
 #define  SKL_FUSE_PG_DIST_STATUS(pg)   (1 << (27 - (pg)))
 
+
+/* HDCP Key Registers */
+#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
+#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
+#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
+#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
+#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
+#define  SKL_HDCP_FUSE_ERROR   BIT(6)
+#define  SKL_HDCP_FUSE_DONEBIT(5)
+#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
+#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
+#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
+#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
+#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
+#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
+#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
+#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
+#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
+#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)
+#define  SKL_HDCP_DDIB_SHA1_M0 (1 << 20)
+#define  SKL_HDCP_DDIA_SHA1_M0 (2 << 20)
+#define  SKL_HDCP_DDIC_SHA1_M0 (3 << 20)
+#define  SKL_HDCP_DDID_SHA1_M0 (4 << 20)
+#define  SKL_HDCP_DDIF_SHA1_M0 (5 << 20)
+#define  SKL_HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define  SKL_HDCP_SHA1_BUSYBIT(16)
+#define  SKL_HDCP_SHA1_READY   BIT(17)
+#define  SKL_HDCP_SHA1_COMPLETEBIT(18)
+#define  SKL_HDCP_SHA1_V_MATCH BIT(19)
+#define  SKL_HDCP_SHA1_TEXT_32 (1 << 1)
+#define  SKL_HDCP_SHA1_COMPLETE_HASH   (2 << 1)
+#define  SKL_HDCP_SHA1_TEXT_24 (4 << 1)
+#define  SKL_HDCP_SHA1_TEXT_16 (5 << 1)
+#define  SKL_HDCP_SHA1_TEXT_8  (6 << 1)
+#define  SKL_HDCP_SHA1_TEXT_0  (7 << 1)
+#define SKL_HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define SKL_HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define SKL_HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define SKL_HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define SKL_HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define SKL_HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + h * 4))
+#define SKL_HDCP_SHA_TEXT  _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _SKL_PORTA_HDCP_AUTHENC0x66800
+#define _SKL_PORTB_HDCP_AUTHENC0x66500
+#define _SKL_PORTC_HDCP_AUTHENC0x66600
+#define _SKL_PORTD_HDCP_AUTHENC0x66700
+#define 

[Intel-gfx] [PATCH v2 4/8] drm: Add some HDCP related #defines

[Sean Paul]

In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.

Changes in v2:
- drm_hdcp.h gets MIT license (Daniel)

Cc: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 include/drm/drm_dp_helper.h | 17 ++
 include/drm/drm_hdcp.h  | 56 +
 2 files changed, 73 insertions(+)
 create mode 100644 include/drm/drm_hdcp.h

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 8b9ac321c3bd..4b2640d54c70 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -815,6 +815,23 @@
 #define DP_CEC_TX_MESSAGE_BUFFER   0x3020
 #define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10
 
+#define DP_AUX_HDCP_BKSV   0x68000
+#define DP_AUX_HDCP_RI_PRIME   0x68005
+#define DP_AUX_HDCP_AKSV   0x68007
+#define DP_AUX_HDCP_AN 0x6800C
+#define DP_AUX_HDCP_V_PRIME(h) (0x68014 + h * 4)
+#define DP_AUX_HDCP_BCAPS  0x68028
+# define DP_BCAPS_REPEATER_PRESENT BIT(1)
+# define DP_BCAPS_HDCP_CAPABLE BIT(0)
+#define DP_AUX_HDCP_BSTATUS0x68029
+# define DP_BSTATUS_REAUTH_REQ BIT(3)
+# define DP_BSTATUS_LINK_FAILURE   BIT(2)
+# define DP_BSTATUS_R0_PRIME_READY BIT(1)
+# define DP_BSTATUS_READY  BIT(0)
+#define DP_AUX_HDCP_BINFO  0x6802A
+#define DP_AUX_HDCP_KSV_FIFO   0x6802C
+#define DP_AUX_HDCP_AINFO  0x6803B
+
 /* DP 1.2 Sideband message defines */
 /* peer device type - DP 1.2a Table 2-92 */
 #define DP_PEER_DEVICE_NONE0x0
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
new file mode 100644
index ..c9b2484240d4
--- /dev/null
+++ b/include/drm/drm_hdcp.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2017 Google, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Sean Paul 
+ */
+
+#ifndef _DRM_HDCP_H_INCLUDED_
+#define _DRM_HDCP_H_INCLUDED_
+
+/* Period of hdcp checks (to ensure we're still authenticated) */
+#define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
+
+/* Shared lengths/masks between HDMI/DVI/DisplayPort */
+#define DRM_HDCP_AN_LEN8
+#define DRM_HDCP_BSTATUS_LEN   2
+#define DRM_HDCP_KSV_LEN   5
+#define DRM_HDCP_RI_LEN2
+#define DRM_HDCP_V_PRIME_PART_LEN  4
+#define DRM_HDCP_V_PRIME_NUM_PARTS 5
+#define DRM_HDCP_NUM_DOWNSTREAM(x) (x & 0x3f)
+
+/* Slave address for the HDCP registers in the receiver */
+#define DRM_HDCP_DDC_ADDR  0x3A
+
+/* HDCP register offsets for HDMI/DVI devices */
+#define DRM_HDCP_DDC_BKSV  0x00
+#define DRM_HDCP_DDC_RI_PRIME  0x08
+#define DRM_HDCP_DDC_AKSV  0x10
+#define DRM_HDCP_DDC_AN0x18
+#define DRM_HDCP_DDC_V_PRIME(h)(0x20 + h * 4)
+#define DRM_HDCP_DDC_BCAPS 0x40
+#define  DRM_HDCP_DDC_BCAPS_REPEATER_PRESENT   BIT(6)
+#define  DRM_HDCP_DDC_BCAPS_KSV_FIFO_READY BIT(5)
+#define DRM_HDCP_DDC_BSTATUS   0x41
+#define DRM_HDCP_DDC_KSV_FIFO  0x43
+
+#endif
-- 
2.15.0.531.g2ccb3012c9-goog

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

[Intel-gfx] [PATCH v2 2/8] drm/i915: Add more control to wait_for routines

[Sean Paul]

This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
 - need the value of the register after the wait_for
 - run arbitrary operation for the read portion

This patch also chooses the correct sleep function (based on
timers-howto.txt) for the polling interval the caller specifies.

Changes in v2:
- Added to the series

Suggested-by: Chris Wilson 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_drv.h| 17 -
 drivers/gpu/drm/i915/intel_uncore.c | 23 ---
 drivers/gpu/drm/i915/intel_uncore.h | 14 +-
 3 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 69aab324aaa1..191c80fc4314 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -41,19 +41,21 @@
 #include 
 
 /**
- * _wait_for - magic (register) wait macro
+ * __wait_for - magic wait macro
  *
- * Does the right thing for modeset paths when run under kdgb or similar atomic
- * contexts. Note that it's important that we check the condition again after
+ * Macro to help avoid open coding check/wait/timeout patterns, will do the
+ * right think wrt to choosing msleep vs usleep_range based on how long the 
wait
+ * interval is. Note that it's important that we check the condition again 
after
  * having timed out, since the timeout could be due to preemption or similar 
and
  * we've never had a chance to check the condition before the timeout.
  */
-#define _wait_for(COND, US, W) ({ \
+#define __wait_for(OP, COND, US, W) ({ \
unsigned long timeout__ = jiffies + usecs_to_jiffies(US) + 1;   \
int ret__;  \
might_sleep();  \
for (;;) {  \
bool expired__ = time_after(jiffies, timeout__);\
+   OP; \
if (COND) { \
ret__ = 0;  \
break;  \
@@ -62,11 +64,16 @@
ret__ = -ETIMEDOUT; \
break;  \
}   \
-   usleep_range((W), (W) * 2); \
+   if (W > (20 * 1000))\
+   msleep(W / 1000);   \
+   else\
+   usleep_range((W), (W) * 2); \
}   \
ret__;  \
 })
 
+#define _wait_for(COND, US, W) __wait_for(;,(COND), US, W)
+
 #define wait_for(COND, MS) _wait_for((COND), (MS) * 1000, 1000)
 
 /* If CONFIG_PREEMPT_COUNT is disabled, in_atomic() always reports false. */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index b4621271e7a2..c851b0c0602d 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1770,12 +1770,14 @@ int __intel_wait_for_register_fw(struct 
drm_i915_private *dev_priv,
 }
 
 /**
- * intel_wait_for_register - wait until register matches expected state
+ * __intel_wait_for_register - wait until register matches expected state
  * @dev_priv: the i915 device
  * @reg: the register to read
  * @mask: mask to apply to register value
  * @value: expected value
- * @timeout_ms: timeout in millisecond
+ * @fast_timeout_us: fast timeout in microsecond for atomic/tight wait
+ * @slow_timeout_ms: slow timeout in millisecond
+ * @out_value: optional placeholder to hold registry value
  *
  * This routine waits until the target register @reg contains the expected
  * @value after applying the @mask, i.e. it waits until ::
@@ -1786,15 +1788,18 @@ int __intel_wait_for_register_fw(struct 
drm_i915_private *dev_priv,
  *
  * Returns 0 if the register matches the desired condition, or -ETIMEOUT.
  */
-int intel_wait_for_register(struct drm_i915_private *dev_priv,
+int __intel_wait_for_register(struct drm_i915_private *dev_priv,
i915_reg_t reg,
u32 mask,
u32 value,
-   unsigned int timeout_ms)
+   unsigned int fast_timeout_us,
+   unsigned int slow_timeout_ms,
+   u32 *out_value)
 {
unsigned fw =
 

[Intel-gfx] [PATCH v2 1/8] drm: Fix link-status kerneldoc line lengths

[Sean Paul]

I'm adding some stuff below it and it's killing my editor's vibe.

Changes in v2:
- Added to the series

Cc: Manasi Navare 
Acked-by: Daniel Vetter 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/drm_connector.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..f14b48e6e839 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -759,10 +759,11 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
  * should update this value using drm_mode_connector_set_tile_property().
  * Userspace cannot change this property.
  * link-status:
- *  Connector link-status property to indicate the status of link. The 
default
- *  value of link-status is "GOOD". If something fails during or after 
modeset,
- *  the kernel driver may set this to "BAD" and issue a hotplug uevent. 
Drivers
- *  should update this value using 
drm_mode_connector_set_link_status_property().
+ *  Connector link-status property to indicate the status of link. The
+ *  default value of link-status is "GOOD". If something fails during or
+ *  after modeset, the kernel driver may set this to "BAD" and issue a
+ *  hotplug uevent. Drivers should update this value using
+ *  drm_mode_connector_set_link_status_property().
  *
  * Connectors also have one standardized atomic property:
  *
-- 
2.15.0.531.g2ccb3012c9-goog

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

[Intel-gfx] [PATCH v2 0/8] drm/i915: Implement HDCP

[Sean Paul]

Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
list I set out in the first version (Annotated below for convenience).

The big changes to take note of in v2 is locking. To account for atomic async +
the property's mutability, I'm using a dedicated mutex and moved property
setting on the kernel side to the worker. I think this is actually a lot easier
to read, and it opens the door to future improvements such as not doing the
enable/disable via modeset.

TODO:
- DONE: Add kerneldoc for property
- DONE: Fix '//' comments
- DONE: Change to MIT license
- DONE: Improve documentation on drm_intel_hdcp_shim
- DONE: Fix async commit locking (ie: don't use connection_mutex)
- DONE: Don't change connector->state in enable, defer to worker
- Rebase on Ville's gmbus fixes (thanks Ville)
  - Looks like these haven't landed, but I've rebased on drm-intel-next
- Add igt coverage for the feature.
  - Working on this now

Thanks!

Sean

Sean Paul (8):
  drm: Fix link-status kerneldoc line lengths
  drm/i915: Add more control to wait_for routines
  drm: Add Content Protection property
  drm: Add some HDCP related #defines
  drm/i915: Add HDCP framework + base implementation
  drm/i915: Add function to output Aksv over GMBUS
  drm/i915: Implement HDCP for HDMI
  drm/i915: Implement HDCP for DisplayPort

 drivers/gpu/drm/drm_atomic.c|   8 +
 drivers/gpu/drm/drm_connector.c |  80 -
 drivers/gpu/drm/drm_sysfs.c |   1 +
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   1 +
 drivers/gpu/drm/i915/i915_reg.h |  85 +
 drivers/gpu/drm/i915/intel_atomic.c |  26 +-
 drivers/gpu/drm/i915/intel_ddi.c|  64 
 drivers/gpu/drm/i915/intel_dp.c | 245 -
 drivers/gpu/drm/i915/intel_drv.h|  98 +-
 drivers/gpu/drm/i915/intel_hdcp.c   | 684 
 drivers/gpu/drm/i915/intel_hdmi.c   | 254 +
 drivers/gpu/drm/i915/intel_i2c.c|  54 ++-
 drivers/gpu/drm/i915/intel_uncore.c |  23 +-
 drivers/gpu/drm/i915/intel_uncore.h |  14 +-
 include/drm/drm_connector.h |  16 +
 include/drm/drm_dp_helper.h |  17 +
 include/drm/drm_hdcp.h  |  56 +++
 include/uapi/drm/drm_mode.h |   4 +
 19 files changed, 1697 insertions(+), 34 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
 create mode 100644 include/drm/drm_hdcp.h

-- 
2.15.0.531.g2ccb3012c9-goog

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

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/huc: Load HuC only if requested

[Michal Wajdeczko]

On Fri, 01 Dec 2017 17:39:38 +0100, Sagar Arun Kamble  
 wrote:





On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:

Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 



  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
int ret, attempts;
if (!USES_GUC(dev_priv))
@@ -220,7 +221,12 @@ int intel_uc_init_hw(struct drm_i915_private  
*dev_priv)

if (ret)
goto err_submission;
  - intel_huc_init_hw(_priv->huc);
+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_init_hw(huc);
+   if (ret)
+   break;

this break should be "goto err_submission" as GuC is still not ready.


but GuC may also be not ready due to guc fw upload failure ...

looks like user has to be very careful with param now that HuC failure  
can block GuC tasks too.


yep, this is lowlight of this patch, as all selected options are now  
'required'



+   }
+
intel_guc_init_params(guc);
ret = intel_guc_fw_upload(guc);
if (ret == 0 || ret != -EAGAIN)
@@ -238,7 +244,12 @@ int intel_uc_init_hw(struct drm_i915_private  
*dev_priv)

if (ret)
goto err_log_capture;
  - intel_huc_auth(_priv->huc);
+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_auth(huc);
+   if (ret)
+   goto err_interrupts;
+   }
+
if (USES_GUC_SUBMISSION(dev_priv)) {
if (i915_modparams.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
@@ -252,6 +263,8 @@ int intel_uc_init_hw(struct drm_i915_private  
*dev_priv)

 guc->fw.major_ver_found, guc->fw.minor_ver_found);
dev_info(dev_priv->drm.dev, "GuC submission %s\n",
 enableddisabled(USES_GUC_SUBMISSION(dev_priv)));
+   dev_info(dev_priv->drm.dev, "HuC %s\n",
+enableddisabled(USES_HUC(dev_priv)));
return 0;


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

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/huc: Load HuC only if requested

[Sagar Arun Kamble]

On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:

Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 



  int intel_uc_init_hw(struct drm_i915_private *dev_priv)
  {
struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
int ret, attempts;
  
  	if (!USES_GUC(dev_priv))

@@ -220,7 +221,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_submission;
  
-		intel_huc_init_hw(_priv->huc);

+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_init_hw(huc);
+   if (ret)
+   break;

this break should be "goto err_submission" as GuC is still not ready.
looks like user has to be very careful with param now that HuC failure 
can block GuC tasks too.

+   }
+
intel_guc_init_params(guc);
ret = intel_guc_fw_upload(guc);
if (ret == 0 || ret != -EAGAIN)
@@ -238,7 +244,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
if (ret)
goto err_log_capture;
  
-	intel_huc_auth(_priv->huc);

+   if (USES_HUC(dev_priv)) {
+   ret = intel_huc_auth(huc);
+   if (ret)
+   goto err_interrupts;
+   }
+
if (USES_GUC_SUBMISSION(dev_priv)) {
if (i915_modparams.guc_log_level >= 0)
gen9_enable_guc_interrupts(dev_priv);
@@ -252,6 +263,8 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 guc->fw.major_ver_found, guc->fw.minor_ver_found);
dev_info(dev_priv->drm.dev, "GuC submission %s\n",
 enableddisabled(USES_GUC_SUBMISSION(dev_priv)));
+   dev_info(dev_priv->drm.dev, "HuC %s\n",
+enableddisabled(USES_HUC(dev_priv)));
  
  	return 0;
  


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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Sleep and retry a GPU reset if at first we don't succeed (rev2)

[Chris Wilson]

Quoting Patchwork (2017-12-01 14:00:49)
> == Series Details ==
> 
> Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed 
> (rev2)
> URL   : https://patchwork.freedesktop.org/series/34747/
> State : success
> 
> == Summary ==
> 
> Test drv_selftest:
> Subgroup mock_sanitycheck:
> pass   -> DMESG-WARN (shard-snb) fdo#102707
> Test perf:
> Subgroup oa-exponents:
> pass   -> FAIL   (shard-hsw) fdo#102254
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
> skip   -> PASS   (shard-snb) fdo#101623
> Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-wc:
> skip   -> PASS   (shard-snb) fdo#103167
> Test kms_plane:
> Subgroup plane-panning-top-left-pipe-a-planes:
> skip   -> PASS   (shard-snb)
> Test kms_cursor_legacy:
> Subgroup cursora-vs-flipa-legacy:
> skip   -> PASS   (shard-snb)
> Test kms_cursor_crc:
> Subgroup cursor-256x256-suspend:
> pass   -> INCOMPLETE (shard-hsw) fdo#103375
> Test kms_setmode:
> Subgroup basic:
> pass   -> FAIL   (shard-hsw) fdo#99912
> Test kms_flip:
> Subgroup blocking-wf_vblank:
> fail   -> PASS   (shard-snb)

And applied to see if ilk ever fumbles again. Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/uc: Don't use -EIO to report missing firmware

[Michal Wajdeczko]

On Fri, 01 Dec 2017 16:55:41 +0100, Sagar Arun Kamble  
 wrote:





On 12/1/2017 6:01 PM, Chris Wilson wrote:

Quoting Michal Wajdeczko (2017-12-01 10:33:14)

-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to GPU condition.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 

Ok, keeping -EIO to mean something special is a good idea. So if upload
now fails, we abort loading of the driver with ENOEXEC.

Is that sensible? Let's say due to fs corruption, or other error, we
aren't able to upload a fw, what should we do? If we abort the driver
load at this point, the user is likely left with a blank screen. If we
use -EIO, at least KMS is still functional and the user can still
interact with the system. (If we just fell back to execlists, then the
system remains very usable.)

What is the plan for HW initialisation failure?
Earlier we were returning -EIO from intel_uc_init_hw when GuC  
load/submission was "required" (enable_guc_loading/submission=2).
Keeping the same behavior I feel we should return -EIO if (enable_guc &  
1) (need to know that user requested "required")
I feel on auto mode (need to know user requested "auto") falling back to  
execlists makes sense as user dint enforce, so we should be returning 0  
then.


if we return 0 and use execlist then we will have mismatched state
in flags as USES_GUC will be still returning true (as the same time
we don't want to do late changes to enable_guc modparam on failure
as part of the driver was already initiated with old value)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Michal Wajdeczko]

On Fri, 01 Dec 2017 16:47:40 +0100, Sagar Arun Kamble  
 wrote:





On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.

Lets combine above module parameters into one "enable_guc"
modparam. New supported bit values are:

  0=disable GuC (no GuC submission, no HuC)
  1=enable GuC submission
  2=enable HuC load

Special value "-1" can be used to let driver decide what
option should be enabled for given platform based on
hardware/firmware availability or preference.

Explicit enabling any of the GuC features makes GuC load
a required step, fallback to non-GuC mode will not be
supported.

v2: Don't use -EIO

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 



+void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+{
+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
+   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   int enable_guc = __get_default_enable_guc(dev_priv);
/* A negative value means "use platform default" */
-   if (i915_modparams.enable_guc_submission < 0)
-   i915_modparams.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
+   if (i915_modparams.enable_guc < 0)
+   i915_modparams.enable_guc = enable_guc;
+
+   /* Verify GuC firmware availability */
+   if (USES_GUC(dev_priv) && !intel_uc_fw_is_selected(guc_fw)) {
+   DRM_WARN("Incompatible option enable_guc=%d - %s\n",
+i915_modparams.enable_guc,
+!HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+   }
+
+   /* Verify HuC firmware availability */
+	if (USES_GUC_SUBMISSION(dev_priv) &&  
!intel_uc_fw_is_selected(huc_fw)) {

should be USES_HUC here


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

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/uc: Don't use -EIO to report missing firmware

[Sagar Arun Kamble]

On 12/1/2017 6:01 PM, Chris Wilson wrote:

Quoting Michal Wajdeczko (2017-12-01 10:33:14)

-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to GPU condition.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 

Ok, keeping -EIO to mean something special is a good idea. So if upload
now fails, we abort loading of the driver with ENOEXEC.

Is that sensible? Let's say due to fs corruption, or other error, we
aren't able to upload a fw, what should we do? If we abort the driver
load at this point, the user is likely left with a blank screen. If we
use -EIO, at least KMS is still functional and the user can still
interact with the system. (If we just fell back to execlists, then the
system remains very usable.)

What is the plan for HW initialisation failure?
Earlier we were returning -EIO from intel_uc_init_hw when GuC 
load/submission was "required" (enable_guc_loading/submission=2).
Keeping the same behavior I feel we should return -EIO if (enable_guc & 
1) (need to know that user requested "required")
I feel on auto mode (need to know user requested "auto") falling back to 
execlists makes sense as user dint enforce, so we should be returning 0 
then.

-Chris


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

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Sagar Arun Kamble]

On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.

Lets combine above module parameters into one "enable_guc"
modparam. New supported bit values are:

  0=disable GuC (no GuC submission, no HuC)
  1=enable GuC submission
  2=enable HuC load

Special value "-1" can be used to let driver decide what
option should be enabled for given platform based on
hardware/firmware availability or preference.

Explicit enabling any of the GuC features makes GuC load
a required step, fallback to non-GuC mode will not be
supported.

v2: Don't use -EIO

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 



+void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+{
+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
+   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   int enable_guc = __get_default_enable_guc(dev_priv);
  
  	/* A negative value means "use platform default" */

-   if (i915_modparams.enable_guc_submission < 0)
-   i915_modparams.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
+   if (i915_modparams.enable_guc < 0)
+   i915_modparams.enable_guc = enable_guc;
+
+   /* Verify GuC firmware availability */
+   if (USES_GUC(dev_priv) && !intel_uc_fw_is_selected(guc_fw)) {
+   DRM_WARN("Incompatible option enable_guc=%d - %s\n",
+i915_modparams.enable_guc,
+!HAS_GUC(dev_priv) ? "no GuC hardware" :
+ "no GuC firmware");
+   }
+
+   /* Verify HuC firmware availability */
+   if (USES_GUC_SUBMISSION(dev_priv) && !intel_uc_fw_is_selected(huc_fw)) {

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

[Intel-gfx] ✓ Fi.CI.IGT: success for igt: Make dependency on libunwind mandatory

[Patchwork]

== Series Details ==

Series: igt: Make dependency on libunwind mandatory
URL   : https://patchwork.freedesktop.org/series/34752/
State : success

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS   (shard-snb) fdo#104009 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-snb) fdo#102707 +1
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-a-planes:
incomplete -> PASS   (shard-hsw)
Test gem_busy:
Subgroup close-race:
fail   -> PASS   (shard-snb) fdo#103829

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

shard-hswtotal:2663 pass:1536 dwarn:1   dfail:0   fail:10  skip:1116 
time:9535s
shard-snbtotal:2663 pass:1306 dwarn:3   dfail:0   fail:12  skip:1342 
time:8174s
Blacklisted hosts:
shard-apltotal:2663 pass:1689 dwarn:3   dfail:0   fail:22  skip:949 
time:13669s
shard-kbltotal:2663 pass:1805 dwarn:1   dfail:0   fail:24  skip:833 
time:10935s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Interlaced DP output doesn't work on VLV/CHV

[Ville Syrjälä]

On Wed, Nov 29, 2017 at 03:07:03PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 29, 2017 at 06:08:47PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Reject interlaced modes on VLV/CHV DP outputs. This simply does
> > not work correctly in the hardware. We do get some output, but
> > it's quite corrupted.
> > 
> > The available documentation fails to mention this fact. I
> > contacted some hardware people who eventually managed to locate
> > the relevant HSD for VLV, which was resolved by declaring
> > interlaced DP output as not supported. The HSD was never cloned
> > for CHV even though it inherited most of the hardware and
> > thus has the same problems with interlaced DP output.
> > 
> > Cc: Dennis Vshivkov 
> > Reported-by: Dennis Vshivkov 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103922
> > Signed-off-by: Ville Syrjälä 
> 
> I'm afraid we won't be able to track that down...
> I took a quick look on wa_database for vlv/chv to see if
> something seemed related, but nothing ring a bell...
> 
> So, let's live without these modes.
> 
> Acked-by: Rodrigo Vivi 

Thanks. Pushed to dinq.

> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 957735c0b4c6..61cde5cd04d3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1677,6 +1677,10 @@ intel_dp_compute_config(struct intel_encoder 
> > *encoder,
> > conn_state->scaling_mode);
> > }
> >  
> > +   if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
> > +   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
> > +   return false;
> > +
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return false;
> >  
> > @@ -6083,7 +6087,8 @@ intel_dp_init_connector(struct intel_digital_port 
> > *intel_dig_port,
> > drm_connector_init(dev, connector, _dp_connector_funcs, type);
> > drm_connector_helper_add(connector, _dp_connector_helper_funcs);
> >  
> > -   connector->interlace_allowed = true;
> > +   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> > +   connector->interlace_allowed = true;
> > connector->doublescan_allowed = 0;
> >  
> > intel_dp_init_connector_port_info(intel_dig_port);
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix deadlock in i830_disable_pipe()

[Ville Syrjälä]

On Wed, Nov 29, 2017 at 02:54:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> i830_disable_pipe() gets called from the power well code, and thus
> we're already holding the power domain mutex. That means we can't
> call plane->get_hw_state() as it will also try to grab the
> same mutex and will thus deadlock.
> 
> Replace the assert_plane() calls (which calls ->get_hw_state()) with
> just raw register reads in i830_disable_pipe(). As a bonus we can
> now get a warning if plane C is enabled even though we don't even
> expose it as a drm plane.
> 
> v2: Do a separate WARN_ON() for each plane (Chris)
> 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson 
> Fixes: 51f5a0963984 ("drm/i915: Add .get_hw_state() method for planes")
> Signed-off-by: Ville Syrjälä 

Pushed to dinq. Thanks for the review.

> ---
>  drivers/gpu/drm/i915/intel_display.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d67c7c498b34..674b86bbe7d7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14731,8 +14731,11 @@ void i830_disable_pipe(struct drm_i915_private 
> *dev_priv, enum pipe pipe)
>   DRM_DEBUG_KMS("disabling pipe %c due to force quirk\n",
> pipe_name(pipe));
>  
> - assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_A));
> - assert_planes_disabled(intel_get_crtc_for_pipe(dev_priv, PIPE_B));
> + WARN_ON(I915_READ(DSPCNTR(PLANE_A)) & DISPLAY_PLANE_ENABLE);
> + WARN_ON(I915_READ(DSPCNTR(PLANE_B)) & DISPLAY_PLANE_ENABLE);
> + WARN_ON(I915_READ(DSPCNTR(PLANE_C)) & DISPLAY_PLANE_ENABLE);
> + WARN_ON(I915_READ(CURCNTR(PIPE_A)) & CURSOR_MODE);
> + WARN_ON(I915_READ(CURCNTR(PIPE_B)) & CURSOR_MODE);
>  
>   I915_WRITE(PIPECONF(pipe), 0);
>   POSTING_READ(PIPECONF(pipe));
> -- 
> 2.13.6

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Pass crtc state to intel_pipe_{enable, disable}()

[Ville Syrjälä]

On Wed, Nov 29, 2017 at 03:45:41PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-29 15:37:32)
> > From: Ville Syrjälä 
> > 
> > Get rid of the crtc->config usages from within
> > intel_pipe_{enable,disable}() by passing in the appropriate
> > crtc state.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Looks mechanical, so I hope I didn't miss anything important,
> Reviewed-by: Chris Wilson 

Series pushed to dinq. Thanks for the review.

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disable DP audio for g4x

[Ville Syrjälä]

On Wed, Nov 29, 2017 at 03:22:33PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 29, 2017 at 04:43:01PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Apparently g4x doesn't support audio over DP. Bspec lists the
> > bit as "Reserved for Audio Output Enable", and empirical evidence
> > tells us that the bit won't stick. So stop trying to enable DP
> > audio on g4x.
> 
> Based on the display controller specified at
> https://01.org/sites/default/files/documentation/g45_vol_3_register_0_0_0.pdf
> 
> you are right...
> If I'm following the right spec feel free to use:
> 
> Reviewed-by: Rodrigo Vivi 
> 
> otherwise, please point me to the right place ;)

Your doc link looks correct for this case.

Amended with
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103989

and pushed the lot to dinq. Thanks for the review.

> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 957735c0b4c6..0e1a20e625e4 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1643,7 +1643,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> > pipe_config->has_pch_encoder = true;
> >  
> > pipe_config->has_drrs = false;
> > -   if (port == PORT_A)
> > +   if (IS_G4X(dev_priv) || port == PORT_A)
> > pipe_config->has_audio = false;
> > else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
> > pipe_config->has_audio = intel_dp->has_audio;
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH i-g-t] igt: Make dependency on libunwind mandatory

[Chris Wilson]

Quoting Arkadiusz Hiler (2017-12-01 13:19:54)
> With Android support gone there is not much reason for keeping libunwind
> dependency optional. This also deals (cheaply!) with ifdefs covering
> huge portions of code, removing a placement minefield.
> 
> Cc: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Signed-off-by: Arkadiusz Hiler 
> ---
>  configure.ac   | 12 ++--
>  lib/igt_core.c | 13 -
>  meson.build|  2 +-
>  3 files changed, 7 insertions(+), 20 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 84c6e646..6908f742 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -124,8 +124,10 @@ PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.82])
>  PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
>  PKG_CHECK_MODULES(KMOD, [libkmod])
>  PKG_CHECK_MODULES(PROCPS, [libprocps])
> +PKG_CHECK_MODULES(LIBUNWIND, [libunwind])
>  PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
> [have_valgrind=no])
>  
> +

Surplus '\n'.
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] tools/intel_reg: Add reading and writing registers through engine

[Chris Wilson]

Quoting Mika Kuoppala (2017-12-01 14:16:39)
> Add option to specify engine for register read/write operation.
> If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
> to write and read register using a batch targeted at that engine.
> 
> v2: no MI_NOOP after BBE (Chris)
> 
> Cc: Jani Nikula 
> Cc: Chris Wilson 
> CC: Joonas Lahtinen 
> Signed-off-by: Mika Kuoppala 
> ---
>  tools/intel_reg.c | 139 
> +-
>  1 file changed, 137 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
> index 00d2a4a1..ec45c2c9 100644
> --- a/tools/intel_reg.c
> +++ b/tools/intel_reg.c
> @@ -33,6 +33,7 @@
>  #include 
>  
>  #include "igt.h"
> +#include "igt_gt.h"
>  #include "intel_io.h"
>  #include "intel_chipset.h"
>  
> @@ -73,6 +74,12 @@ struct config {
>  
> /* register spec */
> char *specfile;
> +
> +   /* engine to use for lri (write) and srm (read) */
> +   char *engine;
> +   /* use secure batch */
> +   bool engine_secure_batch;
> +
> struct reg *regs;
> ssize_t regcount;
>  
> @@ -236,13 +243,116 @@ static void dump_decode(struct config *config, struct 
> reg *reg, uint32_t val)
> }
>  }
>  
> +static const struct intel_execution_engine *find_engine(const char *name)
> +{

Being modern, we should be using the "$class$instance" pattern (e.g. vcs1).

> +   const struct intel_execution_engine *e;
> +
> +   for (e = intel_execution_engines; e->name; e++) {
> +   if (!strcmp(e->name, name))
> +   return e;
> +   }
> +
> +   fprintf(stderr, "no such engine as '%s'\n", name);
> +
> +   fprintf(stderr, "valid engines:");
> +   for (e = intel_execution_engines; e->name; e++)
> +   fprintf(stderr, " %s", e->name);
> +
> +   fprintf(stderr, "\n");
> +
> +   exit(EXIT_FAILURE);
> +}
> +
> +static int register_srm(struct config *config, struct reg *reg,
> +   uint32_t *val_in)
> +{
> +   const int gen = intel_gen(intel_get_drm_devid(config->drm_fd));
> +   const bool r64b = gen >= 8;
> +   const uint32_t ctx = 0;
> +   struct drm_i915_gem_exec_object2 obj[2];
> +   struct drm_i915_gem_relocation_entry reloc[1];
> +   struct drm_i915_gem_execbuffer2 execbuf;
> +   uint32_t *batch, *r;
> +   const struct intel_execution_engine *engine;
> +   int i915, i;
> +   uint32_t val;
> +   i915 = config->drm_fd;
> +
> +   engine = find_engine(config->engine);
> +
> +   memset(obj, 0, sizeof(obj));
> +   obj[0].handle = gem_create(i915, 4096);
> +   obj[1].handle = gem_create(i915, 4096);
> +   obj[1].relocs_ptr = to_user_pointer(reloc);
> +   obj[1].relocation_count = 1;
> +
> +   batch = gem_mmap__cpu(i915, obj[1].handle, 0, 4096, PROT_WRITE);
> +   gem_set_domain(i915, obj[1].handle,
> +  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
> +
> +   i = 0;
> +   if (val_in) {
> +   batch[i++] = MI_NOOP;
> +   batch[i++] = MI_NOOP;
> +
> +   batch[i++] = MI_LOAD_REGISTER_IMM;
> +   batch[i++] = reg->addr;
> +   batch[i++] = *val_in;
> +   batch[i++] = MI_NOOP;
> +   }
> +
> +   batch[i++] = 0x24 << 23 | (1 + r64b); /* SRM */
> +   batch[i++] = reg->addr;
> +   reloc[0].target_handle = obj[0].handle;
> +   reloc[0].presumed_offset = obj[0].offset;
> +   reloc[0].offset = i * sizeof(uint32_t);
> +   reloc[0].delta = 0;
> +   reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
> +   reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
> +   batch[i++] = reloc[0].delta;
> +   if (r64b)
> +   batch[i++] = 0;
> +
> +   batch[i++] = MI_BATCH_BUFFER_END;
> +   munmap(batch, 4096);
> +
> +   memset(, 0, sizeof(execbuf));
> +   execbuf.buffers_ptr = to_user_pointer(obj);
> +   execbuf.buffer_count = 2;
> +   execbuf.flags = engine->exec_id;
> +
> +   if (config->engine_secure_batch) {
> +   execbuf.flags |= I915_EXEC_SECURE;
> +
> +   if (config->verbosity > 0)
> +   printf("%s: using priviledged (secure) batch\n",
privileged
Scrap saying (secure) to the users. It's blatantly not at this point if
we allow any old (root) user to write any old register.

> +  engine->name);
> +   }
> +
> +   execbuf.rsvd1 = ctx;
> +   gem_execbuf(i915, );
> +   gem_close(i915, obj[1].handle);
> +
> +   r = gem_mmap__cpu(i915, obj[0].handle, 0, 4096, PROT_READ);
> +   gem_set_domain(i915, obj[0].handle, I915_GEM_DOMAIN_CPU, 0);
> +
> +   val = r[0];
> +
> +   gem_close(i915, obj[0].handle);
> +
> +   return val;
> +}
> +
>  static int read_register(struct 

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 14:09:31)
> On Fri, 01 Dec 2017 13:36:06 +0100, Chris Wilson  
>  wrote:
> 
> > Quoting Michal Wajdeczko (2017-12-01 10:33:15)
> >> We currently have two module parameters that control GuC:
> >> "enable_guc_loading" and "enable_guc_submission". Whenever
> >> we need submission=1, we also need loading=1. We also need
> >> loading=1 when we want to want to load and verify the HuC.
> >>
> >> Lets combine above module parameters into one "enable_guc"
> >> modparam. New supported bit values are:
> >>
> >>  0=disable GuC (no GuC submission, no HuC)
> >>  1=enable GuC submission
> >>  2=enable HuC load
> >>
> >> Special value "-1" can be used to let driver decide what
> >> option should be enabled for given platform based on
> >> hardware/firmware availability or preference.
> >>
> >> Explicit enabling any of the GuC features makes GuC load
> >> a required step, fallback to non-GuC mode will not be
> >> supported.
> >>
> >> v2: Don't use -EIO
> >>
> >> Signed-off-by: Michal Wajdeczko 
> >> Cc: Chris Wilson 
> >> Cc: Joonas Lahtinen 
> >> Cc: Sagar Arun Kamble 
> >> Cc: Sujaritha Sundaresan 
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h|   5 +-
> >>  drivers/gpu/drm/i915/i915_params.c |  11 ++--
> >>  drivers/gpu/drm/i915/i915_params.h |   3 +-
> >>  drivers/gpu/drm/i915/intel_uc.c| 100  
> >> +
> >>  4 files changed, 65 insertions(+), 54 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h  
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 2c386c7..9162a60 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -3238,8 +3238,9 @@ intel_info(const struct drm_i915_private  
> >> *dev_priv)
> >>  #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
> >>
> >>  /* Having a GuC is not the same as using a GuC */
> >> -#define USES_GUC(dev_priv)  
> >> (i915_modparams.enable_guc_loading)
> >> -#define USES_GUC_SUBMISSION(dev_priv)   
> >> (i915_modparams.enable_guc_submission)
> >> +#define USES_GUC(dev_priv) (!!(i915_modparams.enable_guc >  
> >> 0))
> >> +#define USES_GUC_SUBMISSION(dev_priv)  (!!(i915_modparams.enable_guc &  
> >> 1))
> >> +#define USES_HUC(dev_priv) (!!(i915_modparams.enable_guc &  
> >> 2))
> >
> > * channelling Joonas
> >
> > Please use a magic name for each bit and so
> >
> > #define USE_GUC_SUBMISSION_BIT 0
> 
> I was considering that, but then I decided to follow existing code
> (see USES_PPGTT* and enable_ppgtt where we use plain numbers only)

enable_ppgtt is on my list to kill. If vgpu didn't conspire against us,
it would be simpler!

> But if we want to start using magic values, then these values should
> be defined in i915_params.h and rather in this way:
> 
> #define ENABLE_GUC_SUBMISSION   BIT(0)
> #define ENABLE_GUC_HUC_LOAD BIT(1)
>  ^^
>  this part matches modparam name

Reasonable.

> > #define USES_GUC_SUBMISSION (!!(i915_modparams.enable_guc &  
> > BIT(USE_GUC_SUBMISSION_BIT)))
> >
> > Gah, that's so ugly.
> >
> > or
> >
> > static inline bool intel_use_guc_submission(void)
> 
> "intel_" ? maybe correct prefix should be "i915_" ?
> 
> > {
> >   return i915_modparams.enable_guc & BIT(USE_GUC_SUBMISSION_BIT);
> > }
> 
> I assume that above will still be wrapped inside macro
> 
> #define USES_GUC_SUBMISSION(dev_priv) intel_uses_guc_submission()

Why? The compiler will dce functions just as well as macros; the age of
the macro is long past, so the question is just a matter of how much is
it worth continuing to cargo-cult a pattern that is long past requirement.

Even its placement in i915_drv.h is up for debate. Maintaining the
status quo is a valid argument, we just need a good reason to switch
patterns (splitting up X-thousand lines of code into manageable chunks
with consistent forward-facing interfaces is one such :).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for tools/intel_reg: Add reading and writing registers through engine

[Patchwork]

== Series Details ==

Series: tools/intel_reg: Add reading and writing registers through engine
URL   : https://patchwork.freedesktop.org/series/34755/
State : failure

== Summary ==

IGT patchset build failed on latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

make  all-recursive
Making all in lib
make  all-recursive
Making all in .
Making all in tests
make[4]: Nothing to be done for 'all'.
Making all in man
make[2]: Nothing to be done for 'all'.
Making all in tools
Making all in null_state_gen
make[3]: Nothing to be done for 'all'.
Making all in registers
make[3]: Nothing to be done for 'all'.
  CCLD intel_aubdump.la
  CCLD intel_audio_dump
  CC   intel_reg.o
intel_reg.c: In function ‘register_srm’:
intel_reg.c:269:54: error: ‘struct config’ has no member named ‘drm_fd’
  const int gen = intel_gen(intel_get_drm_devid(config->drm_fd));
  ^~
intel_reg.c:279:15: error: ‘struct config’ has no member named ‘drm_fd’
  i915 = config->drm_fd;
   ^~
Makefile:1145: recipe for target 'intel_reg.o' failed
make[3]: *** [intel_reg.o] Error 1
Makefile:1209: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
Makefile:531: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:463: recipe for target 'all' failed
make: *** [all] Error 2

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

[Intel-gfx] [PATCH igt] tools/intel_reg: Add reading and writing registers through engine

[Mika Kuoppala]

Add option to specify engine for register read/write operation.
If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
to write and read register using a batch targeted at that engine.

v2: no MI_NOOP after BBE (Chris)

Cc: Jani Nikula 
Cc: Chris Wilson 
CC: Joonas Lahtinen 
Signed-off-by: Mika Kuoppala 
---
 tools/intel_reg.c | 139 +-
 1 file changed, 137 insertions(+), 2 deletions(-)

diff --git a/tools/intel_reg.c b/tools/intel_reg.c
index 00d2a4a1..ec45c2c9 100644
--- a/tools/intel_reg.c
+++ b/tools/intel_reg.c
@@ -33,6 +33,7 @@
 #include 
 
 #include "igt.h"
+#include "igt_gt.h"
 #include "intel_io.h"
 #include "intel_chipset.h"
 
@@ -73,6 +74,12 @@ struct config {
 
/* register spec */
char *specfile;
+
+   /* engine to use for lri (write) and srm (read) */
+   char *engine;
+   /* use secure batch */
+   bool engine_secure_batch;
+
struct reg *regs;
ssize_t regcount;
 
@@ -236,13 +243,116 @@ static void dump_decode(struct config *config, struct 
reg *reg, uint32_t val)
}
 }
 
+static const struct intel_execution_engine *find_engine(const char *name)
+{
+   const struct intel_execution_engine *e;
+
+   for (e = intel_execution_engines; e->name; e++) {
+   if (!strcmp(e->name, name))
+   return e;
+   }
+
+   fprintf(stderr, "no such engine as '%s'\n", name);
+
+   fprintf(stderr, "valid engines:");
+   for (e = intel_execution_engines; e->name; e++)
+   fprintf(stderr, " %s", e->name);
+
+   fprintf(stderr, "\n");
+
+   exit(EXIT_FAILURE);
+}
+
+static int register_srm(struct config *config, struct reg *reg,
+   uint32_t *val_in)
+{
+   const int gen = intel_gen(intel_get_drm_devid(config->drm_fd));
+   const bool r64b = gen >= 8;
+   const uint32_t ctx = 0;
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc[1];
+   struct drm_i915_gem_execbuffer2 execbuf;
+   uint32_t *batch, *r;
+   const struct intel_execution_engine *engine;
+   int i915, i;
+   uint32_t val;
+   i915 = config->drm_fd;
+
+   engine = find_engine(config->engine);
+
+   memset(obj, 0, sizeof(obj));
+   obj[0].handle = gem_create(i915, 4096);
+   obj[1].handle = gem_create(i915, 4096);
+   obj[1].relocs_ptr = to_user_pointer(reloc);
+   obj[1].relocation_count = 1;
+
+   batch = gem_mmap__cpu(i915, obj[1].handle, 0, 4096, PROT_WRITE);
+   gem_set_domain(i915, obj[1].handle,
+  I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
+
+   i = 0;
+   if (val_in) {
+   batch[i++] = MI_NOOP;
+   batch[i++] = MI_NOOP;
+
+   batch[i++] = MI_LOAD_REGISTER_IMM;
+   batch[i++] = reg->addr;
+   batch[i++] = *val_in;
+   batch[i++] = MI_NOOP;
+   }
+
+   batch[i++] = 0x24 << 23 | (1 + r64b); /* SRM */
+   batch[i++] = reg->addr;
+   reloc[0].target_handle = obj[0].handle;
+   reloc[0].presumed_offset = obj[0].offset;
+   reloc[0].offset = i * sizeof(uint32_t);
+   reloc[0].delta = 0;
+   reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
+   reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
+   batch[i++] = reloc[0].delta;
+   if (r64b)
+   batch[i++] = 0;
+
+   batch[i++] = MI_BATCH_BUFFER_END;
+   munmap(batch, 4096);
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = to_user_pointer(obj);
+   execbuf.buffer_count = 2;
+   execbuf.flags = engine->exec_id;
+
+   if (config->engine_secure_batch) {
+   execbuf.flags |= I915_EXEC_SECURE;
+
+   if (config->verbosity > 0)
+   printf("%s: using priviledged (secure) batch\n",
+  engine->name);
+   }
+
+   execbuf.rsvd1 = ctx;
+   gem_execbuf(i915, );
+   gem_close(i915, obj[1].handle);
+
+   r = gem_mmap__cpu(i915, obj[0].handle, 0, 4096, PROT_READ);
+   gem_set_domain(i915, obj[0].handle, I915_GEM_DOMAIN_CPU, 0);
+
+   val = r[0];
+
+   gem_close(i915, obj[0].handle);
+
+   return val;
+}
+
 static int read_register(struct config *config, struct reg *reg, uint32_t 
*valp)
 {
uint32_t val = 0;
 
switch (reg->port_desc.port) {
case PORT_MMIO:
-   val = INREG(reg->mmio_offset + reg->addr);
+   if (config->engine)
+   val = register_srm(config, reg, NULL);
+   else
+   val = INREG(reg->mmio_offset + reg->addr);
break;
case PORT_PORTIO_VGA:
iopl(3);
@@ -299,7 +409,15 @@ static int write_register(struct config *config, struct 
reg *reg, 

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter  wrote:
> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>> Sean,
>>
>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>> drm helpers and all interested display drivers to use them.
>>
>> This Design will make the extending of hdcp easy for other display drivers
>> based on DRM.
>>
>> We can have the required drm_hdcp_shim type of implementation at drm
>> structure which will be called for platform specific operations (like
>> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
>
> I discussed this exact question with Sean Paul, and apparently the
> hardware designs are too diverse to make shared code much useful. Some hw
> has the entire hdcp flow in hw, some almost nothing (like i915 here), and
> then there's everything in between.
>
> Given that Sean has seen a lot more hdcp implementations than we have,
> that we right now have no other implementation than i915 in upstream and
> than wrong abstraction is much harder to fix than no abstraction I'm going
> with Sean's approach of "no generic abstraction" here. Personally I'm not
> even fully sold on the shim abstraction, but I think by that one is
> fine.
>

[html fail on the first response, resending in plain text]

I think there's some sharing potential between exynos and i915, but
the rockchip stuff is completely different. Even exynos differs in
that each step of the authentication process is interrupt driven
(iirc). I just don't see a pattern worth abstracting atm. We might be
able to share the enable/disable/check song & dance, but let's not
worry about abstraction until we have 2 implementations.


>> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
>> > This patch adds the framework required to add HDCP support to intel
>> > connectors. It implements Aksv loading from fuse, and parts 1/2/3
>> > of the HDCP authentication scheme.
>> >
>> > Note that without shim implementations, this does not actually implement
>> > HDCP. That will come in subsequent patches.
>> >
>> > Signed-off-by: Sean Paul 
>> > ---
>> >   drivers/gpu/drm/i915/Makefile   |   1 +
>> >   drivers/gpu/drm/i915/i915_reg.h |  83 +
>> >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
>> >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
>> >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
>> >   drivers/gpu/drm/i915/intel_hdcp.c   | 636 
>> > 
>> >   6 files changed, 811 insertions(+), 2 deletions(-)
>> >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
>> >
>> > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> > index 6c3b0481ef82..1e745508e437 100644
>> > --- a/drivers/gpu/drm/i915/Makefile
>> > +++ b/drivers/gpu/drm/i915/Makefile
>> > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
>> >   intel_fbc.o \
>> >   intel_fifo_underrun.o \
>> >   intel_frontbuffer.o \
>> > + intel_hdcp.o \
>> >   intel_hotplug.o \
>> >   intel_modes.o \
>> >   intel_overlay.o \
>> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> > b/drivers/gpu/drm/i915/i915_reg.h
>> > index 68a58cce6ab1..43128030171d 100644
>> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > @@ -7991,6 +7991,7 @@ enum {
>> >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
>> >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
>> >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
>> > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
>> >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
>> >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
>> >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
>> > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
>> >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 + 
>> > SKL_PG1)
>> >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
>> > +
>> > +/* HDCP Key Registers */
>> > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
>> > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
>> > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
>> > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
>> > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
>> > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
>> > +#define  SKL_HDCP_FUSE_DONEBIT(5)
>> > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
>> > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
>> > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
>> > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
>> > +
>> > +/* HDCP Repeater Registers */
>> > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
>> > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
>> > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
>> > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
>> > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
>> > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
>> > +#define  SKL_HDCP_DDIE_REP_PRESENT BIT(25)

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

On Fri, Dec 1, 2017 at 3:36 AM, Ramalingam C  wrote:
>
>
>
> On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote:
>>
>> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>>>
>>> Sean,
>>>
>>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>>> drm helpers and all interested display drivers to use them.
>>>
>>> This Design will make the extending of hdcp easy for other display drivers
>>> based on DRM.
>>>
>>> We can have the required drm_hdcp_shim type of implementation at drm
>>> structure which will be called for platform specific operations (like
>>> prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
>>
>> I discussed this exact question with Sean Paul, and apparently the
>> hardware designs are too diverse to make shared code much useful. Some hw
>> has the entire hdcp flow in hw, some almost nothing (like i915 here), and
>> then there's everything in between.
>
> Just trying to understand the other extreme of HW (full)support for HDCP here.
>
> When you say everything about HDCP is implemented in HW, do you mean that 
> whole protocol comm on HDCP link also driven by HW?
>

Yep. Check out the rockchip implementation in our 4.4 tree.

Sean


>
> --Ram
>
>>
>> Given that Sean has seen a lot more hdcp implementations than we have,
>> that we right now have no other implementation than i915 in upstream and
>> than wrong abstraction is much harder to fix than no abstraction I'm going
>> with Sean's approach of "no generic abstraction" here. Personally I'm not
>> even fully sold on the shim abstraction, but I think by that one is
>> fine.
>>
>>> On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:

 This patch adds the framework required to add HDCP support to intel
 connectors. It implements Aksv loading from fuse, and parts 1/2/3
 of the HDCP authentication scheme.

 Note that without shim implementations, this does not actually implement
 HDCP. That will come in subsequent patches.

 Signed-off-by: Sean Paul 
 ---
drivers/gpu/drm/i915/Makefile   |   1 +
drivers/gpu/drm/i915/i915_reg.h |  83 +
drivers/gpu/drm/i915/intel_atomic.c |  26 +-
drivers/gpu/drm/i915/intel_ddi.c|  14 +
drivers/gpu/drm/i915/intel_drv.h|  53 +++
drivers/gpu/drm/i915/intel_hdcp.c   | 636 
 
6 files changed, 811 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c

 diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
 index 6c3b0481ef82..1e745508e437 100644
 --- a/drivers/gpu/drm/i915/Makefile
 +++ b/drivers/gpu/drm/i915/Makefile
 @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
   intel_fbc.o \
   intel_fifo_underrun.o \
   intel_frontbuffer.o \
 + intel_hdcp.o \
   intel_hotplug.o \
   intel_modes.o \
   intel_overlay.o \
 diff --git a/drivers/gpu/drm/i915/i915_reg.h 
 b/drivers/gpu/drm/i915/i915_reg.h
 index 68a58cce6ab1..43128030171d 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -7991,6 +7991,7 @@ enum {
#define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
#define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT 16
#define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT 24
 +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
#define   SKL_PCODE_CDCLK_CONTROL0x7
#define SKL_CDCLK_PREPARE_FOR_CHANGE 0x3
#define SKL_CDCLK_READY_FOR_CHANGE   0x1
 @@ -8285,6 +8286,88 @@ enum skl_power_gate {
#define  SKL_PW_TO_PG(pw)((pw) - SKL_DISP_PW_1 + 
 SKL_PG1)
#define  SKL_FUSE_PG_DIST_STATUS(pg) (1 << (27 - (pg)))
 +
 +/* HDCP Key Registers */
 +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
 +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
 +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
 +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
 +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
 +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
 +#define  SKL_HDCP_FUSE_DONEBIT(5)
 +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
 +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
 +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
 +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
 +
 +/* HDCP Repeater Registers */
 +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
 +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
 +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
 +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
 +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
 +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
 +#define  

Re: [Intel-gfx] [RFC PATCH 3/6] drm/i915: Add HDCP framework + base implementation

[Sean Paul]

On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter  wrote:

> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> > Sean,
> >
> > IMHO, it will good if we can have all generic hdcp1.4 authentication
> flow in
> > drm helpers and all interested display drivers to use them.
> >
> > This Design will make the extending of hdcp easy for other display
> drivers
> > based on DRM.
> >
> > We can have the required drm_hdcp_shim type of implementation at drm
> > structure which will be called for platform specific operations (like
> > prepare an, send aksv, program bksv/repeater/r0 and verify sha1 etc)?
>
> I discussed this exact question with Sean Paul, and apparently the
> hardware designs are too diverse to make shared code much useful. Some hw
> has the entire hdcp flow in hw, some almost nothing (like i915 here), and
> then there's everything in between.
>
> Given that Sean has seen a lot more hdcp implementations than we have,
> that we right now have no other implementation than i915 in upstream and
> than wrong abstraction is much harder to fix than no abstraction I'm going
> with Sean's approach of "no generic abstraction" here. Personally I'm not
> even fully sold on the shim abstraction, but I think by that one is
> fine.
>

I think there's some sharing potential between exynos and i915, but the
rockchip stuff is completely different. Even exynos differs in that each
step of the authentication process is interrupt driven (iirc). I just don't
see a pattern worth abstracting atm. We might be able to share the
enable/disable/check song & dance, but let's not worry about abstraction
until we have 2 implementations.



> > On Thursday 30 November 2017 08:38 AM, Sean Paul wrote:
> > > This patch adds the framework required to add HDCP support to intel
> > > connectors. It implements Aksv loading from fuse, and parts 1/2/3
> > > of the HDCP authentication scheme.
> > >
> > > Note that without shim implementations, this does not actually
> implement
> > > HDCP. That will come in subsequent patches.
> > >
> > > Signed-off-by: Sean Paul 
> > > ---
> > >   drivers/gpu/drm/i915/Makefile   |   1 +
> > >   drivers/gpu/drm/i915/i915_reg.h |  83 +
> > >   drivers/gpu/drm/i915/intel_atomic.c |  26 +-
> > >   drivers/gpu/drm/i915/intel_ddi.c|  14 +
> > >   drivers/gpu/drm/i915/intel_drv.h|  53 +++
> > >   drivers/gpu/drm/i915/intel_hdcp.c   | 636
> 
> > >   6 files changed, 811 insertions(+), 2 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/i915/intel_hdcp.c
> > >
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/
> Makefile
> > > index 6c3b0481ef82..1e745508e437 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -87,6 +87,7 @@ i915-y += intel_audio.o \
> > >   intel_fbc.o \
> > >   intel_fifo_underrun.o \
> > >   intel_frontbuffer.o \
> > > + intel_hdcp.o \
> > >   intel_hotplug.o \
> > >   intel_modes.o \
> > >   intel_overlay.o \
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > > index 68a58cce6ab1..43128030171d 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7991,6 +7991,7 @@ enum {
> > >   #define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT  8
> > >   #define GEN9_MEM_LATENCY_LEVEL_2_6_SHIFT  16
> > >   #define GEN9_MEM_LATENCY_LEVEL_3_7_SHIFT  24
> > > +#define   SKL_PCODE_LOAD_HDCP_KEYS 0x5
> > >   #define   SKL_PCODE_CDCLK_CONTROL 0x7
> > >   #define SKL_CDCLK_PREPARE_FOR_CHANGE  0x3
> > >   #define SKL_CDCLK_READY_FOR_CHANGE0x1
> > > @@ -8285,6 +8286,88 @@ enum skl_power_gate {
> > >   #define  SKL_PW_TO_PG(pw) ((pw) - SKL_DISP_PW_1 +
> SKL_PG1)
> > >   #define  SKL_FUSE_PG_DIST_STATUS(pg)  (1 << (27 - (pg)))
> > > +
> > > +/* HDCP Key Registers */
> > > +#define SKL_HDCP_KEY_CONF  _MMIO(0x66c00)
> > > +#define SKL_HDCP_AKSV_SEND_TRIGGER BIT(31)
> > > +#define  SKL_HDCP_CLEAR_KEYS_TRIGGER   BIT(30)
> > > +#define SKL_HDCP_KEY_STATUS_MMIO(0x66c04)
> > > +#define  SKL_HDCP_FUSE_IN_PROGRESS BIT(7)
> > > +#define  SKL_HDCP_FUSE_ERROR   BIT(6)
> > > +#define  SKL_HDCP_FUSE_DONEBIT(5)
> > > +#define  SKL_HDCP_KEY_LOAD_STATUS  BIT(1)
> > > +#define  SKL_HDCP_KEY_LOAD_DONEBIT(0)
> > > +#define SKL_HDCP_AKSV_LO   _MMIO(0x66c10)
> > > +#define SKL_HDCP_AKSV_HI   _MMIO(0x66c14)
> > > +
> > > +/* HDCP Repeater Registers */
> > > +#define SKL_HDCP_REP_CTL   _MMIO(0x66d00)
> > > +#define  SKL_HDCP_DDIB_REP_PRESENT BIT(30)
> > > +#define  SKL_HDCP_DDIA_REP_PRESENT BIT(29)
> > > +#define  SKL_HDCP_DDIC_REP_PRESENT BIT(28)
> > > +#define  SKL_HDCP_DDID_REP_PRESENT BIT(27)
> > > +#define  SKL_HDCP_DDIF_REP_PRESENT BIT(26)
> > > +#define  

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Michal Wajdeczko]

On Fri, 01 Dec 2017 13:36:06 +0100, Chris Wilson  
 wrote:



Quoting Michal Wajdeczko (2017-12-01 10:33:15)

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.

Lets combine above module parameters into one "enable_guc"
modparam. New supported bit values are:

 0=disable GuC (no GuC submission, no HuC)
 1=enable GuC submission
 2=enable HuC load

Special value "-1" can be used to let driver decide what
option should be enabled for given platform based on
hardware/firmware availability or preference.

Explicit enabling any of the GuC features makes GuC load
a required step, fallback to non-GuC mode will not be
supported.

v2: Don't use -EIO

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
---
 drivers/gpu/drm/i915/i915_drv.h|   5 +-
 drivers/gpu/drm/i915/i915_params.c |  11 ++--
 drivers/gpu/drm/i915/i915_params.h |   3 +-
 drivers/gpu/drm/i915/intel_uc.c| 100  
+

 4 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h  
b/drivers/gpu/drm/i915/i915_drv.h

index 2c386c7..9162a60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3238,8 +3238,9 @@ intel_info(const struct drm_i915_private  
*dev_priv)

 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))

 /* Having a GuC is not the same as using a GuC */
-#define USES_GUC(dev_priv)  
(i915_modparams.enable_guc_loading)
-#define USES_GUC_SUBMISSION(dev_priv)   
(i915_modparams.enable_guc_submission)
+#define USES_GUC(dev_priv) (!!(i915_modparams.enable_guc >  
0))
+#define USES_GUC_SUBMISSION(dev_priv)  (!!(i915_modparams.enable_guc &  
1))
+#define USES_HUC(dev_priv) (!!(i915_modparams.enable_guc &  
2))


* channelling Joonas

Please use a magic name for each bit and so

#define USE_GUC_SUBMISSION_BIT 0


I was considering that, but then I decided to follow existing code
(see USES_PPGTT* and enable_ppgtt where we use plain numbers only)

But if we want to start using magic values, then these values should
be defined in i915_params.h and rather in this way:

#define ENABLE_GUC_SUBMISSION   BIT(0)
#define ENABLE_GUC_HUC_LOAD BIT(1)
^^
this part matches modparam name

#define USES_GUC_SUBMISSION (!!(i915_modparams.enable_guc &  
BIT(USE_GUC_SUBMISSION_BIT)))


Gah, that's so ugly.

or

static inline bool intel_use_guc_submission(void)


"intel_" ? maybe correct prefix should be "i915_" ?


{
return i915_modparams.enable_guc & BIT(USE_GUC_SUBMISSION_BIT);
}


I assume that above will still be wrapped inside macro

#define USES_GUC_SUBMISSION(dev_priv) intel_uses_guc_submission()



which at least stops being so shouty.
-Chris

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Sleep and retry a GPU reset if at first we don't succeed (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed 
(rev2)
URL   : https://patchwork.freedesktop.org/series/34747/
State : success

== Summary ==

Test drv_selftest:
Subgroup mock_sanitycheck:
pass   -> DMESG-WARN (shard-snb) fdo#102707
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-hsw) fdo#102254
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
skip   -> PASS   (shard-snb) fdo#101623
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-wc:
skip   -> PASS   (shard-snb) fdo#103167
Test kms_plane:
Subgroup plane-panning-top-left-pipe-a-planes:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-legacy:
skip   -> PASS   (shard-snb)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup blocking-wf_vblank:
fail   -> PASS   (shard-snb)

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

shard-hswtotal:2624 pass:1516 dwarn:1   dfail:0   fail:11  skip:1094 
time:8900s
shard-snbtotal:2661 pass:1307 dwarn:2   dfail:0   fail:11  skip:1340 
time:8006s
Blacklisted hosts:
shard-kbltotal:2663 pass:1793 dwarn:13  dfail:1   fail:24  skip:832 
time:10909s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Make dependency on libunwind mandatory

[Patchwork]

== Series Details ==

Series: igt: Make dependency on libunwind mandatory
URL   : https://patchwork.freedesktop.org/series/34752/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3429
f0e4ac384907 drm-tip: 2017y-12m-01d-13h-14m-22s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test gem_exec_reloc:
Subgroup basic-gtt-active:
fail   -> PASS   (fi-gdg-551) fdo#102582 +3
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:387s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:525s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:517s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:494s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:482s
fi-elk-e7500 total:224  pass:162  dwarn:16  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:269s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:382s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:260s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:398s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:448s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:493s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:534s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:530s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:599s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:547s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:499s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:550s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:421s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:614s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] igt: Make dependency on libunwind mandatory

[Chris Wilson]

Quoting Arkadiusz Hiler (2017-12-01 13:19:54)
> With Android support gone there is not much reason for keeping libunwind
> dependency optional. This also deals (cheaply!) with ifdefs covering
> huge portions of code, removing a placement minefield.

Could also force building with frame-pointers? I'm wonder if that would
help with the less-than-useful stacktraces I get...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt/gem_ctx_isolation: Check isolation of registers between contexts (rev9)

[Patchwork]

== Series Details ==

Series: igt/gem_ctx_isolation: Check isolation of registers between contexts 
(rev9)
URL   : https://patchwork.freedesktop.org/series/32531/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
skip   -> PASS   (shard-snb) fdo#101623 +1
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-wc:
skip   -> PASS   (shard-snb) fdo#103167
Test drv_selftest:
Subgroup mock_sanitycheck:
pass   -> DMESG-WARN (shard-snb) fdo#102707 +1
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-legacy:
skip   -> PASS   (shard-snb)
Test kms_flip:
Subgroup blocking-wf_vblank:
fail   -> PASS   (shard-snb)
Test kms_fbcon_fbt:
Subgroup fbc-suspend:
pass   -> SKIP   (shard-hsw)
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-top-edge:
pass   -> INCOMPLETE (shard-hsw)
Test kms_plane:
Subgroup plane-panning-top-left-pipe-a-planes:
skip   -> PASS   (shard-snb)

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

shard-hswtotal:2608 pass:1484 dwarn:1   dfail:0   fail:9   skip:1112 
time:8900s
shard-snbtotal:2674 pass:1300 dwarn:3   dfail:0   fail:13  skip:1357 
time:7701s
Blacklisted hosts:
shard-apltotal:2698 pass:1715 dwarn:1   dfail:0   fail:26  skip:956 
time:14014s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Sleep and retry a GPU reset if at first we don't succeed

[Chris Wilson]

Quoting Mika Kuoppala (2017-12-01 13:20:29)
> Chris Wilson  writes:
> 
> > As we declare the GPU wedged if the reset fails, such a failure is quite
> > terminal. Before taking that drastic action, let's sleep first and try
> > active, in the hope that the hardware has quietened down and is then
> > able to reset. After a few such attempts, it is fair to say that the HW
> > is truly wedged.
> >
> > v2: Always print the failure message now, we precheck whether resets are
> > disabled.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=104007
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Joonas Lahtinen 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 20 +++-
> >  1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index e0f053f9c186..7faf20aff25a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1877,7 +1877,9 @@ void i915_reset(struct drm_i915_private *i915, 
> > unsigned int flags)
> >  {
> >   struct i915_gpu_error *error = >gpu_error;
> >   int ret;
> > + int i;
> >  
> > + might_sleep();
> >   lockdep_assert_held(>drm.struct_mutex);
> >   GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
> >  
> > @@ -1900,12 +1902,20 @@ void i915_reset(struct drm_i915_private *i915, 
> > unsigned int flags)
> >   goto error;
> >   }
> >  
> > - ret = intel_gpu_reset(i915, ALL_ENGINES);
> > + if (!intel_has_gpu_reset(i915)) {
> > + DRM_DEBUG_DRIVER("GPU reset disabled\n");
> > + goto error;
> > + }
> > +
> > + for (i = 0; i < 3; i++) {
> > + ret = intel_gpu_reset(i915, ALL_ENGINES);
> > + if (ret == 0)
> > + break;
> > +
> > + msleep(100);
> 
> Seems reasonable to try few times and pause between defibrillate
> attempts instead of throwing dirt on top of coffin right
> off the bat.
> 
> Also I have been pondering that should we add a minicheck
> to intel_gpu_reset to poke that the gpu is really there.
> Like doing few nops in (render)ringbuffer and see if head
> moves before declaring it as a reset success?

That's kind of what the recovery tests. It's tricky to do so because we
would have to unwind hw state after the trial, plus we may not see a
problem until it tries to do something like write to HWSP.

> Not that we would not see it in init right after but just
> to have more precise location of failure instead of
> initing a dead gpu.

It's dead, Jim. Either way, the location should be in the post-mortem
error state capture before the first attempt to reset. As always, if
that isn't enough to diagnose the problem, we need to work harder to get
the right information into that dump. Tricky.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Call intel_opregion_notify_encoder in intel_sanitize_encoder

[Ville Syrjälä]

On Thu, Nov 30, 2017 at 04:18:53PM +0100, Maarten Lankhorst wrote:
> Normally this is called on a modeset, but the call is missing when
> we inherit the mode from the BIOS, so make sure it's called somewhere
> in hardware readout.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index cd60b4d5cd9d..26edae07e006 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14843,6 +14843,8 @@ static void intel_sanitize_encoder(struct 
> intel_encoder *encoder)
>  
>   connector->base.dpms = DRM_MODE_DPMS_OFF;
>   connector->base.encoder = NULL;
> + } else if (connector) {
> + intel_opregion_notify_encoder(encoder, true);


We should probably also do intel_opregion_notify_encoder(encoder, false)
when intel_sanitize_encoder() disables the encoder.

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

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove unsafe i915.enable_rc6 (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove unsafe i915.enable_rc6 (rev4)
URL   : https://patchwork.freedesktop.org/series/21884/
State : success

== Summary ==

Test pm_rc6_residency:
Subgroup rc6p-accuracy:
skip   -> PASS   (shard-snb)
Test kms_flip:
Subgroup blocking-wf_vblank:
fail   -> PASS   (shard-snb)
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
skip   -> PASS   (shard-snb) fdo#101623
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-wc:
skip   -> PASS   (shard-snb) fdo#103167
Test kms_plane:
Subgroup plane-panning-top-left-pipe-a-planes:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-legacy:
skip   -> PASS   (shard-snb)
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375

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

shard-hswtotal:2652 pass:1530 dwarn:1   dfail:0   fail:10  skip:1109 
time:8908s
shard-snbtotal:2661 pass:1309 dwarn:1   dfail:0   fail:11  skip:1339 
time:7982s
Blacklisted hosts:
shard-apltotal:2663 pass:1690 dwarn:1   dfail:1   fail:22  skip:949 
time:13722s
shard-kbltotal:2663 pass:1804 dwarn:1   dfail:0   fail:24  skip:834 
time:10956s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Sleep and retry a GPU reset if at first we don't succeed

[Mika Kuoppala]

Chris Wilson  writes:

> As we declare the GPU wedged if the reset fails, such a failure is quite
> terminal. Before taking that drastic action, let's sleep first and try
> active, in the hope that the hardware has quietened down and is then
> able to reset. After a few such attempts, it is fair to say that the HW
> is truly wedged.
>
> v2: Always print the failure message now, we precheck whether resets are
> disabled.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104007
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e0f053f9c186..7faf20aff25a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1877,7 +1877,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
> int flags)
>  {
>   struct i915_gpu_error *error = >gpu_error;
>   int ret;
> + int i;
>  
> + might_sleep();
>   lockdep_assert_held(>drm.struct_mutex);
>   GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
>  
> @@ -1900,12 +1902,20 @@ void i915_reset(struct drm_i915_private *i915, 
> unsigned int flags)
>   goto error;
>   }
>  
> - ret = intel_gpu_reset(i915, ALL_ENGINES);
> + if (!intel_has_gpu_reset(i915)) {
> + DRM_DEBUG_DRIVER("GPU reset disabled\n");
> + goto error;
> + }
> +
> + for (i = 0; i < 3; i++) {
> + ret = intel_gpu_reset(i915, ALL_ENGINES);
> + if (ret == 0)
> + break;
> +
> + msleep(100);

Seems reasonable to try few times and pause between defibrillate
attempts instead of throwing dirt on top of coffin right
off the bat.

Also I have been pondering that should we add a minicheck
to intel_gpu_reset to poke that the gpu is really there.
Like doing few nops in (render)ringbuffer and see if head
moves before declaring it as a reset success?

Not that we would not see it in init right after but just
to have more precise location of failure instead of
initing a dead gpu.

Reviewed-by: Mika Kuoppala 

-Mika


> + }
>   if (ret) {
> - if (ret != -ENODEV)
> - DRM_ERROR("Failed to reset chip: %i\n", ret);
> - else
> - DRM_DEBUG_DRIVER("GPU reset disabled\n");
> + dev_err(i915->drm.dev, "Failed to reset chip\n");
>   goto error;
>   }
>  
> -- 
> 2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] igt: Make dependency on libunwind mandatory

[Arkadiusz Hiler]

With Android support gone there is not much reason for keeping libunwind
dependency optional. This also deals (cheaply!) with ifdefs covering
huge portions of code, removing a placement minefield.

Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Signed-off-by: Arkadiusz Hiler 
---
 configure.ac   | 12 ++--
 lib/igt_core.c | 13 -
 meson.build|  2 +-
 3 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/configure.ac b/configure.ac
index 84c6e646..6908f742 100644
--- a/configure.ac
+++ b/configure.ac
@@ -124,8 +124,10 @@ PKG_CHECK_MODULES(DRM, [libdrm >= 2.4.82])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
 PKG_CHECK_MODULES(KMOD, [libkmod])
 PKG_CHECK_MODULES(PROCPS, [libprocps])
+PKG_CHECK_MODULES(LIBUNWIND, [libunwind])
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 
+
 if test x$have_valgrind = xyes; then
AC_DEFINE(HAVE_VALGRIND, 1, [Enable valgrind annotation support.])
 fi
@@ -330,15 +332,6 @@ AM_CONDITIONAL(BUILD_SHADER_DEBUGGER, [test 
"x$BUILD_SHADER_DEBUGGER" != xno])
 AS_IF([test "x$BUILD_SHADER_DEBUGGER" != xno],
   [enable_debugger=yes], [enable_debugger=no])
 
-AC_ARG_WITH(libunwind,
-   AS_HELP_STRING([--without-libunwind],
-  [Build tests without libunwind support]),
-   [], [with_libunwind=yes])
-if test "x$with_libunwind" = xyes; then
-   PKG_CHECK_MODULES(LIBUNWIND, libunwind, AC_DEFINE(HAVE_LIBUNWIND, 1, 
[libunwind support]),
- AC_MSG_ERROR([libunwind not found. Use 
--without-libunwind to disable libunwind support.]))
-fi
-
 # enable debug symbols
 AC_ARG_ENABLE(debug,
  AS_HELP_STRING([--disable-debug],
@@ -434,7 +427,6 @@ echo "   Build tests: ${BUILD_TESTS}"
 echo "   Chamelium tests: ${enable_chamelium}"
 echo "   Audio tests: ${enable_audio}"
 echo "   Compile prime tests: ${NOUVEAU}"
-echo "   Print stack traces : ${with_libunwind}"
 echo "   Debug flags: ${DEBUG_CFLAGS}"
 echo ""
 echo " • Tools:"
diff --git a/lib/igt_core.c b/lib/igt_core.c
index de9269b0..03fa6e4e 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -71,6 +71,9 @@
 #include "igt_sysfs.h"
 #include "igt_rc.h"
 
+#define UNW_LOCAL_ONLY
+#include 
+
 #ifdef HAVE_LIBGEN_H
 #include/* for basename() on Solaris */
 #endif
@@ -1173,10 +1176,6 @@ static void write_stderr(const char *str)
__write_stderr(str, strlen(str));
 }
 
-#ifdef HAVE_LIBUNWIND
-#define UNW_LOCAL_ONLY
-#include 
-
 static void print_backtrace(void)
 {
unw_cursor_t cursor;
@@ -1371,7 +1370,6 @@ static void print_backtrace_sig_safe(void)
 
}
 }
-#endif
 
 void __igt_fail_assert(const char *domain, const char *file, const int line,
   const char *func, const char *assertion,
@@ -1394,9 +1392,7 @@ void __igt_fail_assert(const char *domain, const char 
*file, const int line,
va_end(args);
}
 
-#ifdef HAVE_LIBUNWIND
print_backtrace();
-#endif
 
if (run_under_gdb())
abort();
@@ -1876,9 +1872,8 @@ static void fatal_sig_handler(int sig)
igt_exitcode = 128 + sig;
 
failed_one = true;
-#ifdef HAVE_LIBUNWIND
print_backtrace_sig_safe();
-#endif
+
if (in_subtest)
exit_subtest("CRASH");
}
diff --git a/meson.build b/meson.build
index 8e01b05d..a564893d 100644
--- a/meson.build
+++ b/meson.build
@@ -38,6 +38,7 @@ libdrm_amdgpu = dependency('libdrm_amdgpu', required : false)
 pciaccess = dependency('pciaccess', version : '>=0.10')
 libkmod = dependency('libkmod')
 libprocps = dependency('libprocps', required : true)
+libunwind = dependency('libunwind', required : true)
 
 valgrind = dependency('valgrind', required : false)
 if valgrind.found()
@@ -56,7 +57,6 @@ if glib.found()
config.set('HAVE_GLIB', 1)
 endif
 
-libunwind = dependency('libunwind')
 gsl = dependency('gsl', required : false)
 alsa = dependency('alsa', required : false)
 
-- 
2.13.6

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc

[Patchwork]

== Series Details ==

Series: test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc
URL   : https://patchwork.freedesktop.org/series/34749/
State : warning

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3428
807db75b1a12 drm-tip: 2017y-12m-01d-11h-04m-28s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-snb-2600)
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:389s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:519s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:496s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:476s
fi-elk-e7500 total:224  pass:162  dwarn:15  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:271s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:367s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:260s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:399s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:448s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:494s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:532s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:525s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:463s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:547s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:247  dwarn:1   dfail:0   fail:0   skip:40  
time:423s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:607s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 10:33:15)
> We currently have two module parameters that control GuC:
> "enable_guc_loading" and "enable_guc_submission". Whenever
> we need submission=1, we also need loading=1. We also need
> loading=1 when we want to want to load and verify the HuC.
> 
> Lets combine above module parameters into one "enable_guc"
> modparam. New supported bit values are:
> 
>  0=disable GuC (no GuC submission, no HuC)
>  1=enable GuC submission
>  2=enable HuC load
> 
> Special value "-1" can be used to let driver decide what
> option should be enabled for given platform based on
> hardware/firmware availability or preference.
> 
> Explicit enabling any of the GuC features makes GuC load
> a required step, fallback to non-GuC mode will not be
> supported.
> 
> v2: Don't use -EIO
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Sagar Arun Kamble 
> Cc: Sujaritha Sundaresan 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|   5 +-
>  drivers/gpu/drm/i915/i915_params.c |  11 ++--
>  drivers/gpu/drm/i915/i915_params.h |   3 +-
>  drivers/gpu/drm/i915/intel_uc.c| 100 
> +
>  4 files changed, 65 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2c386c7..9162a60 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3238,8 +3238,9 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
>  
>  /* Having a GuC is not the same as using a GuC */
> -#define USES_GUC(dev_priv) (i915_modparams.enable_guc_loading)
> -#define USES_GUC_SUBMISSION(dev_priv)  (i915_modparams.enable_guc_submission)
> +#define USES_GUC(dev_priv) (!!(i915_modparams.enable_guc > 0))
> +#define USES_GUC_SUBMISSION(dev_priv)  (!!(i915_modparams.enable_guc & 1))
> +#define USES_HUC(dev_priv) (!!(i915_modparams.enable_guc & 2))

* channelling Joonas

Please use a magic name for each bit and so

#define USE_GUC_SUBMISSION_BIT 0
#define USES_GUC_SUBMISSION (!!(i915_modparams.enable_guc & 
BIT(USE_GUC_SUBMISSION_BIT)))

Gah, that's so ugly.

or

static inline bool intel_use_guc_submission(void)
{
return i915_modparams.enable_guc & BIT(USE_GUC_SUBMISSION_BIT);
}

which at least stops being so shouty.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc

[Arkadiusz Hiler]

Compiler complained on crc_lowres and crc_hires2 being uninitialized
and indeed, display_commit_mode() seems to have intention of retruning
the value through the parameter that is only a single pointer.

This couses only the local copy of the pointer, the one inside
display_commit_mode(), to be overwritten.

Let's fix that!

Also add missing hires crc comparison (M. Kahola).

Cc: Mika Kahola 
Cc: Maarten Lankhorst 
Signed-off-by: Arkadiusz Hiler 
---
 tests/kms_plane_lowres.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/tests/kms_plane_lowres.c b/tests/kms_plane_lowres.c
index 85d3145d..9cc9724c 100644
--- a/tests/kms_plane_lowres.c
+++ b/tests/kms_plane_lowres.c
@@ -127,7 +127,7 @@ test_fini(data_t *data, igt_output_t *output, enum pipe 
pipe)
 
 static int
 display_commit_mode(igt_display_t *display, igt_pipe_crc_t *pipe_crc,
-   enum pipe pipe, int flags, igt_crc_t *crc)
+   enum pipe pipe, int flags, igt_crc_t **crc)
 {
char buf[256];
struct drm_event *e = (void *)buf;
@@ -148,7 +148,7 @@ display_commit_mode(igt_display_t *display, igt_pipe_crc_t 
*pipe_crc,
igt_assert_eq(e->type, DRM_EVENT_FLIP_COMPLETE);
igt_reset_timeout();
 
-   n = igt_pipe_crc_get_crcs(pipe_crc, vblank_stop - vblank_start, );
+   n = igt_pipe_crc_get_crcs(pipe_crc, vblank_stop - vblank_start, crc);
igt_assert_eq(n, vblank_stop - vblank_start);
 
return n;
@@ -252,7 +252,8 @@ test_plane_position_with_output(data_t *data, enum pipe 
pipe,
 
check_mode(_lowres, mode2);
 
-   display_commit_mode(>display, pipe_crc, pipe, flags, crc_lowres);
+   display_commit_mode(>display, pipe_crc, pipe, flags, _lowres);
+   free(crc_lowres);
 
igt_assert_plane_visible(data->drm_fd, pipe, false);
 
@@ -264,10 +265,15 @@ test_plane_position_with_output(data_t *data, enum pipe 
pipe,
 
check_mode(mode1, mode3);
 
-   display_commit_mode(>display, pipe_crc, pipe, flags, crc_hires2);
+   display_commit_mode(>display, pipe_crc, pipe, flags, _hires2);
 
igt_assert_plane_visible(data->drm_fd, pipe, true);
 
+   igt_assert_crc_equal(crc_hires1, crc_hires2);
+
+   free(crc_hires1);
+   free(crc_hires2);
+
igt_pipe_crc_stop(pipe_crc);
igt_pipe_crc_free(pipe_crc);
 
-- 
2.13.6

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Sleep and retry a GPU reset if at first we don't succeed (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed 
(rev2)
URL   : https://patchwork.freedesktop.org/series/34747/
State : success

== Summary ==

Series 34747v2 drm/i915: Sleep and retry a GPU reset if at first we don't 
succeed
https://patchwork.freedesktop.org/api/1.0/series/34747/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:387s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:523s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:511s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:491s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-elk-e7500 total:224  pass:162  dwarn:15  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:273s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:551s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:372s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:260s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:392s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:489s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:533s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:542s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:526s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:548s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:422s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:609s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s

807db75b1a12167fffcae6afb925da1393cb7f15 drm-tip: 2017y-12m-01d-11h-04m-28s UTC 
integration manifest
cff3c9022fcc drm/i915: Sleep and retry a GPU reset if at first we don't succeed

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/huc: Load HuC only if requested

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 10:33:16)
> Our new "enable_guc" modparam allows to control whenever HuC
> should be loaded. However existing code will try load and
> authenticate HuC always when we use the GuC. This patch is
> trying to enforce modparam selection.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Sagar Arun Kamble 
> ---
> -void intel_huc_auth(struct intel_huc *huc)
> +int intel_huc_auth(struct intel_huc *huc)
>  {
> struct drm_i915_private *i915 = huc_to_i915(huc);
> struct intel_guc *guc = >guc;
> @@ -213,14 +213,14 @@ void intel_huc_auth(struct intel_huc *huc)
> int ret;
>  
> if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
> -   return;
> +   return -ENOEXEC;
>  
> vma = i915_gem_object_ggtt_pin(huc->fw.obj, NULL, 0, 0,
> PIN_OFFSET_BIAS | GUC_WOPCM_TOP);
> if (IS_ERR(vma)) {
> -   DRM_ERROR("failed to pin huc fw object %d\n",
> -   (int)PTR_ERR(vma));
> -   return;
> +   ret = (int)PTR_ERR(vma);

The advantage here is that (int) is now implicit.

Looks ok. I'd recommend we add the various expected combinations to
drv_module_reload.
"enable_guc=0"
"enable_guc=0x1"
"enable_guc=0x2"
"enable_guc=0x3"
etc?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915/uc: Don't use -EIO to report missing firmware

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 10:33:14)
> -EIO has special meaning and is used when we want to allow
> engine initialization to fail and mark GPU as wedged.
> Missing firmware does not fit into this scenario as this is
> permanent error not related to GPU condition.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Sagar Arun Kamble 

Ok, keeping -EIO to mean something special is a good idea. So if upload
now fails, we abort loading of the driver with ENOEXEC.

Is that sensible? Let's say due to fs corruption, or other error, we
aren't able to upload a fw, what should we do? If we abort the driver
load at this point, the user is likely left with a blank screen. If we
use -EIO, at least KMS is still functional and the user can still
interact with the system. (If we just fell back to execlists, then the
system remains very usable.)

What is the plan for HW initialisation failure?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/7] drm/i915/guc: Introduce USES_GUC_xxx helper macros

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 10:33:13)
> In the upcoming patch we will change the way how to recognize
> when GuC is in use. Using helper macros will minimize scope
> of that changes. While here, update dev_info message.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Sagar Arun Kamble 

> ---
>  drivers/gpu/drm/i915/i915_drv.h|  4 
>  drivers/gpu/drm/i915/i915_gem_context.c|  4 ++--
>  drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
>  drivers/gpu/drm/i915/i915_irq.c|  2 +-
>  drivers/gpu/drm/i915/intel_guc.c   |  2 +-
>  drivers/gpu/drm/i915/intel_guc_log.c   |  6 +++---
>  drivers/gpu/drm/i915/intel_gvt.c   |  2 +-
>  drivers/gpu/drm/i915/intel_uc.c| 23 +++
>  drivers/gpu/drm/i915/selftests/intel_guc.c |  2 +-
>  9 files changed, 25 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4c3616b..2c386c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3237,6 +3237,10 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define HAS_HUC(dev_priv)  (HAS_GUC(dev_priv))
>  #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
>  
> +/* Having a GuC is not the same as using a GuC */
> +#define USES_GUC(dev_priv) (i915_modparams.enable_guc_loading)
> +#define USES_GUC_SUBMISSION(dev_priv)  (i915_modparams.enable_guc_submission)

I was thinking that maybe we should keep the HAS_GUC here until the end,
but afaict the modparam is always sanitized by the point we inspect it
for USES_GUC.

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

Re: [Intel-gfx] [PATCH v2 2/7] drm/i915/guc: Move firmware selection to init_early

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 10:33:12)
> Doing GuC firmware path selection from sanitize_options function
> is not perfect, while there is no problem with doing so during
> early init stage as we already have all needed data.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_ctx_isolation: Check isolation of registers between contexts (rev9)

[Patchwork]

== Series Details ==

Series: igt/gem_ctx_isolation: Check isolation of registers between contexts 
(rev9)
URL   : https://patchwork.freedesktop.org/series/32531/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for 
in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3428
807db75b1a12 drm-tip: 2017y-12m-01d-11h-04m-28s UTC integration manifest

Testlist changes:
+igt@gem_ctx_isolation@bcs0-clean
+igt@gem_ctx_isolation@bcs0-dirty-create
+igt@gem_ctx_isolation@bcs0-dirty-switch
+igt@gem_ctx_isolation@bcs0-none
+igt@gem_ctx_isolation@bcs0-reset
+igt@gem_ctx_isolation@bcs0-s3
+igt@gem_ctx_isolation@bcs0-s4
+igt@gem_ctx_isolation@rcs0-clean
+igt@gem_ctx_isolation@rcs0-dirty-create
+igt@gem_ctx_isolation@rcs0-dirty-switch
+igt@gem_ctx_isolation@rcs0-none
+igt@gem_ctx_isolation@rcs0-reset
+igt@gem_ctx_isolation@rcs0-s3
+igt@gem_ctx_isolation@rcs0-s4
+igt@gem_ctx_isolation@vcs0-clean
+igt@gem_ctx_isolation@vcs0-dirty-create
+igt@gem_ctx_isolation@vcs0-dirty-switch
+igt@gem_ctx_isolation@vcs0-none
+igt@gem_ctx_isolation@vcs0-reset
+igt@gem_ctx_isolation@vcs0-s3
+igt@gem_ctx_isolation@vcs0-s4
+igt@gem_ctx_isolation@vcs1-clean
+igt@gem_ctx_isolation@vcs1-dirty-create
+igt@gem_ctx_isolation@vcs1-dirty-switch
+igt@gem_ctx_isolation@vcs1-none
+igt@gem_ctx_isolation@vcs1-reset
+igt@gem_ctx_isolation@vcs1-s3
+igt@gem_ctx_isolation@vcs1-s4
+igt@gem_ctx_isolation@vecs0-clean
+igt@gem_ctx_isolation@vecs0-dirty-create
+igt@gem_ctx_isolation@vecs0-dirty-switch
+igt@gem_ctx_isolation@vecs0-none
+igt@gem_ctx_isolation@vecs0-reset
+igt@gem_ctx_isolation@vecs0-s3
+igt@gem_ctx_isolation@vecs0-s4

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:526s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:493s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:480s
fi-elk-e7500 total:224  pass:162  dwarn:16  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:273s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:374s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:264s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:395s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:446s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:490s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:531s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:589s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:461s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:537s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:491s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:425s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:607s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:492s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/7] drm/i915/huc: Move firmware selection to init_early

[Chris Wilson]

Quoting Michal Wajdeczko (2017-12-01 10:33:11)
> Doing HuC firmware path selection from sanitize_options function
> is not perfect, while there is no problem with doing so during
> early init stage as we already have all needed data.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Sleep and retry a GPU reset if at first we don't succeed

[Chris Wilson]

As we declare the GPU wedged if the reset fails, such a failure is quite
terminal. Before taking that drastic action, let's sleep first and try
active, in the hope that the hardware has quietened down and is then
able to reset. After a few such attempts, it is fair to say that the HW
is truly wedged.

v2: Always print the failure message now, we precheck whether resets are
disabled.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104007
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e0f053f9c186..7faf20aff25a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1877,7 +1877,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
 {
struct i915_gpu_error *error = >gpu_error;
int ret;
+   int i;
 
+   might_sleep();
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
 
@@ -1900,12 +1902,20 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
goto error;
}
 
-   ret = intel_gpu_reset(i915, ALL_ENGINES);
+   if (!intel_has_gpu_reset(i915)) {
+   DRM_DEBUG_DRIVER("GPU reset disabled\n");
+   goto error;
+   }
+
+   for (i = 0; i < 3; i++) {
+   ret = intel_gpu_reset(i915, ALL_ENGINES);
+   if (ret == 0)
+   break;
+
+   msleep(100);
+   }
if (ret) {
-   if (ret != -ENODEV)
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
-   else
-   DRM_DEBUG_DRIVER("GPU reset disabled\n");
+   dev_err(i915->drm.dev, "Failed to reset chip\n");
goto error;
}
 
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Sleep and retry a GPU reset if at first we don't succeed

[Chris Wilson]

Quoting Chris Wilson (2017-12-01 12:12:40)
> As we declare the GPU wedged if the reset fails, such a failure is quite
> terminal. Before taking that drastic action, let's sleep first and try
> active, in the hope that the hardware has quietened down and is then
> able to reset. After a few such attempts, it is fair to say that the HW
> is truly wedged.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=104007
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 22 --
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e0f053f9c186..924ebe24b282 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1877,7 +1877,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
> int flags)
>  {
> struct i915_gpu_error *error = >gpu_error;
> int ret;
> +   int i;
>  
> +   might_sleep();
> lockdep_assert_held(>drm.struct_mutex);
> GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
>  
> @@ -1900,12 +1902,20 @@ void i915_reset(struct drm_i915_private *i915, 
> unsigned int flags)
> goto error;
> }
>  
> -   ret = intel_gpu_reset(i915, ALL_ENGINES);
> -   if (ret) {
> -   if (ret != -ENODEV)
> -   DRM_ERROR("Failed to reset chip: %i\n", ret);
> -   else
> -   DRM_DEBUG_DRIVER("GPU reset disabled\n");
> +   if (!intel_has_gpu_reset(i915)) {
> +   DRM_DEBUG_DRIVER("GPU reset disabled\n");
> +   goto error;
> +   }
> +
> +   for (i = 0; i < 3; i++) {
> +   ret = intel_gpu_reset(i915, ALL_ENGINES);
> +   if (ret == 0)
> +   break;
> +
> +   msleep(100);
> +   }
> +   if (ret != -ENODEV) {

Bah, was meant to be if (ret) {

> +   DRM_ERROR("Failed to reset chip: %i\n", ret);
> goto error;
> }
>  
> -- 
> 2.15.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Sleep and retry a GPU reset if at first we don't succeed

[Chris Wilson]

As we declare the GPU wedged if the reset fails, such a failure is quite
terminal. Before taking that drastic action, let's sleep first and try
active, in the hope that the hardware has quietened down and is then
able to reset. After a few such attempts, it is fair to say that the HW
is truly wedged.

References: https://bugs.freedesktop.org/show_bug.cgi?id=104007
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e0f053f9c186..924ebe24b282 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1877,7 +1877,9 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
 {
struct i915_gpu_error *error = >gpu_error;
int ret;
+   int i;
 
+   might_sleep();
lockdep_assert_held(>drm.struct_mutex);
GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, >flags));
 
@@ -1900,12 +1902,20 @@ void i915_reset(struct drm_i915_private *i915, unsigned 
int flags)
goto error;
}
 
-   ret = intel_gpu_reset(i915, ALL_ENGINES);
-   if (ret) {
-   if (ret != -ENODEV)
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
-   else
-   DRM_DEBUG_DRIVER("GPU reset disabled\n");
+   if (!intel_has_gpu_reset(i915)) {
+   DRM_DEBUG_DRIVER("GPU reset disabled\n");
+   goto error;
+   }
+
+   for (i = 0; i < 3; i++) {
+   ret = intel_gpu_reset(i915, ALL_ENGINES);
+   if (ret == 0)
+   break;
+
+   msleep(100);
+   }
+   if (ret != -ENODEV) {
+   DRM_ERROR("Failed to reset chip: %i\n", ret);
goto error;
}
 
-- 
2.15.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_eio: Increase wakeup delay for in-flight-suspend (rev2)

[Patchwork]

== Series Details ==

Series: igt/gem_eio: Increase wakeup delay for in-flight-suspend (rev2)
URL   : https://patchwork.freedesktop.org/series/34691/
State : failure

== Summary ==

Series 34691 revision 2 was fully merged or fully failed: no git log

___
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: Remove unsafe i915.enable_rc6 (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Remove unsafe i915.enable_rc6 (rev4)
URL   : https://patchwork.freedesktop.org/series/21884/
State : success

== Summary ==

Series 21884v4 drm/i915: Remove unsafe i915.enable_rc6
https://patchwork.freedesktop.org/api/1.0/series/21884/revisions/4/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:381s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:518s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:507s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:492s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:475s
fi-elk-e7500 total:224  pass:162  dwarn:16  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:271s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:380s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:261s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:394s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:444s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:487s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:524s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:535s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:593s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:542s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
fi-skl-6700k total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:514s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:498s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:552s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:417s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:605s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-cnl-y failed to collect. IGT log at Patchwork_7390/fi-cnl-y/igt.log

807db75b1a12167fffcae6afb925da1393cb7f15 drm-tip: 2017y-12m-01d-11h-04m-28s UTC 
integration manifest
3912d0a54ad3 drm/i915: Remove unsafe i915.enable_rc6

== Logs ==

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

[Intel-gfx] [CI] drm/i915: Remove unsafe i915.enable_rc6

[Chris Wilson]

It has been many years since the last confirmed sighting (and fix) of an
RC6 related bug (usually a system hang). Remove the parameter to stop
users from setting dangerous values, as they often set it during triage
and end up disabling the entire runtime pm instead (the option is not a
fine scalpel!).

Furthermore, it allows users to set known dangerous values which were
intended for testing and not for production use. For testing, we can
always patch in the required setting without having to expose ourselves
to random abuse.

v2: Fixup NEEDS_WaRsDisableCoarsePowerGating fumble, and document the
lack of ilk support better.
v3: Clear intel_info->rc6p if we don't support rc6 itself.

Signed-off-by: Chris Wilson 
Cc: Rodrigo Vivi 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Imre Deak 
Cc: Daniel Vetter 
Acked-by: Daniel Vetter 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.h |   2 +
 drivers/gpu/drm/i915/i915_params.c  |   7 --
 drivers/gpu/drm/i915/i915_params.h  |   1 -
 drivers/gpu/drm/i915/i915_pci.c |   2 +
 drivers/gpu/drm/i915/i915_pmu.c |   4 +-
 drivers/gpu/drm/i915/i915_sysfs.c   |  13 +++-
 drivers/gpu/drm/i915/intel_drv.h|   5 --
 drivers/gpu/drm/i915/intel_guc.c|   3 +-
 drivers/gpu/drm/i915/intel_pm.c | 142 +++-
 drivers/gpu/drm/i915/intel_uncore.c |   3 -
 11 files changed, 64 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cda67dfb0a50..e0f053f9c186 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2517,7 +2517,7 @@ static int intel_runtime_suspend(struct device *kdev)
struct drm_i915_private *dev_priv = to_i915(dev);
int ret;
 
-   if (WARN_ON_ONCE(!(dev_priv->gt_pm.rc6.enabled && intel_rc6_enabled(
+   if (WARN_ON_ONCE(!(dev_priv->gt_pm.rc6.enabled && HAS_RC6(dev_priv
return -ENODEV;
 
if (WARN_ON_ONCE(!HAS_RUNTIME_PM(dev_priv)))
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd65839f60..e8dc7b77ac96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3213,8 +3213,10 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_DDI(dev_priv)   ((dev_priv)->info.has_ddi)
 #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) ((dev_priv)->info.has_fpga_dbg)
 #define HAS_PSR(dev_priv)   ((dev_priv)->info.has_psr)
+
 #define HAS_RC6(dev_priv)   ((dev_priv)->info.has_rc6)
 #define HAS_RC6p(dev_priv)  ((dev_priv)->info.has_rc6p)
+#define HAS_RC6pp(dev_priv) (false) /* HW was never validated */
 
 #define HAS_CSR(dev_priv)  ((dev_priv)->info.has_csr)
 
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 3328147b4863..7bc538687871 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,13 +46,6 @@ i915_param_named_unsafe(panel_ignore_lid, int, 0600,
"Override lid status (0=autodetect, 1=autodetect disabled [default], "
"-1=force lid closed, -2=force lid open)");
 
-i915_param_named_unsafe(enable_rc6, int, 0400,
-   "Enable power-saving render C-state 6. "
-   "Different stages can be selected via bitmask values "
-   "(0 = disable; 1 = enable rc6; 2 = enable deep rc6; 4 = enable deepest 
rc6). "
-   "For example, 3 would enable rc6 and deep rc6, and 7 would enable 
everything. "
-   "default: -1 (use per-chip default)");
-
 i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
"(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 8321bd86cba5..c48c88bb95e8 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -34,7 +34,6 @@
param(int, lvds_channel_mode, 0) \
param(int, panel_use_ssc, -1) \
param(int, vbt_sdvo_panel_type, -1) \
-   param(int, enable_rc6, -1) \
param(int, enable_dc, -1) \
param(int, enable_fbc, -1) \
param(int, enable_ppgtt, -1) \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6458c309c039..fa67d3dde20e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -209,6 +209,8 @@ static const struct intel_device_info intel_gm45_info 
__initconst = {
.has_hotplug = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
.has_snoop = true, \
+   /* ilk does support rc6, but we do not implement [power] contexts */ \
+   .has_rc6 = 0, \

[Intel-gfx] [PATCH igt] igt/gem_ctx_isolation: Check isolation of registers between contexts

[Chris Wilson]

A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.

v2: Extend back to Sandybridge (etc)
v3: Check context preserves registers across suspend/hibernate and resets.
v4: Complete the remapping onto the new class:instance
v5: Not like that, like this, try again to use class:instance
v6: Prepare for retrospective gen4 contexts!
v7: Repaint register set name to nonpriv, as this is what bspec calls the
registers that are writable by userspace.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
 tests/Makefile.sources|   1 +
 tests/gem_ctx_isolation.c | 677 ++
 tests/gem_exec_fence.c|   2 +-
 3 files changed, 679 insertions(+), 1 deletion(-)
 create mode 100644 tests/gem_ctx_isolation.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 34ca71a0..e16e586a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -57,6 +57,7 @@ TESTS_progs = \
gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
gem_ctx_thrash \
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
new file mode 100644
index ..8b69cd33
--- /dev/null
+++ b/tests/gem_ctx_isolation.c
@@ -0,0 +1,677 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_dummyload.h"
+
+#define MAX_REG 0x4
+#define NUM_REGS (MAX_REG / sizeof(uint32_t))
+
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
+
+#define DIRTY1 0x1
+#define DIRTY2 0x2
+#define RESET 0x4
+
+#define BIT(x) (1ul << (x))
+#define ENGINE(x, y) BIT(4*(x) + (y))
+
+enum {
+   RCS0 = ENGINE(I915_ENGINE_CLASS_RENDER, 0),
+   BCS0 = ENGINE(I915_ENGINE_CLASS_COPY, 0),
+   VCS0 = ENGINE(I915_ENGINE_CLASS_VIDEO, 0),
+   VCS1 = ENGINE(I915_ENGINE_CLASS_VIDEO, 1),
+   VECS0 = ENGINE(I915_ENGINE_CLASS_VIDEO_ENHANCE, 0),
+};
+
+#define ALL ~0u
+#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
+#define GEN4 (ALL << 4)
+#define GEN5 (ALL << 5)
+#define GEN6 (ALL << 6)
+#define GEN7 (ALL << 7)
+#define GEN8 (ALL << 8)
+#define GEN9 (ALL << 9)
+
+#define NOCTX 0
+
+#define LAST_KNOWN_GEN 10
+
+static const struct named_register {
+   const char *name;
+   unsigned int gen_mask;
+   unsigned int engine_mask;
+   uint32_t offset;
+   uint32_t count;
+} nonpriv_registers[] = {
+   { "NOPID", NOCTX, RCS0, 0x2094 },
+   { "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
+   { "INSTPM", GEN9, RCS0, 0x20c0 },
+   { "IA_VERTICES_COUNT", GEN4, RCS0, 0x2310, 2 },
+   { "IA_PRIMITIVES_COUNT", GEN4, RCS0, 0x2318, 2 },
+   { "VS_INVOCATION_COUNT", GEN4, RCS0, 0x2320, 2 },
+   { "HS_INVOCATION_COUNT", GEN4, RCS0, 0x2300, 2 },
+   { "DS_INVOCATION_COUNT", GEN4, RCS0, 0x2308, 2 },
+   { "GS_INVOCATION_COUNT", GEN4, RCS0, 0x2328, 2 },
+   { "GS_PRIMITIVES_COUNT", GEN4, RCS0, 0x2330, 2 },
+   { "CL_INVOCATION_COUNT", GEN4, RCS0, 0x2338, 2 },
+   { "CL_PRIMITIVES_COUNT", GEN4, RCS0, 0x2340, 2 },
+   { "PS_INVOCATION_COUNT_0", GEN4, RCS0, 0x22c8, 2 },
+   { "PS_DEPTH_COUNT_0", GEN4, RCS0, 0x22d8, 2 },
+   { "GPUGPU_DISPATCHDIMX", GEN8, RCS0, 0x2500 },
+   { "GPUGPU_DISPATCHDIMY", GEN8, RCS0, 0x2504 },
+   { "GPUGPU_DISPATCHDIMZ", GEN8, RCS0, 0x2508 },
+   { "MI_PREDICATE_SRC0", GEN8, RCS0, 0x2400, 2 },
+   { "MI_PREDICATE_SRC1", GEN8, RCS0, 0x2408, 2 },
+   { "MI_PREDICATE_DATA", GEN8, RCS0, 0x2410, 2 },
+   { "MI_PRED_RESULT", GEN8, RCS0, 0x2418 },
+   { "3DPRIM_END_OFFSET", GEN6, RCS0, 0x2420 },
+   { "3DPRIM_START_VERTEX", GEN6, RCS0, 0x2430 },
+

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,1/7] drm/i915/huc: Move firmware selection to init_early

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/7] drm/i915/huc: Move firmware selection to 
init_early
URL   : https://patchwork.freedesktop.org/series/34738/
State : warning

== Summary ==

Series 34738v1 series starting with [v2,1/7] drm/i915/huc: Move firmware 
selection to init_early
https://patchwork.freedesktop.org/api/1.0/series/34738/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-skl-6700k)
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-bxt-dsi)
pass   -> DMESG-WARN (fi-bxt-j4205)
pass   -> DMESG-WARN (fi-kbl-7500u) fdo#103285
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-7567u)
pass   -> DMESG-WARN (fi-kbl-r)
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:443s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:516s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:257  dwarn:1   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:258  dwarn:1   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:485s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:480s
fi-elk-e7500 total:224  pass:162  dwarn:16  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:266s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:358s
fi-hsw-4770r total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  
time:263s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:391s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-ivb-3770  total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:443s
fi-kbl-7500u total:288  pass:262  dwarn:2   dfail:0   fail:0   skip:24  
time:474s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:513s
fi-kbl-7567u total:288  pass:267  dwarn:1   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:518s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:594s
fi-skl-6260u total:288  pass:267  dwarn:1   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6700k total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:500s
fi-skl-6770hqtotal:288  pass:267  dwarn:1   dfail:0   fail:0   skip:20  
time:476s
fi-skl-gvtdvmtotal:288  pass:264  dwarn:1   dfail:0   fail:0   skip:23  
time:435s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:419s
Blacklisted hosts:
fi-cfl-s2total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:593s
fi-glk-dsi   total:162  pass:77   dwarn:0   dfail:1   fail:0   skip:83 

9e7a016a79ab9948d08e1afccb14805a848fb7df drm-tip: 2017y-12m-01d-09h-20m-42s UTC 
integration manifest
4f8097244eec HAX enable GuC/HuC load
17b7a62b25c9 drm/i915/huc: Load HuC only if requested
8d8ee68dbe22 drm/i915/guc: Combine enable_guc_loading|submission modparams
90d41677bb95 drm/i915/uc: Don't use -EIO to report missing firmware
1eed9c449e57 drm/i915/guc: Introduce USES_GUC_xxx helper macros
03e04733c93c drm/i915/guc: Move firmware selection to init_early
ed8b3e1c5832 drm/i915/huc: Move firmware selection to init_early

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7389/
___

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wake the device before executing requests on the GPU

[Chris Wilson]

Quoting Mika Kuoppala (2017-12-01 10:40:24)
> Chris Wilson  writes:
> 
> > To execute a requests requires us to have first woken the device, using
> > the rpm wakeref (as the request needs to write to hardware to setup the
> > context/ppGTT and execute on the GPU). So call intel_runtime_pm_get()
> > around queuing the request; the request itself will then carry a wakeref
> > until completion.
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103994
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Matthew Auld 
> 
> Reviewed-by: Mika Kuoppala 

Ta, answers on a postcard if you can explain why this is not happening
on every run!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Wake the device before executing requests on the GPU

[Mika Kuoppala]

Chris Wilson  writes:

> To execute a requests requires us to have first woken the device, using
> the rpm wakeref (as the request needs to write to hardware to setup the
> context/ppGTT and execute on the GPU). So call intel_runtime_pm_get()
> around queuing the request; the request itself will then carry a wakeref
> until completion.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103994
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Matthew Auld 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/selftests/i915_gem_context.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c 
> b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> index ec1eff739e01..56a803d11916 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
> @@ -376,7 +376,9 @@ static int igt_ctx_exec(void *arg)
>   }
>   }
>  
> + intel_runtime_pm_get(i915);
>   err = gpu_fill(obj, ctx, engine, dw);
> + intel_runtime_pm_put(i915);
>   if (err) {
>   pr_err("Failed to fill dword %lu [%lu/%lu] with 
> gpu (%s) in ctx %u [full-ppgtt? %s], err=%d\n",
>  ndwords, dw, max_dwords(obj),
> -- 
> 2.15.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/gem_eio: Increase wakeup delay for in-flight-suspend

[Chris Wilson]

For in-flight-suspend, we need to wait for the GPU hang within
i915_gem_suspend(). This will take 10-20s, which means that the standard
wakeup delay of around 15s may occur before we complete the suspend.
This causes a pm_system_wakeup(), causing dpm_suspend() to return
-EBUSY.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 tests/gem_eio.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 7a6be393..2ac9f0a9 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -258,8 +258,8 @@ static void test_inflight_suspend(int fd)
igt_assert(fence[n] != -1);
}
 
-   igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
- SUSPEND_TEST_NONE);
+   igt_set_autoresume_delay(30);
+   igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
 
igt_post_hang_ring(fd, hang);
 
-- 
2.15.1

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

[Intel-gfx] [PATCH v2 5/7] drm/i915/guc: Combine enable_guc_loading|submission modparams

[Michal Wajdeczko]

We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.

Lets combine above module parameters into one "enable_guc"
modparam. New supported bit values are:

 0=disable GuC (no GuC submission, no HuC)
 1=enable GuC submission
 2=enable HuC load

Special value "-1" can be used to let driver decide what
option should be enabled for given platform based on
hardware/firmware availability or preference.

Explicit enabling any of the GuC features makes GuC load
a required step, fallback to non-GuC mode will not be
supported.

v2: Don't use -EIO

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
---
 drivers/gpu/drm/i915/i915_drv.h|   5 +-
 drivers/gpu/drm/i915/i915_params.c |  11 ++--
 drivers/gpu/drm/i915/i915_params.h |   3 +-
 drivers/gpu/drm/i915/intel_uc.c| 100 +
 4 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c386c7..9162a60 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3238,8 +3238,9 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
 /* Having a GuC is not the same as using a GuC */
-#define USES_GUC(dev_priv) (i915_modparams.enable_guc_loading)
-#define USES_GUC_SUBMISSION(dev_priv)  (i915_modparams.enable_guc_submission)
+#define USES_GUC(dev_priv) (!!(i915_modparams.enable_guc > 0))
+#define USES_GUC_SUBMISSION(dev_priv)  (!!(i915_modparams.enable_guc & 1))
+#define USES_HUC(dev_priv) (!!(i915_modparams.enable_guc & 2))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 3328147..8654e45 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -154,13 +154,10 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
 
-i915_param_named_unsafe(enable_guc_loading, int, 0400,
-   "Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
-
-i915_param_named_unsafe(enable_guc_submission, int, 0400,
-   "Enable GuC submission "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
+i915_param_named_unsafe(enable_guc, int, 0400,
+   "Enable GuC load for GuC submission and/or HuC load. "
+   "Required functionality can be selected using bitmask values. "
+   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 8321bd8..10e2f74 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -42,8 +42,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc_loading, 0) \
-   param(int, enable_guc_submission, 0) \
+   param(int, enable_guc, 0) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index ed2dd76..8a761af 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -47,35 +47,59 @@ static int __intel_uc_reset_hw(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+static int __get_default_enable_guc(struct drm_i915_private *dev_priv)
 {
-   if (!HAS_GUC(dev_priv)) {
-   if (i915_modparams.enable_guc_loading > 0 ||
-   i915_modparams.enable_guc_submission > 0)
-   DRM_INFO("Ignoring GuC options, no hardware\n");
+   struct intel_uc_fw *guc_fw = _priv->guc.fw;
+   struct intel_uc_fw *huc_fw = _priv->huc.fw;
+   /* Default is to enable GuC/HuC if we know their firmwares */
+   int enable_guc = (intel_uc_fw_is_selected(guc_fw) ? 1 : 0) |
+(intel_uc_fw_is_selected(huc_fw) ? 2 : 0);
 
-   i915_modparams.enable_guc_loading = 0;
-   i915_modparams.enable_guc_submission = 0;
-   return;
-   }
+   /* Any platform specific fine-tuning can be done here */
 
-   /* A 

[Intel-gfx] [PATCH v2 4/7] drm/i915/uc: Don't use -EIO to report missing firmware

[Michal Wajdeczko]

-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to GPU condition.

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

diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c 
b/drivers/gpu/drm/i915/intel_uc_fw.c
index b376dd3..784eff9 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -214,7 +214,7 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
 intel_uc_fw_type_repr(uc_fw->type), uc_fw->path);
 
if (uc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
-   return -EIO;
+   return -ENOEXEC;
 
uc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
DRM_DEBUG_DRIVER("%s fw load %s\n",
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH igt] igt/gem_eio: Increase wakeup delay for in-flight-suspend

[Mika Kuoppala]

Chris Wilson  writes:

> For in-flight-suspend, we need to wait for the GPU hang within
> i915_gem_suspend(). This will take 10-20s, which means that the standard
> wakeup delay of around 15s may occur before we complete the suspend.
> This causes a pm_system_wakeup(), causing dpm_suspend() to return
> -EBUSY.
>
> Signed-off-by: Chris Wilson 

Reviewed-by: Mika Kuoppala 

> ---
>  tests/gem_eio.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/gem_eio.c b/tests/gem_eio.c
> index 7a6be393..2ac9f0a9 100644
> --- a/tests/gem_eio.c
> +++ b/tests/gem_eio.c
> @@ -258,8 +258,8 @@ static void test_inflight_suspend(int fd)
>   igt_assert(fence[n] != -1);
>   }
>  
> - igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
> -   SUSPEND_TEST_NONE);
> + igt_set_autoresume_delay(30);
> + igt_system_suspend_autoresume(SUSPEND_STATE_MEM, SUSPEND_TEST_NONE);
>  
>   igt_post_hang_ring(fd, hang);

post_hang_cleanup(?) ...

-Mika

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

[Intel-gfx] [PATCH v2 1/7] drm/i915/huc: Move firmware selection to init_early

[Michal Wajdeczko]

Doing HuC firmware path selection from sanitize_options function
is not perfect, while there is no problem with doing so during
early init stage as we already have all needed data.

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

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bddd658..4c3616b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3232,6 +3232,9 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_GUC_CT(dev_priv)   ((dev_priv)->info.has_guc_ct)
 #define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
+
+/* For now, anything with a GuC has also HuC */
+#define HAS_HUC(dev_priv)  (HAS_GUC(dev_priv))
 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 98d1725..6d0e050 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -77,43 +77,57 @@ MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
 #define I915_GLK_HUC_UCODE HUC_FW_PATH(glk, GLK_HUC_FW_MAJOR, \
GLK_HUC_FW_MINOR, GLK_BLD_NUM)
 
-/**
- * intel_huc_select_fw() - selects HuC firmware for loading
- * @huc:   intel_huc struct
- */
-void intel_huc_select_fw(struct intel_huc *huc)
+static void huc_fw_select(struct intel_uc_fw *huc_fw)
 {
+   struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
struct drm_i915_private *dev_priv = huc_to_i915(huc);
 
-   intel_uc_fw_init(>fw, INTEL_UC_FW_TYPE_HUC);
+   GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
+
+   if (!HAS_HUC(dev_priv))
+   return;
 
if (i915_modparams.huc_firmware_path) {
-   huc->fw.path = i915_modparams.huc_firmware_path;
-   huc->fw.major_ver_wanted = 0;
-   huc->fw.minor_ver_wanted = 0;
+   huc_fw->path = i915_modparams.huc_firmware_path;
+   huc_fw->major_ver_wanted = 0;
+   huc_fw->minor_ver_wanted = 0;
} else if (IS_SKYLAKE(dev_priv)) {
-   huc->fw.path = I915_SKL_HUC_UCODE;
-   huc->fw.major_ver_wanted = SKL_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = SKL_HUC_FW_MINOR;
+   huc_fw->path = I915_SKL_HUC_UCODE;
+   huc_fw->major_ver_wanted = SKL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = SKL_HUC_FW_MINOR;
} else if (IS_BROXTON(dev_priv)) {
-   huc->fw.path = I915_BXT_HUC_UCODE;
-   huc->fw.major_ver_wanted = BXT_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = BXT_HUC_FW_MINOR;
+   huc_fw->path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = BXT_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = BXT_HUC_FW_MINOR;
} else if (IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv)) {
-   huc->fw.path = I915_KBL_HUC_UCODE;
-   huc->fw.major_ver_wanted = KBL_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = KBL_HUC_FW_MINOR;
+   huc_fw->path = I915_KBL_HUC_UCODE;
+   huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR;
} else if (IS_GEMINILAKE(dev_priv)) {
-   huc->fw.path = I915_GLK_HUC_UCODE;
-   huc->fw.major_ver_wanted = GLK_HUC_FW_MAJOR;
-   huc->fw.minor_ver_wanted = GLK_HUC_FW_MINOR;
+   huc_fw->path = I915_GLK_HUC_UCODE;
+   huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR;
+   huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR;
} else {
-   DRM_ERROR("No HuC firmware known for platform with HuC!\n");
-   return;
+   DRM_WARN("%s: No firmware known for this platform!\n",
+intel_uc_fw_type_repr(huc_fw->type));
}
 }
 
 /**
+ * intel_huc_init_early() - initializes HuC struct
+ * @huc: intel_huc struct
+ *
+ * On platforms with HuC selects firmware for uploading
+ */
+void intel_huc_init_early(struct intel_huc *huc)
+{
+   struct intel_uc_fw *huc_fw = >fw;
+
+   intel_uc_fw_init(huc_fw, INTEL_UC_FW_TYPE_HUC);
+   huc_fw_select(huc_fw);
+}
+
+/**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm_i915_private device
  *
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index aaa38b9..3d757bc 100644
--- 

[Intel-gfx] [PATCH v2 7/7] HAX enable GuC/HuC load

[Michal Wajdeczko]

Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")

v2: don't enable GuC on GLK

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
 drivers/gpu/drm/i915/i915_params.h  | 2 +-
 drivers/gpu/drm/i915/intel_uc.c | 2 ++
 3 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 209bb11..a5e75a3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3590,17 +3590,13 @@ int i915_ggtt_enable_hw(struct drm_i915_private 
*dev_priv)
 
 void i915_ggtt_enable_guc(struct drm_i915_private *i915)
 {
-   GEM_BUG_ON(i915->ggtt.invalidate != gen6_ggtt_invalidate);
-
i915->ggtt.invalidate = guc_ggtt_invalidate;
 }
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
 {
-   /* We should only be called after i915_ggtt_enable_guc() */
-   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
-
-   i915->ggtt.invalidate = gen6_ggtt_invalidate;
+   if (i915->ggtt.invalidate == guc_ggtt_invalidate)
+   i915->ggtt.invalidate = gen6_ggtt_invalidate;
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 10e2f74..fd5e598 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -42,7 +42,7 @@
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 6c30a4d..76d4658 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -56,6 +56,8 @@ static int __get_default_enable_guc(struct drm_i915_private 
*dev_priv)
 (intel_uc_fw_is_selected(huc_fw) ? 2 : 0);
 
/* Any platform specific fine-tuning can be done here */
+   if (IS_GEMINILAKE(dev_priv))
+   enable_guc = 0; /* no firmware on CI machines */
 
/* Make sure that our "platform default" is well-defined */
GEM_BUG_ON(enable_guc < 0);
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 3/7] drm/i915/guc: Introduce USES_GUC_xxx helper macros

[Michal Wajdeczko]

In the upcoming patch we will change the way how to recognize
when GuC is in use. Using helper macros will minimize scope
of that changes. While here, update dev_info message.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.h|  4 
 drivers/gpu/drm/i915/i915_gem_context.c|  4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
 drivers/gpu/drm/i915/i915_irq.c|  2 +-
 drivers/gpu/drm/i915/intel_guc.c   |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c   |  6 +++---
 drivers/gpu/drm/i915/intel_gvt.c   |  2 +-
 drivers/gpu/drm/i915/intel_uc.c| 23 +++
 drivers/gpu/drm/i915/selftests/intel_guc.c |  2 +-
 9 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4c3616b..2c386c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3237,6 +3237,10 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_HUC(dev_priv)  (HAS_GUC(dev_priv))
 #define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
+/* Having a GuC is not the same as using a GuC */
+#define USES_GUC(dev_priv) (i915_modparams.enable_guc_loading)
+#define USES_GUC_SUBMISSION(dev_priv)  (i915_modparams.enable_guc_submission)
+
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index ce3139e..21ce374 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -316,7 +316,7 @@ __create_hw_context(struct drm_i915_private *dev_priv,
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
+   if (USES_GUC(dev_priv))
ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
@@ -409,7 +409,7 @@ i915_gem_context_create_gvt(struct drm_device *dev)
i915_gem_context_set_closed(ctx); /* not user accessible */
i915_gem_context_clear_bannable(ctx);
i915_gem_context_set_force_single_submission(ctx);
-   if (!i915_modparams.enable_guc_submission)
+   if (!USES_GUC_SUBMISSION(to_i915(dev)))
ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
 
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f3c35e8..209bb11 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3503,7 +3503,7 @@ int i915_ggtt_probe_hw(struct drm_i915_private *dev_priv)
 * currently don't have any bits spare to pass in this upper
 * restriction!
 */
-   if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading) {
+   if (USES_GUC(dev_priv)) {
ggtt->base.total = min_t(u64, ggtt->base.total, GUC_GGTT_TOP);
ggtt->mappable_end = min(ggtt->mappable_end, ggtt->base.total);
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7cac07d..3517c65 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1400,7 +1400,7 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
 
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
notify_ring(engine);
-   tasklet |= i915_modparams.enable_guc_submission;
+   tasklet |= USES_GUC_SUBMISSION(engine->i915);
}
 
if (tasklet)
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 8136478..39919e9 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -129,7 +129,7 @@ void intel_guc_init_params(struct intel_guc *guc)
}
 
/* If GuC submission is enabled, set up additional parameters here */
-   if (i915_modparams.enable_guc_submission) {
+   if (USES_GUC_SUBMISSION(dev_priv)) {
u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 76d3eb1..1a2c5ee 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -505,7 +505,7 @@ static void guc_flush_logs(struct intel_guc *guc)
 {
struct drm_i915_private