[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Move LRC register offsets to a header file (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Move LRC register offsets to a header file (rev3)
URL   : https://patchwork.freedesktop.org/series/36930/
State : failure

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-tilingchange:
fail   -> PASS   (shard-apl) fdo#103167
Subgroup fbc-1p-offscren-pri-indfb-draw-pwrite:
pass   -> FAIL   (shard-apl) fdo#101623 +2
Test testdisplay:
pass   -> DMESG-WARN (shard-apl) fdo#104727
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test gem_eio:
Subgroup in-flight-external:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_flip:
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test pm_rpm:
Subgroup gem-execbuf-stress:
pass   -> INCOMPLETE (shard-hsw)
Test drv_suspend:
Subgroup fence-restore-tiled2untiled-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254

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

shard-apltotal:2753 pass:1713 dwarn:2   dfail:0   fail:25  skip:1013 
time:13942s
shard-hswtotal:2728 pass:1713 dwarn:1   dfail:0   fail:10  skip:1002 
time:14856s
shard-snbtotal:2753 pass:1319 dwarn:1   dfail:0   fail:9   skip:1424 
time:7892s
Blacklisted hosts:
shard-kbltotal:2753 pass:1842 dwarn:1   dfail:0   fail:23  skip:887 
time:10683s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev5)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev5)
URL   : https://patchwork.freedesktop.org/series/36828/
State : failure

== Summary ==

Test kms_flip:
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Subgroup 2x-vblank-vs-hang:
pass   -> INCOMPLETE (shard-hsw)
Test gem_softpin:
Subgroup noreloc-s4:
fail   -> SKIP   (shard-snb) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Subgroup fbc-tilingchange:
fail   -> PASS   (shard-apl)
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715
Test pm_rpm:
Subgroup gem-execbuf-stress:
pass   -> INCOMPLETE (shard-hsw)

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

shard-apltotal:2753 pass:1715 dwarn:1   dfail:0   fail:24  skip:1013 
time:14021s
shard-hswtotal:2652 pass:1669 dwarn:1   dfail:0   fail:11  skip:968 
time:14667s
shard-snbtotal:2753 pass:1318 dwarn:1   dfail:0   fail:10  skip:1424 
time:7894s
Blacklisted hosts:
shard-kbltotal:2753 pass:1815 dwarn:4   dfail:0   fail:23  skip:911 
time:10642s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/dp: Add HBR3 support in existing DRM DP helpers

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/dp: Add HBR3 support in existing DRM DP 
helpers
URL   : https://patchwork.freedesktop.org/series/36931/
State : failure

== Summary ==

Test kms_cursor_legacy:
Subgroup short-flip-after-cursor-atomic-transitions:
pass   -> FAIL   (shard-apl) fdo#103792
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test kms_frontbuffer_tracking:
Subgroup fbc-tilingchange:
fail   -> PASS   (shard-apl)
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test drv_suspend:
Subgroup fence-restore-tiled2untiled-hibernate:
fail   -> SKIP   (shard-snb) fdo#103375
Test kms_flip:
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Subgroup vblank-vs-suspend-interruptible:
pass   -> FAIL   (shard-apl) fdo#100368
Test pm_rpm:
Subgroup gem-execbuf-stress:
pass   -> INCOMPLETE (shard-hsw)

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

shard-apltotal:2753 pass:1713 dwarn:1   dfail:0   fail:26  skip:1013 
time:13962s
shard-hswtotal:2728 pass:1712 dwarn:1   dfail:0   fail:11  skip:1002 
time:14880s
shard-snbtotal:2753 pass:1319 dwarn:1   dfail:0   fail:9   skip:1424 
time:7883s
Blacklisted hosts:
shard-kbltotal:2753 pass:1838 dwarn:1   dfail:1   fail:24  skip:889 
time:10774s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for Queued/runnable/running engine stats

[Patchwork]

== Series Details ==

Series: Queued/runnable/running engine stats
URL   : https://patchwork.freedesktop.org/series/36926/
State : failure

== Summary ==

Test kms_flip:
Subgroup busy-flip-interruptible:
pass   -> FAIL   (shard-apl) fdo#103257
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-snb)
fail   -> INCOMPLETE (shard-hsw) fdo#104676 +1
pass   -> INCOMPLETE (shard-apl)
Subgroup in-flight-internal:
pass   -> INCOMPLETE (shard-snb)
pass   -> INCOMPLETE (shard-apl)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623 +1
Subgroup fbc-tilingchange:
fail   -> PASS   (shard-apl)
Subgroup fbc-1p-shrfb-fliptrack:
pass   -> DMESG-FAIL (shard-apl) fdo#103167 +2
Test gem_softpin:
Subgroup noreloc-s4:
fail   -> SKIP   (shard-snb) fdo#103375
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> INCOMPLETE (shard-snb)
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355

fdo#103257 https://bugs.freedesktop.org/show_bug.cgi?id=103257
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355

shard-apltotal:2670 pass:1658 dwarn:1   dfail:1   fail:26  skip:982 
time:12752s
shard-hswtotal:2721 pass:1707 dwarn:1   dfail:0   fail:10  skip:1001 
time:15055s
shard-snbtotal:2598 pass:1241 dwarn:1   dfail:0   fail:7   skip:1346 
time:7137s
Blacklisted hosts:
shard-kbltotal:2670 pass:1788 dwarn:1   dfail:0   fail:22  skip:857 
time:10063s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7744/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/cnl: Add AUX-F support

[Pandiyan, Dhinakaran]

On Tue, 2018-01-23 at 02:43 +, Pandiyan, Dhinakaran wrote:
> 
> 
> On Mon, 2018-01-22 at 15:59 -0800, Rodrigo Vivi wrote:
> > On some Cannonlake SKUs we have a dedicated Aux for port F,
> > that is only the full split between port A and port E.
> > 
> > There is still no Aux E for Port E, as in previous platforms,
> > because port_E still means shared lanes with port A.
> > 


Lucas,


Should "drm/i915/cnl: apply Display WA #1178 to fix type C dongles" be
extended to AUX F ?

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Restore HDCP DRM_INFO when with no downstream

[Patchwork]

== Series Details ==

Series: drm/i915: Restore HDCP DRM_INFO when with no downstream
URL   : https://patchwork.freedesktop.org/series/36921/
State : warning

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-tilingchange:
fail   -> PASS   (shard-apl)
Subgroup fbc-1p-primscrn-cur-indfb-move:
pass   -> FAIL   (shard-apl) fdo#101623 +1
Test gem_eio:
Subgroup in-flight-external:
fail   -> PASS   (shard-hsw) fdo#104676 +1
Test kms_cursor_legacy:
Subgroup cursora-vs-flipa-atomic-transitions-varying-size:
pass   -> SKIP   (shard-snb)
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_flip:
Subgroup vblank-vs-suspend:
pass   -> DMESG-WARN (shard-snb) fdo#102365
pass   -> INCOMPLETE (shard-hsw) fdo#100368
Subgroup vblank-vs-dpms-suspend-interruptible:
pass   -> INCOMPLETE (shard-hsw) fdo#103540 +1
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test drv_suspend:
Subgroup debugfs-reader:
pass   -> SKIP   (shard-snb)
Subgroup fence-restore-tiled2untiled-hibernate:
fail   -> SKIP   (shard-hsw) fdo#103375

fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676
fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
fdo#102365 https://bugs.freedesktop.org/show_bug.cgi?id=102365
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375

shard-apltotal:2753 pass:1715 dwarn:1   dfail:0   fail:24  skip:1013 
time:13948s
shard-hswtotal:2632 pass:1643 dwarn:1   dfail:0   fail:9   skip:975 
time:13556s
shard-snbtotal:2753 pass:1314 dwarn:2   dfail:0   fail:12  skip:1425 
time:7825s
Blacklisted hosts:
shard-kbltotal:2735 pass:1820 dwarn:1   dfail:0   fail:24  skip:889 
time:10598s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Implement display w/a #1143 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Implement display w/a #1143 (rev2)
URL   : https://patchwork.freedesktop.org/series/36813/
State : warning

== Summary ==

Test kms_flip:
Subgroup vblank-vs-dpms-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Subgroup vblank-vs-modeset-rpm:
pass   -> DMESG-WARN (shard-apl)
Subgroup flip-vs-panning-vs-hang-interruptible:
dmesg-warn -> PASS   (shard-snb) fdo#103821
Test kms_frontbuffer_tracking:
Subgroup fbc-tilingchange:
fail   -> PASS   (shard-apl)
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
fail   -> PASS   (shard-snb) fdo#101623
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
fail   -> PASS   (shard-apl) fdo#103355
Test gem_exec_schedule:
Subgroup reorder-wide-blt:
pass   -> FAIL   (shard-apl) fdo#102848
Test drv_suspend:
Subgroup fence-restore-tiled2untiled-hibernate:
fail   -> SKIP   (shard-hsw) fdo#103375
Test perf:
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254

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

shard-apltotal:2675 pass:1671 dwarn:2   dfail:0   fail:21  skip:981 
time:13568s
shard-hswtotal:2709 pass:1695 dwarn:1   dfail:0   fail:10  skip:1001 
time:15070s
shard-snbtotal:2753 pass:1319 dwarn:1   dfail:0   fail:10  skip:1423 
time:7879s
Blacklisted hosts:
shard-kbltotal:2735 pass:1821 dwarn:1   dfail:0   fail:25  skip:887 
time:10553s

== Logs ==

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

Re: [Intel-gfx] [PATCH 08/10] drm/i915/cnl: Enable DDI-F on Cannonlake.

[Pandiyan, Dhinakaran]

On Fri, 2018-01-19 at 16:05 -0800, Rodrigo Vivi wrote:
> Now let's finish the Port-F support by adding the
> proper port F detection, irq and power well support.
> 
> v2: Rebase
> v3: Use BIT_ULL
> v4: Cover missed case on ddi init.
> v5: Update commit message.
> v6: Rebase on top of display headers rework.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c|  4 
>  drivers/gpu/drm/i915/intel_display.c|  6 +-
>  drivers/gpu/drm/i915/intel_display.h|  2 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +
>  5 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 861a7d5a27af..32ec64eb2c5a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1304,6 +1304,7 @@ enum i915_power_well_id {
>   SKL_DISP_PW_DDI_B,
>   SKL_DISP_PW_DDI_C,
>   SKL_DISP_PW_DDI_D,

This looks suspicious, why isn't there a DDI_E here for CNL? I see that
bit 10 and 11 correspond to CNL port E in the spec.

> + CNL_DISP_PW_DDI_F = 6,
>  
>   GLK_DISP_PW_AUX_A = 8,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Don't try to manage Port F power wells on all CNL.

[Pandiyan, Dhinakaran]

On Mon, 2018-01-22 at 15:48 -0800, Rodrigo Vivi wrote:
> SKUs that lacks on the full port F split will just time out
> when touching this power well bits, causing a noisy warn.
> 
> v2: Suggested-by: Imre. Temporarily remove the aux pw id after setting
> it instead of duplicating and redefining everything.
> 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 433048ffa5c6..7cee63860a7b 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1861,18 +1861,20 @@ void intel_display_power_put(struct drm_i915_private 
> *dev_priv,
>  #define CNL_DISPLAY_AUX_D_POWER_DOMAINS (\
>   BIT_ULL(POWER_DOMAIN_AUX_D) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (\
> - BIT_ULL(POWER_DOMAIN_AUX_F) |   \
> - BIT_ULL(POWER_DOMAIN_INIT))
> -#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS ( \
> - BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
> - BIT_ULL(POWER_DOMAIN_INIT))
>  #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS (   \
>   CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
>   BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
>   BIT_ULL(POWER_DOMAIN_MODESET) | \
>   BIT_ULL(POWER_DOMAIN_AUX_A) |   \
>   BIT_ULL(POWER_DOMAIN_INIT))
> +/* Power wells for CNL with port F after this */
> +#define CNL_FIRST_PORT_F_PW CNL_DISP_PW_AUX_F
> +#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (\
> + BIT_ULL(POWER_DOMAIN_AUX_F) |   \
> + BIT_ULL(POWER_DOMAIN_INIT))
> +#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS ( \
> + BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
> + BIT_ULL(POWER_DOMAIN_INIT))
>  
>  static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
>   .sync_hw = i9xx_power_well_sync_hw_noop,
> @@ -2544,6 +2546,17 @@ int intel_power_domains_init(struct drm_i915_private 
> *dev_priv)
>   set_power_wells(power_domains, skl_power_wells);
>   } else if (IS_CANNONLAKE(dev_priv)) {
>   set_power_wells(power_domains, cnl_power_wells);
> +
> + if (!IS_CNL_WITH_PORT_F(dev_priv)) {
> + int i;
> +
> + for (i = 0; i < power_domains->power_well_count; i++)
> + if (power_domains->power_wells[i].id ==
> + CNL_FIRST_PORT_F_PW)
> + break;
> + WARN_ON(power_domains->power_well_count == i - 1);
> + power_domains->power_well_count = i - 1;
Shouldn't this be
WARN_ON(power_domains->power_well_count == i);
power_domains->power_well_count = i; ?

 
> + }
>   } else if (IS_BROXTON(dev_priv)) {
>   set_power_wells(power_domains, bxt_power_wells);
>   } else if (IS_GEMINILAKE(dev_priv)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

[Pandiyan, Dhinakaran]

On Mon, 2018-01-22 at 15:59 -0800, Rodrigo Vivi wrote:
> On some Cannonlake SKUs we have a dedicated Aux for port F,
> that is only the full split between port A and port E.
> 
> There is still no Aux E for Port E, as in previous platforms,
> because port_E still means shared lanes with port A.
> 
> v2: Rebase.
> v3: Add couple missed PORT_F cases on intel_dp.
> v4: Rebase and fix commit message.
> v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> v6: Rebase on top of display headers rework.
> v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> v8: Fix Aux bits for Port F (DK)
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_irq.c |  6 ++
>  drivers/gpu/drm/i915/i915_reg.h |  9 +
>  drivers/gpu/drm/i915/intel_display.h|  1 +
>  drivers/gpu/drm/i915/intel_dp.c |  8 
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
>  6 files changed, 36 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3d3727829ac7..7206c7c5f81c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1255,6 +1255,7 @@ enum modeset_restore {
>  #define DP_AUX_B 0x10
>  #define DP_AUX_C 0x20
>  #define DP_AUX_D 0x30
> +#define DP_AUX_F 0x50

How is this decided? Looks like drivers/gpu/drm/i915/gvt/opregion.c
<> needs to be updated too. I guess that's a
separate patch. 

>  
>  #define DDC_PIN_B  0x05
>  #define DDC_PIN_C  0x04
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index db3466ec6faa..0af970d4b3cf 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2579,6 +2579,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
> u32 master_ctl)
>   GEN9_AUX_CHANNEL_C |
>   GEN9_AUX_CHANNEL_D;
>  
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + tmp_mask |= CNL_AUX_CHANNEL_F;
> +
>   if (iir & tmp_mask) {
>   dp_aux_irq_handler(dev_priv);
>   found = true;
> @@ -3617,6 +3620,9 @@ static void gen8_de_irq_postinstall(struct 
> drm_i915_private *dev_priv)
>   de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
>   }
>  
> + if (IS_CNL_WITH_PORT_F(dev_priv))
> + de_port_masked |= CNL_AUX_CHANNEL_F;
> +
>   de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
>  GEN8_PIPE_FIFO_UNDERRUN;
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index abd9ee876186..ebdee212767a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1312,6 +1312,7 @@ enum i915_power_well_id {
>   CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
>   CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
>   CNL_DISP_PW_AUX_D,
> + CNL_DISP_PW_AUX_F,
>  
>   SKL_DISP_PW_1 = 14,
>   SKL_DISP_PW_2,
> @@ -5284,6 +5285,13 @@ enum {
>  #define _DPD_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64320)
>  #define _DPD_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64324)
>  
> +#define _DPF_AUX_CH_CTL  (dev_priv->info.display_mmio_offset + 
> 0x64510)
> +#define _DPF_AUX_CH_DATA1(dev_priv->info.display_mmio_offset + 0x64514)
> +#define _DPF_AUX_CH_DATA2(dev_priv->info.display_mmio_offset + 0x64518)
> +#define _DPF_AUX_CH_DATA3(dev_priv->info.display_mmio_offset + 0x6451c)
> +#define _DPF_AUX_CH_DATA4(dev_priv->info.display_mmio_offset + 0x64520)
> +#define _DPF_AUX_CH_DATA5(dev_priv->info.display_mmio_offset + 0x64524)
> +
>  #define DP_AUX_CH_CTL(port)  _MMIO_PORT(port, _DPA_AUX_CH_CTL, 
> _DPB_AUX_CH_CTL)
>  #define DP_AUX_CH_DATA(port, i)  _MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
> _DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
>  
> @@ -6939,6 +6947,7 @@ enum {
>  #define GEN8_DE_PORT_IMR _MMIO(0x4)
>  #define GEN8_DE_PORT_IIR _MMIO(0x8)
>  #define GEN8_DE_PORT_IER _MMIO(0xc)
> +#define  CNL_AUX_CHANNEL_F   (1 << 28)
>  #define  GEN9_AUX_CHANNEL_D  (1 << 27)
>  #define  GEN9_AUX_CHANNEL_C  (1 << 26)
>  #define  GEN9_AUX_CHANNEL_B  (1 << 25)
> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index e47638931b51..30fa2041a45f 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -172,6 +172,7 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_AUX_B,
>   POWER_DOMAIN_AUX_C,
>  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move LRC register offsets to a header file (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Move LRC register offsets to a header file (rev3)
URL   : https://patchwork.freedesktop.org/series/36930/
State : success

== Summary ==

Series 36930v3 drm/i915: Move LRC register offsets to a header file
https://patchwork.freedesktop.org/api/1.0/series/36930/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
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:429s
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:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:484s
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:479s
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:471s
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:279s
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:390s
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:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
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:455s
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:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
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:531s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:490s
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:432s
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: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:258  dwarn:0   dfail:0   fail:0   skip:30  
time:473s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
41d2d900b12a drm/i915: Move LRC register offsets to a header file

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7750/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: Move LRC register offsets to a header file

[Michel Thierry]

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.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michel Thierry]

Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.

v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)

v3: License notice shenanigans.

Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Lucas De Marchi 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 50 +--
 drivers/gpu/drm/i915/intel_lrc_reg.h | 57 
 2 files changed, 58 insertions(+), 49 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lrc_reg.h

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 506bc2bc04f9..3cf30b982524 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_gem_render_state.h"
+#include "intel_lrc_reg.h"
 #include "intel_mocs.h"
 
 #define RING_EXECLIST_QFULL(1 << 0x2)
@@ -156,55 +157,6 @@
 #define GEN8_CTX_STATUS_COMPLETED_MASK \
 (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
 
-#define CTX_LRI_HEADER_0   0x01
-#define CTX_CONTEXT_CONTROL0x02
-#define CTX_RING_HEAD  0x04
-#define CTX_RING_TAIL  0x06
-#define CTX_RING_BUFFER_START  0x08
-#define CTX_RING_BUFFER_CONTROL0x0a
-#define CTX_BB_HEAD_U  0x0c
-#define CTX_BB_HEAD_L  0x0e
-#define CTX_BB_STATE   0x10
-#define CTX_SECOND_BB_HEAD_U   0x12
-#define CTX_SECOND_BB_HEAD_L   0x14
-#define CTX_SECOND_BB_STATE0x16
-#define CTX_BB_PER_CTX_PTR 0x18
-#define CTX_RCS_INDIRECT_CTX   0x1a
-#define CTX_RCS_INDIRECT_CTX_OFFSET0x1c
-#define CTX_LRI_HEADER_1   0x21
-#define CTX_CTX_TIMESTAMP  0x22
-#define CTX_PDP3_UDW   0x24
-#define CTX_PDP3_LDW   0x26
-#define CTX_PDP2_UDW   0x28
-#define CTX_PDP2_LDW   0x2a
-#define CTX_PDP1_UDW   0x2c
-#define CTX_PDP1_LDW   0x2e
-#define CTX_PDP0_UDW   0x30
-#define CTX_PDP0_LDW   0x32
-#define CTX_LRI_HEADER_2   0x41
-#define CTX_R_PWR_CLK_STATE0x42
-#define CTX_GPGPU_CSR_BASE_ADDRESS 0x44
-
-#define CTX_REG(reg_state, pos, reg, val) do { \
-   (reg_state)[(pos)+0] = i915_mmio_reg_offset(reg); \
-   (reg_state)[(pos)+1] = (val); \
-} while (0)
-
-#define ASSIGN_CTX_PDP(ppgtt, reg_state, n) do {   \
-   const u64 _addr = i915_page_dir_dma_addr((ppgtt), (n)); \
-   reg_state[CTX_PDP ## n ## _UDW+1] = upper_32_bits(_addr); \
-   reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
-} while (0)
-
-#define ASSIGN_CTX_PML4(ppgtt, reg_state) do { \
-   reg_state[CTX_PDP0_UDW + 1] = upper_32_bits(px_dma(>pml4)); \
-   reg_state[CTX_PDP0_LDW + 1] = lower_32_bits(px_dma(>pml4)); \
-} while (0)
-
-#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
-
 /* Typical size of the average request (2 pipecontrols and a MI_BB) */
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 #define WA_TAIL_DWORDS 2
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h 
b/drivers/gpu/drm/i915/intel_lrc_reg.h
new file mode 100644
index ..875a16fdece8
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -0,0 +1,57 @@
+// SPDX-License-Identifier: MIT
+// Copyright © 2014-2018 Intel Corporation
+
+#ifndef _INTEL_LRC_REG_H_
+#define _INTEL_LRC_REG_H_
+
+/* GEN8+ Reg State Context */
+#define CTX_LRI_HEADER_0   0x01
+#define CTX_CONTEXT_CONTROL0x02
+#define CTX_RING_HEAD  0x04
+#define CTX_RING_TAIL  0x06
+#define CTX_RING_BUFFER_START  0x08
+#define CTX_RING_BUFFER_CONTROL0x0a
+#define CTX_BB_HEAD_U  0x0c
+#define CTX_BB_HEAD_L  0x0e
+#define CTX_BB_STATE   0x10
+#define CTX_SECOND_BB_HEAD_U   0x12
+#define CTX_SECOND_BB_HEAD_L   0x14
+#define CTX_SECOND_BB_STATE0x16
+#define CTX_BB_PER_CTX_PTR 0x18
+#define CTX_RCS_INDIRECT_CTX   0x1a
+#define CTX_RCS_INDIRECT_CTX_OFFSET0x1c
+#define CTX_LRI_HEADER_1   0x21
+#define CTX_CTX_TIMESTAMP  0x22
+#define CTX_PDP3_UDW   0x24
+#define CTX_PDP3_LDW   0x26
+#define CTX_PDP2_UDW   0x28
+#define CTX_PDP2_LDW   0x2a
+#define CTX_PDP1_UDW   0x2c
+#define CTX_PDP1_LDW 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev5)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev5)
URL   : https://patchwork.freedesktop.org/series/36828/
State : success

== Summary ==

Series 36828v5 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/36828/revisions/5/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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:421s
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:488s
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:491s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
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:454s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
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:411s
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:415s
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:503s
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:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
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:528s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
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:432s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:512s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:480s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
fa8e29c5efca drm/i915/cnl: Don't try to manage Port F power wells on all CNL.
9e809a487e96 drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
8a59bbb7760c drm/i915/cnl: Enable DDI-F on Cannonlake.
ebf6b037613a drm/i915/cnl: Add HPD support for Port F.
61fa99461586 drm/i915: For HPD connected port use hpd_pin instead of port.
6bdd9adcc251 drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
aedb3f70c1bf drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
39a900b42f1a drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
bc396648ec88 drm/i915/cnl: Add AUX-F support
2f3f59fe0a19 drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7749/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: Move LRC register offsets to a header file

[Lucas De Marchi]

On Mon, Jan 22, 2018 at 01:49:19PM -0800, Michel Thierry wrote:
> > > > diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h
> > > > b/drivers/gpu/drm/i915/intel_lrc_reg.h
> > > > new file mode 100644
> > > > index ..f50d63cb4b66
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
> > > > @@ -0,0 +1,78 @@
> > > > +/* SPDX-License-Identifier: MIT */
> > > > +/*
> > > > + * Copyright © 2018 Intel Corporation
> >     
> > hmm, maybe years should be "2014-2018"
> > 
> 
> 2014 because that's when these #define were originally added?

Because that's what is in the copyright line in that file I suppose.

> 
> > > > + *
> > > > + * Permission is hereby granted, free of charge, to any person
> > > > obtaining a
> > > > + * copy of this software and associated documentation files
> > > > (the "Software"),
> > > > + * to deal in the Software without restriction, including
> > > > without limitation
> > > > + * the rights to use, copy, modify, merge, publish, distribute,
> > > > sublicense,
> > > > + * and/or sell copies of the Software, and to permit persons to
> > > > whom the
> > > > + * Software is furnished to do so, subject to the following conditions:
> > > > + *
> > > > + * The above copyright notice and this permission notice
> > > > (including the next
> > > > + * paragraph) shall be included in all copies or substantial
> > > > portions of the
> > > > + * Software.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > > > KIND, EXPRESS OR
> > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > > MERCHANTABILITY,
> > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > > > EVENT SHALL
> > > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > > > DAMAGES OR OTHER
> > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > > > OTHERWISE, ARISING
> > > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > > > + * DEALINGS IN THE SOFTWARE.
> > > > + */
> > > 
> > > Looking at other files added after the SPDX change, it doesn't look
> > > like we should duplicate the information about license. So in this case
> > > AFAIU it should contain only the SPDX tag and the Copyright, but not
> > > license text. See
> > > 
> > > git log --grep "Remove redundant license text"
> > > 
> > > 
> > > Lucas De Marchi
> > > 
> > 
> > and by looking at other examples I think best practice is to put this tag
> > right under a copyright line:
> > 
> > /*
> >   * Copyright © 2014-2018 Intel Corporation
> >   *
> >   * SPDX-License-Identifier: MIT
> >   */
> > 
> 
> Best practice, but not the most common:
> 
> $ git grep " \* SPDX-License-Identifier:" |wc -l
> 94
> 
> $ git grep "/\* SPDX-License-Identifier:" |wc -l
> 7822
> 
> Anyway it looks ok to me, objections?

I remember Linus stating his preference for `// SPDX ... ' as the first
line. The copyright could then follow the comment format.  Searching now
I found this:

https://lkml.org/lkml/2017/11/2/715

(and see the thread why it was used /* rather than // in headers...
which as been fixed by 5cb0512c02ecd7e6214e912e4c150f4219ac78e0).

So for this file what I understand is that it should be:

// SPDX-License-Identifier: MIT
// Copyright (C) 2014-2018 Intel Corporation

Lucas De Marchi


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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU. (rev4)

[Patchwork]

== Series Details ==

Series: series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI IDs for 
another SKU. (rev4)
URL   : https://patchwork.freedesktop.org/series/36828/
State : success

== Summary ==

Series 36828v4 series starting with [01/10] drm/i915/cnl: Add Cannonlake PCI 
IDs for another SKU.
https://patchwork.freedesktop.org/api/1.0/series/36828/revisions/4/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:429s
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:372s
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:280s
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: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:454s
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:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:515s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
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:410s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:457s
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:459s
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: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:598s
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:507s
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:486s
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:420s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:471s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
9f5b51071be1 drm/i915/cnl: Don't try to manage Port F power wells on all CNL.
ca2178f36358 drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
8f60cfa6b58d drm/i915/cnl: Enable DDI-F on Cannonlake.
68f82bbfe11e drm/i915/cnl: Add HPD support for Port F.
ce1021de5ce2 drm/i915: For HPD connected port use hpd_pin instead of port.
7821c0fda1f7 drm/i915/cnl: Add right GMBUS pin number for HDMI on Port F.
bb9c87f63c8f drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.
454b349cec3f drm/i915/cnl: Fix _CNL_PORT_TX_DW2_LN0_F definition.
5df350c312bf drm/i915/cnl: Add AUX-F support
7566db01d212 drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Patchwork]

== Series Details ==

Series: drm/i915/breadcrumbs: Drop request reference for the signaler thread
URL   : https://patchwork.freedesktop.org/series/36908/
State : failure

== Summary ==

Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw)
Subgroup vblank-vs-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#100368
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test gem_eio:
Subgroup in-flight-external:
fail   -> PASS   (shard-hsw) fdo#104676
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-cur-indfb-move:
pass   -> SKIP   (shard-snb) fdo#101623 +1
Test perf_pmu:
Subgroup multi-client-vcs0:
pass   -> FAIL   (shard-apl)

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

shard-apltotal:2753 pass:1713 dwarn:1   dfail:0   fail:26  skip:1013 
time:13941s
shard-hswtotal:2721 pass:1706 dwarn:1   dfail:0   fail:10  skip:1002 
time:14634s
shard-snbtotal:2753 pass:1317 dwarn:1   dfail:0   fail:10  skip:1425 
time:7887s
Blacklisted hosts:
shard-kbltotal:2753 pass:1812 dwarn:24  dfail:2   fail:25  skip:890 
time:10845s

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/cnl: Add AUX-F support

[Rodrigo Vivi]

On some Cannonlake SKUs we have a dedicated Aux for port F,
that is only the full split between port A and port E.

There is still no Aux E for Port E, as in previous platforms,
because port_E still means shared lanes with port A.

v2: Rebase.
v3: Add couple missed PORT_F cases on intel_dp.
v4: Rebase and fix commit message.
v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
v6: Rebase on top of display headers rework.
v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
v8: Fix Aux bits for Port F (DK)

Cc: Dhinakaran Pandiyan 
Cc: Lucas De Marchi 
Cc: Imre Deak 
Cc: Manasi Navare 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c |  6 ++
 drivers/gpu/drm/i915/i915_reg.h |  9 +
 drivers/gpu/drm/i915/intel_display.h|  1 +
 drivers/gpu/drm/i915/intel_dp.c |  8 
 drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
 6 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d3727829ac7..7206c7c5f81c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1255,6 +1255,7 @@ enum modeset_restore {
 #define DP_AUX_B 0x10
 #define DP_AUX_C 0x20
 #define DP_AUX_D 0x30
+#define DP_AUX_F 0x50
 
 #define DDC_PIN_B  0x05
 #define DDC_PIN_C  0x04
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index db3466ec6faa..0af970d4b3cf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2579,6 +2579,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   tmp_mask |= CNL_AUX_CHANNEL_F;
+
if (iir & tmp_mask) {
dp_aux_irq_handler(dev_priv);
found = true;
@@ -3617,6 +3620,9 @@ static void gen8_de_irq_postinstall(struct 
drm_i915_private *dev_priv)
de_pipe_masked |= GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
}
 
+   if (IS_CNL_WITH_PORT_F(dev_priv))
+   de_port_masked |= CNL_AUX_CHANNEL_F;
+
de_pipe_enables = de_pipe_masked | GEN8_PIPE_VBLANK |
   GEN8_PIPE_FIFO_UNDERRUN;
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index abd9ee876186..ebdee212767a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1312,6 +1312,7 @@ enum i915_power_well_id {
CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
CNL_DISP_PW_AUX_D,
+   CNL_DISP_PW_AUX_F,
 
SKL_DISP_PW_1 = 14,
SKL_DISP_PW_2,
@@ -5284,6 +5285,13 @@ enum {
 #define _DPD_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64320)
 #define _DPD_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64324)
 
+#define _DPF_AUX_CH_CTL(dev_priv->info.display_mmio_offset + 
0x64510)
+#define _DPF_AUX_CH_DATA1  (dev_priv->info.display_mmio_offset + 0x64514)
+#define _DPF_AUX_CH_DATA2  (dev_priv->info.display_mmio_offset + 0x64518)
+#define _DPF_AUX_CH_DATA3  (dev_priv->info.display_mmio_offset + 0x6451c)
+#define _DPF_AUX_CH_DATA4  (dev_priv->info.display_mmio_offset + 0x64520)
+#define _DPF_AUX_CH_DATA5  (dev_priv->info.display_mmio_offset + 0x64524)
+
 #define DP_AUX_CH_CTL(port)_MMIO_PORT(port, _DPA_AUX_CH_CTL, 
_DPB_AUX_CH_CTL)
 #define DP_AUX_CH_DATA(port, i)_MMIO(_PORT(port, _DPA_AUX_CH_DATA1, 
_DPB_AUX_CH_DATA1) + (i) * 4) /* 5 registers */
 
@@ -6939,6 +6947,7 @@ enum {
 #define GEN8_DE_PORT_IMR _MMIO(0x4)
 #define GEN8_DE_PORT_IIR _MMIO(0x8)
 #define GEN8_DE_PORT_IER _MMIO(0xc)
+#define  CNL_AUX_CHANNEL_F (1 << 28)
 #define  GEN9_AUX_CHANNEL_D(1 << 27)
 #define  GEN9_AUX_CHANNEL_C(1 << 26)
 #define  GEN9_AUX_CHANNEL_B(1 << 25)
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index e47638931b51..30fa2041a45f 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -172,6 +172,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_B,
POWER_DOMAIN_AUX_C,
POWER_DOMAIN_AUX_D,
+   POWER_DOMAIN_AUX_F,
POWER_DOMAIN_GMBUS,
POWER_DOMAIN_MODESET,
POWER_DOMAIN_GT_IRQ,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a2e88715..ae3b0b030177 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ 

[Intel-gfx] [PATCH] drm/i915/cnl: Don't try to manage Port F power wells on all CNL.

[Rodrigo Vivi]

SKUs that lacks on the full port F split will just time out
when touching this power well bits, causing a noisy warn.

v2: Suggested-by: Imre. Temporarily remove the aux pw id after setting
it instead of duplicating and redefining everything.

Cc: Lucas De Marchi 
Cc: Imre Deak 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 433048ffa5c6..7cee63860a7b 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1861,18 +1861,20 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
 #define CNL_DISPLAY_AUX_D_POWER_DOMAINS (  \
BIT_ULL(POWER_DOMAIN_AUX_D) |   \
BIT_ULL(POWER_DOMAIN_INIT))
-#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (  \
-   BIT_ULL(POWER_DOMAIN_AUX_F) |   \
-   BIT_ULL(POWER_DOMAIN_INIT))
-#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS (   \
-   BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
-   BIT_ULL(POWER_DOMAIN_INIT))
 #define CNL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
CNL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
BIT_ULL(POWER_DOMAIN_GT_IRQ) |  \
BIT_ULL(POWER_DOMAIN_MODESET) | \
BIT_ULL(POWER_DOMAIN_AUX_A) |   \
BIT_ULL(POWER_DOMAIN_INIT))
+/* Power wells for CNL with port F after this */
+#define CNL_FIRST_PORT_F_PW CNL_DISP_PW_AUX_F
+#define CNL_DISPLAY_AUX_F_POWER_DOMAINS (  \
+   BIT_ULL(POWER_DOMAIN_AUX_F) |   \
+   BIT_ULL(POWER_DOMAIN_INIT))
+#define CNL_DISPLAY_DDI_F_IO_POWER_DOMAINS (   \
+   BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO) |   \
+   BIT_ULL(POWER_DOMAIN_INIT))
 
 static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
.sync_hw = i9xx_power_well_sync_hw_noop,
@@ -2544,6 +2546,17 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
set_power_wells(power_domains, skl_power_wells);
} else if (IS_CANNONLAKE(dev_priv)) {
set_power_wells(power_domains, cnl_power_wells);
+
+   if (!IS_CNL_WITH_PORT_F(dev_priv)) {
+   int i;
+
+   for (i = 0; i < power_domains->power_well_count; i++)
+   if (power_domains->power_wells[i].id ==
+   CNL_FIRST_PORT_F_PW)
+   break;
+   WARN_ON(power_domains->power_well_count == i - 1);
+   power_domains->power_well_count = i - 1;
+   }
} else if (IS_BROXTON(dev_priv)) {
set_power_wells(power_domains, bxt_power_wells);
} else if (IS_GEMINILAKE(dev_priv)) {
-- 
2.13.6

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

Re: [Intel-gfx] [PATCH 02/10] drm/i915/cnl: Add AUX-F support

[Pandiyan, Dhinakaran]

On Fri, 2018-01-19 at 16:05 -0800, Rodrigo Vivi wrote:
> On some Cannonlake SKUs we have a dedicated Aux for port F,
> that is only the full split between port A and port E.
> 
> There is still no Aux E for Port E, as in previous platforms,
> because port_E still means shared lanes with port A.
> 
> v2: Rebase.
> v3: Add couple missed PORT_F cases on intel_dp.
> v4: Rebase and fix commit message.
> v5: Squash Imre's "drm/i915: Add missing AUX_F power well string"
> v6: Rebase on top of display headers rework.
> v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK)
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/i915_irq.c |  6 ++
>  drivers/gpu/drm/i915/i915_reg.h |  9 +
>  drivers/gpu/drm/i915/intel_display.h|  1 +
>  drivers/gpu/drm/i915/intel_dp.c |  8 
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
>  6 files changed, 36 insertions(+)



> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 83b3f02d33b7..381c6758f3a6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1312,6 +1312,7 @@ enum i915_power_well_id {
>   CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
>   CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
>   CNL_DISP_PW_AUX_D,
> + CNL_DISP_PW_AUX_F = 13,

Should be 12, status bit is 24 (= id*2) and request is 25 (= id*2 + 1) 

>  
>   SKL_DISP_PW_1 = 14,
>   SKL_DISP_PW_2,

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

Re: [Intel-gfx] [PATCH 07/10] drm/i915/cnl: Add HPD support for Port F.

[Rodrigo Vivi]

On Mon, Jan 22, 2018 at 04:51:08PM +, Ville Syrjälä wrote:
> On Fri, Jan 19, 2018 at 04:05:21PM -0800, Rodrigo Vivi wrote:
> > On CNP boards that are using DDI F,
> > bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
> > the Digital Port F hotplug line when the Digital
> > Port F hotplug detect input is enabled.
> > 
> > v2: Reuse all existent structure instead of adding a
> > new HPD_PORT_F pointing to pin of port E.
> > v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
> > this right now. If that SKU ever get a proper name
> > we come back and update it.
> > v4: Rebase on top of digital connected port using encoder
> > instead of port.
> > v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.
> > 
> > Cc: Lucas De Marchi 
> > Cc: Manasi Navare 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Ville Syrjälä 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |  6 --
> >  drivers/gpu/drm/i915/i915_irq.c  | 35 
> > +++
> >  drivers/gpu/drm/i915/intel_dp.c  |  4 +++-
> >  drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
> >  drivers/gpu/drm/i915/intel_hotplug.c | 19 +++
> >  5 files changed, 42 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7206c7c5f81c..0b5f8d887bfd 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2957,8 +2957,10 @@ void intel_hpd_irq_handler(struct drm_i915_private 
> > *dev_priv,
> >  void intel_hpd_init(struct drm_i915_private *dev_priv);
> >  void intel_hpd_init_work(struct drm_i915_private *dev_priv);
> >  void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
> > -enum port intel_hpd_pin_to_port(enum hpd_pin pin);
> > -enum hpd_pin intel_hpd_pin(enum port port);
> > +enum port intel_hpd_pin_to_port(struct drm_i915_private *dev_priv,
> > +   enum hpd_pin pin);
> > +enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
> > +  enum port port);
> >  bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin 
> > pin);
> >  void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 0af970d4b3cf..78af4594eb38 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1568,10 +1568,11 @@ static bool i9xx_port_hotplug_long_detect(enum port 
> > port, u32 val)
> >   *
> >   * Note that the caller is expected to zero out the masks initially.
> >   */
> > -static void intel_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
> > -u32 hotplug_trigger, u32 dig_hotplug_reg,
> > -const u32 hpd[HPD_NUM_PINS],
> > -bool long_pulse_detect(enum port port, u32 val))
> > +static void intel_get_hpd_pins(struct drm_i915_private *dev_priv,
> > +  u32 *pin_mask, u32 *long_mask,
> > +  u32 hotplug_trigger, u32 dig_hotplug_reg,
> > +  const u32 hpd[HPD_NUM_PINS],
> > +  bool long_pulse_detect(enum port port, u32 val))
> >  {
> > enum port port;
> > int i;
> > @@ -1582,7 +1583,7 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
> > *long_mask,
> >  
> > *pin_mask |= BIT(i);
> >  
> > -   port = intel_hpd_pin_to_port(i);
> > +   port = intel_hpd_pin_to_port(dev_priv, i);
> > if (port == PORT_NONE)
> > continue;
> >  
> > @@ -1970,8 +1971,9 @@ static void i9xx_hpd_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> >  
> > if (hotplug_trigger) {
> > -   intel_get_hpd_pins(_mask, _mask, 
> > hotplug_trigger,
> > -  hotplug_trigger, hpd_status_g4x,
> > +   intel_get_hpd_pins(dev_priv, _mask, _mask,
> > +  hotplug_trigger, hotplug_trigger,
> > +  hpd_status_g4x,
> >i9xx_port_hotplug_long_detect);
> >  
> > intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> > @@ -1983,8 +1985,9 @@ static void i9xx_hpd_irq_handler(struct 
> > drm_i915_private *dev_priv,
> > u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> >  
> > if (hotplug_trigger) {
> > -   intel_get_hpd_pins(_mask, _mask, 
> > hotplug_trigger,
> > -  hotplug_trigger, hpd_status_i915,
> > +   intel_get_hpd_pins(dev_priv, 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace open-coded wait-for loop

[Patchwork]

== Series Details ==

Series: drm/i915: Replace open-coded wait-for loop
URL   : https://patchwork.freedesktop.org/series/36904/
State : success

== Summary ==

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-legacy:
pass   -> FAIL   (shard-apl) fdo#103355
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
incomplete -> PASS   (shard-hsw) fdo#103375
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw)
Test perf:
Subgroup blocking:
pass   -> FAIL   (shard-hsw) fdo#102252 +1

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

shard-apltotal:2753 pass:1713 dwarn:1   dfail:0   fail:26  skip:1013 
time:13946s
shard-hswtotal:2753 pass:1724 dwarn:1   dfail:0   fail:12  skip:1015 
time:15415s
shard-snbtotal:2753 pass:1318 dwarn:1   dfail:0   fail:11  skip:1423 
time:7921s
Blacklisted hosts:
shard-kbltotal:2735 pass:1820 dwarn:1   dfail:0   fail:24  skip:889 
time:10542s

== Logs ==

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

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.

[Rodrigo Vivi]

On Mon, Jan 22, 2018 at 09:44:47PM +, Pandiyan, Dhinakaran wrote:
> On Fri, 2018-01-19 at 16:05 -0800, Rodrigo Vivi wrote:
> > Since when it got introduced with commit '555e38d27317
> > ("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
> > was wrong, because Port F bits are far from bits used
> > for A to E.
> > 
> > Since Port F is not used so far we don't need to propagate
> > Fixes back there.
> > 
> > v2: Reuse _SHIFT definition to avoid complicated duplication (DK).
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Lucas De Marchi 
> > Cc: Manasi Navare 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 3ad9ad4a7918..861a7d5a27af 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -8838,10 +8838,12 @@ enum skl_power_gate {
> >   * CNL Clocks
> >   */
> >  #define DPCLKA_CFGCR0  _MMIO(0x6C200)
> > -#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port)+10))
> > -#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 << ((port)*2))
> > -#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port)*2)
> > -#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) << ((port)*2))
> > +#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port)   (1 << ((port) ==  PORT_F ? 23 : 
> > \
> > + (port)+10))
> > +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port) == PORT_F ? 21 
> > : \
> > +   (port)*2)
> 
> nit: I wouldn't bother with the new line, more readable without it. And
> there seems to be plenty of places in that file where the 80 char limit
> is exceeded.

well, it depends on the screen size. If not cut the screen size will limit that
and in my current case it gets worse...

>  
> 
> Either way, patch looks correct.
> Reviewed-by: Dhinakaran Pandiyan 

Thanks,
Rodrigo.

> 
> 
> > +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)  (3 << 
> > DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
> > +#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)  ((pll) << 
> > DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
> >  
> >  /* CNL PLL */
> >  #define DPLL0_ENABLE   0x46010
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: For HPD connected port use hpd_pin instead of port.

[Rodrigo Vivi]

Let's try to simplify this mapping to hpd_pin -> bit
instead using port.
So for CNL with port F where we have this port using
hdp_pin and bits of other ports we don't need to duplicated
the mapping.

But for now this is only a re-org with no functional change
expected.

v2: Add missing lines and nuke @port reference from code
documentation. (Ville)

Cc: Lucas De Marchi 
Suggested-by: Ville Syrjälä 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 150 ++--
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 drivers/gpu/drm/i915/intel_lspcon.c |   3 +-
 3 files changed, 77 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ae3b0b030177..8579d2d09231 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4487,173 +4487,174 @@ edp_detect(struct intel_dp *intel_dp)
return status;
 }
 
-static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool ibx_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = SDE_PORTB_HOTPLUG;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = SDE_PORTC_HOTPLUG;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = SDE_PORTD_HOTPLUG;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool cpt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool cpt_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = SDE_PORTB_HOTPLUG_CPT;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = SDE_PORTC_HOTPLUG_CPT;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = SDE_PORTD_HOTPLUG_CPT;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool spt_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_A:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_A:
bit = SDE_PORTA_HOTPLUG_SPT;
break;
-   case PORT_E:
+   case HPD_PORT_E:
bit = SDE_PORTE_HOTPLUG_SPT;
break;
default:
-   return cpt_digital_port_connected(dev_priv, port);
+   return cpt_digital_port_connected(encoder);
}
 
return I915_READ(SDEISR) & bit;
 }
 
-static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
-  struct intel_digital_port *port)
+static bool g4x_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
u32 bit;
 
-   switch (port->base.port) {
-   case PORT_B:
+   switch (encoder->hpd_pin) {
+   case HPD_PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_G4X;
break;
-   case PORT_C:
+   case HPD_PORT_C:
bit = PORTC_HOTPLUG_LIVE_STATUS_G4X;
break;
-   case PORT_D:
+   case HPD_PORT_D:
bit = PORTD_HOTPLUG_LIVE_STATUS_G4X;
break;
default:
-   MISSING_CASE(port->base.port);
+   MISSING_CASE(encoder->hpd_pin);
return false;
}
 
return I915_READ(PORT_HOTPLUG_STAT) & bit;
 }
 
-static bool gm45_digital_port_connected(struct drm_i915_private *dev_priv,
-   struct intel_digital_port *port)
+static bool gm45_digital_port_connected(struct intel_encoder *encoder)
 {
+   struct 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp: Add HBR3 support in existing DRM DP helpers

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/dp: Add HBR3 support in existing DRM DP 
helpers
URL   : https://patchwork.freedesktop.org/series/36931/
State : success

== Summary ==

Series 36931v1 series starting with [1/2] drm/dp: Add HBR3 support in existing 
DRM DP helpers
https://patchwork.freedesktop.org/api/1.0/series/36931/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:427s
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:374s
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:280s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:486s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
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:280s
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:406s
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:465s
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:457s
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:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:433s
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:528s
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:475s
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:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:536s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:404s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
fc0af05dea6f drm/dp: Add definitions for TPS4 bits and macros to check the 
support
398f509336f9 drm/dp: Add HBR3 support in existing DRM DP helpers

== Logs ==

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

Re: [Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

[Rodrigo Vivi]

On Mon, Jan 22, 2018 at 04:56:10PM +, Ville Syrjälä wrote:
> On Fri, Jan 19, 2018 at 04:05:15PM -0800, Rodrigo Vivi wrote:
> > The only difference is that this SKUs has the full
> > Port A/E split named as Port F.
> > 
> > But since SKUs differences don't matter on the platform
> > definition group and ids, let's merge all off them together.
> > 
> > v2: Really include the PCI IDs to the picidlist[];
> > v3: Add the PCI Id for another SKU (Anusha).
> > v4: Update IDs, really include to pciidlists again.
> > v5: Unify all GT2 IDs.
> > v6: Unify in a way that we don't break early-quirks.c
> > v7: Remove GT reference since it doesn't matter here (Paulo)
> > Also move IS_CNL_WITH_PORT_F macro to this patch to
> > make it easier for review this part and also to get
> > used sooner.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Paulo Zanoni 
> > Cc: Lucas De Marchi 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  2 ++
> >  drivers/gpu/drm/i915/i915_pci.c |  5 ++---
> >  include/drm/i915_pciids.h   | 18 +++---
> >  3 files changed, 11 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8333692dac5a..3d3727829ac7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2647,6 +2647,8 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  (dev_priv)->info.gt == 2)
> >  #define IS_CFL_GT3(dev_priv)   (IS_COFFEELAKE(dev_priv) && \
> >  (dev_priv)->info.gt == 3)
> > +#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> > +   (INTEL_DEVID(dev_priv) & 0x0004) == 
> > 0x0004)
> 
> I wonder if we should generalize this sort of thing into some kind of
> device info port_mask. Though our port namespace currently only covers
> the various digital port type, so listing all possible ports there
> wouldn't currently be possible.

well... the right way actually would be having a proper name for this SKU,
but unfortunately we don't :/

> 
> Perhaps not worth the hassle right now.

yeap... I don't feel it is worth right now.

> 
> >  
> >  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index f28c165fc49d..7eb3d5e4350e 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -571,7 +571,7 @@ static const struct intel_device_info 
> > intel_coffeelake_gt3_info __initconst = {
> > .ddb_size = 1024, \
> > GLK_COLORS
> >  
> > -static const struct intel_device_info intel_cannonlake_gt2_info 
> > __initconst = {
> > +static const struct intel_device_info intel_cannonlake_info __initconst = {
> > GEN10_FEATURES,
> > .is_alpha_support = 1,
> > .platform = INTEL_CANNONLAKE,
> > @@ -649,8 +649,7 @@ static const struct pci_device_id pciidlist[] = {
> > INTEL_CFL_U_GT1_IDS(_coffeelake_gt1_info),
> > INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
> > INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
> > -   INTEL_CNL_U_GT2_IDS(_cannonlake_gt2_info),
> > -   INTEL_CNL_Y_GT2_IDS(_cannonlake_gt2_info),
> > +   INTEL_CNL_IDS(_cannonlake_info),
> > {0, 0, 0}
> >  };
> >  MODULE_DEVICE_TABLE(pci, pciidlist);
> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> > index 5db0458dd832..9e1fe6634424 100644
> > --- a/include/drm/i915_pciids.h
> > +++ b/include/drm/i915_pciids.h
> > @@ -414,24 +414,20 @@
> > INTEL_CFL_U_GT2_IDS(info), \
> > INTEL_CFL_U_GT3_IDS(info)
> >  
> > -/* CNL U 2+2 */
> > -#define INTEL_CNL_U_GT2_IDS(info) \
> > +/* CNL */
> > +#define INTEL_CNL_IDS(info) \
> > INTEL_VGA_DEVICE(0x5A52, info), \
> > INTEL_VGA_DEVICE(0x5A5A, info), \
> > INTEL_VGA_DEVICE(0x5A42, info), \
> > -   INTEL_VGA_DEVICE(0x5A4A, info)
> > -
> > -/* CNL Y 2+2 */
> > -#define INTEL_CNL_Y_GT2_IDS(info) \
> > +   INTEL_VGA_DEVICE(0x5A4A, info), \
> > INTEL_VGA_DEVICE(0x5A51, info), \
> > INTEL_VGA_DEVICE(0x5A59, info), \
> > INTEL_VGA_DEVICE(0x5A41, info), \
> > INTEL_VGA_DEVICE(0x5A49, info), \
> > INTEL_VGA_DEVICE(0x5A71, info), \
> > -   INTEL_VGA_DEVICE(0x5A79, info)
> > -
> > -#define INTEL_CNL_IDS(info) \
> > -   INTEL_CNL_U_GT2_IDS(info), \
> > -   INTEL_CNL_Y_GT2_IDS(info)
> > +   INTEL_VGA_DEVICE(0x5A79, info), \
> > +   INTEL_VGA_DEVICE(0x5A54, info), \
> > +   INTEL_VGA_DEVICE(0x5A5C, info), \
> > +   INTEL_VGA_DEVICE(0x5A44, info)
> >  
> >  #endif /* _I915_PCIIDS_H */
> > -- 
> > 2.13.6
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > 

Re: [Intel-gfx] [PATCH i-g-t 3/4] scripts/trace.pl: Calculate stats only after all munging

[John Harrison]

On 1/22/2018 2:54 AM, Tvrtko Ursulin wrote:


On 20/01/2018 00:24, john.c.harri...@intel.com wrote:

From: John Harrison 

There are various statistics being calculated multiple times in
multiple places while the log file is being read in. Some of these are
then re-calculated when the database is munged to correct various
issues with the logs. This patch consolidates the calculations into a
separate pass after all the reading and munging has been done.

Note that this actually produces a different final output as the
'execute-delay' values were not previously being re-calculated after
all the fixups. Thus were based on an incorrect calculation.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
  scripts/trace.pl | 54 
--

  1 file changed, 28 insertions(+), 26 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index cf841b7e..c5d822aa 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -437,8 +437,7 @@ while (<>) {
  $req{'global'} = $tp{'global'};
  $req{'port'} = $tp{'port'};
  $req{'queue'} = $queue{$key};
-    $req{'submit-delay'} = $submit{$key} - $queue{$key};
-    $req{'execute-delay'} = $req{'start'} - $submit{$key};
+    $req{'submit'} = $submit{$key};


You only use the submit key to look up things two times, so you could 
use the %submit hash directly to save some lookups, but on the other 
hand maybe you were going for nicer split between data structures over 
performance.


When I look at it again, I was using the same approach for 'queue' 
when %queue was also available so never mind.. maybe an optimisation 
opportunity with both for later, if would be worth it.
Yeah, I wasn't 100% certain the queue/submit things were safe to use 
later given that you weren't. However, I think it definitely makes the 
code easier to maintain if %db is assumed to be the one true source of 
all information. Once that is constructed, all else can be forgotten 
about and all subsequent processing only needs to operate on that one 
data structure.






  $rings{$ring} = $gid++ unless exists $rings{$ring};
  $ringmap{$rings{$ring}} = $ring;
  $db{$key} = \%req;
@@ -458,8 +457,6 @@ while (<>) {
  $db{$key}->{'notify'} = $db{$key}->{'end'};
  $db{$key}->{'no-notify'} = 1;
  }
-    $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-    $db{$key}->{'context-complete-delay'} = $db{$key}->{'end'} - 
$db{$key}->{'notify'};

  } elsif ($tp_name eq 'i915:intel_engine_notify:') {
  $notify{global_key($ring, $seqno)} = $time;
  } elsif ($tp_name eq 'i915:intel_gpu_freq_change:') {
@@ -493,16 +490,11 @@ foreach my $key (keys %db) {
  $db{$key}->{'notify'} = $db{$key}->{'end'};
  $db{$key}->{'incomplete'} = 1;
  }
-
-    $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-    $db{$key}->{'context-complete-delay'} = $db{$key}->{'end'} - 
$db{$key}->{'notify'};

  } else {
  # Notify arrived after context complete.
  if (exists $db{$key}->{'no-notify'} and exists 
$notify{$gkey}) {

  delete $db{$key}->{'no-notify'};
  $db{$key}->{'notify'} = $notify{$gkey};
-    $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-    $db{$key}->{'context-complete-delay'} = 
$db{$key}->{'end'} - $db{$key}->{'notify'};

  }
  }
  }
@@ -529,8 +521,6 @@ foreach my $key (@keys) {
  if (exists $db{$next_key}) {
  $db{$key}->{'notify'} = $db{$next_key}->{'end'};
  $db{$key}->{'end'} = $db{$key}->{'notify'};
-    $db{$key}->{'duration'} = $db{$key}->{'notify'} - 
$db{$key}->{'start'};
-    $db{$key}->{'context-complete-delay'} = $db{$key}->{'end'} - 
$db{$key}->{'notify'};

  }
  }
  @@ -565,19 +555,14 @@ die "Database changed size?!" unless 
scalar(@sorted_keys) == $keyCount;

  foreach my $key (@sorted_keys) {
  my $ring = $db{$key}->{'ring'};
  my $end = $db{$key}->{'end'};
+    my $start = $db{$key}->{'start'};
+    my $notify = $db{$key}->{'notify'};


Why did you move/put these two here since they are not used outside 
the $correct_durations block? I'd avoid hash queries if not needed.


The code had mutated a lot before arriving at this point, yer honour. It 
all made sense at one point in time!




    $first_ts = $db{$key}->{'queue'} if not defined $first_ts or 
$db{$key}->{'queue'} < $first_ts;

  $last_ts = $end if $end > $last_ts;
  -    $running{$ring} += $end - $db{$key}->{'start'} unless exists 
$db{$key}->{'no-end'};

-    $runnable{$ring} += $db{$key}->{'execute-delay'};
-    $queued{$ring} += $db{$key}->{'start'} - 
$db{$key}->{'execute-delay'} - $db{$key}->{'queue'};

-
-    $batch_count{$ring}++;
-
  # correct duration of merged batches

Re: [Intel-gfx] [PATCH i-g-t 2/4] scripts/trace.pl: Sort order

[John Harrison]

On 1/22/2018 2:19 AM, Tvrtko Ursulin wrote:


On 20/01/2018 00:24, john.c.harri...@intel.com wrote:

From: John Harrison 

Add an extra level to the databse key sort so that the ordering is
deterministic. If the time stamp matches, it now compares the key
itself as well (context/seqno). This makes it much easier to determine
if a change has actually broken anything. Previously back to back runs
with no changes could still produce different output, especially when
adding extra debug output during the calculations.


Makes sense. I guess I never expected ns resolution time stamps to be 
different.


Computers are fast - ns is slow!




As the comparison test is now more than a single equation, moved it
out into a separate sort function.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
  scripts/trace.pl | 26 ++
  1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index 7b8a920e..cf841b7e 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -540,7 +540,25 @@ my (%submit_avg, %execute_avg, %ctxsave_avg);
  my $last_ts = 0;
  my $first_ts;
  -my @sorted_keys = sort {$db{$a}->{'start'} <=> $db{$b}->{'start'}} 
keys %db;

+sub sortStart {
+    my $as = $db{$a}->{'start'};
+    my $bs = $db{$b}->{'start'};
+
+    return $as <=> $bs if($as ne $bs);


In the spirit of the last round of optimising work, I would check if 
this is the most optimal way to write this. Perhaps it would be better 
with a single comparison on this line. And not mixing string and 
numerical context? Like:


my $val = $as <=> $bs;

$val = $a cmp $b if $val == 0;

return $val;

?
Six of one, half a dozen of another. Again, I would assume the compiler 
would be smart enough to make both versions equal but I'm happy to go 
with your version if you feel it is better.





+
+    return $a cmp $b;
+}
+
+sub sortQueue {
+    my $as = $db{$a}->{'queue'};
+    my $bs = $db{$b}->{'queue'};
+
+    return $as <=> $bs if($as ne $bs);
+
+    return $a cmp $b;
+}
+
+my @sorted_keys = sort sortStart keys %db;
  my $re_sort = 0;
  die "Database changed size?!" unless scalar(@sorted_keys) == 
$keyCount;

  @@ -589,9 +607,9 @@ foreach my $key (@sorted_keys) {
  $ctxsave_avg{$ring} += $db{$key}->{'end'} - $db{$key}->{'notify'};
  }
  -@sorted_keys = sort {$db{$a}->{'start'} <=> $db{$b}->{'start'}} 
keys %db if $re_sort;

+@sorted_keys = sort sortStart keys %db if $re_sort;
  -foreach my $ring (keys %batch_avg) {
+foreach my $ring (sort keys %batch_avg) {
  $batch_avg{$ring} /= $batch_count{$ring};
  $batch_total_avg{$ring} /= $batch_count{$ring};
  $submit_avg{$ring} /= $batch_count{$ring};
@@ -831,7 +849,7 @@ print <{'queue'} <=> $db{$b}->{'queue'}} 
keys %db) {

+foreach my $key (sort sortQueue keys %db) {
  my ($name, $ctx, $seqno) = ($db{$key}->{'name'}, 
$db{$key}->{'ctx'}, $db{$key}->{'seqno'});
  my ($queue, $start, $notify, $end) = ($db{$key}->{'queue'}, 
$db{$key}->{'start'}, $db{$key}->{'notify'}, $db{$key}->{'end'});

  my $submit = $queue + $db{$key}->{'submit-delay'};



Rest looks OK.

Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH i-g-t 1/4] scripts/trace.pl: More hash key optimisations

[John Harrison]

On 1/22/2018 2:14 AM, Tvrtko Ursulin wrote:


On 20/01/2018 00:24, john.c.harri...@intel.com wrote:

From: John Harrison 

Cache the key count value rather than querying the hash every time.


This actually makes a difference? Just curious, I would have assumed 
Perl would know the size of it's arrays but maybe the implementation 
is stupid...


Actually, I'm not sure it does anymore. I thought it did but I later 
decided that the change was actually just run to run noise. However, I 
already had the patch and I think it makes the code at least look 
simpler. IMHO, '$key_count' is easier to read than 'scalar(keys(%db))' 
and it is obviously trivial rather than relying on the compiler to be smart.




Btw I was using Devel::NTYProf in HTML output mode to profile my 
changes. It is quite easy to use and provided all the info I needed.



Also assert that the database does not magically change size after the
fixups.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
  scripts/trace.pl | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index cb93900d..7b8a920e 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -508,7 +508,9 @@ foreach my $key (keys %db) {
  }
    # Fix up incompletes
-foreach my $key (keys %db) {
+my @keys = keys(%db);


This array is unused except for the query below so I'd suggest to not 
have it.



+my $keyCount = scalar(@keys);


About came case.. I won't complain too the max, since I'm happy you 
are finding the tool useful and improving it, but it would be good to 
stay within the same style of variable naming or we'll have a 
mish-mash of styles which won't help readability.


Oops, I missed that. Habit and too many different style guides in too 
many different projects! I'll change it to $key_count instead.





Regards,

Tvrtko


+foreach my $key (@keys) {
  next unless exists $db{$key}->{'incomplete'};
    # End the incomplete batch at the time next one starts
@@ -522,7 +524,7 @@ foreach my $key (keys %db) {
  $next_key = db_key($ring, $ctx, $seqno + $i);
  $i++;
  } until ((exists $db{$next_key} and not exists 
$db{$next_key}->{'incomplete'})

- or $i > scalar(keys(%db)));  # ugly stop hack
+ or $i > $keyCount);  # ugly stop hack
    if (exists $db{$next_key}) {
  $db{$key}->{'notify'} = $db{$next_key}->{'end'};
@@ -540,6 +542,7 @@ my $first_ts;
    my @sorted_keys = sort {$db{$a}->{'start'} <=> 
$db{$b}->{'start'}} keys %db;

  my $re_sort = 0;
+die "Database changed size?!" unless scalar(@sorted_keys) == $keyCount;
    foreach my $key (@sorted_keys) {
  my $ring = $db{$key}->{'ring'};
@@ -565,7 +568,7 @@ foreach my $key (@sorted_keys) {
  do {
  $next_key = db_key($ring, $ctx, $seqno + $i);
  $i++;
-    } until (exists $db{$next_key} or $i > scalar(keys(%db)));  
# ugly stop hack
+    } until (exists $db{$next_key} or $i > $keyCount); # ugly 
stop hack

    # 20us tolerance
  if (exists $db{$next_key} and $db{$next_key}->{'start'} < 
$start + 20) {




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

[Intel-gfx] [PATCH 2/2] drm/dp: Add definitions for TPS4 bits and macros to check the support

[Manasi Navare]

DP 1.4 spec adds a TPS4 training pattern sequence required for
HBR3. This patch adds the corresponding bit definitions in
MAX_DOWNSPREAD register and TRAINING_PATTERN_SET and
inline functions to check if this bit is set and for selecting
a proper TRAINING_PATTERN_MASK that changed to 0x7 on
DP spec 1.4

Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Manasi Navare 
---
 include/drm/drm_dp_helper.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c80fa92..c239e6e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -75,6 +75,7 @@
 #define DP_MAX_DOWNSPREAD   0x003
 # define DP_MAX_DOWNSPREAD_0_5 (1 << 0)
 # define DP_NO_AUX_HANDSHAKE_LINK_TRAINING  (1 << 6)
+# define DP_TPS4_SUPPORTED  (1 << 7)
 
 #define DP_NORP 0x004
 
@@ -345,7 +346,9 @@
 # define DP_TRAINING_PATTERN_1 1
 # define DP_TRAINING_PATTERN_2 2
 # define DP_TRAINING_PATTERN_3 3   /* 1.2 */
+# define DP_TRAINING_PATTERN_4  7   /* 1.4 */
 # define DP_TRAINING_PATTERN_MASK  0x3
+# define DP_TRAINING_PATTERN_MASK_1_4  0xf
 
 /* DPCD 1.1 only. For DPCD >= 1.2 see per-lane DP_LINK_QUAL_LANEn_SET */
 # define DP_LINK_QUAL_PATTERN_11_DISABLE(0 << 2)
@@ -989,6 +992,20 @@ drm_dp_tps3_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 }
 
 static inline bool
+drm_dp_tps4_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_DPCD_REV] >= 0x14 &&
+   dpcd[DP_MAX_DOWNSPREAD] & DP_TPS4_SUPPORTED;
+}
+
+static inline u8
+drm_dp_training_pattern_mask(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return (dpcd[DP_DPCD_REV] >= 0x14) ? DP_TRAINING_PATTERN_MASK_1_4 :
+   DP_TRAINING_PATTERN_MASK;
+}
+
+static inline bool
 drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/2] drm/dp: Add HBR3 support in existing DRM DP helpers

[Manasi Navare]

Existing helpers add support upto HBR2. This patch
adds support for HBR3 rate (8.1 Gbps) introduced as
part of DP 1.4 specification.

Cc: Rodrigo Vivi 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_dp_helper.c   | 4 
 drivers/gpu/drm/drm_dp_mst_topology.c | 3 +++
 include/drm/drm_dp_helper.h   | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..ffe14ec 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -146,6 +146,8 @@ u8 drm_dp_link_rate_to_bw_code(int link_rate)
return DP_LINK_BW_2_7;
case 54:
return DP_LINK_BW_5_4;
+   case 81:
+   return DP_LINK_BW_8_1;
}
 }
 EXPORT_SYMBOL(drm_dp_link_rate_to_bw_code);
@@ -161,6 +163,8 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
return 27;
case DP_LINK_BW_5_4:
return 54;
+   case DP_LINK_BW_8_1:
+   return 81;
}
 }
 EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate);
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 70dcfa5..36df7df 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2087,6 +2087,9 @@ static bool drm_dp_get_vc_payload_bw(int dp_link_bw,
case DP_LINK_BW_5_4:
*out = 10 * dp_link_count;
break;
+   case DP_LINK_BW_8_1:
+   *out = 15 * dp_link_count;
+   break;
}
return true;
 }
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9d3ce3b..c80fa92 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -334,6 +334,7 @@
 # define DP_LINK_BW_1_62   0x06
 # define DP_LINK_BW_2_70x0a
 # define DP_LINK_BW_5_40x14/* 1.2 */
+# define DP_LINK_BW_8_10x1e/* 1.4 */
 
 #define DP_LANE_COUNT_SET  0x101
 # define DP_LANE_COUNT_MASK0x0f
-- 
2.7.4

___
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

[Michel Thierry]

On 22/01/18 13:28, Michal Wajdeczko wrote:
On Mon, 22 Jan 2018 21:56:36 +0100, Lucas De Marchi 
 wrote:



On Mon, Jan 22, 2018 at 12:32:57PM -0800, Michel Thierry wrote:

Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.

v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)

Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Lucas De Marchi 
Cc: Chris Wilson 
---


[ ... ]

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

new file mode 100644
index ..f50d63cb4b66
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2018 Intel Corporation

    
hmm, maybe years should be "2014-2018"



2014 because that's when these #define were originally added?


+ *
+ * Permission is hereby granted, free of charge, to any person 
obtaining a
+ * copy of this software and associated documentation files (the 
"Software"),
+ * to deal in the Software without restriction, including without 
limitation
+ * the rights to use, copy, modify, merge, publish, distribute, 
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom 
the

+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including 
the next
+ * paragraph) shall be included in all copies or substantial 
portions of the

+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO 
EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES 
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
ARISING

+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */


Looking at other files added after the SPDX change, it doesn't look
like we should duplicate the information about license. So in this case
AFAIU it should contain only the SPDX tag and the Copyright, but not
license text. See

git log --grep "Remove redundant license text"


Lucas De Marchi



and by looking at other examples I think best practice is to put this tag
right under a copyright line:

/*
  * Copyright © 2014-2018 Intel Corporation
  *
  * SPDX-License-Identifier: MIT
  */



Best practice, but not the most common:

$ git grep " \* SPDX-License-Identifier:" |wc -l
94

$ git grep "/\* SPDX-License-Identifier:" |wc -l
7822

Anyway it looks ok to me, objections?

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

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Fix DPLCLKA_CFGCR0 bits for Port F.

[Pandiyan, Dhinakaran]

On Fri, 2018-01-19 at 16:05 -0800, Rodrigo Vivi wrote:
> Since when it got introduced with commit '555e38d27317
> ("drm/i915/cnl: DDI - PLL mapping")' the support for Port F
> was wrong, because Port F bits are far from bits used
> for A to E.
> 
> Since Port F is not used so far we don't need to propagate
> Fixes back there.
> 
> v2: Reuse _SHIFT definition to avoid complicated duplication (DK).
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3ad9ad4a7918..861a7d5a27af 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8838,10 +8838,12 @@ enum skl_power_gate {
>   * CNL Clocks
>   */
>  #define DPCLKA_CFGCR0_MMIO(0x6C200)
> -#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port) (1 << ((port)+10))
> -#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)(3 << ((port)*2))
> -#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port)   ((port)*2)
> -#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)((pll) << ((port)*2))
> +#define  DPCLKA_CFGCR0_DDI_CLK_OFF(port) (1 << ((port) ==  PORT_F ? 23 : 
> \
> +   (port)+10))
> +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port)   ((port) == PORT_F ? 21 
> : \
> + (port)*2)

nit: I wouldn't bother with the new line, more readable without it. And
there seems to be plenty of places in that file where the 80 char limit
is exceeded.
 

Either way, patch looks correct.
Reviewed-by: Dhinakaran Pandiyan 


> +#define  DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port)(3 << 
> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
> +#define  DPCLKA_CFGCR0_DDI_CLK_SEL(pll, port)((pll) << 
> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port))
>  
>  /* CNL PLL */
>  #define DPLL0_ENABLE 0x46010
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Daniele Ceraolo Spurio]

On 22/01/18 09:32, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2018-01-22 16:09:28)



On 22/01/18 07:13, Chris Wilson wrote:

Quoting Mika Kuoppala (2018-01-22 15:08:16)

Daniele Ceraolo Spurio  writes:


On 19/01/18 05:05, Mika Kuoppala wrote:

Daniele Ceraolo Spurio  writes:


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,
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 ELSQ 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 Gen11+ 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)

Cc: Chris Wilson 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 


Was going to adopt this patch from Rodrigo but you were faster.

I choose to stash the elsq and use it as a gen11 vs rest toggle:

Relevant bits:

+static inline void write_port(struct intel_engine_execlists * const execlists,
+ unsigned int n,
+ u64 desc)
+{
+   if (execlists->elsq)
+   gen11_elsq_write(desc, n, execlists->elsq);
+   else
+   gen8_elsp_write(desc, execlists->elsp);
+}
+
+static inline void submit_ports(struct intel_engine_execlists * const 
execlists)
+{
+   /* for gen11+ we need to manually load the submit queue */
+   if (execlists->elsq) {
+   struct intel_engine_cs *engine =
+   container_of(execlists,
+struct intel_engine_cs,
+execlists);
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
+   }
+}
+



I was undecided about hiding the code in sub-functions because of the
pre-emption path. There is no need in gen11 to inject a context to
preempt to idle,


Really? The preempt-to-idle is so that we can sync the bookkeeping with
the pending CS interrupts. The HW doesn't require it currently either,
it's the SW that does. If you have a way to avoid that, that should be
applicable to the current code as well?
-Chris



We can't avoid preempt-to-idle, we can do it in a simpler way. There is
a bit in RING_EXECLIST_CONTROL that triggers a preemp-to-idle, without
the need to do a ctx injection. We'll need to move preemption completion
detection to the CSB value instead of the HWSP write, not sure about the
impact of that on our bookkeeping.


Ah, shucks :( I was hoping there's a simple way to avoid idling.

I have to ask, is it worth it? If we still have to do a CS interrupt
round trip, what's the difference? Hmm. I wonder if assume that the
preemption is nearly instantaneous (say 10us), we could short-circuit
the interrupt and poll. Falling back to interrupt if longer, and/or
resetting the GPU to guarantee latencies.
-Chris



The SW cost shouldn't be too bad, so having 1 less ctx switch should 
give us some some benefits. Trying a poll with a fall-back sounds nice, 
but we'll probably have to wait until we have timing info to see if the 
polling makes sense at all.


Daniele
___
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

[Michal Wajdeczko]

On Mon, 22 Jan 2018 21:56:36 +0100, Lucas De Marchi  
 wrote:



On Mon, Jan 22, 2018 at 12:32:57PM -0800, Michel Thierry wrote:

Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.

v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)

Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Lucas De Marchi 
Cc: Chris Wilson 
---


[ ... ]

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

new file mode 100644
index ..f50d63cb4b66
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2018 Intel Corporation

   
hmm, maybe years should be "2014-2018"


+ *
+ * Permission is hereby granted, free of charge, to any person  
obtaining a
+ * copy of this software and associated documentation files (the  
"Software"),
+ * to deal in the Software without restriction, including without  
limitation
+ * the rights to use, copy, modify, merge, publish, distribute,  
sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom  
the

+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including  
the next
+ * paragraph) shall be included in all copies or substantial portions  
of the

+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,  
EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF  
MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT  
SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES  
OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,  
ARISING

+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */


Looking at other files added after the SPDX change, it doesn't look
like we should duplicate the information about license. So in this case
AFAIU it should contain only the SPDX tag and the Copyright, but not
license text. See

git log --grep "Remove redundant license text"


Lucas De Marchi



and by looking at other examples I think best practice is to put this tag
right under a copyright line:

/*
 * Copyright © 2014-2018 Intel Corporation
 *
 * SPDX-License-Identifier: MIT
 */

Michal

___
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] drm/i915: Increase render/media power gating hysteresis for gen9+ (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2] drm/i915: Increase render/media power gating 
hysteresis for gen9+ (rev3)
URL   : https://patchwork.freedesktop.org/series/36842/
State : success

== Summary ==

Warning: bzip CI_DRM_3667/shard-glkb6/results7.json.bz2 wasn't in correct JSON 
format
Test kms_cursor_legacy:
Subgroup cursor-vs-flip-atomic:
fail   -> PASS   (shard-apl) fdo#103355
Subgroup flip-vs-cursor-legacy:
pass   -> FAIL   (shard-apl) fdo#102670
Test perf:
Subgroup buffer-fill:
fail   -> PASS   (shard-apl) fdo#103755
Subgroup oa-exponents:
fail   -> PASS   (shard-apl) fdo#102254
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
fail   -> PASS   (shard-snb) fdo#101623 +1

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

shard-apltotal:2780 pass:1716 dwarn:1   dfail:0   fail:23  skip:1040 
time:14666s
shard-hswtotal:2780 pass:1724 dwarn:1   dfail:0   fail:12  skip:1042 
time:15570s
shard-snbtotal:2780 pass:1317 dwarn:1   dfail:0   fail:13  skip:1449 
time:8120s
Blacklisted hosts:
shard-kbltotal:2780 pass:1835 dwarn:3   dfail:0   fail:26  skip:916 
time:11041s

== Logs ==

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

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

[Lucas De Marchi]

On Mon, Jan 22, 2018 at 12:32:57PM -0800, Michel Thierry wrote:
> Newer platforms may have subtle offset changes, which will increase the
> number of defines, so it is probably better to start moving them to its
> own header file. Also move the macros used while setting the reg state.
> 
> v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
> intel_guc_reg.h (Chris)
> 
> Signed-off-by: Michel Thierry 
> Cc: Michal Wajdeczko 
> Cc: Lucas De Marchi 
> Cc: Chris Wilson 
> ---

[ ... ]

> diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h 
> b/drivers/gpu/drm/i915/intel_lrc_reg.h
> new file mode 100644
> index ..f50d63cb4b66
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
> @@ -0,0 +1,78 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2018 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */

Looking at other files added after the SPDX change, it doesn't look
like we should duplicate the information about license. So in this case
AFAIU it should contain only the SPDX tag and the Copyright, but not
license text. See

git log --grep "Remove redundant license text"


Lucas De Marchi


> +
> +#ifndef _INTEL_LRC_REG_H_
> +#define _INTEL_LRC_REG_H_
> +
> +/* GEN8+ Reg State Context */
> +#define CTX_LRI_HEADER_0 0x01
> +#define CTX_CONTEXT_CONTROL  0x02
> +#define CTX_RING_HEAD0x04
> +#define CTX_RING_TAIL0x06
> +#define CTX_RING_BUFFER_START0x08
> +#define CTX_RING_BUFFER_CONTROL  0x0a
> +#define CTX_BB_HEAD_U0x0c
> +#define CTX_BB_HEAD_L0x0e
> +#define CTX_BB_STATE 0x10
> +#define CTX_SECOND_BB_HEAD_U 0x12
> +#define CTX_SECOND_BB_HEAD_L 0x14
> +#define CTX_SECOND_BB_STATE  0x16
> +#define CTX_BB_PER_CTX_PTR   0x18
> +#define CTX_RCS_INDIRECT_CTX 0x1a
> +#define CTX_RCS_INDIRECT_CTX_OFFSET  0x1c
> +#define CTX_LRI_HEADER_1 0x21
> +#define CTX_CTX_TIMESTAMP0x22
> +#define CTX_PDP3_UDW 0x24
> +#define CTX_PDP3_LDW 0x26
> +#define CTX_PDP2_UDW 0x28
> +#define CTX_PDP2_LDW 0x2a
> +#define CTX_PDP1_UDW 0x2c
> +#define CTX_PDP1_LDW 0x2e
> +#define CTX_PDP0_UDW 0x30
> +#define CTX_PDP0_LDW 0x32
> +#define CTX_LRI_HEADER_2 0x41
> +#define CTX_R_PWR_CLK_STATE  0x42
> +#define CTX_GPGPU_CSR_BASE_ADDRESS   0x44
> +
> +#define CTX_REG(reg_state, pos, reg, val) do { \
> + (reg_state)[(pos)+0] = i915_mmio_reg_offset(reg); \
> + (reg_state)[(pos)+1] = (val); \
> +} while (0)
> +
> +#define ASSIGN_CTX_PDP(ppgtt, reg_state, n) do { \
> + const u64 _addr = i915_page_dir_dma_addr((ppgtt), (n)); \
> + reg_state[CTX_PDP ## n ## _UDW+1] = upper_32_bits(_addr); \
> + reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
> +} while (0)
> +
> +#define ASSIGN_CTX_PML4(ppgtt, reg_state) do { \
> + reg_state[CTX_PDP0_UDW + 1] = upper_32_bits(px_dma(>pml4)); \
> + reg_state[CTX_PDP0_LDW + 1] = lower_32_bits(px_dma(>pml4)); \
> +} while (0)
> +
> +#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_DEFAULT0x19
> +
> +#endif /* _INTEL_LRC_REG_H_ */
> -- 
> 2.15.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move LRC register offsets to a header file (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Move LRC register offsets to a header file (rev2)
URL   : https://patchwork.freedesktop.org/series/36930/
State : success

== Summary ==

Series 36930v2 drm/i915: Move LRC register offsets to a header file
https://patchwork.freedesktop.org/api/1.0/series/36930/revisions/2/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:418s
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:483s
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:483s
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:465s
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:279s
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: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:418s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
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:454s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:499s
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:503s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
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:507s
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:490s
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:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:517s
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:575s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:471s
fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7746/fi-bdw-gvtdvm/igt.log

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
1fffb939 drm/i915: Move LRC register offsets to a header file

== Logs ==

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

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

[Michel Thierry]

Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.

v2: Rename to intel_lrc_reg.h, to be consistent with i915_reg.h and
intel_guc_reg.h (Chris)

Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Lucas De Marchi 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_lrc.c | 50 +--
 drivers/gpu/drm/i915/intel_lrc_reg.h | 78 
 2 files changed, 79 insertions(+), 49 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lrc_reg.h

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 506bc2bc04f9..3cf30b982524 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_gem_render_state.h"
+#include "intel_lrc_reg.h"
 #include "intel_mocs.h"
 
 #define RING_EXECLIST_QFULL(1 << 0x2)
@@ -156,55 +157,6 @@
 #define GEN8_CTX_STATUS_COMPLETED_MASK \
 (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
 
-#define CTX_LRI_HEADER_0   0x01
-#define CTX_CONTEXT_CONTROL0x02
-#define CTX_RING_HEAD  0x04
-#define CTX_RING_TAIL  0x06
-#define CTX_RING_BUFFER_START  0x08
-#define CTX_RING_BUFFER_CONTROL0x0a
-#define CTX_BB_HEAD_U  0x0c
-#define CTX_BB_HEAD_L  0x0e
-#define CTX_BB_STATE   0x10
-#define CTX_SECOND_BB_HEAD_U   0x12
-#define CTX_SECOND_BB_HEAD_L   0x14
-#define CTX_SECOND_BB_STATE0x16
-#define CTX_BB_PER_CTX_PTR 0x18
-#define CTX_RCS_INDIRECT_CTX   0x1a
-#define CTX_RCS_INDIRECT_CTX_OFFSET0x1c
-#define CTX_LRI_HEADER_1   0x21
-#define CTX_CTX_TIMESTAMP  0x22
-#define CTX_PDP3_UDW   0x24
-#define CTX_PDP3_LDW   0x26
-#define CTX_PDP2_UDW   0x28
-#define CTX_PDP2_LDW   0x2a
-#define CTX_PDP1_UDW   0x2c
-#define CTX_PDP1_LDW   0x2e
-#define CTX_PDP0_UDW   0x30
-#define CTX_PDP0_LDW   0x32
-#define CTX_LRI_HEADER_2   0x41
-#define CTX_R_PWR_CLK_STATE0x42
-#define CTX_GPGPU_CSR_BASE_ADDRESS 0x44
-
-#define CTX_REG(reg_state, pos, reg, val) do { \
-   (reg_state)[(pos)+0] = i915_mmio_reg_offset(reg); \
-   (reg_state)[(pos)+1] = (val); \
-} while (0)
-
-#define ASSIGN_CTX_PDP(ppgtt, reg_state, n) do {   \
-   const u64 _addr = i915_page_dir_dma_addr((ppgtt), (n)); \
-   reg_state[CTX_PDP ## n ## _UDW+1] = upper_32_bits(_addr); \
-   reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
-} while (0)
-
-#define ASSIGN_CTX_PML4(ppgtt, reg_state) do { \
-   reg_state[CTX_PDP0_UDW + 1] = upper_32_bits(px_dma(>pml4)); \
-   reg_state[CTX_PDP0_LDW + 1] = lower_32_bits(px_dma(>pml4)); \
-} while (0)
-
-#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
-
 /* Typical size of the average request (2 pipecontrols and a MI_BB) */
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 #define WA_TAIL_DWORDS 2
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg.h 
b/drivers/gpu/drm/i915/intel_lrc_reg.h
new file mode 100644
index ..f50d63cb4b66
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lrc_reg.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef 

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

[Michel Thierry]

On 1/22/2018 12:14 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-01-22 20:06:32)

Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.


I was scared that we might be starting to duplicate the lrc setup
code. If you can see a quick way of splitting the lrc setup from
execlists submission, that would also be good.
  


At the very least, we will need different implementations of 
execlists_init_reg_state.




Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Lucas De Marchi 
---
  drivers/gpu/drm/i915/intel_lrc.c | 50 +-
  drivers/gpu/drm/i915/intel_lrc_reg_offsets.h | 78 
  2 files changed, 79 insertions(+), 49 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/intel_lrc_reg_offsets.h

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 506bc2bc04f9..bc9287645bf3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
  #include 
  #include "i915_drv.h"
  #include "i915_gem_render_state.h"
+#include "intel_lrc_reg_offsets.h"


Just intel_lrc_reg.h to be consistent with i915_reg.h and
intel_guc_reg.h

The numbers look the same, so with a new filename,
Reviewed-by: Chris Wilson 


Thanks, I'll resend it with the new filename.


-Chris


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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move LRC register offsets to a header file

[Patchwork]

== Series Details ==

Series: drm/i915: Move LRC register offsets to a header file
URL   : https://patchwork.freedesktop.org/series/36930/
State : success

== Summary ==

Series 36930v1 drm/i915: Move LRC register offsets to a header file
https://patchwork.freedesktop.org/api/1.0/series/36930/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700k2) fdo#104108
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#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
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: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:488s
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:483s
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:469s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
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:519s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
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:418s
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: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:499s
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:504s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:579s
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:526s
fi-skl-6700k2total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:498s
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:416s
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:527s
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:570s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
8b448bc12149 drm/i915: Move LRC register offsets to a header file

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7745/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: Move LRC register offsets to a header file

[Chris Wilson]

Quoting Michel Thierry (2018-01-22 20:06:32)
> Newer platforms may have subtle offset changes, which will increase the
> number of defines, so it is probably better to start moving them to its
> own header file. Also move the macros used while setting the reg state.

I was scared that we might be starting to duplicate the lrc setup
code. If you can see a quick way of splitting the lrc setup from
execlists submission, that would also be good.
 
> Signed-off-by: Michel Thierry 
> Cc: Michal Wajdeczko 
> Cc: Lucas De Marchi 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 50 +-
>  drivers/gpu/drm/i915/intel_lrc_reg_offsets.h | 78 
> 
>  2 files changed, 79 insertions(+), 49 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_lrc_reg_offsets.h
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 506bc2bc04f9..bc9287645bf3 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -137,6 +137,7 @@
>  #include 
>  #include "i915_drv.h"
>  #include "i915_gem_render_state.h"
> +#include "intel_lrc_reg_offsets.h"

Just intel_lrc_reg.h to be consistent with i915_reg.h and
intel_guc_reg.h

The numbers look the same, so with a new filename,
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/i915: Move LRC register offsets to a header file

[Michel Thierry]

Newer platforms may have subtle offset changes, which will increase the
number of defines, so it is probably better to start moving them to its
own header file. Also move the macros used while setting the reg state.

Signed-off-by: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Lucas De Marchi 
---
 drivers/gpu/drm/i915/intel_lrc.c | 50 +-
 drivers/gpu/drm/i915/intel_lrc_reg_offsets.h | 78 
 2 files changed, 79 insertions(+), 49 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lrc_reg_offsets.h

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 506bc2bc04f9..bc9287645bf3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -137,6 +137,7 @@
 #include 
 #include "i915_drv.h"
 #include "i915_gem_render_state.h"
+#include "intel_lrc_reg_offsets.h"
 #include "intel_mocs.h"
 
 #define RING_EXECLIST_QFULL(1 << 0x2)
@@ -156,55 +157,6 @@
 #define GEN8_CTX_STATUS_COMPLETED_MASK \
 (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED)
 
-#define CTX_LRI_HEADER_0   0x01
-#define CTX_CONTEXT_CONTROL0x02
-#define CTX_RING_HEAD  0x04
-#define CTX_RING_TAIL  0x06
-#define CTX_RING_BUFFER_START  0x08
-#define CTX_RING_BUFFER_CONTROL0x0a
-#define CTX_BB_HEAD_U  0x0c
-#define CTX_BB_HEAD_L  0x0e
-#define CTX_BB_STATE   0x10
-#define CTX_SECOND_BB_HEAD_U   0x12
-#define CTX_SECOND_BB_HEAD_L   0x14
-#define CTX_SECOND_BB_STATE0x16
-#define CTX_BB_PER_CTX_PTR 0x18
-#define CTX_RCS_INDIRECT_CTX   0x1a
-#define CTX_RCS_INDIRECT_CTX_OFFSET0x1c
-#define CTX_LRI_HEADER_1   0x21
-#define CTX_CTX_TIMESTAMP  0x22
-#define CTX_PDP3_UDW   0x24
-#define CTX_PDP3_LDW   0x26
-#define CTX_PDP2_UDW   0x28
-#define CTX_PDP2_LDW   0x2a
-#define CTX_PDP1_UDW   0x2c
-#define CTX_PDP1_LDW   0x2e
-#define CTX_PDP0_UDW   0x30
-#define CTX_PDP0_LDW   0x32
-#define CTX_LRI_HEADER_2   0x41
-#define CTX_R_PWR_CLK_STATE0x42
-#define CTX_GPGPU_CSR_BASE_ADDRESS 0x44
-
-#define CTX_REG(reg_state, pos, reg, val) do { \
-   (reg_state)[(pos)+0] = i915_mmio_reg_offset(reg); \
-   (reg_state)[(pos)+1] = (val); \
-} while (0)
-
-#define ASSIGN_CTX_PDP(ppgtt, reg_state, n) do {   \
-   const u64 _addr = i915_page_dir_dma_addr((ppgtt), (n)); \
-   reg_state[CTX_PDP ## n ## _UDW+1] = upper_32_bits(_addr); \
-   reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
-} while (0)
-
-#define ASSIGN_CTX_PML4(ppgtt, reg_state) do { \
-   reg_state[CTX_PDP0_UDW + 1] = upper_32_bits(px_dma(>pml4)); \
-   reg_state[CTX_PDP0_LDW + 1] = lower_32_bits(px_dma(>pml4)); \
-} while (0)
-
-#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
-
 /* Typical size of the average request (2 pipecontrols and a MI_BB) */
 #define EXECLISTS_REQUEST_SIZE 64 /* bytes */
 #define WA_TAIL_DWORDS 2
diff --git a/drivers/gpu/drm/i915/intel_lrc_reg_offsets.h 
b/drivers/gpu/drm/i915/intel_lrc_reg_offsets.h
new file mode 100644
index ..4918dbf02244
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lrc_reg_offsets.h
@@ -0,0 +1,78 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _INTEL_LRC_REG_OFFSETS_H_
+#define _INTEL_LRC_REG_OFFSETS_H_
+
+/* GEN8+ Reg State Context */
+#define 

[Intel-gfx] ✓ Fi.CI.BAT: success for Queued/runnable/running engine stats

[Patchwork]

== Series Details ==

Series: Queued/runnable/running engine stats
URL   : https://patchwork.freedesktop.org/series/36926/
State : success

== Summary ==

Series 36926v1 Queued/runnable/running engine stats
https://patchwork.freedesktop.org/api/1.0/series/36926/revisions/1/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> INCOMPLETE (fi-blb-e6850) fdo#101600 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
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:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:146  pass:114  dwarn:0   dfail:0   fail:0   skip:31 
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
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:485s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-elk-e7500 total:224  pass:168  dwarn:9   dfail:1   fail:0   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:517s
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:398s
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:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
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:502s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-pnv-d510  total:146  pass:113  dwarn:0   dfail:0   fail:0   skip:32 
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:506s
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:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
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:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:520s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:399s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
04a7a34b2eb0 drm/i915/pmu: Add running counter
72966345ddb8 drm/i915/pmu: Add runnable counter
a1536333b48a drm/i915/pmu: Add queued counter
ccc54acc0b69 drm/i915: Keep a count of requests submitted from userspace
209a5eb505fd drm/i915: Keep a count of requests waiting for a slot on GPU
b7740c97908f drm/i915/pmu: Fix enable count array size and bounds checking

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Reinitialize sink scrambling/TMDS clock ratio on HPD

[Ville Syrjälä]

On Mon, Jan 22, 2018 at 12:07:28PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 1/13/2018 2:34 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > The LG 4k TV I have doesn't deassert HPD when I turn the TV off, but
> > when I turn it back on it will pulse the HPD line. By that time it has
> > forgotten everything we told it about scrambling and the clock ratio.
> > Hence if we want to get a picture out if it again we have to tell it
> > whether we're currently sending scrambled data or not. Implement
> > that via the encoder->hotplug() hook.
> >
> > v2: Force a full modeset to not follow the HDMI 2.0 spec more
> >  closely (Shashank)
> >
> > Cc: Shashank Sharma 
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_ddi.c | 146 
> > ++-
> >   1 file changed, 145 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 1aeae3e97013..25793bdc692f 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -25,6 +25,7 @@
> >*
> >*/
> >   
> > +#include 
> >   #include "i915_drv.h"
> >   #include "intel_drv.h"
> >   
> > @@ -2756,6 +2757,146 @@ intel_ddi_init_dp_connector(struct 
> > intel_digital_port *intel_dig_port)
> > return connector;
> >   }
> >   
> > +static int modeset_pipe(struct drm_crtc *crtc,
> > +   struct drm_modeset_acquire_ctx *ctx)
> Should this function go to intel_atomic.c or similar ?

Do you have another user for it? If not I don't see a particularly
good reason for moving it out.

> Also a little 
> documentation about
> usage will be helpful for others, who want to reuse this.

What should it say? To me the function name is pretty clear.

> > +{
> > +   struct drm_atomic_state *state;
> > +   struct drm_crtc_state *crtc_state;
> > +   int ret;
> > +
> > +   state = drm_atomic_state_alloc(crtc->dev);
> > +   if (!state)
> > +   return -ENOMEM;
> > +
> > +   state->acquire_ctx = ctx;
> > +
> > +   crtc_state = drm_atomic_get_crtc_state(state, crtc);
> > +   if (IS_ERR(crtc_state)) {
> > +   ret = PTR_ERR(crtc_state);
> > +   goto out;
> > +   }
> > +
> > +   crtc_state->mode_changed = true;
> > +
> > +   ret = drm_atomic_add_affected_connectors(state, crtc);
> > +   if (ret)
> > +   goto out;
> > +
> > +   ret = drm_atomic_add_affected_planes(state, crtc);
> > +   if (ret)
> > +   goto out;
> > +
> > +   ret = drm_atomic_commit(state);
> > +   if (ret)
> > +   goto out;
> > +
> As this is an internal modeset trigger, should we send an event to 
> userspace about this ?

What would userspace do with such an event?

> > +   return 0;
> > +
> > + out:
> one debug message here telling us about if modeset was success/fail ?

There's a WARN already higher up.

> > +   drm_atomic_state_put(state);
> > +
> > +   return ret;
> > +}
> > +
> > +static int intel_hdmi_reset_link(struct intel_encoder *encoder,
> > +struct drm_modeset_acquire_ctx *ctx)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   struct intel_hdmi *hdmi = enc_to_intel_hdmi(>base);
> > +   struct intel_connector *connector = hdmi->attached_connector;
> > +   struct i2c_adapter *adapter =
> > +   intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
> > +   struct drm_connector_state *conn_state;
> > +   struct intel_crtc_state *crtc_state;
> > +   struct intel_crtc *crtc;
> > +   u8 config;
> > +   int ret;
> > +
> > +   if (!connector || connector->base.status != connector_status_connected)
> > +   return 0;
> > +
> > +   ret = drm_modeset_lock(_priv->drm.mode_config.connection_mutex, 
> > ctx);
> > +   if (ret)
> > +   return ret;
> > +
> > +   conn_state = connector->base.state;
> > +
> > +   crtc = to_intel_crtc(conn_state->crtc);
> > +   if (!crtc)
> > +   return 0;
> > +
> > +   ret = drm_modeset_lock(>base.mutex, ctx);
> > +   if (ret)
> > +   return ret;
> > +
> > +   crtc_state = to_intel_crtc_state(crtc->base.state);
> > +
> > +   WARN_ON(!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI));
> > +
> > +   if (!crtc_state->base.active)
> > +   return 0;
> > +
> > +   if (!crtc_state->hdmi_high_tmds_clock_ratio &&
> > +   !crtc_state->hdmi_scrambling)
> > +   return 0;
> > +
> > +   if (conn_state->commit &&
> > +   !try_wait_for_completion(_state->commit->hw_done))
> > +   return 0;
> > +
> > +   ret = drm_scdc_readb(adapter, SCDC_TMDS_CONFIG, );
> > +   if (ret < 0) {
> > +   DRM_ERROR("Failed to read TMDS config: %d\n", ret);
> > +   return 0;
> > +   }
> We can export this read as helper in scdc_helper.c, something like 
> 

Re: [Intel-gfx] [PATCH 2/3] drm/i915/: Initialise trans_min for skl_compute_transition_wm()

[Chris Wilson]

Quoting Rodrigo Vivi (2017-11-16 01:12:15)
> On Wed, Nov 15, 2017 at 10:50:35AM +, Chris Wilson wrote:
> > clang spots
> > 
> > drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is 
> > used uninitialized whenever 'if' condition is false 
> > [-Wsometimes-uninitialized]
> > if (INTEL_GEN(dev_priv) >= 10)
> > 
> > but fortunately for us we skip the function unless on a gen10+ device.
> > However, to keep the function generic in case we do want to re-enable it
> > for gen9 again, initialise trans_min to 0.
> 
> Based on this comment:  /* Transition WM are not recommended by HW team for 
> GEN9 */
> 
> I believe the function should be called cnl_compute_transition_wm
> 
> plus:
> 
> -  uint16_t trans_min, trans_y_tile_min;
> +  u16 trans_min = 4, trans_y_tile_min;
> 
> -  if (INTEL_GEN(dev_priv) >= 10)
> -   trans_min = 4;
> 
> Also Wa for CNL A0 can be removed... We never put our hands in on A0...
> 
> But in case you want to go with the quick fix:
> Reviewed-by: Rodrigo Vivi 

This code still hasn't been fixed. At this rate I'll merge this patch
just to suppress the compiler warning... But please fix the code!
 
> up to you.
> 
> > 
> > References: ca47667f523e ("drm/i915/gen10: Calculate and enable transition 
> > WM")
> > Signed-off-by: Chris Wilson 
> > Cc: Mahesh Kumar 
> > Cc: Maarten Lankhorst 
> > Cc: Jani Nikula 
> > Cc: Joonas Lahtinen 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 8c69ec9eb6ee..5d8babfaec30 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4649,6 +4649,7 @@ static void skl_compute_transition_wm(struct 
> > intel_crtc_state *cstate,
> >   if (!dev_priv->ipc_enabled)
> >   goto exit;
> >  
> > + trans_min = 0;
> >   if (INTEL_GEN(dev_priv) >= 10)
> >   trans_min = 4;
> >  
> > -- 
> > 2.15.0
> > 
> 
___
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/breadcrumbs: Drop request reference for the signaler thread

[Patchwork]

== Series Details ==

Series: drm/i915/breadcrumbs: Drop request reference for the signaler thread
URL   : https://patchwork.freedesktop.org/series/36908/
State : success

== Summary ==

Series 36908v1 drm/i915/breadcrumbs: Drop request reference for the signaler 
thread
https://patchwork.freedesktop.org/api/1.0/series/36908/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (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:420s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
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:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45 
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:392s
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:466s
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:460s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:494s
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:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:434s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:515s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:530s
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:491s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:422s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:516s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:398s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
a40183e96a23 drm/i915/breadcrumbs: Drop request reference for the signaler 
thread

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7743/issues.html
___
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

[Chris Wilson]

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.
-Chris
___
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-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? :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 2/6] drm/i915: Keep a count of requests waiting for a slot on GPU

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-22 18:43:54)
> From: Tvrtko Ursulin 
> 
> Keep a per-engine number of runnable (waiting for GPU time) requests.
> 
> v2:
>  * Move queued increment from insert_request to execlist_submit_request to
>avoid bumping when re-ordering for priority.
>  * Support the counter on the ringbuffer submission path as well, albeit
>just notionally. (Chris Wilson)
> 
> v3:
>  * Rebase.
> 
> v4:
>  * Rename and move the stats into a container structure. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  drivers/gpu/drm/i915/i915_gem_request.c | 7 +++
>  drivers/gpu/drm/i915/intel_engine_cs.c  | 5 +++--
>  drivers/gpu/drm/i915/intel_lrc.c| 2 ++
>  drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
>  4 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index a0f451b4a4e8..8da350bacff1 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -502,6 +502,9 @@ void __i915_gem_request_submit(struct 
> drm_i915_gem_request *request)
> engine->emit_breadcrumb(request,
> request->ring->vaddr + request->postfix);
>  
> +   GEM_BUG_ON(engine->request_stats.runnable == 0);
> +   engine->request_stats.runnable--;
> +
> spin_lock(>timeline->lock);
> list_move_tail(>link, >requests);
> spin_unlock(>timeline->lock);
> @@ -517,6 +520,8 @@ void i915_gem_request_submit(struct drm_i915_gem_request 
> *request)
> /* Will be called from irq-context when using foreign fences. */
> spin_lock_irqsave(>timeline->lock, flags);
>  
> +   engine->request_stats.runnable++;
> +
> __i915_gem_request_submit(request);
>  
> spin_unlock_irqrestore(>timeline->lock, flags);
> @@ -548,6 +553,8 @@ void __i915_gem_request_unsubmit(struct 
> drm_i915_gem_request *request)
> timeline = request->timeline;
> GEM_BUG_ON(timeline == engine->timeline);
>  
> +   engine->request_stats.runnable++;
> +
> spin_lock(>lock);
> list_move(>link, >requests);
> spin_unlock(>lock);
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 7eebfbb95e89..8377a77cfbe7 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1731,12 +1731,13 @@ void intel_engine_dump(struct intel_engine_cs *engine,
> if (i915_terminally_wedged(>i915->gpu_error))
> drm_printf(m, "*** WEDGED ***\n");
>  
> -   drm_printf(m, "current seqno %x, last %x, hangcheck %x [%d ms], 
> inflight %d\n",
> +   drm_printf(m, "current seqno %x, last %x, hangcheck %x [%d ms], 
> inflight %d, runnable %u\n",
>intel_engine_get_seqno(engine),
>intel_engine_last_submit(engine),
>engine->hangcheck.seqno,
>jiffies_to_msecs(jiffies - 
> engine->hangcheck.action_timestamp),
> -  engine->timeline->inflight_seqnos);
> +  engine->timeline->inflight_seqnos,
> +  engine->request_stats.runnable);
> drm_printf(m, "Reset count: %d (global %d)\n",
>i915_reset_engine_count(error, engine),
>i915_reset_count(error));
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 51e61b04a555..319937e67a6e 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -965,6 +965,8 @@ static void execlists_submit_request(struct 
> drm_i915_gem_request *request)
> /* Will be called from irq-context when using foreign fences. */
> spin_lock_irqsave(>timeline->lock, flags);
>  
> +   engine->request_stats.runnable++;
> +
> insert_request(engine, >priotree, 
> request->priotree.priority);
>  
> GEM_BUG_ON(!engine->execlists.first);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 27a0c47db51e..d7ee7831288d 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -303,6 +303,15 @@ struct intel_engine_cs {
> struct intel_ring *buffer;
> struct intel_timeline *timeline;
>  
> +   struct {
> +   /**
> +* @runnable: Number of runnable requests sent to the backend.
> +*
> +* Count of requests waiting for the GPU to execute them.
> +*/
> +   unsigned int runnable;
> +   } request_stats;
> +
> struct drm_i915_gem_object *default_state;

Just thinking about easy holes, probably want to keep the pointer above
next to the other pointers. I'll let you argue cachelines ;)
-Chris

[Intel-gfx] [RFC 3/6] drm/i915: Keep a count of requests submitted from userspace

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Keep a count of requests submitted from userspace and not yet runnable due
unresolved dependencies.

v2: Rename and move under the container struct. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 3 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.h | 8 
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8da350bacff1..125a598b886c 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -599,6 +599,7 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
rcu_read_lock();
request->engine->submit_request(request);
rcu_read_unlock();
+   atomic_dec(>engine->request_stats.queued);
break;
 
case FENCE_FREE:
@@ -1067,6 +1068,8 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
if (engine->schedule)
engine->schedule(request, request->ctx->priority);
 
+   atomic_inc(>request_stats.queued);
+
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 8377a77cfbe7..46b2a92cb7a2 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1731,12 +1731,13 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d, runnable %u\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d, queued %u, runnable %u\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
   engine->hangcheck.seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp),
   engine->timeline->inflight_seqnos,
+  atomic_read(>request_stats.queued),
   engine->request_stats.runnable);
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d7ee7831288d..4519788cc5a1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -304,6 +304,14 @@ struct intel_engine_cs {
struct intel_timeline *timeline;
 
struct {
+   /**
+* @queued: Number of submitted requests with dependencies.
+*
+* Count of requests waiting for dependencies before they can be
+* submitted to the backend.
+*/
+   atomic_t queued;
+
/**
 * @runnable: Number of runnable requests sent to the backend.
 *
-- 
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/i915/pmu: Add queued counter

[Tvrtko Ursulin]

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));
}
 
if (fw)
@@ -297,6 +303,7 @@ engine_event_status(struct intel_engine_cs *engine,
switch (sample) {
case I915_SAMPLE_BUSY:
case I915_SAMPLE_WAIT:
+   case I915_SAMPLE_QUEUED:
break;
case I915_SAMPLE_SEMA:
if (INTEL_GEN(engine->i915) < 6)
@@ -407,6 +414,9 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
} else {
val = engine->pmu.sample[sample].cur;
}
+
+   if (sample == I915_SAMPLE_QUEUED)
+   val = div_u64(val, FREQUENCY);
} else {
switch (event->attr.config) {
case I915_PMU_ACTUAL_FREQUENCY:
@@ -719,6 +729,16 @@ static const struct attribute_group 
*i915_pmu_attr_groups[] = {
 { \
.sample = (__sample), \
.name = (__name), \
+   .suffix = "unit", \
+   .value = "ns", \
+}
+
+#define __engine_event_scale(__sample, __name, __scale) \
+{ \
+   .sample = (__sample), \
+   .name = (__name), \
+   .suffix = "scale", \
+   .value = (__scale), \
 }
 
 static struct i915_ext_attribute *
@@ -746,6 +766,9 @@ add_pmu_attr(struct perf_pmu_events_attr *attr, const char 
*name,
return ++attr;
 }
 
+/* No brackets or quotes below please. */
+#define I915_SAMPLE_QUEUED_SCALE 0.01
+
 static struct attribute **
 create_event_attributes(struct drm_i915_private *i915)
 {
@@ -762,10 +785,14 @@ create_event_attributes(struct drm_i915_private *i915)
static const struct {
enum drm_i915_pmu_engine_sample sample;
char *name;
+   char *suffix;
+   char *value;
} engine_events[] = {
__engine_event(I915_SAMPLE_BUSY, "busy"),
__engine_event(I915_SAMPLE_SEMA, "sema"),
__engine_event(I915_SAMPLE_WAIT, "wait"),
+   __engine_event_scale(I915_SAMPLE_QUEUED, "queued",
+__stringify(I915_SAMPLE_QUEUED_SCALE)),
};
unsigned int count = 0;
struct perf_pmu_events_attr *pmu_attr = NULL, *pmu_iter;
@@ -775,6 +802,9 @@ create_event_attributes(struct drm_i915_private *i915)
enum intel_engine_id id;
unsigned int i;
 
+   BUILD_BUG_ON(I915_SAMPLE_QUEUED_DIVISOR !=
+(1 / I915_SAMPLE_QUEUED_SCALE));
+
/* Count how many counters we will be exposing. */
for (i = 0; i < ARRAY_SIZE(events); i++) {
if (!config_status(i915, events[i].config))
@@ -852,13 +882,15 @@ create_event_attributes(struct drm_i915_private *i915)

engine->instance,

engine_events[i].sample));
 
-   str = kasprintf(GFP_KERNEL, "%s-%s.unit",
-   engine->name, engine_events[i].name);
+   str = kasprintf(GFP_KERNEL, "%s-%s.%s",
+   engine->name, engine_events[i].name,
+   engine_events[i].suffix);
if (!str)
goto err;
 
*attr_iter++ = _iter->attr.attr;
-   pmu_iter = add_pmu_attr(pmu_iter, str, 

[Intel-gfx] [RFC 5/6] drm/i915/pmu: Add runnable counter

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We add a PMU counter to expose the number of requests with resolved
dependencies waiting for a slot on the GPU to run.

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

v2: Don't limit to gen8+.

v3:
 * Rebase for dynamic sysfs.
 * Drop currently executing requests.

v4:
 * Sync with internal renaming.
 * Drop floating point constant. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_pmu.c | 18 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 include/uapi/drm/i915_drm.h |  7 ++-
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 8eefdf09a30a..f332eff6d057 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -37,7 +37,8 @@
(BIT(I915_SAMPLE_BUSY) | \
 BIT(I915_SAMPLE_WAIT) | \
 BIT(I915_SAMPLE_SEMA) | \
-BIT(I915_SAMPLE_QUEUED))
+BIT(I915_SAMPLE_QUEUED) | \
+BIT(I915_SAMPLE_RUNNABLE))
 
 #define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
 
@@ -226,6 +227,11 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
update_sample(>pmu.sample[I915_SAMPLE_QUEUED],
  I915_SAMPLE_QUEUED_DIVISOR,
  
atomic_read(>request_stats.queued));
+
+   if (engine->pmu.enable & BIT(I915_SAMPLE_RUNNABLE))
+   update_sample(>pmu.sample[I915_SAMPLE_RUNNABLE],
+ I915_SAMPLE_RUNNABLE_DIVISOR,
+ engine->request_stats.runnable);
}
 
if (fw)
@@ -304,6 +310,7 @@ engine_event_status(struct intel_engine_cs *engine,
case I915_SAMPLE_BUSY:
case I915_SAMPLE_WAIT:
case I915_SAMPLE_QUEUED:
+   case I915_SAMPLE_RUNNABLE:
break;
case I915_SAMPLE_SEMA:
if (INTEL_GEN(engine->i915) < 6)
@@ -415,7 +422,8 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
val = engine->pmu.sample[sample].cur;
}
 
-   if (sample == I915_SAMPLE_QUEUED)
+   if (sample == I915_SAMPLE_QUEUED ||
+   sample == I915_SAMPLE_RUNNABLE)
val = div_u64(val, FREQUENCY);
} else {
switch (event->attr.config) {
@@ -768,6 +776,7 @@ add_pmu_attr(struct perf_pmu_events_attr *attr, const char 
*name,
 
 /* No brackets or quotes below please. */
 #define I915_SAMPLE_QUEUED_SCALE 0.01
+#define I915_SAMPLE_RUNNABLE_SCALE 0.01
 
 static struct attribute **
 create_event_attributes(struct drm_i915_private *i915)
@@ -793,6 +802,8 @@ create_event_attributes(struct drm_i915_private *i915)
__engine_event(I915_SAMPLE_WAIT, "wait"),
__engine_event_scale(I915_SAMPLE_QUEUED, "queued",
 __stringify(I915_SAMPLE_QUEUED_SCALE)),
+   __engine_event_scale(I915_SAMPLE_RUNNABLE, "runnable",
+__stringify(I915_SAMPLE_RUNNABLE_SCALE)),
};
unsigned int count = 0;
struct perf_pmu_events_attr *pmu_attr = NULL, *pmu_iter;
@@ -805,6 +816,9 @@ create_event_attributes(struct drm_i915_private *i915)
BUILD_BUG_ON(I915_SAMPLE_QUEUED_DIVISOR !=
 (1 / I915_SAMPLE_QUEUED_SCALE));
 
+   BUILD_BUG_ON(I915_SAMPLE_RUNNABLE_DIVISOR !=
+(1 / I915_SAMPLE_RUNNABLE_SCALE));
+
/* Count how many counters we will be exposing. */
for (i = 0; i < ARRAY_SIZE(events); i++) {
if (!config_status(i915, events[i].config))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 580f07b2a5dd..a06f1fc0c150 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -381,7 +381,7 @@ struct intel_engine_cs {
 *
 * Our internal timer stores the current counters in this field.
 */
-#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_QUEUED + 1)
+#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_RUNNABLE + 1)
struct i915_pmu_sample sample[I915_ENGINE_SAMPLE_MAX];
/**
 * @busy_stats: Has enablement of engine stats tracking been
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 968bdc3269cb..05951839abe0 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -111,11 +111,13 @@ enum drm_i915_pmu_engine_sample {
I915_SAMPLE_BUSY = 0,
I915_SAMPLE_WAIT = 1,
I915_SAMPLE_SEMA = 2,
-   I915_SAMPLE_QUEUED = 3
+   I915_SAMPLE_QUEUED = 3,
+   I915_SAMPLE_RUNNABLE = 4,
 };
 
  /* Divide counter value by divisor to get the real value. */
 #define 

[Intel-gfx] [RFC 6/6] drm/i915/pmu: Add running counter

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

We add a PMU counter to expose the number of requests currently executing
on the GPU.

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

v2:
 * Rebase.
 * Drop floating point constant. (Chris Wilson)

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

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index f332eff6d057..86d9b9fb6aef 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -38,7 +38,8 @@
 BIT(I915_SAMPLE_WAIT) | \
 BIT(I915_SAMPLE_SEMA) | \
 BIT(I915_SAMPLE_QUEUED) | \
-BIT(I915_SAMPLE_RUNNABLE))
+BIT(I915_SAMPLE_RUNNABLE) | \
+BIT(I915_SAMPLE_RUNNING))
 
 #define ENGINE_SAMPLE_BITS (1 << I915_PMU_SAMPLE_BITS)
 
@@ -232,6 +233,11 @@ static void engines_sample(struct drm_i915_private 
*dev_priv)
update_sample(>pmu.sample[I915_SAMPLE_RUNNABLE],
  I915_SAMPLE_RUNNABLE_DIVISOR,
  engine->request_stats.runnable);
+
+   if (engine->pmu.enable & BIT(I915_SAMPLE_RUNNING))
+   update_sample(>pmu.sample[I915_SAMPLE_RUNNING],
+ I915_SAMPLE_RUNNING_DIVISOR,
+ last_seqno - current_seqno);
}
 
if (fw)
@@ -311,6 +317,7 @@ engine_event_status(struct intel_engine_cs *engine,
case I915_SAMPLE_WAIT:
case I915_SAMPLE_QUEUED:
case I915_SAMPLE_RUNNABLE:
+   case I915_SAMPLE_RUNNING:
break;
case I915_SAMPLE_SEMA:
if (INTEL_GEN(engine->i915) < 6)
@@ -423,7 +430,8 @@ static u64 __i915_pmu_event_read(struct perf_event *event)
}
 
if (sample == I915_SAMPLE_QUEUED ||
-   sample == I915_SAMPLE_RUNNABLE)
+   sample == I915_SAMPLE_RUNNABLE ||
+   sample == I915_SAMPLE_RUNNING)
val = div_u64(val, FREQUENCY);
} else {
switch (event->attr.config) {
@@ -777,6 +785,7 @@ add_pmu_attr(struct perf_pmu_events_attr *attr, const char 
*name,
 /* No brackets or quotes below please. */
 #define I915_SAMPLE_QUEUED_SCALE 0.01
 #define I915_SAMPLE_RUNNABLE_SCALE 0.01
+#define I915_SAMPLE_RUNNING_SCALE 0.01
 
 static struct attribute **
 create_event_attributes(struct drm_i915_private *i915)
@@ -804,6 +813,8 @@ create_event_attributes(struct drm_i915_private *i915)
 __stringify(I915_SAMPLE_QUEUED_SCALE)),
__engine_event_scale(I915_SAMPLE_RUNNABLE, "runnable",
 __stringify(I915_SAMPLE_RUNNABLE_SCALE)),
+   __engine_event_scale(I915_SAMPLE_RUNNING, "running",
+__stringify(I915_SAMPLE_RUNNING_SCALE)),
};
unsigned int count = 0;
struct perf_pmu_events_attr *pmu_attr = NULL, *pmu_iter;
@@ -819,6 +830,9 @@ create_event_attributes(struct drm_i915_private *i915)
BUILD_BUG_ON(I915_SAMPLE_RUNNABLE_DIVISOR !=
 (1 / I915_SAMPLE_RUNNABLE_SCALE));
 
+   BUILD_BUG_ON(I915_SAMPLE_RUNNING_DIVISOR !=
+(1 / I915_SAMPLE_RUNNING_SCALE));
+
/* Count how many counters we will be exposing. */
for (i = 0; i < ARRAY_SIZE(events); i++) {
if (!config_status(i915, events[i].config))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a06f1fc0c150..2adc87e48dab 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -381,7 +381,7 @@ struct intel_engine_cs {
 *
 * Our internal timer stores the current counters in this field.
 */
-#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_RUNNABLE + 1)
+#define I915_ENGINE_SAMPLE_MAX (I915_SAMPLE_RUNNING + 1)
struct i915_pmu_sample sample[I915_ENGINE_SAMPLE_MAX];
/**
 * @busy_stats: Has enablement of engine stats tracking been
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 05951839abe0..1618da74d8d8 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -113,11 +113,13 @@ enum drm_i915_pmu_engine_sample {
I915_SAMPLE_SEMA = 2,
I915_SAMPLE_QUEUED = 3,
I915_SAMPLE_RUNNABLE = 4,
+   I915_SAMPLE_RUNNING = 5,
 };
 
  /* Divide counter value by divisor to get the real value. */
 #define I915_SAMPLE_QUEUED_DIVISOR (100)
 #define I915_SAMPLE_RUNNABLE_DIVISOR (100)
+#define I915_SAMPLE_RUNNING_DIVISOR (100)
 
 #define I915_PMU_SAMPLE_BITS (4)
 

[Intel-gfx] [RFC 1/6] drm/i915/pmu: Fix enable count array size and bounds checking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Enable count array is supposed to have one counter for each possible
engine sampler. As such array sizing and bounds checking is not
correct when more engine samplers are added.

At the same time tidy the assert for readability and robustness.

Signed-off-by: Tvrtko Ursulin 
Fixes: b46a33e271ed ("drm/i915/pmu: Expose a PMU interface for perf queries")
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_pmu.c | 13 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 065a28c713c4..cbfca4a255ab 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -476,7 +476,8 @@ static void i915_pmu_enable(struct perf_event *event)
 * Update the bitmask of enabled events and increment
 * the event reference counter.
 */
-   GEM_BUG_ON(bit >= I915_PMU_MASK_BITS);
+   BUILD_BUG_ON(ARRAY_SIZE(i915->pmu.enable_count) != I915_PMU_MASK_BITS);
+   GEM_BUG_ON(bit >= ARRAY_SIZE(i915->pmu.enable_count));
GEM_BUG_ON(i915->pmu.enable_count[bit] == ~0);
i915->pmu.enable |= BIT_ULL(bit);
i915->pmu.enable_count[bit]++;
@@ -500,7 +501,10 @@ static void i915_pmu_enable(struct perf_event *event)
GEM_BUG_ON(!engine);
engine->pmu.enable |= BIT(sample);
 
-   GEM_BUG_ON(sample >= I915_PMU_SAMPLE_BITS);
+   BUILD_BUG_ON(ARRAY_SIZE(engine->pmu.enable_count) !=
+(1 << I915_PMU_SAMPLE_BITS));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
GEM_BUG_ON(engine->pmu.enable_count[sample] == ~0);
if (engine->pmu.enable_count[sample]++ == 0) {
/*
@@ -554,7 +558,8 @@ static void i915_pmu_disable(struct perf_event *event)
  engine_event_class(event),
  engine_event_instance(event));
GEM_BUG_ON(!engine);
-   GEM_BUG_ON(sample >= I915_PMU_SAMPLE_BITS);
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.enable_count));
+   GEM_BUG_ON(sample >= ARRAY_SIZE(engine->pmu.sample));
GEM_BUG_ON(engine->pmu.enable_count[sample] == 0);
/*
 * Decrement the reference count and clear the enabled
@@ -582,7 +587,7 @@ static void i915_pmu_disable(struct perf_event *event)
}
}
 
-   GEM_BUG_ON(bit >= I915_PMU_MASK_BITS);
+   GEM_BUG_ON(bit >= ARRAY_SIZE(i915->pmu.enable_count));
GEM_BUG_ON(i915->pmu.enable_count[bit] == 0);
/*
 * Decrement the reference count and clear the enabled
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index c5ff203e42d6..27a0c47db51e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -358,7 +358,7 @@ struct intel_engine_cs {
 *
 * Index number corresponds to the bit number from @enable.
 */
-   unsigned int enable_count[I915_PMU_SAMPLE_BITS];
+   unsigned int enable_count[1 << I915_PMU_SAMPLE_BITS];
/**
 * @sample: Counter values for sampling events.
 *
-- 
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/i915: Keep a count of requests waiting for a slot on GPU

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Keep a per-engine number of runnable (waiting for GPU time) requests.

v2:
 * Move queued increment from insert_request to execlist_submit_request to
   avoid bumping when re-ordering for priority.
 * Support the counter on the ringbuffer submission path as well, albeit
   just notionally. (Chris Wilson)

v3:
 * Rebase.

v4:
 * Rename and move the stats into a container structure. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 7 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 5 +++--
 drivers/gpu/drm/i915/intel_lrc.c| 2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index a0f451b4a4e8..8da350bacff1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -502,6 +502,9 @@ void __i915_gem_request_submit(struct drm_i915_gem_request 
*request)
engine->emit_breadcrumb(request,
request->ring->vaddr + request->postfix);
 
+   GEM_BUG_ON(engine->request_stats.runnable == 0);
+   engine->request_stats.runnable--;
+
spin_lock(>timeline->lock);
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
@@ -517,6 +520,8 @@ void i915_gem_request_submit(struct drm_i915_gem_request 
*request)
/* Will be called from irq-context when using foreign fences. */
spin_lock_irqsave(>timeline->lock, flags);
 
+   engine->request_stats.runnable++;
+
__i915_gem_request_submit(request);
 
spin_unlock_irqrestore(>timeline->lock, flags);
@@ -548,6 +553,8 @@ void __i915_gem_request_unsubmit(struct 
drm_i915_gem_request *request)
timeline = request->timeline;
GEM_BUG_ON(timeline == engine->timeline);
 
+   engine->request_stats.runnable++;
+
spin_lock(>lock);
list_move(>link, >requests);
spin_unlock(>lock);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 7eebfbb95e89..8377a77cfbe7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1731,12 +1731,13 @@ void intel_engine_dump(struct intel_engine_cs *engine,
if (i915_terminally_wedged(>i915->gpu_error))
drm_printf(m, "*** WEDGED ***\n");
 
-   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d\n",
+   drm_printf(m, "\tcurrent seqno %x, last %x, hangcheck %x [%d ms], 
inflight %d, runnable %u\n",
   intel_engine_get_seqno(engine),
   intel_engine_last_submit(engine),
   engine->hangcheck.seqno,
   jiffies_to_msecs(jiffies - 
engine->hangcheck.action_timestamp),
-  engine->timeline->inflight_seqnos);
+  engine->timeline->inflight_seqnos,
+  engine->request_stats.runnable);
drm_printf(m, "\tReset count: %d (global %d)\n",
   i915_reset_engine_count(error, engine),
   i915_reset_count(error));
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 51e61b04a555..319937e67a6e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -965,6 +965,8 @@ static void execlists_submit_request(struct 
drm_i915_gem_request *request)
/* Will be called from irq-context when using foreign fences. */
spin_lock_irqsave(>timeline->lock, flags);
 
+   engine->request_stats.runnable++;
+
insert_request(engine, >priotree, request->priotree.priority);
 
GEM_BUG_ON(!engine->execlists.first);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 27a0c47db51e..d7ee7831288d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -303,6 +303,15 @@ struct intel_engine_cs {
struct intel_ring *buffer;
struct intel_timeline *timeline;
 
+   struct {
+   /**
+* @runnable: Number of runnable requests sent to the backend.
+*
+* Count of requests waiting for the GPU to execute them.
+*/
+   unsigned int runnable;
+   } request_stats;
+
struct drm_i915_gem_object *default_state;
 
atomic_t irq_count;
-- 
2.14.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore HDCP DRM_INFO when with no downstream

[Patchwork]

== Series Details ==

Series: drm/i915: Restore HDCP DRM_INFO when with no downstream
URL   : https://patchwork.freedesktop.org/series/36921/
State : success

== Summary ==

Series 36921v1 drm/i915: Restore HDCP DRM_INFO when with no downstream
https://patchwork.freedesktop.org/api/1.0/series/36921/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:418s
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:484s
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:483s
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:455s
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:277s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
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: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: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:460s
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:586s
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:507s
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:485s
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:419s
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:525s
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:572s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
6b99b286739e drm/i915: Restore HDCP DRM_INFO when with no downstream

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement display w/a #1143 (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Implement display w/a #1143 (rev2)
URL   : https://patchwork.freedesktop.org/series/36813/
State : success

== Summary ==

Series 36813v2 drm/i915: Implement display w/a #1143
https://patchwork.freedesktop.org/api/1.0/series/36813/revisions/2/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:421s
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:379s
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:280s
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:481s
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:466s
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:510s
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:416s
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:409s
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:501s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
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:511s
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:491s
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:418s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:527s
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:469s

06c8efda323ac918fad0e26d81e8884574ec8b84 drm-tip: 2018y-01m-22d-17h-43m-26s UTC 
integration manifest
0cc7ea9e43d0 drm/i915: Implement display w/a #1143

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Restore HDCP DRM_INFO when with no downstream

[Sean Paul]

The commit below returned earlier than before, but failed to move the
info message when authenticating without downstream devices. This patch
restores the message on authentication success.

Fixes: 87eb3ec818fa ("drm/i915: II stage HDCP auth for repeater only")
Cc: Ramalingam C 
Cc: Sean Paul 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/i915/intel_hdcp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index db9527173a1e..dd7dffd405d5 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -168,10 +168,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port 
*intel_dig_port,
 
/* If there are no downstream devices, we're all done. */
num_downstream = DRM_HDCP_NUM_DOWNSTREAM(bstatus[0]);
-   if (num_downstream == 0) {
-   DRM_INFO("HDCP is enabled (no downstream devices)\n");
+   if (num_downstream == 0)
return 0;
-   }
 
ksv_fifo = kzalloc(num_downstream * DRM_HDCP_KSV_LEN, GFP_KERNEL);
if (!ksv_fifo)
@@ -502,6 +500,7 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
if (repeater_present)
return intel_hdcp_auth_downstream(intel_dig_port, shim);
 
+   DRM_INFO("HDCP is enabled (no downstream devices)\n");
return 0;
 }
 
-- 
2.16.0.rc1.238.g530d649a79-goog

___
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

[Rodrigo Vivi]

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 


> ---
>  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
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Ville Syrjala]

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ä 
---
 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

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

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

[Ville Syrjälä]

On Fri, Jan 19, 2018 at 12:07:47PM -0800, Rodrigo Vivi wrote:
> On Fri, Jan 19, 2018 at 06:45:49PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Apparently SKL/KBL 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.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  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 
> > */
> 
> Wa on Bspec doesnt mention port E, although it makes sense to have...
> maybe a WARN_ON if DDIE but not TRANS_A then?!

We pick the registers instance purely based on the port, so
there's no point in such a WARN_ON() as it would just be
asserting that we didn't mess up a part of the 
port_to_transcoder[] table.

> 
> > +#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..7b1ab003279f 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 */
> > +   if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> 
> on KBL, but not on CFL?! Strange... Art?
> 
> > +   /*
> > +* 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
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > 

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

[Chris Wilson]

Quoting Daniele Ceraolo Spurio (2018-01-22 16:09:28)
> 
> 
> On 22/01/18 07:13, Chris Wilson wrote:
> > Quoting Mika Kuoppala (2018-01-22 15:08:16)
> >> Daniele Ceraolo Spurio  writes:
> >>
> >>> On 19/01/18 05:05, Mika Kuoppala wrote:
>  Daniele Ceraolo Spurio  writes:
> 
> > 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,
> > 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 ELSQ 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 Gen11+ 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)
> >
> > Cc: Chris Wilson 
> > Signed-off-by: Thomas Daniel 
> > Signed-off-by: Rodrigo Vivi 
> > Signed-off-by: Daniele Ceraolo Spurio 
> 
>  Was going to adopt this patch from Rodrigo but you were faster.
> 
>  I choose to stash the elsq and use it as a gen11 vs rest toggle:
> 
>  Relevant bits:
> 
>  +static inline void write_port(struct intel_engine_execlists * const 
>  execlists,
>  + unsigned int n,
>  + u64 desc)
>  +{
>  +   if (execlists->elsq)
>  +   gen11_elsq_write(desc, n, execlists->elsq);
>  +   else
>  +   gen8_elsp_write(desc, execlists->elsp);
>  +}
>  +
>  +static inline void submit_ports(struct intel_engine_execlists * const 
>  execlists)
>  +{
>  +   /* for gen11+ we need to manually load the submit queue */
>  +   if (execlists->elsq) {
>  +   struct intel_engine_cs *engine =
>  +   container_of(execlists,
>  +struct intel_engine_cs,
>  +execlists);
>  +   struct drm_i915_private *dev_priv = engine->i915;
>  +
>  +   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
>  +   }
>  +}
>  +
> 
> >>>
> >>> I was undecided about hiding the code in sub-functions because of the
> >>> pre-emption path. There is no need in gen11 to inject a context to
> >>> preempt to idle,
> > 
> > Really? The preempt-to-idle is so that we can sync the bookkeeping with
> > the pending CS interrupts. The HW doesn't require it currently either,
> > it's the SW that does. If you have a way to avoid that, that should be
> > applicable to the current code as well?
> > -Chris
> > 
> 
> We can't avoid preempt-to-idle, we can do it in a simpler way. There is 
> a bit in RING_EXECLIST_CONTROL that triggers a preemp-to-idle, without 
> the need to do a ctx injection. We'll need to move preemption completion 
> detection to the CSB value instead of the HWSP write, not sure about the 
> impact of that on our bookkeeping.

Ah, shucks :( I was hoping there's a simple way to avoid idling.

I have to ask, is it worth it? If we still have to do a CS interrupt
round trip, what's the difference? Hmm. I wonder if assume that the
preemption is nearly instantaneous (say 10us), we could short-circuit
the interrupt and poll. Falling back to interrupt if longer, and/or
resetting the GPU to guarantee latencies.
-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/execlists: Skip forcewake for ELSP submission

[Tvrtko Ursulin]

On 22/01/2018 17:17, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-22 16:59:21)


On 22/01/2018 10:07, Chris Wilson wrote:

Now that we can read the CSB from the HWSP, we may avoid having to
perform mmio reads entirely and so forgo the rigmarole of the forcewake
dance.

v2: Include forcewake hint for GEM_TRACE readback of mmio. If we don't
hold fw ourselves, the reads may return garbage.

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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ff25f209d0a5..075e7f56e9ba 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -778,6 +778,7 @@ static void execlists_submission_tasklet(unsigned long data)
   struct intel_engine_execlists * const execlists = >execlists;
   struct execlist_port * const port = execlists->port;
   struct drm_i915_private *dev_priv = engine->i915;
+ bool fw = false;
   
   /* We can skip acquiring intel_runtime_pm_get() here as it was taken

* on our behalf by the request (see i915_gem_mark_busy()) and it will
@@ -788,8 +789,6 @@ static void execlists_submission_tasklet(unsigned long data)
*/
   GEM_BUG_ON(!dev_priv->gt.awake);
   
- intel_uncore_forcewake_get(dev_priv, execlists->fw_domains);

-
   /* Prefer doing test_and_clear_bit() as a two stage operation to avoid
* imposing the cost of a locked atomic transaction when submitting a
* new request (outside of the context-switch interrupt).
@@ -818,6 +817,12 @@ static void execlists_submission_tasklet(unsigned long 
data)
*/
   __clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
   if (unlikely(execlists->csb_head == -1)) { /* following a reset 
*/
+ if (!fw) {
+ intel_uncore_forcewake_get(dev_priv,
+execlists->fw_domains);
+ fw = true;
+ }
+
   head = readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
   tail = GEN8_CSB_WRITE_PTR(head);
   head = GEN8_CSB_READ_PTR(head);
@@ -830,10 +835,10 @@ static void execlists_submission_tasklet(unsigned long 
data)
   head = execlists->csb_head;
   tail = READ_ONCE(buf[write_idx]);
   }
- GEM_TRACE("%s cs-irq head=%d [%d], tail=%d [%d]\n",
+ GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
 engine->name,
-   head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine,
-   tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine);
+   head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
+   tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");


Not useful to log the correct value in any case? Or in other words, this
trace is not useful for debugging potential problems with the HWSP CSB
copy, while with this change it stops being so?


It also completely invalidates CI's testing as otherwise we will always
be forcewaking on submission. I am not shedding a tear over the loss of
that information on the occasions it is garbage - it too is likely to
cause heisenbugs and mask the very information we are trying to present
(in this case latency between HWSP write and CS interrupt).


Ookay.


   while (head != tail) {
   struct drm_i915_gem_request *rq;
@@ -943,7 +948,8 @@ static void execlists_submission_tasklet(unsigned long data)


There is a writel a bit above which now has no fw in HWSP mode.


And it doesn't need one, afaict. There's no imposed wakeup (no forcewake)
and no latency, ergo the HW is pulling the right value immediate.
Otherwise the mostly idle submission of new requests would go entirely
unnoticed. (I've always had a wonder about why they would add RING_TAIL
to the shadow regs but not RING_ELSP.)


Ha shadowed, ok.. GEM_BUG_ON(intel_reg_forcewake_for_read(...))? But not 
in the tasklet, perhaps somewhere else.


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] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Downgrade incorrect engine constructor usage warnings to development

[Tvrtko Ursulin]

On 19/01/2018 10:43, Patchwork wrote:

== Series Details ==

Series: series starting with [1/3] drm/i915: Downgrade incorrect engine 
constructor usage warnings to development
URL   : https://patchwork.freedesktop.org/series/36771/
State : success

== Summary ==

Series 36771v1 series starting with [1/3] drm/i915: Downgrade incorrect engine 
constructor usage warnings to development
https://patchwork.freedesktop.org/api/1.0/series/36771/revisions/1/mbox/

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:427s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
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:487s
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:484s
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:465s
fi-elk-e7500 total:224  pass:168  dwarn:10  dfail:0   fail:0   skip:45
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:279s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:517s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:393s
fi-hsw-4770r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:403s
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:461s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
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:494s
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:502s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:576s
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:516s
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:485s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:494s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:526s
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:570s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:469s
fi-skl-guc   total:288  pass:212  dwarn:48  dfail:0   fail:0   skip:28  
time:407s

3ddf5cf5ba662407c1d233e73bd783c548cc973b drm-tip: 2018y-01m-19d-10h-03m-03s UTC 
integration manifest
900552342868 drm/i915: Stop ignoring failure to set up workaround batch buffers
c25d70919bc2 drm/i915: Per-engine scratch VMA is mandatory
fd11054b3673 drm/i915: Downgrade incorrect engine constructor usage warnings to 
development


Pushed first two, for whatever miniscule improvement. Thanks for the 
reviews!


Regards,

Tvrtko
___
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: Skip forcewake for ELSP submission

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-22 16:59:21)
> 
> On 22/01/2018 10:07, Chris Wilson wrote:
> > Now that we can read the CSB from the HWSP, we may avoid having to
> > perform mmio reads entirely and so forgo the rigmarole of the forcewake
> > dance.
> > 
> > v2: Include forcewake hint for GEM_TRACE readback of mmio. If we don't
> > hold fw ourselves, the reads may return garbage.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > ---
> >   drivers/gpu/drm/i915/intel_lrc.c | 18 --
> >   1 file changed, 12 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index ff25f209d0a5..075e7f56e9ba 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -778,6 +778,7 @@ static void execlists_submission_tasklet(unsigned long 
> > data)
> >   struct intel_engine_execlists * const execlists = >execlists;
> >   struct execlist_port * const port = execlists->port;
> >   struct drm_i915_private *dev_priv = engine->i915;
> > + bool fw = false;
> >   
> >   /* We can skip acquiring intel_runtime_pm_get() here as it was taken
> >* on our behalf by the request (see i915_gem_mark_busy()) and it will
> > @@ -788,8 +789,6 @@ static void execlists_submission_tasklet(unsigned long 
> > data)
> >*/
> >   GEM_BUG_ON(!dev_priv->gt.awake);
> >   
> > - intel_uncore_forcewake_get(dev_priv, execlists->fw_domains);
> > -
> >   /* Prefer doing test_and_clear_bit() as a two stage operation to avoid
> >* imposing the cost of a locked atomic transaction when submitting a
> >* new request (outside of the context-switch interrupt).
> > @@ -818,6 +817,12 @@ static void execlists_submission_tasklet(unsigned long 
> > data)
> >*/
> >   __clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
> >   if (unlikely(execlists->csb_head == -1)) { /* following a 
> > reset */
> > + if (!fw) {
> > + intel_uncore_forcewake_get(dev_priv,
> > +
> > execlists->fw_domains);
> > + fw = true;
> > + }
> > +
> >   head = readl(dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> >   tail = GEN8_CSB_WRITE_PTR(head);
> >   head = GEN8_CSB_READ_PTR(head);
> > @@ -830,10 +835,10 @@ static void execlists_submission_tasklet(unsigned 
> > long data)
> >   head = execlists->csb_head;
> >   tail = READ_ONCE(buf[write_idx]);
> >   }
> > - GEM_TRACE("%s cs-irq head=%d [%d], tail=%d [%d]\n",
> > + GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
> > engine->name,
> > -   head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine,
> > -   tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine);
> > +   head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
> > +   tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
> > i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");
> 
> Not useful to log the correct value in any case? Or in other words, this 
> trace is not useful for debugging potential problems with the HWSP CSB 
> copy, while with this change it stops being so?

It also completely invalidates CI's testing as otherwise we will always
be forcewaking on submission. I am not shedding a tear over the loss of
that information on the occasions it is garbage - it too is likely to
cause heisenbugs and mask the very information we are trying to present
(in this case latency between HWSP write and CS interrupt).

> >   while (head != tail) {
> >   struct drm_i915_gem_request *rq;
> > @@ -943,7 +948,8 @@ static void execlists_submission_tasklet(unsigned long 
> > data)
> 
> There is a writel a bit above which now has no fw in HWSP mode.

And it doesn't need one, afaict. There's no imposed wakeup (no forcewake)
and no latency, ergo the HW is pulling the right value immediate.
Otherwise the mostly idle submission of new requests would go entirely
unnoticed. (I've always had a wonder about why they would add RING_TAIL
to the shadow regs but not RING_ELSP.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Allow clients to query own per-engine busyness

[Tvrtko Ursulin]

On 22/01/2018 12:32, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-22 11:45:04)


On 22/01/2018 10:00, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-22 09:53:27)


On 19/01/2018 21:08, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-01-19 13:45:24)

+   case I915_CONTEXT_GET_ENGINE_BUSY:
+   engine = intel_engine_lookup_user(i915, args->class,
+ args->instance);
+   if (!engine) {
+   ret = -EINVAL;
+   break;
+   }
+
+   ce = >engine[engine->id];
+   if (!READ_ONCE(ce->stats.enabled)) {
+   ret = i915_mutex_lock_interruptible(dev);
+   if (!ret)
+   break;
+
+   if (!ce->stats.enabled) {
+   ret = intel_enable_engine_stats(engine);


* Blink.

This caught me by surprise. (Other than struct_mutex) Not too offensive,
but surprising. At the very least call out to a function to handle the
request. Where did args->class, args->instance come from? You surely
didn't extend the ioctl struct just for that?


Haven't extended it no, just did this:

--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1468,7 +1468,16 @@ struct drm_i915_gem_context_param {
#define   I915_CONTEXT_MAX_USER_PRIORITY  1023 /* inclusive */
#define   I915_CONTEXT_DEFAULT_PRIORITY   0
#define   I915_CONTEXT_MIN_USER_PRIORITY  -1023 /* inclusive */
-   __u64 value;
+#define I915_CONTEXT_GET_ENGINE_BUSY   0x7
+   union {
+   __u64 value;
+   struct {
+   __u8 pad[6]; /* unused */
+
+   __u8 class;
+   __u8 instance;
+   };
+   };
};


Not entirely happy about mixing in/out parameters. It's already
complicated by being either an out value or an out pointer.

Closer to the original idea for context_getparam would be to return the
array of engine values.


It would have the advantage that multiple engines could be queried
(more) atomically. How about then:

I915_CONTEXT_ENABLE_ENGINE_STATS:
value = &{
 __u32 num_engines;
 __u32 pad;
 
 struct {

 __u8 class;
 __u8 instance;
 __u8 pad[6];
 } [num_engines];
};


We could also get away without explicit stats enable step if so is 
desired (like the posted RFC). Enable on first query, disable on context 
destroy.




I915_CONTEXT_GET_ENGINE_STATS:
value = &{
 __u32 num_engines;
 __u32 pad;


Will need length here so we don't overwrite users memory.



 struct {
 __u8 class;
 __u8 instance;
 __u8 pad[6];

 __u64 busy;
 } [num_engines];
};


Yes, that's what I had in mind. How does that work in practice? Does it
make userspace too clumsy?


I wouldn't expect it to be a problem. Gordon?

Regards,

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

[Intel-gfx] ✗ Fi.CI.IGT: warning for Adding NV12 support (rev7)

[Patchwork]

== Series Details ==

Series: Adding NV12 support (rev7)
URL   : https://patchwork.freedesktop.org/series/28103/
State : warning

== Summary ==

Test kms_flip:
Subgroup 2x-flip-vs-dpms-off-vs-modeset:
pass   -> DMESG-WARN (shard-hsw)
Subgroup 2x-vblank-vs-modeset-suspend-interruptible:
incomplete -> PASS   (shard-hsw)
Test kms_plane_lowres:
Subgroup pipe-c-tiling-x:
pass   -> FAIL   (shard-apl) fdo#103166
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (shard-hsw) fdo#103375
Test kms_frontbuffer_tracking:
Subgroup fbc-rgb565-draw-blt:
pass   -> FAIL   (shard-snb) fdo#101623
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-legacy:
pass   -> FAIL   (shard-apl) fdo#102670
Test pm_rc6_residency:
Subgroup rc6-accuracy:
pass   -> SKIP   (shard-snb)
Test kms_atomic_transition:
Subgroup 1x-modeset-transitions:
fail   -> PASS   (shard-apl) fdo#103207
Test perf:
Subgroup buffer-fill:
fail   -> PASS   (shard-apl) fdo#103755
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
fdo#103207 https://bugs.freedesktop.org/show_bug.cgi?id=103207
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:2780 pass:1714 dwarn:1   dfail:0   fail:25  skip:1040 
time:14689s
shard-hswtotal:2780 pass:1721 dwarn:2   dfail:0   fail:13  skip:1043 
time:15527s
shard-snbtotal:2780 pass:1315 dwarn:1   dfail:0   fail:14  skip:1450 
time:8094s
Blacklisted hosts:
shard-kbltotal:2780 pass:1837 dwarn:1   dfail:0   fail:24  skip:918 
time:11085s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Skip forcewake for ELSP submission

[Tvrtko Ursulin]

On 22/01/2018 10:07, Chris Wilson wrote:

Now that we can read the CSB from the HWSP, we may avoid having to
perform mmio reads entirely and so forgo the rigmarole of the forcewake
dance.

v2: Include forcewake hint for GEM_TRACE readback of mmio. If we don't
hold fw ourselves, the reads may return garbage.

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

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ff25f209d0a5..075e7f56e9ba 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -778,6 +778,7 @@ static void execlists_submission_tasklet(unsigned long data)
struct intel_engine_execlists * const execlists = >execlists;
struct execlist_port * const port = execlists->port;
struct drm_i915_private *dev_priv = engine->i915;
+   bool fw = false;
  
  	/* We can skip acquiring intel_runtime_pm_get() here as it was taken

 * on our behalf by the request (see i915_gem_mark_busy()) and it will
@@ -788,8 +789,6 @@ static void execlists_submission_tasklet(unsigned long data)
 */
GEM_BUG_ON(!dev_priv->gt.awake);
  
-	intel_uncore_forcewake_get(dev_priv, execlists->fw_domains);

-
/* Prefer doing test_and_clear_bit() as a two stage operation to avoid
 * imposing the cost of a locked atomic transaction when submitting a
 * new request (outside of the context-switch interrupt).
@@ -818,6 +817,12 @@ static void execlists_submission_tasklet(unsigned long 
data)
 */
__clear_bit(ENGINE_IRQ_EXECLIST, >irq_posted);
if (unlikely(execlists->csb_head == -1)) { /* following a reset 
*/
+   if (!fw) {
+   intel_uncore_forcewake_get(dev_priv,
+  
execlists->fw_domains);
+   fw = true;
+   }
+
head = readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
tail = GEN8_CSB_WRITE_PTR(head);
head = GEN8_CSB_READ_PTR(head);
@@ -830,10 +835,10 @@ static void execlists_submission_tasklet(unsigned long 
data)
head = execlists->csb_head;
tail = READ_ONCE(buf[write_idx]);
}
-   GEM_TRACE("%s cs-irq head=%d [%d], tail=%d [%d]\n",
+   GEM_TRACE("%s cs-irq head=%d [%d%s], tail=%d [%d%s]\n",
  engine->name,
- head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine,
- tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine);
+ head, GEN8_CSB_READ_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?",
+ tail, GEN8_CSB_WRITE_PTR(readl(dev_priv->regs + 
i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine, fw ? "" : "?");


Not useful to log the correct value in any case? Or in other words, this 
trace is not useful for debugging potential problems with the HWSP CSB 
copy, while with this change it stops being so?


  
  		while (head != tail) {

struct drm_i915_gem_request *rq;
@@ -943,7 +948,8 @@ static void execlists_submission_tasklet(unsigned long data)


There is a writel a bit above which now has no fw in HWSP mode.


if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_PREEMPT))
execlists_dequeue(engine); > -   
intel_uncore_forcewake_put(dev_priv, execlists->fw_domains);
+   if (fw)
+   intel_uncore_forcewake_put(dev_priv, execlists->fw_domains);
  }
  
  static void insert_request(struct intel_engine_cs *engine,



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

Re: [Intel-gfx] [PATCH 01/10] drm/i915/cnl: Add Cannonlake PCI IDs for another SKU.

[Ville Syrjälä]

On Fri, Jan 19, 2018 at 04:05:15PM -0800, Rodrigo Vivi wrote:
> The only difference is that this SKUs has the full
> Port A/E split named as Port F.
> 
> But since SKUs differences don't matter on the platform
> definition group and ids, let's merge all off them together.
> 
> v2: Really include the PCI IDs to the picidlist[];
> v3: Add the PCI Id for another SKU (Anusha).
> v4: Update IDs, really include to pciidlists again.
> v5: Unify all GT2 IDs.
> v6: Unify in a way that we don't break early-quirks.c
> v7: Remove GT reference since it doesn't matter here (Paulo)
> Also move IS_CNL_WITH_PORT_F macro to this patch to
> make it easier for review this part and also to get
> used sooner.
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Paulo Zanoni 
> Cc: Lucas De Marchi 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_pci.c |  5 ++---
>  include/drm/i915_pciids.h   | 18 +++---
>  3 files changed, 11 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8333692dac5a..3d3727829ac7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2647,6 +2647,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>(dev_priv)->info.gt == 2)
>  #define IS_CFL_GT3(dev_priv) (IS_COFFEELAKE(dev_priv) && \
>(dev_priv)->info.gt == 3)
> +#define IS_CNL_WITH_PORT_F(dev_priv)   (IS_CANNONLAKE(dev_priv) && \
> + (INTEL_DEVID(dev_priv) & 0x0004) == 
> 0x0004)

I wonder if we should generalize this sort of thing into some kind of
device info port_mask. Though our port namespace currently only covers
the various digital port type, so listing all possible ports there
wouldn't currently be possible.

Perhaps not worth the hassle right now.

>  
>  #define IS_ALPHA_SUPPORT(intel_info) ((intel_info)->is_alpha_support)
>  
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f28c165fc49d..7eb3d5e4350e 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -571,7 +571,7 @@ static const struct intel_device_info 
> intel_coffeelake_gt3_info __initconst = {
>   .ddb_size = 1024, \
>   GLK_COLORS
>  
> -static const struct intel_device_info intel_cannonlake_gt2_info __initconst 
> = {
> +static const struct intel_device_info intel_cannonlake_info __initconst = {
>   GEN10_FEATURES,
>   .is_alpha_support = 1,
>   .platform = INTEL_CANNONLAKE,
> @@ -649,8 +649,7 @@ static const struct pci_device_id pciidlist[] = {
>   INTEL_CFL_U_GT1_IDS(_coffeelake_gt1_info),
>   INTEL_CFL_U_GT2_IDS(_coffeelake_gt2_info),
>   INTEL_CFL_U_GT3_IDS(_coffeelake_gt3_info),
> - INTEL_CNL_U_GT2_IDS(_cannonlake_gt2_info),
> - INTEL_CNL_Y_GT2_IDS(_cannonlake_gt2_info),
> + INTEL_CNL_IDS(_cannonlake_info),
>   {0, 0, 0}
>  };
>  MODULE_DEVICE_TABLE(pci, pciidlist);
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index 5db0458dd832..9e1fe6634424 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -414,24 +414,20 @@
>   INTEL_CFL_U_GT2_IDS(info), \
>   INTEL_CFL_U_GT3_IDS(info)
>  
> -/* CNL U 2+2 */
> -#define INTEL_CNL_U_GT2_IDS(info) \
> +/* CNL */
> +#define INTEL_CNL_IDS(info) \
>   INTEL_VGA_DEVICE(0x5A52, info), \
>   INTEL_VGA_DEVICE(0x5A5A, info), \
>   INTEL_VGA_DEVICE(0x5A42, info), \
> - INTEL_VGA_DEVICE(0x5A4A, info)
> -
> -/* CNL Y 2+2 */
> -#define INTEL_CNL_Y_GT2_IDS(info) \
> + INTEL_VGA_DEVICE(0x5A4A, info), \
>   INTEL_VGA_DEVICE(0x5A51, info), \
>   INTEL_VGA_DEVICE(0x5A59, info), \
>   INTEL_VGA_DEVICE(0x5A41, info), \
>   INTEL_VGA_DEVICE(0x5A49, info), \
>   INTEL_VGA_DEVICE(0x5A71, info), \
> - INTEL_VGA_DEVICE(0x5A79, info)
> -
> -#define INTEL_CNL_IDS(info) \
> - INTEL_CNL_U_GT2_IDS(info), \
> - INTEL_CNL_Y_GT2_IDS(info)
> + INTEL_VGA_DEVICE(0x5A79, info), \
> + INTEL_VGA_DEVICE(0x5A54, info), \
> + INTEL_VGA_DEVICE(0x5A5C, info), \
> + INTEL_VGA_DEVICE(0x5A44, info)
>  
>  #endif /* _I915_PCIIDS_H */
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 07/10] drm/i915/cnl: Add HPD support for Port F.

[Ville Syrjälä]

On Fri, Jan 19, 2018 at 04:05:21PM -0800, Rodrigo Vivi wrote:
> On CNP boards that are using DDI F,
> bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing
> the Digital Port F hotplug line when the Digital
> Port F hotplug detect input is enabled.
> 
> v2: Reuse all existent structure instead of adding a
> new HPD_PORT_F pointing to pin of port E.
> v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming
> this right now. If that SKU ever get a proper name
> we come back and update it.
> v4: Rebase on top of digital connected port using encoder
> instead of port.
> v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch.
> 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Cc: Dhinakaran Pandiyan 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  6 --
>  drivers/gpu/drm/i915/i915_irq.c  | 35 +++
>  drivers/gpu/drm/i915/intel_dp.c  |  4 +++-
>  drivers/gpu/drm/i915/intel_hdmi.c|  2 +-
>  drivers/gpu/drm/i915/intel_hotplug.c | 19 +++
>  5 files changed, 42 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7206c7c5f81c..0b5f8d887bfd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2957,8 +2957,10 @@ void intel_hpd_irq_handler(struct drm_i915_private 
> *dev_priv,
>  void intel_hpd_init(struct drm_i915_private *dev_priv);
>  void intel_hpd_init_work(struct drm_i915_private *dev_priv);
>  void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
> -enum port intel_hpd_pin_to_port(enum hpd_pin pin);
> -enum hpd_pin intel_hpd_pin(enum port port);
> +enum port intel_hpd_pin_to_port(struct drm_i915_private *dev_priv,
> + enum hpd_pin pin);
> +enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
> +enum port port);
>  bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
>  
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 0af970d4b3cf..78af4594eb38 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1568,10 +1568,11 @@ static bool i9xx_port_hotplug_long_detect(enum port 
> port, u32 val)
>   *
>   * Note that the caller is expected to zero out the masks initially.
>   */
> -static void intel_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
> -  u32 hotplug_trigger, u32 dig_hotplug_reg,
> -  const u32 hpd[HPD_NUM_PINS],
> -  bool long_pulse_detect(enum port port, u32 val))
> +static void intel_get_hpd_pins(struct drm_i915_private *dev_priv,
> +u32 *pin_mask, u32 *long_mask,
> +u32 hotplug_trigger, u32 dig_hotplug_reg,
> +const u32 hpd[HPD_NUM_PINS],
> +bool long_pulse_detect(enum port port, u32 val))
>  {
>   enum port port;
>   int i;
> @@ -1582,7 +1583,7 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
> *long_mask,
>  
>   *pin_mask |= BIT(i);
>  
> - port = intel_hpd_pin_to_port(i);
> + port = intel_hpd_pin_to_port(dev_priv, i);
>   if (port == PORT_NONE)
>   continue;
>  
> @@ -1970,8 +1971,9 @@ static void i9xx_hpd_irq_handler(struct 
> drm_i915_private *dev_priv,
>   u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
>  
>   if (hotplug_trigger) {
> - intel_get_hpd_pins(_mask, _mask, 
> hotplug_trigger,
> -hotplug_trigger, hpd_status_g4x,
> + intel_get_hpd_pins(dev_priv, _mask, _mask,
> +hotplug_trigger, hotplug_trigger,
> +hpd_status_g4x,
>  i9xx_port_hotplug_long_detect);
>  
>   intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> @@ -1983,8 +1985,9 @@ static void i9xx_hpd_irq_handler(struct 
> drm_i915_private *dev_priv,
>   u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
>  
>   if (hotplug_trigger) {
> - intel_get_hpd_pins(_mask, _mask, 
> hotplug_trigger,
> -hotplug_trigger, hpd_status_i915,
> + intel_get_hpd_pins(dev_priv, _mask, _mask,
> +hotplug_trigger, hotplug_trigger,
> +hpd_status_i915,
>  i9xx_port_hotplug_long_detect);

Re: [Intel-gfx] [PATCH 09/10] drm/i915/cnl: Fix DP max rate for Cannonlake with port F.

[Ville Syrjälä]

On Fri, Jan 19, 2018 at 04:05:23PM -0800, Rodrigo Vivi wrote:
> On CNL SKUs that uses port F,  max DP rate is 8.1G for all
> ports when we have the elevated voltage.
> 
> v2: Make commit message more generic.
> 
> Cc: Lucas De Marchi 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4b963732454d..36826460d8fb 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -240,8 +240,9 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>   source_rates = cnl_rates;
>   size = ARRAY_SIZE(cnl_rates);
>   voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
> - if (port == PORT_A || port == PORT_D ||
> - voltage == VOLTAGE_INFO_0_85V)
> + if (voltage == VOLTAGE_INFO_0_85V ||
> + (!IS_CNL_WITH_PORT_F(dev_priv) && (port == PORT_A ||
> +port == PORT_D)))

This is getting a bit hard to parse. Maybe move all these checks to a
small helper that is easier to read?

>   size -= 2;
>   } else if (IS_GEN9_BC(dev_priv)) {
>   source_rates = skl_rates;
> -- 
> 2.13.6
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 06/10] drm/i915: For HPD connected port use hpd_pin instead of port.

[Ville Syrjälä]

On Fri, Jan 19, 2018 at 04:05:20PM -0800, Rodrigo Vivi wrote:
> Let's try to simplify this mapping to hpd_pin -> bit
> instead using port.
> So for CNL with port F where we have this port using
> hdp_pin and bits of other ports we don't need to duplicated
> the mapping.
> 
> But for now this is only a re-org with no functional change
> expected.
> 
> Cc: Lucas De Marchi 
> Suggested-by: Ville Syrjälä 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 144 
> ++--
>  drivers/gpu/drm/i915/intel_drv.h|   3 +-
>  drivers/gpu/drm/i915/intel_lspcon.c |   3 +-
>  3 files changed, 72 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ae3b0b030177..4ff6fcf542e9 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4487,173 +4487,170 @@ edp_detect(struct intel_dp *intel_dp)
>   return status;
>  }
>  
> -static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
> -struct intel_digital_port *port)
> +static bool ibx_digital_port_connected(struct intel_encoder *encoder)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   u32 bit;
>  
> - switch (port->base.port) {
> - case PORT_B:
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_B:
>   bit = SDE_PORTB_HOTPLUG;
>   break;
> - case PORT_C:
> + case HPD_PORT_C:
>   bit = SDE_PORTC_HOTPLUG;
>   break;
> - case PORT_D:
> + case HPD_PORT_D:
>   bit = SDE_PORTD_HOTPLUG;
>   break;
>   default:
> - MISSING_CASE(port->base.port);
> + MISSING_CASE(encoder->hpd_pin);
>   return false;
>   }
>  
>   return I915_READ(SDEISR) & bit;
>  }
>  
> -static bool cpt_digital_port_connected(struct drm_i915_private *dev_priv,
> -struct intel_digital_port *port)
> +static bool cpt_digital_port_connected(struct intel_encoder *encoder)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   u32 bit;
>  
> - switch (port->base.port) {
> - case PORT_B:
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_B:
>   bit = SDE_PORTB_HOTPLUG_CPT;
>   break;
> - case PORT_C:
> + case HPD_PORT_C:
>   bit = SDE_PORTC_HOTPLUG_CPT;
>   break;
> - case PORT_D:
> + case HPD_PORT_D:
>   bit = SDE_PORTD_HOTPLUG_CPT;
>   break;
>   default:
> - MISSING_CASE(port->base.port);
> + MISSING_CASE(encoder->hpd_pin);
>   return false;
>   }
>  
>   return I915_READ(SDEISR) & bit;
>  }
>  
> -static bool spt_digital_port_connected(struct drm_i915_private *dev_priv,
> -struct intel_digital_port *port)
> +static bool spt_digital_port_connected(struct intel_encoder *encoder)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   u32 bit;
>  
> - switch (port->base.port) {
> - case PORT_A:
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_A:
>   bit = SDE_PORTA_HOTPLUG_SPT;
>   break;
> - case PORT_E:
> + case HPD_PORT_E:
>   bit = SDE_PORTE_HOTPLUG_SPT;
>   break;
>   default:
> - return cpt_digital_port_connected(dev_priv, port);
> + return cpt_digital_port_connected(encoder);
>   }
>  
>   return I915_READ(SDEISR) & bit;
>  }
>  
> -static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
> -struct intel_digital_port *port)
> +static bool g4x_digital_port_connected(struct intel_encoder *encoder)
>  {
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   u32 bit;
>  
> - switch (port->base.port) {
> - case PORT_B:
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_B:
>   bit = PORTB_HOTPLUG_LIVE_STATUS_G4X;
>   break;
> - case PORT_C:
> + case HPD_PORT_C:
>   bit = PORTC_HOTPLUG_LIVE_STATUS_G4X;
>   break;
> - case PORT_D:
> + case HPD_PORT_D:
>   bit = PORTD_HOTPLUG_LIVE_STATUS_G4X;
>   break;
>   default:
> - MISSING_CASE(port->base.port);
> + MISSING_CASE(encoder->hpd_pin);
>   return false;
>   }
>  
>   return I915_READ(PORT_HOTPLUG_STAT) & bit;
>  }
>  
> -static bool gm45_digital_port_connected(struct drm_i915_private *dev_priv,
> - struct intel_digital_port *port)
> +static bool gm45_digital_port_connected(struct intel_encoder 

Re: [Intel-gfx] [PATCH RFC 6/9] drm: Add cgroup helper library

[Tejun Heo]

Hello, Matt.

On Fri, Jan 19, 2018 at 05:51:38PM -0800, Matt Roper wrote:
> Most DRM drivers will want to handle the CGROUP_SETPARAM ioctl by looking up a
> driver-specific per-cgroup data structure (or allocating a new one) and 
> storing
> the supplied parameter value into the data structure (possibly after doing 
> some
> checking and sanitization on the provided value).  Let's provide a helper
> library for drivers that will take care of the details of storing per-cgroup
> data structures in a hashtable and destroying those structures if/when the
> cgroup itself is removed.

Would it be possible to make the core of this a built-in part of
cgroup like cgroup-bpf does?  My gut feeling is that that isn't gonna
be much code anyway and likely to be cleaner to implement and use.

Being a full-fledged controller comes with quite a bit of complexity
in terms of sync rules and everything, and we may build a simpler
modular infrastructure if usages like this proliferate but for now
extending from the core seems the most straight forward.

Thanks.

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

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

[Daniele Ceraolo Spurio]

On 22/01/18 07:13, Chris Wilson wrote:

Quoting Mika Kuoppala (2018-01-22 15:08:16)

Daniele Ceraolo Spurio  writes:


On 19/01/18 05:05, Mika Kuoppala wrote:

Daniele Ceraolo Spurio  writes:


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,
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 ELSQ 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 Gen11+ 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)

Cc: Chris Wilson 
Signed-off-by: Thomas Daniel 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 


Was going to adopt this patch from Rodrigo but you were faster.

I choose to stash the elsq and use it as a gen11 vs rest toggle:

Relevant bits:

+static inline void write_port(struct intel_engine_execlists * const execlists,
+ unsigned int n,
+ u64 desc)
+{
+   if (execlists->elsq)
+   gen11_elsq_write(desc, n, execlists->elsq);
+   else
+   gen8_elsp_write(desc, execlists->elsp);
+}
+
+static inline void submit_ports(struct intel_engine_execlists * const 
execlists)
+{
+   /* for gen11+ we need to manually load the submit queue */
+   if (execlists->elsq) {
+   struct intel_engine_cs *engine =
+   container_of(execlists,
+struct intel_engine_cs,
+execlists);
+   struct drm_i915_private *dev_priv = engine->i915;
+
+   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
+   }
+}
+



I was undecided about hiding the code in sub-functions because of the
pre-emption path. There is no need in gen11 to inject a context to
preempt to idle,


Really? The preempt-to-idle is so that we can sync the bookkeeping with
the pending CS interrupts. The HW doesn't require it currently either,
it's the SW that does. If you have a way to avoid that, that should be
applicable to the current code as well?
-Chris



We can't avoid preempt-to-idle, we can do it in a simpler way. There is 
a bit in RING_EXECLIST_CONTROL that triggers a preemp-to-idle, without 
the need to do a ctx injection. We'll need to move preemption completion 
detection to the CSB value instead of the HWSP write, not sure about the 
impact of that on our bookkeeping.


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

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

[Mika Kuoppala]

Jani Nikula  writes:

> On Mon, 08 Jan 2018, Mika Kuoppala  wrote:
>> Add option to specify engine for register read/write operation.
>> If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
>> to write and read register using a batch targeted at that engine.
>
> Copy-pasting from the man page, we already have the notation:
>
> "Registers are defined as [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR)."
>
> Why don't we add this as ENGINE:REGNAME or something instead of an extra
> --engine parameter? As a "port". Sure, it's more work, but I really like
> the current possibility of reading all types of registers at once. Now
> you prevent dumps that would contain both mmio and batch based reads.
>

Are you ok with the latest version? As discussed in irc, there are
problems with trying to add engines as ports, due to dynamic nature
and also that the existing infra relies on PORTNAME being mmio
for symbolic register dumping to work correctly.

for the wart of if (reg->engine) in read/write paths
we gain the benefits of mmio dumps with engines.

-Mika

> BR,
> Jani.
>
>
>>
>> v2: no MI_NOOP after BBE (Chris)
>> v3: use modern engine names (Chris), use global fd
>>
>> Cc: Jani Nikula 
>> Cc: Chris Wilson 
>> CC: Joonas Lahtinen 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  tools/intel_reg.c | 156 
>> +-
>>  1 file changed, 154 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/intel_reg.c b/tools/intel_reg.c
>> index 00d2a4a1..7f3494ef 100644
>> --- a/tools/intel_reg.c
>> +++ b/tools/intel_reg.c
>> @@ -33,6 +33,7 @@
>>  #include 
>>  
>>  #include "igt.h"
>> +#include "igt_gt.h"
>>  #include "intel_io.h"
>>  #include "intel_chipset.h"
>>  
>> @@ -73,6 +74,11 @@ struct config {
>>  
>>  /* register spec */
>>  char *specfile;
>> +
>> +/* engine to use for lri (write) and srm (read) */
>> +char *engine;
>> +int fd;
>> +
>>  struct reg *regs;
>>  ssize_t regcount;
>>  
>> @@ -236,13 +242,140 @@ static void dump_decode(struct config *config, struct 
>> reg *reg, uint32_t val)
>>  }
>>  }
>>  
>> +static const struct intel_execution_engine2 *find_engine(const char *name,
>> + bool *secure)
>> +{
>> +const struct intel_execution_engine2 *e;
>> +
>> +if (strlen(name) < 2)
>> +goto out;
>> +
>> +if (name[0] == '-') {
>> +*secure = false;
>> +name++;
>> +} else {
>> +*secure = true;
>> +}
>> +
>> +for (e = intel_execution_engines2; e->name; e++) {
>> +if (!strcmp(e->name, name))
>> +return e;
>> +}
>> +
>> +out:
>> +fprintf(stderr, "no such engine as '%s'\n", name);
>> +
>> +fprintf(stderr, "valid engines:");
>> +for (e = intel_execution_engines2; e->name; e++)
>> +fprintf(stderr, " %s", e->name);
>> +
>> +fprintf(stderr, "\n");
>> +
>> +exit(EXIT_FAILURE);
>> +}
>> +
>> +static int register_srm(struct config *config, struct reg *reg,
>> +uint32_t *val_in)
>> +{
>> +const int gen = intel_gen(config->devid);
>> +const bool r64b = gen >= 8;
>> +const uint32_t ctx = 0;
>> +struct drm_i915_gem_exec_object2 obj[2];
>> +struct drm_i915_gem_relocation_entry reloc[1];
>> +struct drm_i915_gem_execbuffer2 execbuf;
>> +uint32_t *batch, *r;
>> +const struct intel_execution_engine2 *engine;
>> +bool secure;
>> +int fd, i;
>> +uint32_t val;
>> +
>> +if (config->fd == -1) {
>> +config->fd = __drm_open_driver(DRIVER_INTEL);
>> +if (config->fd == -1) {
>> +fprintf(stderr, "Error opening driver: %s",
>> +strerror(errno));
>> +exit(EXIT_FAILURE);
>> +}
>> +}
>> +
>> +fd = config->fd;
>> +engine = find_engine(config->engine, );
>> +
>> +memset(obj, 0, sizeof(obj));
>> +obj[0].handle = gem_create(fd, 4096);
>> +obj[1].handle = gem_create(fd, 4096);
>> +obj[1].relocs_ptr = to_user_pointer(reloc);
>> +obj[1].relocation_count = 1;
>> +
>> +batch = gem_mmap__cpu(fd, obj[1].handle, 0, 4096, PROT_WRITE);
>> +gem_set_domain(fd, obj[1].handle,
>> +   I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
>> +
>> +i = 0;
>> +if (val_in) {
>> +batch[i++] = MI_NOOP;
>> +batch[i++] = MI_NOOP;
>> +
>> +batch[i++] = MI_LOAD_REGISTER_IMM;
>> +batch[i++] = reg->addr;
>> +batch[i++] = *val_in;
>> +batch[i++] = MI_NOOP;
>> +}
>> +
>> +batch[i++] = 0x24 << 23 | (1 + r64b); /* SRM */
>> +batch[i++] = reg->addr;
>> +reloc[0].target_handle = obj[0].handle;
>> +reloc[0].presumed_offset = 

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Imre Deak]

On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> > In case of eDP because the panel has a fixed mode, the link rate
> > and lane count at which it is trained corresponds to the link BW
> > required to support the native resolution of the panel. In case of
> > panles with lower resolutions where fewer lanes are hooked up internally,
> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> > So it is pointless to fallback to lower link rate/lane count in case
> > of link training failure on eDP connector since the lower link BW
> > will not support the native resolution of the panel and we cannot
> > prune the preferred mode on the eDP connector.
> > 
> > In case of Link training failure on the eDP panel, something is wrong
> > in the HW internally and hence driver errors out with a loud
> > and clear DRM_ERROR message.
> > 
> > v2:
> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> > 
> > Cc: Clinton Taylor 
> > Cc: Jim Bride 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Cc: Dave Airlie 
> > Cc: Daniel Vetter 
> > Signed-off-by: Manasi Navare 
> > Reviewed-by: Ville Syrjala 
> 
> This fell through the cracks, looks like it partially fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=103369
> 
> Why link training fails there is not clear.

Ok, the link training fail turned out to be a race between a modeset
link training and a link retraining called from
runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
one was fixed meanwhile by

commit 42e5e65765265485ecf2a480c244d76c2c624449
Author: Daniel Vetter 
AuthorDate: Mon Nov 13 17:01:40 2017 +0100
Commit: Daniel Vetter 
CommitDate: Thu Nov 23 14:59:07 2017 +0100

drm/i915: sync dp link status checks against atomic commmits

I merged now this fix to address the other issue, adding the above bug
as reference. Thanks for the patch and the review.

--Imre

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 
> > +-
> >  1 file changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..cf8fef8 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> > return;
> >  
> >   failure_handling:
> > -   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
> > %d, lane count = %d",
> > - intel_connector->base.base.id,
> > - intel_connector->base.name,
> > - intel_dp->link_rate, intel_dp->lane_count);
> > -   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > -intel_dp->link_rate,
> > -intel_dp->lane_count))
> > -   /* Schedule a Hotplug Uevent to userspace to start modeset */
> > -   schedule_work(_connector->modeset_retry_work);
> > +   /* Dont fallback and prune modes if its eDP */
> > +   if (!intel_dp_is_edp(intel_dp)) {
> > +   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link 
> > rate = %d, lane count = %d",
> > + intel_connector->base.base.id,
> > + intel_connector->base.name,
> > + intel_dp->link_rate, intel_dp->lane_count);
> > +   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > +
> > intel_dp->link_rate,
> > +
> > intel_dp->lane_count))
> > +   /* Schedule a Hotplug Uevent to userspace to start 
> > modeset */
> > +   schedule_work(_connector->modeset_retry_work);
> > +   } else {
> > +   DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
> > = %d, lane count = %d",
> > + intel_connector->base.base.id,
> > + intel_connector->base.name,
> > + intel_dp->link_rate, intel_dp->lane_count);
> > +   }
> > return;
> >  }
> > -- 
> > 2.1.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/breadcrumbs: Drop request reference for the signaler thread

[Patchwork]

== Series Details ==

Series: drm/i915/breadcrumbs: Drop request reference for the signaler thread
URL   : https://patchwork.freedesktop.org/series/36908/
State : warning

== Summary ==

Series 36908v1 drm/i915/breadcrumbs: Drop request reference for the signaler 
thread
https://patchwork.freedesktop.org/api/1.0/series/36908/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
fail   -> DMESG-WARN (fi-elk-e7500) fdo#103989 +1
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7500u)
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:428s
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:488s
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: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:279s
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:398s
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:460s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:416s
fi-kbl-7500u total:288  pass:262  dwarn:2   dfail:0   fail:0   skip:24  
time:459s
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:453s
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:572s
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:510s
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:486s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:492s
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:436s
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:399s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:470s
fi-bdw-gvtdvm failed to collect. IGT log at Patchwork_7740/fi-bdw-gvtdvm/igt.log

0edb3ea337349387863e60ed0bdf53b9b2767cf4 drm-tip: 2018y-01m-22d-14h-27m-52s UTC 
integration manifest
c6f6fdb0d9c0 drm/i915/breadcrumbs: Drop request reference for the signaler 
thread

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace open-coded wait-for loop

[Patchwork]

== Series Details ==

Series: drm/i915: Replace open-coded wait-for loop
URL   : https://patchwork.freedesktop.org/series/36904/
State : success

== Summary ==

Series 36904v1 drm/i915: Replace open-coded wait-for loop
https://patchwork.freedesktop.org/api/1.0/series/36904/revisions/1/mbox/

Test debugfs_test:
Subgroup read_all_entries:
fail   -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:421s
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:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
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:484s
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:472s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
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:280s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:514s
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:400s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
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:460s
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:459s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
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:430s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:505s
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:487s
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:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:436s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:518s
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:564s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:467s

0edb3ea337349387863e60ed0bdf53b9b2767cf4 drm-tip: 2018y-01m-22d-14h-27m-52s UTC 
integration manifest
c9d1f96dbc20 drm/i915: Replace open-coded wait-for loop

== Logs ==

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

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

[Chris Wilson]

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).

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 intricacies involved
+* here with defeating CPU/compiler speculation and enforcing
+* the required memory barriers.
+*/
+   do {
+   struct drm_i915_gem_request *request;
+
+   request = rcu_dereference(b->first_signal);
+   if (request)
+   request = i915_gem_request_get_rcu(request);
+
+   barrier();
+
+   if (!request || request == 

[Intel-gfx] [PATCH] drm/i915: Replace open-coded wait-for loop

[Chris Wilson]

Now that we can pass arbitrary commands into the base __wait_for()
macro, we can reimplement the open-coded wait-for inside
i915_gem_idle_work_handler() using the macro. This means that instead of
using ktime, we now use jiffies, and benefit from the exponential sleep
backoff that allows a fast response if the HW settles quickly.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 

---
Note this depends on __wait_for() from the hdcp topic branch.
---
 drivers/gpu/drm/i915/i915_gem.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7f0684ccc724..cb4df1be0909 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3347,7 +3347,6 @@ 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;
-   ktime_t end;
 
if (!READ_ONCE(dev_priv->gt.awake))
return;
@@ -3356,16 +3355,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
 * Wait for last execlists context complete, but bail out in case a
 * new request is submitted.
 */
-   end = ktime_add_ms(ktime_get(), I915_IDLE_ENGINES_TIMEOUT);
-   do {
-   if (new_requests_since_last_retire(dev_priv))
-   return;
-
-   if (intel_engines_are_idle(dev_priv))
-   break;
-
-   usleep_range(100, 500);
-   } while (ktime_before(ktime_get(), end));
+   __wait_for(if (new_requests_since_last_retire(dev_priv)) return,
+  intel_engines_are_idle(dev_priv),
+  I915_IDLE_ENGINES_TIMEOUT * 1000,
+  10,  1000);
 
rearm_hangcheck =
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
-- 
2.15.1

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

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

[Sagar Arun Kamble]

On 1/22/2018 4:17 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-22 10:38:10)


On 1/22/2018 3:46 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-22 08:26:01)

+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;
+
+   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 +442,31 @@ static int guc_log_runtime_create(struct intel_guc *guc)
  DRM_ERROR("Couldn't create relay chan for GuC logging\n");
   
  ret = -ENOMEM;

-   goto err_vaddr;
+   goto err;
  }
   
  GEM_BUG_ON(guc_log_relay_chan->subbuf_size < subbuf_size);

  guc->log.runtime.relay_chan = guc_log_relay_chan;
   
-   INIT_WORK(>log.runtime.flush_work, capture_logs_work);

  return 0;
   
-err_vaddr:

-   i915_gem_object_unpin_map(guc->log.vma->obj);
-   guc->log.runtime.buf_addr = NULL;
+err:
+   /* logging will be off */
+   i915_modparams.guc_log_level = 0;
  return ret;
   }
   
-static void guc_log_runtime_destroy(struct intel_guc *guc)

+void intel_guc_log_relay_destroy(struct intel_guc *guc)
   {

Now exposed to multiple users, we need to document what the locking
requirements are here. Or add some local locking.

Do you mean locking between relay_create and relay_destroy?

We need a lock around guc->log.runtime.relay_chan as the destroy path is
not ostensibly serialised between multiple potential callers. Ordinarily
I would have said that serialisation for create/destroy/access of
relay_chan was guaranteed by init/fini ordering,
I was also initially thinking that init/fini ordering should take care 
of synchronization.
Checked further and I see that relay_open and relay_destroy are 
synchronized by relay_channels_mutex
and internally if needed through debugfs inode synchronization. So I 
feel we need not add new lock.

  but that's no longer
clear (based on a 5min read of the patch).

The most important question is "can relay_destroy be called while some
user still has access to the relay_chan?"


   Looks like at the
moment, _create is using struct_mutex,

relay_create and relay_destroy are now to be done outside of struct_mutex.
I will add this documentation to the functions.

(lockdep_assert_held :)
-Chris


--
Thanks,
Sagar

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

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

[Chris Wilson]

Quoting Mika Kuoppala (2018-01-22 15:08:16)
> Daniele Ceraolo Spurio  writes:
> 
> > On 19/01/18 05:05, Mika Kuoppala wrote:
> >> Daniele Ceraolo Spurio  writes:
> >> 
> >>> 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,
> >>> 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 ELSQ 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 Gen11+ 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)
> >>>
> >>> Cc: Chris Wilson 
> >>> Signed-off-by: Thomas Daniel 
> >>> Signed-off-by: Rodrigo Vivi 
> >>> Signed-off-by: Daniele Ceraolo Spurio 
> >> 
> >> Was going to adopt this patch from Rodrigo but you were faster.
> >> 
> >> I choose to stash the elsq and use it as a gen11 vs rest toggle:
> >> 
> >> Relevant bits:
> >> 
> >> +static inline void write_port(struct intel_engine_execlists * const 
> >> execlists,
> >> + unsigned int n,
> >> + u64 desc)
> >> +{
> >> +   if (execlists->elsq)
> >> +   gen11_elsq_write(desc, n, execlists->elsq);
> >> +   else
> >> +   gen8_elsp_write(desc, execlists->elsp);
> >> +}
> >> +
> >> +static inline void submit_ports(struct intel_engine_execlists * const 
> >> execlists)
> >> +{
> >> +   /* for gen11+ we need to manually load the submit queue */
> >> +   if (execlists->elsq) {
> >> +   struct intel_engine_cs *engine =
> >> +   container_of(execlists,
> >> +struct intel_engine_cs,
> >> +execlists);
> >> +   struct drm_i915_private *dev_priv = engine->i915;
> >> +
> >> +   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
> >> +   }
> >> +}
> >> +
> >>
> >
> > I was undecided about hiding the code in sub-functions because of the 
> > pre-emption path. There is no need in gen11 to inject a context to 
> > preempt to idle,

Really? The preempt-to-idle is so that we can sync the bookkeeping with
the pending CS interrupts. The HW doesn't require it currently either,
it's the SW that does. If you have a way to avoid that, that should be
applicable to the current code as well?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Mika Kuoppala]

Daniele Ceraolo Spurio  writes:

> On 19/01/18 05:05, Mika Kuoppala wrote:
>> Daniele Ceraolo Spurio  writes:
>> 
>>> 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,
>>> 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 ELSQ 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 Gen11+ 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)
>>>
>>> Cc: Chris Wilson 
>>> Signed-off-by: Thomas Daniel 
>>> Signed-off-by: Rodrigo Vivi 
>>> Signed-off-by: Daniele Ceraolo Spurio 
>> 
>> Was going to adopt this patch from Rodrigo but you were faster.
>> 
>> I choose to stash the elsq and use it as a gen11 vs rest toggle:
>> 
>> Relevant bits:
>> 
>> +static inline void write_port(struct intel_engine_execlists * const 
>> execlists,
>> + unsigned int n,
>> + u64 desc)
>> +{
>> +   if (execlists->elsq)
>> +   gen11_elsq_write(desc, n, execlists->elsq);
>> +   else
>> +   gen8_elsp_write(desc, execlists->elsp);
>> +}
>> +
>> +static inline void submit_ports(struct intel_engine_execlists * const 
>> execlists)
>> +{
>> +   /* for gen11+ we need to manually load the submit queue */
>> +   if (execlists->elsq) {
>> +   struct intel_engine_cs *engine =
>> +   container_of(execlists,
>> +struct intel_engine_cs,
>> +execlists);
>> +   struct drm_i915_private *dev_priv = engine->i915;
>> +
>> +   I915_WRITE_FW(RING_ELCR(engine), ELCR_LOAD);
>> +   }
>> +}
>> +
>>
>
> I was undecided about hiding the code in sub-functions because of the 
> pre-emption path. There is no need in gen11 to inject a context to 
> preempt to idle, so the inject_preempt function will be pre-gen11 only 
> and therefore I'd prefer to keep a direct call to elsp_write there. IMHO 
> it'd be cleaner to have similar code in both places, hence the 
> open-coding. This said, I'd be happy to change it like you proposed if 
> there is a general preference to abstract things a bit in the shared 
> path even if the pre-emption path stays different.
>

Please don't change. I did the more abstract version before
learning that gen11 don't need the special preempt switch.

> Regarding using execlists->elsq as a toggle, I was thinking that we 
> could have a device info flag instead, so we could use it even before 
> setting execlists->elsq. Any preference on this?

has_logical_ring_elsq? Doesn't taste bad.

> Thanks,
> Daniele
>
> P.S. If you want to take over feel free to send an updated patch ;)
>

No need to take over, I thought it was orphaned patch :)

-Mika

>> ...
>> -Mika
>> 
>>> ---
>>>   drivers/gpu/drm/i915/i915_drv.h |  5 -
>>>   drivers/gpu/drm/i915/intel_lrc.c| 35 
>>> -
>>>   drivers/gpu/drm/i915/intel_lrc.h|  3 +++
>>>   drivers/gpu/drm/i915/intel_ringbuffer.h |  6 --
>>>   4 files changed, 41 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index c42015b..3163543 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -2738,8 +2738,11 @@ static inline unsigned int i915_sg_segment_size(void)
>>>   
>>>   #define HAS_LOGICAL_RING_CONTEXTS(dev_priv) \
>>> ((dev_priv)->info.has_logical_ring_contexts)
>>> +
>>> +/* XXX: Preemption disabled for Gen11+ 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 && \
>>> +INTEL_GEN(dev_priv) < 11)
>>>   
>>>   #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>>>   
>>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
>>> b/drivers/gpu/drm/i915/intel_lrc.c
>>> index 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915: Increase render/media power gating hysteresis for gen9+ (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v2] drm/i915: Increase render/media power gating 
hysteresis for gen9+ (rev3)
URL   : https://patchwork.freedesktop.org/series/36842/
State : success

== Summary ==

Series 36842v3 series starting with [v2] drm/i915: Increase render/media power 
gating hysteresis for gen9+
https://patchwork.freedesktop.org/api/1.0/series/36842/revisions/3/mbox/

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:428s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:435s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:386s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:520s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:294s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:500s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:499s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:489s
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:309s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
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:407s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:425s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:471s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:422s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:464s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:462s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:631s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:441s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:522s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:539s
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:487s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:425s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:442s
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:411s
Blacklisted hosts:
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:487s

8748fd927893780fde7b782d41ed70d0fd1d388e drm-tip: 2018y-01m-22d-12h-23m-58s UTC 
integration manifest
63181736bea6 drm/i915/execlists: Skip forcewake for ELSP submission
918ce1a71b8f drm/i915: Increase render/media power gating hysteresis for gen9+

== Logs ==

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

[Intel-gfx] [PATCH v2] drm/i915: Increase render/media power gating hysteresis for gen9+

[Chris Wilson]

On gen9+, after an idle period the HW will disable the entire power well
to conserve power (by preventing current leakage). It takes around a 100
microseconds to bring the power well back online afterwards. With the
current hysteresis value of 25us (really 25 * 1280ns), we do not have
sufficient time to respond to an interrupt and schedule the next execution
before the HW powers itself down. (At present, we prevent this by
grabbing the forcewake for prolonged periods of time, but that overkill
fixed in the next patch.) The minimum we want to set the power gating
hysteresis to is the length of time it takes us to service the GPU, which
across a broad spectrum of machines is about 250us.

(Note this also brings guc latency into the same ballpark as execlists.)

v2: Include some notes on where I plucked the numbers from.

Testcase: igt/gem_exec_nop/sequential
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Michel Thierry 
Cc: Michal Winiarski 
Reviewed-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1db79a860b96..0b92ea1dbd40 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6626,9 +6626,29 @@ static void gen9_enable_rc6(struct drm_i915_private 
*dev_priv)
 
I915_WRITE(GEN6_RC_SLEEP, 0);
 
-   /* 2c: Program Coarse Power Gating Policies. */
-   I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 25);
-   I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 25);
+   /*
+* 2c: Program Coarse Power Gating Policies.
+*
+* Bspec's guidance is to use 25us (really 25 * 1280ns) here. What we
+* use instead is a more conservative estimate for the maximum time
+* it takes us to service a CS interrupt and submit a new ELSP - that
+* is the time which the GPU is idle waiting for the CPU to select the
+* next request to execute. If the idle hysteresis is less than that
+* interrupt service latency, the hardware will automatically gate
+* the power well and we will then incur the wake up cost on top of
+* the service latency. A similar guide from intel_pstate is that we
+* do not want the enable hysteresis to less than the wakeup latency.
+*
+* igt/gem_exec_nop/sequential provides a rough estimate for the
+* service latency, and puts it around 10us for Broadwell (and other
+* big core) and around 40us for Broxton (and other low power cores).
+* [Note that for legacy ringbuffer submission, this is less than 1us!]
+* However, the wakeup latency on Broxton is closer to 100us. To be
+* conservative, we have to factor in a context switch on top (due
+* to ksoftirqd).
+*/
+   I915_WRITE(GEN9_MEDIA_PG_IDLE_HYSTERESIS, 250);
+   I915_WRITE(GEN9_RENDER_PG_IDLE_HYSTERESIS, 250);
 
/* 3a: Enable RC6 */
I915_WRITE(GEN6_RC6_THRESHOLD, 37500); /* 37.5/125ms per EI */
-- 
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 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband

[Chris Wilson]

Quoting Mika Kuoppala (2018-01-15 12:04:40)
> Chris Wilson  writes:
> 
> > While we talk to the punit over its sideband, we need to prevent the cpu
> > from sleeping in order to prevent a potential machine hang.
> >
> > Note that by itself, it appears that pm_qos_update_request (via
> > intel_idle) doesn't provide a sufficient barrier to ensure that all core
> > are indeed awake (out of Cstate) and that the package is awake. To do so,
> > we need to supplement the pm_qos with a manual ping on_each_cpu.
> >
> > v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
> > is insufficient evidence to implicate a wider problem atm. Similarly,
> > restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
> > of users.
> >
> 
> One datapoint about the v1 of this patch with the cpu ping in it.
> The j1900 byt did end up with system hang during weekend with
> drm-tip + v1.

Fwiw, I've reproduced a scenario that triggers j1900 death:
gem_exec_load/pulse.

So far so good with essentially this patchset on drm-tip. Does that
testcase trigger the bug for you?
-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 [1/4] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

[Patchwork]

== Series Details ==

Series: series starting with [1/4] drm/i915/guc: Fix lockdep due to log relay 
channel handling under struct_mutex
URL   : https://patchwork.freedesktop.org/series/36875/
State : failure

== Summary ==

Test drv_suspend:
Subgroup forcewake:
skip   -> PASS   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-indfb-draw-render:
fail   -> PASS   (shard-apl) fdo#101623 +1
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw)
Subgroup rcs-wf_vblank-vs-dpms-interruptible:
dmesg-warn -> PASS   (shard-hsw) fdo#102614
Subgroup flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-apl) fdo#102887
Subgroup modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-apl) fdo#103060
Subgroup vblank-vs-suspend-interruptible:
incomplete -> PASS   (shard-hsw) fdo#100368

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

shard-apltotal:2702 pass:1669 dwarn:1   dfail:0   fail:25  skip:1006 
time:14465s
shard-hswtotal:2780 pass:1721 dwarn:1   dfail:0   fail:15  skip:1042 
time:15536s
shard-snbtotal:2780 pass:1316 dwarn:1   dfail:0   fail:13  skip:1450 
time:8109s
Blacklisted hosts:
shard-kbltotal:2776 pass:1834 dwarn:1   dfail:0   fail:24  skip:916 
time:10705s

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Allow clients to query own per-engine busyness

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-01-22 11:45:04)
> 
> On 22/01/2018 10:00, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-01-22 09:53:27)
> >>
> >> On 19/01/2018 21:08, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-01-19 13:45:24)
>  +   case I915_CONTEXT_GET_ENGINE_BUSY:
>  +   engine = intel_engine_lookup_user(i915, args->class,
>  + args->instance);
>  +   if (!engine) {
>  +   ret = -EINVAL;
>  +   break;
>  +   }
>  +
>  +   ce = >engine[engine->id];
>  +   if (!READ_ONCE(ce->stats.enabled)) {
>  +   ret = i915_mutex_lock_interruptible(dev);
>  +   if (!ret)
>  +   break;
>  +
>  +   if (!ce->stats.enabled) {
>  +   ret = intel_enable_engine_stats(engine);
> >>>
> >>> * Blink.
> >>>
> >>> This caught me by surprise. (Other than struct_mutex) Not too offensive,
> >>> but surprising. At the very least call out to a function to handle the
> >>> request. Where did args->class, args->instance come from? You surely
> >>> didn't extend the ioctl struct just for that?
> >>
> >> Haven't extended it no, just did this:
> >>
> >> --- a/include/uapi/drm/i915_drm.h
> >> +++ b/include/uapi/drm/i915_drm.h
> >> @@ -1468,7 +1468,16 @@ struct drm_i915_gem_context_param {
> >>#define   I915_CONTEXT_MAX_USER_PRIORITY  1023 /* inclusive */
> >>#define   I915_CONTEXT_DEFAULT_PRIORITY   0
> >>#define   I915_CONTEXT_MIN_USER_PRIORITY  -1023 /* inclusive */
> >> -   __u64 value;
> >> +#define I915_CONTEXT_GET_ENGINE_BUSY   0x7
> >> +   union {
> >> +   __u64 value;
> >> +   struct {
> >> +   __u8 pad[6]; /* unused */
> >> +
> >> +   __u8 class;
> >> +   __u8 instance;
> >> +   };
> >> +   };
> >>};
> > 
> > Not entirely happy about mixing in/out parameters. It's already
> > complicated by being either an out value or an out pointer.
> > 
> > Closer to the original idea for context_getparam would be to return the
> > array of engine values.
> 
> It would have the advantage that multiple engines could be queried 
> (more) atomically. How about then:
> 
> I915_CONTEXT_ENABLE_ENGINE_STATS:
> value = &{
> __u32 num_engines;
> __u32 pad;
> 
> struct {
> __u8 class;
> __u8 instance;
> __u8 pad[6];
> } [num_engines];
> };
> 
> I915_CONTEXT_GET_ENGINE_STATS:
> value = &{
> __u32 num_engines;
> __u32 pad;
> 
> struct {
> __u8 class;
> __u8 instance;
> __u8 pad[6];
> 
> __u64 busy;
> } [num_engines];
> };

Yes, that's what I had in mind. How does that work in practice? Does it
make userspace too clumsy?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Adding NV12 support (rev7)

[Patchwork]

== Series Details ==

Series: Adding NV12 support (rev7)
URL   : https://patchwork.freedesktop.org/series/28103/
State : success

== Summary ==

Series 28103v7 Adding NV12 support
https://patchwork.freedesktop.org/api/1.0/series/28103/revisions/7/mbox/

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:427s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:432s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:383s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:521s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:292s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:501s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:494s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:479s
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:307s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:394s
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:420s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:468s
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:464s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:510s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:634s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:436s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:519s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:534s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:427s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:442s
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:409s
Blacklisted hosts:
fi-cfl-s2total:288  pass:256  dwarn:0   dfail:0   fail:3   skip:26  
time:564s
fi-glk-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:485s

be38e25290c9e7d4fe196977d71ea4aba7d92dd1 drm-tip: 2018y-01m-22d-11h-16m-45s UTC 
integration manifest
eb196c11b901 drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg
0c7152ea9eea drm/i915: Add NV12 support to intel_framebuffer_init
9d2ea1c202e1 drm/i915: Add NV12 as supported format for sprite plane
514cf2654ce7 drm/i915: Add NV12 as supported format for primary plane
9d6475430376 drm/i915: Upscale scaler max scale for NV12
de495f7786ef drm/i915: Update format_is_yuv() to include NV12
6ad39e4b8620 drm/i915: Set scaler mode for NV12
6c62dead084e drm/i915/skl: split skl_compute_ddb function
b7024c4da6d9 drm/i915/skl+: nv12 workaround disable WM level 1-7
97ae3e76f79b drm/i915/skl+: make sure higher latency level has higher wm value
61331a2db19b drm/i915/skl+: pass skl_wm_level struct to wm compute func
56148e08cf02 drm/i915/skl+: NV12 related changes for WM
3baebdbb122f drm/i915/skl+: support verification of DDB HW state for NV12
bb3fd7868e54 drm/i915/skl+: add NV12 in skl_format_to_fourcc
6a0ed4afec26 drm/i915/skl+: refactor WM calculation for NV12
009a14962919 drm/i915/skl+: rename skl_wm_values struct to skl_ddb_values

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7737/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: Protect WC stash allocation against direct reclaim

[Chris Wilson]

Quoting Matthew Auld (2018-01-22 11:04:33)
> On 21 January 2018 at 17:31, Chris Wilson  wrote:
> > As we attempt to allocate pages for use in a new WC stash, direct
> > reclaim may run underneath us and fill up the WC stash. We have to be
> > careful then not to overflow the pvec.
> >
> > Fixes: 66df1014efba ("drm/i915: Keep a small stash of preallocated WC 
> > pages")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103109
> > Signed-off-by: Chris Wilson 
> > Cc: Matthew Auld 
> > Cc: Joonas Lahtinen 
> 
> Yikes.

Quite the understatement :)

> Reviewed-by: Matthew Auld 

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

Re: [Intel-gfx] [PATCH 10/10] drm/i915/cnl: Don't try to manage Port F power wells on all CNL.

[Imre Deak]

On Fri, Jan 19, 2018 at 04:05:24PM -0800, Rodrigo Vivi wrote:
> SKUs that lacks on the full port F split will just time out
> when touching this power well bits, causing a noisy warn.
> 
> This macro style is a deviation from the original definition in use
> for other platforms, but it at least avoid code duplication.
> Other smart alternatives like providing a joint list was also considered
> but it would require some extra memory handling that would be
> a deviation from the original simplistic definitions here anyways,
> plus requiring extra tests and possibly creating some corner cases
> for one single platform. So let's move with the simplest and safest
> approach.
> 
> Cc: Lucas De Marchi 
> Cc: Imre Deak 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 177 
> +---
>  1 file changed, 94 insertions(+), 83 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 433048ffa5c6..8dbc9b138ffd 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -2334,89 +2334,96 @@ static struct i915_power_well glk_power_wells[] = {
>   },
>  };
>  
> +#define basic_cnl_power_wells
> \
> + {   \
> + .name = "always-on",\
> + .always_on = 1, \
> + .domains = POWER_DOMAIN_MASK,   \
> + .ops = _always_on_power_well_ops,  \
> + .id = I915_DISP_PW_ALWAYS_ON,   \
> + },  \
> + {   \
> + .name = "power well 1", \
> + /* Handled by the DMC firmware */   \
> + .domains = 0,   \
> + .ops = _power_well_ops, \
> + .id = SKL_DISP_PW_1,\
> + {   \
> + .hsw.has_fuses = true,  \
> + },  \
> + },  \
> + {   \
> + .name = "AUX A",\
> + .domains = CNL_DISPLAY_AUX_A_POWER_DOMAINS, \
> + .ops = _power_well_ops, \
> + .id = CNL_DISP_PW_AUX_A,\
> + },  \
> + {   \
> + .name = "AUX B",\
> + .domains = CNL_DISPLAY_AUX_B_POWER_DOMAINS, \
> + .ops = _power_well_ops, \
> + .id = CNL_DISP_PW_AUX_B,\
> + },  \
> + {   \
> + .name = "AUX C",\
> + .domains = CNL_DISPLAY_AUX_C_POWER_DOMAINS, \
> + .ops = _power_well_ops, \
> + .id = CNL_DISP_PW_AUX_C,\
> + },  \
> + {   \
> + .name = "AUX D",\
> + .domains = CNL_DISPLAY_AUX_D_POWER_DOMAINS, \
> + .ops = _power_well_ops, \
> + .id = CNL_DISP_PW_AUX_D,\
> + },  \
> + {   \
> + .name = "DC off",   \
> + .domains = CNL_DISPLAY_DC_OFF_POWER_DOMAINS,\
> + .ops = _dc_off_power_well_ops, \
> + .id = SKL_DISP_PW_DC_OFF,   \
> + },  \
> + {   \
> + .name = "power well 2", \
> +   

Re: [Intel-gfx] [PATCH i-g-t 4/4] scripts/trace.pl: Simplify 'end' & 'notify' generation

[Tvrtko Ursulin]

On 20/01/2018 00:24, john.c.harri...@intel.com wrote:

From: John Harrison 

Delay the auto-generation of end/notify values until the point where
everything is known. As opposed to potentially generating them
multiple times with differing values.

Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
---
  scripts/trace.pl | 31 ++-
  1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/scripts/trace.pl b/scripts/trace.pl
index c5d822aa..fbf4b92e 100755
--- a/scripts/trace.pl
+++ b/scripts/trace.pl
@@ -467,10 +467,11 @@ while (<>) {
  }
  
  # Sanitation pass to fixup up out of order notify and context complete, and to

-# fine the largest seqno to be used for timeline sorting purposes.
+# find the largest seqno to be used for timeline sorting purposes.
  my $max_seqno = 0;
  foreach my $key (keys %db) {
my $gkey = global_key($db{$key}->{'ring'}, $db{$key}->{'global'});
+   my $notify = $notify{$gkey};
  
  	die unless exists $db{$key}->{'start'};
  
@@ -478,23 +479,21 @@ foreach my $key (keys %db) {
  
  	unless (exists $db{$key}->{'end'}) {

# Context complete not received.
-   if (exists $notify{$gkey}) {
+   $db{$key}->{'no-end'} = 1;
+
+   if (defined($notify)) {
# No context complete due req merging - use notify.
-   $db{$key}->{'notify'} = $notify{$gkey};
-   $db{$key}->{'end'} = $db{$key}->{'notify'};
-   $db{$key}->{'no-end'} = 1;
+   $db{$key}->{'notify'} = $notify;
+   $db{$key}->{'end'} = $notify;
} else {
-   # No notify and no context complete - mark it.
-   $db{$key}->{'no-end'} = 1;
-   $db{$key}->{'end'} = $db{$key}->{'start'} + 999;
-   $db{$key}->{'notify'} = $db{$key}->{'end'};
+   # No notify and no context complete - give up for now.
$db{$key}->{'incomplete'} = 1;
}
} else {
# Notify arrived after context complete.
-   if (exists $db{$key}->{'no-notify'} and exists $notify{$gkey}) {
+   if (exists $db{$key}->{'no-notify'} and defined($notify)) {
delete $db{$key}->{'no-notify'};
-   $db{$key}->{'notify'} = $notify{$gkey};
+   $db{$key}->{'notify'} = $notify;
}
}
  }
@@ -511,6 +510,7 @@ foreach my $key (@keys) {
my $seqno = $db{$key}->{'seqno'};
my $next_key;
my $i = 1;
+   my $end;
  
  	do {

$next_key = db_key($ring, $ctx, $seqno + $i);
@@ -519,9 +519,14 @@ foreach my $key (@keys) {
 or $i > $keyCount);  # ugly stop hack
  
  	if (exists $db{$next_key}) {

-   $db{$key}->{'notify'} = $db{$next_key}->{'end'};
-   $db{$key}->{'end'} = $db{$key}->{'notify'};
+   $end = $db{$next_key}->{'end'};
+   } else {
+   # No info at all, fake it:
+   $end = $db{$key}->{'start'} + 999;
}
+
+   $db{$key}->{'notify'} = $end;
+   $db{$key}->{'end'} = $end;
  }
  
  # GPU time accounting




Looks cleaner and still correct. Just please explain in the commit that 
the description applies only for requests marked as incomplete. AFICS 
those were the only ones it was setting the end and notify times 
potentially two times.


Regards,

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

[Intel-gfx] [PATCH 09/16] drm/i915/skl: split skl_compute_ddb function

[Vidya Srinivas]

From: Mahesh Kumar 

This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_pm.c | 157 ++--
 1 file changed, 88 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0ab84e4..7785f13 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5009,69 +5009,16 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
*cstate)
 static int
 skl_compute_ddb(struct drm_atomic_state *state)
 {
-   struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_i915_private *dev_priv = to_i915(state->dev);
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct intel_crtc *intel_crtc;
struct skl_ddb_allocation *ddb = _state->wm_results.ddb;
-   uint32_t realloc_pipes = pipes_modified(state);
-   int ret;
-
-   /*
-* If this is our first atomic update following hardware readout,
-* we can't trust the DDB that the BIOS programmed for us.  Let's
-* pretend that all pipes switched active status so that we'll
-* ensure a full DDB recompute.
-*/
-   if (dev_priv->wm.distrust_bios_wm) {
-   ret = drm_modeset_lock(>mode_config.connection_mutex,
-  state->acquire_ctx);
-   if (ret)
-   return ret;
-
-   intel_state->active_pipe_changes = ~0;
-
-   /*
-* We usually only initialize intel_state->active_crtcs if we
-* we're doing a modeset; make sure this field is always
-* initialized during the sanitization process that happens
-* on the first commit too.
-*/
-   if (!intel_state->modeset)
-   intel_state->active_crtcs = dev_priv->active_crtcs;
-   }
-
-   /*
-* If the modeset changes which CRTC's are active, we need to
-* recompute the DDB allocation for *all* active pipes, even
-* those that weren't otherwise being modified in any way by this
-* atomic commit.  Due to the shrinking of the per-pipe allocations
-* when new active CRTC's are added, it's possible for a pipe that
-* we were already using and aren't changing at all here to suddenly
-* become invalid if its DDB needs exceeds its new allocation.
-*
-* Note that if we wind up doing a full DDB recompute, we can't let
-* any other display updates race with this transaction, so we need
-* to grab the lock on *all* CRTC's.
-*/
-   if (intel_state->active_pipe_changes) {
-   realloc_pipes = ~0;
-   intel_state->wm_results.dirty_pipes = ~0;
-   }
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *cstate;
+   int ret, i;
 
-   /*
-* We're not recomputing for the pipes not included in the commit, so
-* make sure we start with the current state.
-*/
memcpy(ddb, _priv->wm.skl_hw.ddb, sizeof(*ddb));
 
-   for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
-   struct intel_crtc_state *cstate;
-
-   cstate = intel_atomic_get_crtc_state(state, intel_crtc);
-   if (IS_ERR(cstate))
-   return PTR_ERR(cstate);
-
+   for_each_new_intel_crtc_in_state(intel_state, crtc, cstate, i) {
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
@@ -5133,23 +5080,23 @@ skl_print_wm_changes(const struct drm_atomic_state 
*state)
 }
 
 static int
-skl_compute_wm(struct drm_atomic_state *state)
+skl_ddb_add_affected_pipes(struct drm_atomic_state *state, bool *changed)
 {
-   struct drm_crtc *crtc;
-   struct drm_crtc_state *cstate;
-   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
-   struct skl_ddb_values *results = _state->wm_results;
struct drm_device *dev = state->dev;
-   struct skl_pipe_wm *pipe_wm;
-   bool changed = false;
+   const struct drm_i915_private *dev_priv = to_i915(dev);
+   const struct drm_crtc *crtc;
+   const struct drm_crtc_state *cstate;
+   struct intel_crtc *intel_crtc;
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   uint32_t realloc_pipes = pipes_modified(state);
int ret, i;
 
/*
 * When we distrust bios wm we always need to recompute to set the
 * expected DDB allocations for each CRTC.
 */
-   if (to_i915(dev)->wm.distrust_bios_wm)
-   changed = true;
+   if 

[Intel-gfx] [PATCH 12/16] drm/i915: Upscale scaler max scale for NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch updates scaler max limit support for NV12

v2: Rebased (me)

v3: Rebased (me)

v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series

v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Rebased (me)

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 33 +++--
 drivers/gpu/drm/i915/intel_drv.h |  3 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  3 ++-
 3 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ffc7a63..0893c11 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3397,6 +3397,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_UYVY;
case DRM_FORMAT_VYUY:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
+   case DRM_FORMAT_NV12:
+   return PLANE_CTL_FORMAT_NV12;
default:
MISSING_CASE(pixel_format);
}
@@ -4620,7 +4622,8 @@ static void cpt_verify_modeset(struct drm_device *dev, 
int pipe)
 static int
 skl_update_scaler(struct intel_crtc_state *crtc_state, bool force_detach,
  unsigned int scaler_user, int *scaler_id,
- int src_w, int src_h, int dst_w, int dst_h)
+ int src_w, int src_h, int dst_w, int dst_h,
+ uint32_t pixel_format)
 {
struct intel_crtc_scaler_state *scaler_state =
_state->scaler_state;
@@ -4636,7 +4639,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, 
bool force_detach,
 * the 90/270 degree plane rotation cases (to match the
 * GTT mapping), hence no need to account for rotation here.
 */
-   need_scaling = src_w != dst_w || src_h != dst_h;
+   need_scaling = src_w != dst_w || src_h != dst_h ||
+   (pixel_format == DRM_FORMAT_NV12);
 
if (crtc_state->ycbcr420 && scaler_user == SKL_CRTC_INDEX)
need_scaling = true;
@@ -4715,7 +4719,7 @@ int skl_update_scaler_crtc(struct intel_crtc_state *state)
return skl_update_scaler(state, !state->base.active, SKL_CRTC_INDEX,
>scaler_state.scaler_id,
state->pipe_src_w, state->pipe_src_h,
-   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay);
+   adjusted_mode->crtc_hdisplay, adjusted_mode->crtc_vdisplay, 0);
 }
 
 /**
@@ -4745,7 +4749,8 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
drm_rect_width(_state->base.src) >> 16,
drm_rect_height(_state->base.src) >> 16,
drm_rect_width(_state->base.dst),
-   drm_rect_height(_state->base.dst));
+   drm_rect_height(_state->base.dst),
+   fb ? fb->format->format : 0);
 
if (ret || plane_state->scaler_id < 0)
return ret;
@@ -4771,6 +4776,7 @@ static int skl_update_scaler_plane(struct 
intel_crtc_state *crtc_state,
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
+   case DRM_FORMAT_NV12:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format 
0x%x\n",
@@ -12701,11 +12707,12 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
 }
 
 int
-skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state 
*crtc_state)
+skl_max_scale(struct intel_crtc *intel_crtc,
+   struct intel_crtc_state *crtc_state, uint32_t pixel_format)
 {
struct drm_i915_private *dev_priv;
-   int max_scale;
-   int crtc_clock, max_dotclk;
+   int max_scale, mult;
+   int crtc_clock, max_dotclk, tmpclk1, tmpclk2;
 
if (!intel_crtc || !crtc_state->base.enable)
return DRM_PLANE_HELPER_NO_SCALING;
@@ -12727,8 +12734,10 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
 *or
 *cdclk/crtc_clock
 */
-   max_scale = min((1 << 16) * 3 - 1,
-   (1 << 8) * ((max_dotclk << 8) / crtc_clock));
+ 

[Intel-gfx] [PATCH 11/16] drm/i915: Update format_is_yuv() to include NV12

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to format_is_yuv() function
for sprite planes.

v2:
-Use intel_ prefix for format_is_yuv (Ville)

v3: Rebased (me)

v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.

v6: Rebased (me)

v7: Rebased (me)

v8: Rebased (me)

v9: Rebased (me)

v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_sprite.c | 8 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7644ca7..3f0af25 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2029,6 +2029,7 @@ void skl_disable_plane(struct intel_plane *plane, struct 
intel_crtc *crtc);
 bool skl_plane_get_hw_state(struct intel_plane *plane);
 bool skl_plane_has_ccs(struct drm_i915_private *dev_priv,
   enum pipe pipe, enum plane_id plane_id);
+bool intel_format_is_yuv(uint32_t format);
 
 /* intel_tv.c */
 void intel_tv_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 9418848..a9ef4da 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -41,14 +41,14 @@
 #include 
 #include "i915_drv.h"
 
-static bool
-format_is_yuv(uint32_t format)
+bool intel_format_is_yuv(uint32_t format)
 {
switch (format) {
case DRM_FORMAT_YUYV:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_NV12:
return true;
default:
return false;
@@ -352,7 +352,7 @@ chv_update_csc(struct intel_plane *plane, uint32_t format)
enum plane_id plane_id = plane->id;
 
/* Seems RGB data bypasses the CSC always */
-   if (!format_is_yuv(format))
+   if (!intel_format_is_yuv(format))
return;
 
/*
@@ -975,7 +975,7 @@ intel_check_sprite_plane(struct intel_plane *plane,
src_y = src->y1 >> 16;
src_h = drm_rect_height(src) >> 16;
 
-   if (format_is_yuv(fb->format->format)) {
+   if (intel_format_is_yuv(fb->format->format)) {
src_x &= ~1;
src_w &= ~1;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 14/16] drm/i915: Add NV12 as supported format for sprite plane

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 to list of supported formats for sprite plane.

v2: Rebased (me)

v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats

v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series

v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.

v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B

v7: Rebased (me)

v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)

v9: Rebased (me)

v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_sprite.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 833b4ad..f6f2ee8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1161,6 +1161,7 @@ static uint32_t skl_plane_formats[] = {
DRM_FORMAT_YVYU,
DRM_FORMAT_UYVY,
DRM_FORMAT_VYUY,
+   DRM_FORMAT_NV12,
 };
 
 static const uint64_t skl_plane_format_modifiers_noccs[] = {
@@ -1359,6 +1360,10 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
plane_formats = skl_plane_formats;
num_plane_formats = ARRAY_SIZE(skl_plane_formats);
 
+   if (INTEL_GEN(dev_priv) <= 10 && ((plane != 0) ||
+   (pipe == PIPE_C)))
+   num_plane_formats -= 1;
+
if (skl_plane_has_ccs(dev_priv, pipe, PLANE_SPRITE0 + plane))
modifiers = skl_plane_format_modifiers_ccs;
else
-- 
2.7.4

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

[Intel-gfx] [PATCH 16/16] drm/i915: Enable YUV to RGB for Gen10 in Plane Ctrl Reg

[Vidya Srinivas]

If the fb format is YUV, enable the plane CSC mode bits
for the conversion.

Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/i915_reg.h  | 6 ++
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 492a1b8..6db7d1a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6384,6 +6384,12 @@ enum {
 #define _PLANE_COLOR_CTL_3_A   0x703CC /* GLK+ */
 #define   PLANE_COLOR_PIPE_GAMMA_ENABLE(1 << 30)
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23)
+#define PLANE_COLOR_CSC_MASK   (0x7 << 17)
+#define PLANE_COLOR_CSC_MODE_BYPASS(0 << 17)
+#define PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709  (1 << 17)
+#define PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709  (2 << 17)
+#define PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020(3 << 17)
+#define PLANE_COLOR_CSC_MODE_RGB709_TO_RGB2020 (4 << 17)
 #define   PLANE_COLOR_PLANE_GAMMA_DISABLE  (1 << 13)
 #define   PLANE_COLOR_ALPHA_MASK   (0x3 << 4)
 #define   PLANE_COLOR_ALPHA_DISABLE(0 << 4)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0f87bf3..da9282d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3539,6 +3539,8 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state 
*crtc_state,
plane_color_ctl |= PLANE_COLOR_PIPE_CSC_ENABLE;
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
plane_color_ctl |= glk_plane_color_ctl_alpha(fb->format->format);
+   if (intel_format_is_yuv(fb->format->format))
+   plane_color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
 
return plane_color_ctl;
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH 15/16] drm/i915: Add NV12 support to intel_framebuffer_init

[Vidya Srinivas]

From: Chandra Konduru 

This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.

v2:
-Fix an issue in checks added (Chandra Konduru)

v3: rebased (me)

v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case

v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.

v6: Rebased (me)

v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.

v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.

v9: Rebased (me)

v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable

Tested-by: Clinton Taylor 
Reviewed-by: Clinton Taylor 
Signed-off-by: Chandra Konduru 
Signed-off-by: Nabendu Maiti 
Signed-off-by: Vidya Srinivas 
---
 drivers/gpu/drm/i915/intel_display.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c6fbb05..0f87bf3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13976,6 +13976,14 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
goto err;
}
break;
+   case DRM_FORMAT_NV12:
+   if (INTEL_GEN(dev_priv) < 9) {
+   DRM_DEBUG_KMS("unsupported pixel format: %s\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+   _name));
+   goto err;
+   }
+   break;
default:
DRM_DEBUG_KMS("unsupported pixel format: %s\n",
  drm_get_format_name(mode_cmd->pixel_format, 
_name));
-- 
2.7.4

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

[Intel-gfx] [PATCH 03/16] drm/i915/skl+: add NV12 in skl_format_to_fourcc

[Vidya Srinivas]

From: Mahesh Kumar 

Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 91f3c0a..a1e4a5e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2612,6 +2612,8 @@ static int skl_format_to_fourcc(int format, bool 
rgb_order, bool alpha)
switch (format) {
case PLANE_CTL_FORMAT_RGB_565:
return DRM_FORMAT_RGB565;
+   case PLANE_CTL_FORMAT_NV12:
+   return DRM_FORMAT_NV12;
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
-- 
2.7.4

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