Re: [Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

[Kai Heng Feng]

> On 25 Jan 2018, at 2:56 AM, Rodrigo Vivi  wrote:
> 
> If the table result is out of bounds on the array map
> there is something really wrong with VBT pin so we don't
> return that vbt_pin, but only return 0 instead.
> 
> This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
> Ignore VBT request for know invalid DDC pin.")'
> 
> Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
> Map VBT DDC Pin to BSpec DDC Pin.")
> 
> Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC 
> pin.")
> Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
> Cc: Radhakrishna Sripada 
> Cc: Jani Nikula 
> Cc: Kai Heng Feng 
> Signed-off-by: Rodrigo Vivi 

Tested-by: Kai-Heng Feng 

> ---
> drivers/gpu/drm/i915/intel_bios.c | 13 -
> 1 file changed, 4 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 95f0b310d656..844c1e8f574f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1115,16 +1115,11 @@ static const u8 cnp_ddc_pin_map[] = {
> 
> static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> {
> - if (HAS_PCH_CNP(dev_priv)) {
> - if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> - return cnp_ddc_pin_map[vbt_pin];
> - if (vbt_pin > GMBUS_PIN_4_CNP) {
> - DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC 
> pin %d, which is not valid for this platform\n", vbt_pin);
> - return 0;
> - }
> - }
> + if (HAS_PCH_CNP(dev_priv) &&
> + vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> + return cnp_ddc_pin_map[vbt_pin];
> 
> - return vbt_pin;
> + return 0;
> }
> 
> static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
> -- 
> 2.13.6
> 

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks (rev2)

[Patchwork]

== Series Details ==

Series: drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit 
bitmasks (rev2)
URL   : https://patchwork.freedesktop.org/series/37058/
State : success

== Summary ==

Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-b-planes:
pass   -> FAIL   (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-modeset-interruptible:
dmesg-warn -> PASS   (shard-hsw)
Subgroup plain-flip-fb-recreate-interruptible:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test drv_suspend:
Subgroup forcewake-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-atomic:
fail   -> PASS   (shard-apl)

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

shard-apltotal:2838 pass:1753 dwarn:1   dfail:0   fail:22  skip:1062 
time:12529s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:0   fail:13  skip:1090 
time:11853s
shard-snbtotal:2838 pass:1328 dwarn:1   dfail:0   fail:11  skip:1498 
time:6626s
Blacklisted hosts:
shard-kbltotal:2740 pass:1799 dwarn:9   dfail:1   fail:25  skip:905 
time:9131s

== Logs ==

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

Re: [Intel-gfx] [PULL] drm-misc-fixes for 4.15

[Sean Paul]

On Wed, Jan 24, 2018, 8:13 PM Daniel Vetter  wrote:

> On Wed, Jan 24, 2018 at 7:54 PM, Sean Paul  wrote:
> >
> > Hi Dave,
> > I'm sending this since danvet is down under this week. We've collected a
> couple
> > fixes in drm-misc-fixes this week, and since we're still in the business
> of
> > 4.15, I figured I'd send them along.
>
> Hah, was just about to check whether anything got applied because
> -rc9, and then wondered why there's a tag for which I didn't send out
> a pull request mail yet :-)
>
> Thanks a lot for doing this.
>

Maintainer team ftw! Good luck on your talk today.

Sean


> Cheers, Daniel
>
> >
> > drm-misc-fixes-2018-01-24:
> > Two vc4 fixes that were applied in the last day.
> > One fixes a NULL dereference, and the other fixes
> > a flickering bug.
> >
> > Cc: Eric Anholt 
> > Cc: Boris Brezillon 
> >
> > Cheers, Sean
> >
> >
> > The following changes since commit
> 75f195f46f27a2524b249b95e6f241cd13c7e549:
> >
> >   Merge tag 'drm-misc-fixes-2018-01-17' of git://
> anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-01-18 13:30:22
> +1000)
> >
> > are available in the Git repository at:
> >
> >   git://anongit.freedesktop.org/drm/drm-misc
> tags/drm-misc-fixes-2018-01-24
> >
> > for you to fetch changes up to 17b11b76b87afe9f8be199d7a5f442497133e2b0:
> >
> >   drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
> (2018-01-18 12:17:03 -0800)
> >
> > 
> > Two vc4 fixes that were applied in the last day.
> > One fixes a NULL dereference, and the other fixes
> > a flickering bug.
> >
> > Cc: Eric Anholt 
> > Cc: Boris Brezillon 
> >
> > 
> > Boris Brezillon (1):
> >   drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
> >
> > Eric Anholt (1):
> >   drm/vc4: Flush the caches before the bin jobs, as well.
> >
> >  drivers/gpu/drm/vc4/vc4_gem.c | 33 +++--
> >  1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] drm-misc-fixes for 4.15

[Daniel Vetter]

On Wed, Jan 24, 2018 at 7:54 PM, Sean Paul  wrote:
>
> Hi Dave,
> I'm sending this since danvet is down under this week. We've collected a 
> couple
> fixes in drm-misc-fixes this week, and since we're still in the business of
> 4.15, I figured I'd send them along.

Hah, was just about to check whether anything got applied because
-rc9, and then wondered why there's a tag for which I didn't send out
a pull request mail yet :-)

Thanks a lot for doing this.

Cheers, Daniel

>
> drm-misc-fixes-2018-01-24:
> Two vc4 fixes that were applied in the last day.
> One fixes a NULL dereference, and the other fixes
> a flickering bug.
>
> Cc: Eric Anholt 
> Cc: Boris Brezillon 
>
> Cheers, Sean
>
>
> The following changes since commit 75f195f46f27a2524b249b95e6f241cd13c7e549:
>
>   Merge tag 'drm-misc-fixes-2018-01-17' of 
> git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-01-18 
> 13:30:22 +1000)
>
> are available in the Git repository at:
>
>   git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-24
>
> for you to fetch changes up to 17b11b76b87afe9f8be199d7a5f442497133e2b0:
>
>   drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() (2018-01-18 
> 12:17:03 -0800)
>
> 
> Two vc4 fixes that were applied in the last day.
> One fixes a NULL dereference, and the other fixes
> a flickering bug.
>
> Cc: Eric Anholt 
> Cc: Boris Brezillon 
>
> 
> Boris Brezillon (1):
>   drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()
>
> Eric Anholt (1):
>   drm/vc4: Flush the caches before the bin jobs, as well.
>
>  drivers/gpu/drm/vc4/vc4_gem.c | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 12/27] drm/i915/icl: Add Indirect Context Offset for Gen11

[Michel Thierry]

v2: rebased to intel_lr_indirect_ctx_offset
v3: rebase, move define to intel_lrc_reg.h

BSpec: 11740
Signed-off-by: Michel Thierry 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Michal Wajdeczko 
Reviewed-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_lrc.c | 4 
 drivers/gpu/drm/i915/intel_lrc_reg.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4eb409dc9dd1..ecc07cc2ffc4 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2426,6 +2426,10 @@ static u32 intel_lr_indirect_ctx_offset(struct 
intel_engine_cs *engine)
default:
MISSING_CASE(INTEL_GEN(engine->i915));
/* fall through */
+   case 11:
+   indirect_ctx_offset =
+   GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
+   break;
case 10:
indirect_ctx_offset =
GEN10_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h 
b/drivers/gpu/drm/i915/intel_lrc_reg.h
index a53336e2fc97..169a2239d6c7 100644
--- a/drivers/gpu/drm/i915/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -63,5 +63,6 @@
 #define GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x17
 #define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x26
 #define GEN10_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x19
+#define GEN11_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x1A
 
 #endif /* _INTEL_LRC_REG_H_ */
-- 
2.16.1

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/8] drm/i915: Define an engine class enum for the uABI

[Jeff McGee]

On Fri, Nov 10, 2017 at 06:14:17PM +, Chris Wilson wrote:
> Quoting Patchwork (2017-11-10 16:46:14)
> > == Series Details ==
> > 
> > Series: series starting with [CI,1/8] drm/i915: Define an engine class enum 
> > for the uABI
> > URL   : https://patchwork.freedesktop.org/series/33606/
> > State : success
> > 
> > == Summary ==
> > 
> > Test kms_busy:
> > Subgroup extended-modeset-hang-oldfb-with-reset-render-c:
> > dmesg-warn -> PASS   (shard-hsw) fdo#102249
> > 
> > fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
> > 
> > shard-hswtotal:2584 pass:1453 dwarn:1   dfail:2   fail:10  
> > skip:1118 time:9370s
> > Blacklisted hosts:
> > shard-apltotal:2568 pass:1586 dwarn:3   dfail:1   fail:22  skip:955 
> > time:12758s
> > shard-kbltotal:2534 pass:1638 dwarn:31  dfail:4   fail:24  skip:835 
> > time:9791s
> > shard-snbtotal:2584 pass:1199 dwarn:2   dfail:2   fail:10  
> > skip:1371 time:7769s
> > 
> > == Logs ==
> > 
> > For more details see: 
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7062/shards.html
> 
> Sealed in the uabi, no regrets!
> 
> Thanks everyone for the review,
> -Chris

Hi Chris. Should this series for context isolation be added to the 4.14 LTS?
-Jeff
___
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: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks (rev2)

[Patchwork]

== Series Details ==

Series: drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit 
bitmasks (rev2)
URL   : https://patchwork.freedesktop.org/series/37058/
State : success

== Summary ==

Series 37058v2 drm: Warn if plane/crtc/encoder/connector index exceeds our 
32bit bitmasks
https://patchwork.freedesktop.org/api/1.0/series/37058/revisions/2/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:426s
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:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:495s
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:491s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:295s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:518s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:395s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:415s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:414s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:513s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:537s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:495s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:419s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
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:401s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:571s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s

9d8467fe5626095314bc34449457798dae066fbb drm-tip: 2018y-01m-24d-19h-59m-41s UTC 
integration manifest
1c7a8e2421cd drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit 
bitmasks

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Inhibit context save/restore for the fake preempt context

[Michel Thierry]

On 1/24/2018 12:46 PM, Chris Wilson wrote:

Quoting Chris Wilson (2018-01-24 09:44:45)

Quoting Michel Thierry (2018-01-24 01:24:25)

On 1/23/2018 1:04 PM, Chris Wilson wrote:

We only use the preempt context to inject an idle point into execlists.
We never need to reference its logical state, so tell the GPU never to
load it or save it.

v2: BIT(2) for save-inhibit.

N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the
submission process rather than the context image.

Suggested-by: Daniele Ceraolo Spurio 
Signed-off-by: Chris Wilson 
Cc: Michal Winiarski 
Cc: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Cc: Daniele Ceraolo Spurio 
---
   drivers/gpu/drm/i915/intel_lrc.c | 4 
   drivers/gpu/drm/i915/intel_lrc.h | 1 +
   2 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 22d471a4228d..c28f267a8417 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2285,6 +2285,10 @@ populate_lr_context(struct i915_gem_context *ctx,
   if (!engine->default_state)
   regs[CTX_CONTEXT_CONTROL + 1] |=
   _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
+ if (ctx->hw_id == PREEMPT_ID)
+ regs[CTX_CONTEXT_CONTROL + 1] |=
+ _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
+CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT);



This shouldn't break anything and ICL is not merged yet (plus things may
still change) so if you want to merge this,


I think it's the right thing conceptually to do.


Uhoh, seeing GPU hangs on Broxton when thrashing preemption.
Is the bit still valid?


It should be valid, but nobody used cxt save inhibit until now (it 
doesn't surprise bxt is doing something different).


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

[Patchwork]

== Series Details ==

Series: drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
URL   : https://patchwork.freedesktop.org/series/37060/
State : failure

== Summary ==

Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test kms_plane:
Subgroup plane-position-hole-dpms-pipe-b-planes:
pass   -> FAIL   (shard-apl)
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-hsw) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +2
Test kms_plane_lowres:
Subgroup pipe-a-tiling-none:
pass   -> SKIP   (shard-snb)
Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (shard-snb)
Test kms_draw_crc:
Subgroup draw-method-rgb565-blt-xtiled:
pass   -> SKIP   (shard-snb)
Test kms_cursor_legacy:
Subgroup long-nonblocking-modeset-vs-cursor-atomic:
pass   -> SKIP   (shard-snb)
Subgroup flip-vs-cursor-crc-atomic:
fail   -> PASS   (shard-apl)
Test kms_busy:
Subgroup extended-pageflip-hang-oldfb-render-b:
pass   -> SKIP   (shard-snb)
Test kms_flip:
Subgroup plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-apltotal:2838 pass:1751 dwarn:1   dfail:0   fail:23  skip:1062 
time:12533s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:0   fail:12  skip:1091 
time:11851s
shard-snbtotal:2838 pass:1324 dwarn:1   dfail:0   fail:10  skip:1503 
time:6543s
Blacklisted hosts:
shard-kbltotal:2838 pass:1865 dwarn:8   dfail:1   fail:24  skip:940 
time:9529s

== Logs ==

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

[Intel-gfx] [PATCH v2] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Ville Syrjala]

From: Ville Syrjälä 

We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
Naturally we can only do that if the index of those objects stays
below 32. Issue a warning whenever we exceed that limit, hopefully
prompting someone to fix the problem.

For connectors the issue is a bit more complicated as they can
be created/destroyed at runtime due to MST. So the problem is no
longer a purely theoretical programmer error. As the connector
indexes are allocated via ida, we can simply limit the maximum
value the ida is allowed to hand out. The error handling is already
in place.

v2: Return an error to the caller (Harry)

Cc: Harry Wentland 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c | 3 ++-
 drivers/gpu/drm/drm_crtc.c  | 4 
 drivers/gpu/drm/drm_encoder.c   | 4 
 drivers/gpu/drm/drm_plane.c | 4 
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b85a7749709d..f4a689ab990a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -205,7 +205,8 @@ int drm_connector_init(struct drm_device *dev,
connector->dev = dev;
connector->funcs = funcs;
 
-   ret = ida_simple_get(>connector_ida, 0, 0, GFP_KERNEL);
+   /* connector index is used with 32bit bitmasks */
+   ret = ida_simple_get(>connector_ida, 0, 32, GFP_KERNEL);
if (ret < 0)
goto out_put;
connector->index = ret;
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f0556e654116..5b4be382a1d7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -282,6 +282,10 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
WARN_ON(primary && primary->type != DRM_PLANE_TYPE_PRIMARY);
WARN_ON(cursor && cursor->type != DRM_PLANE_TYPE_CURSOR);
 
+   /* crtc index is used with 32bit bitmasks */
+   if (WARN_ON(config->num_crtc >= 32))
+   return -EINVAL;
+
crtc->dev = dev;
crtc->funcs = funcs;
 
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 59e0ebe733f8..273e1c59c54a 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -110,6 +110,10 @@ int drm_encoder_init(struct drm_device *dev,
 {
int ret;
 
+   /* encoder index is used with 32bit bitmasks */
+   if (WARN_ON(dev->mode_config.num_encoder >= 32))
+   return -EINVAL;
+
ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_ENCODER);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 2c90519576a3..22b54663b6e7 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -173,6 +173,10 @@ int drm_universal_plane_init(struct drm_device *dev, 
struct drm_plane *plane,
unsigned int format_modifier_count = 0;
int ret;
 
+   /* plane index is used with 32bit bitmasks */
+   if (WARN_ON(config->num_total_plane >= 32))
+   return -EINVAL;
+
ret = drm_mode_object_add(dev, >base, DRM_MODE_OBJECT_PLANE);
if (ret)
return ret;
-- 
2.13.6

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Assert that we don't overflow frontbuffer tracking bits

[Patchwork]

== Series Details ==

Series: drm/i915: Assert that we don't overflow frontbuffer tracking bits
URL   : https://patchwork.freedesktop.org/series/37057/
State : failure

== Summary ==

Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup blocking:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623 +1
Test kms_cursor_crc:
Subgroup cursor-64x64-random:
pass   -> DMESG-FAIL (shard-hsw)
Subgroup cursor-256x256-suspend:
pass   -> SKIP   (shard-hsw) fdo#103375
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-crc-atomic:
fail   -> PASS   (shard-apl)

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

shard-apltotal:2838 pass:1752 dwarn:1   dfail:0   fail:23  skip:1062 
time:12615s
shard-hswtotal:2838 pass:1733 dwarn:1   dfail:1   fail:11  skip:1091 
time:11870s
shard-snbtotal:2838 pass:1330 dwarn:1   dfail:0   fail:10  skip:1497 
time:6593s
Blacklisted hosts:
shard-kbltotal:2838 pass:1855 dwarn:18  dfail:1   fail:24  skip:940 
time:9521s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 11:24:05PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 24, 2018 at 04:01:18PM -0500, Harry Wentland wrote:
> > On 2018-01-24 01:37 PM, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > > Naturally we can only do that if the index of those objects stays
> > > below 32. Issue a warning whenever we exceed that limit, hopefully
> > > prompting someone to fix the problem.
> > > 
> > > Or should we just outright fail the object initializatio perhaps?
> > > 
> > 
> > This would make sense in my opinion. index >= 32 looks like it would lead 
> > to completely undefined behavior when trying to attach objects to each 
> > other.
> 
> I suppose. The counter argument is that this is basically the developer
> shooting themselves in the foot intentionally, so it's a bit hard to
> justify complicating the runtime error handling for this.

And after giving this one second of actual though I figured it won't
actually complicate anything if we do it early enough. These functions
can't be safely called concurrently anyway, and so we can ignore any
races that sort of thing would bring.

> 
> The connector case might be well justified though since the index there
> comes from ida, and with MST connectors can come and go as they please.
> So it might not be entirely impossible to overflow the bits there.
> 
> > 
> > Harry
> > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_connector.c | 3 +++
> > >  drivers/gpu/drm/drm_crtc.c  | 3 +++
> > >  drivers/gpu/drm/drm_encoder.c   | 3 +++
> > >  drivers/gpu/drm/drm_plane.c | 3 +++
> > >  4 files changed, 12 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_connector.c 
> > > b/drivers/gpu/drm/drm_connector.c
> > > index b85a7749709d..9278a81c5d54 100644
> > > --- a/drivers/gpu/drm/drm_connector.c
> > > +++ b/drivers/gpu/drm/drm_connector.c
> > > @@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
> > >   connector->index = ret;
> > >   ret = 0;
> > >  
> > > + /* we have 32bit connector bitmasks */
> > > + WARN_ON(connector->index >= 32);
> > > +
> > >   connector->connector_type = connector_type;
> > >   connector->connector_type_id =
> > >   ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index f0556e654116..e27ffa3561af 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> > > struct drm_crtc *crtc,
> > >   list_add_tail(>head, >crtc_list);
> > >   crtc->index = config->num_crtc++;
> > >  
> > > + /* we have 32bit crtc bitmasks */
> > > + WARN_ON(crtc->index >= 32);
> > > +
> > >   crtc->primary = primary;
> > >   crtc->cursor = cursor;
> > >   if (primary && !primary->possible_crtcs)
> > > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > > index 59e0ebe733f8..66d0cdd217fa 100644
> > > --- a/drivers/gpu/drm/drm_encoder.c
> > > +++ b/drivers/gpu/drm/drm_encoder.c
> > > @@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
> > >   list_add_tail(>head, >mode_config.encoder_list);
> > >   encoder->index = dev->mode_config.num_encoder++;
> > >  
> > > + /* we have 32bit encoder bitmasks */
> > > + WARN_ON(encoder->index >= 32);
> > > +
> > >  out_put:
> > >   if (ret)
> > >   drm_mode_object_unregister(dev, >base);
> > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > index 2c90519576a3..0a8d807603c1 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, 
> > > struct drm_plane *plane,
> > >   list_add_tail(>head, >plane_list);
> > >   plane->index = config->num_total_plane++;
> > >  
> > > + /* we have 32bit plane bitmasks */
> > > + WARN_ON(plane->index >= 32);
> > > +
> > >   drm_object_attach_property(>base,
> > >  config->plane_type_property,
> > >  plane->type);
> > > 
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Harry Wentland]

On 2018-01-24 04:24 PM, Ville Syrjälä wrote:
> On Wed, Jan 24, 2018 at 04:01:18PM -0500, Harry Wentland wrote:
>> On 2018-01-24 01:37 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä 
>>>
>>> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
>>> Naturally we can only do that if the index of those objects stays
>>> below 32. Issue a warning whenever we exceed that limit, hopefully
>>> prompting someone to fix the problem.
>>>
>>> Or should we just outright fail the object initializatio perhaps?
>>>
>>
>> This would make sense in my opinion. index >= 32 looks like it would lead to 
>> completely undefined behavior when trying to attach objects to each other.
> 
> I suppose. The counter argument is that this is basically the developer
> shooting themselves in the foot intentionally, so it's a bit hard to
> justify complicating the runtime error handling for this.
> 

True, if this needs extensive runtime error handling a WARN_ON is probably 
better.

> The connector case might be well justified though since the index there
> comes from ida, and with MST connectors can come and go as they please.
> So it might not be entirely impossible to overflow the bits there.
> 

Right, I was trying to think of a real-life case where this might happen. MST 
is a good one (although still quite rare in the vast majority of cases).

Harry

>>
>> Harry
>>
>>> Signed-off-by: Ville Syrjälä 
>>> ---
>>>  drivers/gpu/drm/drm_connector.c | 3 +++
>>>  drivers/gpu/drm/drm_crtc.c  | 3 +++
>>>  drivers/gpu/drm/drm_encoder.c   | 3 +++
>>>  drivers/gpu/drm/drm_plane.c | 3 +++
>>>  4 files changed, 12 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c 
>>> b/drivers/gpu/drm/drm_connector.c
>>> index b85a7749709d..9278a81c5d54 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
>>> connector->index = ret;
>>> ret = 0;
>>>  
>>> +   /* we have 32bit connector bitmasks */
>>> +   WARN_ON(connector->index >= 32);
>>> +
>>> connector->connector_type = connector_type;
>>> connector->connector_type_id =
>>> ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index f0556e654116..e27ffa3561af 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
>>> struct drm_crtc *crtc,
>>> list_add_tail(>head, >crtc_list);
>>> crtc->index = config->num_crtc++;
>>>  
>>> +   /* we have 32bit crtc bitmasks */
>>> +   WARN_ON(crtc->index >= 32);
>>> +
>>> crtc->primary = primary;
>>> crtc->cursor = cursor;
>>> if (primary && !primary->possible_crtcs)
>>> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
>>> index 59e0ebe733f8..66d0cdd217fa 100644
>>> --- a/drivers/gpu/drm/drm_encoder.c
>>> +++ b/drivers/gpu/drm/drm_encoder.c
>>> @@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
>>> list_add_tail(>head, >mode_config.encoder_list);
>>> encoder->index = dev->mode_config.num_encoder++;
>>>  
>>> +   /* we have 32bit encoder bitmasks */
>>> +   WARN_ON(encoder->index >= 32);
>>> +
>>>  out_put:
>>> if (ret)
>>> drm_mode_object_unregister(dev, >base);
>>> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
>>> index 2c90519576a3..0a8d807603c1 100644
>>> --- a/drivers/gpu/drm/drm_plane.c
>>> +++ b/drivers/gpu/drm/drm_plane.c
>>> @@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, 
>>> struct drm_plane *plane,
>>> list_add_tail(>head, >plane_list);
>>> plane->index = config->num_total_plane++;
>>>  
>>> +   /* we have 32bit plane bitmasks */
>>> +   WARN_ON(plane->index >= 32);
>>> +
>>> drm_object_attach_property(>base,
>>>config->plane_type_property,
>>>plane->type);
>>>
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 04:01:18PM -0500, Harry Wentland wrote:
> On 2018-01-24 01:37 PM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> > Naturally we can only do that if the index of those objects stays
> > below 32. Issue a warning whenever we exceed that limit, hopefully
> > prompting someone to fix the problem.
> > 
> > Or should we just outright fail the object initializatio perhaps?
> > 
> 
> This would make sense in my opinion. index >= 32 looks like it would lead to 
> completely undefined behavior when trying to attach objects to each other.

I suppose. The counter argument is that this is basically the developer
shooting themselves in the foot intentionally, so it's a bit hard to
justify complicating the runtime error handling for this.

The connector case might be well justified though since the index there
comes from ida, and with MST connectors can come and go as they please.
So it might not be entirely impossible to overflow the bits there.

> 
> Harry
> 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 3 +++
> >  drivers/gpu/drm/drm_crtc.c  | 3 +++
> >  drivers/gpu/drm/drm_encoder.c   | 3 +++
> >  drivers/gpu/drm/drm_plane.c | 3 +++
> >  4 files changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index b85a7749709d..9278a81c5d54 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
> > connector->index = ret;
> > ret = 0;
> >  
> > +   /* we have 32bit connector bitmasks */
> > +   WARN_ON(connector->index >= 32);
> > +
> > connector->connector_type = connector_type;
> > connector->connector_type_id =
> > ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index f0556e654116..e27ffa3561af 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> > struct drm_crtc *crtc,
> > list_add_tail(>head, >crtc_list);
> > crtc->index = config->num_crtc++;
> >  
> > +   /* we have 32bit crtc bitmasks */
> > +   WARN_ON(crtc->index >= 32);
> > +
> > crtc->primary = primary;
> > crtc->cursor = cursor;
> > if (primary && !primary->possible_crtcs)
> > diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> > index 59e0ebe733f8..66d0cdd217fa 100644
> > --- a/drivers/gpu/drm/drm_encoder.c
> > +++ b/drivers/gpu/drm/drm_encoder.c
> > @@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
> > list_add_tail(>head, >mode_config.encoder_list);
> > encoder->index = dev->mode_config.num_encoder++;
> >  
> > +   /* we have 32bit encoder bitmasks */
> > +   WARN_ON(encoder->index >= 32);
> > +
> >  out_put:
> > if (ret)
> > drm_mode_object_unregister(dev, >base);
> > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > index 2c90519576a3..0a8d807603c1 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, 
> > struct drm_plane *plane,
> > list_add_tail(>head, >plane_list);
> > plane->index = config->num_total_plane++;
> >  
> > +   /* we have 32bit plane bitmasks */
> > +   WARN_ON(plane->index >= 32);
> > +
> > drm_object_attach_property(>base,
> >config->plane_type_property,
> >plane->type);
> > 

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

Re: [Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Harry Wentland]

On 2018-01-24 01:37 PM, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
> Naturally we can only do that if the index of those objects stays
> below 32. Issue a warning whenever we exceed that limit, hopefully
> prompting someone to fix the problem.
> 
> Or should we just outright fail the object initializatio perhaps?
> 

This would make sense in my opinion. index >= 32 looks like it would lead to 
completely undefined behavior when trying to attach objects to each other.

Harry

> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_connector.c | 3 +++
>  drivers/gpu/drm/drm_crtc.c  | 3 +++
>  drivers/gpu/drm/drm_encoder.c   | 3 +++
>  drivers/gpu/drm/drm_plane.c | 3 +++
>  4 files changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b85a7749709d..9278a81c5d54 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
>   connector->index = ret;
>   ret = 0;
>  
> + /* we have 32bit connector bitmasks */
> + WARN_ON(connector->index >= 32);
> +
>   connector->connector_type = connector_type;
>   connector->connector_type_id =
>   ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f0556e654116..e27ffa3561af 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
> struct drm_crtc *crtc,
>   list_add_tail(>head, >crtc_list);
>   crtc->index = config->num_crtc++;
>  
> + /* we have 32bit crtc bitmasks */
> + WARN_ON(crtc->index >= 32);
> +
>   crtc->primary = primary;
>   crtc->cursor = cursor;
>   if (primary && !primary->possible_crtcs)
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index 59e0ebe733f8..66d0cdd217fa 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
>   list_add_tail(>head, >mode_config.encoder_list);
>   encoder->index = dev->mode_config.num_encoder++;
>  
> + /* we have 32bit encoder bitmasks */
> + WARN_ON(encoder->index >= 32);
> +
>  out_put:
>   if (ret)
>   drm_mode_object_unregister(dev, >base);
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 2c90519576a3..0a8d807603c1 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   list_add_tail(>head, >plane_list);
>   plane->index = config->num_total_plane++;
>  
> + /* we have 32bit plane bitmasks */
> + WARN_ON(plane->index >= 32);
> +
>   drm_object_attach_property(>base,
>  config->plane_type_property,
>  plane->type);
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Inhibit context save/restore for the fake preempt context

[Chris Wilson]

Quoting Chris Wilson (2018-01-24 09:44:45)
> Quoting Michel Thierry (2018-01-24 01:24:25)
> > On 1/23/2018 1:04 PM, Chris Wilson wrote:
> > > We only use the preempt context to inject an idle point into execlists.
> > > We never need to reference its logical state, so tell the GPU never to
> > > load it or save it.
> > > 
> > > v2: BIT(2) for save-inhibit.
> > > 
> > > N.B. Daniele mentioned this bit mbz for ICL, and has been moved into the
> > > submission process rather than the context image.
> > > 
> > > Suggested-by: Daniele Ceraolo Spurio 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Michal Winiarski 
> > > Cc: Michel Thierry 
> > > Cc: Michal Wajdeczko 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Mika Kuoppala 
> > > Cc: Daniele Ceraolo Spurio 
> > > ---
> > >   drivers/gpu/drm/i915/intel_lrc.c | 4 
> > >   drivers/gpu/drm/i915/intel_lrc.h | 1 +
> > >   2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > > b/drivers/gpu/drm/i915/intel_lrc.c
> > > index 22d471a4228d..c28f267a8417 100644
> > > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > > @@ -2285,6 +2285,10 @@ populate_lr_context(struct i915_gem_context *ctx,
> > >   if (!engine->default_state)
> > >   regs[CTX_CONTEXT_CONTROL + 1] |=
> > >   
> > > _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
> > > + if (ctx->hw_id == PREEMPT_ID)
> > > + regs[CTX_CONTEXT_CONTROL + 1] |=
> > > + 
> > > _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
> > > +
> > > CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT);
> > >
> > 
> > This shouldn't break anything and ICL is not merged yet (plus things may 
> > still change) so if you want to merge this,
> 
> I think it's the right thing conceptually to do.

Uhoh, seeing GPU hangs on Broxton when thrashing preemption.
Is the bit still valid?
-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 DRM logging tidy (rev2)

[Patchwork]

== Series Details ==

Series: DRM logging tidy (rev2)
URL   : https://patchwork.freedesktop.org/series/16439/
State : warning

== Summary ==

Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-shrfb-msflip-blt:
pass   -> SKIP   (shard-apl) fdo#101623 +1
Subgroup fbc-1p-primscrn-cur-indfb-draw-blt:
pass   -> FAIL   (shard-apl) fdo#103167
Test pm_rpm:
Subgroup i2c:
pass   -> SKIP   (shard-apl)
Test kms_chv_cursor_fail:
Subgroup pipe-c-256x256-left-edge:
pass   -> SKIP   (shard-apl)
Subgroup pipe-b-256x256-bottom-edge:
pass   -> SKIP   (shard-apl)
Test kms_universal_plane:
Subgroup universal-plane-pipe-b-sanity:
pass   -> SKIP   (shard-apl)
Test kms_plane:
Subgroup plane-panning-bottom-right-suspend-pipe-c-planes:
pass   -> DMESG-WARN (shard-apl) fdo#104164
Test kms_flip:
Subgroup flip-vs-absolute-wf_vblank-interruptible:
pass   -> SKIP   (shard-apl) fdo#100368
Subgroup flip-vs-rmfb-interruptible:
pass   -> SKIP   (shard-apl)
Subgroup 2x-plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (shard-apl) fdo#103481
Test gem_eio:
Subgroup in-flight:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test kms_rotation_crc:
Subgroup sprite-rotation-90:
pass   -> FAIL   (shard-apl) fdo#103356
Test drv_suspend:
Subgroup forcewake-hibernate:
skip   -> FAIL   (shard-snb) fdo#103375

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#104164 https://bugs.freedesktop.org/show_bug.cgi?id=104164
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481
fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#103356 https://bugs.freedesktop.org/show_bug.cgi?id=103356
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:2838 pass:1741 dwarn:2   dfail:0   fail:25  skip:1070 
time:12451s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:10  skip:1091 
time:11767s
shard-snbtotal:2838 pass:1328 dwarn:2   dfail:0   fail:11  skip:1497 
time:6577s
Blacklisted hosts:
shard-kbltotal:2795 pass:1834 dwarn:15  dfail:1   fail:23  skip:921 
time:9149s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7769/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: failure for series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Chris Wilson]

Quoting Patchwork (2018-01-24 19:39:56)
> == Series Details ==
> 
> Series: series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock while 
> disabling GuC interrupts
> URL   : https://patchwork.freedesktop.org/series/37044/
> State : failure
> 
> == Summary ==
> 
> Test kms_cursor_crc:
> Subgroup cursor-256x256-suspend:
> skip   -> PASS   (shard-hsw) fdo#103375 +1
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
> pass   -> FAIL   (shard-snb) fdo#101623 +1
> Test kms_flip:
> Subgroup 2x-plain-flip-ts-check-interruptible:
> fail   -> PASS   (shard-hsw)
> Test drv_selftest:
> Subgroup live_hangcheck:
> pass   -> INCOMPLETE (shard-apl)
> Test kms_draw_crc:
> Subgroup draw-method-xrgb-mmap-wc-untiled:
> pass   -> SKIP   (shard-snb)
> Test kms_vblank:
> Subgroup crtc-id:
> pass   -> SKIP   (shard-snb)
> Test perf:
> Subgroup oa-exponents:
> fail   -> PASS   (shard-apl) fdo#102254

And pushed (except for the last patch ofc). Thanks for the patches and
review,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915/guc: Fix comments style in intel_guc_log.c

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-24 15:47:00)
> Use consistent multi-line comment style as per guideline.
> 
> v2: Reverted comments prefix update to kernel-doc comment. (Chris)
> 
> Suggested-by: Michal Wajdeczko 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Michal Wajdeczko 
> Cc: Chris Wilson 
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 v4 3/6] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-24 15:46:58)
> This patch fixes lockdep issue due to circular locking dependency of
> struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex.
> For GuC log relay channel we create debugfs file that requires i_mutex_key
> lock and we are doing that under struct_mutex. So we introduced newer
> dependency as:
> >struct_mutex --> >s_type->i_mutex_key#3 --> >mmap_sem
> However, there is dependency from mmap_sem to struct_mutex. Hence we
> separate the relay create/destroy operation from under struct_mutex.
> Also added runtime check of relay buffer status.
> 
> ==
> WARNING: possible circular locking dependency detected
> 4.15.0-rc6-CI-Patchwork_7614+ #1 Not tainted
> --
> debugfs_test/1388 is trying to acquire lock:
>  (>struct_mutex){+.+.}, at: [] 
> i915_mutex_lock_interruptible+0x47/0x130 [i915]
> 
> but task is already holding lock:
>  (>mmap_sem){}, at: [<29a9c131>] __do_page_fault+0x106/0x560
> 
> which lock already depends on the new lock.
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #3 (>mmap_sem){}:
>_copy_to_user+0x1e/0x70
>filldir+0x8c/0xf0
>dcache_readdir+0xeb/0x160
>iterate_dir+0xdc/0x140
>SyS_getdents+0xa0/0x130
>entry_SYSCALL_64_fastpath+0x1c/0x89
> 
> -> #2 (>s_type->i_mutex_key#3){}:
>start_creating+0x59/0x110
>__debugfs_create_file+0x2e/0xe0
>relay_create_buf_file+0x62/0x80
>relay_late_setup_files+0x84/0x250
>guc_log_late_setup+0x4f/0x110 [i915]
>i915_guc_log_register+0x32/0x40 [i915]
>i915_driver_load+0x7b6/0x1720 [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
> 
> -> #1 (relay_channels_mutex){+.+.}:
>relay_open+0x12c/0x2b0
>intel_guc_log_runtime_create+0xab/0x230 [i915]
>intel_guc_init+0x81/0x120 [i915]
>intel_uc_init+0x29/0xa0 [i915]
>i915_gem_init+0x182/0x530 [i915]
>i915_driver_load+0xaa9/0x1720 [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){+.+.}:
>__mutex_lock+0x81/0x9b0
>i915_mutex_lock_interruptible+0x47/0x130 [i915]
>i915_gem_fault+0x201/0x790 [i915]
>__do_fault+0x15/0x70
>__handle_mm_fault+0x677/0xdc0
>handle_mm_fault+0x14f/0x2f0
>__do_page_fault+0x2d1/0x560
>page_fault+0x4c/0x60
> 
> other info that might help us debug this:
> 
> Chain exists of:
>   >struct_mutex --> >s_type->i_mutex_key#3 --> >mmap_sem
> 
>  Possible unsafe locking scenario:
> 
>CPU0CPU1
>
>   lock(>mmap_sem);
>lock(>s_type->i_mutex_key#3);
>lock(>mmap_sem);
>   lock(>struct_mutex);
> 
>  *** DEADLOCK ***
> 
> 1 lock held by debugfs_test/1388:
>  #0:  (>mmap_sem){}, at: [<29a9c131>] 
> __do_page_fault+0x106/0x560
> 
> stack backtrace:
> CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ 
> #1
> Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS 
> P1.10 09/29/2016
> Call Trace:
>  dump_stack+0x5f/0x86
>  print_circular_bug.isra.18+0x1d0/0x2c0
>  __lock_acquire+0x14ae/0x1b60
>  ? lock_acquire+0xaf/0x200
>  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/0x790 [i915]
>  __do_fault+0x15/0x70
>  ? _raw_spin_unlock+0x29/0x40
>  __handle_mm_fault+0x677/0xdc0
>  handle_mm_fault+0x14f/0x2f0
>  __do_page_fault+0x2d1/0x560
>  ? page_fault+0x36/0x60
>  page_fault+0x4c/0x60
> 
> v2: Added lock protection to guc->log.runtime.relay_chan (Chris)
> Fixed locking inside guc_flush_logs uncovered by new lockdep.
> 
> v3: Locking guc_read_update_log_buffer entirely with 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock while 
disabling GuC interrupts
URL   : https://patchwork.freedesktop.org/series/37044/
State : failure

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
skip   -> PASS   (shard-hsw) fdo#103375 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test kms_flip:
Subgroup 2x-plain-flip-ts-check-interruptible:
fail   -> PASS   (shard-hsw)
Test drv_selftest:
Subgroup live_hangcheck:
pass   -> INCOMPLETE (shard-apl)
Test kms_draw_crc:
Subgroup draw-method-xrgb-mmap-wc-untiled:
pass   -> SKIP   (shard-snb)
Test kms_vblank:
Subgroup crtc-id:
pass   -> SKIP   (shard-snb)
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254

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

shard-apltotal:2820 pass:1734 dwarn:1   dfail:0   fail:22  skip:1062 
time:12164s
shard-hswtotal:2838 pass:1735 dwarn:1   dfail:0   fail:11  skip:1090 
time:11886s
shard-snbtotal:2838 pass:1326 dwarn:1   dfail:0   fail:11  skip:1500 
time:6632s
Blacklisted hosts:
shard-kbltotal:2838 pass:1871 dwarn:5   dfail:1   fail:23  skip:938 
time:9485s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

[Patchwork]

== Series Details ==

Series: drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
URL   : https://patchwork.freedesktop.org/series/37060/
State : success

== Summary ==

Series 37060v1 drm/i915/cnp: Properly handle VBT ddc pin out of bounds.
https://patchwork.freedesktop.org/api/1.0/series/37060/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:490s
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:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:516s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:496s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

d33d70e5449f1477b09de4963fc7397890da1263 drm-tip: 2018y-01m-24d-18h-16m-27s UTC 
integration manifest
3dbf54c61ae6 drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7773/issues.html
___
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: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Patchwork]

== Series Details ==

Series: drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit 
bitmasks
URL   : https://patchwork.freedesktop.org/series/37058/
State : warning

== Summary ==

Series 37058v1 drm: Warn if plane/crtc/encoder/connector index exceeds our 
32bit bitmasks
https://patchwork.freedesktop.org/api/1.0/series/37058/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-bdw-5557u) fdo#104162

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:428s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
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:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:281s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:513s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:396s
fi-hsw-4770r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:401s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:461s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:501s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:506s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:429s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:489s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:396s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-glk-dsi   total:288  pass:183  dwarn:1   dfail:4   fail:0   skip:100 
time:361s

d33d70e5449f1477b09de4963fc7397890da1263 drm-tip: 2018y-01m-24d-18h-16m-27s UTC 
integration manifest
2180375a38f7 drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit 
bitmasks

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7772/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: Use enum plane_id for frontbuffer tracking

[Pandiyan, Dhinakaran]

On Wed, 2018-01-24 at 17:16 +0200, Ville Syrjälä wrote:
> On Wed, Jan 24, 2018 at 04:16:19AM +, Pandiyan, Dhinakaran wrote:
> > On Tue, 2018-01-23 at 20:33 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Replace the ad-hoc plane indexing scheme used by the frontbuffer
> > > tracking with enum plane_id.
> > > 
> > > The old video overlay not being part of the plane_id namespace
> > > will just be given the high bit.
> > 
> > I'm curious why the bit corresponding to PLANE_SPRITE0 is not re-used
> > for the overlay. From a cursory read seems like platforms with overlays
> > and sprites are mutually exclusive.
> 
> Currently yes, but maybe not in the future. I still have dreams of
> exposing all the planes on these platforms, which would mean having
> at least one sprite plane that's not the video overlay. I haven't
> really figured out how to make it all work out nicely with enum
> plane_id though as that's a per-pipe thing and the planes on the
> old hw are not necessarily tied to a single pipe. Perhaps one
> option would be to assign the plane ids globally, ie. PRIMARY==A,
> PLANE1==B, PLANE2==C, etc. Not sure if that would actually work out
> though.
> 
> > 
> > Related question, how different is this overlay from the sprite planes?
> 
> Very different. I would like to expose it as a drm_plane eventually,
> but there's a bit of actual work involved to convert the overlay
> register updates to use mmio, and to handle the render cache
> reconfiguration (which still involves stuffing MI commands to the
> ring) in a decent way.
> 
> I do have a basic mmio conversion sitting on some branch somewhere,

I'm interested in seeing how this is done, is this in your public repo?
And thanks for the explanation.

-DK

> but I don't think I got it to look as nice as I'd like. Plus it's
> probably bitrotted enough by now that it needs some rework anyway.
> 
> > 
> > 
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  | 11 +++
> > >  drivers/gpu/drm/i915/intel_display.c |  4 ++--
> > >  drivers/gpu/drm/i915/intel_fbc.c |  2 +-
> > >  drivers/gpu/drm/i915/intel_sprite.c  |  4 +++-
> > >  4 files changed, 9 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 8333692dac5a..bd545b1c9546 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2404,16 +2404,11 @@ enum hdmi_force_audio {
> > >   *
> > >   * We have one bit per pipe and per scanout plane type.
> > >   */
> > > -#define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
> > >  #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
> > > -#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
> > > - (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > > -#define INTEL_FRONTBUFFER_CURSOR(pipe) \
> > > - (1 << (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > > -#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
> > > - (1 << (2 + plane + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > > +#define INTEL_FRONTBUFFER(pipe, plane_id) \
> > > + (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > >  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
> > > - (1 << (2 + INTEL_MAX_SPRITE_BITS_PER_PIPE + 
> > > (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > > + (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
> > > INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > >  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
> > >   (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > >  
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index d585ce4c8732..3cc35add362f 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -13168,7 +13168,7 @@ intel_primary_plane_create(struct 
> > > drm_i915_private *dev_priv, enum pipe pipe)
> > >   else
> > >   primary->i9xx_plane = (enum i9xx_plane_id) pipe;
> > >   primary->id = PLANE_PRIMARY;
> > > - primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
> > > + primary->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, primary->id);
> > >   primary->check_plane = intel_check_primary_plane;
> > >  
> > >   if (INTEL_GEN(dev_priv) >= 9) {
> > > @@ -13289,7 +13289,7 @@ intel_cursor_plane_create(struct drm_i915_private 
> > > *dev_priv,
> > >   cursor->pipe = pipe;
> > >   cursor->i9xx_plane = (enum i9xx_plane_id) pipe;
> > >   cursor->id = PLANE_CURSOR;
> > > - cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
> > > + cursor->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, cursor->id);
> > >  
> > >   if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
> > >   cursor->update_plane = i845_update_cursor;
> > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > index 9dc2b8b5f2db..a8a8a80497a8 100644
> > > --- a/drivers/gpu/drm/i915/intel_fbc.c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assert that we don't overflow frontbuffer tracking bits

[Patchwork]

== Series Details ==

Series: drm/i915: Assert that we don't overflow frontbuffer tracking bits
URL   : https://patchwork.freedesktop.org/series/37057/
State : success

== Summary ==

Series 37057v1 drm/i915: Assert that we don't overflow frontbuffer tracking bits
https://patchwork.freedesktop.org/api/1.0/series/37057/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:426s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:474s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:510s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:495s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:507s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:529s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:475s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:416s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
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:395s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s

d33d70e5449f1477b09de4963fc7397890da1263 drm-tip: 2018y-01m-24d-18h-16m-27s UTC 
integration manifest
19b64b896bf6 drm/i915: Assert that we don't overflow frontbuffer tracking bits

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/cnp: Properly handle VBT ddc pin out of bounds.

[Rodrigo Vivi]

If the table result is out of bounds on the array map
there is something really wrong with VBT pin so we don't
return that vbt_pin, but only return 0 instead.

This basically reverts commit 'a8e6f3888b05 ("drm/i915/cnp:
Ignore VBT request for know invalid DDC pin.")'

Also this properly fixes commit 9c3b2689d01f ("drm/i915/cnl:
Map VBT DDC Pin to BSpec DDC Pin.")

Fixes: a8e6f3888b05 ("drm/i915/cnp: Ignore VBT request for know invalid DDC 
pin.")
Fixes: 9c3b2689d01f ("drm/i915/cnl: Map VBT DDC Pin to BSpec DDC Pin.")
Cc: Radhakrishna Sripada 
Cc: Jani Nikula 
Cc: Kai Heng Feng 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_bios.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 95f0b310d656..844c1e8f574f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1115,16 +1115,11 @@ static const u8 cnp_ddc_pin_map[] = {
 
 static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
 {
-   if (HAS_PCH_CNP(dev_priv)) {
-   if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
-   return cnp_ddc_pin_map[vbt_pin];
-   if (vbt_pin > GMBUS_PIN_4_CNP) {
-   DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC 
pin %d, which is not valid for this platform\n", vbt_pin);
-   return 0;
-   }
-   }
+   if (HAS_PCH_CNP(dev_priv) &&
+   vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
+   return cnp_ddc_pin_map[vbt_pin];
 
-   return vbt_pin;
+   return 0;
 }
 
 static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
-- 
2.13.6

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

[Intel-gfx] [PULL] drm-misc-fixes for 4.15

[Sean Paul]

Hi Dave,
I'm sending this since danvet is down under this week. We've collected a couple
fixes in drm-misc-fixes this week, and since we're still in the business of
4.15, I figured I'd send them along.

drm-misc-fixes-2018-01-24:
Two vc4 fixes that were applied in the last day.
One fixes a NULL dereference, and the other fixes
a flickering bug.

Cc: Eric Anholt 
Cc: Boris Brezillon 

Cheers, Sean


The following changes since commit 75f195f46f27a2524b249b95e6f241cd13c7e549:

  Merge tag 'drm-misc-fixes-2018-01-17' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-01-18 13:30:22 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-24

for you to fetch changes up to 17b11b76b87afe9f8be199d7a5f442497133e2b0:

  drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() (2018-01-18 
12:17:03 -0800)


Two vc4 fixes that were applied in the last day.
One fixes a NULL dereference, and the other fixes
a flickering bug.

Cc: Eric Anholt 
Cc: Boris Brezillon 


Boris Brezillon (1):
  drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

Eric Anholt (1):
  drm/vc4: Flush the caches before the bin jobs, as well.

 drivers/gpu/drm/vc4/vc4_gem.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Assert that we don't overflow frontbuffer tracking bits

[Chris Wilson]

Quoting Ville Syrjala (2018-01-24 18:36:42)
> From: Ville Syrjälä 
> 
> Add some compile time assrts to the frontbuffer tracking to make sure
> that we have enough bits per pipe to cover all the planes, and that we
> have enough total bits to cover all the planes across all pipes.
> 
> We'll ignore any potential clash between the overlay bit and the
> plane bits because that will allow us to keep using a total of 32
> bits for the foreseeable future.
> 
> While at it change the macros to use BIT() and GENMASK(). The latter
> gets rid of the hardcoded 0xff and thus means we can change the
> number of bits per pipe by just changing
> INTEL_FRONTBUFFER_BITS_PER_PIPE.
> 
> Cc: Chris Wilson 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 454d8f937fae..98f346c7b0b3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2411,12 +2411,16 @@ enum hdmi_force_audio {
>   * We have one bit per pipe and per scanout plane type.
>   */
>  #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
> -#define INTEL_FRONTBUFFER(pipe, plane_id) \
> -   (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> +#define INTEL_FRONTBUFFER(pipe, plane_id) ({ \
> +   BUILD_BUG_ON(INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES > 32); \
> +   BUILD_BUG_ON(I915_MAX_PLANES > INTEL_FRONTBUFFER_BITS_PER_PIPE); \
> +   BIT((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)); \
> +})

Next endeavour will be to convert to unsigned long just so we can use
BITS_PER_LONG here ; (These masks are now defined as ul, seems a natural
progression to use unsigned long throughout. Alternatively typedef
intel_frontbuffer_mask_t and 8*sizeof().)

>  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
> -   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
> INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> +   BIT(INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
> INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))
>  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
> -   (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> +   GENMASK(INTEL_FRONTBUFFER_BITS_PER_PIPE * ((pipe) + 1) - 1, \
> +   INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))

Inclusive ends, check.

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

[Intel-gfx] [PATCH] drm: Warn if plane/crtc/encoder/connector index exceeds our 32bit bitmasks

[Ville Syrjala]

From: Ville Syrjälä 

We use 32bit bitmasks to track planes/crtcs/encoders/connectors.
Naturally we can only do that if the index of those objects stays
below 32. Issue a warning whenever we exceed that limit, hopefully
prompting someone to fix the problem.

Or should we just outright fail the object initializatio perhaps?

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c | 3 +++
 drivers/gpu/drm/drm_crtc.c  | 3 +++
 drivers/gpu/drm/drm_encoder.c   | 3 +++
 drivers/gpu/drm/drm_plane.c | 3 +++
 4 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b85a7749709d..9278a81c5d54 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -211,6 +211,9 @@ int drm_connector_init(struct drm_device *dev,
connector->index = ret;
ret = 0;
 
+   /* we have 32bit connector bitmasks */
+   WARN_ON(connector->index >= 32);
+
connector->connector_type = connector_type;
connector->connector_type_id =
ida_simple_get(connector_ida, 1, 0, GFP_KERNEL);
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f0556e654116..e27ffa3561af 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -318,6 +318,9 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
list_add_tail(>head, >crtc_list);
crtc->index = config->num_crtc++;
 
+   /* we have 32bit crtc bitmasks */
+   WARN_ON(crtc->index >= 32);
+
crtc->primary = primary;
crtc->cursor = cursor;
if (primary && !primary->possible_crtcs)
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index 59e0ebe733f8..66d0cdd217fa 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -136,6 +136,9 @@ int drm_encoder_init(struct drm_device *dev,
list_add_tail(>head, >mode_config.encoder_list);
encoder->index = dev->mode_config.num_encoder++;
 
+   /* we have 32bit encoder bitmasks */
+   WARN_ON(encoder->index >= 32);
+
 out_put:
if (ret)
drm_mode_object_unregister(dev, >base);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 2c90519576a3..0a8d807603c1 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -242,6 +242,9 @@ int drm_universal_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
list_add_tail(>head, >plane_list);
plane->index = config->num_total_plane++;
 
+   /* we have 32bit plane bitmasks */
+   WARN_ON(plane->index >= 32);
+
drm_object_attach_property(>base,
   config->plane_type_property,
   plane->type);
-- 
2.13.6

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

[Intel-gfx] [PATCH] drm/i915: Assert that we don't overflow frontbuffer tracking bits

[Ville Syrjala]

From: Ville Syrjälä 

Add some compile time assrts to the frontbuffer tracking to make sure
that we have enough bits per pipe to cover all the planes, and that we
have enough total bits to cover all the planes across all pipes.

We'll ignore any potential clash between the overlay bit and the
plane bits because that will allow us to keep using a total of 32
bits for the foreseeable future.

While at it change the macros to use BIT() and GENMASK(). The latter
gets rid of the hardcoded 0xff and thus means we can change the
number of bits per pipe by just changing
INTEL_FRONTBUFFER_BITS_PER_PIPE.

Cc: Chris Wilson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 454d8f937fae..98f346c7b0b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2411,12 +2411,16 @@ enum hdmi_force_audio {
  * We have one bit per pipe and per scanout plane type.
  */
 #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
-#define INTEL_FRONTBUFFER(pipe, plane_id) \
-   (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+#define INTEL_FRONTBUFFER(pipe, plane_id) ({ \
+   BUILD_BUG_ON(INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES > 32); \
+   BUILD_BUG_ON(I915_MAX_PLANES > INTEL_FRONTBUFFER_BITS_PER_PIPE); \
+   BIT((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)); \
+})
 #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
-   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+   BIT(INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))
 #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
-   (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+   GENMASK(INTEL_FRONTBUFFER_BITS_PER_PIPE * ((pipe) + 1) - 1, \
+   INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))
 
 /*
  * Optimised SGL iterator for GEM objects
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Ignore VBT request for know invalid DDC pin.

[Rodrigo Vivi]

On Wed, Jan 24, 2018 at 09:25:06AM +, Jani Nikula wrote:
> On Tue, 23 Jan 2018, Rodrigo Vivi  wrote:
> > On Tue, Jan 23, 2018 at 05:40:50PM +, Rodrigo Vivi wrote:
> >> Let's ignore VBT request if the pin is clearly wrong.
> >> 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104139
> >> Cc: Kai Heng Feng 
> >> Signed-off-by: Rodrigo Vivi 
> >
> > Reviewed-by: Radhakrishna Sripada 
> > (f2f)
> > thanks
> >
> > merged to dinq.
> 
> A bit too fast IMO. The bug report doesn't include the vbt dump which
> you should *always* look at before making workarounds for vbt.

my apologies. My biggest mistake was taking so long to reply to the
bug and taking so long to post the patch here. :(

I looked to the VBT now and it is really just this ddc pin for this
particular port wrong. Or should I look to something else?

What other kind of useful information would that bring to us
normally?

> 
> Also, see below.
> 
> >> ---
> >>  drivers/gpu/drm/i915/intel_bios.c | 11 ---
> >>  1 file changed, 8 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> >> b/drivers/gpu/drm/i915/intel_bios.c
> >> index b0668202dc7e..95f0b310d656 100644
> >> --- a/drivers/gpu/drm/i915/intel_bios.c
> >> +++ b/drivers/gpu/drm/i915/intel_bios.c
> >> @@ -1115,9 +1115,14 @@ static const u8 cnp_ddc_pin_map[] = {
> >>  
> >>  static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
> >>  {
> >> -  if (HAS_PCH_CNP(dev_priv) &&
> >> -  vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> >> -  return cnp_ddc_pin_map[vbt_pin];
> >> +  if (HAS_PCH_CNP(dev_priv)) {
> >> +  if (vbt_pin > 0 && vbt_pin < ARRAY_SIZE(cnp_ddc_pin_map))
> >> +  return cnp_ddc_pin_map[vbt_pin];
> >> +  if (vbt_pin > GMBUS_PIN_4_CNP) {
> >> +  DRM_DEBUG_KMS("Ignoring alternate pin: VBT claims DDC 
> >> pin %d, which is not valid for this platform\n", vbt_pin);
> >> +  return 0;
> >> +  }
> 
> The original code was wrong in the sense that it would only do the
> mapping if the provided vbt_pin was within bounds for CNP, and would
> return the unmapped vbt_pin otherwise. Instead, I think you should
> directly return 0 for out of bounds vbt_pin.
> 
> This change here is effectively the same, but more confusing. As if
> there's a case where the vbt_pin can be both out of bounds, within CNP
> pin limits, and should be returned unmapped. That can't happen, so
> please make the code reflect that.

Yes. That's a great idea. Thanks for the suggestion.

Honestly, at first I assumed our behavior was something
like this so I couldn't believe we had the issue even with
the original mapping there. But when I did the last fix
I avoided changing the original behavior and messed things up. Sorry.

Thanks,
Rodrigo.

> 
> BR,
> Jani.
> 
> 
> >> +  }
> >>  
> >>return vbt_pin;
> >>  }
> >> -- 
> >> 2.13.6
> >> 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use enum plane_id for frontbuffer tracking

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 07:36:01PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 23, 2018 at 09:11:23PM +, Chris Wilson wrote:
> > Quoting Ville Syrjala (2018-01-23 18:33:43)
> > > From: Ville Syrjälä 
> > > 
> > > Replace the ad-hoc plane indexing scheme used by the frontbuffer
> > > tracking with enum plane_id.
> > > 
> > > The old video overlay not being part of the plane_id namespace
> > > will just be given the high bit.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  | 11 +++
> > >  drivers/gpu/drm/i915/intel_display.c |  4 ++--
> > >  drivers/gpu/drm/i915/intel_fbc.c |  2 +-
> > >  drivers/gpu/drm/i915/intel_sprite.c  |  4 +++-
> > >  4 files changed, 9 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 8333692dac5a..bd545b1c9546 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -2404,16 +2404,11 @@ enum hdmi_force_audio {
> > >   *
> > >   * We have one bit per pipe and per scanout plane type.
> > >   */
> > > -#define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
> > >  #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
> > 
> > I would feel safer with a BUILD_BUG_ON to catch plane_id overflowing
> > INTEL_FRONTBUFFER_BITS_PER_PIPE (-1 for the overlay reservation).
> 
> Actaully we'll be going past that BITS_PER_PIPE-1 limit real soon
> now, but the BITS_PER_PIPE will be sufficient for some time I think.
> So I think I'd just rather ignore the overlap between the plane_id
> and the overlay because that's not going happen on actual hardware.
> 
> But I think asserting that BITS_PER_PIPE is sufficient is a good idea.
> Just need to figure out where to put it. There's no init function
> or anything like that in the frontbuffer tracking code, so that's
> not going to work. I guess one option would be to include the
> assert in the INTEL_FRONTBUFFER() macro itself.

Pushed this as is to dinq. Thanks for the review.

I'll send that BUILD_BUG_ON() as a followup.

> 
> > 
> > > -#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
> > > -   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > > -#define INTEL_FRONTBUFFER_CURSOR(pipe) \
> > > -   (1 << (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > > -#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
> > > -   (1 << (2 + plane + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > > +#define INTEL_FRONTBUFFER(pipe, plane_id) \
> > > +   (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > >  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
> > > -   (1 << (2 + INTEL_MAX_SPRITE_BITS_PER_PIPE + 
> > > (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > > +   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
> > > INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > >  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
> > > (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > 
> > The conversion looks straightforward nevertheless, and indeed no reason
> > to have move than one indexing id for a plane.
> > Reviewed-by: Chris Wilson 
> > -Chris
> 
> -- 
> Ville Syrjälä
> Intel OTC

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Implement display w/a #1143

[Ville Syrjälä]

On Mon, Jan 22, 2018 at 09:48:46AM -0800, Rodrigo Vivi wrote:
> On Mon, Jan 22, 2018 at 05:41:31PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Apparently SKL/KBL/CFL need some manual help to get the
> > programmed HDMI vswing to stick. Implement the relevant
> > workaround (display w/a #1143).
> > 
> > Note that the relevant chicken bits live in a transcoder register
> > even though the bits affect a specific DDI port rather than a
> > specific transcoder. Hence we must pick the correct transcoder
> > register instance based on the port rather than based on the
> > cpu_transcoder.
> > 
> > Also note that for completeness I included support for DDI A/E
> > in the code even though we never have HDMI on those ports.
> > 
> > v2: CFL needs the w/a as well (Rodrigo and Art)
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Art Runyan 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Rodrigo Vivi 

Pushed to dinq. Thanks for the review.

> 
> 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  8 ++--
> >  drivers/gpu/drm/i915/intel_ddi.c | 42 
> > 
> >  2 files changed, 48 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 10e1269ad6af..2e6d0dc01dc7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7012,8 +7012,12 @@ enum {
> >  #define CHICKEN_TRANS_A 0x420c0
> >  #define CHICKEN_TRANS_B 0x420c4
> >  #define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> > CHICKEN_TRANS_B)
> > -#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
> > -#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> > +#define  DDI_TRAINING_OVERRIDE_ENABLE  (1<<19)
> > +#define  DDI_TRAINING_OVERRIDE_VALUE   (1<<18)
> > +#define  DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /* CHICKEN_TRANS_A only 
> > */
> > +#define  DDIE_TRAINING_OVERRIDE_VALUE  (1<<16) /* CHICKEN_TRANS_A only 
> > */
> > +#define  PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> > +#define  PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
> >  
> >  #define DISP_ARB_CTL   _MMIO(0x45000)
> >  #define  DISP_FBC_MEMORY_WAKE  (1<<31)
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 6260a882fbe4..e51559be2e3b 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2433,6 +2433,48 @@ static void intel_enable_ddi_hdmi(struct 
> > intel_encoder *encoder,
> >   
> > crtc_state->hdmi_high_tmds_clock_ratio,
> >   crtc_state->hdmi_scrambling);
> >  
> > +   /* Display WA #1143: skl,kbl,cfl */
> > +   if (IS_GEN9_BC(dev_priv)) {
> > +   /*
> > +* For some reason these chicken bits have been
> > +* stuffed into a transcoder register, event though
> > +* the bits affect a specific DDI port rather than
> > +* a specific transcoder.
> > +*/
> > +   static const enum transcoder port_to_transcoder[] = {
> > +   [PORT_A] = TRANSCODER_EDP,
> > +   [PORT_B] = TRANSCODER_A,
> > +   [PORT_C] = TRANSCODER_B,
> > +   [PORT_D] = TRANSCODER_C,
> > +   [PORT_E] = TRANSCODER_A,
> > +   };
> > +   enum transcoder transcoder = port_to_transcoder[port];
> > +   u32 val;
> > +
> > +   val = I915_READ(CHICKEN_TRANS(transcoder));
> > +
> > +   if (port == PORT_E)
> > +   val |= DDIE_TRAINING_OVERRIDE_ENABLE |
> > +   DDIE_TRAINING_OVERRIDE_VALUE;
> > +   else
> > +   val |= DDI_TRAINING_OVERRIDE_ENABLE |
> > +   DDI_TRAINING_OVERRIDE_VALUE;
> > +
> > +   I915_WRITE(CHICKEN_TRANS(transcoder), val);
> > +   POSTING_READ(CHICKEN_TRANS(transcoder));
> > +
> > +   udelay(1);
> > +
> > +   if (port == PORT_E)
> > +   val &= ~(DDIE_TRAINING_OVERRIDE_ENABLE |
> > +DDIE_TRAINING_OVERRIDE_VALUE);
> > +   else
> > +   val &= ~(DDI_TRAINING_OVERRIDE_ENABLE |
> > +DDI_TRAINING_OVERRIDE_VALUE);
> > +
> > +   I915_WRITE(CHICKEN_TRANS(transcoder), val);
> > +   }
> > +
> > /* In HDMI/DVI mode, the port width, and swing/emphasis values
> >  * are ignored so nothing special needs to be done besides
> >  * enabling the port.
> > -- 
> > 2.13.6
> > 

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

Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add a comment exlaining CCS hsub/vsub

[Ville Syrjälä]

On Sat, Jan 20, 2018 at 09:39:13AM -0800, Jason Ekstrand wrote:
> Reviewed-by: Jason Ekstrand 

Thanks for the comment and review ;) Patches 1-6 have now been pushed to
dinq.

> 
> On Fri, Jan 19, 2018 at 6:41 AM, Ville Syrjala <
> ville.syrj...@linux.intel.com> wrote:
> 
> > From: Ville Syrjälä 
> >
> > Let's document why we claim hsub==8,vsub==16 for CCS.
> >
> > v2: Replace my explanation with Jason's
> >
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Cc: Jason Ekstrand 
> > Cc: Daniel Stone 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 91f3c0a64596..8d0d5d8753c0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2387,6 +2387,20 @@ static unsigned int 
> > intel_fb_modifier_to_tiling(uint64_t
> > fb_modifier)
> > }
> >  }
> >
> > +/*
> > + * From the Sky Lake PRM:
> > + * "The Color Control Surface (CCS) contains the compression status of
> > + *  the cache-line pairs. The compression state of the cache-line pair
> > + *  is specified by 2 bits in the CCS. Each CCS cache-line represents
> > + *  an area on the main surface of 16 x16 sets of 128 byte Y-tiled
> > + *  cache-line-pairs. CCS is always Y tiled."
> > + *
> > + * Since cache line pairs refers to horizontally adjacent cache lines,
> > + * each cache line in the CCS corresponds to an area of 32x16 cache
> > + * lines on the main surface. Since each pixel is 4 bytes, this gives
> > + * us a ratio of one byte in the CCS for each 8x16 pixels in the
> > + * main surface.
> > + */
> >  static const struct drm_format_info ccs_formats[] = {
> > { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2,
> > .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
> > { .format = DRM_FORMAT_XBGR, .depth = 24, .num_planes = 2,
> > .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, },
> > --
> > 2.13.6
> >
> >

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

Re: [Intel-gfx] [RFC v2 0/6] Queued/runnable/running engine stats

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-24 18:01:14)
> 
> On 22/01/2018 18:52, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-01-22 18:43:52)
> >> From: Tvrtko Ursulin 
> >>
> >> Per-engine queue depths are an interesting metric for analyzing the system 
> >> load
> >> and also for users who wish to use it to load balance their submissions 
> >> based
> >> on it.
> >>
> >> In this version I have split the metrics into three separate counters:
> >>
> >> 1. QUEUED - From execbuf time to request being runnable - runnable meaning 
> >> until
> >>  dependencies have been resolved and fences signaled.
> >> 2. RUNNABLE - From runnable to running on the GPU.
> >> 3. RUNNING - Running on the GPU.
> >>
> >> When inspected with perf stat the output looks roughly like this:
> >>
> >> #   time counts unit events
> >> 201.160490145   0.01  i915/rcs0-queued/
> >> 201.160490145  19.13  i915/rcs0-runnable/
> >> 201.160490145   2.39  i915/rcs0-running/
> >>
> >> The reported numbers are average queue depths for the last query period.
> >>
> >> Having split out metrics should be more flexible for all users, and it is 
> >> still
> >> possible to fetch an atomic snapshot of all using the perf groups for those
> >> wanting to combine them.
> >>
> >> For users wanting instantanous numbers instead of averaged, we could 
> >> potentially
> >> expose them using the query API Lionel is working on.
> >> (https://patchwork.freedesktop.org/series/36622/)
> >>
> >> For instance a query packet could look like:
> >>
> >> #define DRM_I915_QUERY_ENGINE_QUEUES0x04
> >>
> >> struct drm_i915_query_engine_queues {
> >>  __u8 class;
> >>  __u8 instance
> >>
> >>  __u8 pad[2];
> >>
> >>  __u32 queued;
> >>  __u32 runnable;
> >>  __u32 running;
> >> };
> >>
> >> I also have patches to expose this via intel-gpu-top, using the perf API.
> > 
> > Can you stick a ewma loadavg just after the hostname in intel-gpu-overlay,
> > pretty please? :)
> 
> Sure, just one period and all three counters aggregated?

Hmm, just runnable + running I think matches loadavg best. (For the cpu
that is the number of tasks in the runqueue.) I think having the 1s,
30s, 15m figures would be useful but they can be computed in userspace
from the single (combined) sampler.

But the problem with just runnable + running is that we don't see those
inter-engine dependencies so clearly (but it does hide inter-device waits
etc), so I don't know.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 4/6] drm/i915/pmu: Add queued counter

[Tvrtko Ursulin]

On 22/01/2018 18:56, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-22 18:43:56)

From: Tvrtko Ursulin 

We add a PMU counter to expose the number of requests which have been
submitted from userspace but are not yet runnable due dependencies and
unsignaled fences.

This is useful to analyze the overall load of the system.

v2:
  * Rebase for name change and re-order.
  * Drop floating point constant. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_pmu.c | 40 +
  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
  include/uapi/drm/i915_drm.h |  9 +++-
  3 files changed, 45 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index cbfca4a255ab..8eefdf09a30a 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -36,7 +36,8 @@
  #define ENGINE_SAMPLE_MASK \
 (BIT(I915_SAMPLE_BUSY) | \
  BIT(I915_SAMPLE_WAIT) | \
-BIT(I915_SAMPLE_SEMA))
+BIT(I915_SAMPLE_SEMA) | \
+BIT(I915_SAMPLE_QUEUED))
  
  #define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
  
@@ -220,6 +221,11 @@ static void engines_sample(struct drm_i915_private *dev_priv)
  
 update_sample(>pmu.sample[I915_SAMPLE_SEMA],

   PERIOD, !!(val & RING_WAIT_SEMAPHORE));
+
+   if (engine->pmu.enable & BIT(I915_SAMPLE_QUEUED))
+   update_sample(>pmu.sample[I915_SAMPLE_QUEUED],
+ I915_SAMPLE_QUEUED_DIVISOR,
+ 
atomic_read(>request_stats.queued));


engine->request_stats.foo works for me, and reads quite nicely.


+/* No brackets or quotes below please. */
+#define I915_SAMPLE_QUEUED_SCALE 0.01



+ /* Divide counter value by divisor to get the real value. */
+#define I915_SAMPLE_QUEUED_DIVISOR (100)


I'm just thinking of favouring the sampler arithmetic by using 128. As
far as userspace the difference is not going to that noticeable, less if
you chose 256.


I'll do 1024 then, but the CPU usage in the sampling thread is so low 
anyway.


Regards,

Tvrtko

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

Re: [Intel-gfx] [RFC v2 0/6] Queued/runnable/running engine stats

[Tvrtko Ursulin]

On 22/01/2018 18:52, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-22 18:43:52)

From: Tvrtko Ursulin 

Per-engine queue depths are an interesting metric for analyzing the system load
and also for users who wish to use it to load balance their submissions based
on it.

In this version I have split the metrics into three separate counters:

1. QUEUED - From execbuf time to request being runnable - runnable meaning until
 dependencies have been resolved and fences signaled.
2. RUNNABLE - From runnable to running on the GPU.
3. RUNNING - Running on the GPU.

When inspected with perf stat the output looks roughly like this:

#   time counts unit events
201.160490145   0.01  i915/rcs0-queued/
201.160490145  19.13  i915/rcs0-runnable/
201.160490145   2.39  i915/rcs0-running/

The reported numbers are average queue depths for the last query period.

Having split out metrics should be more flexible for all users, and it is still
possible to fetch an atomic snapshot of all using the perf groups for those
wanting to combine them.

For users wanting instantanous numbers instead of averaged, we could potentially
expose them using the query API Lionel is working on.
(https://patchwork.freedesktop.org/series/36622/)

For instance a query packet could look like:

#define DRM_I915_QUERY_ENGINE_QUEUES0x04

struct drm_i915_query_engine_queues {
 __u8 class;
 __u8 instance

 __u8 pad[2];

 __u32 queued;
 __u32 runnable;
 __u32 running;
};

I also have patches to expose this via intel-gpu-top, using the perf API.


Can you stick a ewma loadavg just after the hostname in intel-gpu-overlay,
pretty please? :)


Sure, just one period and all three counters aggregated?

Regards,

Tvrtko

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Enhanced execution list support

[Patchwork]

== Series Details ==

Series: drm/i915/icl: Enhanced execution list support
URL   : https://patchwork.freedesktop.org/series/37054/
State : failure

== Summary ==

Series 37054v1 drm/i915/icl: Enhanced execution list support
https://patchwork.freedesktop.org/api/1.0/series/37054/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (fi-hsw-4770)
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
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:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
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:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:109  pass:100  dwarn:0   dfail:0   fail:0   skip:8  
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:458s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:497s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:575s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:527s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:486s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

92c5caeeb0cae3952f5e01d0305be09559ce49b4 drm-tip: 2018y-01m-24d-15h-29m-34s UTC 
integration manifest
b980e21aac94 drm/i915/icl: Enhanced execution list support

== Logs ==

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

Re: [Intel-gfx] [RFC 1/6] drm/armada: Simplify drm_dev_init error log

[Russell King - ARM Linux]

On Wed, Jan 24, 2018 at 04:18:16PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> dev_err will log the device in question and since there is a single caller
> to drm_dev_init inside this driver, the drm prefix and the function name
> can both also be safely dropped.
> 
> Signed-off-by: Tvrtko Ursulin 

Acked-by: Russell King 

Thanks.

> Cc: David Airlie 
> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/armada/armada_drv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 4b11b6b52f1d..76a06bf6ebcd 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -115,8 +115,7 @@ static int armada_drm_bind(struct device *dev)
>  
>   ret = drm_dev_init(>drm, _drm_driver, dev);
>   if (ret) {
> - dev_err(dev, "[" DRM_NAME ":%s] drm_dev_init failed: %d\n",
> - __func__, ret);
> + dev_err(dev, "drm_dev_init failed: %d\n", ret);
>   kfree(priv);
>   return ret;
>   }
> -- 
> 2.14.1
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915/icl: Enhanced execution list support

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-01-24 17:30:07)
> From: Thomas Daniel 
> 
> Enhanced Execlists is an upgraded version of execlists which supports
> up to 8 ports. The lrcs to be submitted are written to a submit queue
> (the ExecLists Submission Queue - ELSQ), which is then loaded on the
> HW. When writing to the ELSP register, the lrcs are written cyclically
> in the queue from position 0 to position 7. Alternatively, it is
> possible to write directly in the individual positions of the queue
> using the ELSQC registers. To be able to re-use all the existing code
> we're using the latter method and we're currently limiting ourself to
> only using 2 elements.
> 
> The preemption flow is sligthly different with enhanced execlists, so
> this patch turns preemption off temporarily for platforms with ELSQ
> while we wait for the new mechanism to land.
> 
> v2: Rebase.
> v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
> v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
> v5: Reword commit, rename regs to be closer to specs, turn off
> preemption (Daniele), reuse engine->execlists.elsp (Chris)
> v6: use has_logical_ring_elsq to differentiate the new paths
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Thomas Daniel 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Daniele Ceraolo Spurio 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  7 ++-
>  drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
>  drivers/gpu/drm/i915/intel_device_info.h |  1 +
>  drivers/gpu/drm/i915/intel_lrc.c | 35 
> +++-
>  drivers/gpu/drm/i915/intel_lrc.h |  3 +++
>  drivers/gpu/drm/i915/intel_ringbuffer.h  |  6 --
>  6 files changed, 46 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8333692..346209a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2741,8 +2741,13 @@ static inline unsigned int i915_sg_segment_size(void)
>  
>  #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
> ((dev_priv)->info.has_logical_ring_contexts)
> +#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
> +   ((dev_priv)->info.has_logical_ring_elsq)
> +
> +/* XXX: Preemption disabled for ELSQ until support for new flow lands */
>  #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
> -   ((dev_priv)->info.has_logical_ring_preemption)
> +   ((dev_priv)->info.has_logical_ring_preemption && \
> +!HAS_LOGICAL_RING_ELSQ(dev_priv))

It's in the intel_device_info for a reason. I knew I should not have let
Michal turn this into a macro.

I still do not see any reason why you don't just make the current
preemption work (it will) and then you can refine it if you prove it
worthwhile.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use enum plane_id for frontbuffer tracking

[Ville Syrjälä]

On Tue, Jan 23, 2018 at 09:11:23PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-01-23 18:33:43)
> > From: Ville Syrjälä 
> > 
> > Replace the ad-hoc plane indexing scheme used by the frontbuffer
> > tracking with enum plane_id.
> > 
> > The old video overlay not being part of the plane_id namespace
> > will just be given the high bit.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 11 +++
> >  drivers/gpu/drm/i915/intel_display.c |  4 ++--
> >  drivers/gpu/drm/i915/intel_fbc.c |  2 +-
> >  drivers/gpu/drm/i915/intel_sprite.c  |  4 +++-
> >  4 files changed, 9 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8333692dac5a..bd545b1c9546 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2404,16 +2404,11 @@ enum hdmi_force_audio {
> >   *
> >   * We have one bit per pipe and per scanout plane type.
> >   */
> > -#define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
> >  #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
> 
> I would feel safer with a BUILD_BUG_ON to catch plane_id overflowing
> INTEL_FRONTBUFFER_BITS_PER_PIPE (-1 for the overlay reservation).

Actaully we'll be going past that BITS_PER_PIPE-1 limit real soon
now, but the BITS_PER_PIPE will be sufficient for some time I think.
So I think I'd just rather ignore the overlap between the plane_id
and the overlay because that's not going happen on actual hardware.

But I think asserting that BITS_PER_PIPE is sufficient is a good idea.
Just need to figure out where to put it. There's no init function
or anything like that in the frontbuffer tracking code, so that's
not going to work. I guess one option would be to include the
assert in the INTEL_FRONTBUFFER() macro itself.

> 
> > -#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
> > -   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > -#define INTEL_FRONTBUFFER_CURSOR(pipe) \
> > -   (1 << (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > -#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
> > -   (1 << (2 + plane + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > +#define INTEL_FRONTBUFFER(pipe, plane_id) \
> > +   (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
> > -   (1 << (2 + INTEL_MAX_SPRITE_BITS_PER_PIPE + 
> > (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > +   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
> > INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
> > (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> 
> The conversion looks straightforward nevertheless, and indeed no reason
> to have move than one indexing id for a plane.
> Reviewed-by: Chris Wilson 
> -Chris

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

[Intel-gfx] [PATCH v6] drm/i915/icl: Enhanced execution list support

[Daniele Ceraolo Spurio]

From: Thomas Daniel 

Enhanced Execlists is an upgraded version of execlists which supports
up to 8 ports. The lrcs to be submitted are written to a submit queue
(the ExecLists Submission Queue - ELSQ), which is then loaded on the
HW. When writing to the ELSP register, the lrcs are written cyclically
in the queue from position 0 to position 7. Alternatively, it is
possible to write directly in the individual positions of the queue
using the ELSQC registers. To be able to re-use all the existing code
we're using the latter method and we're currently limiting ourself to
only using 2 elements.

The preemption flow is sligthly different with enhanced execlists, so
this patch turns preemption off temporarily for platforms with ELSQ
while we wait for the new mechanism to land.

v2: Rebase.
v3: Switch from !IS_GEN11 to GEN < 11 (Daniele Ceraolo Spurio).
v4: Use the elsq registers instead of elsp. (Daniele Ceraolo Spurio)
v5: Reword commit, rename regs to be closer to specs, turn off
preemption (Daniele), reuse engine->execlists.elsp (Chris)
v6: use has_logical_ring_elsq to differentiate the new paths

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_drv.h  |  7 ++-
 drivers/gpu/drm/i915/i915_pci.c  |  3 ++-
 drivers/gpu/drm/i915/intel_device_info.h |  1 +
 drivers/gpu/drm/i915/intel_lrc.c | 35 +++-
 drivers/gpu/drm/i915/intel_lrc.h |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  6 --
 6 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8333692..346209a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2741,8 +2741,13 @@ static inline unsigned int i915_sg_segment_size(void)
 
 #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
((dev_priv)->info.has_logical_ring_contexts)
+#define HAS_LOGICAL_RING_ELSQ(dev_priv) \
+   ((dev_priv)->info.has_logical_ring_elsq)
+
+/* XXX: Preemption disabled for ELSQ until support for new flow lands */
 #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \
-   ((dev_priv)->info.has_logical_ring_preemption)
+   ((dev_priv)->info.has_logical_ring_preemption && \
+!HAS_LOGICAL_RING_ELSQ(dev_priv))
 
 #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
 
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f28c165..6c86cba 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -583,7 +583,8 @@
GEN10_FEATURES, \
.gen = 11, \
.ddb_size = 2048, \
-   .has_csr = 0
+   .has_csr = 0, \
+   .has_logical_ring_elsq = 1
 
 static const struct intel_device_info intel_icelake_11_info __initconst = {
GEN11_FEATURES,
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 9542018..dbf0f2d 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -96,6 +96,7 @@ enum intel_platform {
func(has_l3_dpf); \
func(has_llc); \
func(has_logical_ring_contexts); \
+   func(has_logical_ring_elsq); \
func(has_logical_ring_preemption); \
func(has_overlay); \
func(has_pooled_eu); \
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 22d471a..6c7cf93 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -428,11 +428,24 @@ static inline void elsp_write(u64 desc, u32 __iomem *elsp)
writel(lower_32_bits(desc), elsp);
 }
 
+static inline void elsqc_write(u64 desc, u32 __iomem *elsqc, u32 port)
+{
+   writel(lower_32_bits(desc), elsqc + port * 2);
+   writel(upper_32_bits(desc), elsqc + port * 2 + 1);
+}
+
 static void execlists_submit_ports(struct intel_engine_cs *engine)
 {
+   struct drm_i915_private *dev_priv = engine->i915;
struct execlist_port *port = engine->execlists.port;
unsigned int n;
 
+   /*
+* ELSQ note: the submit queue is not cleared after being submitted
+* to the HW so we need to make sure we always clean it up. This is
+* currently ensured by the fact that we always write the same number
+* of elsq entries, keep this in mind before changing the loop below.
+*/
for (n = execlists_num_ports(>execlists); n--; ) {
struct drm_i915_gem_request *rq;
unsigned int count;
@@ -456,8 +469,16 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
desc = 0;
}
 
-   

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use enum plane_id for frontbuffer tracking

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 04:04:49AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Use enum plane_id for frontbuffer tracking
> URL   : https://patchwork.freedesktop.org/series/36991/
> State : failure
> 
> == Summary ==
> 
> Test kms_flip:
> Subgroup 2x-wf_vblank-ts-check-interruptible:
> pass   -> FAIL   (shard-hsw)

missed a vblank
(kms_flip:8780) CRITICAL: Test assertion failure function calibrate_ts,
file kms_flip.c:1199:
(kms_flip:8780) CRITICAL: Failed assertion: ev.sequence == last_seq + 1
(kms_flip:8780) CRITICAL: Last errno: 4, Interrupted system call
(kms_flip:8780) CRITICAL: error: 56602 != 56601

> Subgroup flip-vs-expired-vblank-interruptible:
> fail   -> PASS   (shard-hsw) fdo#102887
> Subgroup vblank-vs-modeset-suspend:
> pass   -> SKIP   (shard-snb) fdo#102365 +1
> Subgroup vblank-vs-modeset-suspend-interruptible:
> pass   -> DMESG-WARN (shard-snb)

[  116.297966] unchecked MSR access error: RDMSR from 0x1b0 at rIP:
0x8102e256 (init_intel_energy_perf.part.3+0x6/0xa0)

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

> Subgroup plain-flip-fb-recreate-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368
> Test kms_sysfs_edid_timing:
> warn   -> PASS   (shard-apl) fdo#100047
> Test gem_softpin:
> Subgroup noreloc-s4:
> fail   -> SKIP   (shard-snb) fdo#103375
> Test perf:
> Subgroup buffer-fill:
> pass   -> FAIL   (shard-apl) fdo#103755
> 
> fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
> fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
> fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
> fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
> fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
> fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
> 
> shard-apltotal:2753 pass:1716 dwarn:1   dfail:0   fail:23  skip:1013 
> time:14064s
> shard-hswtotal:2753 pass:1723 dwarn:1   dfail:0   fail:13  skip:1015 
> time:15328s
> shard-snbtotal:2753 pass:1317 dwarn:2   dfail:0   fail:9   skip:1425 
> time:7847s
> Blacklisted hosts:
> shard-kbltotal:2753 pass:1821 dwarn:16  dfail:1   fail:24  skip:891 
> time:3s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7755/shards.html

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

Re: [Intel-gfx] REGRESSION in c5552fde102f ("nvme: Enable autonomous power state transitions")

[Andy Lutomirski]

On Wed, Jan 24, 2018 at 5:35 AM, Ville Syrjälä
 wrote:
> On Wed, Jan 24, 2018 at 01:42:08PM +0200, Jani Nikula wrote:
>>
>> Hi Andy, all -
>>
>> So this is an odd one.
>>
>> I'm getting display FIFO underruns in a very specific setting: Laptop
>> display switched off, and an external display connected. Other
>> combinations work fine.
>>
>> I've bisected this to c5552fde102f ("nvme: Enable autonomous power state
>> transitions"), and, being baffled by the result, carefully checked
>> this. There are no problems when running c5552fde102f^, with
>> nvme_core.default_ps_max_latency_us=0, or after 'echo 0 >
>> pm_qos_latency_tolerance_us'. With the last one, restoring the original
>> value of 10 brings the underruns back.
>>
>> I have no idea what the root cause mechanism here is, but the bisect is
>> correct. Perhaps something to do with timing. I'd be happy to provide
>> further details.
>>
>> I see that you have quirked one Samsung device. Incidentally, this
>> Lenovo Yoga 910 (Kabylake, SunrisePoint LP PCH) also has a Samsung NVMe
>> device, just a different one. Details below. I don't know what the
>> failure mode in the quirked one is, so I don't know if this could be the
>> same issue.
>
> My first gut feeling would be that by allowing the nvme to go to sleep
> we're gettting into some deeper power saving state, which then causes
> display underruns. How does the package c-state residency look
> before/after the commit?

I know approximately nothing about how package C-states works and what
exactly triggers APSM low-power state entry, but I've seen reports
that APST is required to get ASPM L1 and that ASPM L1 is needed to get
to the deep PC states.  And deep PC states can surely trigger i915
issues...

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

Re: [Intel-gfx] [RFC v2 0/6] DRM logging tidy

[Tvrtko Ursulin]

On 24/01/2018 16:23, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-24 16:18:15)

From: Tvrtko Ursulin 

This series tries to solve a few issues in the current DRM logging code to
primarily make it clearer which messages belong to which driver.

Main problem is that currently some logging functions allow individual drivers
to override the log prefix (since they are defined as macros, or static
inlines), while other hardcode the "drm" prefix into them due being situated in
the DRM core modules.

Another thing is that I noticed the DRM_NAME macro which is used for this is
defined in the uAPI header and had a comment which looked outdated.

Therefore I introduce a new define, called, DRM_LOG_NAME, this time defined
internally in the kernel headers and not exported in the uAPI.

I also refactored some logging functions to take this string as a parameter
instead of hardcoding it.

Individual drivers can then override this define to make DRM logging functions
prefix their message with the respective driver prefix.

End result in the case of the i915 driver looks like this:

Old log:

  [drm] Found 128MB of eDRAM
  [drm:skl_enable_dc6 [i915]] Enabling DC6

New log:

  [i915] Found 128MB of eDRAM
  [i915:skl_enable_dc6 [i915]] Enabling DC6


And still not conforming to the standard logging string. DRM_LOG should


What is the standard logging string? the dev_ one?


be killed off as an anachronistic OS compat layer.


You mean only dev variants should be kept?

Regards,

Tvrtko


___
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 logging tidy (rev2)

[Patchwork]

== Series Details ==

Series: DRM logging tidy (rev2)
URL   : https://patchwork.freedesktop.org/series/16439/
State : success

== Summary ==

Series 16439v2 DRM logging tidy
https://patchwork.freedesktop.org/api/1.0/series/16439/revisions/2/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
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:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:399s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:459s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:596s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:525s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
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:400s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s

92c5caeeb0cae3952f5e01d0305be09559ce49b4 drm-tip: 2018y-01m-24d-15h-29m-34s UTC 
integration manifest
641f30a6ad61 drm: Respect driver set DRM_LOG_NAME in drm_info_printer
3260202bbbd8 drm: Respect driver set DRM_LOG_NAME in drm_dev_printk
e4053d27154d drm: Respect driver set DRM_LOG_NAME in drm_printk
95c203daf028 drm/i915: Give our log messages our name
c3494a30403b drm: Introduce unexported DRM_LOG_NAME define for logging
2507afa2f0d7 drm/armada: Simplify drm_dev_init error log

== Logs ==

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

Re: [Intel-gfx] [RFC v2 0/6] DRM logging tidy

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-24 16:18:15)
> From: Tvrtko Ursulin 
> 
> This series tries to solve a few issues in the current DRM logging code to
> primarily make it clearer which messages belong to which driver.
> 
> Main problem is that currently some logging functions allow individual drivers
> to override the log prefix (since they are defined as macros, or static
> inlines), while other hardcode the "drm" prefix into them due being situated 
> in
> the DRM core modules.
> 
> Another thing is that I noticed the DRM_NAME macro which is used for this is
> defined in the uAPI header and had a comment which looked outdated.
> 
> Therefore I introduce a new define, called, DRM_LOG_NAME, this time defined
> internally in the kernel headers and not exported in the uAPI.
> 
> I also refactored some logging functions to take this string as a parameter
> instead of hardcoding it.
> 
> Individual drivers can then override this define to make DRM logging functions
> prefix their message with the respective driver prefix.
> 
> End result in the case of the i915 driver looks like this:
> 
> Old log:
> 
>  [drm] Found 128MB of eDRAM
>  [drm:skl_enable_dc6 [i915]] Enabling DC6
> 
> New log:
> 
>  [i915] Found 128MB of eDRAM
>  [i915:skl_enable_dc6 [i915]] Enabling DC6

And still not conforming to the standard logging string. DRM_LOG should
be killed off as an anachronistic OS compat layer.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC 5/6] drm: Respect driver set DRM_LOG_NAME in drm_dev_printk

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Same as the previous patch did for drm_printk, allow for the logging
macros to pass in the driver set DRM_LOG_NAME for drm_dev_printk.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/drm_print.c | 12 ++--
 include/drm/drm_print.h | 31 ---
 2 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 90d38c830392..f97bfcb7d882 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -63,11 +63,10 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
 }
 EXPORT_SYMBOL(drm_printf);
 
-#define DRM_PRINTK_FMT "[" DRM_LOG_NAME ":%s]%s %pV"
-
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...)
+   const char *prefix, const char *driver,
+   const char *format, ...)
 {
struct va_format vaf;
va_list args;
@@ -80,10 +79,11 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
vaf.va = 
 
if (dev)
-   dev_printk(level, dev, DRM_PRINTK_FMT, function_name, prefix,
-  );
+   dev_printk(level, dev, "[%s:%s]%s %pV", driver, function_name,
+  prefix, );
else
-   printk("%s" DRM_PRINTK_FMT, level, function_name, prefix, );
+   printk("%s[%s:%s]%s %pV", level, driver, function_name, prefix,
+  );
 
va_end(args);
 }
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index c6047de9cbcc..c4dfcd217bce 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -203,10 +203,11 @@ static inline struct drm_printer drm_debug_printer(const 
char *prefix)
 #define DRM_UT_STATE   0x40
 #define DRM_UT_LEASE   0x80
 
-__printf(6, 7)
+__printf(7, 8)
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...);
+   const char *prefix, const char *driver, const char *format,
+   ...);
 __printf(4, 5)
 void drm_printk(const char *level, unsigned int category, const char *driver,
const char *format, ...);
@@ -241,7 +242,7 @@ void drm_printk(const char *level, unsigned int category, 
const char *driver,
  */
 #define DRM_DEV_ERROR(dev, fmt, ...)   \
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
-  fmt, ##__VA_ARGS__)
+  DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 #define DRM_ERROR(fmt, ...)\
drm_printk(KERN_ERR, DRM_UT_NONE, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
@@ -264,8 +265,8 @@ void drm_printk(const char *level, unsigned int category, 
const char *driver,
DRM_DEV_ERROR_RATELIMITED(NULL, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_INFO(dev, fmt, ...)\
-   drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "", fmt,  \
-  ##__VA_ARGS__)
+   drm_dev_printk(dev, KERN_INFO, DRM_UT_NONE, __func__, "",   \
+  DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_INFO_ONCE(dev, fmt, ...)   \
 ({ \
@@ -283,38 +284,38 @@ void drm_printk(const char *level, unsigned int category, 
const char *driver,
  * @fmt: printf() like format string.
  */
 #define DRM_DEV_DEBUG(dev, fmt, args...)   \
-   drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
-  ##args)
+   drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "",  \
+  DRM_LOG_NAME, fmt, ##args)
 #define DRM_DEBUG(fmt, ...)\
drm_printk(KERN_DEBUG, DRM_UT_CORE, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
-  fmt, ##args)
+  DRM_LOG_NAME, fmt, ##args)
 #define DRM_DEBUG_DRIVER(fmt, ...) \
drm_printk(KERN_DEBUG, DRM_UT_DRIVER, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_KMS(dev, fmt, args...)   \
-   drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt,  \
-

[Intel-gfx] [RFC 6/6] drm: Respect driver set DRM_LOG_NAME in drm_info_printer

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Same as the previous patch did for drm_printk, allow for the logging
macros to pass in the driver set DRM_LOG_NAME for drm_info_printer.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/drm_print.c | 2 +-
 include/drm/drm_print.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index f97bfcb7d882..1fcc08876f87 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -38,7 +38,7 @@ EXPORT_SYMBOL(__drm_printfn_seq_file);
 
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf)
 {
-   dev_info(p->arg, "[" DRM_LOG_NAME "] %pV", vaf);
+   dev_info(p->arg, "[%s] %pV", p->prefix, vaf);
 }
 EXPORT_SYMBOL(__drm_printfn_info);
 
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index c4dfcd217bce..1f613b49c8f2 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -139,6 +139,7 @@ static inline struct drm_printer drm_info_printer(struct 
device *dev)
struct drm_printer p = {
.printfn = __drm_printfn_info,
.arg = dev,
+   .prefix = DRM_LOG_NAME,
};
return p;
 }
-- 
2.14.1

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

[Intel-gfx] [RFC 1/6] drm/armada: Simplify drm_dev_init error log

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

dev_err will log the device in question and since there is a single caller
to drm_dev_init inside this driver, the drm prefix and the function name
can both also be safely dropped.

Signed-off-by: Tvrtko Ursulin 
Cc: Russell King 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/armada/armada_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 4b11b6b52f1d..76a06bf6ebcd 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -115,8 +115,7 @@ static int armada_drm_bind(struct device *dev)
 
ret = drm_dev_init(>drm, _drm_driver, dev);
if (ret) {
-   dev_err(dev, "[" DRM_NAME ":%s] drm_dev_init failed: %d\n",
-   __func__, ret);
+   dev_err(dev, "drm_dev_init failed: %d\n", ret);
kfree(priv);
return ret;
}
-- 
2.14.1

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

[Intel-gfx] [RFC 3/6] drm/i915: Give our log messages our name

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Define DRM_LOG_NAME to i915 so that the log messages we output change
from:

 [drm] RC6 on

to:

 [i915] RC6 on

Signed-off-by: Tvrtko Ursulin 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8333692dac5a..2b48a7d2d129 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -30,6 +30,11 @@
 #ifndef _I915_DRV_H_
 #define _I915_DRV_H_
 
+#ifdef DRM_LOG_NAME
+#undef DRM_LOG_NAME
+#endif
+#define DRM_LOG_NAME "i915"
+
 #include 
 #include 
 
-- 
2.14.1

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

[Intel-gfx] [RFC v2 0/6] DRM logging tidy

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

This series tries to solve a few issues in the current DRM logging code to
primarily make it clearer which messages belong to which driver.

Main problem is that currently some logging functions allow individual drivers
to override the log prefix (since they are defined as macros, or static
inlines), while other hardcode the "drm" prefix into them due being situated in
the DRM core modules.

Another thing is that I noticed the DRM_NAME macro which is used for this is
defined in the uAPI header and had a comment which looked outdated.

Therefore I introduce a new define, called, DRM_LOG_NAME, this time defined
internally in the kernel headers and not exported in the uAPI.

I also refactored some logging functions to take this string as a parameter
instead of hardcoding it.

Individual drivers can then override this define to make DRM logging functions
prefix their message with the respective driver prefix.

End result in the case of the i915 driver looks like this:

Old log:

 [drm] Found 128MB of eDRAM
 [drm:skl_enable_dc6 [i915]] Enabling DC6

New log:

 [i915] Found 128MB of eDRAM
 [i915:skl_enable_dc6 [i915]] Enabling DC6

There is some redundancy in the debug logs, as can be seen in the line above,
but this comes from drm_printk printing the calling function name using the %ps
formatting specifier and __builtin_return_address. Theoretically we could remove
the driver prefix from debug messages, but that would make the messages a bit
unusually formatted like:

 [skl_enable_dc6 [i915]] Enabling DC6

Better would probably be:

 [i915:skl_enable_dc6] Enabling DC6

But I do not know how to achieve that apart from changing the drm_printk
wrapper macros to pass in __func__ and drop the __builtin_return_address
business. And that would also mean all DRM drivers would have to start defining
DRM_LOG_NAME or would lose the module owner info. So I opted not to go that
route for now.

Main question is whether people find all this an interesting change or would
prefer to leave the logging prefixes as they were, or perhaps do some heavier
changes to DRM logging.

Cc: dri-de...@lists.freedesktop.org

Tvrtko Ursulin (6):
  drm/armada: Simplify drm_dev_init error log
  drm: Introduce unexported DRM_LOG_NAME define for logging
  drm/i915: Give our log messages our name
  drm: Respect driver set DRM_LOG_NAME in drm_printk
  drm: Respect driver set DRM_LOG_NAME in drm_dev_printk
  drm: Respect driver set DRM_LOG_NAME in drm_info_printer

 drivers/gpu/drm/armada/armada_drv.c  |  3 +-
 drivers/gpu/drm/drm_print.c  | 20 ++--
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  5 +++
 drivers/gpu/drm/i915/intel_display.c |  3 +-
 include/drm/drm_print.h  | 61 +---
 include/uapi/drm/drm.h   |  2 +-
 7 files changed, 55 insertions(+), 41 deletions(-)

-- 
2.14.1

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

[Intel-gfx] [RFC 2/6] drm: Introduce unexported DRM_LOG_NAME define for logging

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Instead of having DRM_NAME which is defined in the uAPI headers used for
kernel log prefix messages, introduct a new DRM_LOG_NAME define defined
privately in kernel space.

Leave the DRM_NAME around, but mark it as obsolete in case there is some
userspace code depending on its presence.

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/drm_print.c | 6 +++---
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 include/drm/drm_print.h | 9 -
 include/uapi/drm/drm.h  | 2 +-
 4 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 781518fd88e3..27244f11c9a3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -38,7 +38,7 @@ EXPORT_SYMBOL(__drm_printfn_seq_file);
 
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf)
 {
-   dev_info(p->arg, "[" DRM_NAME "] %pV", vaf);
+   dev_info(p->arg, "[" DRM_LOG_NAME "] %pV", vaf);
 }
 EXPORT_SYMBOL(__drm_printfn_info);
 
@@ -63,7 +63,7 @@ void drm_printf(struct drm_printer *p, const char *f, ...)
 }
 EXPORT_SYMBOL(drm_printf);
 
-#define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
+#define DRM_PRINTK_FMT "[" DRM_LOG_NAME ":%s]%s %pV"
 
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
@@ -102,7 +102,7 @@ void drm_printk(const char *level, unsigned int category,
vaf.fmt = format;
vaf.va = 
 
-   printk("%s" "[" DRM_NAME ":%ps]%s %pV",
+   printk("%s" "[" DRM_LOG_NAME ":%ps]%s %pV",
   level, __builtin_return_address(0),
   strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1fbe37889d92..915e43aacaa5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -94,7 +94,7 @@ __i915_printk(struct drm_i915_private *dev_priv, const char 
*level,
vaf.fmt = fmt;
vaf.va = 
 
-   dev_printk(level, kdev, "[" DRM_NAME ":%ps] %pV",
+   dev_printk(level, kdev, "[" DRM_LOG_NAME ":%ps] %pV",
   __builtin_return_address(0), );
 
if (is_error && !shown_bug_once) {
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 2a4a42e59a47..d6901128faf2 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -60,6 +60,13 @@
  * }
  */
 
+/**
+ * String output in log messages - can be overriden by driver code.
+ */
+#ifndef DRM_LOG_NAME
+#define DRM_LOG_NAME "drm"
+#endif
+
 /**
  * struct drm_printer - drm output "stream"
  *
@@ -208,7 +215,7 @@ void drm_printk(const char *level, unsigned int category,
 
 #define _DRM_PRINTK(once, level, fmt, ...) \
do {\
-   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+   printk##once(KERN_##level "[" DRM_LOG_NAME "] " fmt,\
 ##__VA_ARGS__);\
} while (0)
 
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff5945c8a..7b512673c220 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -69,7 +69,7 @@ typedef unsigned long drm_handle_t;
 extern "C" {
 #endif
 
-#define DRM_NAME   "drm" /**< Name in kernel, /dev, and /proc */
+#define DRM_NAME   "drm" /**< Deprecated. */
 #define DRM_MIN_ORDER  5 /**< At least 2^5 bytes = 32 bytes */
 #define DRM_MAX_ORDER  22/**< Up to 2^22 bytes = 4MB */
 #define DRM_RAM_PERCENT 10   /**< How much system ram can we lock? */
-- 
2.14.1

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

[Intel-gfx] [RFC 4/6] drm: Respect driver set DRM_LOG_NAME in drm_printk

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Since drm_printk is built inside the DRM core module, it will not respect
the potentially overriden by the driver DRM_LOG_NAME.

Make it tale the driver prefix and change it's wrappers so it is passed
in from the driver code. This makes the driver log messages correctly
identify from which driver they originated.

For instance i915, instead of:

 [drm:edp_panel_off [i915]] Wait for panel power off time

would now log debug messages as:

 [i915:edp_panel_off [i915]] Wait for panel power off time

Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Gustavo Padovan 
Cc: Sean Paul 
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/drm_print.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  3 ++-
 include/drm/drm_print.h  | 20 ++--
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 27244f11c9a3..90d38c830392 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -89,7 +89,7 @@ void drm_dev_printk(const struct device *dev, const char 
*level,
 }
 EXPORT_SYMBOL(drm_dev_printk);
 
-void drm_printk(const char *level, unsigned int category,
+void drm_printk(const char *level, unsigned int category, const char *driver,
const char *format, ...)
 {
struct va_format vaf;
@@ -102,8 +102,8 @@ void drm_printk(const char *level, unsigned int category,
vaf.fmt = format;
vaf.va = 
 
-   printk("%s" "[" DRM_LOG_NAME ":%ps]%s %pV",
-  level, __builtin_return_address(0),
+   printk("%s[%s:%ps]%s %pV",
+  level, driver, __builtin_return_address(0),
   strcmp(level, KERN_ERR) == 0 ? " *ERROR*" : "", );
 
va_end(args);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d585ce4c8732..51fea2eb1b2e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10973,7 +10973,8 @@ pipe_config_err(bool adjust, const char *name, const 
char *format, ...)
vaf.fmt = format;
vaf.va = 
 
-   drm_printk(level, category, "mismatch in %s %pV", name, );
+   drm_printk(level, category, DRM_LOG_NAME, "mismatch in %s %pV", name,
+  );
 
va_end(args);
 }
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index d6901128faf2..c6047de9cbcc 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -207,8 +207,8 @@ __printf(6, 7)
 void drm_dev_printk(const struct device *dev, const char *level,
unsigned int category, const char *function_name,
const char *prefix, const char *format, ...);
-__printf(3, 4)
-void drm_printk(const char *level, unsigned int category,
+__printf(4, 5)
+void drm_printk(const char *level, unsigned int category, const char *driver,
const char *format, ...);
 
 /* Macros to make printk easier */
@@ -243,7 +243,7 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_ERR, DRM_UT_NONE, __func__, " *ERROR*",\
   fmt, ##__VA_ARGS__)
 #define DRM_ERROR(fmt, ...)\
-   drm_printk(KERN_ERR, DRM_UT_NONE, fmt,  ##__VA_ARGS__)
+   drm_printk(KERN_ERR, DRM_UT_NONE, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 /**
  * Rate limited error output.  Like DRM_ERROR() but won't flood the log.
@@ -286,40 +286,40 @@ void drm_printk(const char *level, unsigned int category,
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_CORE, __func__, "", fmt, \
   ##args)
 #define DRM_DEBUG(fmt, ...)\
-   drm_printk(KERN_DEBUG, DRM_UT_CORE, fmt, ##__VA_ARGS__)
+   drm_printk(KERN_DEBUG, DRM_UT_CORE, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_DRIVER(dev, fmt, args...)
\
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_DRIVER, __func__, "",\
   fmt, ##args)
 #define DRM_DEBUG_DRIVER(fmt, ...) \
-   drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
+   drm_printk(KERN_DEBUG, DRM_UT_DRIVER, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_KMS(dev, fmt, args...)   \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_KMS, __func__, "", fmt,  \
   ##args)
 #define DRM_DEBUG_KMS(fmt, ...)\
-   drm_printk(KERN_DEBUG, DRM_UT_KMS, fmt, ##__VA_ARGS__)
+   drm_printk(KERN_DEBUG, DRM_UT_KMS, DRM_LOG_NAME, fmt, ##__VA_ARGS__)
 
 #define DRM_DEV_DEBUG_PRIME(dev, fmt, args...) \
drm_dev_printk(dev, KERN_DEBUG, DRM_UT_PRIME, __func__, "", \
  

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock while 
disabling GuC interrupts
URL   : https://patchwork.freedesktop.org/series/37044/
State : success

== Summary ==

Series 37044v1 series starting with [v4,1/6] drm/i915/guc: Grab RPM wakelock 
while disabling GuC interrupts
https://patchwork.freedesktop.org/api/1.0/series/37044/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:422s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:489s
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:482s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:466s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-elk-e7500 total:224  pass:167  dwarn:10  dfail:0   fail:1   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:278s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:390s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:412s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:417s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:431s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:511s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:415s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:435s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:563s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s

92c5caeeb0cae3952f5e01d0305be09559ce49b4 drm-tip: 2018y-01m-24d-15h-29m-34s UTC 
integration manifest
475cd4c8c2b8 Revert "drm/i915/guc: Keep GuC log disabled by default"
4ea239fa225c drm/i915/guc: Fix comments style in intel_guc_log.c
4800c9d3713e drm/i915/guc: Update name and prototype of i915_guc_log_control
0e0263e727c1 drm/i915/guc: Fix lockdep due to log relay channel handling under 
struct_mutex
03ab713e21d0 drm/i915/guc: Enable interrupts before resuming GuC during runtime 
resume
14022b30f2f8 drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

== Logs ==

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

[Intel-gfx] [PATCH v4 3/6] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

[Sagar Arun Kamble]

This patch fixes lockdep issue due to circular locking dependency of
struct_mutex, i_mutex_key, mmap_sem, relay_channels_mutex.
For GuC log relay channel we create debugfs file that requires i_mutex_key
lock and we are doing that under struct_mutex. So we introduced newer
dependency as:
>struct_mutex --> >s_type->i_mutex_key#3 --> >mmap_sem
However, there is dependency from mmap_sem to struct_mutex. Hence we
separate the relay create/destroy operation from under struct_mutex.
Also added runtime check of relay buffer status.

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

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

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #3 (>mmap_sem){}:
   _copy_to_user+0x1e/0x70
   filldir+0x8c/0xf0
   dcache_readdir+0xeb/0x160
   iterate_dir+0xdc/0x140
   SyS_getdents+0xa0/0x130
   entry_SYSCALL_64_fastpath+0x1c/0x89

-> #2 (>s_type->i_mutex_key#3){}:
   start_creating+0x59/0x110
   __debugfs_create_file+0x2e/0xe0
   relay_create_buf_file+0x62/0x80
   relay_late_setup_files+0x84/0x250
   guc_log_late_setup+0x4f/0x110 [i915]
   i915_guc_log_register+0x32/0x40 [i915]
   i915_driver_load+0x7b6/0x1720 [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

-> #1 (relay_channels_mutex){+.+.}:
   relay_open+0x12c/0x2b0
   intel_guc_log_runtime_create+0xab/0x230 [i915]
   intel_guc_init+0x81/0x120 [i915]
   intel_uc_init+0x29/0xa0 [i915]
   i915_gem_init+0x182/0x530 [i915]
   i915_driver_load+0xaa9/0x1720 [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){+.+.}:
   __mutex_lock+0x81/0x9b0
   i915_mutex_lock_interruptible+0x47/0x130 [i915]
   i915_gem_fault+0x201/0x790 [i915]
   __do_fault+0x15/0x70
   __handle_mm_fault+0x677/0xdc0
   handle_mm_fault+0x14f/0x2f0
   __do_page_fault+0x2d1/0x560
   page_fault+0x4c/0x60

other info that might help us debug this:

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

 Possible unsafe locking scenario:

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

 *** DEADLOCK ***

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

stack backtrace:
CPU: 2 PID: 1388 Comm: debugfs_test Not tainted 4.15.0-rc6-CI-Patchwork_7614+ #1
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS 
P1.10 09/29/2016
Call Trace:
 dump_stack+0x5f/0x86
 print_circular_bug.isra.18+0x1d0/0x2c0
 __lock_acquire+0x14ae/0x1b60
 ? lock_acquire+0xaf/0x200
 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/0x790 [i915]
 __do_fault+0x15/0x70
 ? _raw_spin_unlock+0x29/0x40
 __handle_mm_fault+0x677/0xdc0
 handle_mm_fault+0x14f/0x2f0
 __do_page_fault+0x2d1/0x560
 ? page_fault+0x36/0x60
 page_fault+0x4c/0x60

v2: Added lock protection to guc->log.runtime.relay_chan (Chris)
Fixed locking inside guc_flush_logs uncovered by new lockdep.

v3: Locking guc_read_update_log_buffer entirely with relay_lock. (Chris)
Prepared intel_guc_init_early. Moved relay_lock inside relay_create
relay_destroy, relay_file_create, guc_read_update_log_buffer. (Michal)
Removed struct_mutex lock around guc_log_flush and removed usage
of guc_log_has_relay() from runtime_create path as it needs
struct_mutex lock.

v4: 

[Intel-gfx] [PATCH v4 1/6] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

[Sagar Arun Kamble]

Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

v1-v2: old changelog
1: Add comment about need to synchronize flush work and log runtime
   destroy
2: Moved patch earlier in the series and removed comment about future
work. (Tvrtko)

v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_irq.c  | 6 ++
 drivers/gpu/drm/i915/intel_guc_log.c | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3517c65..85c46a2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -452,6 +452,8 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
 
 void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv)
 {
+   assert_rpm_wakelock_held(dev_priv);
+
spin_lock_irq(_priv->irq_lock);
gen6_reset_pm_iir(dev_priv, dev_priv->pm_guc_events);
spin_unlock_irq(_priv->irq_lock);
@@ -459,6 +461,8 @@ void gen9_reset_guc_interrupts(struct drm_i915_private 
*dev_priv)
 
 void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv)
 {
+   assert_rpm_wakelock_held(dev_priv);
+
spin_lock_irq(_priv->irq_lock);
if (!dev_priv->guc.interrupts_enabled) {
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
@@ -471,6 +475,8 @@ void gen9_enable_guc_interrupts(struct drm_i915_private 
*dev_priv)
 
 void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv)
 {
+   assert_rpm_wakelock_held(dev_priv);
+
spin_lock_irq(_priv->irq_lock);
dev_priv->guc.interrupts_enabled = false;
 
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 2ffc966..8f2da30 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -639,7 +639,10 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
 
mutex_lock(_priv->drm.struct_mutex);
/* GuC logging is currently the only user of Guc2Host interrupts */
+   intel_runtime_pm_get(dev_priv);
gen9_disable_guc_interrupts(dev_priv);
+   intel_runtime_pm_put(dev_priv);
+
guc_log_runtime_destroy(_priv->guc);
mutex_unlock(_priv->drm.struct_mutex);
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/6] drm/i915/guc: Enable interrupts before resuming GuC during runtime resume

[Sagar Arun Kamble]

GuC log streaming needs interrupts enabled prior to GuC resume but
runtime pm interrupt setup was happening post GuC resume. Fix it.
While at it, fix the unwinding of steps in the runtime suspend path.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104695
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michal Wajdeczko 
Cc: Michał Winiarski 
Cc: Joonas Lahtinen 
Cc: Marta Lofstedt 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1fbe378..95e1c16 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2600,6 +2600,11 @@ static int intel_runtime_suspend(struct device *kdev)
 
intel_runtime_pm_enable_interrupts(dev_priv);
 
+   intel_guc_resume(dev_priv);
+
+   i915_gem_init_swizzling(dev_priv);
+   i915_gem_restore_fences(dev_priv);
+
enable_rpm_wakeref_asserts(dev_priv);
 
return ret;
@@ -2665,8 +2670,6 @@ static int intel_runtime_resume(struct device *kdev)
if (intel_uncore_unclaimed_mmio(dev_priv))
DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
 
-   intel_guc_resume(dev_priv);
-
if (IS_GEN9_LP(dev_priv)) {
bxt_disable_dc9(dev_priv);
bxt_display_core_init(dev_priv, true);
@@ -2681,6 +2684,10 @@ static int intel_runtime_resume(struct device *kdev)
 
intel_uncore_runtime_resume(dev_priv);
 
+   intel_runtime_pm_enable_interrupts(dev_priv);
+
+   intel_guc_resume(dev_priv);
+
/*
 * No point of rolling back things in case of an error, as the best
 * we can do is to hope that things will still work (and disable RPM).
@@ -2688,8 +2695,6 @@ static int intel_runtime_resume(struct device *kdev)
i915_gem_init_swizzling(dev_priv);
i915_gem_restore_fences(dev_priv);
 
-   intel_runtime_pm_enable_interrupts(dev_priv);
-
/*
 * On VLV/CHV display interrupts are part of the display
 * power well, so hpd is reinitialized from there. For
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 6/6] [HAX] Revert "drm/i915/guc: Keep GuC log disabled by default"

[Sagar Arun Kamble]

Comment DRM_ERROR_RATELIMIT outputs as log capturer won't be
running.

This reverts commit bd724318b682587ad2f989ab8e0f7b3d4486ced5.
---
 drivers/gpu/drm/i915/i915_params.h   | 2 +-
 drivers/gpu/drm/i915/intel_guc_log.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..c963603 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -48,7 +48,7 @@
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
param(int, enable_guc, 0) \
-   param(int, guc_log_level, 0) \
+   param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 86a3321..1ceb81a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -249,7 +249,7 @@ static bool guc_check_log_buf_overflow(struct intel_guc 
*guc,
/* buffer_full_cnt is a 4 bit counter */
guc->log.total_overflow_count[type] += 16;
}
-   DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
+   //DRM_ERROR_RATELIMITED("GuC log buffer overflow\n");
}
 
return overflow;
@@ -296,7 +296,7 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 * Used rate limited to avoid deluge of messages, logs might be
 * getting consumed by User at a slow rate.
 */
-   DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
+   //DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
guc->log.capture_miss_count++;
mutex_unlock(>log.runtime.relay_lock);
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 5/6] drm/i915/guc: Fix comments style in intel_guc_log.c

[Sagar Arun Kamble]

Use consistent multi-line comment style as per guideline.

v2: Reverted comments prefix update to kernel-doc comment. (Chris)

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 45 
 1 file changed, 30 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index cb10f7a..86a3321 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -81,7 +81,8 @@ static int subbuf_start_callback(struct rchan_buf *buf,
 void *prev_subbuf,
 size_t prev_padding)
 {
-   /* Use no-overwrite mode by default, where relay will stop accepting
+   /*
+* Use no-overwrite mode by default, where relay will stop accepting
 * new data if there are no empty sub buffers left.
 * There is no strict synchronization enforced by relay between Consumer
 * and Producer. In overwrite mode, there is a possibility of getting
@@ -107,7 +108,8 @@ static struct dentry *create_buf_file_callback(const char 
*filename,
 {
struct dentry *buf_file;
 
-   /* This to enable the use of a single buffer for the relay channel and
+   /*
+* This to enable the use of a single buffer for the relay channel and
 * correspondingly have a single file exposed to User, through which
 * it can collect the logs in order without any post-processing.
 * Need to set 'is_global' even if parent is NULL for early logging.
@@ -117,7 +119,8 @@ static struct dentry *create_buf_file_callback(const char 
*filename,
if (!parent)
return NULL;
 
-   /* Not using the channel filename passed as an argument, since for each
+   /*
+* Not using the channel filename passed as an argument, since for each
 * channel relay appends the corresponding CPU number to the filename
 * passed in relay_open(). This should be fine as relay just needs a
 * dentry of the file associated with the channel buffer and that file's
@@ -158,7 +161,8 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
/* For now create the log file in /sys/kernel/debug/dri/0 dir */
log_dir = dev_priv->drm.primary->debugfs_root;
 
-   /* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
+   /*
+* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
 * not mounted and so can't create the relay file.
 * The relay API seems to fit well with debugfs only, for availing relay
 * there are 3 requirements which can be met for debugfs file only in a
@@ -195,7 +199,8 @@ static bool guc_log_has_relay(struct intel_guc *guc)
 
 static void guc_move_to_next_buf(struct intel_guc *guc)
 {
-   /* Make sure the updates made in the sub buffer are visible when
+   /*
+* Make sure the updates made in the sub buffer are visible when
 * Consumer sees the following update to offset inside the sub buffer.
 */
smp_wmb();
@@ -215,7 +220,8 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
if (!guc_log_has_relay(guc))
return NULL;
 
-   /* Just get the base address of a new sub buffer and copy data into it
+   /*
+* Just get the base address of a new sub buffer and copy data into it
 * ourselves. NULL will be returned in no-overwrite mode, if all sub
 * buffers are full. Could have used the relay_write() to indirectly
 * copy the data, but that would have been bit convoluted, as we need to
@@ -286,7 +292,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
 
if (unlikely(!log_buf_snapshot_state)) {
-   /* Used rate limited to avoid deluge of messages, logs might be
+   /*
+* Used rate limited to avoid deluge of messages, logs might be
 * getting consumed by User at a slow rate.
 */
DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
@@ -301,7 +308,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
dst_data += PAGE_SIZE;
 
for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
-   /* Make a copy of the state structure, inside GuC log buffer
+   /*
+* Make a copy of the state structure, inside GuC log buffer
 * (which is uncached mapped), on the stack to avoid reading
 * from it multiple times.
 */
@@ -325,7 +333,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
   

[Intel-gfx] [PATCH v4 4/6] drm/i915/guc: Update name and prototype of i915_guc_log_control

[Sagar Arun Kamble]

i915_guc_log_control is GuC interface and GuC APIs that are not user
facing should be named with "intel_guc" prefix hence we change name to
intel_guc_log_control. Also changed the parameter to intel_guc struct.

v2: Move log vma check to intel_guc_log_control (Michal)
Return -ENODEV when log isn't initialized. (Chris)

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 5 +
 drivers/gpu/drm/i915/intel_guc_log.c | 7 +--
 drivers/gpu/drm/i915/intel_guc_log.h | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b45be0d..b511b92 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2471,10 +2471,7 @@ static int i915_guc_log_control_set(void *data, u64 val)
if (!HAS_GUC(dev_priv))
return -ENODEV;
 
-   if (!dev_priv->guc.log.vma)
-   return -EINVAL;
-
-   return i915_guc_log_control(dev_priv, val);
+   return intel_guc_log_control(_priv->guc, val);
 }
 
 DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index d10ec53..cb10f7a 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -637,13 +637,16 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(>log.vma);
 }
 
-int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val)
+int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
 {
-   struct intel_guc *guc = _priv->guc;
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
bool enable_logging = control_val > 0;
u32 verbosity;
int ret;
 
+   if (!guc->log.vma)
+   return -ENODEV;
+
BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h 
b/drivers/gpu/drm/i915/intel_guc_log.h
index c638b9d..dab0e94 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -64,7 +64,7 @@ struct intel_guc_log {
 void intel_guc_log_init_early(struct intel_guc *guc);
 int intel_guc_log_relay_create(struct intel_guc *guc);
 void intel_guc_log_relay_destroy(struct intel_guc *guc);
-int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val);
+int intel_guc_log_control(struct intel_guc *guc, u64 control_val);
 void i915_guc_log_register(struct drm_i915_private *dev_priv);
 void i915_guc_log_unregister(struct drm_i915_private *dev_priv);
 
-- 
1.9.1

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/2] drm/i915: Track the number of times we have woken the GPU up

[Chris Wilson]

Quoting Patchwork (2018-01-24 15:23:14)
> == Series Details ==
> 
> Series: series starting with [v3,1/2] drm/i915: Track the number of times we 
> have woken the GPU up
> URL   : https://patchwork.freedesktop.org/series/37030/
> State : failure
> 
> == Summary ==
> 
> Test kms_flip:
> Subgroup wf_vblank-ts-check-interruptible:
> pass   -> FAIL   (shard-hsw) fdo#100368 +1
> Subgroup modeset-vs-vblank-race:
> pass   -> FAIL   (shard-hsw) fdo#103060
> Subgroup 2x-plain-flip-fb-recreate-interruptible:
> pass   -> FAIL   (shard-hsw)
> Subgroup 2x-vblank-vs-modeset-suspend-interruptible:
> pass   -> INCOMPLETE (shard-hsw) fdo#104750
> Test perf:
> Subgroup blocking:
> pass   -> FAIL   (shard-hsw) fdo#102252
> Subgroup oa-exponents:
> pass   -> FAIL   (shard-apl) fdo#102254
> Subgroup buffer-fill:
> fail   -> PASS   (shard-apl) fdo#103755
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
> pass   -> FAIL   (shard-snb) fdo#101623
> Test gem_exec_suspend:
> Subgroup basic-s3:
> skip   -> PASS   (shard-snb) fdo#103880

And pushed. Thanks for review and suggested improvements. I'm sure we
will be able to find more things we can do upon idling, and think of
interesting ways to detect idling outside of the GT context, but for now
I think this is a worthy initial improvement by itself.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3,1/2] drm/i915: Track the number of times we have woken the GPU up

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915: Track the number of times we 
have woken the GPU up
URL   : https://patchwork.freedesktop.org/series/37030/
State : failure

== Summary ==

Test kms_flip:
Subgroup wf_vblank-ts-check-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Subgroup modeset-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup 2x-vblank-vs-modeset-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw) fdo#104750
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Subgroup buffer-fill:
fail   -> PASS   (shard-apl) fdo#103755
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test gem_exec_suspend:
Subgroup basic-s3:
skip   -> PASS   (shard-snb) fdo#103880

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#104750 https://bugs.freedesktop.org/show_bug.cgi?id=104750
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103880 https://bugs.freedesktop.org/show_bug.cgi?id=103880

shard-apltotal:2753 pass:1716 dwarn:1   dfail:0   fail:23  skip:1013 
time:14071s
shard-hswtotal:2704 pass:1694 dwarn:1   dfail:0   fail:15  skip:992 
time:14953s
shard-snbtotal:2753 pass:1318 dwarn:1   dfail:0   fail:11  skip:1423 
time:7913s
Blacklisted hosts:
shard-kbltotal:2736 pass:1821 dwarn:1   dfail:0   fail:24  skip:889 
time:10694s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Use enum plane_id for frontbuffer tracking

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 04:16:19AM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-01-23 at 20:33 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Replace the ad-hoc plane indexing scheme used by the frontbuffer
> > tracking with enum plane_id.
> > 
> > The old video overlay not being part of the plane_id namespace
> > will just be given the high bit.
> 
> I'm curious why the bit corresponding to PLANE_SPRITE0 is not re-used
> for the overlay. From a cursory read seems like platforms with overlays
> and sprites are mutually exclusive.

Currently yes, but maybe not in the future. I still have dreams of
exposing all the planes on these platforms, which would mean having
at least one sprite plane that's not the video overlay. I haven't
really figured out how to make it all work out nicely with enum
plane_id though as that's a per-pipe thing and the planes on the
old hw are not necessarily tied to a single pipe. Perhaps one
option would be to assign the plane ids globally, ie. PRIMARY==A,
PLANE1==B, PLANE2==C, etc. Not sure if that would actually work out
though.

> 
> Related question, how different is this overlay from the sprite planes?

Very different. I would like to expose it as a drm_plane eventually,
but there's a bit of actual work involved to convert the overlay
register updates to use mmio, and to handle the render cache
reconfiguration (which still involves stuffing MI commands to the
ring) in a decent way.

I do have a basic mmio conversion sitting on some branch somewhere,
but I don't think I got it to look as nice as I'd like. Plus it's
probably bitrotted enough by now that it needs some rework anyway.

> 
> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 11 +++
> >  drivers/gpu/drm/i915/intel_display.c |  4 ++--
> >  drivers/gpu/drm/i915/intel_fbc.c |  2 +-
> >  drivers/gpu/drm/i915/intel_sprite.c  |  4 +++-
> >  4 files changed, 9 insertions(+), 12 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8333692dac5a..bd545b1c9546 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2404,16 +2404,11 @@ enum hdmi_force_audio {
> >   *
> >   * We have one bit per pipe and per scanout plane type.
> >   */
> > -#define INTEL_MAX_SPRITE_BITS_PER_PIPE 5
> >  #define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
> > -#define INTEL_FRONTBUFFER_PRIMARY(pipe) \
> > -   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> > -#define INTEL_FRONTBUFFER_CURSOR(pipe) \
> > -   (1 << (1 + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > -#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
> > -   (1 << (2 + plane + (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > +#define INTEL_FRONTBUFFER(pipe, plane_id) \
> > +   (1 << ((plane_id) + INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
> > -   (1 << (2 + INTEL_MAX_SPRITE_BITS_PER_PIPE + 
> > (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe
> > +   (1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE - 1 + 
> > INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
> > (0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d585ce4c8732..3cc35add362f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13168,7 +13168,7 @@ intel_primary_plane_create(struct drm_i915_private 
> > *dev_priv, enum pipe pipe)
> > else
> > primary->i9xx_plane = (enum i9xx_plane_id) pipe;
> > primary->id = PLANE_PRIMARY;
> > -   primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
> > +   primary->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, primary->id);
> > primary->check_plane = intel_check_primary_plane;
> >  
> > if (INTEL_GEN(dev_priv) >= 9) {
> > @@ -13289,7 +13289,7 @@ intel_cursor_plane_create(struct drm_i915_private 
> > *dev_priv,
> > cursor->pipe = pipe;
> > cursor->i9xx_plane = (enum i9xx_plane_id) pipe;
> > cursor->id = PLANE_CURSOR;
> > -   cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
> > +   cursor->frontbuffer_bit = INTEL_FRONTBUFFER(pipe, cursor->id);
> >  
> > if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
> > cursor->update_plane = i845_update_cursor;
> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > b/drivers/gpu/drm/i915/intel_fbc.c
> > index 9dc2b8b5f2db..a8a8a80497a8 100644
> > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > @@ -1373,7 +1373,7 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
> >  
> > for_each_pipe(dev_priv, pipe) {
> > fbc->possible_framebuffer_bits |=
> > -   INTEL_FRONTBUFFER_PRIMARY(pipe);
> > +   INTEL_FRONTBUFFER(pipe, 

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915: add query uAPI

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-24 12:03:46)
> 
> On 23/01/2018 14:17, Lionel Landwerlin wrote:
> > Hi all,
> > 
> > I've been trying to expose some information to userspace about the fused 
> > parts of the GPU.
> > This is the 4th attempt at getting this upstream, here are the previous 
> > ones :
> >      https://patchwork.freedesktop.org/patch/185959/
> >      https://patchwork.freedesktop.org/series/33436/
> >      https://patchwork.freedesktop.org/series/33950/
> > 
> > This last iteration was based upon some direction by Daniel : 
> > https://lists.freedesktop.org/archives/dri-devel/2017-December/160162.html
> > There was, I think, a fair point about having this working in 
> > environments where sysfs (mechanism used in the 3rd iteration) is not 
> > available (containers).
> > 
> > Following some discussion on IRC, it seems Joonas would like this 
> > rewritten in a such way that we essentially drop the generic mechanism 
> > introduced in this patch, and instead go for an additional ioctl() on 
> > the drm fd just for querying the state of a fused part of 
> > slice/subslice/eus.
> > The proposal is to have a single struct like :
> > 
> > struct drm_i915_topology {
> >     /* All field are in/out */
> >     int slice;
> >     int subslice;
> >     int eu;
> > 
> >     int enabled;
> > };
> > 
> > You would let the slice field to -1 and then the kernel would fill it 
> > with the max slice value. Same for subslice (with a valid slice value) 
> > and eu.
> > When querying with slice = 0, and all other fields to -1, the kernel 
> > would fill the enabled value with 0 or 1.
> > Essentially that would mean that an application wanting to query the 
> > state of all of the EUs would have to go through them one by one (which 
> > would be about ~100 ioctl() on SKL GT4 for example).
> > 
> > Apart from the fact that we'll probably end up adding another ioctl() 
> > for engine discovery, I don't have any problem with what Joonas is 
> > proposing.
> > It's just a bit annoying this comes up on the 4th rewrite.
> > I really wouldn't like to rewrite this one more time and get turned down 
> > because this isn't to the taste of one of the reviewer.
> > So my question is : Is everybody happy with what Joonas is proposing?
> > Anybody in favor of having a generic mechanism?
> 
> I am not very keen on this counter-proposal for two reasons.
> 
> First is that I think is a bit inelegant to have to query so many times 
> just to get the full topology out. If this ends in some library, we may 
> end up running this on every trivial client startup.
> 
> Secondly, it is kind of dispatcher in it's own right. Since the 
> operation mode will depend on the combination of field values. As such a 
> generic, or at least a more explicit, dispatcher, like the proposed 
> i915_query_ioctl sounds cleaner to me.
> 
> I take the point we can't guess how many other users we will have for it 
> in the future. So there is a little bit of a risk of adding something 
> generic which won't be used a lot in the future.
> 
> Because apart from the three queries Lionel needs, I would be adding an 
> engine info query and potentially, depending on userspace interest, 
> engine queue depths. So that would be a maximum of five queries I am 
> aware of would use the generic framework. Maybe too little, or maybe 
> good enough for a start?

Another use case would be a single shot method to gather all GETPARAMs.

There's a lot of too'ing and fro'ing at the start of mesa trying to
determine all of the kernel's capabilities, which more or less come down
to a long series of parsing GETPARAM results. Bundling all of those up
into a single ioctl seems attractive to me (bonus for it being properly
defined and not a compat nightmare).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-24 13:09:37)
> 
> On 22/01/2018 15:41, Chris Wilson wrote:
> > If we remember to cancel the signaler on a request when retiring it
> > (after we know that the request has been signaled), we do not need to
> > carry an additional request in the signaler itself. This prevents an
> > issue whereby the signaler threads may be delayed and hold on to
> > thousands of request references, causing severe memory fragmentation and
> > premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
> > and frequent use of inter-engine fences).
> 
> What is starving the signaler thread, which is set to SCHED_FIFO, and 
> can't be tasklets on SNB?

Interrupts. MI_USER_INTERRUPT to be precise, but we have to check all
the other sources on snb as well.

> Before I actually start revieweing the code, which I'd rather avoid :) :
> 
> Is it just not able to process enough requests in it's time-slice 
> (need_resched) so is falling behind? It would be surprising since I 
> would expect it to be much lighter wait processing there, per request, 
> than on the submission paths.

The conclusion is a bit odd, but more or less it's just a pathological
case where interrupts + rt task are contending for one cpu with
submission proceeding on another. Making the signaler lighter was the
intention of the rest of the series, but this patch by itself prevents
the runaway references.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915: Track the number of times we have woken the GPU up

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Track the number of times we 
have woken the GPU up
URL   : https://patchwork.freedesktop.org/series/37026/
State : success

== Summary ==

Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-apl) fdo#102254
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Test gem_exec_suspend:
Subgroup basic-s3:
skip   -> PASS   (shard-snb) fdo#103880

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

shard-apltotal:2753 pass:1715 dwarn:1   dfail:0   fail:24  skip:1013 
time:13995s
shard-hswtotal:2753 pass:1724 dwarn:1   dfail:0   fail:12  skip:1015 
time:15356s
shard-snbtotal:2753 pass:1317 dwarn:1   dfail:0   fail:12  skip:1423 
time:7936s
Blacklisted hosts:
shard-kbltotal:2753 pass:1835 dwarn:2   dfail:0   fail:24  skip:892 
time:11093s

== Logs ==

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

Re: [Intel-gfx] REGRESSION in c5552fde102f ("nvme: Enable autonomous power state transitions")

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 01:42:08PM +0200, Jani Nikula wrote:
> 
> Hi Andy, all -
> 
> So this is an odd one.
> 
> I'm getting display FIFO underruns in a very specific setting: Laptop
> display switched off, and an external display connected. Other
> combinations work fine.
> 
> I've bisected this to c5552fde102f ("nvme: Enable autonomous power state
> transitions"), and, being baffled by the result, carefully checked
> this. There are no problems when running c5552fde102f^, with
> nvme_core.default_ps_max_latency_us=0, or after 'echo 0 >
> pm_qos_latency_tolerance_us'. With the last one, restoring the original
> value of 10 brings the underruns back.
> 
> I have no idea what the root cause mechanism here is, but the bisect is
> correct. Perhaps something to do with timing. I'd be happy to provide
> further details.
> 
> I see that you have quirked one Samsung device. Incidentally, this
> Lenovo Yoga 910 (Kabylake, SunrisePoint LP PCH) also has a Samsung NVMe
> device, just a different one. Details below. I don't know what the
> failure mode in the quirked one is, so I don't know if this could be the
> same issue.

My first gut feeling would be that by allowing the nvme to go to sleep
we're gettting into some deeper power saving state, which then causes
display underruns. How does the package c-state residency look
before/after the commit?

I might be wrong too of course. IIRC there were plenty of display
flicker issues on SKL at least that were magically fixed by unknown
magic in BIOS updates.

> 
> BR,
> Jani.
> 
> 
> $ lspci -vvnn -s 02:00.0
> 02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd 
> Device [144d:a804] (prog-if 02 [NVM Express])
>   Subsystem: Samsung Electronics Co Ltd Device [144d:a801]
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 16
>   NUMA node: 0
>   Region 0: Memory at a120 (64-bit, non-prefetchable) [size=16K]
>   Capabilities: [40] Power Management version 3
>   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>   Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>   Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
>   Address:   Data: 
>   Capabilities: [70] Express (v2) Endpoint, MSI 00
>   DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 
> unlimited, L1 unlimited
>   ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ 
> SlotPowerLimit 25.000W
>   DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ 
> Unsupported+
>   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>   MaxPayload 256 bytes, MaxReadReq 512 bytes
>   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
> TransPend-
>   LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency 
> L0s unlimited, L1 <64us
>   ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
>   LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
>   ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
>   LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- 
> BWMgmt- ABWMgmt-
>   DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, 
> OBFF Not Supported
>   DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, 
> OBFF Disabled
>   LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
>Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>Compliance De-emphasis: -6dB
>   LnkSta2: Current De-emphasis Level: -6dB, 
> EqualizationComplete+, EqualizationPhase1+
>EqualizationPhase2+, EqualizationPhase3+, 
> LinkEqualizationRequest-
>   Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
>   Vector table: BAR=0 offset=3000
>   PBA: BAR=0 offset=2000
>   Capabilities: [100 v2] Advanced Error Reporting
>   UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>   UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>   UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>   CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>   CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>   AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>   Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00
>   

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Ignore VBT request for know invalid DDC pin.

[Ville Syrjälä]

On Wed, Jan 24, 2018 at 12:03:12PM +0200, Jani Nikula wrote:
> On Wed, 24 Jan 2018, Kai Heng Feng  wrote:
> > Hi,
> >
> >> On 24 Jan 2018, at 5:25 PM, Jani Nikula  
> >> wrote:
> >> A bit too fast IMO. The bug report doesn't include the vbt dump which
> >> you should *always* look at before making workarounds for vbt.
> >
> > I didn’t have access to the machine in question until now, I can provide
> > VBT dump as well as i915_opregion requested by Ville.
> >
> > But how do I make a VBT dump?
> 
> Copy /sys/kernel/debug/dri/0/i915_vbt
> 
> I don't think the opregion will be necessary, I think Ville asks for it
> for the vbt, which on most platforms is contained in the opregion.

Old habits...

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

Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Tvrtko Ursulin]

On 22/01/2018 15:41, Chris Wilson wrote:

If we remember to cancel the signaler on a request when retiring it
(after we know that the request has been signaled), we do not need to
carry an additional request in the signaler itself. This prevents an
issue whereby the signaler threads may be delayed and hold on to
thousands of request references, causing severe memory fragmentation and
premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL
and frequent use of inter-engine fences).


What is starving the signaler thread, which is set to SCHED_FIFO, and 
can't be tasklets on SNB?

Before I actually start revieweing the code, which I'd rather avoid :) :

Is it just not able to process enough requests in it's time-slice 
(need_resched) so is falling behind? It would be surprising since I 
would expect it to be much lighter wait processing there, per request, 
than on the submission paths.


Regards,

Tvrtko


Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem_request.c  |   6 +-
  drivers/gpu/drm/i915/intel_breadcrumbs.c | 149 +--
  2 files changed, 85 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..e4eca6ba0d05 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -441,7 +441,10 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
spin_lock_irq(>lock);
if (request->waitboost)
atomic_dec(>i915->gt_pm.rps.num_waiters);
-   dma_fence_signal_locked(>fence);
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags))
+   dma_fence_signal_locked(>fence);
+   if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+   intel_engine_cancel_signaling(request);
spin_unlock_irq(>lock);
  
  	i915_priotree_fini(request->i915, >priotree);

@@ -738,6 +741,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
  
  	/* No zalloc, must clear what we need by hand */

req->global_seqno = 0;
+   req->signaling.wait.seqno = 0;
req->file_priv = NULL;
req->batch = NULL;
req->capture_list = NULL;
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 86acac010bb8..e3667dc1e96d 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -235,7 +235,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs 
*engine)
struct intel_wait *wait, *n;
  
  	if (!b->irq_armed)

-   goto wakeup_signaler;
+   return;
  
  	/*

 * We only disarm the irq when we are idle (all requests completed),
@@ -260,14 +260,6 @@ void intel_engine_disarm_breadcrumbs(struct 
intel_engine_cs *engine)
b->waiters = RB_ROOT;
  
  	spin_unlock_irq(>rb_lock);

-
-   /*
-* The signaling thread may be asleep holding a reference to a request,
-* that had its signaling cancelled prior to being preempted. We need
-* to kick the signaler, just in case, to release any such reference.
-*/
-wakeup_signaler:
-   wake_up_process(b->signaler);
  }
  
  static bool use_fake_irq(const struct intel_breadcrumbs *b)

@@ -644,6 +636,62 @@ static void signaler_set_rtpriority(void)
 sched_setscheduler_nocheck(current, SCHED_FIFO, );
  }
  
+static void __intel_engine_remove_signal(struct intel_engine_cs *engine,

+struct drm_i915_gem_request *request)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+
+   lockdep_assert_held(>rb_lock);
+
+   /*
+* Wake up all other completed waiters and select the
+* next bottom-half for the next user interrupt.
+*/
+   __intel_engine_remove_wait(engine, >signaling.wait);
+
+   /*
+* Find the next oldest signal. Note that as we have
+* not been holding the lock, another client may
+* have installed an even older signal than the one
+* we just completed - so double check we are still
+* the oldest before picking the next one.
+*/
+   if (request->signaling.wait.seqno) {
+   if (request == rcu_access_pointer(b->first_signal)) {
+   struct rb_node *rb = rb_next(>signaling.node);
+   rcu_assign_pointer(b->first_signal,
+  rb ? to_signaler(rb) : NULL);
+   }
+
+   rb_erase(>signaling.node, >signals);
+   request->signaling.wait.seqno = 0;
+   }
+}
+
+static struct drm_i915_gem_request *first_signal(struct intel_breadcrumbs *b)
+{
+   /*
+* See the big warnings for i915_gem_active_get_rcu() and similarly
+* for dma_fence_get_rcu_safe() that explain the 

[Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] tests/testdisplay.c: add support to test modes with aspect ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch adds the support to test the modes with aspect ratios.
If the kernel supports the aspect ratio capabilities, the modes
with aspect ratios are set one by one.

This test is a means to verify the drm patch series :Aspect ratio
support in DRM : https://patchwork.freedesktop.org/series/33984/

Signed-off-by: Ankit Nautiyal 
---
 tests/testdisplay.c | 104 ++--
 1 file changed, 100 insertions(+), 4 deletions(-)

diff --git a/tests/testdisplay.c b/tests/testdisplay.c
index b0156c5..910e395 100644
--- a/tests/testdisplay.c
+++ b/tests/testdisplay.c
@@ -73,13 +73,22 @@
 #define Yb_OPT  3
 #define Yf_OPT  4
 
+#ifndef DRM_CLIENT_CAP_ASPECT_RATIO
+/**
+ * Taken from drm-uapi/drm.h
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will expose aspect ratio to userspace
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+#endif
 static int tio_fd;
 struct termios saved_tio;
 
 drmModeRes *resources;
 int drm_fd, modes;
 int test_all_modes = 0, test_preferred_mode = 0, force_mode = 0, test_plane,
-test_stereo_modes;
+test_stereo_modes, test_aspect_ratio_modes = 0;
 uint64_t tiling = LOCAL_DRM_FORMAT_MOD_NONE;
 int sleep_between_modes = 5;
 int do_dpms = 0; /* This aliases to DPMS_ON */
@@ -443,6 +452,62 @@ set_stereo_mode(struct connector *c)
drmModeFreeConnector(c->connector);
 }
 
+static void
+set_aspect_ratio_mode(struct connector *c)
+{
+   int i, n;
+   uint32_t fb_id;
+   struct igt_fb fb_info = { };
+
+
+   if (specified_mode_num != -1)
+   n = 1;
+   else
+   n = c->connector->count_modes;
+
+   for (i = 0; i < n; i++) {
+   if (specified_mode_num == -1)
+   c->mode = c->connector->modes[i];
+
+   if (!c->mode_valid)
+   continue;
+
+   if (!(c->mode.flags & DRM_MODE_FLAG_PIC_AR_MASK))
+   continue;
+
+   igt_info("CRTC(%u): [%d]", c->crtc, i);
+   kmstest_dump_mode(>mode);
+   width = c->mode.hdisplay;
+   height = c->mode.vdisplay;
+
+   fb_id = igt_create_pattern_fb(drm_fd, width, height,
+   igt_bpp_depth_to_drm_format(bpp, depth),
+   tiling, _info);
+   paint_output_info(c, _info);
+   paint_color_key(_info);
+
+   kmstest_dump_mode(>mode);
+   igt_warn_on_f(drmModeSetCrtc(drm_fd, c->crtc, fb_id, 0, 0, 
>id, 1, >mode),
+ "failed to set mode (%dx%d@%dHz): %s\n", width, 
height, c->mode.vrefresh, strerror(errno));
+   if (qr_code) {
+   set_single();
+   pause();
+   } else if (sleep_between_modes)
+   sleep(sleep_between_modes);
+
+   if (do_dpms) {
+   kmstest_set_connector_dpms(drm_fd, c->connector,
+  DRM_MODE_DPMS_OFF);
+   sleep(sleep_between_modes);
+   kmstest_set_connector_dpms(drm_fd, c->connector,
+  DRM_MODE_DPMS_ON);
+   }
+
+   igt_remove_fb(drm_fd, _info);
+   }
+   drmModeFreeEncoder(c->encoder);
+   drmModeFreeConnector(c->connector);
+}
 /*
  * Re-probe outputs and light up as many as possible.
  *
@@ -517,18 +582,39 @@ int update_display(bool probe)
}
}
 
+   if (test_aspect_ratio_modes) {
+   for (c = 0; c < resources->count_connectors; c++) {
+   struct connector *connector = [c];
+
+   connector->id = resources->connectors[c];
+   if (specified_disp_id != -1 &&
+   connector->id != specified_disp_id)
+   continue;
+
+   connector_find_preferred_mode(connector->id,
+ -1UL,
+ specified_mode_num,
+ connector, probe);
+   if (!connector->mode_valid)
+   continue;
+
+   set_aspect_ratio_mode(connector);
+   }
+   }
+
free(connectors);
drmModeFreeResources(resources);
return 1;
 }
 
-static char optstr[] = "3hiaf:s:d:p:mrto:j:y";
+static char optstr[] = "3hziaf:s:d:p:mrto:j:y";
 
 static void __attribute__((noreturn)) usage(char *name, char opt)
 {
igt_info("usage: %s [-hiasdpmtf]\n", name);
igt_info("\t-i\tdump info\n");
igt_info("\t-a\ttest all modes\n");
+   igt_info("\t-z\ttest aspect ratio modes\n");
igt_info("\t-s\t\tsleep between each 

[Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] lib/igt_kms.c: modify kmstest_dump_mode to print aspect ratio of a mode

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch adds the support to print the aspect ratio of the modes
(if provided) along with other mode information.

Signed-off-by: Ankit Nautiyal 
---
 lib/igt_kms.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index eb57f4a..585f94d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -56,6 +56,14 @@
 #include "igt_sysfs.h"
 #include "sw_sync.h"
 
+#ifndef DRM_MODE_FLAG_PIC_AR_64_27
+#define DRM_MODE_FLAG_PIC_AR_64_27 (3<<19)
+#endif
+
+#ifndef DRM_MODE_FLAG_PIC_AR_256_135
+#define DRM_MODE_FLAG_PIC_AR_256_135 (4<<19)
+#endif
+
 /**
  * SECTION:igt_kms
  * @short_description: Kernel modesetting support library
@@ -491,6 +499,22 @@ static const char *mode_stereo_name(const drmModeModeInfo 
*mode)
}
 }
 
+static const char *mode_aspect_name(const drmModeModeInfo *mode)
+{
+   switch (mode->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   return "4:3";
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   return "16:9";
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   return "64:27";
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   return "256:135";
+   default:
+   return NULL;
+   }
+}
+
 /**
  * kmstest_dump_mode:
  * @mode: libdrm mode structure
@@ -500,8 +524,9 @@ static const char *mode_stereo_name(const drmModeModeInfo 
*mode)
 void kmstest_dump_mode(drmModeModeInfo *mode)
 {
const char *stereo = mode_stereo_name(mode);
+   const char *aspect_ratio = mode_aspect_name(mode);
 
-   igt_info("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s%s%s\n",
+   igt_info("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s%s%s %s%s%s\n",
 mode->name, mode->vrefresh,
 mode->hdisplay, mode->hsync_start,
 mode->hsync_end, mode->htotal,
@@ -509,7 +534,9 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
 mode->vsync_end, mode->vtotal,
 mode->flags, mode->type, mode->clock,
 stereo ? " (3D:" : "",
-stereo ? stereo : "", stereo ? ")" : "");
+stereo ? stereo : "", stereo ? ")" : "",
+aspect_ratio ? " (Pixel Aspect Ratio:" : "",
+aspect_ratio ? aspect_ratio : "", aspect_ratio ? ")" : "");
 }
 
 /**
-- 
2.7.4

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

[Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] Test modes with aspect ratios

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch series provides a means to test the aspect ratio support
in DRM layer.
https://patchwork.freedesktop.org/series/33984/
Patch 1: adds support to print aspect ratio information for a mode.
Patch 2: modifies the testdisplay to test modes with aspect ratios

Ankit Nautiyal (2):
  lib/igt_kms.c: modify kmstest_dump_mode to print aspect ratio of a
mode
  tests/testdisplay.c: add support to test modes with aspect ratio

 lib/igt_kms.c   |  31 +++-
 tests/testdisplay.c | 104 ++--
 2 files changed, 129 insertions(+), 6 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915: add query uAPI

[Tvrtko Ursulin]

On 23/01/2018 14:17, Lionel Landwerlin wrote:

Hi all,

I've been trying to expose some information to userspace about the fused 
parts of the GPU.
This is the 4th attempt at getting this upstream, here are the previous 
ones :

     https://patchwork.freedesktop.org/patch/185959/
     https://patchwork.freedesktop.org/series/33436/
     https://patchwork.freedesktop.org/series/33950/

This last iteration was based upon some direction by Daniel : 
https://lists.freedesktop.org/archives/dri-devel/2017-December/160162.html
There was, I think, a fair point about having this working in 
environments where sysfs (mechanism used in the 3rd iteration) is not 
available (containers).


Following some discussion on IRC, it seems Joonas would like this 
rewritten in a such way that we essentially drop the generic mechanism 
introduced in this patch, and instead go for an additional ioctl() on 
the drm fd just for querying the state of a fused part of 
slice/subslice/eus.

The proposal is to have a single struct like :

struct drm_i915_topology {
    /* All field are in/out */
    int slice;
    int subslice;
    int eu;

    int enabled;
};

You would let the slice field to -1 and then the kernel would fill it 
with the max slice value. Same for subslice (with a valid slice value) 
and eu.
When querying with slice = 0, and all other fields to -1, the kernel 
would fill the enabled value with 0 or 1.
Essentially that would mean that an application wanting to query the 
state of all of the EUs would have to go through them one by one (which 
would be about ~100 ioctl() on SKL GT4 for example).


Apart from the fact that we'll probably end up adding another ioctl() 
for engine discovery, I don't have any problem with what Joonas is 
proposing.

It's just a bit annoying this comes up on the 4th rewrite.
I really wouldn't like to rewrite this one more time and get turned down 
because this isn't to the taste of one of the reviewer.

So my question is : Is everybody happy with what Joonas is proposing?
Anybody in favor of having a generic mechanism?


I am not very keen on this counter-proposal for two reasons.

First is that I think is a bit inelegant to have to query so many times 
just to get the full topology out. If this ends in some library, we may 
end up running this on every trivial client startup.


Secondly, it is kind of dispatcher in it's own right. Since the 
operation mode will depend on the combination of field values. As such a 
generic, or at least a more explicit, dispatcher, like the proposed 
i915_query_ioctl sounds cleaner to me.


I take the point we can't guess how many other users we will have for it 
in the future. So there is a little bit of a risk of adding something 
generic which won't be used a lot in the future.


Because apart from the three queries Lionel needs, I would be adding an 
engine info query and potentially, depending on userspace interest, 
engine queue depths. So that would be a maximum of five queries I am 
aware of would use the generic framework. Maybe too little, or maybe 
good enough for a start?


Alternative would be to go with dedicated ioctls for all of these. It 
would work for my needs, but I am not sure if Lionel can massage the 
GPU/EU topology into one, or at least fewer than three, nicer ioctls 
(Not the kind which needs to be called hundred times to get the complete 
state.).


Regards,

Tvrtko



On 22/01/18 08:21, Lionel Landwerlin wrote:

There are a number of information that are readable from hardware
registers and that we would like to make accessible to userspace. One
particular example is the topology of the execution units (how are
execution units grouped in subslices and slices and also which ones
have been fused off for die recovery).

At the moment the GET_PARAM ioctl covers some basic needs, but
generally is only able to return a single value for each defined
parameter. This is a bit problematic with topology descriptions which
are array/maps of available units.

This change introduces a new ioctl that can deal with requests to fill
structures of potentially variable lengths. The user is expected fill
a query with length fields set at 0 on the first call, the kernel then
sets the length fields to the their expected values. A second call to
the kernel with length fields at their expected values will trigger a
copy of the data to the pointed memory locations.

The scope of this uAPI is only to provide information to userspace,
not to allow configuration of the device.

v2: Simplify dispatcher code iteration (Tvrtko)
 Tweak uapi drm_i915_query_item structure (Tvrtko)

v3: Rename pad fields into flags (Chris)
 Return error on flags field != 0 (Chris)
 Only copy length back to userspace in drm_i915_query_item (Chris)

v4: Use array of functions instead of switch (Chris)

v5: More comments in uapi (Tvrtko)
 Return query item errors in length field (All)

v6: Tweak uapi comments style to match the coding style (Lionel)

Signed-off-by: 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915: Track the number of times we have woken the GPU up

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] drm/i915: Track the number of times we 
have woken the GPU up
URL   : https://patchwork.freedesktop.org/series/37030/
State : success

== Summary ==

Series 37030v1 series starting with [v3,1/2] drm/i915: Track the number of 
times we have woken the GPU up
https://patchwork.freedesktop.org/api/1.0/series/37030/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
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:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:467s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:458s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:512s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:391s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:402s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:466s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:498s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:580s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:434s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:508s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:526s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:484s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:421s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-glk-dsi   total:288  pass:176  dwarn:1   dfail:4   fail:0   skip:107 
time:319s

ef2011c6380601730d0083e77c386aaa2d8c6673 drm-tip: 2018y-01m-24d-09h-45m-08s UTC 
integration manifest
abc5510b184f drm/i915: Shrink the GEM kmem_caches upon idling
23d058ee9662 drm/i915: Track the number of times we have woken the GPU up

== Logs ==

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

Re: [Intel-gfx] REGRESSION in c5552fde102f ("nvme: Enable autonomous power state transitions")

[Jani Nikula]

[Fixed Ville's address, sorry for the extra noise.]

On Wed, 24 Jan 2018, Jani Nikula  wrote:
> Hi Andy, all -
>
> So this is an odd one.
>
> I'm getting display FIFO underruns in a very specific setting: Laptop
> display switched off, and an external display connected. Other
> combinations work fine.
>
> I've bisected this to c5552fde102f ("nvme: Enable autonomous power state
> transitions"), and, being baffled by the result, carefully checked
> this. There are no problems when running c5552fde102f^, with
> nvme_core.default_ps_max_latency_us=0, or after 'echo 0 >
> pm_qos_latency_tolerance_us'. With the last one, restoring the original
> value of 10 brings the underruns back.
>
> I have no idea what the root cause mechanism here is, but the bisect is
> correct. Perhaps something to do with timing. I'd be happy to provide
> further details.
>
> I see that you have quirked one Samsung device. Incidentally, this
> Lenovo Yoga 910 (Kabylake, SunrisePoint LP PCH) also has a Samsung NVMe
> device, just a different one. Details below. I don't know what the
> failure mode in the quirked one is, so I don't know if this could be the
> same issue.
>
> BR,
> Jani.
>
>
> $ lspci -vvnn -s 02:00.0
> 02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd 
> Device [144d:a804] (prog-if 02 [NVM Express])
>   Subsystem: Samsung Electronics Co Ltd Device [144d:a801]
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx+
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-  SERR-Latency: 0, Cache Line Size: 64 bytes
>   Interrupt: pin A routed to IRQ 16
>   NUMA node: 0
>   Region 0: Memory at a120 (64-bit, non-prefetchable) [size=16K]
>   Capabilities: [40] Power Management version 3
>   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>   Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
>   Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
>   Address:   Data: 
>   Capabilities: [70] Express (v2) Endpoint, MSI 00
>   DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s 
> unlimited, L1 unlimited
>   ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ 
> SlotPowerLimit 25.000W
>   DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ 
> Unsupported+
>   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ FLReset-
>   MaxPayload 256 bytes, MaxReadReq 512 bytes
>   DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ 
> TransPend-
>   LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L1, Exit Latency 
> L0s unlimited, L1 <64us
>   ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
>   LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
>   ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
>   LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- 
> BWMgmt- ABWMgmt-
>   DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+, 
> OBFF Not Supported
>   DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, 
> OBFF Disabled
>   LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
>Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>Compliance De-emphasis: -6dB
>   LnkSta2: Current De-emphasis Level: -6dB, 
> EqualizationComplete+, EqualizationPhase1+
>EqualizationPhase2+, EqualizationPhase3+, 
> LinkEqualizationRequest-
>   Capabilities: [b0] MSI-X: Enable+ Count=33 Masked-
>   Vector table: BAR=0 offset=3000
>   PBA: BAR=0 offset=2000
>   Capabilities: [100 v2] Advanced Error Reporting
>   UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>   UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
>   UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
>   CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
>   CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
>   AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
>   Capabilities: [148 v1] Device Serial Number 00-00-00-00-00-00-00-00
>   Capabilities: [158 v1] Power Budgeting 
>   Capabilities: [168 v1] #19
>   Capabilities: [188 v1] Latency Tolerance Reporting
>   Max snoop latency: 3145728ns
>   Max no snoop latency: 3145728ns
>   Capabilities: [190 v1] L1 PM Substates
>   L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Track the number of times we have woken the GPU up

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Track the number of times we 
have woken the GPU up
URL   : https://patchwork.freedesktop.org/series/37026/
State : success

== Summary ==

Series 37026v1 series starting with [v2,1/2] drm/i915: Track the number of 
times we have woken the GPU up
https://patchwork.freedesktop.org/api/1.0/series/37026/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:496s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:484s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:476s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:518s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:398s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:404s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:453s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:456s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:500s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:509s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:414s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:513s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:400s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:468s
fi-byt-n2820 failed to collect. IGT log at Patchwork_7766/fi-byt-n2820/igt.log

ef2011c6380601730d0083e77c386aaa2d8c6673 drm-tip: 2018y-01m-24d-09h-45m-08s UTC 
integration manifest
591cc1c83a13 drm/i915: Shrink the GEM kmem_caches upon idling
ac442515a418 drm/i915: Track the number of times we have woken the GPU up

== Logs ==

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

[Intel-gfx] REGRESSION in c5552fde102f ("nvme: Enable autonomous power state transitions")

[Jani Nikula]

Hi Andy, all -

So this is an odd one.

I'm getting display FIFO underruns in a very specific setting: Laptop
display switched off, and an external display connected. Other
combinations work fine.

I've bisected this to c5552fde102f ("nvme: Enable autonomous power state
transitions"), and, being baffled by the result, carefully checked
this. There are no problems when running c5552fde102f^, with
nvme_core.default_ps_max_latency_us=0, or after 'echo 0 >
pm_qos_latency_tolerance_us'. With the last one, restoring the original
value of 10 brings the underruns back.

I have no idea what the root cause mechanism here is, but the bisect is
correct. Perhaps something to do with timing. I'd be happy to provide
further details.

I see that you have quirked one Samsung device. Incidentally, this
Lenovo Yoga 910 (Kabylake, SunrisePoint LP PCH) also has a Samsung NVMe
device, just a different one. Details below. I don't know what the
failure mode in the quirked one is, so I don't know if this could be the
same issue.

BR,
Jani.


$ lspci -vvnn -s 02:00.0
02:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd 
Device [144d:a804] (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd Device [144d:a801]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [168 v1] #19
Capabilities: [188 v1] Latency Tolerance Reporting
Max snoop latency: 3145728ns
Max no snoop latency: 3145728ns
Capabilities: [190 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ 
L1_PM_Substates+
  PortCommonModeRestoreTime=10us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
   T_CommonMode=0us LTR1.2_Threshold=163840ns
L1SubCtl2: T_PwrOn=44us
Kernel driver in use: nvme
Kernel modules: nvme


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Chris Wilson]

When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.

v3: Defer until an rcu grace period after we idle.
v4: Think about epoch wraparound and how likely that is.
v5: Use I915_EPOCH_INVALID magic.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 79 +
 1 file changed, 79 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..ba43482d0a0c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3334,6 +3334,65 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
 }
 
+static void shrink_caches(struct drm_i915_private *i915)
+{
+   /*
+* kmem_cache_shrink() discards empty slabs and reorders partially
+* filled slabs to prioritise allocating from the mostly full slabs,
+* with the aim of reducing fragmentation.
+*/
+   kmem_cache_shrink(i915->priorities);
+   kmem_cache_shrink(i915->dependencies);
+   kmem_cache_shrink(i915->requests);
+   kmem_cache_shrink(i915->luts);
+   kmem_cache_shrink(i915->vmas);
+   kmem_cache_shrink(i915->objects);
+}
+
+struct sleep_rcu_work {
+   union {
+   struct rcu_head rcu;
+   struct work_struct work;
+   };
+   struct drm_i915_private *i915;
+   unsigned int epoch;
+};
+
+static inline bool
+same_epoch(struct drm_i915_private *i915, unsigned int epoch)
+{
+   /*
+* There is a small chance that the epoch wrapped since we started
+* sleeping. If we assume that epoch is at least a u32, then it will
+* take at least 2^32 * 100ms for it to wrap, or about 326 years.
+*/
+   return epoch == READ_ONCE(i915->gt.epoch);
+}
+
+static void __sleep_work(struct work_struct *work)
+{
+   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
+   struct drm_i915_private *i915 = s->i915;
+   unsigned int epoch = s->epoch;
+
+   kfree(s);
+   if (same_epoch(i915, epoch))
+   shrink_caches(i915);
+}
+
+static void __sleep_rcu(struct rcu_head *rcu)
+{
+   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
+   struct drm_i915_private *i915 = s->i915;
+
+   if (same_epoch(i915, s->epoch)) {
+   INIT_WORK(>work, __sleep_work);
+   queue_work(i915->wq, >work);
+   } else {
+   kfree(s);
+   }
+}
+
 static inline bool
 new_requests_since_last_retire(const struct drm_i915_private *i915)
 {
@@ -3346,6 +3405,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
+   unsigned int epoch = I915_EPOCH_INVALID;
bool rearm_hangcheck;
ktime_t end;
 
@@ -3405,6 +3465,8 @@ i915_gem_idle_work_handler(struct work_struct *work)
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
+   epoch = dev_priv->gt.epoch;
+   GEM_BUG_ON(epoch == I915_EPOCH_INVALID);
rearm_hangcheck = false;
 
if (INTEL_GEN(dev_priv) >= 6)
@@ -3421,6 +3483,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   if (same_epoch(dev_priv, epoch)) {
+   struct sleep_rcu_work *s = kmalloc(sizeof(*s), GFP_KERNEL);
+   if (s) {
+   s->i915 = dev_priv;
+   s->epoch = epoch;
+   call_rcu(>rcu, __sleep_rcu);
+   }
+   }
 }
 
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
-- 
2.15.1

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

[Intel-gfx] [PATCH v3 1/2] drm/i915: Track the number of times we have woken the GPU up

[Chris Wilson]

By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.

v2: No reason to specify precise number of bits here.
v3: Take Tvrtko's advice and reserve 0 as an invalid epoch.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
 drivers/gpu/drm/i915/i915_drv.h | 6 ++
 drivers/gpu/drm/i915/i915_gem_request.c | 2 ++
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 80dc679c0f01..65b175ac19b0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2717,7 +2717,8 @@ static int i915_runtime_pm_status(struct seq_file *m, 
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
 
-   seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
+   seq_printf(m, "GPU idle: %s (epoch %d)\n",
+  yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
   yesno(!intel_irqs_enabled(dev_priv)));
 #ifdef CONFIG_PM
@@ -3150,8 +3151,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
intel_runtime_pm_get(dev_priv);
 
-   seq_printf(m, "GT awake? %s\n",
-  yesno(dev_priv->gt.awake));
+   seq_printf(m, "GT awake? %s (epoch %d)\n",
+  yesno(dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "Global active requests: %d\n",
   dev_priv->gt.active_requests);
seq_printf(m, "CS timestamp frequency: %u kHz\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8333692dac5a..7b8cc0420206 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2312,6 +2312,12 @@ struct drm_i915_private {
 */
bool awake;
 
+   /**
+* The number of times we have woken up.
+*/
+   unsigned int epoch;
+#define I915_EPOCH_INVALID 0
+
/**
 * We leave the user IRQ off as much as possible,
 * but this means that requests will finish and never
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..c060cbfa311a 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -274,6 +274,8 @@ static void mark_busy(struct drm_i915_private *i915)
intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
 
i915->gt.awake = true;
+   if (++i915->gt.epoch == 0) /* keep 0 as invalid */
+   i915->gt.epoch = 1;
 
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Tvrtko Ursulin]

On 24/01/2018 11:03, Chris Wilson wrote:

When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.

v3: Defer until an rcu grace period after we idle.
v4: Think about epoch wraparound and how likely that is.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem.c | 78 +
  1 file changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..60b34bb98ee3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3334,6 +3334,65 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
  }
  
+static void shrink_caches(struct drm_i915_private *i915)

+{
+   /*
+* kmem_cache_shrink() discards empty slabs and reorders partially
+* filled slabs to prioritise allocating from the mostly full slabs,
+* with the aim of reducing fragmentation.
+*/
+   kmem_cache_shrink(i915->priorities);
+   kmem_cache_shrink(i915->dependencies);
+   kmem_cache_shrink(i915->requests);
+   kmem_cache_shrink(i915->luts);
+   kmem_cache_shrink(i915->vmas);
+   kmem_cache_shrink(i915->objects);
+}
+
+struct sleep_rcu_work {
+   union {
+   struct rcu_head rcu;
+   struct work_struct work;
+   };
+   struct drm_i915_private *i915;
+   unsigned int epoch;
+};
+
+static inline bool
+same_epoch(struct drm_i915_private *i915, unsigned int epoch)
+{
+   /*
+* There is a small chance that the epoch wrapped since we started
+* sleeping. If we assume that epoch is at least a u32, then it will
+* take at least 2^32 * 100ms for it to wrap, or about 326 years.
+*/
+   return epoch == READ_ONCE(i915->gt.epoch);
+}
+
+static void __sleep_work(struct work_struct *work)
+{
+   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
+   struct drm_i915_private *i915 = s->i915;
+   unsigned int epoch = s->epoch;
+
+   kfree(s);
+   if (same_epoch(i915, epoch))
+   shrink_caches(i915);
+}
+
+static void __sleep_rcu(struct rcu_head *rcu)
+{
+   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
+   struct drm_i915_private *i915 = s->i915;
+
+   if (same_epoch(i915, s->epoch)) {
+   INIT_WORK(>work, __sleep_work);
+   queue_work(i915->wq, >work);
+   } else {
+   kfree(s);
+   }
+}
+
  static inline bool
  new_requests_since_last_retire(const struct drm_i915_private *i915)
  {
@@ -3346,6 +3405,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
  {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
+   unsigned int epoch = 0;
bool rearm_hangcheck;
ktime_t end;
  
@@ -3406,6 +3466,7 @@ i915_gem_idle_work_handler(struct work_struct *work)

GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
rearm_hangcheck = false;
+   epoch = dev_priv->gt.epoch;
  
  	if (INTEL_GEN(dev_priv) >= 6)

gen6_rps_idle(dev_priv);
@@ -3421,6 +3482,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   if (same_epoch(dev_priv, epoch)) {
+   struct sleep_rcu_work *s = kmalloc(sizeof(*s), GFP_KERNEL);
+   if (s) {
+   s->i915 = dev_priv;
+   s->epoch = epoch;
+   call_rcu(>rcu, __sleep_rcu);
+   }
+   }
  }
  
  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)




Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Chris Wilson]

Quoting Chris Wilson (2018-01-24 11:03:49)
> When we finally decide the gpu is idle, that is a good time to shrink
> our kmem_caches.
> 
> v3: Defer until an rcu grace period after we idle.
> v4: Think about epoch wraparound and how likely that is.
> 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin  #v3
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Tvrtko Ursulin]

On 24/01/2018 10:37, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-24 10:32:16)


On 19/01/2018 15:23, Chris Wilson wrote:

When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.

v3: Defer until an rcu grace period after we idle.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
   drivers/gpu/drm/i915/i915_gem.c | 65 
+
   1 file changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..6a8fbcae835b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3341,12 +3341,59 @@ new_requests_since_last_retire(const struct 
drm_i915_private *i915)
   work_pending(>gt.idle_work.work));
   }
   
+static void shrink_caches(struct drm_i915_private *i915)

+{
+ /*
+  * kmem_cache_shrink() discards empty slabs and reorders partially
+  * filled slabs to prioritise allocating from the mostly full slabs,
+  * with the aim of reducing fragmentation.
+  */
+ kmem_cache_shrink(i915->priorities);
+ kmem_cache_shrink(i915->dependencies);
+ kmem_cache_shrink(i915->requests);
+ kmem_cache_shrink(i915->luts);
+ kmem_cache_shrink(i915->vmas);
+ kmem_cache_shrink(i915->objects);
+}
+
+struct sleep_rcu_work {
+ struct drm_i915_private *i915;
+ struct rcu_head rcu;
+ struct work_struct work;
+ u32 epoch;
+};
+
+static void __sleep_work(struct work_struct *work)
+{
+ struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
+ struct drm_i915_private *i915 = s->i915;
+ u32 epoch = s->epoch;
+
+ kfree(s);
+ if (epoch == READ_ONCE(i915->gt.epoch))
+ shrink_caches(i915);
+}
+
+static void __sleep_rcu(struct rcu_head *rcu)
+{
+ struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
+ struct drm_i915_private *i915 = s->i915;
+
+ if (s->epoch == READ_ONCE(i915->gt.epoch)) {
+ INIT_WORK(>work, __sleep_work);
+ queue_work(i915->wq, >work);
+ } else {
+ kfree(s);
+ }
+}
+
   static void
   i915_gem_idle_work_handler(struct work_struct *work)
   {
   struct drm_i915_private *dev_priv =
   container_of(work, typeof(*dev_priv), gt.idle_work.work);
   bool rearm_hangcheck;
+ u32 epoch = 0;
   ktime_t end;
   
   if (!READ_ONCE(dev_priv->gt.awake))

@@ -3406,6 +3453,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
   GEM_BUG_ON(!dev_priv->gt.awake);
   dev_priv->gt.awake = false;
   rearm_hangcheck = false;
+ epoch = dev_priv->gt.epoch;
   
   if (INTEL_GEN(dev_priv) >= 6)

   gen6_rps_idle(dev_priv);
@@ -3421,6 +3469,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
   GEM_BUG_ON(!dev_priv->gt.awake);
   i915_queue_hangcheck(dev_priv);
   }
+
+ /*
+  * When we are idle, it is an opportune time to reap our caches.
+  * However, we have many objects that utilise RCU and the ordered
+  * i915->wq that this work is executing on. To try and flush any
+  * pending frees now we are idle, we first wait for an RCU grace
+  * period, and then queue a task (that will run last on the wq) to
+  * shrink and re-optimize the caches.
+  */
+ if (epoch == READ_ONCE(dev_priv->gt.epoch)) {


Theoretically this can be true on epoch wrap-around, when trylock
failed. It's one in four billion busy transitions but it could be just
worth handling it explicitly. Simplest probably to ensure gt.epoch is
never zero when incrementing?


I was working on the principle that a u32 wraparound takes at least
100ms * 2^32, or about 326 years. :)


Ah forgot there is a time delay.. okay then. :)

Reviewed-by: Tvrtko Ursulin 

To be kept if/when you change to unsigned int.

Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-24 10:52:28)
> 
> 
> On 1/24/2018 3:48 PM, Chris Wilson wrote:
> > Quoting Sagar Arun Kamble (2018-01-24 04:09:09)
> >> @@ -197,7 +212,7 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
> >>   
> >>   static void *guc_get_write_buffer(struct intel_guc *guc)
> >>   {
> >> -   if (!guc->log.runtime.relay_chan)
> >> +   if (!guc_log_has_relay(guc))
> >>  return NULL;
> >>   
> >>  /* Just get the base address of a new sub buffer and copy data 
> >> into it
> >> @@ -265,6 +280,8 @@ static void guc_read_update_log_buffer(struct 
> >> intel_guc *guc)
> >>  /* Get the pointer to shared GuC log buffer */
> >>  log_buf_state = src_data = guc->log.runtime.buf_addr;
> >>   
> >> +   mutex_lock(>log.runtime.relay_lock);
> >> +
> >>  /* Get the pointer to local buffer to store the logs */
> >>  log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
> > Hmm. The locking here tells me that we are being careful in case the
> > relay_chan disappears, but we don't handle the NULL pointer here.
> >   
> There is check for log_bug_snapshot_state below in for loop. But yes, we 
> should return from here.
> Will update.
> >> @@ -643,6 +724,8 @@ void i915_guc_log_unregister(struct drm_i915_private 
> >> *dev_priv)
> >>  gen9_disable_guc_interrupts(dev_priv);
> >>  intel_runtime_pm_put(dev_priv);
> >>   
> >> -   guc_log_runtime_destroy(_priv->guc);
> >> +   guc_log_runtime_destroy(guc);
> >>  mutex_unlock(_priv->drm.struct_mutex);
> >> +
> >> +   intel_guc_log_relay_destroy(guc);
> >>   }
> > This looks all reasonably well described by the addition of the
> > relay_lock and the interactions look fine. The only mistake I could see,
> > in the story told by this patch, was the runtime checking.
> Could you please elaborate more on this.

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

[Intel-gfx] [PATCH v2 1/2] drm/i915: Track the number of times we have woken the GPU up

[Chris Wilson]

By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.

v2: No reason to specify precise number of bits here.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
 drivers/gpu/drm/i915/i915_drv.h | 5 +
 drivers/gpu/drm/i915/i915_gem_request.c | 1 +
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 80dc679c0f01..65b175ac19b0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2717,7 +2717,8 @@ static int i915_runtime_pm_status(struct seq_file *m, 
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
 
-   seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
+   seq_printf(m, "GPU idle: %s (epoch %d)\n",
+  yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
   yesno(!intel_irqs_enabled(dev_priv)));
 #ifdef CONFIG_PM
@@ -3150,8 +3151,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
intel_runtime_pm_get(dev_priv);
 
-   seq_printf(m, "GT awake? %s\n",
-  yesno(dev_priv->gt.awake));
+   seq_printf(m, "GT awake? %s (epoch %d)\n",
+  yesno(dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "Global active requests: %d\n",
   dev_priv->gt.active_requests);
seq_printf(m, "CS timestamp frequency: %u kHz\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8333692dac5a..eed2e69dc002 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2312,6 +2312,11 @@ struct drm_i915_private {
 */
bool awake;
 
+   /**
+* The number of times we have woken up.
+*/
+   unsigned int epoch;
+
/**
 * We leave the user IRQ off as much as possible,
 * but this means that requests will finish and never
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..f0fab070a3a0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -274,6 +274,7 @@ static void mark_busy(struct drm_i915_private *i915)
intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
 
i915->gt.awake = true;
+   i915->gt.epoch++;
 
intel_enable_gt_powersave(i915);
i915_update_gfx_val(i915);
-- 
2.15.1

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

[Intel-gfx] [PATCH v2 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Chris Wilson]

When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.

v3: Defer until an rcu grace period after we idle.
v4: Think about epoch wraparound and how likely that is.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 78 +
 1 file changed, 78 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..60b34bb98ee3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3334,6 +3334,65 @@ i915_gem_retire_work_handler(struct work_struct *work)
}
 }
 
+static void shrink_caches(struct drm_i915_private *i915)
+{
+   /*
+* kmem_cache_shrink() discards empty slabs and reorders partially
+* filled slabs to prioritise allocating from the mostly full slabs,
+* with the aim of reducing fragmentation.
+*/
+   kmem_cache_shrink(i915->priorities);
+   kmem_cache_shrink(i915->dependencies);
+   kmem_cache_shrink(i915->requests);
+   kmem_cache_shrink(i915->luts);
+   kmem_cache_shrink(i915->vmas);
+   kmem_cache_shrink(i915->objects);
+}
+
+struct sleep_rcu_work {
+   union {
+   struct rcu_head rcu;
+   struct work_struct work;
+   };
+   struct drm_i915_private *i915;
+   unsigned int epoch;
+};
+
+static inline bool
+same_epoch(struct drm_i915_private *i915, unsigned int epoch)
+{
+   /*
+* There is a small chance that the epoch wrapped since we started
+* sleeping. If we assume that epoch is at least a u32, then it will
+* take at least 2^32 * 100ms for it to wrap, or about 326 years.
+*/
+   return epoch == READ_ONCE(i915->gt.epoch);
+}
+
+static void __sleep_work(struct work_struct *work)
+{
+   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
+   struct drm_i915_private *i915 = s->i915;
+   unsigned int epoch = s->epoch;
+
+   kfree(s);
+   if (same_epoch(i915, epoch))
+   shrink_caches(i915);
+}
+
+static void __sleep_rcu(struct rcu_head *rcu)
+{
+   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
+   struct drm_i915_private *i915 = s->i915;
+
+   if (same_epoch(i915, s->epoch)) {
+   INIT_WORK(>work, __sleep_work);
+   queue_work(i915->wq, >work);
+   } else {
+   kfree(s);
+   }
+}
+
 static inline bool
 new_requests_since_last_retire(const struct drm_i915_private *i915)
 {
@@ -3346,6 +3405,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
+   unsigned int epoch = 0;
bool rearm_hangcheck;
ktime_t end;
 
@@ -3406,6 +3466,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
rearm_hangcheck = false;
+   epoch = dev_priv->gt.epoch;
 
if (INTEL_GEN(dev_priv) >= 6)
gen6_rps_idle(dev_priv);
@@ -3421,6 +3482,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   if (same_epoch(dev_priv, epoch)) {
+   struct sleep_rcu_work *s = kmalloc(sizeof(*s), GFP_KERNEL);
+   if (s) {
+   s->i915 = dev_priv;
+   s->epoch = epoch;
+   call_rcu(>rcu, __sleep_rcu);
+   }
+   }
 }
 
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)
-- 
2.15.1

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

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/guc: Update name and prototype of i915_guc_log_control

[Sagar Arun Kamble]

On 1/24/2018 3:41 PM, Chris Wilson wrote:

Quoting Michal Wajdeczko (2018-01-24 10:07:12)

On Wed, 24 Jan 2018 05:09:10 +0100, Sagar Arun Kamble
 wrote:


i915_guc_log_control is GuC interface and GuC APIs that are not user
facing should be named with "intel_guc" prefix hence we change name to
intel_guc_log_control. Also changed the parameter to intel_guc struct.

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

Reviewed-by: Michal Wajdeczko 

with small bikeshed below


  drivers/gpu/drm/i915/i915_debugfs.c  | 5 +++--
  drivers/gpu/drm/i915/intel_guc_log.c | 4 ++--
  drivers/gpu/drm/i915/intel_guc_log.h | 2 +-
  3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b45be0d..c10a9e8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2467,14 +2467,15 @@ static int i915_guc_log_control_get(void *data,
u64 *val)
  static int i915_guc_log_control_set(void *data, u64 val)
  {
   struct drm_i915_private *dev_priv = data;
+ struct intel_guc *guc = _priv->guc;
   if (!HAS_GUC(dev_priv))
   return -ENODEV;
- if (!dev_priv->guc.log.vma)
+ if (!guc->log.vma)
   return -EINVAL;

Hmm, as this looks like internal check, maybe better to move
it into intel_guc_log_control() ?

Also, I'm not sure that lack of internal vma should be reported
as -EINVAL

Right, it's not reporting that the user's parameter was wrong, just that
the device wasn't initialised, so ENODEV seems appropriate.

Thanks for the review and inputs.

-Chris


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

[Sagar Arun Kamble]

On 1/24/2018 3:48 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-24 04:09:09)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 8f2da30..35de889 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -153,6 +153,8 @@ static int guc_log_relay_file_create(struct intel_guc *guc)
 if (!i915_modparams.guc_log_level)
 return 0;
  
+   mutex_lock(>log.runtime.relay_lock);

+
 /* For now create the log file in /sys/kernel/debug/dri/0 dir */
 log_dir = dev_priv->drm.primary->debugfs_root;
  
@@ -169,16 +171,26 @@ static int guc_log_relay_file_create(struct intel_guc *guc)

  */
 if (!log_dir) {
 DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto out_unlock;
 }
  
 ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log", log_dir);

 if (ret < 0 && ret != -EEXIST) {
 DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
-   return ret;
+   goto out_unlock;
 }
  
-   return 0;

+out_unlock:
+   mutex_unlock(>log.runtime.relay_lock);
+   return ret;
+}
+
+static bool guc_log_has_relay(struct intel_guc *guc)
+{
+   lockdep_assert_held(>log.runtime.relay_lock);
+
+   return guc->log.runtime.relay_chan != NULL;
  }
  
  static void guc_move_to_next_buf(struct intel_guc *guc)

@@ -188,6 +200,9 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
  */
 smp_wmb();
  
+   if (!guc_log_has_relay(guc))

+   return;
+
 /* All data has been written, so now move the offset of sub buffer. */
 relay_reserve(guc->log.runtime.relay_chan, 
guc->log.vma->obj->base.size);
  
@@ -197,7 +212,7 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
  
  static void *guc_get_write_buffer(struct intel_guc *guc)

  {
-   if (!guc->log.runtime.relay_chan)
+   if (!guc_log_has_relay(guc))
 return NULL;
  
 /* Just get the base address of a new sub buffer and copy data into it

@@ -265,6 +280,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 /* Get the pointer to shared GuC log buffer */
 log_buf_state = src_data = guc->log.runtime.buf_addr;
  
+   mutex_lock(>log.runtime.relay_lock);

+
 /* Get the pointer to local buffer to store the logs */
 log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);

Hmm. The locking here tells me that we are being careful in case the
relay_chan disappears, but we don't handle the NULL pointer here.
  
There is check for log_bug_snapshot_state below in for loop. But yes, we 
should return from here.

Will update.

@@ -344,6 +361,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
 guc->log.capture_miss_count++;
 }
+
+   mutex_unlock(>log.runtime.relay_lock);
  }
  
  static void capture_logs_work(struct work_struct *work)

@@ -363,8 +382,6 @@ static int guc_log_runtime_create(struct intel_guc *guc)
  {
 struct drm_i915_private *dev_priv = guc_to_i915(guc);
 void *vaddr;
-   struct rchan *guc_log_relay_chan;
-   size_t n_subbufs, subbuf_size;
 int ret;
  
 lockdep_assert_held(_priv->drm.struct_mutex);

@@ -387,8 +404,44 @@ static int guc_log_runtime_create(struct intel_guc *guc)
  
 guc->log.runtime.buf_addr = vaddr;
  
+   return 0;

+}
+
+static void guc_log_runtime_destroy(struct intel_guc *guc)
+{
+   /*
+* It's possible that the runtime stuff was never allocated because
+* GuC log was disabled at the boot time.
+**/
+   if (!guc_log_has_runtime(guc))
+   return;
+
+   i915_gem_object_unpin_map(guc->log.vma->obj);
+   guc->log.runtime.buf_addr = NULL;
+}
+
+void intel_guc_log_init_early(struct intel_guc *guc)
+{
+   mutex_init(>log.runtime.relay_lock);
+   INIT_WORK(>log.runtime.flush_work, capture_logs_work);
+}
+
+int intel_guc_log_relay_create(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct rchan *guc_log_relay_chan;
+   size_t n_subbufs, subbuf_size;
+   int ret;
+
+   if (!i915_modparams.guc_log_level)
+   return 0;
+
+   mutex_lock(>log.runtime.relay_lock);
+
+   GEM_BUG_ON(guc_log_has_relay(guc));
+
  /* Keep the size of sub buffers same as shared log buffer */
-   subbuf_size = guc->log.vma->obj->base.size;
+   subbuf_size = GUC_LOG_SIZE;
  
 /* Store up to 8 snapshots, which is large enough to buffer sufficient

  * boot time logs and provides enough leeway to User, in terms of
@@ -407,33 +460,39 @@ static int 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track the number of times we have woken the GPU up

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-24 10:33:29)
> 
> On 19/01/2018 15:23, Chris Wilson wrote:
> > By counting the number of times we have woken up, we have a very simple
> > means of defining an epoch, which will come in handy if we want to
> > perform deferred tasks at the end of an epoch (i.e. while we are going
> > to sleep) without imposing on the next activity cycle.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >   drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
> >   drivers/gpu/drm/i915/i915_drv.h | 5 +
> >   drivers/gpu/drm/i915/i915_gem_request.c | 1 +
> >   3 files changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index cc659b4b2a45..1aac3ec7d14d 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2717,7 +2717,8 @@ static int i915_runtime_pm_status(struct seq_file *m, 
> > void *unused)
> >   if (!HAS_RUNTIME_PM(dev_priv))
> >   seq_puts(m, "Runtime power management not supported\n");
> >   
> > - seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));
> > + seq_printf(m, "GPU idle: %s (epoch %d)\n",
> > +yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
> >   seq_printf(m, "IRQs disabled: %s\n",
> >  yesno(!intel_irqs_enabled(dev_priv)));
> >   #ifdef CONFIG_PM
> > @@ -3150,8 +3151,8 @@ static int i915_engine_info(struct seq_file *m, void 
> > *unused)
> >   
> >   intel_runtime_pm_get(dev_priv);
> >   
> > - seq_printf(m, "GT awake? %s\n",
> > -yesno(dev_priv->gt.awake));
> > + seq_printf(m, "GT awake? %s (epoch %d)\n",
> > +yesno(dev_priv->gt.awake), dev_priv->gt.epoch);
> >   seq_printf(m, "Global active requests: %d\n",
> >  dev_priv->gt.active_requests);
> >   seq_printf(m, "CS timestamp frequency: %u kHz\n",
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 317953484fec..98e8385d1bb0 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2302,6 +2302,11 @@ struct drm_i915_private {
> >   struct i915_gem_timeline global_timeline;
> >   u32 active_requests;
> >   
> > + /**
> > +  * The number of times we have woken up.
> > +  */
> > + u32 epoch;
> > +
> >   /**
> >* Is the GPU currently considered idle, or busy executing
> >* userspace requests? Whilst idle, we allow runtime power
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > b/drivers/gpu/drm/i915/i915_gem_request.c
> > index a0f451b4a4e8..f0fab070a3a0 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -274,6 +274,7 @@ static void mark_busy(struct drm_i915_private *i915)
> >   intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
> >   
> >   i915->gt.awake = true;
> > + i915->gt.epoch++;
> >   
> >   intel_enable_gt_powersave(i915);
> >   i915_update_gfx_val(i915);
> > 
> 
> I'd be tempted to use a standard type like unsigned int where explicit 
> width is not needed but it's minor.

Yeah, I was just copying the neighbouring type. active_requests is bound
to u32 by inflight_seqnos (which is bound by the hw seqno being u32).

Still no reason to impose u32 here, it raises the question of why must
it be exactly 32b.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-24 10:32:16)
> 
> On 19/01/2018 15:23, Chris Wilson wrote:
> > When we finally decide the gpu is idle, that is a good time to shrink
> > our kmem_caches.
> > 
> > v3: Defer until an rcu grace period after we idle.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/i915_gem.c | 65 
> > +
> >   1 file changed, 65 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 7f0684ccc724..6a8fbcae835b 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3341,12 +3341,59 @@ new_requests_since_last_retire(const struct 
> > drm_i915_private *i915)
> >   work_pending(>gt.idle_work.work));
> >   }
> >   
> > +static void shrink_caches(struct drm_i915_private *i915)
> > +{
> > + /*
> > +  * kmem_cache_shrink() discards empty slabs and reorders partially
> > +  * filled slabs to prioritise allocating from the mostly full slabs,
> > +  * with the aim of reducing fragmentation.
> > +  */
> > + kmem_cache_shrink(i915->priorities);
> > + kmem_cache_shrink(i915->dependencies);
> > + kmem_cache_shrink(i915->requests);
> > + kmem_cache_shrink(i915->luts);
> > + kmem_cache_shrink(i915->vmas);
> > + kmem_cache_shrink(i915->objects);
> > +}
> > +
> > +struct sleep_rcu_work {
> > + struct drm_i915_private *i915;
> > + struct rcu_head rcu;
> > + struct work_struct work;
> > + u32 epoch;
> > +};
> > +
> > +static void __sleep_work(struct work_struct *work)
> > +{
> > + struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
> > + struct drm_i915_private *i915 = s->i915;
> > + u32 epoch = s->epoch;
> > +
> > + kfree(s);
> > + if (epoch == READ_ONCE(i915->gt.epoch))
> > + shrink_caches(i915);
> > +}
> > +
> > +static void __sleep_rcu(struct rcu_head *rcu)
> > +{
> > + struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
> > + struct drm_i915_private *i915 = s->i915;
> > +
> > + if (s->epoch == READ_ONCE(i915->gt.epoch)) {
> > + INIT_WORK(>work, __sleep_work);
> > + queue_work(i915->wq, >work);
> > + } else {
> > + kfree(s);
> > + }
> > +}
> > +
> >   static void
> >   i915_gem_idle_work_handler(struct work_struct *work)
> >   {
> >   struct drm_i915_private *dev_priv =
> >   container_of(work, typeof(*dev_priv), gt.idle_work.work);
> >   bool rearm_hangcheck;
> > + u32 epoch = 0;
> >   ktime_t end;
> >   
> >   if (!READ_ONCE(dev_priv->gt.awake))
> > @@ -3406,6 +3453,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >   GEM_BUG_ON(!dev_priv->gt.awake);
> >   dev_priv->gt.awake = false;
> >   rearm_hangcheck = false;
> > + epoch = dev_priv->gt.epoch;
> >   
> >   if (INTEL_GEN(dev_priv) >= 6)
> >   gen6_rps_idle(dev_priv);
> > @@ -3421,6 +3469,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >   GEM_BUG_ON(!dev_priv->gt.awake);
> >   i915_queue_hangcheck(dev_priv);
> >   }
> > +
> > + /*
> > +  * When we are idle, it is an opportune time to reap our caches.
> > +  * However, we have many objects that utilise RCU and the ordered
> > +  * i915->wq that this work is executing on. To try and flush any
> > +  * pending frees now we are idle, we first wait for an RCU grace
> > +  * period, and then queue a task (that will run last on the wq) to
> > +  * shrink and re-optimize the caches.
> > +  */
> > + if (epoch == READ_ONCE(dev_priv->gt.epoch)) {
> 
> Theoretically this can be true on epoch wrap-around, when trylock 
> failed. It's one in four billion busy transitions but it could be just 
> worth handling it explicitly. Simplest probably to ensure gt.epoch is 
> never zero when incrementing?

I was working on the principle that a u32 wraparound takes at least
100ms * 2^32, or about 326 years. :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track the number of times we have woken the GPU up

[Tvrtko Ursulin]

On 19/01/2018 15:23, Chris Wilson wrote:

By counting the number of times we have woken up, we have a very simple
means of defining an epoch, which will come in handy if we want to
perform deferred tasks at the end of an epoch (i.e. while we are going
to sleep) without imposing on the next activity cycle.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
  drivers/gpu/drm/i915/i915_drv.h | 5 +
  drivers/gpu/drm/i915/i915_gem_request.c | 1 +
  3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cc659b4b2a45..1aac3ec7d14d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2717,7 +2717,8 @@ static int i915_runtime_pm_status(struct seq_file *m, 
void *unused)
if (!HAS_RUNTIME_PM(dev_priv))
seq_puts(m, "Runtime power management not supported\n");
  
-	seq_printf(m, "GPU idle: %s\n", yesno(!dev_priv->gt.awake));

+   seq_printf(m, "GPU idle: %s (epoch %d)\n",
+  yesno(!dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "IRQs disabled: %s\n",
   yesno(!intel_irqs_enabled(dev_priv)));
  #ifdef CONFIG_PM
@@ -3150,8 +3151,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
  
  	intel_runtime_pm_get(dev_priv);
  
-	seq_printf(m, "GT awake? %s\n",

-  yesno(dev_priv->gt.awake));
+   seq_printf(m, "GT awake? %s (epoch %d)\n",
+  yesno(dev_priv->gt.awake), dev_priv->gt.epoch);
seq_printf(m, "Global active requests: %d\n",
   dev_priv->gt.active_requests);
seq_printf(m, "CS timestamp frequency: %u kHz\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 317953484fec..98e8385d1bb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2302,6 +2302,11 @@ struct drm_i915_private {
struct i915_gem_timeline global_timeline;
u32 active_requests;
  
+		/**

+* The number of times we have woken up.
+*/
+   u32 epoch;
+
/**
 * Is the GPU currently considered idle, or busy executing
 * userspace requests? Whilst idle, we allow runtime power
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..f0fab070a3a0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -274,6 +274,7 @@ static void mark_busy(struct drm_i915_private *i915)
intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
  
  	i915->gt.awake = true;

+   i915->gt.epoch++;
  
  	intel_enable_gt_powersave(i915);

i915_update_gfx_val(i915);



I'd be tempted to use a standard type like unsigned int where explicit 
width is not needed but it's minor.


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Shrink the GEM kmem_caches upon idling

[Tvrtko Ursulin]

On 19/01/2018 15:23, Chris Wilson wrote:

When we finally decide the gpu is idle, that is a good time to shrink
our kmem_caches.

v3: Defer until an rcu grace period after we idle.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem.c | 65 +
  1 file changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..6a8fbcae835b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3341,12 +3341,59 @@ new_requests_since_last_retire(const struct 
drm_i915_private *i915)
work_pending(>gt.idle_work.work));
  }
  
+static void shrink_caches(struct drm_i915_private *i915)

+{
+   /*
+* kmem_cache_shrink() discards empty slabs and reorders partially
+* filled slabs to prioritise allocating from the mostly full slabs,
+* with the aim of reducing fragmentation.
+*/
+   kmem_cache_shrink(i915->priorities);
+   kmem_cache_shrink(i915->dependencies);
+   kmem_cache_shrink(i915->requests);
+   kmem_cache_shrink(i915->luts);
+   kmem_cache_shrink(i915->vmas);
+   kmem_cache_shrink(i915->objects);
+}
+
+struct sleep_rcu_work {
+   struct drm_i915_private *i915;
+   struct rcu_head rcu;
+   struct work_struct work;
+   u32 epoch;
+};
+
+static void __sleep_work(struct work_struct *work)
+{
+   struct sleep_rcu_work *s = container_of(work, typeof(*s), work);
+   struct drm_i915_private *i915 = s->i915;
+   u32 epoch = s->epoch;
+
+   kfree(s);
+   if (epoch == READ_ONCE(i915->gt.epoch))
+   shrink_caches(i915);
+}
+
+static void __sleep_rcu(struct rcu_head *rcu)
+{
+   struct sleep_rcu_work *s = container_of(rcu, typeof(*s), rcu);
+   struct drm_i915_private *i915 = s->i915;
+
+   if (s->epoch == READ_ONCE(i915->gt.epoch)) {
+   INIT_WORK(>work, __sleep_work);
+   queue_work(i915->wq, >work);
+   } else {
+   kfree(s);
+   }
+}
+
  static void
  i915_gem_idle_work_handler(struct work_struct *work)
  {
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
bool rearm_hangcheck;
+   u32 epoch = 0;
ktime_t end;
  
  	if (!READ_ONCE(dev_priv->gt.awake))

@@ -3406,6 +3453,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
rearm_hangcheck = false;
+   epoch = dev_priv->gt.epoch;
  
  	if (INTEL_GEN(dev_priv) >= 6)

gen6_rps_idle(dev_priv);
@@ -3421,6 +3469,23 @@ i915_gem_idle_work_handler(struct work_struct *work)
GEM_BUG_ON(!dev_priv->gt.awake);
i915_queue_hangcheck(dev_priv);
}
+
+   /*
+* When we are idle, it is an opportune time to reap our caches.
+* However, we have many objects that utilise RCU and the ordered
+* i915->wq that this work is executing on. To try and flush any
+* pending frees now we are idle, we first wait for an RCU grace
+* period, and then queue a task (that will run last on the wq) to
+* shrink and re-optimize the caches.
+*/
+   if (epoch == READ_ONCE(dev_priv->gt.epoch)) {


Theoretically this can be true on epoch wrap-around, when trylock 
failed. It's one in four billion busy transitions but it could be just 
worth handling it explicitly. Simplest probably to ensure gt.epoch is 
never zero when incrementing?



+   struct sleep_rcu_work *s = kmalloc(sizeof(*s), GFP_KERNEL);
+   if (s) {
+   s->i915 = dev_priv;
+   s->epoch = epoch;
+   call_rcu(>rcu, __sleep_rcu);
+   }
+   }
  }
  
  void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file)




Otherwise it sounds believable and looks correct.

Regards,

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

Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

[Chris Wilson]

Quoting Sagar Arun Kamble (2018-01-24 04:09:09)
> diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
> b/drivers/gpu/drm/i915/intel_guc_log.c
> index 8f2da30..35de889 100644
> --- a/drivers/gpu/drm/i915/intel_guc_log.c
> +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> @@ -153,6 +153,8 @@ static int guc_log_relay_file_create(struct intel_guc 
> *guc)
> if (!i915_modparams.guc_log_level)
> return 0;
>  
> +   mutex_lock(>log.runtime.relay_lock);
> +
> /* For now create the log file in /sys/kernel/debug/dri/0 dir */
> log_dir = dev_priv->drm.primary->debugfs_root;
>  
> @@ -169,16 +171,26 @@ static int guc_log_relay_file_create(struct intel_guc 
> *guc)
>  */
> if (!log_dir) {
> DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
> -   return -ENODEV;
> +   ret = -ENODEV;
> +   goto out_unlock;
> }
>  
> ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log", 
> log_dir);
> if (ret < 0 && ret != -EEXIST) {
> DRM_ERROR("Couldn't associate relay chan with file %d\n", 
> ret);
> -   return ret;
> +   goto out_unlock;
> }
>  
> -   return 0;
> +out_unlock:
> +   mutex_unlock(>log.runtime.relay_lock);
> +   return ret;
> +}
> +
> +static bool guc_log_has_relay(struct intel_guc *guc)
> +{
> +   lockdep_assert_held(>log.runtime.relay_lock);
> +
> +   return guc->log.runtime.relay_chan != NULL;
>  }
>  
>  static void guc_move_to_next_buf(struct intel_guc *guc)
> @@ -188,6 +200,9 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
>  */
> smp_wmb();
>  
> +   if (!guc_log_has_relay(guc))
> +   return;
> +
> /* All data has been written, so now move the offset of sub buffer. */
> relay_reserve(guc->log.runtime.relay_chan, 
> guc->log.vma->obj->base.size);
>  
> @@ -197,7 +212,7 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
>  
>  static void *guc_get_write_buffer(struct intel_guc *guc)
>  {
> -   if (!guc->log.runtime.relay_chan)
> +   if (!guc_log_has_relay(guc))
> return NULL;
>  
> /* Just get the base address of a new sub buffer and copy data into it
> @@ -265,6 +280,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
> *guc)
> /* Get the pointer to shared GuC log buffer */
> log_buf_state = src_data = guc->log.runtime.buf_addr;
>  
> +   mutex_lock(>log.runtime.relay_lock);
> +
> /* Get the pointer to local buffer to store the logs */
> log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);

Hmm. The locking here tells me that we are being careful in case the
relay_chan disappears, but we don't handle the NULL pointer here.
 
> @@ -344,6 +361,8 @@ static void guc_read_update_log_buffer(struct intel_guc 
> *guc)
> DRM_ERROR_RATELIMITED("no sub-buffer to capture logs\n");
> guc->log.capture_miss_count++;
> }
> +
> +   mutex_unlock(>log.runtime.relay_lock);
>  }
>  
>  static void capture_logs_work(struct work_struct *work)
> @@ -363,8 +382,6 @@ static int guc_log_runtime_create(struct intel_guc *guc)
>  {
> struct drm_i915_private *dev_priv = guc_to_i915(guc);
> void *vaddr;
> -   struct rchan *guc_log_relay_chan;
> -   size_t n_subbufs, subbuf_size;
> int ret;
>  
> lockdep_assert_held(_priv->drm.struct_mutex);
> @@ -387,8 +404,44 @@ static int guc_log_runtime_create(struct intel_guc *guc)
>  
> guc->log.runtime.buf_addr = vaddr;
>  
> +   return 0;
> +}
> +
> +static void guc_log_runtime_destroy(struct intel_guc *guc)
> +{
> +   /*
> +* It's possible that the runtime stuff was never allocated because
> +* GuC log was disabled at the boot time.
> +**/
> +   if (!guc_log_has_runtime(guc))
> +   return;
> +
> +   i915_gem_object_unpin_map(guc->log.vma->obj);
> +   guc->log.runtime.buf_addr = NULL;
> +}
> +
> +void intel_guc_log_init_early(struct intel_guc *guc)
> +{
> +   mutex_init(>log.runtime.relay_lock);
> +   INIT_WORK(>log.runtime.flush_work, capture_logs_work);
> +}
> +
> +int intel_guc_log_relay_create(struct intel_guc *guc)
> +{
> +   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> +   struct rchan *guc_log_relay_chan;
> +   size_t n_subbufs, subbuf_size;
> +   int ret;
> +
> +   if (!i915_modparams.guc_log_level)
> +   return 0;
> +
> +   mutex_lock(>log.runtime.relay_lock);
> +
> +   GEM_BUG_ON(guc_log_has_relay(guc));
> +
>  /* Keep the size of sub buffers same as shared log buffer */
> -   subbuf_size = guc->log.vma->obj->base.size;
> +   subbuf_size = GUC_LOG_SIZE;
>  
> /* Store up to 8 snapshots, which is large enough to buffer sufficient
>  * boot time logs and provides enough leeway to User, in 

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/guc: Update name and prototype of i915_guc_log_control

[Chris Wilson]

Quoting Michal Wajdeczko (2018-01-24 10:07:12)
> On Wed, 24 Jan 2018 05:09:10 +0100, Sagar Arun Kamble  
>  wrote:
> 
> > i915_guc_log_control is GuC interface and GuC APIs that are not user
> > facing should be named with "intel_guc" prefix hence we change name to
> > intel_guc_log_control. Also changed the parameter to intel_guc struct.
> >
> > Suggested-by: Michal Wajdeczko 
> > Signed-off-by: Sagar Arun Kamble 
> > Cc: Michal Wajdeczko 
> > Cc: Chris Wilson 
> > ---
> 
> Reviewed-by: Michal Wajdeczko 
> 
> with small bikeshed below
> 
> >  drivers/gpu/drm/i915/i915_debugfs.c  | 5 +++--
> >  drivers/gpu/drm/i915/intel_guc_log.c | 4 ++--
> >  drivers/gpu/drm/i915/intel_guc_log.h | 2 +-
> >  3 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c  
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index b45be0d..c10a9e8 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2467,14 +2467,15 @@ static int i915_guc_log_control_get(void *data,  
> > u64 *val)
> >  static int i915_guc_log_control_set(void *data, u64 val)
> >  {
> >   struct drm_i915_private *dev_priv = data;
> > + struct intel_guc *guc = _priv->guc;
> >   if (!HAS_GUC(dev_priv))
> >   return -ENODEV;
> > - if (!dev_priv->guc.log.vma)
> > + if (!guc->log.vma)
> >   return -EINVAL;
> 
> Hmm, as this looks like internal check, maybe better to move
> it into intel_guc_log_control() ?
> 
> Also, I'm not sure that lack of internal vma should be reported
> as -EINVAL

Right, it's not reporting that the user's parameter was wrong, just that
the device wasn't initialised, so ENODEV seems appropriate.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Move LRC register offsets to a header file

[Jani Nikula]

On Tue, 23 Jan 2018, Chris Wilson  wrote:
> Quoting Lucas De Marchi (2018-01-23 16:06:16)
>> On Tue, Jan 23, 2018 at 08:48:01AM +, Chris Wilson wrote:
>> > Quoting Michel Thierry (2018-01-23 00:41:07)
>> > > On 1/22/2018 4:31 PM, Lucas De Marchi wrote:
>> > > > So for this file what I understand is that it should be:
>> > > > 
>> > > >   // SPDX-License-Identifier: MIT
>> > > >   // Copyright (C) 2014-2018 Intel Corporation
>> > > 
>> > > So be it.
>> > 
>> > Oh no, we don't do C++ comments.
>> 
>> We drm or we kernel devs?
>> 
>> $ git grep "// SPDX"| wc -l 
>> 4487
>> 
>> The suggestion was actually from Linus in the thread I linked. Quoting
>> here:
>> 
>> > So in general, the _hope_ is that we can just end up replacing
>> > existing boilerplate comments with that single line SPDX comment
>> > (using "//" in *.[ch] files, but obviously some other kinds of files
>> > end up having a different comment character, typically '#').
>> ...
>> > And yes, feel free to replace block comments with // while at it.
>> ...
>> > We already have something like 700 different versions of the same
>> > silly copyright license boiler-plate due to typos, whitespace
>> > differences, comment style choices, yadda yadda. Let's avoid that mess
>> > by just picking _one_ single format and placement for the SPDX line.
>> 
>> Which I agree with, hence my suggestion. Let me know if it should be
>> different in drm/
>
> Being consistent is far more important.
> Documentation/process/coding-style.rst is what we follow, breaking the
> rule and being inconsistent for copyright headers doesn't make any sense.

Please use /* */ rather than // in i915 throughout.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/guc: Update name and prototype of i915_guc_log_control

[Michal Wajdeczko]

On Wed, 24 Jan 2018 05:09:10 +0100, Sagar Arun Kamble  
 wrote:



i915_guc_log_control is GuC interface and GuC APIs that are not user
facing should be named with "intel_guc" prefix hence we change name to
intel_guc_log_control. Also changed the parameter to intel_guc struct.

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


Reviewed-by: Michal Wajdeczko 

with small bikeshed below


 drivers/gpu/drm/i915/i915_debugfs.c  | 5 +++--
 drivers/gpu/drm/i915/intel_guc_log.c | 4 ++--
 drivers/gpu/drm/i915/intel_guc_log.h | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

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

index b45be0d..c10a9e8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2467,14 +2467,15 @@ static int i915_guc_log_control_get(void *data,  
u64 *val)

 static int i915_guc_log_control_set(void *data, u64 val)
 {
struct drm_i915_private *dev_priv = data;
+   struct intel_guc *guc = _priv->guc;
if (!HAS_GUC(dev_priv))
return -ENODEV;
-   if (!dev_priv->guc.log.vma)
+   if (!guc->log.vma)
return -EINVAL;


Hmm, as this looks like internal check, maybe better to move
it into intel_guc_log_control() ?

Also, I'm not sure that lack of internal vma should be reported
as -EINVAL


-   return i915_guc_log_control(dev_priv, val);
+   return intel_guc_log_control(guc, val);
 }
DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c  
b/drivers/gpu/drm/i915/intel_guc_log.c

index 35de889..27eb545 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -637,9 +637,9 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(>log.vma);
 }
-int i915_guc_log_control(struct drm_i915_private *dev_priv, u64  
control_val)

+int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
 {
-   struct intel_guc *guc = _priv->guc;
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
bool enable_logging = control_val > 0;
u32 verbosity;
int ret;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h  
b/drivers/gpu/drm/i915/intel_guc_log.h

index c638b9d..dab0e94 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.h
+++ b/drivers/gpu/drm/i915/intel_guc_log.h
@@ -64,7 +64,7 @@ struct intel_guc_log {
 void intel_guc_log_init_early(struct intel_guc *guc);
 int intel_guc_log_relay_create(struct intel_guc *guc);
 void intel_guc_log_relay_destroy(struct intel_guc *guc);
-int i915_guc_log_control(struct drm_i915_private *dev_priv, u64  
control_val);

+int intel_guc_log_control(struct intel_guc *guc, u64 control_val);
 void i915_guc_log_register(struct drm_i915_private *dev_priv);
 void i915_guc_log_unregister(struct drm_i915_private *dev_priv);

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

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915/guc: Fix comments style in intel_guc_log.c

[Sagar Arun Kamble]

On 1/24/2018 3:20 PM, Michal Wajdeczko wrote:
On Wed, 24 Jan 2018 10:49:02 +0100, Chris Wilson 
 wrote:



Quoting Sagar Arun Kamble (2018-01-24 04:09:11)

Use consistent multi-line comment style as per guideline.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 49 
+++-

 1 file changed, 32 insertions(+), 17 deletions(-)

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

index 27eb545..7c6c41b 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -30,7 +30,7 @@

 static void guc_log_capture_logs(struct intel_guc *guc);

-/**
+/*
  * DOC: GuC firmware log
  *
  * Firmware log is enabled by setting i915.guc_log_level to the 
positive level.


The double ** here indicates a kerneldoc. So this one is correct.



yes. will update.

The one that is wrong is in guc_log_runtime_destroy()
as it ends with **/


yes. that one got introduced by patch in series. will fix.

Michal


--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Ignore VBT request for know invalid DDC pin.

[Kai Heng Feng]

> On 24 Jan 2018, at 6:03 PM, Jani Nikula  wrote:
> 
> On Wed, 24 Jan 2018, Kai Heng Feng  wrote:
>> Hi,
>> 
>>> On 24 Jan 2018, at 5:25 PM, Jani Nikula  wrote:
>>> A bit too fast IMO. The bug report doesn't include the vbt dump which
>>> you should *always* look at before making workarounds for vbt.
>> 
>> I didn’t have access to the machine in question until now, I can provide
>> VBT dump as well as i915_opregion requested by Ville.
>> 
>> But how do I make a VBT dump?
> 
> Copy /sys/kernel/debug/dri/0/i915_vbt
> 
> I don't think the opregion will be necessary, I think Ville asks for it
> for the vbt, which on most platforms is contained in the opregion.
> 

Thanks for the tip.

Attached i915_vbt:
https://bugs.freedesktop.org/attachment.cgi?id=136935

Kai-Heng

> BR,
> Jani.
> 
> 
>> 
>> Kai-Heng 
>> 
>>> 
>>> -- 
>>> Jani Nikula, Intel Open Source Technology Center
>> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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

Re: [Intel-gfx] [PATCH] drm/i915/cnp: Ignore VBT request for know invalid DDC pin.

[Jani Nikula]

On Wed, 24 Jan 2018, Kai Heng Feng  wrote:
> Hi,
>
>> On 24 Jan 2018, at 5:25 PM, Jani Nikula  wrote:
>> A bit too fast IMO. The bug report doesn't include the vbt dump which
>> you should *always* look at before making workarounds for vbt.
>
> I didn’t have access to the machine in question until now, I can provide
> VBT dump as well as i915_opregion requested by Ville.
>
> But how do I make a VBT dump?

Copy /sys/kernel/debug/dri/0/i915_vbt

I don't think the opregion will be necessary, I think Ville asks for it
for the vbt, which on most platforms is contained in the opregion.

BR,
Jani.


>
> Kai-Heng 
>
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915/guc: Fix comments style in intel_guc_log.c

[Michal Wajdeczko]

On Wed, 24 Jan 2018 10:49:02 +0100, Chris Wilson  
 wrote:



Quoting Sagar Arun Kamble (2018-01-24 04:09:11)

Use consistent multi-line comment style as per guideline.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 49  
+++-

 1 file changed, 32 insertions(+), 17 deletions(-)

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

index 27eb545..7c6c41b 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -30,7 +30,7 @@

 static void guc_log_capture_logs(struct intel_guc *guc);

-/**
+/*
  * DOC: GuC firmware log
  *
  * Firmware log is enabled by setting i915.guc_log_level to the  
positive level.


The double ** here indicates a kerneldoc. So this one is correct.


The one that is wrong is in guc_log_runtime_destroy()
as it ends with **/

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