[Intel-gfx] [PULL] more gvt-next for 4.16

[Zhenyu Wang]

Hi,

Please pull more gvt-next updates for 4.16. Mostly on code and
regression fixes for last two gvt-next pulls and more refinement.
Details below.

thanks
--
The following changes since commit 1603660b3342269c95fcafee1945790342a8c28e:

  drm/i915/gvt: set max priority for gvt context (2017-12-04 11:24:35 +0800)

are available in the Git repository at:

  https://github.com/intel/gvt-linux.git tags/gvt-next-2017-12-14

for you to fetch changes up to 461bd6227ede277138bf33c2156b6ebd1fba04c2:

  drm/i915/gvt/fb_decoder: Fix out-of-bounds read (2017-12-11 17:18:39 +0800)


gvt-next-2017-12-14:

- fixes for two coverity scan errors (Colin)
- mmio switch code refine (Changbin)
- more virtual display dmabuf fixes (Tina/Gustavo)
- misc cleanups (Pei)


Changbin Du (4):
  drm/i915/gvt: Refine the ring mmio list definition
  drm/i915/gvt: Select appropriate mmio list at initialization time
  drm/i915/gvt: Remove MMIO barrier in MMIO switch
  drm/i915/gvt: Rename file render.{c, h} to mmio_context.{c, h}

Colin Ian King (2):
  drm/i915/gvt: Add missing breaks in switch statement
  drm/i915/gvt: fix off-by-one comparison of ring_id

Gustavo A. R. Silva (1):
  drm/i915/gvt/fb_decoder: Fix out-of-bounds read

Pei Zhang (2):
  drm/i915/gvt/kvmgt: fill info for ROM/VGA region
  drm/i915/gvt: refine function emulate_mmio_read/write

Tina Zhang (1):
  drm/i915/gvt: Refine dmabuf_obj cleanup process

 drivers/gpu/drm/i915/gvt/Makefile  |   2 +-
 drivers/gpu/drm/i915/gvt/dmabuf.c  |  15 +-
 drivers/gpu/drm/i915/gvt/fb_decoder.c  |   6 +
 drivers/gpu/drm/i915/gvt/gvt.c |   2 +
 drivers/gpu/drm/i915/gvt/gvt.h |   4 +-
 drivers/gpu/drm/i915/gvt/handlers.c|   6 +-
 drivers/gpu/drm/i915/gvt/kvmgt.c   |   6 +-
 drivers/gpu/drm/i915/gvt/mmio.c|  36 ++-
 .../gpu/drm/i915/gvt/{render.c => mmio_context.c}  | 262 ++---
 .../gpu/drm/i915/gvt/{render.h => mmio_context.h}  |   9 +
 10 files changed, 181 insertions(+), 167 deletions(-)
 rename drivers/gpu/drm/i915/gvt/{render.c => mmio_context.c} (53%)
 rename drivers/gpu/drm/i915/gvt/{render.h => mmio_context.h} (91%)

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation (rev2)

[Patchwork]

== Series Details ==

Series: tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation 
(rev2)
URL   : https://patchwork.freedesktop.org/series/35101/
State : warning

== Summary ==

Test kms_draw_crc:
Subgroup draw-method-rgb565-mmap-wc-untiled:
skip   -> PASS   (shard-snb)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-busy-crc-atomic:
skip   -> PASS   (shard-hsw)
Subgroup flip-vs-cursor-varying-size:
skip   -> PASS   (shard-hsw) fdo#102670
Test pm_rc6_residency:
Subgroup rc6-accuracy:
pass   -> SKIP   (shard-snb)

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

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:10  skip:1164 
time:9538s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:11  skip:1391 
time:8107s
Blacklisted hosts:
shard-apltotal:2694 pass:1668 dwarn:1   dfail:0   fail:22  skip:1001 
time:13518s
shard-kbltotal:2712 pass:1774 dwarn:32  dfail:0   fail:25  skip:881 
time:11285s

== Logs ==

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

Re: [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> Hi,
> 
> I sent this individual i915 patch to our CI, and it is passing on all 
> platforms:
> 
> https://patchwork.freedesktop.org/series/34822/
> 
> Is it ok if I merge this to drm-tip already?

As long as you have this change in your tree, it should be safe.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/include/linux/pci.h?id=7912af5c835bd86f2b0347a480e0f40e2fab30d0


> 
> Regards, Joonas
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] GemniLake laptops goes power off directly after performing suspend

[Chris Chiu]

On Tue, Dec 12, 2017 at 9:32 PM, Imre Deak  wrote:
> On Fri, Dec 08, 2017 at 10:31:30AM +, Daniel Drake wrote:
>> Hi,
>>
>> Adding intel-gfx list in case i915 developers can help. Updated summary 
>> below.
>>
>> On Thu, Dec 7, 2017 at 2:14 AM, Chris Chiu  wrote:
>> > On Wed, Dec 6, 2017 at 9:34 PM, Rafael J. Wysocki  
>> > wrote:
>> > > On Wed, Dec 6, 2017 at 10:33 AM, Chris Chiu  wrote:
>> > >> On Wed, Dec 6, 2017 at 5:56 AM, Rafael J. Wysocki  
>> > >> wrote:
>> > >>> On Tuesday, December 5, 2017 5:19:03 PM CET Chris Chiu wrote:
>> >  On Tue, Dec 5, 2017 at 11:01 PM, Rafael J. Wysocki 
>> >   wrote:
>> >  > On Tue, Dec 5, 2017 at 11:32 AM, Chris Chiu  
>> >  > wrote:
>> >  >> I have 2 GemniLake laptops from ASUS, named X441MB and X507MA,
>> >  >> both go power off after I do "systemctl suspend" on top of kerne 
>> >  >> head
>> >  >> fd6d2e506ce6 (Merge tag 'docs-4.15-fixes' of 
>> >  >> git://git.lwn.net/linux).
>> >  >> I then wipe it out and install Windows RS3 instead, also goes to 
>> >  >> power
>> >  >> off after pressing media key for suspend(S3). Then I installed 
>> >  >> intel
>> >  >> graphic driver with the following version number, Windows has no
>> >  >> problem on suspend resume then.
>> >  >
>> >  > There is a suspend-related fix missing in 4.15-rc at this point, so
>> >  > please test 4.14.y or wait for the fix to be merged.
>> > 
>> >  You mean the suspend-related fix used to exist in 4.14? Could you 
>> >  point me
>> >  out which commit it is? Thanks
>> > >>>
>> > >>> I mean that suspend generally works in 4.14 and is currently broken
>> > >>> in 4.15-rc which requires a fix to be applied.  The fix in question is 
>> > >>> at:
>> > >>> https://lkml.org/lkml/2017/11/30/546
>> > >>> This is needed due to some changes made in 4.15-rc (with respect to 
>> > >>> 4.14)
>> > >>> that broke resume from suspend to RAM.
>> > >>
>> > >> I think maybe for GemniLake is a different issue. I tried 
>> > >> Ubuntu-4.14.0-11.13
>> > >> kernel and 4.13 kernel. Both go power off immediately.
>> > >
>> > > OK, so yes, this is a different issue.
>> > > Is that suspend-to-idle or suspend-to-RAM (ACPI S3)?
>> >
>> > It's ACPI S3, suspend-to RAM. Due to it power off immediately,
>> > difficult for me to collect useful information
>>
>> Multiple new Acer and Asus consumer products based on Intel GeminiLake
>> N4100/N5000 fail to go into S3 suspend-to-RAM. At the point when you
>> would normally expect the system to go into sleep, the computer
>> completely powers off.
>>
>> The same happens under Windows 10 RS3, until the following Intel
>> graphics driver is installed:
>>
>> Package: 530967
>> Intel(R) Graphics Driver: 23.20.16.4849
>> Intel(R) Display Audio Driver: 10.00.00.1
>>
>> After installing this driver, Windows can now go into S3 suspend and
>> also be resumed. I'm wondering if someone can check with the Windows
>> gfx driver developers what this driver does to affect S3 suspend, so
>> that we can fix up Linux behaviour.
>
> To check this from the GFX side, could you open a bug at [1]? Please try
> suspend/resume without the graphics driver loaded (booting with
> nomodeset) and if that works suspend/resume with first setting one of
> the test phases in /sys/power/state. Trying the drm-tip branch from [2]
> would be also helpful. Please provide the dmesg logs at each run when
> GFX is enabled, booting with drm.debug=0xe. Using netconsole or
> pstore could help gathering the log when the machine just powers off.
>
> Thanks,
> Imre
>
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI
> [2] git://anongit.freedesktop.org/drm-tip
>
>
>>
>> Thanks
>> Daniel
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Hi Imre,
Thanks for your feedback. I've opened a bug on
https://bugs.freedesktop.org/show_bug.cgi?id=104235 and attach a dmesg
log which shows the Linux does go into sleep while booting with
"nomodeset". I will try drm-tip then and update the ticket if anything
interesting

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

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation (rev2)

[Patchwork]

== Series Details ==

Series: tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation 
(rev2)
URL   : https://patchwork.freedesktop.org/series/35101/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
ea7015f1fabbdfdd52a145162c658d2e90161ec5 lib/core: Don't leak dummyloads 
between subtests

with latest DRM-Tip kernel build CI_DRM_3512
ad17a7aa7ae2 drm-tip: 2017y-12m-13d-21h-59m-15s UTC integration manifest

No testlist changes.

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:512s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:280s
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:509s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:488s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:475s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:268s
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:405s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:395s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:483s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:527s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:536s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:539s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:452s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:554s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:416s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:601s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:628s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:488s

== Logs ==

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

[Intel-gfx] [PATCH i-g-t v2] tests/gem_reset_stats: Fix retrieval of hangcheck stats expectation

[Antonio Argenziano]

The test expected IOCTL 'I915_GET_RESET_STATS' would return an error
when not root. That is no longer true in the driver since commit
4c9c0d09741d ("drm/i915: Fix retrieval of hangcheck stats") and therefore
the test was incorrectly failing.

v2:
- Add the commit that changed the behaviour in the Driver to the
  commit message (Michel)

Cc: Michel Thierry 
Cc: Arkadiusz Hiler 
Cc: Chris Wilson 
Signed-off-by: Antonio Argenziano 
---
 tests/gem_reset_stats.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/tests/gem_reset_stats.c b/tests/gem_reset_stats.c
index edc40767..0c36a7eb 100644
--- a/tests/gem_reset_stats.c
+++ b/tests/gem_reset_stats.c
@@ -605,10 +605,7 @@ static void test_reset_count(const struct 
intel_execution_engine *e,
 
c2 = get_reset_count(fd, ctx);
 
-   if (ctx == 0)
-   igt_assert(c2 == -EPERM);
-   else
-   igt_assert(c2 == 0);
+   igt_assert(c2 == 0);
}
 
igt_waitchildren();
@@ -619,6 +616,11 @@ static void test_reset_count(const struct 
intel_execution_engine *e,
close(fd);
 }
 
+static int __get_reset_stats(int fd, struct local_drm_i915_reset_stats *rs)
+{
+   return drmIoctl(fd, GET_RESET_STATS_IOCTL, );
+}
+
 static int _test_params(int fd, int ctx, uint32_t flags, uint32_t pad)
 {
struct local_drm_i915_reset_stats rs;
@@ -644,10 +646,17 @@ static void _check_param_ctx(const int fd, const int ctx, 
const cap_t cap)
const uint32_t bad = rand() + 1;
 
if (ctx == 0) {
-   if (cap == root)
-   igt_assert_eq(_test_params(fd, ctx, 0, 0), 0);
-   else
-   igt_assert_eq(_test_params(fd, ctx, 0, 0), -EPERM);
+   igt_assert_eq(_test_params(fd, ctx, 0, 0), 0);
+
+   if (cap != root) {
+   struct local_drm_i915_reset_stats rs;
+   rs.ctx_id = ctx;
+   rs.reset_count = rand();
+   rs.batch_active = rand();
+   rs.batch_pending = rand();
+   igt_assert(__get_reset_stats(fd, ));
+   igt_assert(rs.reset_count != 0);
+   }
}
 
igt_assert_eq(_test_params(fd, ctx, 0, bad), -EINVAL);
-- 
2.14.2

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [CI,1/7] drm/i915/guc: Move shared data allocation away from submission path

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/guc: Move shared data allocation 
away from submission path
URL   : https://patchwork.freedesktop.org/series/35321/
State : warning

== Summary ==

Warning: bzip Patchwork_7492/shard-snb5/results20.json.bz2 wasn't in correct 
JSON format
Test kms_draw_crc:
Subgroup draw-method-rgb565-mmap-wc-untiled:
skip   -> PASS   (shard-snb)
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
skip   -> PASS   (shard-hsw) fdo#102670
Subgroup flip-vs-cursor-busy-crc-atomic:
skip   -> PASS   (shard-hsw)
Test kms_plane:
Subgroup plane-position-hole-pipe-a-planes:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-64x64-onscreen:
pass   -> SKIP   (shard-hsw)
Subgroup cursor-256x256-suspend:
pass   -> FAIL   (shard-snb) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test drv_suspend:
Subgroup fence-restore-tiled2untiled:
pass   -> SKIP   (shard-snb)

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

shard-hswtotal:2712 pass:1535 dwarn:1   dfail:0   fail:10  skip:1166 
time:9453s
shard-snbtotal:2636 pass:1269 dwarn:2   dfail:0   fail:12  skip:1353 
time:7672s
Blacklisted hosts:
shard-apltotal:2712 pass:1689 dwarn:1   dfail:0   fail:21  skip:1001 
time:13899s
shard-kbltotal:2712 pass:1775 dwarn:33  dfail:0   fail:23  skip:881 
time:11161s

== Logs ==

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

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/drm_edid.c

between commit:

  4b4df570b41d ("drm: Update edid-derived drm_display_info fields at edid 
property set [v2]")

from the drm-misc-fixes tree and commit:

  c945b8c14bb7 ("drm/edid: build ELD in drm_add_edid_modes()")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/drm_edid.c
index cb487148359a,524eace3d460..
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@@ -4653,6 -4645,10 +4671,8 @@@ int drm_add_edid_modes(struct drm_conne
return 0;
}
  
 -  quirks = edid_get_quirks(edid);
 -
+   drm_edid_to_eld(connector, edid);
+ 
/*
 * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks.
 * To avoid multiple parsing of same block, lets parse that map
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning

[Yaodong Li]

On 12/13/2017 01:34 PM, Michal Wajdeczko wrote:
On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li  
wrote:



On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:

On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:

Hardware may have specific restrictions on GuC WOPCM partition
size versus HuC firmware size. With static WOPCM partitioning,
there's no way to adjust the GuC WOPCM partition size based on
the actual HuC firmware size, so that GuC/HuC loading failure
would occur even if there was enough WOPCM space for both
GuC and HuC firmware.

WOPCM being a shared feature of the hardware, it should not go under
intel_guc_ prefix.

There should be a clear division of what is specific to GuC feature
only and what is just a feature that happens to be used by GuC (and
equally can be used by HuC too).

the intel_guc_wopcm here only refers to the wopcm used by
GuC, this structure only defines the GuC related wopcm info.
(wopcm partition for GuC). We only need to set these values
(defined in this structure) to GuC registers. And this structure
should never be touched if GuC was disabled. so it should be
a part of GuC.



But note that yours intel_guc_wopcm is just one of many wopcm partitions.
I think it would be a good idea to create "intel_wopcm.c|h" and keep
all related code and data there (including verification of early setup
done by bios, wopcpm reporting, partitioning).

Then we can do rest of the programming right there or just take values 
that

will be programmed individually by interested components (but former is
preferred to avoid spreading single feature code over too many places)

The KMD only needs to take care of the setup of the GuC WOPCM partition. 
Other
HW WOPCM (e.g HuC) usages are all transparent to kernel driver. Plus, 
the GuC WOPM
partitioning is needed only when GuC is enabled and uc firmwares are 
loaded correctly.
The only reason for us to have an intel_wopcm is to maintain the overall 
WOPCM info
such as WOPCM size and base. However, it's not necessary since we can 
reuse existing

driver code to get these info.

Regards,
-Jackie

Michal


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

[Intel-gfx] ✗ Fi.CI.IGT: warning for x86/gpu: add CFL to early quirks (rev2)

[Patchwork]

== Series Details ==

Series: x86/gpu: add CFL to early quirks (rev2)
URL   : https://patchwork.freedesktop.org/series/35109/
State : warning

== Summary ==

Test gem_softpin:
Subgroup noreloc-s4:
fail   -> SKIP   (shard-snb) fdo#103375 +2
Test pm_rc6_residency:
Subgroup rc6-accuracy:
pass   -> SKIP   (shard-snb)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
skip   -> PASS   (shard-snb)
Test drv_suspend:
Subgroup debugfs-reader:
skip   -> PASS   (shard-hsw)
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623

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

shard-hswtotal:2712 pass:1536 dwarn:1   dfail:0   fail:11  skip:1164 
time:9439s
shard-snbtotal:2712 pass:1308 dwarn:1   dfail:0   fail:10  skip:1393 
time:8009s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7490/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 series starting with [CI,1/7] drm/i915/guc: Move shared data allocation away from submission path

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/7] drm/i915/guc: Move shared data allocation 
away from submission path
URL   : https://patchwork.freedesktop.org/series/35321/
State : success

== Summary ==

Series 35321v1 series starting with [CI,1/7] drm/i915/guc: Move shared data 
allocation away from submission path
https://patchwork.freedesktop.org/api/1.0/series/35321/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
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:504s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:488s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:273s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:391s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:484s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:522s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:473s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:528s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
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:449s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:553s
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:595s
fi-cnl-y total:250  pass:224  dwarn:0   dfail:0   fail:0   skip:25 
fi-glk-dsi   total:288  pass:168  dwarn:1   dfail:4   fail:1   skip:114 
time:315s

ad17a7aa7ae2195ef6cd4a5da3fbf34fc25abc68 drm-tip: 2017y-12m-13d-21h-59m-15s UTC 
integration manifest
2502daf6aaa7 drm/i915/guc: Extract doorbell verification into a function
2908d7839a66 drm/i915/guc: Extract clients allocation to submission_init
7fc6d2cb806b drm/i915/guc: Extract doorbell creation from client allocation
04eb024a6da0 drm/i915/guc: Call invalidate after changing the vfunc
900653ecd27a drm/i915/guc: Extract guc_init from guc_init_hw
049e5dfa77f7 drm/i915/guc: Move GuC workqueue allocations outside of the mutex
35d19c216130 drm/i915/guc: Move shared data allocation away from submission path

== Logs ==

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

[Intel-gfx] [CI 7/7] drm/i915/guc: Extract doorbell verification into a function

[Michał Winiarski]

We have the selftest that's checking doorbell create/destroy, so there's
no need to check all doorbells delaying the reset every time.
We do want to have that extra sanity check at module load/unload though.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Reviewed-by: Michal Wajdeczko 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 488110602e7e..4d2409466a3a 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -820,9 +820,19 @@ static bool doorbell_ok(struct intel_guc *guc, u16 db_id)
return false;
 }
 
-static int guc_clients_doorbell_init(struct intel_guc *guc)
+static bool guc_verify_doorbells(struct intel_guc *guc)
 {
u16 db_id;
+
+   for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id)
+   if (!doorbell_ok(guc, db_id))
+   return false;
+
+   return true;
+}
+
+static int guc_clients_doorbell_init(struct intel_guc *guc)
+{
int ret;
 
ret = create_doorbell(guc->execbuf_client);
@@ -835,10 +845,6 @@ static int guc_clients_doorbell_init(struct intel_guc *guc)
return ret;
}
 
-   /* Read back & verify all (used & unused) doorbell registers */
-   for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id)
-   WARN_ON(!doorbell_ok(guc, db_id));
-
return 0;
 }
 
@@ -1149,6 +1155,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
 
+   WARN_ON(!guc_verify_doorbells(guc));
ret = guc_clients_create(guc);
if (ret)
return ret;
@@ -1177,6 +1184,8 @@ void intel_guc_submission_fini(struct intel_guc *guc)
cancel_work_sync(>preempt_work[id].work);
 
guc_clients_destroy(guc);
+   WARN_ON(!guc_verify_doorbells(guc));
+
guc_ads_destroy(guc);
intel_guc_log_destroy(guc);
guc_stage_desc_pool_destroy(guc);
-- 
2.14.3

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

[Intel-gfx] [CI 6/7] drm/i915/guc: Extract clients allocation to submission_init

[Michał Winiarski]

We can now move the clients allocation to submission_init path, rather
than keeping the condition inside submission_enable called on every
reset.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 33 ++---
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index c74e78b6ba41..488110602e7e 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1149,6 +1149,10 @@ int intel_guc_submission_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
 
+   ret = guc_clients_create(guc);
+   if (ret)
+   return ret;
+
for_each_engine(engine, dev_priv, id) {
guc->preempt_work[id].engine = engine;
INIT_WORK(>preempt_work[id].work, inject_preempt_context);
@@ -1172,6 +1176,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
for_each_engine(engine, dev_priv, id)
cancel_work_sync(>preempt_work[id].work);
 
+   guc_clients_destroy(guc);
guc_ads_destroy(guc);
intel_guc_log_destroy(guc);
guc_stage_desc_pool_destroy(guc);
@@ -1277,28 +1282,18 @@ int intel_guc_submission_enable(struct intel_guc *guc)
 sizeof(struct guc_wq_item) *
 I915_NUM_ENGINES > GUC_WQ_SIZE);
 
-   /*
-* We're being called on both module initialization and on reset,
-* until this flow is changed, we're using regular client presence to
-* determine which case are we in, and whether we should allocate new
-* clients or just reset their workqueues.
-*/
-   if (!guc->execbuf_client) {
-   err = guc_clients_create(guc);
-   if (err)
-   return err;
-   } else {
-   guc_reset_wq(guc->execbuf_client);
-   guc_reset_wq(guc->preempt_client);
-   }
+   GEM_BUG_ON(!guc->execbuf_client);
+
+   guc_reset_wq(guc->execbuf_client);
+   guc_reset_wq(guc->preempt_client);
 
err = intel_guc_sample_forcewake(guc);
if (err)
-   goto err_free_clients;
+   return err;
 
err = guc_clients_doorbell_init(guc);
if (err)
-   goto err_free_clients;
+   return err;
 
/* Take over from manual control of ELSP (execlists) */
guc_interrupts_capture(dev_priv);
@@ -1315,10 +1310,6 @@ int intel_guc_submission_enable(struct intel_guc *guc)
}
 
return 0;
-
-err_free_clients:
-   guc_clients_destroy(guc);
-   return err;
 }
 
 void intel_guc_submission_disable(struct intel_guc *guc)
@@ -1332,8 +1323,6 @@ void intel_guc_submission_disable(struct intel_guc *guc)
 
/* Revert back to manual ELSP submission */
intel_engines_reset_default_submission(dev_priv);
-
-   guc_clients_destroy(guc);
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
-- 
2.14.3

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

[Intel-gfx] [CI 5/7] drm/i915/guc: Extract doorbell creation from client allocation

[Michał Winiarski]

Full GPU reset causes GuC to be reset. This means that every time we're
doing a reset, we need to talk to GuC and tell it about doorbells.
Let's separate the communication part (create_doorbell) from our
internal bookkeeping (reserve_doorbell) so that we can cleanly separate
the initialization done at module load from reinitialization done at
reset in the following patch.
While I'm here, let's also add a proper (although slightly asymetric)
cleanup that doesn't try to communicate with GuC after it's already
gone, getting rid of "expected" warnings caused by GuC action failures
on module unload.

Note that I've also removed one of the tests (bitmap out of sync), since
it doesn't make much sense anymore - bitmaps are now not expected to
change during the lifetime of a client.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
Reviewed-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 151 
 drivers/gpu/drm/i915/selftests/intel_guc.c  | 110 +---
 2 files changed, 88 insertions(+), 173 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 8f4b274d66a7..c74e78b6ba41 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -88,7 +88,7 @@ static inline bool is_high_priority(struct intel_guc_client 
*client)
client->priority == GUC_CLIENT_PRIORITY_HIGH);
 }
 
-static int __reserve_doorbell(struct intel_guc_client *client)
+static int reserve_doorbell(struct intel_guc_client *client)
 {
unsigned long offset;
unsigned long end;
@@ -120,7 +120,7 @@ static int __reserve_doorbell(struct intel_guc_client 
*client)
return 0;
 }
 
-static void __unreserve_doorbell(struct intel_guc_client *client)
+static void unreserve_doorbell(struct intel_guc_client *client)
 {
GEM_BUG_ON(client->doorbell_id == GUC_DOORBELL_INVALID);
 
@@ -188,32 +188,21 @@ static bool has_doorbell(struct intel_guc_client *client)
return test_bit(client->doorbell_id, client->guc->doorbell_bitmap);
 }
 
-static int __create_doorbell(struct intel_guc_client *client)
+static void __create_doorbell(struct intel_guc_client *client)
 {
struct guc_doorbell_info *doorbell;
-   int err;
 
doorbell = __get_doorbell(client);
doorbell->db_status = GUC_DOORBELL_ENABLED;
doorbell->cookie = 0;
-
-   err = __guc_allocate_doorbell(client->guc, client->stage_id);
-   if (err) {
-   doorbell->db_status = GUC_DOORBELL_DISABLED;
-   DRM_ERROR("Couldn't create client %u doorbell: %d\n",
- client->stage_id, err);
-   }
-
-   return err;
 }
 
-static int __destroy_doorbell(struct intel_guc_client *client)
+static void __destroy_doorbell(struct intel_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(client->guc);
struct guc_doorbell_info *doorbell;
u16 db_id = client->doorbell_id;
 
-   GEM_BUG_ON(db_id >= GUC_DOORBELL_INVALID);
 
doorbell = __get_doorbell(client);
doorbell->db_status = GUC_DOORBELL_DISABLED;
@@ -225,50 +214,42 @@ static int __destroy_doorbell(struct intel_guc_client 
*client)
 */
if (wait_for_us(!(I915_READ(GEN8_DRBREGL(db_id)) & GEN8_DRB_VALID), 10))
WARN_ONCE(true, "Doorbell never became invalid after 
disable\n");
-
-   return __guc_deallocate_doorbell(client->guc, client->stage_id);
 }
 
 static int create_doorbell(struct intel_guc_client *client)
 {
int ret;
 
-   ret = __reserve_doorbell(client);
-   if (ret)
-   return ret;
-
__update_doorbell_desc(client, client->doorbell_id);
+   __create_doorbell(client);
 
-   ret = __create_doorbell(client);
-   if (ret)
-   goto err;
+   ret = __guc_allocate_doorbell(client->guc, client->stage_id);
+   if (ret) {
+   __destroy_doorbell(client);
+   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
+   DRM_ERROR("Couldn't create client %u doorbell: %d\n",
+ client->stage_id, ret);
+   return ret;
+   }
 
return 0;
-
-err:
-   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
-   __unreserve_doorbell(client);
-   return ret;
 }
 
 static int destroy_doorbell(struct intel_guc_client *client)
 {
-   int err;
+   int ret;
 
GEM_BUG_ON(!has_doorbell(client));
 
-   /* XXX: wait for any interrupts */
-   /* XXX: wait for workqueue to drain */
-
-   err = __destroy_doorbell(client);
-   if (err)
-   return err;
+   __destroy_doorbell(client);

[Intel-gfx] [CI 4/7] drm/i915/guc: Call invalidate after changing the vfunc

[Michał Winiarski]

To make this operation a bit cleaner, we should make sure that the HW
can catch up by calling the new implementation right away.
Note that currently we're only touching the vfunc at module load time
(before GuC is even loaded), so this shouldn't cause any functional
changes.

Suggested-by: Chris Wilson 
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a0579b0c8581..c5f393870532 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3552,6 +3552,8 @@ 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;
+
+   i915_ggtt_invalidate(i915);
 }
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
@@ -3560,6 +3562,8 @@ void i915_ggtt_disable_guc(struct drm_i915_private *i915)
GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
 
i915->ggtt.invalidate = gen6_ggtt_invalidate;
+
+   i915_ggtt_invalidate(i915);
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
-- 
2.14.3

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

[Intel-gfx] [CI 1/7] drm/i915/guc: Move shared data allocation away from submission path

[Michał Winiarski]

We need shared data for actions (e.g. guc suspend/resume), and we're
using those with GuC submission disabled.
Let's introduce intel_guc_init and move shared data alloc there.

This fixes GPF during module unload with HuC, but without GuC submission:

BUG: unable to handle kernel NULL pointer dereference at 5aee7809
IP: intel_guc_suspend+0x34/0x140 [i915]
PGD 0 P4D 0
Oops:  [#1] PREEMPT SMP
Modules linked in: i915(O-) netconsole x86_pkg_temp_thermal
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
mei_me i2c_i801 mei prime_numbers [last unloaded: i915]
CPU: 2 PID: 2794 Comm: rmmod Tainted: G U  W  O 4.15.0-rc2+ #297
Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016
task: 55945c61 task.stack: 264ccb43
RIP: 0010:intel_guc_suspend+0x34/0x140 [i915]
RSP: 0018:c9483df8 EFLAGS: 00010286
RAX:  RBX: 88082918 RCX: 
RDX: 0006 RSI: 880844c2c938 RDI: 880844c2c000
RBP: 88082918 R08: a29c58c1 R09: 
R10:  R11:  R12: a040ba40
R13: a040bab0 R14: 88084a195060 R15: 55df3ef357a0
FS:  7ff43c043740() GS:88084e20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 00f9 CR3: 00083f179005 CR4: 003606e0
Call Trace:
 i915_gem_suspend+0x9d/0x130 [i915]
 ? i915_driver_unload+0x68/0x180 [i915]
 i915_driver_unload+0x70/0x180 [i915]
 i915_pci_remove+0x15/0x20 [i915]
 pci_device_remove+0x36/0xb0
 device_release_driver_internal+0x15f/0x220
 driver_detach+0x3a/0x80
 bus_remove_driver+0x58/0xd0
 pci_unregister_driver+0x29/0x90
 SyS_delete_module+0x150/0x1e0
 entry_SYSCALL_64_fastpath+0x23/0x9a
RIP: 0033:0x7ff43b51b5c7
RSP: 002b:7ffe6825a758 EFLAGS: 0206 ORIG_RAX: 00b0
RAX: ffda RBX: 0003 RCX: 7ff43b51b5c7
RDX: 000a RSI: 0800 RDI: 55df3ef35808
RBP:  R08: 7ffe682596d1 R09: 
R10: 7ff43b594880 R11: 0206 R12: 55df3ef357a0
R13: 7ffe68259740 R14: 55df3ef35260 R15: 55df3ef357a0
Code: 00 00 02 74 03 31 c0 c3 53 48 89 fb 48 83 ec 10 e8 52 0f
f8 ff 48 b8 01 05 00 00 02 00 00 00 48 89 44 24 04 48 8b 83 00 12 00 00  80
f9 00 00 00 01 0f 84 a7 00 00 00 f6 80 98 00 00 00 01 0f
RIP: intel_guc_suspend+0x34/0x140 [i915] RSP: c9483df8
CR2: 00f9
---[ end trace 23a192a61d937a3e ]---

Fixes: b8e5eb960b28 ("drm/i915/guc: Allocate separate shared data object for 
GuC communication")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc.c| 51 +
 drivers/gpu/drm/i915/intel_guc.h|  2 ++
 drivers/gpu/drm/i915/intel_guc_submission.c | 37 +
 drivers/gpu/drm/i915/intel_uc.c | 10 +++---
 4 files changed, 60 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 177ee69ca9b1..92ed22f38fc4 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -69,6 +69,57 @@ void intel_guc_init_early(struct intel_guc *guc)
guc->notify = gen8_guc_raise_irq;
 }
 
+static int guc_shared_data_create(struct intel_guc *guc)
+{
+   struct i915_vma *vma;
+   void *vaddr;
+
+   vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
+
+   vaddr = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   i915_vma_unpin_and_release();
+   return PTR_ERR(vaddr);
+   }
+
+   guc->shared_data = vma;
+   guc->shared_data_vaddr = vaddr;
+
+   return 0;
+}
+
+static void guc_shared_data_destroy(struct intel_guc *guc)
+{
+   i915_gem_object_unpin_map(guc->shared_data->obj);
+   i915_vma_unpin_and_release(>shared_data);
+}
+
+int intel_guc_init(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   int ret;
+
+   ret = guc_shared_data_create(guc);
+   if (ret)
+   return ret;
+   GEM_BUG_ON(!guc->shared_data);
+
+   /* We need to notify the guc whenever we change the GGTT */
+   i915_ggtt_enable_guc(dev_priv);
+
+   return 0;
+}
+
+void intel_guc_fini(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   i915_ggtt_disable_guc(dev_priv);
+   guc_shared_data_destroy(guc);
+}
+
 static u32 get_gt_type(struct drm_i915_private *dev_priv)
 {
/* XXX: GT type based on PCI device ID? field seems unused by fw */
diff --git a/drivers/gpu/drm/i915/intel_guc.h 

[Intel-gfx] [CI 3/7] drm/i915/guc: Extract guc_init from guc_init_hw

[Michał Winiarski]

After GPU reset, GuC HW needs to be reinitialized (with FW reload).
Unfortunately, we're doing some extra work there (mostly allocating stuff),
work that can be moved to guc_init and called once at driver load time.

As a side effect we're no longer hitting an assert in
i915_ggtt_enable_guc on suspend/resume.

v2: Do not duplicate disable_communication / reset_guc_interrupts
v3: Add proper teardown after rebase

References: 04f7b24eccdf ("drm/i915/guc: Assert that we switch between known 
ggtt->invalidate functions")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |  1 +
 drivers/gpu/drm/i915/i915_gem.c |  8 -
 drivers/gpu/drm/i915/intel_uc.c | 71 ++---
 drivers/gpu/drm/i915/intel_uc.h |  2 ++
 4 files changed, 56 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 285c8b238bff..ca9f4b2862eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -617,6 +617,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
 
mutex_lock(_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
+   intel_uc_fini(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2c13e3a4f45a..4a7f5579a7a5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5196,10 +5196,14 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 
intel_init_gt_powersave(dev_priv);
 
-   ret = i915_gem_init_hw(dev_priv);
+   ret = intel_uc_init(dev_priv);
if (ret)
goto err_pm;
 
+   ret = i915_gem_init_hw(dev_priv);
+   if (ret)
+   goto err_uc_init;
+
/*
 * Despite its name intel_init_clock_gating applies both display
 * clock gating workarounds; GT mmio workarounds and the occasional
@@ -5240,6 +5244,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
i915_gem_wait_for_idle(dev_priv, I915_WAIT_LOCKED);
i915_gem_contexts_lost(dev_priv);
intel_uc_fini_hw(dev_priv);
+err_uc_init:
+   intel_uc_fini(dev_priv);
 err_pm:
if (ret != -EIO) {
intel_cleanup_gt_powersave(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 785850838a44..907deac6e3fa 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -214,26 +214,20 @@ void intel_uc_fini_wq(struct drm_i915_private *dev_priv)
intel_guc_fini_wq(_priv->guc);
 }
 
-int intel_uc_init_hw(struct drm_i915_private *dev_priv)
+int intel_uc_init(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
-   struct intel_huc *huc = _priv->huc;
-   int ret, attempts;
+   int ret;
 
if (!USES_GUC(dev_priv))
return 0;
 
-   if (!HAS_GUC(dev_priv)) {
-   ret = -ENODEV;
-   goto err_out;
-   }
-
-   guc_disable_communication(guc);
-   gen9_reset_guc_interrupts(dev_priv);
+   if (!HAS_GUC(dev_priv))
+   return -ENODEV;
 
ret = intel_guc_init(guc);
if (ret)
-   goto err_out;
+   return ret;
 
if (USES_GUC_SUBMISSION(dev_priv)) {
/*
@@ -241,10 +235,44 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * if we are planning to enable submission later
 */
ret = intel_guc_submission_init(guc);
-   if (ret)
-   goto err_guc;
+   if (ret) {
+   intel_guc_fini(guc);
+   return ret;
+   }
}
 
+   return 0;
+}
+
+void intel_uc_fini(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+
+   if (!USES_GUC(dev_priv))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(dev_priv));
+
+   if (USES_GUC_SUBMISSION(dev_priv))
+   intel_guc_submission_fini(guc);
+
+   intel_guc_fini(guc);
+}
+
+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))
+   return 0;
+
+   GEM_BUG_ON(!HAS_GUC(dev_priv));
+
+   guc_disable_communication(guc);
+   gen9_reset_guc_interrupts(dev_priv);
+
/* init WOPCM */
I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));

[Intel-gfx] [CI 2/7] drm/i915/guc: Move GuC workqueue allocations outside of the mutex

[Michał Winiarski]

This gets rid of the following lockdep splat:

==
WARNING: possible circular locking dependency detected
4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
--
debugfs_test/1351 is trying to acquire lock:
 (>struct_mutex){+.+.}, at: [<9d90d1a3>] 
i915_mutex_lock_interruptible+0x47/0x130 [i915]

but task is already holding lock:
 (>mmap_sem){}, at: [<5df01c1e>] __do_page_fault+0x106/0x560

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #6 (>mmap_sem){}:
   __might_fault+0x63/0x90
   _copy_to_user+0x1e/0x70
   filldir+0x8c/0xf0
   dcache_readdir+0xeb/0x160
   iterate_dir+0xe6/0x150
   SyS_getdents+0xa0/0x130
   entry_SYSCALL_64_fastpath+0x1c/0x89

-> #5 (>s_type->i_mutex_key#5){}:
   lockref_get+0x9/0x20

-> #4 ((completion)){+.+.}:
   wait_for_common+0x54/0x210
   devtmpfs_create_node+0x130/0x150
   device_add+0x5ad/0x5e0
   device_create_groups_vargs+0xd4/0xe0
   device_create+0x35/0x40
   msr_device_create+0x22/0x40
   cpuhp_invoke_callback+0xc5/0xbf0
   cpuhp_thread_fun+0x167/0x210
   smpboot_thread_fn+0x17f/0x270
   kthread+0x173/0x1b0
   ret_from_fork+0x24/0x30

-> #3 (cpuhp_state-up){+.+.}:
   cpuhp_issue_call+0x132/0x1c0
   __cpuhp_setup_state_cpuslocked+0x12f/0x2a0
   __cpuhp_setup_state+0x3a/0x50
   page_writeback_init+0x3a/0x5c
   start_kernel+0x393/0x3e2
   secondary_startup_64+0xa5/0xb0

-> #2 (cpuhp_state_mutex){+.+.}:
   __mutex_lock+0x81/0x9b0
   __cpuhp_setup_state_cpuslocked+0x4b/0x2a0
   __cpuhp_setup_state+0x3a/0x50
   page_alloc_init+0x1f/0x26
   start_kernel+0x139/0x3e2
   secondary_startup_64+0xa5/0xb0

-> #1 (cpu_hotplug_lock.rw_sem){}:
   cpus_read_lock+0x34/0xa0
   apply_workqueue_attrs+0xd/0x40
   __alloc_workqueue_key+0x2c7/0x4e1
   intel_guc_submission_init+0x10c/0x650 [i915]
   intel_uc_init_hw+0x29e/0x460 [i915]
   i915_gem_init_hw+0xca/0x290 [i915]
   i915_gem_init+0x115/0x3a0 [i915]
   i915_driver_load+0x9a8/0x16c0 [i915]
   i915_pci_probe+0x2e/0x90 [i915]
   pci_device_probe+0x9c/0x120
   driver_probe_device+0x2a3/0x480
   __driver_attach+0xd9/0xe0
   bus_for_each_dev+0x57/0x90
   bus_add_driver+0x168/0x260
   driver_register+0x52/0xc0
   do_one_initcall+0x39/0x150
   do_init_module+0x56/0x1ef
   load_module+0x231c/0x2d70
   SyS_finit_module+0xa5/0xe0
   entry_SYSCALL_64_fastpath+0x1c/0x89

-> #0 (>struct_mutex){+.+.}:
   lock_acquire+0xaf/0x200
   __mutex_lock+0x81/0x9b0
   i915_mutex_lock_interruptible+0x47/0x130 [i915]
   i915_gem_fault+0x201/0x760 [i915]
   __do_fault+0x15/0x70
   __handle_mm_fault+0x85b/0xe40
   handle_mm_fault+0x14f/0x2f0
   __do_page_fault+0x2d1/0x560
   page_fault+0x22/0x30

other info that might help us debug this:

Chain exists of:
  >struct_mutex --> >s_type->i_mutex_key#5 --> >mmap_sem

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(>mmap_sem);
   lock(>s_type->i_mutex_key#5);
   lock(>mmap_sem);
  lock(>struct_mutex);

 *** DEADLOCK ***

1 lock held by debugfs_test/1351:
 #0:  (>mmap_sem){}, at: [<5df01c1e>] 
__do_page_fault+0x106/0x560

stack backtrace:
CPU: 2 PID: 1351 Comm: debugfs_test Not tainted 4.15.0-rc2-CI-Patchwork_7428+ #1
Hardware name:  /NUC6i5SYB, BIOS 
SYSKLi35.86A.0057.2017.0119.1758 01/19/2017
Call Trace:
 dump_stack+0x5f/0x86
 print_circular_bug+0x230/0x3b0
 check_prev_add+0x439/0x7b0
 ? lockdep_init_map_crosslock+0x20/0x20
 ? unwind_get_return_address+0x16/0x30
 ? __lock_acquire+0x1385/0x15a0
 __lock_acquire+0x1385/0x15a0
 lock_acquire+0xaf/0x200
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 __mutex_lock+0x81/0x9b0
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 i915_mutex_lock_interruptible+0x47/0x130 [i915]
 ? __pm_runtime_resume+0x4f/0x80
 i915_gem_fault+0x201/0x760 [i915]
 __do_fault+0x15/0x70
 __handle_mm_fault+0x85b/0xe40
 handle_mm_fault+0x14f/0x2f0
 __do_page_fault+0x2d1/0x560
 page_fault+0x22/0x30
RIP: 0033:0x7f98d6f49116
RSP: 002b:7ffd6ffc3278 EFLAGS: 00010283
RAX: 7f98d39a2bc0 RBX:  RCX: 1680
RDX: 1680 RSI: 7ffd6ffc3400 RDI: 7f98d39a2bc0
RBP: 7ffd6ffc33a0 R08:  R09: 05a0
R10: 55e847c2a830 R11: 0002 R12: 0001
R13: 55e847c1d040 R14: 7ffd6ffc3400 R15: 7f98d6752ba0

v2: Init preempt_work unconditionally (Chris)
v3: Mention that we need the enable_guc=1 for lockdep splat (Chris)

Testcase: 

Re: [Intel-gfx] Non-blocking commits on -ERESTARTSYS

[Leo Li]

On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:

Op 13-12-17 om 17:19 schreef Leo Li:

Hi Daniel, Maarten,

Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html

It's suppose to fix a memory leak on the drm_commit object during
non-blocking commits. Within drm_atomic_helper_setup_commit, a reference
to the commit object is obtained by the new_crtc_state. This reference
is suppose to be 'put' once flip_done is signaled (via the
release_crtc_commit callback), but never happens if .prepare_fb returns
-ERESTARTSYS: drm_atomic_helper_commit early returns before the
commit_tail work is queued.

We're starting to bump into this issue again. Regarding Daniel's
suggestion for an IGT test, has there been any work done on it? I'd be
interested in taking a look otherwise. As a side note, I can also
reproduce this on i915.

Thanks,
Leo


I'm curious, isn't it better to handle this in 
__drm_atomic_helper_crtc_destroy_state with the attached patch?


Good point, it seems sane to me. I gave it a spin and it fixes the issue.

I was concerned that it'll contend with the worker thread, possibly
freeing the crtc_commit before the flip is done. It seems the
atomic_state_get before the work is queued will prevent that.

Leo



No idea if sane though, but drivers are supposed to clear crtc_state->event on 
success..

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 593b30d38ce0..e71233b4c651 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3435,6 +3435,8 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
 void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
 {
if (state->commit) {
+   if (state->event)
+   drm_crtc_commit_put(state->commit);
kfree(state->commit->event);
state->commit->event = NULL;
drm_crtc_commit_put(state->commit);

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

Re: [Intel-gfx] [PATCH] drm: rework delayed connector cleanup in connector_iter

[Daniel Vetter]

On Wed, Dec 13, 2017 at 02:35:16PM +0100, Daniel Vetter wrote:
> On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote:
> > Quoting Daniel Vetter (2017-12-13 12:49:36)
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c 
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index 6ffe952142e6..7681269abe41 100644
> > > --- a/drivers/gpu/drm/drm_mode_config.c
> > > +++ b/drivers/gpu/drm/drm_mode_config.c
> > > @@ -382,6 +382,8 @@ void drm_mode_config_init(struct drm_device *dev)
> > > ida_init(>mode_config.connector_ida);
> > > spin_lock_init(>mode_config.connector_list_lock);
> > >  
> > > +   INIT_WORK(>mode_config.connector_free_work, 
> > > drm_connector_free_work_fn);
> > 
> > A init_llist_head(>mode_config.connector_free_list) wouldn't go
> > amiss here. So perhaps push the connectors init into its own exported
> > function from drm_connector.c as opposed to exposing the free_fn.
> 
> Imo it doesn't matter much how we go about drm.ko internals. But I'll
> stick the init_llist_head in there when applying, somehow I dind't find it
> (why is every kernel data type slightly different in this).
> 
> > Reviewed-by: Chris Wilson 

And applied with init_llist_head added.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning

[Michal Wajdeczko]

On Wed, 13 Dec 2017 19:19:06 +0100, Yaodong Li   
wrote:



On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:

On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:

Hardware may have specific restrictions on GuC WOPCM partition
size versus HuC firmware size. With static WOPCM partitioning,
there's no way to adjust the GuC WOPCM partition size based on
the actual HuC firmware size, so that GuC/HuC loading failure
would occur even if there was enough WOPCM space for both
GuC and HuC firmware.

WOPCM being a shared feature of the hardware, it should not go under
intel_guc_ prefix.

There should be a clear division of what is specific to GuC feature
only and what is just a feature that happens to be used by GuC (and
equally can be used by HuC too).

the intel_guc_wopcm here only refers to the wopcm used by
GuC, this structure only defines the GuC related wopcm info.
(wopcm partition for GuC). We only need to set these values
(defined in this structure) to GuC registers. And this structure
should never be touched if GuC was disabled. so it should be
a part of GuC.



But note that yours intel_guc_wopcm is just one of many wopcm partitions.
I think it would be a good idea to create "intel_wopcm.c|h" and keep
all related code and data there (including verification of early setup
done by bios, wopcpm reporting, partitioning).

Then we can do rest of the programming right there or just take values that
will be programmed individually by interested components (but former is
preferred to avoid spreading single feature code over too many places)

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Disable the fake-irq when disabled by the user/debugfs

[Patchwork]

== Series Details ==

Series: drm/i915: Disable the fake-irq when disabled by the user/debugfs
URL   : https://patchwork.freedesktop.org/series/35319/
State : warning

== Summary ==

Series 35319v1 drm/i915: Disable the fake-irq when disabled by the user/debugfs
https://patchwork.freedesktop.org/api/1.0/series/35319/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989 +5
incomplete -> PASS   (fi-snb-2520m)
Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#104058
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-each:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-many-each:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-store-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-store-each:
pass   -> SKIP   (fi-elk-e7500)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-elk-e7500)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-elk-e7500)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-elk-e7500)
Subgroup basic-await-all:
pass   -> SKIP   (fi-elk-e7500)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:444s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:379s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:513s
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:502s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
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:477s
fi-elk-e7500 total:229  pass:156  dwarn:13  dfail:0   fail:0   skip:59 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:266s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:540s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:408s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
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:477s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:480s
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:475s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
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:537s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:558s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:439s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:413s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:612s
fi-cnl-y total:216  pass:195  dwarn:0   dfail:0   fail:0   skip:20 
fi-glk-dsi   total:53   pass:45   dwarn:0   dfail:0   fail:0   skip:7  

e97b6bb4ff1a307c6b88435f2a629519f04d593b drm-tip: 2017y-12m-13d-19h-58m-44s UTC 
integration manifest
1fb6acf250a3 drm/i915: Disable the fake-irq when disabled by the user/debugfs

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7491/issues.html

[Intel-gfx] ✓ Fi.CI.BAT: success for x86/gpu: add CFL to early quirks (rev2)

[Patchwork]

== Series Details ==

Series: x86/gpu: add CFL to early quirks (rev2)
URL   : https://patchwork.freedesktop.org/series/35109/
State : success

== Summary ==

Series 35109v2 x86/gpu: add CFL to early quirks
https://patchwork.freedesktop.org/api/1.0/series/35109/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
incomplete -> PASS   (fi-snb-2520m)
Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172 +1
Subgroup suspend-read-crc-pipe-b:
notrun -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
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:442s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:382s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:507s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:483s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:470s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:270s
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:413s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:413s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:387s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:1   fail:0   skip:24  
time:486s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:519s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
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:539s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:562s
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:445s
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:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:603s
fi-cnl-y total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:638s
fi-glk-dsi   total:98   pass:54   dwarn:0   dfail:1   fail:0   skip:42 

e97b6bb4ff1a307c6b88435f2a629519f04d593b drm-tip: 2017y-12m-13d-19h-58m-44s UTC 
integration manifest
8d1ef03942ba x86/gpu: add CFL to early quirks

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Disable the fake-irq when disabled by the user/debugfs

[Chris Wilson]

Through debugfs, we expose methods for igt to check and control use of
the fake-irq (for missed breadcrumb detection). Currently, we don't
disable the fake-irq immediately after noticing the bit being cleared,
presuming that we will idle soon enough. However, we can check within
the fake-irq worker and switch back to the slow hangcheck if we notice
that the user disabled the fake-irq.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 58c624f982d9..acd7412eacb8 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -130,11 +130,12 @@ static void intel_breadcrumbs_hangcheck(struct timer_list 
*t)
 
 static void intel_breadcrumbs_fake_irq(struct timer_list *t)
 {
-   struct intel_engine_cs *engine = from_timer(engine, t,
-   breadcrumbs.fake_irq);
+   struct intel_engine_cs *engine =
+   from_timer(engine, t, breadcrumbs.fake_irq);
struct intel_breadcrumbs *b = >breadcrumbs;
 
-   /* The timer persists in case we cannot enable interrupts,
+   /*
+* The timer persists in case we cannot enable interrupts,
 * or if we have previously seen seqno/interrupt incoherency
 * ("missed interrupt" syndrome, better known as a "missed breadcrumb").
 * Here the worker will wake up every jiffie in order to kick the
@@ -148,9 +149,16 @@ static void intel_breadcrumbs_fake_irq(struct timer_list 
*t)
if (!b->irq_armed)
return;
 
+   /* If the user has disabled the fake-irq, restore the hangchecking */
+   if (!test_bit(engine->id, >i915->gpu_error.missed_irq_rings)) {
+   mod_timer(>hangcheck, wait_timeout());
+   return;
+   }
+
mod_timer(>fake_irq, jiffies + 1);
 
-   /* Ensure that even if the GPU hangs, we get woken up.
+   /*
+* Ensure that even if the GPU hangs, we get woken up.
 *
 * However, note that if no one is waiting, we never notice
 * a gpu hang. Eventually, we will have to wait for a resource
-- 
2.15.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/lpe: Remove double-encapsulation of info string

[Patchwork]

== Series Details ==

Series: drm/i915/lpe: Remove double-encapsulation of info string
URL   : https://patchwork.freedesktop.org/series/35303/
State : success

== Summary ==

Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (shard-hsw) fdo#103375

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

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:9   skip:1165 
time:9485s
shard-snbtotal:2712 pass:1308 dwarn:2   dfail:0   fail:11  skip:1391 
time:8018s
Blacklisted hosts:
shard-apltotal:2712 pass:1689 dwarn:1   dfail:0   fail:21  skip:1001 
time:14008s
shard-kbltotal:2712 pass:1807 dwarn:1   dfail:0   fail:24  skip:880 
time:11105s

== Logs ==

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

[Intel-gfx] [PATCH v2] x86/gpu: add CFL to early quirks

[Lucas De Marchi]

CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.

Fixes: b056f8f3d6b9 ("drm/i915/cfl: Add Coffee Lake PCI IDs for S Skus.")
Signed-off-by: Lucas De Marchi 
Cc: Rodrigo Vivi 
Cc: Anusha Srivatsa 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: David Airlie 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
Cc:  # v4.13+ 0890540e21cf drm/i915: add GT number to 
intel_device_info
Cc:  # v4.13+ 41693fd52373 drm/i915/kbl: Change a KBL 
pci id to GT2 from GT1.5
Cc:  # v4.13+
Reviewed-by: Rodrigo Vivi 
---

v2: improve commit message, add Fixes tag and CC stable

 arch/x86/kernel/early-quirks.c | 1 +
 include/drm/i915_pciids.h  | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 3cbb2c78a9df..bae0d32e327b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -528,6 +528,7 @@ static const struct pci_device_id intel_early_ids[] 
__initconst = {
INTEL_SKL_IDS(_early_ops),
INTEL_BXT_IDS(_early_ops),
INTEL_KBL_IDS(_early_ops),
+   INTEL_CFL_IDS(_early_ops),
INTEL_GLK_IDS(_early_ops),
INTEL_CNL_IDS(_early_ops),
 };
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 972a25633525..c65e4489006d 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -392,6 +392,12 @@
INTEL_VGA_DEVICE(0x3EA8, info), /* ULT GT3 */ \
INTEL_VGA_DEVICE(0x3EA5, info)  /* ULT GT3 */
 
+#define INTEL_CFL_IDS(info) \
+   INTEL_CFL_S_GT1_IDS(info), \
+   INTEL_CFL_S_GT2_IDS(info), \
+   INTEL_CFL_H_GT2_IDS(info), \
+   INTEL_CFL_U_GT3_IDS(info)
+
 /* CNL U 2+2 */
 #define INTEL_CNL_U_GT2_IDS(info) \
INTEL_VGA_DEVICE(0x5A52, info), \
-- 
2.14.3

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for tests/psr: Test vblank continuity with PSR enabled

[Patchwork]

== Series Details ==

Series: tests/psr: Test vblank continuity with PSR enabled
URL   : https://patchwork.freedesktop.org/series/35306/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
ea7015f1fabbdfdd52a145162c658d2e90161ec5 lib/core: Don't leak dummyloads 
between subtests

with latest DRM-Tip kernel build CI_DRM_3508
1a717c76c96c drm-tip: 2017y-12m-13d-14h-48m-36s UTC integration manifest

Testlist changes:
+igt@kms_psr_sink_crc@vblank

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-each:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-many-each:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-store-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-store-each:
pass   -> SKIP   (fi-pnv-d510)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-await-all:
pass   -> SKIP   (fi-pnv-d510)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-pnv-d510)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> SKIP   (fi-pnv-d510)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> DMESG-WARN (fi-skl-6600u)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-r)
Test kms_sink_crc_basic:
skip   -> INCOMPLETE (fi-skl-6600u)
skip   -> INCOMPLETE (fi-kbl-7560u)
skip   -> INCOMPLETE (fi-kbl-r)

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

fi-bdw-5557u total:289  pass:267  dwarn:0   dfail:0   fail:0   skip:22  
time:440s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:382s
fi-bsw-n3050 total:289  pass:242  dwarn:0   dfail:0   fail:0   skip:47  
time:511s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:282s
fi-bxt-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:0   skip:31  
time:511s
fi-bxt-j4205 total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-byt-j1900 total:289  pass:253  dwarn:0   dfail:0   fail:0   skip:36  
time:490s
fi-byt-n2820 total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:475s
fi-elk-e7500 total:224  pass:164  dwarn:14  dfail:0   fail:0   skip:45 
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:268s
fi-glk-1 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:536s
fi-hsw-4770  total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-hsw-4770r total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:390s
fi-ivb-3520m total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:474s
fi-ivb-3770  total:289  pass:255  dwarn:0   dfail:0   fail:0   skip:34  
time:435s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:0   skip:25  
time:486s
fi-kbl-7560u total:250  pass:231  dwarn:1   dfail:1   fail:0   skip:16 
fi-kbl-7567u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:474s
fi-kbl-r total:250  pass:222  dwarn:2   dfail:1   fail:0   skip:24 
fi-pnv-d510  total:289  pass:209  dwarn:1   dfail:0   fail:0   skip:79  
time:612s
fi-skl-6260u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-skl-6600u total:250  pass:223  dwarn:1   dfail:1   fail:0   skip:24 
fi-skl-6700hqtotal:289  pass:262  dwarn:0   dfail:0   fail:1   skip:26  
time:570s
fi-skl-6770hqtotal:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:495s
fi-skl-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:445s
fi-snb-2520m total:289  pass:248  dwarn:0   dfail:0   

[Intel-gfx] ✗ Fi.CI.IGT: failure for Non-blocking commits on -ERESTARTSYS

[Patchwork]

== Series Details ==

Series: Non-blocking commits on -ERESTARTSYS
URL   : https://patchwork.freedesktop.org/series/35299/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-gtt:
pass   -> SKIP   (shard-hsw) fdo#101623 +1
Subgroup fbc-1p-primscrn-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#103167
Test pm_rpm:
Subgroup modeset-non-lpsp-stress-no-wait:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-snb) fdo#103375 +1
Test kms_flip:
Subgroup busy-flip:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-hsw) fdo#103257 +1
Subgroup busy-flip-interruptible:
pass   -> INCOMPLETE (shard-snb)
Test kms_plane_lowres:
Subgroup pipe-b-tiling-none:
pass   -> INCOMPLETE (shard-hsw) fdo#103181
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

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#103257 https://bugs.freedesktop.org/show_bug.cgi?id=103257
fdo#103181 https://bugs.freedesktop.org/show_bug.cgi?id=103181
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hswtotal:2634 pass:1488 dwarn:1   dfail:0   fail:11  skip:1131 
time:8753s
shard-snbtotal:2708 pass:1305 dwarn:1   dfail:0   fail:12  skip:1388 
time:7747s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: make CS frequency read support missing more obvious

[Patchwork]

== Series Details ==

Series: drm/i915: make CS frequency read support missing more obvious
URL   : https://patchwork.freedesktop.org/series/35298/
State : success

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-snb) fdo#103375 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623

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

shard-hswtotal:2712 pass:1536 dwarn:1   dfail:0   fail:10  skip:1165 
time:9374s
shard-snbtotal:2712 pass:1310 dwarn:1   dfail:0   fail:11  skip:1390 
time:8101s
Blacklisted hosts:
shard-apltotal:2690 pass:1665 dwarn:1   dfail:0   fail:22  skip:1001 
time:13526s
shard-kbltotal:2712 pass:1800 dwarn:7   dfail:0   fail:25  skip:880 
time:11195s

== Logs ==

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

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

[Dhinakaran Pandiyan]

PSR allows DMC to put the system to low power states when active, but
this can reset the frame counter on some platforms. The frame counter reset
leads to a negative diff applied to vblank count. This subtest checks
for that.

v2: Some optimizations and data type changes.
Cc: Rodrigo Vivi 
Cc: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 tests/intel-ci/fast-feedback.testlist |  1 +
 tests/kms_psr_sink_crc.c  | 66 +++
 2 files changed, 67 insertions(+)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index f71a16bc..72338b72 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -247,6 +247,7 @@ igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a
 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b
 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c
 igt@kms_psr_sink_crc@psr_basic
+igt@kms_psr_sink_crc@vblank
 igt@kms_setmode@basic-clone-single-crtc
 igt@kms_sink_crc_basic
 igt@pm_backlight@basic-brightness
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 83a69f0b..831368b2 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -69,6 +69,7 @@ typedef struct {
enum operations op;
uint32_t devid;
uint32_t crtc_id;
+   enum pipe pipe;
igt_display_t display;
drm_intel_bufmgr *bufmgr;
struct igt_fb fb_green, fb_white;
@@ -107,6 +108,7 @@ static void setup_output(data_t *data)
if (c->connector_type != DRM_MODE_CONNECTOR_eDP)
continue;
 
+   data->pipe = pipe;
igt_output_set_pipe(output, pipe);
data->crtc_id = output->config.crtc->crtc_id;
data->output = output;
@@ -285,6 +287,63 @@ static void assert_or_manual(bool condition, const char 
*expected)
igt_assert(igt_interactive_debug || condition);
 }
 
+static unsigned int get_vblank(int fd, unsigned int pipe)
+{
+   union drm_wait_vblank vbl;
+
+   memset(, 0, sizeof(vbl));
+   vbl.request.type = DRM_VBLANK_RELATIVE | kmstest_get_vbl_flag(pipe);
+   igt_ioctl(fd, DRM_IOCTL_WAIT_VBLANK, );
+
+   return vbl.reply.sequence;
+}
+
+static void dmc_read_counts(unsigned int fd, unsigned int *count)
+{
+   char buf[512];
+
+   igt_debugfs_read(fd, "i915_dmc_info", buf);
+   igt_assert_eq(sscanf(strstr(buf, "DC3 -> DC5"), "DC3 -> DC5 count: %u", 
[0]),
+ 1);
+   igt_assert_eq(sscanf(strstr(buf, "DC5 -> DC6"), "DC5 -> DC6 count: %u", 
[1]),
+ 1);
+   igt_debug("DC3->DC5 count=%u, DC5->DC6 count=%u\n", count[0], count[1]);
+}
+
+static void check_vblanks(data_t *data)
+{
+   unsigned int first_vbl, second_vbl;
+   int wait = 30; /* Takes about 2.5 seconds for DC_OFF disable */
+   char buf[512];
+   bool has_dmc;
+
+   first_vbl = get_vblank(data->drm_fd, data->pipe);
+
+   igt_debugfs_read(data->drm_fd, "i915_dmc_info", buf);
+   has_dmc = strstr(buf, "fw loaded: yes");
+
+   if (has_dmc) {
+   unsigned int new_dc[2], old_dc[2];
+
+   dmc_read_counts(data->drm_fd, new_dc);
+   do {
+   memcpy(old_dc, new_dc, sizeof(new_dc));
+   usleep(100 * 1000);
+   dmc_read_counts(data->drm_fd, new_dc);
+   } while (!memcmp(old_dc, new_dc, sizeof(new_dc)) && --wait);
+
+   igt_assert_f(wait, "Timed out waiting for DC state transition 
3s.\n");
+   } else {
+   sleep(3);
+   }
+
+   second_vbl = get_vblank(data->drm_fd, data->pipe);
+   igt_debug("vblank count went from %u to %u in %d ms.\n",
+ first_vbl, second_vbl, has_dmc ? (30 - wait) * 100 : 3000);
+
+   igt_assert_lt(first_vbl, second_vbl);
+}
+
 static bool drrs_disabled(data_t *data)
 {
char buf[512];
@@ -572,6 +631,13 @@ int main(int argc, char *argv[])
}
}
 
+   igt_subtest("vblank") {
+   setup_test_plane();
+   igt_assert(wait_psr_entry());
+   check_vblanks();
+   test_cleanup();
+   }
+
igt_subtest_f("dpms_off_psr_active") {
data.test_plane = DRM_PLANE_TYPE_PRIMARY;
data.op = RENDER;
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 7/8] drm/i915/guc: Extract doorbell verification into a function

[Michel Thierry]

On 13/12/17 07:23, Michal Wajdeczko wrote:

On Wed, 13 Dec 2017 13:50:45 +0100, Michał Winiarski
 wrote:


We have the selftest that's checking doorbell create/destroy, so there's
no need to check all doorbells delaying the reset every time.
We do want to have that extra sanity check at module load/unload though.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---


Reviewed-by: Michal Wajdeczko 



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

Re: [Intel-gfx] [PATCH 6/8] drm/i915/guc: Extract clients allocation to submission_init

[Michel Thierry]

On 13/12/17 04:50, Michał Winiarski wrote:

We can now move the clients allocation to submission_init path, rather
than keeping the condition inside submission_enable called on every
reset.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---


Reviewed-by: Michel Thierry 


  drivers/gpu/drm/i915/intel_guc_submission.c | 33 ++---
  1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index c74e78b6ba41..488110602e7e 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1149,6 +1149,10 @@ int intel_guc_submission_init(struct intel_guc *guc)
 goto err_log;
 GEM_BUG_ON(!guc->ads_vma);

+   ret = guc_clients_create(guc);
+   if (ret)
+   return ret;
+
 for_each_engine(engine, dev_priv, id) {
 guc->preempt_work[id].engine = engine;
 INIT_WORK(>preempt_work[id].work, inject_preempt_context);
@@ -1172,6 +1176,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
 for_each_engine(engine, dev_priv, id)
 cancel_work_sync(>preempt_work[id].work);

+   guc_clients_destroy(guc);
 guc_ads_destroy(guc);
 intel_guc_log_destroy(guc);
 guc_stage_desc_pool_destroy(guc);
@@ -1277,28 +1282,18 @@ int intel_guc_submission_enable(struct intel_guc *guc)
  sizeof(struct guc_wq_item) *
  I915_NUM_ENGINES > GUC_WQ_SIZE);

-   /*
-* We're being called on both module initialization and on reset,
-* until this flow is changed, we're using regular client presence to
-* determine which case are we in, and whether we should allocate new
-* clients or just reset their workqueues.
-*/
-   if (!guc->execbuf_client) {
-   err = guc_clients_create(guc);
-   if (err)
-   return err;
-   } else {
-   guc_reset_wq(guc->execbuf_client);
-   guc_reset_wq(guc->preempt_client);
-   }
+   GEM_BUG_ON(!guc->execbuf_client);
+
+   guc_reset_wq(guc->execbuf_client);
+   guc_reset_wq(guc->preempt_client);

 err = intel_guc_sample_forcewake(guc);
 if (err)
-   goto err_free_clients;
+   return err;

 err = guc_clients_doorbell_init(guc);
 if (err)
-   goto err_free_clients;
+   return err;

 /* Take over from manual control of ELSP (execlists) */
 guc_interrupts_capture(dev_priv);
@@ -1315,10 +1310,6 @@ int intel_guc_submission_enable(struct intel_guc *guc)
 }

 return 0;
-
-err_free_clients:
-   guc_clients_destroy(guc);
-   return err;
  }

  void intel_guc_submission_disable(struct intel_guc *guc)
@@ -1332,8 +1323,6 @@ void intel_guc_submission_disable(struct intel_guc *guc)

 /* Revert back to manual ELSP submission */
 intel_engines_reset_default_submission(dev_priv);
-
-   guc_clients_destroy(guc);
  }

  #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
--
2.14.3

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


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

Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Extract doorbell creation from client allocation

[Michel Thierry]

On 13/12/17 04:50, Winiarski, Michal wrote:

Full GPU reset causes GuC to be reset. This means that every time we're
doing a reset, we need to talk to GuC and tell it about doorbells.
Let's separate the communication part (create_doorbell) from our
internal bookkeeping (reserve_doorbell) so that we can cleanly separate
the initialization done at module load from reinitialization done at
reset in the following patch.
While I'm here, let's also add a proper (although slightly asymetric)
cleanup that doesn't try to communicate with GuC after it's already
gone, getting rid of "expected" warnings caused by GuC action failures
on module unload.

Note that I've also removed one of the tests (bitmap out of sync), since
it doesn't make much sense anymore - bitmaps are now not expected to
change during the lifetime of a client.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_guc_submission.c | 151 
  drivers/gpu/drm/i915/selftests/intel_guc.c  | 110 +---
  2 files changed, 88 insertions(+), 173 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 8f4b274d66a7..c74e78b6ba41 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -88,7 +88,7 @@ static inline bool is_high_priority(struct intel_guc_client 
*client)
 client->priority == GUC_CLIENT_PRIORITY_HIGH);
  }

-static int __reserve_doorbell(struct intel_guc_client *client)
+static int reserve_doorbell(struct intel_guc_client *client)
  {
 unsigned long offset;
 unsigned long end;
@@ -120,7 +120,7 @@ static int __reserve_doorbell(struct intel_guc_client 
*client)
 return 0;
  }

-static void __unreserve_doorbell(struct intel_guc_client *client)
+static void unreserve_doorbell(struct intel_guc_client *client)
  {
 GEM_BUG_ON(client->doorbell_id == GUC_DOORBELL_INVALID);

@@ -188,32 +188,21 @@ static bool has_doorbell(struct intel_guc_client *client)
 return test_bit(client->doorbell_id, client->guc->doorbell_bitmap);
  }

-static int __create_doorbell(struct intel_guc_client *client)
+static void __create_doorbell(struct intel_guc_client *client)
  {
 struct guc_doorbell_info *doorbell;
-   int err;

 doorbell = __get_doorbell(client);
 doorbell->db_status = GUC_DOORBELL_ENABLED;
 doorbell->cookie = 0;
-
-   err = __guc_allocate_doorbell(client->guc, client->stage_id);
-   if (err) {
-   doorbell->db_status = GUC_DOORBELL_DISABLED;
-   DRM_ERROR("Couldn't create client %u doorbell: %d\n",
- client->stage_id, err);
-   }
-
-   return err;
  }


__create_doorbell isn't creating anything, and now it is just changing 
the db status, but that has nothing to do with this patch.


Reviewed-by: Michel Thierry 



-static int __destroy_doorbell(struct intel_guc_client *client)
+static void __destroy_doorbell(struct intel_guc_client *client)
  {
 struct drm_i915_private *dev_priv = guc_to_i915(client->guc);
 struct guc_doorbell_info *doorbell;
 u16 db_id = client->doorbell_id;

-   GEM_BUG_ON(db_id >= GUC_DOORBELL_INVALID);

 doorbell = __get_doorbell(client);
 doorbell->db_status = GUC_DOORBELL_DISABLED;
@@ -225,50 +214,42 @@ static int __destroy_doorbell(struct intel_guc_client 
*client)
  */
 if (wait_for_us(!(I915_READ(GEN8_DRBREGL(db_id)) & GEN8_DRB_VALID), 
10))
 WARN_ONCE(true, "Doorbell never became invalid after 
disable\n");
-
-   return __guc_deallocate_doorbell(client->guc, client->stage_id);
  }

  static int create_doorbell(struct intel_guc_client *client)
  {
 int ret;

-   ret = __reserve_doorbell(client);
-   if (ret)
-   return ret;
-
 __update_doorbell_desc(client, client->doorbell_id);
+   __create_doorbell(client);

-   ret = __create_doorbell(client);
-   if (ret)
-   goto err;
+   ret = __guc_allocate_doorbell(client->guc, client->stage_id);
+   if (ret) {
+   __destroy_doorbell(client);
+   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
+   DRM_ERROR("Couldn't create client %u doorbell: %d\n",
+ client->stage_id, ret);
+   return ret;
+   }

 return 0;
-
-err:
-   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
-   __unreserve_doorbell(client);
-   return ret;
  }

  static int destroy_doorbell(struct intel_guc_client *client)
  {
-   int err;
+   int ret;

 GEM_BUG_ON(!has_doorbell(client));

-   

Re: [Intel-gfx] [PATCH] drm/i915: make CS frequency read support missing more obvious

[Chris Wilson]

Quoting Lionel Landwerlin (2017-12-13 17:11:54)
> As suggested by Chris, we should make this more obvious for people
> working with newer generations.
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 11ceb43ddcee..6a3c40439e83 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -490,7 +490,7 @@ static u32 read_timestamp_frequency(struct 
> drm_i915_private *dev_priv)
> return freq;
> }
>  
> -   DRM_ERROR("Unknown gen, unable to compute command stream timestamp 
> frequency\n");
> +   MISSING_CASE("Unknown gen, unable to read command streamer timestamp 
> frequency\n");
> return 0;

Worksforme,
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.IGT: warning for igt/tools_test: Check the tools exist before executing (rev2)

[Patchwork]

== Series Details ==

Series: igt/tools_test: Check the tools exist before executing (rev2)
URL   : https://patchwork.freedesktop.org/series/35237/
State : warning

== Summary ==

Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-suspend:
pass   -> SKIP   (shard-hsw) fdo#103540
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test tools_test:
Subgroup tools_test:
pass   -> SKIP   (shard-snb)
pass   -> SKIP   (shard-hsw)
Subgroup sysfs_l3_parity:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-snb) fdo#103375
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> DMESG-FAIL (shard-snb) fdo#104058 +1

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

shard-hswtotal:2712 pass:1533 dwarn:1   dfail:0   fail:11  skip:1167 
time:9413s
shard-snbtotal:2712 pass:1307 dwarn:2   dfail:1   fail:11  skip:1391 
time:8127s
Blacklisted hosts:
shard-apltotal:2712 pass:1686 dwarn:1   dfail:0   fail:23  skip:1002 
time:13856s
shard-kbltotal:2712 pass:1807 dwarn:1   dfail:0   fail:24  skip:880 
time:11160s

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Unwind i915_gem_init() failure (rev4)

[Chris Wilson]

Quoting Patchwork (2017-12-13 18:26:21)
> == Series Details ==
> 
> Series: drm/i915: Unwind i915_gem_init() failure (rev4)
> URL   : https://patchwork.freedesktop.org/series/35060/
> State : warning
> 
> == Summary ==
> 
> Test gem_tiled_swapping:
> Subgroup non-threaded:
> pass   -> INCOMPLETE (shard-snb) fdo#104009
> pass   -> INCOMPLETE (shard-hsw) fdo#104218
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> pass   -> FAIL   (shard-snb) fdo#101623
> Test drv_suspend:
> Subgroup sysfs-reader:
> pass   -> SKIP   (shard-hsw)
> Test kms_cursor_crc:
> Subgroup cursor-256x256-suspend:
> skip   -> PASS   (shard-snb) fdo#103375

With no better suggestions, and this fixes lots of WARN spam from
invalid modparams, I've pushed this patch. Thanks for the review,
and improvements are very much welcome.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lpe: Remove double-encapsulation of info string

[Patchwork]

== Series Details ==

Series: drm/i915/lpe: Remove double-encapsulation of info string
URL   : https://patchwork.freedesktop.org/series/35303/
State : success

== Summary ==

Series 35303v1 drm/i915/lpe: Remove double-encapsulation of info string
https://patchwork.freedesktop.org/api/1.0/series/35303/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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: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:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:512s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
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:482s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:471s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:263s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:406s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:418s
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:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:431s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:479s
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:465s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:539s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:497s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:553s
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:602s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:490s

1a717c76c96c2883866e4041926285b0f576fb54 drm-tip: 2017y-12m-13d-14h-48m-36s UTC 
integration manifest
582ab4461ae7 drm/i915/lpe: Remove double-encapsulation of info string

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: properly init lockdep class

[Peter Zijlstra]

On Wed, Dec 13, 2017 at 06:36:33PM +0100, Sebastian Andrzej Siewior wrote:
> +peterz
> context: http://www.spinics.net/lists/intel-gfx/msg149011.html
> 
> On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> > > > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > > > > The code has an ifdef and uses two functions to either init the bare
> > > > > spinlock or init it and set a lock-class. It is possible to do the 
> > > > > same
> > > > > thing without an ifdef.
> > > > > With this patch (in debug case) we first use the "default" lock class
> > > > > which is later overwritten to the supplied one. Without lockdep the 
> > > > > set
> > > > > name/class function vanishes.
> …
> > > > At least according to the source there doesn't seem to be clarity about
> > > > what is the right thing to do, this being just one option.

The proposed patch is definitely the right thing to do. The fact that it
doesn't require #ifdef is a very big clue.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for HAX mm: Prevent stalling for lock_page in deferred_split_scan

[Patchwork]

== Series Details ==

Series: HAX mm: Prevent stalling for lock_page in deferred_split_scan
URL   : https://patchwork.freedesktop.org/series/35294/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-render:
pass   -> FAIL   (shard-hsw) fdo#103167
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_cursor_crc:
Subgroup cursor-128x128-suspend:
pass   -> SKIP   (shard-hsw) fdo#103375 +1
Test kms_flip:
Subgroup flip-vs-modeset-vs-hang:
pass   -> DMESG-WARN (shard-snb) fdo#103821

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

shard-hswtotal:2712 pass:1535 dwarn:1   dfail:0   fail:11  skip:1165 
time:9368s
shard-snbtotal:2712 pass:1309 dwarn:2   dfail:0   fail:11  skip:1390 
time:8115s
Blacklisted hosts:
shard-apltotal:2636 pass:1639 dwarn:1   dfail:0   fail:22  skip:974 
time:13450s
shard-kbltotal:2712 pass:1809 dwarn:1   dfail:0   fail:23  skip:879 
time:11122s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Unwind i915_gem_init() failure (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Unwind i915_gem_init() failure (rev4)
URL   : https://patchwork.freedesktop.org/series/35060/
State : warning

== Summary ==

Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104009
pass   -> INCOMPLETE (shard-hsw) fdo#104218
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623
Test drv_suspend:
Subgroup sysfs-reader:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-snb) fdo#103375

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

shard-hswtotal:2694 pass:1525 dwarn:1   dfail:0   fail:10  skip:1157 
time:9245s
shard-snbtotal:2694 pass:1301 dwarn:1   dfail:0   fail:13  skip:1378 
time:7870s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/kms_frontbuffer_tracking: Correctly handle debugfs errors

[Patchwork]

== Series Details ==

Series: tests/kms_frontbuffer_tracking: Correctly handle debugfs errors
URL   : https://patchwork.freedesktop.org/series/34555/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test kms_fbcon_fbt:
Subgroup fbc:
pass   -> SKIP   (shard-hsw)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-snb) fdo#103375

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

shard-hswtotal:2712 pass:1536 dwarn:1   dfail:0   fail:10  skip:1165 
time:9475s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:12  skip:1390 
time:8091s
Blacklisted hosts:
shard-apltotal:2712 pass:1687 dwarn:1   dfail:0   fail:23  skip:1001 
time:13871s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for Create a new directory for hardware-targeting tests

[Patchwork]

== Series Details ==

Series: Create a new directory for hardware-targeting tests
URL   : https://patchwork.freedesktop.org/series/35288/
State : success

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-snb) fdo#103375
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank:
pass   -> INCOMPLETE (shard-hsw) fdo#100368

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

shard-hswtotal:2648 pass:1506 dwarn:1   dfail:0   fail:10  skip:1130 
time:9162s
shard-snbtotal:2712 pass:1309 dwarn:1   dfail:0   fail:12  skip:1390 
time:8093s
Blacklisted hosts:
shard-kbltotal:2670 pass:1784 dwarn:1   dfail:0   fail:24  skip:860 
time:10941s

== Logs ==

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

Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/guc: Move GuC WOPCM related code into separate files

[Yaodong Li]

On 12/13/2017 12:19 AM, Joonas Lahtinen wrote:

On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:

intel_guc_reg.h should only include definition for GuC registers
and related register bits. GuC WOPCM related values should not
be defined in intel_guc_reg.h

This patch creates a better file structure by moving GuC WOPCM
related definitions int to a new header intel_guc_wopcm.h
and moving GuC WOPCM related functions to a new source file
intel_guc_wopcm.c

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




+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -218,7 +218,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
}
  
  	/* init WOPCM */

-   I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
+   I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(guc));

This is a write-once register, the code needs to be refactored to
account that somebody (like an ugly BIOS) wrote it already and we have
to live with that value. Otherwise we're digging a hole for future
selves.

It's the way the current code works. I will work out a new patch to
do the code refactoring. Anyhow, this is a good catch! Thanks!


We should also verify that the write sticks as we expect.

For the verification - the following dynamic partitioning patch will
guarantee the correctness of this size value. As for the successful
register updating, I will address it within the new patch code refactoring
patch.


Regards, Joonas


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

[Intel-gfx] [PATCH] drm/i915/lpe: Remove double-encapsulation of info string

[Chris Wilson]

Just printk the string, or at least do not double up on the newlines!

Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver")
Signed-off-by: Chris Wilson 
Cc: Pierre-Louis Bossart 
Cc: Jerome Anand 
Cc: Jani Nikula 
Cc: Takashi Iwai 
---
 drivers/gpu/drm/i915/intel_lpe_audio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
b/drivers/gpu/drm/i915/intel_lpe_audio.c
index 3bf65288..5809b29044fc 100644
--- a/drivers/gpu/drm/i915/intel_lpe_audio.c
+++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
@@ -193,7 +193,7 @@ static bool lpe_audio_detect(struct drm_i915_private 
*dev_priv)
};
 
if (!pci_dev_present(atom_hdaudio_ids)) {
-   DRM_INFO("%s\n", "HDaudio controller not detected, 
using LPE audio instead\n");
+   DRM_INFO("HDaudio controller not detected, using LPE 
audio instead\n");
lpe_present = true;
}
}
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v4 3/5] drm/i915/guc: Implement dynamic WOPCM partitioning

[Yaodong Li]

On 12/13/2017 01:11 AM, Joonas Lahtinen wrote:

On Tue, 2017-12-12 at 14:56 -0800, Jackie Li wrote:

Hardware may have specific restrictions on GuC WOPCM partition
size versus HuC firmware size. With static WOPCM partitioning,
there's no way to adjust the GuC WOPCM partition size based on
the actual HuC firmware size, so that GuC/HuC loading failure
would occur even if there was enough WOPCM space for both
GuC and HuC firmware.

WOPCM being a shared feature of the hardware, it should not go under
intel_guc_ prefix.

There should be a clear division of what is specific to GuC feature
only and what is just a feature that happens to be used by GuC (and
equally can be used by HuC too).

the intel_guc_wopcm here only refers to the wopcm used by
GuC, this structure only defines the GuC related wopcm info.
(wopcm partition for GuC). We only need to set these values
(defined in this structure) to GuC registers. And this structure
should never be touched if GuC was disabled. so it should be
a part of GuC.

Regards, Jackie


Regards, Joonas


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

Re: [Intel-gfx] [PATCH] x86/gpu: add CFL to early quirks

[Lucas De Marchi]

On Wed, Dec 13, 2017 at 2:11 AM, Jani Nikula
 wrote:
> On Tue, 12 Dec 2017, Lucas De Marchi  wrote:
>> On Tue, Dec 12, 2017 at 1:53 AM, Joonas Lahtinen
>>  wrote:
>>> + Jani, who'll continue with -fixes
>>>
>>> On Mon, 2017-12-11 at 13:50 -0800, Lucas De Marchi wrote:
 On Mon, Dec 11, 2017 at 2:26 AM, Joonas Lahtinen
  wrote:
 > On Fri, 2017-12-08 at 10:47 -0800, Lucas De Marchi wrote:
 > > CFL was missing from intel_early_ids[].
 > >
 > > Cc: Ingo Molnar 
 > > Cc: H. Peter Anvin 
 > > Cc: Thomas Gleixner 
 > > Cc: x...@kernel.org
 > > Cc: Rodrigo Vivi 
 > > Signed-off-by: Lucas De Marchi 
 >
 > This should come with a Fixes: line to be picked up to -fixes. The IDs

 I thought this didn't deserve CC to stable since alpha support was
 removed for CFL only for 4.15.
>>>
>>> I don't think system memory corruption is really acceptable even for
>>> alpha quality support :P
>>>
 > have been added in smaller chunks and reworked after, so backporting
 > will be required. For this level of fix, my recommendation would be to
 > actively provide a cleanly applying backports to affected stable
 > versions.

 Are you saying this should be proactive rather than reactive? I don't
 see this mentioned on
 Documentation/process/stable-kernel-rules.rst... the only thing I see
 there regarding patches that don't apply
 cleanly is that I may bring more patches through a tag for each version.

 If we are indeed going to cc stable I can submit a v2 with added tags.
 If a patch that can be cc'ed to stable
 needs to be provided we may need to improve our docs, too.
>>>
>>> That's correct. But once Cc:d stable, we can see from the GIT history
>>> that it'll bounce back because it won't apply. For this specific case
>>> that might cause system memory corruption, I'd make an exception and be
>>> proactive.
>>
>> Another option would be to cherry-pick
>> 0890540e21cf1156b4cf960a4c1c734db4e816f9 and
>> 41693fd5237397d3c61b311af0fda1f6f39297c2 so then all commits apply cleanly.
>
> There's a cc: stable annotation for dependencies like that, see stable

Yep, that's why I suggested the alternative. I think bring those
commits to stable will be
better because they will always cause conflicts on future backports.
If we have them applied
it will make future backports to apply cleanly rather than needing to
diverge more from
master.

> kernel rules. I think Greg has stated a preference for picking up
> dependencies rather than having manually backported patches.

Great. I will follow that approach for v2.

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

Re: [Intel-gfx] [PATCH 8/8] HAX Enable GuC Submission for CI

[Chris Wilson]

Quoting Michał Winiarski (2017-12-13 12:50:46)
> Also:
> 
> Revert "drm/i915/GuC/GLK: Load GuC on GLK"
> 
> Now that we no longer have fallback to execlists submission available,
> if the firmware is selected by the driver but is not available on the
> system (like in this case - where the FW is not yet released), we're
> unable to get a clean CI run.

If the FW hasn't yet been released, should we even be listing it in the
driver? We just had the issue with being strict on not changing dmc
before it was available from linux-firmware to avoid imposing infeasible
demands on the user. In this case it is not so bad since it's not yet
enabled by default, but doesn't it generate a warning about missing
firmware at install time?
-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 Non-blocking commits on -ERESTARTSYS

[Patchwork]

== Series Details ==

Series: Non-blocking commits on -ERESTARTSYS
URL   : https://patchwork.freedesktop.org/series/35299/
State : success

== Summary ==

Series 35299v1 Non-blocking commits on -ERESTARTSYS
https://patchwork.freedesktop.org/api/1.0/series/35299/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
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:440s
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:514s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:488s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:468s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:267s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:534s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:396s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:429s
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:529s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:469s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:530s
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:465s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:490s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:450s
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:418s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:593s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:491s

1a717c76c96c2883866e4041926285b0f576fb54 drm-tip: 2017y-12m-13d-14h-48m-36s UTC 
integration manifest
3f843da44156 Non-blocking commits on -ERESTARTSYS

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: properly init lockdep class

[Sebastian Andrzej Siewior]

+peterz
context: http://www.spinics.net/lists/intel-gfx/msg149011.html

On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> > On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> > > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > > > The code has an ifdef and uses two functions to either init the bare
> > > > spinlock or init it and set a lock-class. It is possible to do the same
> > > > thing without an ifdef.
> > > > With this patch (in debug case) we first use the "default" lock class
> > > > which is later overwritten to the supplied one. Without lockdep the set
> > > > name/class function vanishes.
…
> > > At least according to the source there doesn't seem to be clarity about
> > > what is the right thing to do, this being just one option.
> > 
> > I don' think `ifdef CONFIG_DEBUG_SPINLOCK' is an option. Especially
> > since the i915 driver here is the only user in tree doing this kind of
> > thing.
> > Then we have lockdep_set_class_and_name() (which I promote here). This
> > looks like the official way of doing lockdep related things and it has
> > even more than ten users in tree.
> 
> I think it be worthwhile to suggest would be the addition of
> __spin_lock_init where you can pass in the the lockclass and name.

I don't due to the existing interface. However I don't call the shots
here and added peterz instead :)

> Regards, Joonas

Sebastian
___
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: make CS frequency read support missing more obvious

[Patchwork]

== Series Details ==

Series: drm/i915: make CS frequency read support missing more obvious
URL   : https://patchwork.freedesktop.org/series/35298/
State : success

== Summary ==

Series 35298v1 drm/i915: make CS frequency read support missing more obvious
https://patchwork.freedesktop.org/api/1.0/series/35298/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:441s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:385s
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:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:515s
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:482s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:270s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:414s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:391s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:474s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:481s
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:472s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:528s
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:462s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:536s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:443s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:554s
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:597s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:495s

1a717c76c96c2883866e4041926285b0f576fb54 drm-tip: 2017y-12m-13d-14h-48m-36s UTC 
integration manifest
52eaf8696aff drm/i915: make CS frequency read support missing more obvious

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/8] drm/i915/guc: Move shared data allocation away from submission path

[Patchwork]

== Series Details ==

Series: series starting with [1/8] drm/i915/guc: Move shared data allocation 
away from submission path
URL   : https://patchwork.freedesktop.org/series/35287/
State : success

== Summary ==

Warning: bzip CI_DRM_3507/shard-glkb6/results33.json.bz2 wasn't in correct JSON 
format
Test gem_tiled_swapping:
Subgroup non-threaded:
pass   -> INCOMPLETE (shard-snb) fdo#104009
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
skip   -> PASS   (shard-hsw) fdo#103375
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623

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

shard-hswtotal:2712 pass:1537 dwarn:1   dfail:0   fail:10  skip:1164 
time:9469s
shard-snbtotal:2694 pass:1301 dwarn:2   dfail:0   fail:12  skip:1378 
time:7914s
Blacklisted hosts:
shard-apltotal:2690 pass:1664 dwarn:1   dfail:0   fail:22  skip:1002 
time:13540s
shard-kbltotal:2540 pass:1626 dwarn:18  dfail:2   fail:23  skip:867 
time:9796s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm: rework delayed connector cleanup in connector_iter (rev2)

[Patchwork]

== Series Details ==

Series: drm: rework delayed connector cleanup in connector_iter (rev2)
URL   : https://patchwork.freedesktop.org/series/35282/
State : warning

== Summary ==

Warning: bzip CI_DRM_3507/shard-glkb6/results33.json.bz2 wasn't in correct JSON 
format
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-snb) fdo#103375 +2
Subgroup cursor-256x256-offscreen:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Subgroup fbc-1p-primscrn-pri-shrfb-draw-render:
pass   -> FAIL   (shard-hsw) fdo#103167
Test kms_flip:
Subgroup blt-wf_vblank-vs-dpms:
pass   -> SKIP   (shard-hsw) fdo#102614
Subgroup flip-vs-dpms-interruptible:
pass   -> SKIP   (shard-hsw)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-render-b:
pass   -> SKIP   (shard-hsw)
Test kms_draw_crc:
Subgroup draw-method-xrgb2101010-blt-xtiled:
pass   -> SKIP   (shard-hsw)

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

shard-hswtotal:2712 pass:1529 dwarn:1   dfail:0   fail:11  skip:1171 
time:9152s
shard-snbtotal:2636 pass:1277 dwarn:1   dfail:0   fail:13  skip:1345 
time:7954s
Blacklisted hosts:
shard-apltotal:2694 pass:1675 dwarn:1   dfail:0   fail:21  skip:996 
time:13516s

== Logs ==

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

Re: [Intel-gfx] Non-blocking commits on -ERESTARTSYS

[Maarten Lankhorst]

Op 13-12-17 om 17:19 schreef Leo Li:
> Hi Daniel, Maarten,
>
> Just digging an old thread out of the grave:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
>
> It's suppose to fix a memory leak on the drm_commit object during
> non-blocking commits. Within drm_atomic_helper_setup_commit, a reference
> to the commit object is obtained by the new_crtc_state. This reference
> is suppose to be 'put' once flip_done is signaled (via the
> release_crtc_commit callback), but never happens if .prepare_fb returns
> -ERESTARTSYS: drm_atomic_helper_commit early returns before the
> commit_tail work is queued.
>
> We're starting to bump into this issue again. Regarding Daniel's
> suggestion for an IGT test, has there been any work done on it? I'd be
> interested in taking a look otherwise. As a side note, I can also
> reproduce this on i915.
>
> Thanks,
> Leo

I'm curious, isn't it better to handle this in 
__drm_atomic_helper_crtc_destroy_state with the attached patch?

No idea if sane though, but drivers are supposed to clear crtc_state->event on 
success..

diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 593b30d38ce0..e71233b4c651 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3435,6 +3435,8 @@ EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
 void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state)
 {
 	if (state->commit) {
+		if (state->event)
+			drm_crtc_commit_put(state->commit);
 		kfree(state->commit->event);
 		state->commit->event = NULL;
 		drm_crtc_commit_put(state->commit);
___
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/tools_test: Check the tools exist before executing (rev2)

[Patchwork]

== Series Details ==

Series: igt/tools_test: Check the tools exist before executing (rev2)
URL   : https://patchwork.freedesktop.org/series/35237/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4112f30aedbb252bf8cdd27dbba485c0458faca7 igt/gem_shrink: Exercise allocations 
in the middle of execbuf under oom-pressure

with latest DRM-Tip kernel build CI_DRM_3508
1a717c76c96c drm-tip: 2017y-12m-13d-14h-48m-36s UTC integration manifest

No testlist changes.

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
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:387s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:515s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
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:512s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:490s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:473s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:268s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:542s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:409s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:393s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:488s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:530s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:534s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
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-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:549s
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:598s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:491s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: make CS frequency read support missing more obvious

[Lionel Landwerlin]

As suggested by Chris, we should make this more obvious for people
working with newer generations.

Suggested-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_device_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 11ceb43ddcee..6a3c40439e83 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -490,7 +490,7 @@ static u32 read_timestamp_frequency(struct drm_i915_private 
*dev_priv)
return freq;
}
 
-   DRM_ERROR("Unknown gen, unable to compute command stream timestamp 
frequency\n");
+   MISSING_CASE("Unknown gen, unable to read command streamer timestamp 
frequency\n");
return 0;
 }
 
-- 
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 tests/kms_frontbuffer_tracking: Correctly handle debugfs errors

[Patchwork]

== Series Details ==

Series: tests/kms_frontbuffer_tracking: Correctly handle debugfs errors
URL   : https://patchwork.freedesktop.org/series/34555/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4112f30aedbb252bf8cdd27dbba485c0458faca7 igt/gem_shrink: Exercise allocations 
in the middle of execbuf under oom-pressure

with latest DRM-Tip kernel build CI_DRM_3508
1a717c76c96c drm-tip: 2017y-12m-13d-14h-48m-36s UTC integration manifest

No testlist changes.

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-kbl-r) fdo#104172

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:517s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
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:506s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:488s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:470s
fi-elk-e7500 total:224  pass:163  dwarn:14  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:543s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:412s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:396s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:473s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:482s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:527s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:529s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:597s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:452s
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:420s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:591s
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_664/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] No FBC on Cherry Trail ?

[Ville Syrjälä]

On Wed, Dec 13, 2017 at 05:45:01PM +0100, Hans de Goede wrote:
> Hi All,
> 
> intel_cherryview_info in drivers/gpu/drm/i915/i915_pci.c
> does not have has_fbc set. Is this an oversight / does
> the i915 code need work to allow FBC on CHT, or does CHT
> actually not have FBC?

The code is correct. No FBC on VLV/CHV.

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

[Intel-gfx] No FBC on Cherry Trail ?

[Hans de Goede]

Hi All,

intel_cherryview_info in drivers/gpu/drm/i915/i915_pci.c
does not have has_fbc set. Is this an oversight / does
the i915 code need work to allow FBC on CHT, or does CHT
actually not have FBC?

Regards,

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Create a new directory for hardware-targeting tests

[Patchwork]

== Series Details ==

Series: Create a new directory for hardware-targeting tests
URL   : https://patchwork.freedesktop.org/series/35288/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
4112f30aedbb252bf8cdd27dbba485c0458faca7 igt/gem_shrink: Exercise allocations 
in the middle of execbuf under oom-pressure

with latest DRM-Tip kernel build CI_DRM_3508
1a717c76c96c drm-tip: 2017y-12m-13d-14h-48m-36s UTC integration manifest

No testlist changes.

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:439s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:446s
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:518s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:507s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:492s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-elk-e7500 total:224  pass:163  dwarn:15  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:265s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:411s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:423s
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:491s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:432s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:522s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:532s
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:540s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:449s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:564s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:429s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:599s
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_663/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for HAX mm: Prevent stalling for lock_page in deferred_split_scan

[Patchwork]

== Series Details ==

Series: HAX mm: Prevent stalling for lock_page in deferred_split_scan
URL   : https://patchwork.freedesktop.org/series/35294/
State : success

== Summary ==

Series 35294v1 HAX mm: Prevent stalling for lock_page in deferred_split_scan
https://patchwork.freedesktop.org/api/1.0/series/35294/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-elk-e7500) fdo#103989
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:437s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:384s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:511s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:281s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:488s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:474s
fi-elk-e7500 total:224  pass:164  dwarn:14  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:265s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:417s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:388s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:433s
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:516s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:531s
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:450s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:538s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:445s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:551s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:411s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:588s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:493s
fi-glk-1 failed to collect. IGT log at Patchwork_7486/fi-glk-1/igt.log

1a717c76c96c2883866e4041926285b0f576fb54 drm-tip: 2017y-12m-13d-14h-48m-36s UTC 
integration manifest
15872c601b0b HAX mm: Prevent stalling for lock_page in deferred_split_scan

== Logs ==

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

[Intel-gfx] [PATCH libdrm] headers: Update drm_i915.h

[Michał Winiarski]

Generated using make header_install.

Generated from drm-intel-next-queued commit
53ff2641a817099e1c6d1aef409ba004c3a9f1ea

Signed-off-by: Michał Winiarski 
---
 include/drm/i915_drm.h | 215 ++---
 1 file changed, 202 insertions(+), 13 deletions(-)

diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 5ebe0462..e6ac6b66 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -86,6 +86,62 @@ enum i915_mocs_table_index {
I915_MOCS_CACHED,
 };
 
+/*
+ * Different engines serve different roles, and there may be more than one
+ * engine serving each role. enum drm_i915_gem_engine_class provides a
+ * classification of the role of the engine, which may be used when requesting
+ * operations to be performed on a certain subset of engines, or for providing
+ * information about that group.
+ */
+enum drm_i915_gem_engine_class {
+   I915_ENGINE_CLASS_RENDER= 0,
+   I915_ENGINE_CLASS_COPY  = 1,
+   I915_ENGINE_CLASS_VIDEO = 2,
+   I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
+
+   I915_ENGINE_CLASS_INVALID   = -1
+};
+
+/**
+ * DOC: perf_events exposed by i915 through /sys/bus/event_sources/drivers/i915
+ *
+ */
+
+enum drm_i915_pmu_engine_sample {
+   I915_SAMPLE_BUSY = 0,
+   I915_SAMPLE_WAIT = 1,
+   I915_SAMPLE_SEMA = 2
+};
+
+#define I915_PMU_SAMPLE_BITS (4)
+#define I915_PMU_SAMPLE_MASK (0xf)
+#define I915_PMU_SAMPLE_INSTANCE_BITS (8)
+#define I915_PMU_CLASS_SHIFT \
+   (I915_PMU_SAMPLE_BITS + I915_PMU_SAMPLE_INSTANCE_BITS)
+
+#define __I915_PMU_ENGINE(class, instance, sample) \
+   ((class) << I915_PMU_CLASS_SHIFT | \
+   (instance) << I915_PMU_SAMPLE_BITS | \
+   (sample))
+
+#define I915_PMU_ENGINE_BUSY(class, instance) \
+   __I915_PMU_ENGINE(class, instance, I915_SAMPLE_BUSY)
+
+#define I915_PMU_ENGINE_WAIT(class, instance) \
+   __I915_PMU_ENGINE(class, instance, I915_SAMPLE_WAIT)
+
+#define I915_PMU_ENGINE_SEMA(class, instance) \
+   __I915_PMU_ENGINE(class, instance, I915_SAMPLE_SEMA)
+
+#define __I915_PMU_OTHER(x) (__I915_PMU_ENGINE(0xff, 0xff, 0xf) + 1 + (x))
+
+#define I915_PMU_ACTUAL_FREQUENCY  __I915_PMU_OTHER(0)
+#define I915_PMU_REQUESTED_FREQUENCY   __I915_PMU_OTHER(1)
+#define I915_PMU_INTERRUPTS__I915_PMU_OTHER(2)
+#define I915_PMU_RC6_RESIDENCY __I915_PMU_OTHER(3)
+
+#define I915_PMU_LAST I915_PMU_RC6_RESIDENCY
+
 /* Each region is a minimum of 16k, and there are at most 255 of them.
  */
 #define I915_NR_TEX_REGIONS 255/* table size 2k - maximum due to use
@@ -260,6 +316,8 @@ typedef struct _drm_i915_sarea {
 #define DRM_I915_GEM_CONTEXT_GETPARAM  0x34
 #define DRM_I915_GEM_CONTEXT_SETPARAM  0x35
 #define DRM_I915_PERF_OPEN 0x36
+#define DRM_I915_PERF_ADD_CONFIG   0x37
+#define DRM_I915_PERF_REMOVE_CONFIG0x38
 
 #define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_I915_INIT, drm_i915_init_t)
 #define DRM_IOCTL_I915_FLUSH   DRM_IO ( DRM_COMMAND_BASE + 
DRM_I915_FLUSH)
@@ -315,6 +373,8 @@ typedef struct _drm_i915_sarea {
 #define DRM_IOCTL_I915_GEM_CONTEXT_GETPARAMDRM_IOWR (DRM_COMMAND_BASE + 
DRM_I915_GEM_CONTEXT_GETPARAM, struct drm_i915_gem_context_param)
 #define DRM_IOCTL_I915_GEM_CONTEXT_SETPARAMDRM_IOWR (DRM_COMMAND_BASE + 
DRM_I915_GEM_CONTEXT_SETPARAM, struct drm_i915_gem_context_param)
 #define DRM_IOCTL_I915_PERF_OPEN   DRM_IOW(DRM_COMMAND_BASE + 
DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
+#define DRM_IOCTL_I915_PERF_ADD_CONFIG DRM_IOW(DRM_COMMAND_BASE + 
DRM_I915_PERF_ADD_CONFIG, struct drm_i915_perf_oa_config)
+#define DRM_IOCTL_I915_PERF_REMOVE_CONFIG  DRM_IOW(DRM_COMMAND_BASE + 
DRM_I915_PERF_REMOVE_CONFIG, __u64)
 
 /* Allow drivers to submit batchbuffers directly to hardware, relying
  * on the security mechanisms provided by hardware.
@@ -393,10 +453,20 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 
-/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
+ * The param returns a capability bitmask, nonzero implies that the scheduler
+ * is enabled, with different features present according to the mask.
+ *
+ * The initial priority for each batch is supplied by the context and is
+ * controlled via I915_CONTEXT_PARAM_PRIORITY.
  */
 #define I915_PARAM_HAS_SCHEDULER41
+#define   I915_SCHEDULER_CAP_ENABLED   (1ul << 0)
+#define   I915_SCHEDULER_CAP_PRIORITY  (1ul << 1)
+#define   I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
+
 #define I915_PARAM_HUC_STATUS   42
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports the ability to opt-out of
@@ -412,6 +482,51 @@ typedef struct drm_i915_irq_wait {
  */
 #define 

Re: [Intel-gfx] [PATCH i-g-t 4/4] run-tests.sh: Allow users to override IGT_TEST_ROOT

[Arkadiusz Hiler]

On Wed, Dec 13, 2017 at 02:58:16PM +0200, Petri Latvala wrote:
> Signed-off-by: Petri Latvala 
> Cc: Arkadiusz Hiler 
Reviewed-by: Arkadiusz Hiler 
___
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/guc: Move GuC workqueue allocations outside of the mutex

[Chris Wilson]

Quoting Chris Wilson (2017-12-13 15:23:31)
> Quoting Michał Winiarski (2017-12-13 12:50:40)
> > This gets rid of the following lockdep splat:
> > 
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
> > --
> > debugfs_test/1351 is trying to acquire lock:
> >  (>struct_mutex){+.+.}, at: [<9d90d1a3>] 
> > i915_mutex_lock_interruptible+0x47/0x130 [i915]
> > 
> > but task is already holding lock:
> >  (>mmap_sem){}, at: [<5df01c1e>] __do_page_fault+0x106/0x560
> > 
> > which lock already depends on the new lock.
> > 
> > the existing dependency chain (in reverse order) is:
> > 
> > -> #6 (>mmap_sem){}:
> >__might_fault+0x63/0x90
> >_copy_to_user+0x1e/0x70
> >filldir+0x8c/0xf0
> >dcache_readdir+0xeb/0x160
> >iterate_dir+0xe6/0x150
> >SyS_getdents+0xa0/0x130
> >entry_SYSCALL_64_fastpath+0x1c/0x89
> > 
> > -> #5 (>s_type->i_mutex_key#5){}:
> >lockref_get+0x9/0x20
> > 
> > -> #4 ((completion)){+.+.}:
> >wait_for_common+0x54/0x210
> >devtmpfs_create_node+0x130/0x150
> >device_add+0x5ad/0x5e0
> >device_create_groups_vargs+0xd4/0xe0
> >device_create+0x35/0x40
> >msr_device_create+0x22/0x40
> >cpuhp_invoke_callback+0xc5/0xbf0
> >cpuhp_thread_fun+0x167/0x210
> >smpboot_thread_fn+0x17f/0x270
> >kthread+0x173/0x1b0
> >ret_from_fork+0x24/0x30
> > 
> > -> #3 (cpuhp_state-up){+.+.}:
> >cpuhp_issue_call+0x132/0x1c0
> >__cpuhp_setup_state_cpuslocked+0x12f/0x2a0
> >__cpuhp_setup_state+0x3a/0x50
> >page_writeback_init+0x3a/0x5c
> >start_kernel+0x393/0x3e2
> >secondary_startup_64+0xa5/0xb0
> > 
> > -> #2 (cpuhp_state_mutex){+.+.}:
> >__mutex_lock+0x81/0x9b0
> >__cpuhp_setup_state_cpuslocked+0x4b/0x2a0
> >__cpuhp_setup_state+0x3a/0x50
> >page_alloc_init+0x1f/0x26
> >start_kernel+0x139/0x3e2
> >secondary_startup_64+0xa5/0xb0
> > 
> > -> #1 (cpu_hotplug_lock.rw_sem){}:
> >cpus_read_lock+0x34/0xa0
> >apply_workqueue_attrs+0xd/0x40
> >__alloc_workqueue_key+0x2c7/0x4e1
> >intel_guc_submission_init+0x10c/0x650 [i915]
> >intel_uc_init_hw+0x29e/0x460 [i915]
> >i915_gem_init_hw+0xca/0x290 [i915]
> >i915_gem_init+0x115/0x3a0 [i915]
> >i915_driver_load+0x9a8/0x16c0 [i915]
> >i915_pci_probe+0x2e/0x90 [i915]
> >pci_device_probe+0x9c/0x120
> >driver_probe_device+0x2a3/0x480
> >__driver_attach+0xd9/0xe0
> >bus_for_each_dev+0x57/0x90
> >bus_add_driver+0x168/0x260
> >driver_register+0x52/0xc0
> >do_one_initcall+0x39/0x150
> >do_init_module+0x56/0x1ef
> >load_module+0x231c/0x2d70
> >SyS_finit_module+0xa5/0xe0
> >entry_SYSCALL_64_fastpath+0x1c/0x89
> > 
> > -> #0 (>struct_mutex){+.+.}:
> >lock_acquire+0xaf/0x200
> >__mutex_lock+0x81/0x9b0
> >i915_mutex_lock_interruptible+0x47/0x130 [i915]
> >i915_gem_fault+0x201/0x760 [i915]
> >__do_fault+0x15/0x70
> >__handle_mm_fault+0x85b/0xe40
> >handle_mm_fault+0x14f/0x2f0
> >__do_page_fault+0x2d1/0x560
> >page_fault+0x22/0x30
> > 
> > other info that might help us debug this:
> > 
> > Chain exists of:
> >   >struct_mutex --> >s_type->i_mutex_key#5 --> >mmap_sem
> > 
> >  Possible unsafe locking scenario:
> > 
> >CPU0CPU1
> >
> >   lock(>mmap_sem);
> >lock(>s_type->i_mutex_key#5);
> >lock(>mmap_sem);
> >   lock(>struct_mutex);
> > 
> >  *** DEADLOCK ***
> > 
> > 1 lock held by debugfs_test/1351:
> >  #0:  (>mmap_sem){}, at: [<5df01c1e>] 
> > __do_page_fault+0x106/0x560
> > 
> > stack backtrace:
> > CPU: 2 PID: 1351 Comm: debugfs_test Not tainted 
> > 4.15.0-rc2-CI-Patchwork_7428+ #1
> > Hardware name:  /NUC6i5SYB, BIOS 
> > SYSKLi35.86A.0057.2017.0119.1758 01/19/2017
> > Call Trace:
> >  dump_stack+0x5f/0x86
> >  print_circular_bug+0x230/0x3b0
> >  check_prev_add+0x439/0x7b0
> >  ? lockdep_init_map_crosslock+0x20/0x20
> >  ? unwind_get_return_address+0x16/0x30
> >  ? __lock_acquire+0x1385/0x15a0
> >  __lock_acquire+0x1385/0x15a0
> >  lock_acquire+0xaf/0x200
> >  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
> >  __mutex_lock+0x81/0x9b0
> >  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
> >  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
> >  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
> >  i915_mutex_lock_interruptible+0x47/0x130 [i915]
> >  ? __pm_runtime_resume+0x4f/0x80
> >  i915_gem_fault+0x201/0x760 [i915]
> >  __do_fault+0x15/0x70
> >  __handle_mm_fault+0x85b/0xe40
> 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Unwind i915_gem_init() failure (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915: Unwind i915_gem_init() failure (rev4)
URL   : https://patchwork.freedesktop.org/series/35060/
State : success

== Summary ==

Series 35060v4 drm/i915: Unwind i915_gem_init() failure
https://patchwork.freedesktop.org/api/1.0/series/35060/revisions/4/mbox/

Test kms_frontbuffer_tracking:
Subgroup basic:
incomplete -> SKIP   (fi-elk-e7500) fdo#103989 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172 +1
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
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:439s
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:510s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:504s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:481s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:472s
fi-elk-e7500 total:229  pass:167  dwarn:15  dfail:0   fail:0   skip:46 
fi-gdg-551   total:288  pass:179  dwarn:1   dfail:0   fail:0   skip:108 
time:267s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:416s
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:476s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:425s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
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:472s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:526s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:593s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:543s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:448s
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:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:595s
fi-glk-dsi   total:53   pass:45   dwarn:0   dfail:0   fail:0   skip:7  
fi-glk-1 failed to collect. IGT log at Patchwork_7485/fi-glk-1/igt.log

1a717c76c96c2883866e4041926285b0f576fb54 drm-tip: 2017y-12m-13d-14h-48m-36s UTC 
integration manifest
6f0d85ab93db drm/i915: Unwind i915_gem_init() failure

== Logs ==

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

[Intel-gfx] [PATCH] HAX mm: Prevent stalling for lock_page in deferred_split_scan

[Chris Wilson]

References: https://bugs.freedesktop.org/show_bug.cgi?id=104009

Suggest-Cc: Kirill A. Shutemov 
Suggest-Cc: Vlastimil Babka 
Suggest-Cc: Jerome Marchand 
Suggest-Cc: Andrea Arcangeli 
Suggest-Cc: Hugh Dickins 
Suggest-Cc: Dave Hansen 
Suggest-Cc: Mel Gorman 
Suggest-Cc: Rik van Riel 
Suggest-Cc: Johannes Weiner 
Suggest-Cc: Michal Hocko 
Suggest-Cc: Christoph Lameter 
Suggest-Cc: David Rientjes 
Suggest-Cc: Andrew Morton 
---
 mm/huge_memory.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 2f2f5e774902..e555a90ad079 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2791,10 +2791,13 @@ static unsigned long deferred_split_scan(struct 
shrinker *shrink,
 
list_for_each_safe(pos, next, ) {
page = list_entry((void *)pos, struct page, mapping);
-   lock_page(page);
+   if (!trylock_page(page))
+   continue;
+
/* split_huge_page() removes page from list on success */
if (!split_huge_page(page))
split++;
+
unlock_page(page);
put_page(page);
}
-- 
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: properly init lockdep class

[Joonas Lahtinen]

On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > > The code has an ifdef and uses two functions to either init the bare
> > > spinlock or init it and set a lock-class. It is possible to do the same
> > > thing without an ifdef.
> > > With this patch (in debug case) we first use the "default" lock class
> > > which is later overwritten to the supplied one. Without lockdep the set
> > > name/class function vanishes.
> > > 
> > > Reported-by: kbuild test robot 
> > 
> > How exactly did kbuild test robot figure this out?
> 
> I fixed it up for RT, then robot found a way to complain about it. Then
> I slapped myself for not submitting this patch in the first place.

Right, I was kinda wondering if the robot has gained consciuousness and
is developing new checks...

> > At least according to the source there doesn't seem to be clarity about
> > what is the right thing to do, this being just one option.
> 
> I don' think `ifdef CONFIG_DEBUG_SPINLOCK' is an option. Especially
> since the i915 driver here is the only user in tree doing this kind of
> thing.
> Then we have lockdep_set_class_and_name() (which I promote here). This
> looks like the official way of doing lockdep related things and it has
> even more than ten users in tree.

I think it be worthwhile to suggest would be the addition of
__spin_lock_init where you can pass in the the lockclass and name.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Move shared data allocation away from submission path

[Chris Wilson]

Quoting Michał Winiarski (2017-12-13 12:50:39)
> We need shared data for actions (e.g. guc suspend/resume), and we're
> using those with GuC submission disabled.
> Let's introduce intel_guc_init and move shared data alloc there.
> 
> This fixes GPF during module unload with HuC, but without GuC submission:
> 
> BUG: unable to handle kernel NULL pointer dereference at 5aee7809
> IP: intel_guc_suspend+0x34/0x140 [i915]
> PGD 0 P4D 0
> Oops:  [#1] PREEMPT SMP
> Modules linked in: i915(O-) netconsole x86_pkg_temp_thermal
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> mei_me i2c_i801 mei prime_numbers [last unloaded: i915]
> CPU: 2 PID: 2794 Comm: rmmod Tainted: G U  W  O 4.15.0-rc2+ #297
> Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016
> task: 55945c61 task.stack: 264ccb43
> RIP: 0010:intel_guc_suspend+0x34/0x140 [i915]
> RSP: 0018:c9483df8 EFLAGS: 00010286
> RAX:  RBX: 88082918 RCX: 
> RDX: 0006 RSI: 880844c2c938 RDI: 880844c2c000
> RBP: 88082918 R08: a29c58c1 R09: 
> R10:  R11:  R12: a040ba40
> R13: a040bab0 R14: 88084a195060 R15: 55df3ef357a0
> FS:  7ff43c043740() GS:88084e20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 00f9 CR3: 00083f179005 CR4: 003606e0
> Call Trace:
>  i915_gem_suspend+0x9d/0x130 [i915]
>  ? i915_driver_unload+0x68/0x180 [i915]
>  i915_driver_unload+0x70/0x180 [i915]
>  i915_pci_remove+0x15/0x20 [i915]
>  pci_device_remove+0x36/0xb0
>  device_release_driver_internal+0x15f/0x220
>  driver_detach+0x3a/0x80
>  bus_remove_driver+0x58/0xd0
>  pci_unregister_driver+0x29/0x90
>  SyS_delete_module+0x150/0x1e0
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x7ff43b51b5c7
> RSP: 002b:7ffe6825a758 EFLAGS: 0206 ORIG_RAX: 00b0
> RAX: ffda RBX: 0003 RCX: 7ff43b51b5c7
> RDX: 000a RSI: 0800 RDI: 55df3ef35808
> RBP:  R08: 7ffe682596d1 R09: 
> R10: 7ff43b594880 R11: 0206 R12: 55df3ef357a0
> R13: 7ffe68259740 R14: 55df3ef35260 R15: 55df3ef357a0
> Code: 00 00 02 74 03 31 c0 c3 53 48 89 fb 48 83 ec 10 e8 52 0f
> f8 ff 48 b8 01 05 00 00 02 00 00 00 48 89 44 24 04 48 8b 83 00 12 00 00  
> 80
> f9 00 00 00 01 0f 84 a7 00 00 00 f6 80 98 00 00 00 01 0f
> RIP: intel_guc_suspend+0x34/0x140 [i915] RSP: c9483df8
> CR2: 00f9
> ---[ end trace 23a192a61d937a3e ]---
> 
> Fixes: b8e5eb960b28 ("drm/i915/guc: Allocate separate shared data object for 
> GuC communication")
> Signed-off-by: Michał Winiarski 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Wajdeczko 

The movement looks ok, I'll let others chime in if they think the
ordering is wrong,
Reviewed: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/8] drm/i915/guc: Call invalidate after changing the vfunc

[Chris Wilson]

Quoting Michał Winiarski (2017-12-13 12:50:42)
> To make this operation a bit cleaner, we should make sure that the HW
> can catch up by calling the new implementation right away.
> Note that currently we're only touching the vfunc at module load time
> (before GuC is even loaded), so this shouldn't cause any functional
> changes.
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Michał Winiarski 
> Cc: Chris Wilson 
> Cc: Michal Wajdeczko 
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 7/8] drm/i915/guc: Extract doorbell verification into a function

[Michal Wajdeczko]

On Wed, 13 Dec 2017 13:50:45 +0100, Michał Winiarski  
 wrote:



We have the selftest that's checking doorbell create/destroy, so there's
no need to check all doorbells delaying the reset every time.
We do want to have that extra sanity check at module load/unload though.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---


Reviewed-by: Michal Wajdeczko 
___
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/guc: Move GuC workqueue allocations outside of the mutex

[Chris Wilson]

Quoting Michał Winiarski (2017-12-13 12:50:40)
> This gets rid of the following lockdep splat:
> 
> ==
> WARNING: possible circular locking dependency detected
> 4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
> --
> debugfs_test/1351 is trying to acquire lock:
>  (>struct_mutex){+.+.}, at: [<9d90d1a3>] 
> i915_mutex_lock_interruptible+0x47/0x130 [i915]
> 
> but task is already holding lock:
>  (>mmap_sem){}, at: [<5df01c1e>] __do_page_fault+0x106/0x560
> 
> which lock already depends on the new lock.
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #6 (>mmap_sem){}:
>__might_fault+0x63/0x90
>_copy_to_user+0x1e/0x70
>filldir+0x8c/0xf0
>dcache_readdir+0xeb/0x160
>iterate_dir+0xe6/0x150
>SyS_getdents+0xa0/0x130
>entry_SYSCALL_64_fastpath+0x1c/0x89
> 
> -> #5 (>s_type->i_mutex_key#5){}:
>lockref_get+0x9/0x20
> 
> -> #4 ((completion)){+.+.}:
>wait_for_common+0x54/0x210
>devtmpfs_create_node+0x130/0x150
>device_add+0x5ad/0x5e0
>device_create_groups_vargs+0xd4/0xe0
>device_create+0x35/0x40
>msr_device_create+0x22/0x40
>cpuhp_invoke_callback+0xc5/0xbf0
>cpuhp_thread_fun+0x167/0x210
>smpboot_thread_fn+0x17f/0x270
>kthread+0x173/0x1b0
>ret_from_fork+0x24/0x30
> 
> -> #3 (cpuhp_state-up){+.+.}:
>cpuhp_issue_call+0x132/0x1c0
>__cpuhp_setup_state_cpuslocked+0x12f/0x2a0
>__cpuhp_setup_state+0x3a/0x50
>page_writeback_init+0x3a/0x5c
>start_kernel+0x393/0x3e2
>secondary_startup_64+0xa5/0xb0
> 
> -> #2 (cpuhp_state_mutex){+.+.}:
>__mutex_lock+0x81/0x9b0
>__cpuhp_setup_state_cpuslocked+0x4b/0x2a0
>__cpuhp_setup_state+0x3a/0x50
>page_alloc_init+0x1f/0x26
>start_kernel+0x139/0x3e2
>secondary_startup_64+0xa5/0xb0
> 
> -> #1 (cpu_hotplug_lock.rw_sem){}:
>cpus_read_lock+0x34/0xa0
>apply_workqueue_attrs+0xd/0x40
>__alloc_workqueue_key+0x2c7/0x4e1
>intel_guc_submission_init+0x10c/0x650 [i915]
>intel_uc_init_hw+0x29e/0x460 [i915]
>i915_gem_init_hw+0xca/0x290 [i915]
>i915_gem_init+0x115/0x3a0 [i915]
>i915_driver_load+0x9a8/0x16c0 [i915]
>i915_pci_probe+0x2e/0x90 [i915]
>pci_device_probe+0x9c/0x120
>driver_probe_device+0x2a3/0x480
>__driver_attach+0xd9/0xe0
>bus_for_each_dev+0x57/0x90
>bus_add_driver+0x168/0x260
>driver_register+0x52/0xc0
>do_one_initcall+0x39/0x150
>do_init_module+0x56/0x1ef
>load_module+0x231c/0x2d70
>SyS_finit_module+0xa5/0xe0
>entry_SYSCALL_64_fastpath+0x1c/0x89
> 
> -> #0 (>struct_mutex){+.+.}:
>lock_acquire+0xaf/0x200
>__mutex_lock+0x81/0x9b0
>i915_mutex_lock_interruptible+0x47/0x130 [i915]
>i915_gem_fault+0x201/0x760 [i915]
>__do_fault+0x15/0x70
>__handle_mm_fault+0x85b/0xe40
>handle_mm_fault+0x14f/0x2f0
>__do_page_fault+0x2d1/0x560
>page_fault+0x22/0x30
> 
> other info that might help us debug this:
> 
> Chain exists of:
>   >struct_mutex --> >s_type->i_mutex_key#5 --> >mmap_sem
> 
>  Possible unsafe locking scenario:
> 
>CPU0CPU1
>
>   lock(>mmap_sem);
>lock(>s_type->i_mutex_key#5);
>lock(>mmap_sem);
>   lock(>struct_mutex);
> 
>  *** DEADLOCK ***
> 
> 1 lock held by debugfs_test/1351:
>  #0:  (>mmap_sem){}, at: [<5df01c1e>] 
> __do_page_fault+0x106/0x560
> 
> stack backtrace:
> CPU: 2 PID: 1351 Comm: debugfs_test Not tainted 4.15.0-rc2-CI-Patchwork_7428+ 
> #1
> Hardware name:  /NUC6i5SYB, BIOS 
> SYSKLi35.86A.0057.2017.0119.1758 01/19/2017
> Call Trace:
>  dump_stack+0x5f/0x86
>  print_circular_bug+0x230/0x3b0
>  check_prev_add+0x439/0x7b0
>  ? lockdep_init_map_crosslock+0x20/0x20
>  ? unwind_get_return_address+0x16/0x30
>  ? __lock_acquire+0x1385/0x15a0
>  __lock_acquire+0x1385/0x15a0
>  lock_acquire+0xaf/0x200
>  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
>  __mutex_lock+0x81/0x9b0
>  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
>  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
>  ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
>  i915_mutex_lock_interruptible+0x47/0x130 [i915]
>  ? __pm_runtime_resume+0x4f/0x80
>  i915_gem_fault+0x201/0x760 [i915]
>  __do_fault+0x15/0x70
>  __handle_mm_fault+0x85b/0xe40
>  handle_mm_fault+0x14f/0x2f0
>  __do_page_fault+0x2d1/0x560
>  page_fault+0x22/0x30
> RIP: 0033:0x7f98d6f49116
> RSP: 002b:7ffd6ffc3278 EFLAGS: 00010283
> RAX: 7f98d39a2bc0 RBX:  RCX: 1680
> RDX: 1680 RSI: 7ffd6ffc3400 RDI: 7f98d39a2bc0
> RBP: 

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Lionel Landwerlin]

On 13/12/17 13:35, Chris Wilson wrote:

Quoting Daniel Vetter (2017-12-13 08:17:17)

On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:

On 12/12/17 11:19, Tvrtko Ursulin wrote:

On 11/12/2017 21:05, Daniel Vetter wrote:

On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:

On 11/12/2017 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using
a render node to
know where to get the information it needs.

Important thing to mention as well is that it is trivial
to get from the
master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the
card symlink to
render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value
per file it is
trivial for userspace to access.

So for what I'm concerned, given how gputop would use
all of this and so
be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.

For the GPU topology I agree this is the right choice, it's
going to be
about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs
exposing it.
It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information
about what to
pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.

Apart from more flexibility and easier to extend, sysfs might be
a better
fit for applications which do not otherwise need a drm fd. Say a
top-like
tool which shows engine utilization, or those patches I RFC-ed recently
which do the same but per DRM client.

Okay, these stats are now available also via PMU so the argument
is not the
strongest I admit, but I still find it quite neat. It also might
allow us to
define our own policy with regards to needed privilege to access these
stats, and not be governed by the perf API rules.

How exactly is sysfs easier to extend than ioctl? There's lots of

Easier as in no need to version, add has_this/has_that markers, try to
guess today how big a field for something might be needed in the future
and similar.


serializing and deserializing going on, ime that's more boilerplate. Imo
the only reason for sysfs is when you _must_ access it without having an
fd to the gpu. The inverse is generally not true (i.e. using sysfs when
you have the fd already), and as soon as you add a writeable field here
you're screwed (because sysfs can't be passed to anyone else but root,
compared to drm fd - viz the backlight fiasco).

I would perhaps expand the "must access without having a drm fd" to
"more convenient to access without a drm fd". My use case here was the
per-client engine usage stats. Equivalence with /proc//stat, or
even /proc/stat if you want. So I was interested in creating a foothold
in sysfs for that purpose.

No writable fields were imagined in all these two to three use cases.


But even without writeable fields: Think of highly contained
containers/clients which only get the drm fd to render. If sysfs is
gone,
will they fall on their faces? Atm "drm fd is all you need" is very
deeply
ingrained into our various OS stacks.

Okay, this is something which was mentioned but I think the answer was
unclear. If current stacks do work without sysfs then this is a good
argument to keep that ability.

As I said I am OK to drop the engine info bits from this series.
Question for Lionel, gpu-top and Mesa then is whether sysfs works for
them, for the remaining topology information. Attractiveness of sysfs
there was that it looked easier to be future proof for more or less
hypothetical future topologies.

We did a couple of versions with ioctls :

https://patchwork.freedesktop.org/patch/185959/ (through GET_PARAM)
https://patchwork.freedesktop.org/series/33436/ (though a new discovery uAPI
initially targeted at the engine discovery)

Eventually Chris suggested sysfs (which I find kind of convenient), even
though you Daniel raised a valid point with sandboxed processes.

I personally don't care much in which way this should be implemented.
Just give me some direction :)

Daniel: Would something in the style of
https://patchwork.freedesktop.org/series/33436/ work? If yes, what would you
recommend to change?

tbh I feel bad derailing this even 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/guc: Move shared data allocation away from submission path

[Patchwork]

== Series Details ==

Series: series starting with [1/8] drm/i915/guc: Move shared data allocation 
away from submission path
URL   : https://patchwork.freedesktop.org/series/35287/
State : success

== Summary ==

Series 35287v1 series starting with [1/8] drm/i915/guc: Move shared data 
allocation away from submission path
https://patchwork.freedesktop.org/api/1.0/series/35287/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#104062
Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#103841
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-kbl-r) fdo#104172
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#104062 https://bugs.freedesktop.org/show_bug.cgi?id=104062
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#104172 https://bugs.freedesktop.org/show_bug.cgi?id=104172
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:439s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:511s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:512s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:487s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:476s
fi-elk-e7500 total:224  pass:163  dwarn:14  dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:266s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:405s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:419s
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:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:430s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:1   fail:0   skip:24  
time:484s
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:464s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:531s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:534s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:493s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:447s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:412s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:610s
fi-cnl-y total:217  pass:196  dwarn:0   dfail:0   fail:0   skip:20 
fi-glk-dsi   total:288  pass:10   dwarn:0   dfail:3   fail:0   skip:275 
time:33s

f97f7de6c725c07feea8de61aadc1d0574301bdb drm-tip: 2017y-12m-13d-13h-46m-37s UTC 
integration manifest
df75d6018dc1 HAX Enable GuC Submission for CI
13b8a1ea018f drm/i915/guc: Extract doorbell verification into a function
7b68452943ac drm/i915/guc: Extract clients allocation to submission_init
89a4804778f8 drm/i915/guc: Extract doorbell creation from client allocation
1249f6d1c89e drm/i915/guc: Call invalidate after changing the vfunc
16d145bb5562 drm/i915/guc: Extract guc_init from guc_init_hw
4f2afebe9e23 drm/i915/guc: Move GuC workqueue allocations outside of the mutex
ec31e0a92956 drm/i915/guc: Move shared data allocation away from submission path

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: properly init lockdep class

[Sebastian Andrzej Siewior]

On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > The code has an ifdef and uses two functions to either init the bare
> > spinlock or init it and set a lock-class. It is possible to do the same
> > thing without an ifdef.
> > With this patch (in debug case) we first use the "default" lock class
> > which is later overwritten to the supplied one. Without lockdep the set
> > name/class function vanishes.
> > 
> > Reported-by: kbuild test robot 
> 
> How exactly did kbuild test robot figure this out?

I fixed it up for RT, then robot found a way to complain about it. Then
I slapped myself for not submitting this patch in the first place.

> At least according to the source there doesn't seem to be clarity about
> what is the right thing to do, this being just one option.

I don' think `ifdef CONFIG_DEBUG_SPINLOCK' is an option. Especially
since the i915 driver here is the only user in tree doing this kind of
thing.
Then we have lockdep_set_class_and_name() (which I promote here). This
looks like the official way of doing lockdep related things and it has
even more than ten users in tree.

> Regards, Joonas

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

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Lionel Landwerlin]

On 13/12/17 08:17, Daniel Vetter wrote:

On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:

On 12/12/17 11:19, Tvrtko Ursulin wrote:

On 11/12/2017 21:05, Daniel Vetter wrote:

On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:

On 11/12/2017 10:50, Joonas Lahtinen wrote:

+ Daniel, Chris

On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:

On 04/12/2017 15:02, Lionel Landwerlin wrote:

Hi,

After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using
a render node to
know where to get the information it needs.

Important thing to mention as well is that it is trivial
to get from the
master drm fd to the sysfs root, via fstat and opendir
/sys/dev/char/:. With the addition of the
card symlink to
render nodes it is trivial for render node fd as well.

I am happy with this approach - it is extensible, flexible and avoids
issues with ioctl versioning or whatnot. With one value
per file it is
trivial for userspace to access.

So for what I'm concerned, given how gputop would use
all of this and so
be the userspace, if everyone else is happy, I think we could do a
detailed review and prehaps also think about including gputop in some
distribution to make the case 100% straightforward.

For the GPU topology I agree this is the right choice, it's
going to be
about topology after all, and directory tree is the perfect candidate.
And if a new platform appears, then it's a new platform and may change
the topology well the hardware topology has changed.

For the engine enumeration, I'm not equally sold for sysfs
exposing it.
It's a "linear list of engine instances with flags" how the userspace
is going to be looking at them. And it's also information
about what to
pass to an IOCTL as arguments after decision has been made, and then
you already have the FD you know you'll be dealing with, at hand. So
another IOCTL for that seems more convenient.

Apart from more flexibility and easier to extend, sysfs might be
a better
fit for applications which do not otherwise need a drm fd. Say a
top-like
tool which shows engine utilization, or those patches I RFC-ed recently
which do the same but per DRM client.

Okay, these stats are now available also via PMU so the argument
is not the
strongest I admit, but I still find it quite neat. It also might
allow us to
define our own policy with regards to needed privilege to access these
stats, and not be governed by the perf API rules.

How exactly is sysfs easier to extend than ioctl? There's lots of

Easier as in no need to version, add has_this/has_that markers, try to
guess today how big a field for something might be needed in the future
and similar.


serializing and deserializing going on, ime that's more boilerplate. Imo
the only reason for sysfs is when you _must_ access it without having an
fd to the gpu. The inverse is generally not true (i.e. using sysfs when
you have the fd already), and as soon as you add a writeable field here
you're screwed (because sysfs can't be passed to anyone else but root,
compared to drm fd - viz the backlight fiasco).

I would perhaps expand the "must access without having a drm fd" to
"more convenient to access without a drm fd". My use case here was the
per-client engine usage stats. Equivalence with /proc//stat, or
even /proc/stat if you want. So I was interested in creating a foothold
in sysfs for that purpose.

No writable fields were imagined in all these two to three use cases.


But even without writeable fields: Think of highly contained
containers/clients which only get the drm fd to render. If sysfs is
gone,
will they fall on their faces? Atm "drm fd is all you need" is very
deeply
ingrained into our various OS stacks.

Okay, this is something which was mentioned but I think the answer was
unclear. If current stacks do work without sysfs then this is a good
argument to keep that ability.

As I said I am OK to drop the engine info bits from this series.
Question for Lionel, gpu-top and Mesa then is whether sysfs works for
them, for the remaining topology information. Attractiveness of sysfs
there was that it looked easier to be future proof for more or less
hypothetical future topologies.

We did a couple of versions with ioctls :

https://patchwork.freedesktop.org/patch/185959/ (through GET_PARAM)
https://patchwork.freedesktop.org/series/33436/ (though a new discovery uAPI
initially targeted at the engine discovery)

Eventually Chris suggested sysfs (which I find kind of convenient), even
though you Daniel raised a valid point with sandboxed processes.

I personally don't care much in which way this should be implemented.
Just give me some direction :)

Daniel: Would something in the style of
https://patchwork.freedesktop.org/series/33436/ work? If yes, what would you
recommend to change?

tbh I feel bad derailing this even further, but I think if you want a more
flexible 

[Intel-gfx] [PATCH igt v2] igt/tools_test: Check the tools exist before executing

[Chris Wilson]

As a simple fail-safe against a bad installation, check the tools exist
before testing whether they work.

v2: Check intel_l3_parity as well

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102935
Signed-off-by: Chris Wilson 
Reviewed-by: Petri Latvala 
Reviewed-by: Joonas Lahtinen 
---
 tests/tools_test.c | 48 +---
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/tests/tools_test.c b/tests/tools_test.c
index 6aea7a8a4..4183456e2 100644
--- a/tests/tools_test.c
+++ b/tests/tools_test.c
@@ -26,6 +26,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#define TOOLS "../tools/"
 
 struct line_check {
int found;
@@ -59,10 +63,19 @@ igt_main
 {
igt_skip_on_simulation();
 
+   igt_fixture {
+   char path[4096];
+
+   if (readlink("/proc/self/exe", path, sizeof(path)) > 0)
+   chdir(dirname(path));
+   }
+
igt_subtest("sysfs_l3_parity") {
int exec_return;
struct line_check line;
 
+   igt_require(access(TOOLS "intel_l3_parity", X_OK) == 0);
+
/* Sanity check that l3 parity tool is usable: Enable
 * row,bank,subbank 0,0,0.
 *
@@ -71,27 +84,28 @@ igt_main
 * piglit.
 */
igt_system_cmd(exec_return,
-  "../tools/intel_l3_parity -r 0 -b 0 "
+  TOOLS "intel_l3_parity -r 0 -b 0 "
   "-s 0 -e");
assert_cmd_success(exec_return);
 
/* Disable row,bank,subbank 0,0,0. */
-   igt_system_cmd(exec_return, "../tools/intel_l3_parity -r 0 -b 0 
"
+   igt_system_cmd(exec_return,
+  TOOLS "intel_l3_parity -r 0 -b 0 "
   "-s 0 -d");
assert_cmd_success(exec_return);
 
/* Check that disabling was successful */
-   igt_system_cmd(exec_return, "../tools/intel_l3_parity -l");
+   igt_system_cmd(exec_return,
+  TOOLS "intel_l3_parity -l");
assert_cmd_success(exec_return);
line.substr = "Row 0, Bank 0, Subbank 0 is disabled";
line.found = 0;
-   igt_log_buffer_inspect(check_cmd_output,
-  );
+   igt_log_buffer_inspect(check_cmd_output, );
igt_assert_eq(line.found, 1);
 
/* Re-enable row,bank,subbank 0,0,0 */
igt_system_cmd(exec_return,
-  "../tools/intel_l3_parity -r 0 -b 0 "
+  TOOLS "intel_l3_parity -r 0 -b 0 "
   "-s 0 -e");
assert_cmd_success(exec_return);
 
@@ -102,7 +116,8 @@ igt_main
 * The previously printed line is already in the log
 * buffer so we check for count 1.
 */
-   igt_system_cmd(exec_return, "../tools/intel_l3_parity -l");
+   igt_system_cmd(exec_return,
+  TOOLS "intel_l3_parity -l");
assert_cmd_success(exec_return);
line.substr = "Row 0, Bank 0, Subbank 0 is disabled";
line.found = 0;
@@ -112,17 +127,12 @@ igt_main
}
 
igt_subtest("tools_test") {
-   char *cmd;
-
-   igt_assert(asprintf(,
-   "../tools/intel_reg read 0x4030")
-  != -1);
-   igt_assert(igt_system_quiet(cmd) == IGT_EXIT_SUCCESS);
-   free(cmd);
-
-   igt_assert(asprintf(, "../tools/intel_reg dump")
-  != -1);
-   igt_assert(igt_system_quiet(cmd) == IGT_EXIT_SUCCESS);
-   free(cmd);
+   igt_require(access(TOOLS "intel_reg", X_OK) == 0);
+
+   igt_assert_eq(igt_system_quiet(TOOLS "intel_reg read 0x4030"),
+ IGT_EXIT_SUCCESS);
+
+   igt_assert_eq(igt_system_quiet(TOOLS "intel_reg dump"),
+ IGT_EXIT_SUCCESS);
}
 }
-- 
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 drm: rework delayed connector cleanup in connector_iter (rev2)

[Patchwork]

== Series Details ==

Series: drm: rework delayed connector cleanup in connector_iter (rev2)
URL   : https://patchwork.freedesktop.org/series/35282/
State : success

== Summary ==

Series 35282v2 drm: rework delayed connector cleanup in connector_iter
https://patchwork.freedesktop.org/api/1.0/series/35282/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +2
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#104062

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

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:441s
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:508s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:505s
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:484s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:469s
fi-elk-e7500 total:224  pass:164  dwarn:14  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 
time:266s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:407s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:419s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:401s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:434s
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:529s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
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:592s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
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:563s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
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:590s
fi-cnl-y total:216  pass:195  dwarn:0   dfail:0   fail:0   skip:20 
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s
fi-glk-1 failed to collect. IGT log at Patchwork_7483/fi-glk-1/igt.log
fi-skl-gvtdvm failed to collect. IGT log at Patchwork_7483/fi-skl-gvtdvm/igt.log

f97f7de6c725c07feea8de61aadc1d0574301bdb drm-tip: 2017y-12m-13d-13h-46m-37s UTC 
integration manifest
b2a87a543978 drm: rework delayed connector cleanup in connector_iter

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_sysfs: Let igt_sysfs_read|write return -errno

[Michal Wajdeczko]

On Thu, 07 Dec 2017 22:00:48 +0100, Daniel Vetter  wrote:


On Thu, Dec 07, 2017 at 04:59:36PM +, Chris Wilson wrote:

Quoting Michal Wajdeczko (2017-12-07 16:52:46)
> In some cases debugfs or sysfs may return errors that we
> want to check. Return -errno from helper functions to make
> asserts easier.
>
> v2: don't forget about EOF ret=0 (Chris)
> small re-write (Michal)
>
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 

Just tests/drv_hangman.c needs to fixed to use
igt_require(sysfs >= 0);


Isn't the usual igt pattern that igt_foo never fails, and __igt_foo gives
you the error code? But I guess we can do that later on in follow-ups.


I'm not sure that this pattern is applicable here as igt_sysfs_read() was
already returning some data or error indicator. The only change is that
now we return len/-errno (instead len/-1)

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove unused IRQ chip data of HDMI LPE audio

[Thomas Gleixner]

On Wed, 13 Dec 2017, Takashi Iwai wrote:
> On Wed, 13 Dec 2017 12:35:54 +0100,
> Thomas Gleixner wrote:
> > 
> > > > On Mon, 11 Dec 2017, Anand, Jerome wrote:
> > > > > > On Fri, 8 Dec 2017, Ville Syrjälä wrote:
> > > > > >
> > > > > > > On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote:
> > > > > > > > The chip data of HDMI LPE audio is set to drm_i915_private which
> > > > > > > > is not consistent with the expectation by x86 APIC driver.
> > > > > > >
> > > > > > > Hmm. Why is the apic code looking at data for an irq chip it
> > > > > > > hasn't created?
> > > > > > >
> > > > >
> > > > > apic code expects an irq domain to be place as generic approach.
> > > > 
> > > > APIC code does not even see that interrupt at all. It's completely 
> > > > disconnected.
> > > > 
> > > 
> > > That's the problem - APIC just converts the chip data to its internal
> > > format and fails.
> > 
> > How does APIC code end up to touch that interrupt at all? Call stack please.
> 
> It's found in the bugzilla referred in the patch:
>   https://bugs.freedesktop.org/show_bug.cgi?id=103731
> 
> [   87.353072] irq 298 idata->chip->name hdmi_lpe_audio_irqchip
> [   87.353072] irq 298 apic_chip_data
> [   87.353073] irq 298 data->domain is NULL
> [   87.353120] BUG: unable to handle kernel NULL pointer dereference at (null)
> [   87.353132] IP: setup_vector_irq+0x1ba/0x230
> [   87.353133] PGD 0
> 
> If my understanding is correct, it happens only with 4.14 and earlier
> kernels where __setup_vector_irq() loops over the all irqs:
> 
> static void __setup_vector_irq(int cpu)
> {
>   struct apic_chip_data *data;
>   struct irq_desc *desc;
>   int irq, vector;
> 
>   /* Mark the inuse vectors */
>   for_each_irq_desc(irq, desc) {
>   struct irq_data *idata = irq_desc_get_irq_data(desc);
> 
>   data = apic_chip_data(idata);
>   if (!data || !cpumask_test_cpu(cpu, data->domain))
>   continue;
>   
> 
> And since we have assigned a non-APIC chip data in the driver, the
> code above refers to a wrong object, leading to Oops.

Bah crap. This information should have been provided earlier instead of
handwavy 'doesnt work with CONFIG_FOO and hotplug'.

> As a further note, the setup_vector_irq() code has been changed in
> 4.15, and such a reference won't happen any longer.  So the patch
> isn't necessary for now, although it's not bad to take as a cleanup.
> And we can eventually put Cc to stable there since it actually works
> around the issue above for the older kernels -- of course, with more
> detailed descriptions about the background.

No, that's just tinkering. The proper fix is to make that code robust.

Something like the completely untested patch below should do the trick.

Thanks,

tglx
---
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index f3557a1eb562..02e6a3cc0d74 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -58,6 +58,9 @@ static struct apic_chip_data *apic_chip_data(struct irq_data 
*irq_data)
while (irq_data->parent_data)
irq_data = irq_data->parent_data;
 
+   if (irq_data->domain != x86_vector_domain)
+   return NULL;
+
return irq_data->chip_data;
 }
 

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

Re: [Intel-gfx] [PATCH] drm/i915: properly init lockdep class

[Joonas Lahtinen]

On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> The code has an ifdef and uses two functions to either init the bare
> spinlock or init it and set a lock-class. It is possible to do the same
> thing without an ifdef.
> With this patch (in debug case) we first use the "default" lock class
> which is later overwritten to the supplied one. Without lockdep the set
> name/class function vanishes.
> 
> Reported-by: kbuild test robot 

How exactly did kbuild test robot figure this out?

At least according to the source there doesn't seem to be clarity about
what is the right thing to do, this being just one option.

Regards, Joonas

> +++ b/drivers/gpu/drm/i915/i915_gem_timeline.c
> @@ -33,11 +33,8 @@ static void __intel_timeline_init(struct
>  {
>   tl->fence_context = context;
>   tl->common = parent;
> -#ifdef CONFIG_DEBUG_SPINLOCK
> - __raw_spin_lock_init(>lock.rlock, lockname, lockclass);
> -#else
>   spin_lock_init(>lock);
> -#endif
> + lockdep_set_class_and_name(>lock, lockclass, lockname);
>   init_request_active(>last_request, NULL);
>   INIT_LIST_HEAD(>requests);
>   i915_syncmap_init(>sync);
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Update edid-derived drm_display_info fields at edid property set [v2]

[Daniel Vetter]

On Wed, Dec 13, 2017 at 12:44:26AM -0800, Keith Packard wrote:
> There are a set of values in the drm_display_info structure for each
> connector which hold information derived from EDID. These are computed
> in drm_add_display_info. Before this patch, that was only called in
> drm_add_edid_modes. This meant that they were only set when EDID was
> present and never reset when EDID was not, as happened when the
> display was disconnected.
> 
> One of these fields, non_desktop, is used from
> drm_mode_connector_update_edid_property, the function responsible for
> assigning the new edid value to the application-visible property.
> 
> Various drivers call these two functions (drm_add_edid_modes and
> drm_mode_connector_update_edid_property) in different orders. This
> means that even when EDID is present, the drm_display_info fields may
> not have been computed at the time that
> drm_mode_connector_update_edid_property used the non_desktop value to
> set the non_desktop property.
> 
> I've added a public function (drm_reset_display_info) that resets the
> drm_display_info field values to default values and then made the
> drm_add_display_info function public. These two functions are now
> called directly from drm_mode_connector_update_edid_property so that
> the drm_display_info fields are always computed from the current EDID
> information before being used in that function.
> 
> This means that the drm_display_info values are often computed twice,
> once when the EDID property it set and a second time when EDID is used
> to compute modes for the device. The alternative would be to uniformly
> ensure that the values were computed once before being used, which
> would require that all drivers reliably invoke the two paths in the
> same order. The computation is inexpensive enough that it seems more
> maintainable in the long term to simply compute them in both paths.
> 
> The API to drm_add_display_info has been changed so that it no longer
> takes the set of edid-based quirks as a parameter. Rather, it now
> computes those quirks itself and returns them for further use by
> drm_add_edid_modes.
> 
> This patch also includes a number of 'const' additions caused by
> drm_mode_connector_update_edid_property taking a 'const struct edid *'
> parameter and wanting to pass that along to drm_add_display_info.
> 
> v2: after review by Daniel Vetter 
> 
>   Removed EXPORT_SYMBOL_GPL for drm_reset_display_info and
>   drm_add_display_info.
> 
>   Added FIXME in drm_mode_connector_update_edid_property about
>   potentially merging that with drm_add_edid_modes to avoid
>   the need for two driver calls.
> 
> Signed-off-by: Keith Packard 
> Reviewed-by: Daniel Vetter 

Ok there's a functional conflict when I tried to apply this to -fixes,
due to some rework already in drm-misc-next. Hence I applied your original
patch here to drm-misc-next, and then cherry-picked it over to
drm-misc-fixes and fixed it up. That way we'll not loose the bits needed
in -next.

Please double-check I didn't wreck stuff before I send the pull request
out.

Thanks, Daniel
> ---
>  drivers/gpu/drm/drm_connector.c | 13 ++
>  drivers/gpu/drm/drm_edid.c  | 53 
> ++---
>  include/drm/drm_edid.h  |  2 ++
>  3 files changed, 54 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 25f4b2e9a44f..83c01f359d55 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1207,6 +1207,19 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
>   if (edid)
>   size = EDID_LENGTH * (1 + edid->extensions);
>  
> + /* Set the display info, using edid if available, otherwise
> +  * reseting the values to defaults. This duplicates the work
> +  * done in drm_add_edid_modes, but that function is not
> +  * consistently called before this one in all drivers and the
> +  * computation is cheap enough that it seems better to
> +  * duplicate it rather than attempt to ensure some arbitrary
> +  * ordering of calls.
> +  */
> + if (edid)
> + drm_add_display_info(connector, edid);
> + else
> + drm_reset_display_info(connector);
> +
>   drm_object_property_set_value(>base,
> dev->mode_config.non_desktop_property,
> connector->display_info.non_desktop);
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 524eace3d460..365901c1c33c 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1731,7 +1731,7 @@ EXPORT_SYMBOL(drm_edid_duplicate);
>   *
>   * Returns true if @vendor is in @edid, false otherwise
>   */
> -static bool edid_vendor(struct edid *edid, const char *vendor)
> +static bool 

[Intel-gfx] [PATCH v3] drm/i915: Unwind i915_gem_init() failure

[Chris Wilson]

Since Michal introduced new errors other than -EIO during
i915_gem_init(), we need to actually unwind on the error path as we have
to abort the module load (and we expect to do so cleanly!).

As we now teardown key state and then mark the driver as wedged (on
EIO), we have to be careful to not allow ourselves to resume and
unwedge, thus attempting to use the uninitialised driver.

v2: Try not to free driver state for the suppressed EIO
v3: Use load-fault-injection to test both error/recovery paths.

References: 8620eb1dbbf2 ("drm/i915/uc: Don't use -EIO to report missing 
firmware")
Signed-off-by: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Joonas Lahtinen 
Cc: Sagar Arun Kamble 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem.c | 80 +
 1 file changed, 66 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8c3d801696b7..13fa26238e89 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4865,7 +4865,8 @@ void i915_gem_resume(struct drm_i915_private *i915)
i915_gem_restore_gtt_mappings(i915);
i915_gem_restore_fences(i915);
 
-   /* As we didn't flush the kernel context before suspend, we cannot
+   /*
+* As we didn't flush the kernel context before suspend, we cannot
 * guarantee that the context image is complete. So let's just reset
 * it and start again.
 */
@@ -4886,8 +4887,10 @@ void i915_gem_resume(struct drm_i915_private *i915)
return;
 
 err_wedged:
-   DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
-   i915_gem_set_wedged(i915);
+   if (!i915_terminally_wedged(>gpu_error)) {
+   DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
+   i915_gem_set_wedged(i915);
+   }
goto out_unlock;
 }
 
@@ -5170,22 +5173,28 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
ret = i915_gem_init_ggtt(dev_priv);
-   if (ret)
-   goto out_unlock;
+   if (ret) {
+   GEM_BUG_ON(ret == -EIO);
+   goto err_unlock;
+   }
 
ret = i915_gem_contexts_init(dev_priv);
-   if (ret)
-   goto out_unlock;
+   if (ret) {
+   GEM_BUG_ON(ret == -EIO);
+   goto err_ggtt;
+   }
 
ret = intel_engines_init(dev_priv);
-   if (ret)
-   goto out_unlock;
+   if (ret) {
+   GEM_BUG_ON(ret == -EIO);
+   goto err_context;
+   }
 
intel_init_gt_powersave(dev_priv);
 
ret = i915_gem_init_hw(dev_priv);
if (ret)
-   goto out_unlock;
+   goto err_pm;
 
/*
 * Despite its name intel_init_clock_gating applies both display
@@ -5199,9 +5208,53 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
intel_init_clock_gating(dev_priv);
 
ret = __intel_engines_record_defaults(dev_priv);
-out_unlock:
+   if (ret)
+   goto err_init_hw;
+
+   if (i915_inject_load_failure()) {
+   ret = -ENODEV;
+   goto err_init_hw;
+   }
+
+   if (i915_inject_load_failure()) {
+   ret = -EIO;
+   goto err_init_hw;
+   }
+
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   return 0;
+
+   /*
+* Unwinding is complicated by that we want to handle -EIO to mean
+* disable GPU submission but keep KMS alive. We want to mark the
+* HW as irrevisibly wedged, but keep enough state around that the
+* driver doesn't explode during runtime.
+*/
+err_init_hw:
+   i915_gem_wait_for_idle(dev_priv, I915_WAIT_LOCKED);
+   i915_gem_contexts_lost(dev_priv);
+   intel_uc_fini_hw(dev_priv);
+err_pm:
+   if (ret != -EIO) {
+   intel_cleanup_gt_powersave(dev_priv);
+   i915_gem_cleanup_engines(dev_priv);
+   }
+err_context:
+   if (ret != -EIO)
+   i915_gem_contexts_fini(dev_priv);
+err_ggtt:
+err_unlock:
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   if (ret != -EIO)
+   i915_gem_cleanup_userptr(dev_priv);
+
if (ret == -EIO) {
-   /* Allow engine initialisation to fail by marking the GPU as
+   /*
+* Allow engine initialisation to fail by marking the GPU as
 * wedged. But we only want to do this where the GPU is angry,
 * for all other failure, such as an allocation failure, bail.
 */
@@ -5211,9 +5264,8 @@ int i915_gem_init(struct 

Re: [Intel-gfx] [PATCH v6 0/5] drm/i915: Expose more GPU properties through sysfs

[Chris Wilson]

Quoting Daniel Vetter (2017-12-13 08:17:17)
> On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
> > On 12/12/17 11:19, Tvrtko Ursulin wrote:
> > > 
> > > On 11/12/2017 21:05, Daniel Vetter wrote:
> > > > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> > > > > On 11/12/2017 10:50, Joonas Lahtinen wrote:
> > > > > > + Daniel, Chris
> > > > > > 
> > > > > > On Thu, 2017-12-07 at 09:21 +, Tvrtko Ursulin wrote:
> > > > > > > On 04/12/2017 15:02, Lionel Landwerlin wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > After discussion with Chris, Joonas & Tvrtko, this series adds 
> > > > > > > > an
> > > > > > > > additional commit to link the render node back to the card 
> > > > > > > > through a
> > > > > > > > symlink. Making it obvious from an application using
> > > > > > > > a render node to
> > > > > > > > know where to get the information it needs.
> > > > > > > 
> > > > > > > Important thing to mention as well is that it is trivial
> > > > > > > to get from the
> > > > > > > master drm fd to the sysfs root, via fstat and opendir
> > > > > > > /sys/dev/char/:. With the addition of the
> > > > > > > card symlink to
> > > > > > > render nodes it is trivial for render node fd as well.
> > > > > > > 
> > > > > > > I am happy with this approach - it is extensible, flexible and 
> > > > > > > avoids
> > > > > > > issues with ioctl versioning or whatnot. With one value
> > > > > > > per file it is
> > > > > > > trivial for userspace to access.
> > > > > > > 
> > > > > > > So for what I'm concerned, given how gputop would use
> > > > > > > all of this and so
> > > > > > > be the userspace, if everyone else is happy, I think we could do a
> > > > > > > detailed review and prehaps also think about including gputop in 
> > > > > > > some
> > > > > > > distribution to make the case 100% straightforward.
> > > > > > 
> > > > > > For the GPU topology I agree this is the right choice, it's
> > > > > > going to be
> > > > > > about topology after all, and directory tree is the perfect 
> > > > > > candidate.
> > > > > > And if a new platform appears, then it's a new platform and may 
> > > > > > change
> > > > > > the topology well the hardware topology has changed.
> > > > > > 
> > > > > > For the engine enumeration, I'm not equally sold for sysfs
> > > > > > exposing it.
> > > > > > It's a "linear list of engine instances with flags" how the 
> > > > > > userspace
> > > > > > is going to be looking at them. And it's also information
> > > > > > about what to
> > > > > > pass to an IOCTL as arguments after decision has been made, and then
> > > > > > you already have the FD you know you'll be dealing with, at hand. So
> > > > > > another IOCTL for that seems more convenient.
> > > > > 
> > > > > Apart from more flexibility and easier to extend, sysfs might be
> > > > > a better
> > > > > fit for applications which do not otherwise need a drm fd. Say a
> > > > > top-like
> > > > > tool which shows engine utilization, or those patches I RFC-ed 
> > > > > recently
> > > > > which do the same but per DRM client.
> > > > > 
> > > > > Okay, these stats are now available also via PMU so the argument
> > > > > is not the
> > > > > strongest I admit, but I still find it quite neat. It also might
> > > > > allow us to
> > > > > define our own policy with regards to needed privilege to access these
> > > > > stats, and not be governed by the perf API rules.
> > > > 
> > > > How exactly is sysfs easier to extend than ioctl? There's lots of
> > > 
> > > Easier as in no need to version, add has_this/has_that markers, try to
> > > guess today how big a field for something might be needed in the future
> > > and similar.
> > > 
> > > > serializing and deserializing going on, ime that's more boilerplate. Imo
> > > > the only reason for sysfs is when you _must_ access it without having an
> > > > fd to the gpu. The inverse is generally not true (i.e. using sysfs when
> > > > you have the fd already), and as soon as you add a writeable field here
> > > > you're screwed (because sysfs can't be passed to anyone else but root,
> > > > compared to drm fd - viz the backlight fiasco).
> > > 
> > > I would perhaps expand the "must access without having a drm fd" to
> > > "more convenient to access without a drm fd". My use case here was the
> > > per-client engine usage stats. Equivalence with /proc//stat, or
> > > even /proc/stat if you want. So I was interested in creating a foothold
> > > in sysfs for that purpose.
> > > 
> > > No writable fields were imagined in all these two to three use cases.
> > > 
> > > > But even without writeable fields: Think of highly contained
> > > > containers/clients which only get the drm fd to render. If sysfs is
> > > > gone,
> > > > will they fall on their faces? Atm "drm fd is all you need" is very
> > > > deeply
> > > > ingrained into our various OS stacks.
> > > 
> > > Okay, this is something which was mentioned but I think the answer was
> > > unclear. If 

Re: [Intel-gfx] [PATCH] drm: rework delayed connector cleanup in connector_iter

[Daniel Vetter]

On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-12-13 12:49:36)
> > PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> > that again fails, and we try to flush the overall system_wq (to get
> > all the delayed connectore cleanup work_struct completed), we
> > deadlock.
> > 
> > Fix this by using just a single cleanup work, so that we can only
> > flush that one and don't block on anything else. That means a free
> > list plus locking, a standard pattern.
> > 
> > v2:
> > - Correctly free connectors only on last ref. Oops (Chris).
> > - use llist_head/node (Chris).
> > 
> > Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter")
> > Fixes: 613051dac40d ("drm: locking iterators for connector_list")
> > Cc: Ben Widawsky 
> > Cc: Dave Airlie 
> > Cc: Chris Wilson 
> > Cc: Sean Paul 
> > Cc:  # v4.11+: 613051dac40d ("drm: locking 
> > iterators for connector_list"
> > Cc:  # v4.11+
> > Cc: Daniel Vetter 
> > Cc: Jani Nikula 
> > Cc: Gustavo Padovan 
> > Cc: David Airlie 
> > Cc: Javier Martinez Canillas 
> > Cc: Shuah Khan 
> > Cc: Guillaume Tucker 
> > Cc: Mark Brown 
> > Cc: Kevin Hilman 
> > Cc: Matt Hart 
> > Cc: Thierry Escande 
> > Cc: Tomeu Vizoso 
> > Cc: Enric Balletbo i Serra 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 50 
> > ++---
> >  drivers/gpu/drm/drm_crtc_internal.h |  1 +
> >  drivers/gpu/drm/drm_mode_config.c   |  4 ++-
> >  include/drm/drm_connector.h | 10 +---
> >  include/drm/drm_mode_config.h   | 18 -
> >  5 files changed, 62 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 0b7e0974e6da..3f53f127e1f2 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -153,14 +153,23 @@ static void drm_connector_free(struct kref *kref)
> > connector->funcs->destroy(connector);
> >  }
> >  
> > -static void drm_connector_free_work_fn(struct work_struct *work)
> > +void drm_connector_free_work_fn(struct work_struct *work)
> >  {
> > -   struct drm_connector *connector =
> > -   container_of(work, struct drm_connector, free_work);
> > -   struct drm_device *dev = connector->dev;
> > +   struct drm_connector *connector, *n;
> > +   struct drm_device *dev =
> > +   container_of(work, struct drm_device, 
> > mode_config.connector_free_work);
> > +   struct drm_mode_config *config = >mode_config;
> > +   unsigned long flags;
> > +   struct llist_node *freed;
> >  
> > -   drm_mode_object_unregister(dev, >base);
> > -   connector->funcs->destroy(connector);
> > +   spin_lock_irqsave(>connector_list_lock, flags);
> > +   freed = llist_del_all(>connector_free_list);
> > +   spin_unlock_irqrestore(>connector_list_lock, flags);
> 
> My understanding is that the spinlock here is only used to guard the
> free_list. (It's not protecting the final refcount.) In which case it is
> redundant as llist_del_all/llist_add are a safe lockless combination.
> 
> That just makes the patch bigger than has to be, but it looks correct.
> 
> > +__drm_connector_put_safe(struct drm_connector *conn)
> >  {
> > -   if (refcount_dec_and_test(>base.refcount.refcount))
> > -   schedule_work(>free_work);
> > +   struct drm_mode_config *config = >dev->mode_config;
> > +
> > +   lockdep_assert_held(>connector_list_lock);
> > +
> > +   if (!refcount_dec_and_test(>base.refcount.refcount))
> > +   return;
> > +
> > +   llist_add(>free_node, >connector_free_list);
> > +   schedule_work(>connector_free_work);
> 
> (Didn't like the if (llist_add) nano-optimisation? :)

I thought that one might race, since the schedule_work is what provides the
crucial barrier here. But then I was kinda too lazy to read all the llist
guarantees already and just figured I'll keep the spin_lock stuck around
everything.

But yeah it's all neatly lockless, now I'm tempted to redo it all. If CI
spots something I'll include it in the respin for sure.

> > diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> > b/drivers/gpu/drm/drm_crtc_internal.h
> > index 9ebb8841778c..af00f42ba269 100644
> > --- a/drivers/gpu/drm/drm_crtc_internal.h
> > +++ b/drivers/gpu/drm/drm_crtc_internal.h
> > @@ -142,6 +142,7 @@ int drm_mode_connector_set_obj_prop(struct 
> > 

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep

[Chris Wilson]

Quoting Patchwork (2017-12-12 19:20:00)
> == Series Details ==
> 
> Series: series starting with [1/3] drm/i915: Mark up potential allocation 
> paths within i915_sw_fence as might_sleep
> URL   : https://patchwork.freedesktop.org/series/35239/
> State : success
> 
> == Summary ==
> 
> Test gem_tiled_swapping:
> Subgroup non-threaded:
> incomplete -> PASS   (shard-snb) fdo#104009
> pass   -> INCOMPLETE (shard-hsw) fdo#104218
> Test kms_flip:
> Subgroup plain-flip-fb-recreate-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368
> Test kms_cursor_crc:
> Subgroup cursor-256x256-suspend:
> pass   -> DMESG-WARN (shard-snb) fdo#103375

Thanks for the review. Having left a bit of clear air on CI after the
associated fixes, now pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] tests: Move gem_bad_address to hw-tests

[Chris Wilson]

Quoting Petri Latvala (2017-12-13 12:58:14)
> Since the test is considered to be HW focused, meaning that it doesn't
> really exercise the driver but rather an HW feature, it is placed in
> tests/hw-tests.

Do we really want to keep this test at all? It's an interesting debate
whether we want to show how trivial it is to subvert the kernel and HW
(in some circumstances).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: rework delayed connector cleanup in connector_iter

[Chris Wilson]

Quoting Daniel Vetter (2017-12-13 12:49:36)
> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> that again fails, and we try to flush the overall system_wq (to get
> all the delayed connectore cleanup work_struct completed), we
> deadlock.
> 
> Fix this by using just a single cleanup work, so that we can only
> flush that one and don't block on anything else. That means a free
> list plus locking, a standard pattern.
> 
> v2:
> - Correctly free connectors only on last ref. Oops (Chris).
> - use llist_head/node (Chris).
> 
> Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter")
> Fixes: 613051dac40d ("drm: locking iterators for connector_list")
> Cc: Ben Widawsky 
> Cc: Dave Airlie 
> Cc: Chris Wilson 
> Cc: Sean Paul 
> Cc:  # v4.11+: 613051dac40d ("drm: locking 
> iterators for connector_list"
> Cc:  # v4.11+
> Cc: Daniel Vetter 
> Cc: Jani Nikula 
> Cc: Gustavo Padovan 
> Cc: David Airlie 
> Cc: Javier Martinez Canillas 
> Cc: Shuah Khan 
> Cc: Guillaume Tucker 
> Cc: Mark Brown 
> Cc: Kevin Hilman 
> Cc: Matt Hart 
> Cc: Thierry Escande 
> Cc: Tomeu Vizoso 
> Cc: Enric Balletbo i Serra 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_connector.c | 50 
> ++---
>  drivers/gpu/drm/drm_crtc_internal.h |  1 +
>  drivers/gpu/drm/drm_mode_config.c   |  4 ++-
>  include/drm/drm_connector.h | 10 +---
>  include/drm/drm_mode_config.h   | 18 -
>  5 files changed, 62 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 0b7e0974e6da..3f53f127e1f2 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -153,14 +153,23 @@ static void drm_connector_free(struct kref *kref)
> connector->funcs->destroy(connector);
>  }
>  
> -static void drm_connector_free_work_fn(struct work_struct *work)
> +void drm_connector_free_work_fn(struct work_struct *work)
>  {
> -   struct drm_connector *connector =
> -   container_of(work, struct drm_connector, free_work);
> -   struct drm_device *dev = connector->dev;
> +   struct drm_connector *connector, *n;
> +   struct drm_device *dev =
> +   container_of(work, struct drm_device, 
> mode_config.connector_free_work);
> +   struct drm_mode_config *config = >mode_config;
> +   unsigned long flags;
> +   struct llist_node *freed;
>  
> -   drm_mode_object_unregister(dev, >base);
> -   connector->funcs->destroy(connector);
> +   spin_lock_irqsave(>connector_list_lock, flags);
> +   freed = llist_del_all(>connector_free_list);
> +   spin_unlock_irqrestore(>connector_list_lock, flags);

My understanding is that the spinlock here is only used to guard the
free_list. (It's not protecting the final refcount.) In which case it is
redundant as llist_del_all/llist_add are a safe lockless combination.

That just makes the patch bigger than has to be, but it looks correct.

> +__drm_connector_put_safe(struct drm_connector *conn)
>  {
> -   if (refcount_dec_and_test(>base.refcount.refcount))
> -   schedule_work(>free_work);
> +   struct drm_mode_config *config = >dev->mode_config;
> +
> +   lockdep_assert_held(>connector_list_lock);
> +
> +   if (!refcount_dec_and_test(>base.refcount.refcount))
> +   return;
> +
> +   llist_add(>free_node, >connector_free_list);
> +   schedule_work(>connector_free_work);

(Didn't like the if (llist_add) nano-optimisation? :)

> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 9ebb8841778c..af00f42ba269 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -142,6 +142,7 @@ int drm_mode_connector_set_obj_prop(struct 
> drm_mode_object *obj,
> uint64_t value);
>  int drm_connector_create_standard_properties(struct drm_device *dev);
>  const char *drm_get_connector_force_name(enum drm_connector_force force);
> +void drm_connector_free_work_fn(struct work_struct *work);
>  
>  /* IOCTL */
>  int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index 6ffe952142e6..7681269abe41 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -382,6 +382,8 @@ void drm_mode_config_init(struct 

Re: [Intel-gfx] [PATCH] drm: rework delayed connector cleanup in connector_iter

[Marek Szyprowski]

Hi Daniel,

On 2017-12-13 13:49, Daniel Vetter wrote:

PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.

Fix this by using just a single cleanup work, so that we can only
flush that one and don't block on anything else. That means a free
list plus locking, a standard pattern.

v2:
- Correctly free connectors only on last ref. Oops (Chris).
- use llist_head/node (Chris).

Fixes: a703c55004e1 ("drm: safely free connectors from connector_iter")
Fixes: 613051dac40d ("drm: locking iterators for connector_list")
Cc: Ben Widawsky 
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: Sean Paul 
Cc:  # v4.11+: 613051dac40d ("drm: locking iterators for 
connector_list"
Cc:  # v4.11+
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Gustavo Padovan 
Cc: David Airlie 
Cc: Javier Martinez Canillas 
Cc: Shuah Khan 
Cc: Guillaume Tucker 
Cc: Mark Brown 
Cc: Kevin Hilman 
Cc: Matt Hart 
Cc: Thierry Escande 
Cc: Tomeu Vizoso 
Cc: Enric Balletbo i Serra 
Signed-off-by: Daniel Vetter 


This one works fine and fixes deadlock in my test environment.

Tested-by: Marek Szyprowski 


---
  drivers/gpu/drm/drm_connector.c | 50 ++---
  drivers/gpu/drm/drm_crtc_internal.h |  1 +
  drivers/gpu/drm/drm_mode_config.c   |  4 ++-
  include/drm/drm_connector.h | 10 +---
  include/drm/drm_mode_config.h   | 18 -
  5 files changed, 62 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0b7e0974e6da..3f53f127e1f2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -153,14 +153,23 @@ static void drm_connector_free(struct kref *kref)
connector->funcs->destroy(connector);
  }
  
-static void drm_connector_free_work_fn(struct work_struct *work)

+void drm_connector_free_work_fn(struct work_struct *work)
  {
-   struct drm_connector *connector =
-   container_of(work, struct drm_connector, free_work);
-   struct drm_device *dev = connector->dev;
+   struct drm_connector *connector, *n;
+   struct drm_device *dev =
+   container_of(work, struct drm_device, 
mode_config.connector_free_work);
+   struct drm_mode_config *config = >mode_config;
+   unsigned long flags;
+   struct llist_node *freed;
  
-	drm_mode_object_unregister(dev, >base);

-   connector->funcs->destroy(connector);
+   spin_lock_irqsave(>connector_list_lock, flags);
+   freed = llist_del_all(>connector_free_list);
+   spin_unlock_irqrestore(>connector_list_lock, flags);
+
+   llist_for_each_entry_safe(connector, n, freed, free_node) {
+   drm_mode_object_unregister(dev, >base);
+   connector->funcs->destroy(connector);
+   }
  }
  
  /**

@@ -192,8 +201,6 @@ int drm_connector_init(struct drm_device *dev,
if (ret)
return ret;
  
-	INIT_WORK(>free_work, drm_connector_free_work_fn);

-
connector->base.properties = >properties;
connector->dev = dev;
connector->funcs = funcs;
@@ -550,10 +557,17 @@ EXPORT_SYMBOL(drm_connector_list_iter_begin);
   * actually release the connector when dropping our final reference.
   */
  static void
-drm_connector_put_safe(struct drm_connector *conn)
+__drm_connector_put_safe(struct drm_connector *conn)
  {
-   if (refcount_dec_and_test(>base.refcount.refcount))
-   schedule_work(>free_work);
+   struct drm_mode_config *config = >dev->mode_config;
+
+   lockdep_assert_held(>connector_list_lock);
+
+   if (!refcount_dec_and_test(>base.refcount.refcount))
+   return;
+
+   llist_add(>free_node, >connector_free_list);
+   schedule_work(>connector_free_work);
  }
  
  /**

@@ -585,10 +599,10 @@ drm_connector_list_iter_next(struct 
drm_connector_list_iter *iter)
  
  		/* loop until it's not a zombie connector */

} while (!kref_get_unless_zero(>conn->base.refcount));
-   spin_unlock_irqrestore(>connector_list_lock, flags);
  
  	if (old_conn)

-   drm_connector_put_safe(old_conn);
+   __drm_connector_put_safe(old_conn);
+   spin_unlock_irqrestore(>connector_list_lock, flags);
  
  	return iter->conn;

  }
@@ -605,9 +619,15 @@ EXPORT_SYMBOL(drm_connector_list_iter_next);
   */
  void drm_connector_list_iter_end(struct 

[Intel-gfx] [PATCH i-g-t 3/4] hw-tests: Fix and update gem_bad_address

[Petri Latvala]

From: Antonio Argenziano 

When writing to an invalid memory location, the HW should be clever
enough to silently discard the write without disrupting execution.
gem_bad_address aim at just that. The test has been updated to move away
from the libDrm wrappers and use the IOCTL wrappers instead. Also the
invalid address has been updated to be just outside of the GTT space.

v2 (Petri): Split the directory changes to separate commits, fix
indentation

Signed-off-by: Antonio Argenziano 
Signed-off-by: Petri Latvala 
---
 tests/hw-tests/gem_bad_address.c | 69 +++-
 1 file changed, 39 insertions(+), 30 deletions(-)

diff --git a/tests/hw-tests/gem_bad_address.c b/tests/hw-tests/gem_bad_address.c
index a970dfa4..2d6112bd 100644
--- a/tests/hw-tests/gem_bad_address.c
+++ b/tests/hw-tests/gem_bad_address.c
@@ -23,37 +23,53 @@
  * Authors:
  *Eric Anholt 
  *Jesse Barnes  (based on gem_bad_blit.c)
+ *Antonio Argenziano 
  *
  */
 
 #include "igt.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "drm.h"
-#include "intel_bufmgr.h"
 
-static drm_intel_bufmgr *bufmgr;
-struct intel_batchbuffer *batch;
-
-#define BAD_GTT_DEST ((512*1024*1024)) /* past end of aperture */
+/*
+ * This test aims at verifying that writing to an invalid location in memory,
+ * doesn't cause hangs. The store command should be ignored completely by the
+ * HW and the whole process should be transparent to the user. Therefore,
+ * the test doesn't perform any validation check but expects the wrapping
+ * execution environment to check no hangs have occurred.
+ *
+ * The test needs to send a privileged batch to be able to write to the GTT.
+ */
 
 static void
-bad_store(void)
+bad_store(uint32_t fd, uint32_t engine)
 {
-   BEGIN_BATCH(4, 0);
-   OUT_BATCH(MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL | 1 << 21);
-   OUT_BATCH(0);
-   OUT_BATCH(BAD_GTT_DEST);
-   OUT_BATCH(0xdeadbeef);
-   ADVANCE_BATCH();
+   struct drm_i915_gem_exec_object2 obj;
+   struct drm_i915_gem_execbuffer2 execbuf;
+
+   uint32_t batch[16];
+   int i = 0;
+
+   memset(, 0, sizeof(obj));
+   memset(, 0, sizeof(execbuf));
+
+   execbuf.buffers_ptr = to_user_pointer();
+   execbuf.buffer_count = 1;
+   execbuf.flags = engine;
+   execbuf.flags |= I915_EXEC_SECURE;
 
-   intel_batchbuffer_flush(batch);
+   obj.handle = gem_create(fd, 4096);
+
+   batch[i++] = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
+   batch[i++] = 0x0; //Low part of the GTT address = 4GByte
+   batch[i++] = 0x1; //High part of the GTT address > GTT size
+   batch[i++] = 0xdeadbeef;
+
+   batch[i++] = MI_BATCH_BUFFER_END;
+   batch[i++] = 0x0;
+
+   gem_write(fd, obj.handle, 0, batch, sizeof(batch));
+   gem_execbuf(fd, );
+
+   gem_close(fd, obj.handle);
 }
 
 igt_simple_main
@@ -62,14 +78,7 @@ igt_simple_main
 
fd = drm_open_driver(DRIVER_INTEL);
 
-   bufmgr = drm_intel_bufmgr_gem_init(fd, 4096);
-   drm_intel_bufmgr_gem_enable_reuse(bufmgr);
-   batch = intel_batchbuffer_alloc(bufmgr, intel_get_drm_devid(fd));
-
-   bad_store();
-
-   intel_batchbuffer_free(batch);
-   drm_intel_bufmgr_destroy(bufmgr);
+   bad_store(fd, I915_EXEC_BLT);
 
close(fd);
 }
-- 
2.14.1

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

[Intel-gfx] [PATCH i-g-t 2/4] tests: Move gem_bad_address to hw-tests

[Petri Latvala]

Since the test is considered to be HW focused, meaning that it doesn't
really exercise the driver but rather an HW feature, it is placed in
tests/hw-tests.

Signed-off-by: Petri Latvala 
Cc: Antonio Argenziano 
---
 tests/Makefile.sources | 1 -
 tests/hw-tests/Makefile.sources| 1 +
 tests/{ => hw-tests}/gem_bad_address.c | 0
 tests/hw-tests/meson.build | 1 +
 tests/meson.build  | 1 -
 5 files changed, 2 insertions(+), 2 deletions(-)
 rename tests/{ => hw-tests}/gem_bad_address.c (100%)

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e4e06d01..29dfd9cd 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -264,7 +264,6 @@ HANG = \
gem_bad_batch \
gem_hang \
gem_bad_blit \
-   gem_bad_address \
gem_non_secure_batch \
$(NULL)
 
diff --git a/tests/hw-tests/Makefile.sources b/tests/hw-tests/Makefile.sources
index a224da7c..1fb3ed9e 100644
--- a/tests/hw-tests/Makefile.sources
+++ b/tests/hw-tests/Makefile.sources
@@ -1,2 +1,3 @@
 hw_tests = \
+gem_bad_address \
 $(NULL)
diff --git a/tests/gem_bad_address.c b/tests/hw-tests/gem_bad_address.c
similarity index 100%
rename from tests/gem_bad_address.c
rename to tests/hw-tests/gem_bad_address.c
diff --git a/tests/hw-tests/meson.build b/tests/hw-tests/meson.build
index 32bb637d..848d113e 100644
--- a/tests/hw-tests/meson.build
+++ b/tests/hw-tests/meson.build
@@ -1,4 +1,5 @@
 hw_test_progs = [
+   'gem_bad_address',
 ]
 
 hw_test_deps = [ igt_deps ]
diff --git a/tests/meson.build b/tests/meson.build
index 8ab16a70..5eef1bd6 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -301,7 +301,6 @@ hang_progs = [
'gem_bad_batch',
'gem_hang',
'gem_bad_blit',
-   'gem_bad_address',
'gem_non_secure_batch',
 ]
 foreach prog : hang_progs
-- 
2.14.1

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

[Intel-gfx] [PATCH i-g-t 1/4] tests: Add a hw-tests subdirectory

[Petri Latvala]

The hw-tests subdirectory is meant for tests that target the
hardware's behaviour without the kernel having much say in
matters. Tests in the directory are not meant for regular CI runs, and
running them requires setting IGT_TEST_ROOT to that directory when
using piglit.

Signed-off-by: Petri Latvala 
Cc: Antonio Argenziano 
---
 configure.ac| 12 
 tests/Makefile.am   |  2 +-
 tests/hw-tests/Makefile.am  | 41 +
 tests/hw-tests/Makefile.sources |  2 ++
 tests/hw-tests/meson.build  | 24 
 tests/meson.build   |  2 ++
 6 files changed, 82 insertions(+), 1 deletion(-)
 create mode 100644 tests/hw-tests/Makefile.am
 create mode 100644 tests/hw-tests/Makefile.sources
 create mode 100644 tests/hw-tests/meson.build

diff --git a/configure.ac b/configure.ac
index 8740f7a4..5c48025b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -374,6 +374,16 @@ if test "x$BUILD_TESTS" = xyes; then
AC_DEFINE(BUILD_TESTS, 1, [Build tests])
 fi
 AM_CONDITIONAL(BUILD_TESTS, [test "x$BUILD_TESTS" = xyes])
+
+AC_ARG_ENABLE(hw_tests,
+ AS_HELP_STRING([--disable-hw-tests],
+ [Disable HW tests build (default: enabled)]),
+ [BUILD_HW_TESTS=$enableval], [BUILD_HW_TESTS="yes"])
+if test "x$BUILD_TESTS" = xyes; then
+   AC_DEFINE(BUILD_HW_TESTS, 1, [Build hw tests])
+fi
+AM_CONDITIONAL(BUILD_HW_TESTS, [test "x$BUILD_HW_TESTS" = xyes])
+
 AC_DEFINE_UNQUOTED(TARGET_CPU_PLATFORM, ["$host_cpu"], [Target platform])
 
 files="broadwell cherryview haswell ivybridge sandybridge valleyview skylake"
@@ -397,6 +407,7 @@ AC_CONFIG_FILES([
 man/Makefile
 scripts/Makefile
 tests/Makefile
+tests/hw-tests/Makefile
 tests/intel-ci/Makefile
 tools/Makefile
 tools/null_state_gen/Makefile
@@ -423,6 +434,7 @@ echo "Intel GPU tools"
 echo ""
 echo " • Tests:"
 echo "   Build tests: ${BUILD_TESTS}"
+echo "   Build HW tests : ${BUILD_HW_TESTS}"
 echo "   Chamelium tests: ${enable_chamelium}"
 echo "   Audio tests: ${enable_audio}"
 echo "   Compile prime tests: ${NOUVEAU}"
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 1b9a7b0a..18479722 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1,6 +1,6 @@
 include Makefile.sources
 
-SUBDIRS = intel-ci
+SUBDIRS = hw-tests intel-ci
 
 if HAVE_LIBDRM_AMDGPU
 TESTS_progs += $(AMDGPU_TESTS)
diff --git a/tests/hw-tests/Makefile.am b/tests/hw-tests/Makefile.am
new file mode 100644
index ..434ff695
--- /dev/null
+++ b/tests/hw-tests/Makefile.am
@@ -0,0 +1,41 @@
+include Makefile.sources
+
+if BUILD_HW_TESTS
+test-list.txt: Makefile
+   @echo TESTLIST > $@
+   @echo ${hw_tests} >> $@
+   @echo END TESTLIST >> $@
+
+hwtests_libexecdir = $(pkglibexecdir)/hw-tests
+hwtests_libexec_DATA = \
+   test-list.txt \
+   $(NULL)
+hwtests_libexec_PROGRAMS = $(hw_tests)
+
+all-local: .gitignore
+.gitignore: Makefile.sources
+   @echo "$(hw_tests) test-list.txt /.gitignore" | sed 's/\s\+/\n/g' | 
sort > $@
+
+EXTRA_DIST = \
+   meson.build \
+   $(NULL)
+
+CLEANFILES = test-list.txt .gitignore
+
+AM_CFLAGS = $(CWARNFLAGS) -Wno-unused-result $(DEBUG_CFLAGS)\
+   -I$(top_srcdir)/include/drm-uapi \
+   -I$(srcdir)/.. \
+   -I$(top_srcdir)/lib \
+   -include "$(srcdir)/../lib/check-ndebug.h" \
+   -DIGT_SRCDIR=\""$(abs_srcdir)"\" \
+   -DIGT_DATADIR=\""$(pkgdatadir)"\" \
+   -D_GNU_SOURCE \
+   $(DRM_CFLAGS) $(LIBUNWIND_CFLAGS) $(WERROR_CFLAGS) \
+   $(NULL)
+
+LDADD = ../../lib/libintel_tools.la $(XMLRPC_LIBS)
+
+AM_CFLAGS += $(CAIRO_CFLAGS) $(LIBUDEV_CFLAGS)
+AM_LDFLAGS = -Wl,--as-needed
+
+endif
diff --git a/tests/hw-tests/Makefile.sources b/tests/hw-tests/Makefile.sources
new file mode 100644
index ..a224da7c
--- /dev/null
+++ b/tests/hw-tests/Makefile.sources
@@ -0,0 +1,2 @@
+hw_tests = \
+$(NULL)
diff --git a/tests/hw-tests/meson.build b/tests/hw-tests/meson.build
new file mode 100644
index ..32bb637d
--- /dev/null
+++ b/tests/hw-tests/meson.build
@@ -0,0 +1,24 @@
+hw_test_progs = [
+]
+
+hw_test_deps = [ igt_deps ]
+
+# TODO: Refactoring of all such paths
+hw_libexecdir = join_paths(get_option('libexecdir'), 'intel-gpu-tools', 
'hw-tests')
+
+hw_test_executables = []
+
+foreach prog : hw_test_progs
+   hw_test_executables += executable(prog, prog + '.c',
+  dependencies : test_deps,
+  install_dir : hw_libexecdir,
+  install : true)
+endforeach
+
+hw_pkgdatadir = join_paths(get_option('datadir'), 'intel-gpu-tools', 
'hw-tests')
+
+hw_test_list = custom_target('hw_testlist',
+ output : 'test-list.txt',
+ command : [ gen_testlist, '@OUTPUT@', hw_test_progs ],
+ 

[Intel-gfx] [PATCH i-g-t 4/4] run-tests.sh: Allow users to override IGT_TEST_ROOT

[Petri Latvala]

Signed-off-by: Petri Latvala 
Cc: Arkadiusz Hiler 
---
 scripts/run-tests.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index acd2ae2f..a98e06ce 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -24,7 +24,7 @@
 
 ROOT="`dirname $0`"
 ROOT="`readlink -f $ROOT/..`"
-IGT_TEST_ROOT="$ROOT/tests"
+IGT_TEST_ROOT="${IGT_TEST_ROOT:-$ROOT/tests}"
 IGT_CONFIG_PATH="${IGT_CONFIG_PATH:-$HOME/.igtrc}"
 RESULTS="$ROOT/results"
 PIGLIT=`which piglit 2> /dev/null`
-- 
2.14.1

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

[Intel-gfx] [PATCH i-g-t 0/4] Create a new directory for hardware-targeting tests

[Petri Latvala]

Original patch from Antonio Argenziano, split into separate commits
for its separate steps.

New directory created, tests/hw-tests, meant for tests that target the
hardware's behaviour more than the driver's (or the combination
thereof). Currently just gem_bad_address moved, with Antonio's
changes to the test.

The tests in hw-tests will install into
$libexec/intel-gpu-tools/hw-tests.

Running hw-tests is done by setting IGT_TEST_ROOT appropriately to the
hw-tests directory. scripts/run-tests.sh is amended to support it
instead of hardcoding to $srcdir/tests.

Antonio Argenziano (1):
  hw-tests: Fix and update gem_bad_address

Petri Latvala (3):
  tests: Add a hw-tests subdirectory
  tests: Move gem_bad_address to hw-tests
  run-tests.sh: Allow users to override IGT_TEST_ROOT

 configure.ac   | 12 ++
 scripts/run-tests.sh   |  2 +-
 tests/Makefile.am  |  2 +-
 tests/Makefile.sources |  1 -
 tests/hw-tests/Makefile.am | 41 
 tests/hw-tests/Makefile.sources|  3 ++
 tests/{ => hw-tests}/gem_bad_address.c | 69 +++---
 tests/hw-tests/meson.build | 25 
 tests/meson.build  |  3 +-
 9 files changed, 124 insertions(+), 34 deletions(-)
 create mode 100644 tests/hw-tests/Makefile.am
 create mode 100644 tests/hw-tests/Makefile.sources
 rename tests/{ => hw-tests}/gem_bad_address.c (52%)
 create mode 100644 tests/hw-tests/meson.build

-- 
2.14.1

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

[Intel-gfx] [PATCH 8/8] HAX Enable GuC Submission for CI

[Michał Winiarski]

Also:

Revert "drm/i915/GuC/GLK: Load GuC on GLK"

Now that we no longer have fallback to execlists submission available,
if the firmware is selected by the driver but is not available on the
system (like in this case - where the FW is not yet released), we're
unable to get a clean CI run.

This reverts commit 90f192c8241e431d2c3076e4f2cb99ac25bfb1c5.
---
 drivers/gpu/drm/i915/i915_params.h  | 2 +-
 drivers/gpu/drm/i915/intel_guc_fw.c | 9 -
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 792ce26d7449..9725c5ad8ac6 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,7 +45,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_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index cbc51c960425..3b0932942857 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -39,9 +39,6 @@
 #define KBL_FW_MAJOR 9
 #define KBL_FW_MINOR 39
 
-#define GLK_FW_MAJOR 10
-#define GLK_FW_MINOR 56
-
 #define GUC_FW_PATH(platform, major, minor) \
"i915/" __stringify(platform) "_guc_ver" __stringify(major) "_" 
__stringify(minor) ".bin"
 
@@ -54,8 +51,6 @@ MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
 #define I915_KBL_GUC_UCODE GUC_FW_PATH(kbl, KBL_FW_MAJOR, KBL_FW_MINOR)
 MODULE_FIRMWARE(I915_KBL_GUC_UCODE);
 
-#define I915_GLK_GUC_UCODE GUC_FW_PATH(glk, GLK_FW_MAJOR, GLK_FW_MINOR)
-
 static void guc_fw_select(struct intel_uc_fw *guc_fw)
 {
struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw);
@@ -82,10 +77,6 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw)
guc_fw->path = I915_KBL_GUC_UCODE;
guc_fw->major_ver_wanted = KBL_FW_MAJOR;
guc_fw->minor_ver_wanted = KBL_FW_MINOR;
-   } else if (IS_GEMINILAKE(dev_priv)) {
-   guc_fw->path = I915_GLK_GUC_UCODE;
-   guc_fw->major_ver_wanted = GLK_FW_MAJOR;
-   guc_fw->minor_ver_wanted = GLK_FW_MINOR;
} else {
DRM_WARN("%s: No firmware known for this platform!\n",
 intel_uc_fw_type_repr(guc_fw->type));
-- 
2.14.3

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

[Intel-gfx] [PATCH 7/8] drm/i915/guc: Extract doorbell verification into a function

[Michał Winiarski]

We have the selftest that's checking doorbell create/destroy, so there's
no need to check all doorbells delaying the reset every time.
We do want to have that extra sanity check at module load/unload though.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 488110602e7e..4d2409466a3a 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -820,9 +820,19 @@ static bool doorbell_ok(struct intel_guc *guc, u16 db_id)
return false;
 }
 
-static int guc_clients_doorbell_init(struct intel_guc *guc)
+static bool guc_verify_doorbells(struct intel_guc *guc)
 {
u16 db_id;
+
+   for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id)
+   if (!doorbell_ok(guc, db_id))
+   return false;
+
+   return true;
+}
+
+static int guc_clients_doorbell_init(struct intel_guc *guc)
+{
int ret;
 
ret = create_doorbell(guc->execbuf_client);
@@ -835,10 +845,6 @@ static int guc_clients_doorbell_init(struct intel_guc *guc)
return ret;
}
 
-   /* Read back & verify all (used & unused) doorbell registers */
-   for (db_id = 0; db_id < GUC_NUM_DOORBELLS; ++db_id)
-   WARN_ON(!doorbell_ok(guc, db_id));
-
return 0;
 }
 
@@ -1149,6 +1155,7 @@ int intel_guc_submission_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
 
+   WARN_ON(!guc_verify_doorbells(guc));
ret = guc_clients_create(guc);
if (ret)
return ret;
@@ -1177,6 +1184,8 @@ void intel_guc_submission_fini(struct intel_guc *guc)
cancel_work_sync(>preempt_work[id].work);
 
guc_clients_destroy(guc);
+   WARN_ON(!guc_verify_doorbells(guc));
+
guc_ads_destroy(guc);
intel_guc_log_destroy(guc);
guc_stage_desc_pool_destroy(guc);
-- 
2.14.3

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

[Intel-gfx] [PATCH 6/8] drm/i915/guc: Extract clients allocation to submission_init

[Michał Winiarski]

We can now move the clients allocation to submission_init path, rather
than keeping the condition inside submission_enable called on every
reset.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 33 ++---
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index c74e78b6ba41..488110602e7e 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1149,6 +1149,10 @@ int intel_guc_submission_init(struct intel_guc *guc)
goto err_log;
GEM_BUG_ON(!guc->ads_vma);
 
+   ret = guc_clients_create(guc);
+   if (ret)
+   return ret;
+
for_each_engine(engine, dev_priv, id) {
guc->preempt_work[id].engine = engine;
INIT_WORK(>preempt_work[id].work, inject_preempt_context);
@@ -1172,6 +1176,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
for_each_engine(engine, dev_priv, id)
cancel_work_sync(>preempt_work[id].work);
 
+   guc_clients_destroy(guc);
guc_ads_destroy(guc);
intel_guc_log_destroy(guc);
guc_stage_desc_pool_destroy(guc);
@@ -1277,28 +1282,18 @@ int intel_guc_submission_enable(struct intel_guc *guc)
 sizeof(struct guc_wq_item) *
 I915_NUM_ENGINES > GUC_WQ_SIZE);
 
-   /*
-* We're being called on both module initialization and on reset,
-* until this flow is changed, we're using regular client presence to
-* determine which case are we in, and whether we should allocate new
-* clients or just reset their workqueues.
-*/
-   if (!guc->execbuf_client) {
-   err = guc_clients_create(guc);
-   if (err)
-   return err;
-   } else {
-   guc_reset_wq(guc->execbuf_client);
-   guc_reset_wq(guc->preempt_client);
-   }
+   GEM_BUG_ON(!guc->execbuf_client);
+
+   guc_reset_wq(guc->execbuf_client);
+   guc_reset_wq(guc->preempt_client);
 
err = intel_guc_sample_forcewake(guc);
if (err)
-   goto err_free_clients;
+   return err;
 
err = guc_clients_doorbell_init(guc);
if (err)
-   goto err_free_clients;
+   return err;
 
/* Take over from manual control of ELSP (execlists) */
guc_interrupts_capture(dev_priv);
@@ -1315,10 +1310,6 @@ int intel_guc_submission_enable(struct intel_guc *guc)
}
 
return 0;
-
-err_free_clients:
-   guc_clients_destroy(guc);
-   return err;
 }
 
 void intel_guc_submission_disable(struct intel_guc *guc)
@@ -1332,8 +1323,6 @@ void intel_guc_submission_disable(struct intel_guc *guc)
 
/* Revert back to manual ELSP submission */
intel_engines_reset_default_submission(dev_priv);
-
-   guc_clients_destroy(guc);
 }
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
-- 
2.14.3

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

[Intel-gfx] [PATCH 5/8] drm/i915/guc: Extract doorbell creation from client allocation

[Michał Winiarski]

Full GPU reset causes GuC to be reset. This means that every time we're
doing a reset, we need to talk to GuC and tell it about doorbells.
Let's separate the communication part (create_doorbell) from our
internal bookkeeping (reserve_doorbell) so that we can cleanly separate
the initialization done at module load from reinitialization done at
reset in the following patch.
While I'm here, let's also add a proper (although slightly asymetric)
cleanup that doesn't try to communicate with GuC after it's already
gone, getting rid of "expected" warnings caused by GuC action failures
on module unload.

Note that I've also removed one of the tests (bitmap out of sync), since
it doesn't make much sense anymore - bitmaps are now not expected to
change during the lifetime of a client.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_guc_submission.c | 151 
 drivers/gpu/drm/i915/selftests/intel_guc.c  | 110 +---
 2 files changed, 88 insertions(+), 173 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c 
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 8f4b274d66a7..c74e78b6ba41 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -88,7 +88,7 @@ static inline bool is_high_priority(struct intel_guc_client 
*client)
client->priority == GUC_CLIENT_PRIORITY_HIGH);
 }
 
-static int __reserve_doorbell(struct intel_guc_client *client)
+static int reserve_doorbell(struct intel_guc_client *client)
 {
unsigned long offset;
unsigned long end;
@@ -120,7 +120,7 @@ static int __reserve_doorbell(struct intel_guc_client 
*client)
return 0;
 }
 
-static void __unreserve_doorbell(struct intel_guc_client *client)
+static void unreserve_doorbell(struct intel_guc_client *client)
 {
GEM_BUG_ON(client->doorbell_id == GUC_DOORBELL_INVALID);
 
@@ -188,32 +188,21 @@ static bool has_doorbell(struct intel_guc_client *client)
return test_bit(client->doorbell_id, client->guc->doorbell_bitmap);
 }
 
-static int __create_doorbell(struct intel_guc_client *client)
+static void __create_doorbell(struct intel_guc_client *client)
 {
struct guc_doorbell_info *doorbell;
-   int err;
 
doorbell = __get_doorbell(client);
doorbell->db_status = GUC_DOORBELL_ENABLED;
doorbell->cookie = 0;
-
-   err = __guc_allocate_doorbell(client->guc, client->stage_id);
-   if (err) {
-   doorbell->db_status = GUC_DOORBELL_DISABLED;
-   DRM_ERROR("Couldn't create client %u doorbell: %d\n",
- client->stage_id, err);
-   }
-
-   return err;
 }
 
-static int __destroy_doorbell(struct intel_guc_client *client)
+static void __destroy_doorbell(struct intel_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(client->guc);
struct guc_doorbell_info *doorbell;
u16 db_id = client->doorbell_id;
 
-   GEM_BUG_ON(db_id >= GUC_DOORBELL_INVALID);
 
doorbell = __get_doorbell(client);
doorbell->db_status = GUC_DOORBELL_DISABLED;
@@ -225,50 +214,42 @@ static int __destroy_doorbell(struct intel_guc_client 
*client)
 */
if (wait_for_us(!(I915_READ(GEN8_DRBREGL(db_id)) & GEN8_DRB_VALID), 10))
WARN_ONCE(true, "Doorbell never became invalid after 
disable\n");
-
-   return __guc_deallocate_doorbell(client->guc, client->stage_id);
 }
 
 static int create_doorbell(struct intel_guc_client *client)
 {
int ret;
 
-   ret = __reserve_doorbell(client);
-   if (ret)
-   return ret;
-
__update_doorbell_desc(client, client->doorbell_id);
+   __create_doorbell(client);
 
-   ret = __create_doorbell(client);
-   if (ret)
-   goto err;
+   ret = __guc_allocate_doorbell(client->guc, client->stage_id);
+   if (ret) {
+   __destroy_doorbell(client);
+   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
+   DRM_ERROR("Couldn't create client %u doorbell: %d\n",
+ client->stage_id, ret);
+   return ret;
+   }
 
return 0;
-
-err:
-   __update_doorbell_desc(client, GUC_DOORBELL_INVALID);
-   __unreserve_doorbell(client);
-   return ret;
 }
 
 static int destroy_doorbell(struct intel_guc_client *client)
 {
-   int err;
+   int ret;
 
GEM_BUG_ON(!has_doorbell(client));
 
-   /* XXX: wait for any interrupts */
-   /* XXX: wait for workqueue to drain */
-
-   err = __destroy_doorbell(client);
-   if (err)
-   return err;
+   __destroy_doorbell(client);
+   ret = __guc_deallocate_doorbell(client->guc, 

[Intel-gfx] [PATCH v2 2/8] drm/i915/guc: Move GuC workqueue allocations outside of the mutex

[Michał Winiarski]

This gets rid of the following lockdep splat:

==
WARNING: possible circular locking dependency detected
4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
--
debugfs_test/1351 is trying to acquire lock:
 (>struct_mutex){+.+.}, at: [<9d90d1a3>] 
i915_mutex_lock_interruptible+0x47/0x130 [i915]

but task is already holding lock:
 (>mmap_sem){}, at: [<5df01c1e>] __do_page_fault+0x106/0x560

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #6 (>mmap_sem){}:
   __might_fault+0x63/0x90
   _copy_to_user+0x1e/0x70
   filldir+0x8c/0xf0
   dcache_readdir+0xeb/0x160
   iterate_dir+0xe6/0x150
   SyS_getdents+0xa0/0x130
   entry_SYSCALL_64_fastpath+0x1c/0x89

-> #5 (>s_type->i_mutex_key#5){}:
   lockref_get+0x9/0x20

-> #4 ((completion)){+.+.}:
   wait_for_common+0x54/0x210
   devtmpfs_create_node+0x130/0x150
   device_add+0x5ad/0x5e0
   device_create_groups_vargs+0xd4/0xe0
   device_create+0x35/0x40
   msr_device_create+0x22/0x40
   cpuhp_invoke_callback+0xc5/0xbf0
   cpuhp_thread_fun+0x167/0x210
   smpboot_thread_fn+0x17f/0x270
   kthread+0x173/0x1b0
   ret_from_fork+0x24/0x30

-> #3 (cpuhp_state-up){+.+.}:
   cpuhp_issue_call+0x132/0x1c0
   __cpuhp_setup_state_cpuslocked+0x12f/0x2a0
   __cpuhp_setup_state+0x3a/0x50
   page_writeback_init+0x3a/0x5c
   start_kernel+0x393/0x3e2
   secondary_startup_64+0xa5/0xb0

-> #2 (cpuhp_state_mutex){+.+.}:
   __mutex_lock+0x81/0x9b0
   __cpuhp_setup_state_cpuslocked+0x4b/0x2a0
   __cpuhp_setup_state+0x3a/0x50
   page_alloc_init+0x1f/0x26
   start_kernel+0x139/0x3e2
   secondary_startup_64+0xa5/0xb0

-> #1 (cpu_hotplug_lock.rw_sem){}:
   cpus_read_lock+0x34/0xa0
   apply_workqueue_attrs+0xd/0x40
   __alloc_workqueue_key+0x2c7/0x4e1
   intel_guc_submission_init+0x10c/0x650 [i915]
   intel_uc_init_hw+0x29e/0x460 [i915]
   i915_gem_init_hw+0xca/0x290 [i915]
   i915_gem_init+0x115/0x3a0 [i915]
   i915_driver_load+0x9a8/0x16c0 [i915]
   i915_pci_probe+0x2e/0x90 [i915]
   pci_device_probe+0x9c/0x120
   driver_probe_device+0x2a3/0x480
   __driver_attach+0xd9/0xe0
   bus_for_each_dev+0x57/0x90
   bus_add_driver+0x168/0x260
   driver_register+0x52/0xc0
   do_one_initcall+0x39/0x150
   do_init_module+0x56/0x1ef
   load_module+0x231c/0x2d70
   SyS_finit_module+0xa5/0xe0
   entry_SYSCALL_64_fastpath+0x1c/0x89

-> #0 (>struct_mutex){+.+.}:
   lock_acquire+0xaf/0x200
   __mutex_lock+0x81/0x9b0
   i915_mutex_lock_interruptible+0x47/0x130 [i915]
   i915_gem_fault+0x201/0x760 [i915]
   __do_fault+0x15/0x70
   __handle_mm_fault+0x85b/0xe40
   handle_mm_fault+0x14f/0x2f0
   __do_page_fault+0x2d1/0x560
   page_fault+0x22/0x30

other info that might help us debug this:

Chain exists of:
  >struct_mutex --> >s_type->i_mutex_key#5 --> >mmap_sem

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(>mmap_sem);
   lock(>s_type->i_mutex_key#5);
   lock(>mmap_sem);
  lock(>struct_mutex);

 *** DEADLOCK ***

1 lock held by debugfs_test/1351:
 #0:  (>mmap_sem){}, at: [<5df01c1e>] 
__do_page_fault+0x106/0x560

stack backtrace:
CPU: 2 PID: 1351 Comm: debugfs_test Not tainted 4.15.0-rc2-CI-Patchwork_7428+ #1
Hardware name:  /NUC6i5SYB, BIOS 
SYSKLi35.86A.0057.2017.0119.1758 01/19/2017
Call Trace:
 dump_stack+0x5f/0x86
 print_circular_bug+0x230/0x3b0
 check_prev_add+0x439/0x7b0
 ? lockdep_init_map_crosslock+0x20/0x20
 ? unwind_get_return_address+0x16/0x30
 ? __lock_acquire+0x1385/0x15a0
 __lock_acquire+0x1385/0x15a0
 lock_acquire+0xaf/0x200
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 __mutex_lock+0x81/0x9b0
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
 i915_mutex_lock_interruptible+0x47/0x130 [i915]
 ? __pm_runtime_resume+0x4f/0x80
 i915_gem_fault+0x201/0x760 [i915]
 __do_fault+0x15/0x70
 __handle_mm_fault+0x85b/0xe40
 handle_mm_fault+0x14f/0x2f0
 __do_page_fault+0x2d1/0x560
 page_fault+0x22/0x30
RIP: 0033:0x7f98d6f49116
RSP: 002b:7ffd6ffc3278 EFLAGS: 00010283
RAX: 7f98d39a2bc0 RBX:  RCX: 1680
RDX: 1680 RSI: 7ffd6ffc3400 RDI: 7f98d39a2bc0
RBP: 7ffd6ffc33a0 R08:  R09: 05a0
R10: 55e847c2a830 R11: 0002 R12: 0001
R13: 55e847c1d040 R14: 7ffd6ffc3400 R15: 7f98d6752ba0

v2: Init preempt_work unconditionally (Chris)

Testcase: igt/debugfs_test/read_all_entries
Signed-off-by: Michał Winiarski 
Cc: 

[Intel-gfx] [PATCH v2 3/8] drm/i915/guc: Extract guc_init from guc_init_hw

[Michał Winiarski]

After GPU reset, GuC HW needs to be reinitialized (with FW reload).
Unfortunately, we're doing some extra work there (mostly allocating stuff),
work that can be moved to guc_init and called once at driver load time.

As a side effect we're no longer hitting an assert in
i915_ggtt_enable_guc on suspend/resume.

v2: Do not duplicate disable_communication / reset_guc_interrupts

References: 04f7b24eccdf ("drm/i915/guc: Assert that we switch between known 
ggtt->invalidate functions")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |  1 +
 drivers/gpu/drm/i915/i915_gem.c |  4 +++
 drivers/gpu/drm/i915/intel_uc.c | 71 ++---
 drivers/gpu/drm/i915/intel_uc.h |  2 ++
 4 files changed, 53 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 285c8b238bff..ca9f4b2862eb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -617,6 +617,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
 
mutex_lock(_priv->drm.struct_mutex);
intel_uc_fini_hw(dev_priv);
+   intel_uc_fini(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_contexts_fini(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4b2ca43a610f..77e4091a7c71 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5187,6 +5187,10 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 
intel_init_gt_powersave(dev_priv);
 
+   ret = intel_uc_init(dev_priv);
+   if (ret)
+   goto out_unlock;
+
ret = i915_gem_init_hw(dev_priv);
if (ret)
goto out_unlock;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 785850838a44..907deac6e3fa 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -214,26 +214,20 @@ void intel_uc_fini_wq(struct drm_i915_private *dev_priv)
intel_guc_fini_wq(_priv->guc);
 }
 
-int intel_uc_init_hw(struct drm_i915_private *dev_priv)
+int intel_uc_init(struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
-   struct intel_huc *huc = _priv->huc;
-   int ret, attempts;
+   int ret;
 
if (!USES_GUC(dev_priv))
return 0;
 
-   if (!HAS_GUC(dev_priv)) {
-   ret = -ENODEV;
-   goto err_out;
-   }
-
-   guc_disable_communication(guc);
-   gen9_reset_guc_interrupts(dev_priv);
+   if (!HAS_GUC(dev_priv))
+   return -ENODEV;
 
ret = intel_guc_init(guc);
if (ret)
-   goto err_out;
+   return ret;
 
if (USES_GUC_SUBMISSION(dev_priv)) {
/*
@@ -241,10 +235,44 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 * if we are planning to enable submission later
 */
ret = intel_guc_submission_init(guc);
-   if (ret)
-   goto err_guc;
+   if (ret) {
+   intel_guc_fini(guc);
+   return ret;
+   }
}
 
+   return 0;
+}
+
+void intel_uc_fini(struct drm_i915_private *dev_priv)
+{
+   struct intel_guc *guc = _priv->guc;
+
+   if (!USES_GUC(dev_priv))
+   return;
+
+   GEM_BUG_ON(!HAS_GUC(dev_priv));
+
+   if (USES_GUC_SUBMISSION(dev_priv))
+   intel_guc_submission_fini(guc);
+
+   intel_guc_fini(guc);
+}
+
+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))
+   return 0;
+
+   GEM_BUG_ON(!HAS_GUC(dev_priv));
+
+   guc_disable_communication(guc);
+   gen9_reset_guc_interrupts(dev_priv);
+
/* init WOPCM */
I915_WRITE(GUC_WOPCM_SIZE, intel_guc_wopcm_size(dev_priv));
I915_WRITE(DMA_GUC_WOPCM_OFFSET,
@@ -264,12 +292,12 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 */
ret = __intel_uc_reset_hw(dev_priv);
if (ret)
-   goto err_submission;
+   goto err_out;
 
if (USES_HUC(dev_priv)) {
ret = intel_huc_init_hw(huc);
if (ret)
-   goto err_submission;
+   goto err_out;
}
 
intel_guc_init_params(guc);
@@ -322,11 +350,6 @@ int 

[Intel-gfx] [PATCH 4/8] drm/i915/guc: Call invalidate after changing the vfunc

[Michał Winiarski]

To make this operation a bit cleaner, we should make sure that the HW
can catch up by calling the new implementation right away.
Note that currently we're only touching the vfunc at module load time
(before GuC is even loaded), so this shouldn't cause any functional
changes.

Suggested-by: Chris Wilson 
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a0579b0c8581..c5f393870532 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3552,6 +3552,8 @@ 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;
+
+   i915_ggtt_invalidate(i915);
 }
 
 void i915_ggtt_disable_guc(struct drm_i915_private *i915)
@@ -3560,6 +3562,8 @@ void i915_ggtt_disable_guc(struct drm_i915_private *i915)
GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
 
i915->ggtt.invalidate = gen6_ggtt_invalidate;
+
+   i915_ggtt_invalidate(i915);
 }
 
 void i915_gem_restore_gtt_mappings(struct drm_i915_private *dev_priv)
-- 
2.14.3

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

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Move shared data allocation away from submission path

[Michał Winiarski]

We need shared data for actions (e.g. guc suspend/resume), and we're
using those with GuC submission disabled.
Let's introduce intel_guc_init and move shared data alloc there.

This fixes GPF during module unload with HuC, but without GuC submission:

BUG: unable to handle kernel NULL pointer dereference at 5aee7809
IP: intel_guc_suspend+0x34/0x140 [i915]
PGD 0 P4D 0
Oops:  [#1] PREEMPT SMP
Modules linked in: i915(O-) netconsole x86_pkg_temp_thermal
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
mei_me i2c_i801 mei prime_numbers [last unloaded: i915]
CPU: 2 PID: 2794 Comm: rmmod Tainted: G U  W  O 4.15.0-rc2+ #297
Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016
task: 55945c61 task.stack: 264ccb43
RIP: 0010:intel_guc_suspend+0x34/0x140 [i915]
RSP: 0018:c9483df8 EFLAGS: 00010286
RAX:  RBX: 88082918 RCX: 
RDX: 0006 RSI: 880844c2c938 RDI: 880844c2c000
RBP: 88082918 R08: a29c58c1 R09: 
R10:  R11:  R12: a040ba40
R13: a040bab0 R14: 88084a195060 R15: 55df3ef357a0
FS:  7ff43c043740() GS:88084e20() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 00f9 CR3: 00083f179005 CR4: 003606e0
Call Trace:
 i915_gem_suspend+0x9d/0x130 [i915]
 ? i915_driver_unload+0x68/0x180 [i915]
 i915_driver_unload+0x70/0x180 [i915]
 i915_pci_remove+0x15/0x20 [i915]
 pci_device_remove+0x36/0xb0
 device_release_driver_internal+0x15f/0x220
 driver_detach+0x3a/0x80
 bus_remove_driver+0x58/0xd0
 pci_unregister_driver+0x29/0x90
 SyS_delete_module+0x150/0x1e0
 entry_SYSCALL_64_fastpath+0x23/0x9a
RIP: 0033:0x7ff43b51b5c7
RSP: 002b:7ffe6825a758 EFLAGS: 0206 ORIG_RAX: 00b0
RAX: ffda RBX: 0003 RCX: 7ff43b51b5c7
RDX: 000a RSI: 0800 RDI: 55df3ef35808
RBP:  R08: 7ffe682596d1 R09: 
R10: 7ff43b594880 R11: 0206 R12: 55df3ef357a0
R13: 7ffe68259740 R14: 55df3ef35260 R15: 55df3ef357a0
Code: 00 00 02 74 03 31 c0 c3 53 48 89 fb 48 83 ec 10 e8 52 0f
f8 ff 48 b8 01 05 00 00 02 00 00 00 48 89 44 24 04 48 8b 83 00 12 00 00  80
f9 00 00 00 01 0f 84 a7 00 00 00 f6 80 98 00 00 00 01 0f
RIP: intel_guc_suspend+0x34/0x140 [i915] RSP: c9483df8
CR2: 00f9
---[ end trace 23a192a61d937a3e ]---

Fixes: b8e5eb960b28 ("drm/i915/guc: Allocate separate shared data object for 
GuC communication")
Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c| 51 +
 drivers/gpu/drm/i915/intel_guc.h|  2 ++
 drivers/gpu/drm/i915/intel_guc_submission.c | 37 +
 drivers/gpu/drm/i915/intel_uc.c | 10 +++---
 4 files changed, 60 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 177ee69ca9b1..92ed22f38fc4 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -69,6 +69,57 @@ void intel_guc_init_early(struct intel_guc *guc)
guc->notify = gen8_guc_raise_irq;
 }
 
+static int guc_shared_data_create(struct intel_guc *guc)
+{
+   struct i915_vma *vma;
+   void *vaddr;
+
+   vma = intel_guc_allocate_vma(guc, PAGE_SIZE);
+   if (IS_ERR(vma))
+   return PTR_ERR(vma);
+
+   vaddr = i915_gem_object_pin_map(vma->obj, I915_MAP_WB);
+   if (IS_ERR(vaddr)) {
+   i915_vma_unpin_and_release();
+   return PTR_ERR(vaddr);
+   }
+
+   guc->shared_data = vma;
+   guc->shared_data_vaddr = vaddr;
+
+   return 0;
+}
+
+static void guc_shared_data_destroy(struct intel_guc *guc)
+{
+   i915_gem_object_unpin_map(guc->shared_data->obj);
+   i915_vma_unpin_and_release(>shared_data);
+}
+
+int intel_guc_init(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   int ret;
+
+   ret = guc_shared_data_create(guc);
+   if (ret)
+   return ret;
+   GEM_BUG_ON(!guc->shared_data);
+
+   /* We need to notify the guc whenever we change the GGTT */
+   i915_ggtt_enable_guc(dev_priv);
+
+   return 0;
+}
+
+void intel_guc_fini(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+   i915_ggtt_disable_guc(dev_priv);
+   guc_shared_data_destroy(guc);
+}
+
 static u32 get_gt_type(struct drm_i915_private *dev_priv)
 {
/* XXX: GT type based on PCI device ID? field seems unused by fw */
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index