Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[Sagar Arun Kamble]

On 3/2/2018 12:44 AM, John Spotswood wrote:

On Thu, 2018-03-01 at 17:35 +0530, Sagar Arun Kamble wrote:

On 3/1/2018 1:32 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-02-28 22:07:51)

On 28/02/18 12:26, Michel Thierry wrote:

On 28/02/18 10:42, Piotr Piórkowski wrote:

In the i915 driver, there is a function,
intel_guc_init_params(),
which initializes the GuC parameter block which is passed
into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().


Hi,

Looking at the fw code, you're partially right, GfxGtType is
ignored...
but GfxCoreFamily isn't.


Unless whoever wrote the fw was smart enough to forget to call
the
function that is reading GfxCoreFamily... I didn't count on that.

Is the intention to use GfxCoreFamily documented, i.e. are they
expecting it part of the interface and may re-instantiate the check
"because it was always supposed to exist" in some future version?

Usage of GfxCoreFamily is only in SLPC and for platform specific
initialization and might be removed in future interfaces.
If needed, we can add as part of SLPC patches.

Michel and I have traced through the FW code, and both parameters are
unused.  GfxCoreFamily does appear to be set in the FW, and it gets
passed into SLPC, but then it never gets used.

Hi John,

It is needed for SLPC initialization. Verified on v9 GuC firmware that 
SLPC GTPERF gets disabled if i915 does not send this param.
We can add this param as part of SLPC patches for GuC versions which 
need them.


Thanks
Sagar

   I have confirmed with
FW developers that these parameters have been removed for future gens.

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


--
Thanks,
Sagar

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev2)
URL   : https://patchwork.freedesktop.org/series/39238/
State : success

== Summary ==

 Possible new issues:

Test kms_fence_pin_leak:
incomplete -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup 2x-plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060

shard-apltotal:3300 pass:1733 dwarn:1   dfail:0   fail:6   skip:1557 
time:11316s
shard-hswtotal:3461 pass:1765 dwarn:1   dfail:0   fail:4   skip:1690 
time:11685s
shard-snbtotal:3461 pass:1357 dwarn:4   dfail:0   fail:1   skip:2099 
time:6638s
Blacklisted hosts:
shard-kbltotal:3461 pass:1946 dwarn:1   dfail:0   fail:7   skip:1507 
time:9518s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Register definitions for DP Phy compiance

[Patchwork]

== Series Details ==

Series: drm/i915: Register definitions for DP Phy compiance
URL   : https://patchwork.freedesktop.org/series/39233/
State : success

== Summary ==

 Possible new issues:

Test kms_fence_pin_leak:
incomplete -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2

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

shard-apltotal:3300 pass:1733 dwarn:1   dfail:0   fail:6   skip:1557 
time:11366s
shard-hswtotal:3461 pass:1768 dwarn:1   dfail:0   fail:1   skip:1690 
time:11942s
shard-snbtotal:3461 pass:1359 dwarn:2   dfail:0   fail:1   skip:2099 
time:6694s
Blacklisted hosts:
shard-kbltotal:3435 pass:1932 dwarn:1   dfail:0   fail:6   skip:1495 
time:9097s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: local_clock returns an u64

[Patchwork]

== Series Details ==

Series: drm/i915/icl: local_clock returns an u64
URL   : https://patchwork.freedesktop.org/series/39231/
State : success

== Summary ==

 Possible new issues:

Test kms_fence_pin_leak:
incomplete -> PASS   (shard-apl)

 Known issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test pm_rpm:
Subgroup system-suspend-execbuf:
pass   -> INCOMPLETE (shard-hsw) fdo#103375

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

shard-apltotal:3461 pass:1820 dwarn:1   dfail:0   fail:7   skip:1632 
time:12111s
shard-hswtotal:3399 pass:1735 dwarn:1   dfail:0   fail:1   skip:1660 
time:11519s
shard-snbtotal:3461 pass:1359 dwarn:2   dfail:0   fail:1   skip:2099 
time:6662s
Blacklisted hosts:
shard-kbltotal:3391 pass:1905 dwarn:4   dfail:0   fail:7   skip:1474 
time:9149s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/1] drm/i915/uc: Make GuC/HuC fw fetch and 
loading functions/file structure symmetric
URL   : https://patchwork.freedesktop.org/series/39224/
State : success

== Summary ==

 Possible new issues:

Test kms_fence_pin_leak:
incomplete -> PASS   (shard-apl)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +4
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
pass   -> FAIL   (shard-hsw) fdo#102887
Test perf:
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3300 pass:1733 dwarn:1   dfail:0   fail:6   skip:1557 
time:11413s
shard-hswtotal:3461 pass:1766 dwarn:1   dfail:0   fail:3   skip:1690 
time:11867s
shard-snbtotal:3461 pass:1357 dwarn:4   dfail:0   fail:1   skip:2099 
time:6602s
Blacklisted hosts:
shard-kbltotal:3461 pass:1945 dwarn:1   dfail:0   fail:7   skip:1508 
time:9419s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8201/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: Check for I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset

[Lyude Paul]

Pushed with some small whitespace changes to make sparse happy, thanks!

On Wed, 2018-02-21 at 10:28 +0100, Maarten Lankhorst wrote:
> Moving the check upwards will mean we we no longer have to add planes
> and connectors manually, because everything is handled correctly by
> drm_atomic_helper_check_modeset() as intended.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Lyude Paul 
> Cc: Daniel Vetter 
> Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 20 +---
>  1 file changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 65be7af7f647..c5cc9022d545 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11927,6 +11927,11 @@ static int intel_atomic_check(struct drm_device
> *dev,
>   int ret, i;
>   bool any_ms = false;
>  
> + /* Catch I915_MODE_FLAG_INHERITED */
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> crtc_state, i)
> + if (crtc_state->mode.private_flags != old_crtc_state-
> >mode.private_flags)
> + crtc_state->mode_changed = true;
> +
>   ret = drm_atomic_helper_check_modeset(dev, state);
>   if (ret)
>   return ret;
> @@ -11935,10 +11940,6 @@ static int intel_atomic_check(struct drm_device
> *dev,
>   struct intel_crtc_state *pipe_config =
>   to_intel_crtc_state(crtc_state);
>  
> - /* Catch I915_MODE_FLAG_INHERITED */
> - if (crtc_state->mode.private_flags != old_crtc_state-
> >mode.private_flags)
> - crtc_state->mode_changed = true;
> -
>   if (!needs_modeset(crtc_state))
>   continue;
>  
> @@ -11947,13 +11948,6 @@ static int intel_atomic_check(struct drm_device
> *dev,
>   continue;
>   }
>  
> - /* FIXME: For only active_changed we shouldn't need to do
> any
> -  * state recomputation at all. */
> -
> - ret = drm_atomic_add_affected_connectors(state, crtc);
> - if (ret)
> - return ret;
> -
>   ret = intel_modeset_pipe_config(crtc, pipe_config);
>   if (ret) {
>   intel_dump_pipe_config(to_intel_crtc(crtc),
> @@ -11972,10 +11966,6 @@ static int intel_atomic_check(struct drm_device
> *dev,
>   if (needs_modeset(crtc_state))
>   any_ms = true;
>  
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - return ret;
> -
>   intel_dump_pipe_config(to_intel_crtc(crtc), pipe_config,
>  needs_modeset(crtc_state) ?
>  "[modeset]" : "[fastset]");
-- 
Cheers,
Lyude Paul
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v12,1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Patchwork]

== Series Details ==

Series: series starting with [v12,1/6] drm/i915/guc: Rename guc_ggtt_offset to 
intel_guc_ggtt_offset
URL   : https://patchwork.freedesktop.org/series/39246/
State : failure

== Summary ==

Series 39246v1 series starting with [v12,1/6] drm/i915/guc: Rename 
guc_ggtt_offset to intel_guc_ggtt_offset
https://patchwork.freedesktop.org/api/1.0/series/39246/revisions/1/mbox/

 Possible new issues:

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test debugfs_test:
Subgroup read_all_entries:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
Subgroup basic-reload:
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
Subgroup basic-reload-inject:
pass   -> DMESG-FAIL (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-threads:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_create:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-files:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_exec:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_param:
Subgroup basic:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default-heavy:
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd1:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-bsd2:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-default:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-render:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup gtt-vebox:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-blt:
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup readonly-bsd:
WARNING: Long output truncated
fi-cnl-y3 failed to collect. IGT log at Patchwork_8206/fi-cnl-y3/run0.log

f9dfffd99a0eece6e115bf1f678108dac871ef04 drm-tip: 2018y-03m-02d-00h-00m-27s UTC 
integration manifest
d3be383a46d3 HAX Enable GuC Submission for CI
ed66365a5cb6 drm/i915/guc: Check the locking status of GuC WOPCM registers
69b1615bf155 drm/i915: Add HuC firmware size related restriction for Gen9 and 
CNL A0
4b9ff5708835 drm/i915: Add support to return CNL specific reserved WOPCM size
9b8cd81ac573 drm/i915: Implement dynamic GuC WOPCM offset and size calculation
009573200501 drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8206/issues.html
___
Intel-gfx mailing list

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

[Jackie Li]

Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 08108ce..b49ae20 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -152,7 +152,7 @@ i915_param_named_unsafe(edp_vswing, int, 0400,
 i915_param_named_unsafe(enable_guc, int, 0400,
"Enable GuC load for GuC submission and/or HuC load. "
"Required functionality can be selected using bitmask values. "
-   "(-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load)");
+   "(-1=auto [default], 0=disable, 1=GuC submission, 2=HuC load)");
 
 i915_param_named(guc_log_level, int, 0400,
"GuC firmware logging level. Requires GuC to be loaded. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9..3deae1e 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, 0) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.7.4

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

[Intel-gfx] [PATCH v12 3/6] drm/i915: Add support to return CNL specific reserved WOPCM size

[Jackie Li]

CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
contexts.

This patch updates the code to return CNL specific reserved GuC WOPCM size
for RC6 and other hardware contexts so that the GuC WOPCM size can be
calculated correctly for CNL.

v9:
 - Created a new patch for these changes originally made in v8 4/6 patch of
   this series (Sagar/Michal)

v10:
 - Used if-else ladder to the returning of context sizes (Joonas)

v11:
 - Removed GUC_ prefix from context size macro (Michal)

Bspec: 12690

Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
Reviewed-by: Michal Wajdeczko  (v11)
---
 drivers/gpu/drm/i915/intel_wopcm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 8b2f177..237ca03 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -54,6 +54,8 @@
 
 /* 24KB at the end of WOPCM is reserved for RC6 CTX on BXT. */
 #define BXT_WOPCM_RC6_CTX_RESERVED (24 * 1024)
+/* 36KB WOPCM reserved at the end of WOPCM on CNL. */
+#define CNL_WOPCM_HW_CTX_RESERVED  (36 * 1024)
 
 /* 128KB from GUC_WOPCM_RESERVED is reserved for FW on Gen9. */
 #define GEN9_GUC_FW_RESERVED   (128 * 1024)
@@ -76,6 +78,8 @@ static inline u32 context_reserved_size(struct 
drm_i915_private *i915)
 {
if (IS_GEN9_LP(i915))
return BXT_WOPCM_RC6_CTX_RESERVED;
+   else if (INTEL_GEN(i915) >= 10)
+   return CNL_WOPCM_HW_CTX_RESERVED;
else
return 0;
 }
-- 
2.7.4

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

[Intel-gfx] [PATCH v12 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Jackie Li]

GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its GuC related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates
the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the future
patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.

v8:
 - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h (Sagar)
 - Updated commit message to explain to reason and motivation to add
   intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)

v9:
 - Fixed code alignment issue due to line break (Chris)

v10:
 - Removed unnecessary comments, redundant code and avoided reuse variable
   to avoid potential issues (Joonas)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
Reviewed-by: Michal Wajdeczko  (v11)
---
 drivers/gpu/drm/i915/intel_guc.c| 11 ++-
 drivers/gpu/drm/i915/intel_guc.h| 14 --
 drivers/gpu/drm/i915/intel_guc_ads.c|  8 
 drivers/gpu/drm/i915/intel_guc_ct.c |  5 +++--
 drivers/gpu/drm/i915/intel_guc_fw.c |  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_reg.h|  3 ---
 drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
 drivers/gpu/drm/i915/intel_huc.c|  6 --
 9 files changed, 36 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e6512cc..a788e15 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -269,8 +269,9 @@ void intel_guc_init_params(struct intel_guc *guc)
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
-   u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT;
-   u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool);
+   u32 ads = intel_guc_ggtt_offset(guc,
+   guc->ads_vma) >> PAGE_SHIFT;
+   u32 pgs = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16;
 
params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT;
@@ -418,7 +419,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv)
data[0] = INTEL_GUC_ACTION_ENTER_S_STATE;
/* any value greater than GUC_POWER_D0 */
data[1] = GUC_POWER_D1;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -441,7 +442,7 @@ int intel_guc_reset_engine(struct intel_guc *guc,
data[3] = 0;
data[4] = 0;
data[5] = guc->execbuf_client->stage_id;
-   data[6] = guc_ggtt_offset(guc->shared_data);
+   data[6] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
@@ -463,7 +464,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv)
 
data[0] = INTEL_GUC_ACTION_EXIT_S_STATE;
data[1] = GUC_POWER_D0;
-   data[2] = guc_ggtt_offset(guc->shared_data);
+   data[2] = intel_guc_ggtt_offset(guc, guc->shared_data);
 
return intel_guc_send(guc, data, ARRAY_SIZE(data));
 }
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 52856a9..0c8b10a 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -100,13 +100,23 @@ static inline void intel_guc_notify(struct intel_guc *guc)
guc->notify(guc);
 }
 
-/*
+/* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */
+#define GUC_GGTT_TOP   0xFEE0
+
+/**
+ * intel_guc_ggtt_offset() - Get and validate the GGTT offset of @vma
+ * @guc: intel_guc structure.
+ * @vma: i915 graphics virtual memory area.
+ *
  * GuC does not allow any gfx GGTT address that falls into range [0, 
WOPCM_TOP),
  * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address 
is
  * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects
  * used by GuC is pinned with PIN_OFFSET_BIAS along 

[Intel-gfx] [PATCH v12 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Jackie Li]

GuC WOPCM registers are write-once registers. Current driver code accesses
these registers without checking the accessibility to these registers which
will lead to unpredictable driver behaviors if these registers were touch
by other components (such as faulty BIOS code).

This patch moves the GuC WOPCM registers updating code into intel_wopcm.c
and adds check before and after the update to GuC WOPCM registers so that
we can make sure the driver is in a known state after writing to these
write-once registers.

v6:
 - Made sure module reloading won't bug the kernel while doing
   locking status checking

v7:
 - Fixed patch format issues

v8:
 - Fixed coding style issue on register lock bit macro definition (Sagar)

v9:
 - Avoided to use redundant !! to cast uint to bool (Chris)
 - Return error code instead of GEM_BUG_ON for locked with invalid register
   values case (Sagar)
 - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
 - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
   WOPCM offset register based on the presence of HuC firmware (Michal)
 - Use bit fields instead of macros for GuC WOPCM flags (Michal)

v10:
 - Refined variable names, removed redundant comments (Joonas)
 - Introduced lockable_reg to handle the write once register write and
   propagate the write error to caller (Joonas)
 - Used lockable_reg abstraction to avoid locking bit check on generic
   i915_reg_t (Michal)
 - Added log message for error paths (Michal)
 - Removed hw_updated flag and only relies on real hardware status

v11:
 - Replaced lockable_reg with simplified function (Michal)
 - Used new macros for locking bits of WOPCM size/offset registers instead
   of using BIT(0) directly (Michal)
 - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC
   WOPCM register setup instead of calling from intel_uc_init_hw() (Michal)

v12:
 - Updated function kernel-doc to align with code changes (Michal)
 - Updated code to use wopcm pointer directly (Michal)

BSpec: 10875, 10833

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Michal Wajdeczko  (v11)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem.c  |  6 
 drivers/gpu/drm/i915/intel_guc_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_uc.c  |  5 ---
 drivers/gpu/drm/i915/intel_wopcm.c   | 64 
 drivers/gpu/drm/i915/intel_wopcm.h   |  1 +
 5 files changed, 74 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d31ad0b..662d670 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5122,6 +5122,12 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
goto out;
}
 
+   ret = intel_wopcm_init_hw(_priv->wopcm);
+   if (ret) {
+   DRM_ERROR("Enabling WOPCM failed (%d)\n", ret);
+   goto out;
+   }
+
/* We can't enable contexts until all firmware is loaded */
ret = intel_uc_init_hw(dev_priv);
if (ret) {
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h 
b/drivers/gpu/drm/i915/intel_guc_reg.h
index 01963d0..d860847 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,15 +66,18 @@
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   GUC_WOPCM_OFFSET_VALID (1<<0)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_SHIFT   14
+#define   GUC_WOPCM_OFFSET_MASK  (0x3 << 
GUC_WOPCM_OFFSET_SHIFT)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
 #define HUC_STATUS2 _MMIO(0xD3B0)
 #define   HUC_FW_VERIFIED   (1<<7)
 
 #define GUC_WOPCM_SIZE _MMIO(0xc050)
+#define   GUC_WOPCM_SIZE_LOCKED  (1<<0)
 #define   GUC_WOPCM_SIZE_SHIFT 12
 #define   GUC_WOPCM_SIZE_MASK(0xf << GUC_WOPCM_SIZE_SHIFT)
 
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 964e49f..58186f2 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -341,11 +341,6 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
 
-   /* init WOPCM */
-   I915_WRITE(GUC_WOPCM_SIZE, dev_priv->wopcm.guc.size);
-   I915_WRITE(DMA_GUC_WOPCM_OFFSET,
-  dev_priv->wopcm.guc.base | HUC_LOADING_AGENT_GUC);
-
/* WaEnableuKernelHeaderValidFix:skl */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
if (IS_GEN9(dev_priv))
diff --git 

[Intel-gfx] [PATCH v12 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

[Jackie Li]

Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than the
value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures. On the other hand, with
current static GuC WOPCM offset and size values (512KB for both offset and
size), the GuC WOPCM size verification will fail on Gen9 even if it can be
fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we can
have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds support
to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To
meet all above requirements, let's provide dynamic partitioning of the
WOPCM that will be based on platform specific HuC/GuC firmware sizes.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
 - Moved GuC DMA WOPCM register updating code into intel_wopcm.c
 - Took care of the locking status before writing to GuC DMA
   Write-Once registers. (Joonas)

v6:
 - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

v8:
 - Updated comments and fixed naming issues (Sagar/Joonas)
 - Updated commit message to include more description about the hardware
   restriction on GuC WOPCM size (Sagar)

v9:
 - Minor changes variable names and code comments (Sagar)
 - Added detailed GuC WOPCM layout drawing (Sagar/Michal)
 - Refined macro definitions to be reader friendly (Michal)
 - Removed redundent check to valid flag (Michal)
 - Unified first parameter for exported GuC WOPCM functions (Michal)
 - Refined the name and parameter list of hardware restriction checking
   functions (Michal)

v10:
 - Used shorter function name for internal functions (Joonas)
 - Moved init-ealry function into c file (Joonas)
 - Consolidated and removed redundant size checks (Joonas/Michal)
 - Removed unnecessary unlikely() from code which is only called once
   during boot (Joonas)
 - More fixes to kernel-doc format and content (Michal)
 - Avoided the use of PAGE_MASK for 4K pages (Michal)
 - Added error log messages to error paths (Michal)

v11:
 - Replaced intel_guc_wopcm with more generic intel_wopcm and attached
   intel_wopcm to drm_i915_private instead intel_guc (Michal)
 - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top
   offset from GuC WOPCM base) (Michal)
 - Moved WOPCM marco definitions into .c source file (Michal)
 - Exported WOPCM layout diagram as kernel-doc (Michal)

v12:
 - Updated naming, function kernel-doc to align with new changes (Michal)

Bspec: 12690

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Reviewed-by: Michal Wajdeczko  (v11)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/Makefile   |   3 +-
 drivers/gpu/drm/i915/i915_drv.c |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   8 ++
 drivers/gpu/drm/i915/i915_gem.c |   4 +
 drivers/gpu/drm/i915/i915_gem_context.c |   5 +-
 drivers/gpu/drm/i915/intel_guc.c|  66 ---
 drivers/gpu/drm/i915/intel_guc.h|  16 ++-
 drivers/gpu/drm/i915/intel_guc_reg.h|   8 +-
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c |   6 +-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  13 +--
 drivers/gpu/drm/i915/intel_uc_fw.h  |  16 +++
 drivers/gpu/drm/i915/intel_wopcm.c  | 195 
 drivers/gpu/drm/i915/intel_wopcm.h  |  34 ++
 14 files changed, 337 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_wopcm.h

diff --git 

[Intel-gfx] [PATCH v12 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

[Jackie Li]

On CNL A0 and Gen9, there's a hardware restriction that requires the
available GuC WOPCM size to be larger than or equal to HuC firmware size.

This patch adds new verification code to ensure the available GuC WOPCM
size to be larger than or equal to HuC firmware size on both Gen9 and CNL
A0.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

v8:
 - Renamed variables and functions to avoid ambiguity (Joonas)
 - Updated commit message and comments to be more comprehensive (Sagar)

v9:
 - Moved code that is not related to restriction check into a separate
   patch and updated the commit message accordingly (Sagar/Michal)
 - Avoided to call uc_get_fw_size for better layer isolation (Michal)

v10:
 - Shorten function names and reorganized size_check code to have clear
   isolation (Joonas)
 - Removed unnecessary comments (Joonas)

v11:
 - Fixed logic error in size check (Michal)

v12:
 - Add space between "HuC FW" and "(%uKiB)" in error message (Michal)

BSpec: 10875

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Michal Wajdeczko  (v11)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 237ca03..a94e8f0 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -105,8 +105,26 @@ static inline int gen9_check_dword_gap(u32 guc_wopcm_base, 
u32 guc_wopcm_size)
return 0;
 }
 
+static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size)
+{
+   /*
+* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
+* size to be larger than or equal to HuC firmware size. Otherwise,
+* firmware uploading would fail.
+*/
+   if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
+   DRM_ERROR("HuC FW (%uKiB) won't fit in GuC WOPCM (%uKiB).\n",
+ huc_fw_size / 1024,
+ (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);
+   return -E2BIG;
+   }
+
+   return 0;
+}
+
 static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size)
+  u32 guc_wopcm_base, u32 guc_wopcm_size,
+  u32 huc_fw_size)
 {
int err = 0;
 
@@ -115,7 +133,10 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,
if (err)
return err;
 
-   return 0;
+   if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+
+   return err;
 }
 
 /**
@@ -186,7 +207,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return -E2BIG;
}
 
-   err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size);
+   err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+  huc_fw_size);
if (err) {
DRM_ERROR("Failed to meet HW restriction.\n");
return err;
-- 
2.7.4

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

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

[Chris Wilson]

Quoting Patchwork (2018-03-01 17:28:31)
> == Series Details ==
> 
> Series: drm/i915: Replace open-coded wait-for loop (rev2)
> URL   : https://patchwork.freedesktop.org/series/36904/
> State : success
> 
> == Summary ==
> 
>  Possible new issues:
> 
> Test kms_vblank:
> Subgroup pipe-a-ts-continuation-modeset:
> skip   -> PASS   (shard-snb)
> Subgroup pipe-b-ts-continuation-modeset:
> skip   -> PASS   (shard-snb)

And finally applied. All that waiting for the new __wait_for macro.
-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 [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and 
loading functions/file structure symmetric
URL   : https://patchwork.freedesktop.org/series/39220/
State : failure

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
dmesg-fail -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
pass   -> INCOMPLETE (shard-hsw)

 Known issues:

Test drv_hangman:
Subgroup error-state-capture-blt:
pass   -> DMESG-WARN (shard-snb) fdo#104058
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +4
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-atomic:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup dpms-vs-vblank-race:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup wf_vblank-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
fail   -> PASS   (shard-apl) fdo#103167 +2
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test perf:
Subgroup enable-disable:
pass   -> FAIL   (shard-apl) fdo#103715

fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
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
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:3461 pass:1820 dwarn:1   dfail:0   fail:8   skip:1632 
time:12150s
shard-hswtotal:3367 pass:1717 dwarn:1   dfail:0   fail:4   skip:1642 
time:10748s
shard-snbtotal:3461 pass:1356 dwarn:4   dfail:0   fail:2   skip:2099 
time:6671s
Blacklisted hosts:
shard-kbltotal:3461 pass:1939 dwarn:6   dfail:0   fail:7   skip:1509 
time:9564s

== Logs ==

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

Re: [Intel-gfx] [PATCH 05/17] drm/i915/icl: compute the MG PLL registers

[Manasi Navare]

On Thu, Feb 22, 2018 at 12:55:07AM -0300, Paulo Zanoni wrote:
> This implements the "MG PLL Programming" sequence from our spec. The
> biggest problem was that the spec assumes real numbers, so we had to
> adjust some numbers and alculations due to the fact that the Kernel
> prefers to deal with integers.
> 
> I recommend grabbing some coffee, a pen and paper before reviewing
> this patch.
> 
> v2:
>  - Correctly identify DP encoders after upstream change.
>  - Small checkpatch issues.
>  - Rebase.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 217 
> +-
>  1 file changed, 216 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c 
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 5d7bacc80688..9a2965e0b883 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2514,11 +2514,226 @@ static enum intel_dpll_id icl_port_to_mg_pll_id(enum 
> port port)
>   return port - PORT_C + DPLL_ID_ICL_MGPLL1;
>  }
>  
> +static bool icl_mg_pll_find_divisors(int clock_khz, bool is_dp, bool use_ssc,
> +  uint32_t *target_dco_khz,
> +  struct intel_dpll_hw_state *state)
> +{
> + uint32_t dco_min_freq, dco_max_freq;
> + int div1_vals[] = {7, 5, 3, 2};
> + unsigned int i;
> + int div2;
> +
> + dco_min_freq = is_dp ? 810 : use_ssc ? 800 : 7992000;
> + dco_max_freq = is_dp ? 810 : 1000;
> +
> + for (i = 0; i < ARRAY_SIZE(div1_vals); i++) {
> + int div1 = div1_vals[i];
> +
> + for (div2 = 10; div2 > 0; div2--) {
> + int dco = div1 * div2 * clock_khz * 5;
> + int a_divratio, tlinedrv, inputsel, hsdiv;
> +
> + if (dco < dco_min_freq || dco > dco_max_freq)
> + continue;
> +
> + if (div2 >= 2) {
> + a_divratio = is_dp ? 10 : 5;
> + tlinedrv = 2;
> + } else {
> + a_divratio = 5;
> + tlinedrv = 0;
> + }
> + inputsel = is_dp ? 0 : 1;
> +
> + switch (div1) {
> + default:
> + MISSING_CASE(div1);
> + case 2:
> + hsdiv = 0;
> + break;
> + case 3:
> + hsdiv = 1;
> + break;
> + case 5:
> + hsdiv = 2;
> + break;
> + case 7:
> + hsdiv = 3;
> + break;
> + }
> +
> + *target_dco_khz = dco;
> +
> + state->mg_refclkin_ctl = MG_REFCLKIN_CTL_OD_2_MUX(1);
> +
> + state->mg_clktop2_coreclkctl1 =
> + MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(a_divratio);
> +
> + state->mg_clktop2_hsclkctl =
> + MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(tlinedrv) |
> + MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(inputsel) |
> + MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(hsdiv) |
> + MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(div2);
> +
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> +/*
> + * The specification for this function uses real numbers, so the math had to 
> be
> + * adapted to integer-only calculation, that's why it looks so different.
> + */
>  static bool icl_calc_mg_pll_state(struct intel_crtc_state *crtc_state,
> struct intel_encoder *encoder, int clock,
> struct intel_dpll_hw_state *pll_state)
>  {
> - /* TODO */
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + int refclk_khz = dev_priv->cdclk.hw.ref;
> + uint32_t dco_khz, m1div, m2div_int, m2div_rem, m2div_frac;
> + uint32_t iref_ndiv, iref_trim, iref_pulse_w;
> + uint32_t prop_coeff, int_coeff;
> + uint32_t tdc_targetcnt, feedfwgain;
> + uint64_t ssc_stepsize, ssc_steplen, ssc_steplog;
> + uint64_t tmp;
> + bool use_ssc = false;
> + bool is_dp = !intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI);
> +
> + if (!icl_mg_pll_find_divisors(clock, is_dp, use_ssc, _khz,
> +   pll_state)) {
> + DRM_DEBUG_KMS("Failed to find divisors for clock %d\n", clock);
> + return false;
> + }
> +
> + m1div = 2;
> + m2div_int = dco_khz / (refclk_khz * m1div);
> + if (m2div_int > 255) {
> + m1div = 4;
> + 

Re: [Intel-gfx] i915 vs checkpatch

[Chris Wilson]

Quoting Arkadiusz Hiler (2018-03-01 09:47:06)
> Hey all,
> 
> Since not so long ago our CI is running and reporting sparse and
> checkpatch. Sparse is doing just fine but I had to disable checkpatch
> for the time being - too much "false" positives causing people to
> complain. It's simply confusing to see one thing in the code, and
> fitting your change in only to get a report that it's wrong.

Another aspect is that we use the kernel coding style for igt as well.
checkpatch.pl should be able to pick up style issues on igt patches.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)
URL   : https://patchwork.freedesktop.org/series/39129/
State : success

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
dmesg-fail -> PASS   (shard-apl)

 Known issues:

Test drv_suspend:
Subgroup debugfs-reader:
pass   -> INCOMPLETE (shard-hsw) k.org#196691
Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
fail   -> PASS   (shard-apl) fdo#103167 +1
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

k.org#196691 https://bugzilla.kernel.org/show_bug.cgi?id=196691
fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-apltotal:3459 pass:1819 dwarn:1   dfail:0   fail:7   skip:1631 
time:11761s
shard-hswtotal:3441 pass:1755 dwarn:1   dfail:0   fail:1   skip:1682 
time:11665s
shard-snbtotal:3461 pass:1360 dwarn:1   dfail:0   fail:1   skip:2099 
time:6615s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8199/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: don't leak the pin_map on error (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: don't leak the pin_map on error (rev2)
URL   : https://patchwork.freedesktop.org/series/39207/
State : warning

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-gtt:
dmesg-fail -> PASS   (shard-apl)
Test kms_vblank:
Subgroup pipe-a-query-forked:
pass   -> SKIP   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-top-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103375
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-render:
fail   -> PASS   (shard-apl) fdo#103167 +1
Test perf:
Subgroup oa-exponents:
pass   -> INCOMPLETE (shard-apl) fdo#102254

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apltotal:3354 pass:1765 dwarn:1   dfail:0   fail:7   skip:1578 
time:11437s
shard-hswtotal:3456 pass:1762 dwarn:1   dfail:0   fail:3   skip:1688 
time:11089s
shard-snbtotal:3461 pass:1358 dwarn:1   dfail:0   fail:1   skip:2101 
time:6611s
Blacklisted hosts:
shard-kbltotal:3407 pass:1915 dwarn:3   dfail:0   fail:7   skip:1481 
time:9275s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8198/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/psr: Update PSR2 resolution check for Cannonlake

[Rodrigo Vivi]

On Thu, Mar 01, 2018 at 10:47:05PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to
> > be safe.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Elio Martinez Monroy 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 05770790a4e9..2a2c696c4109 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -451,8 +451,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> >  {
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > -   const struct drm_display_mode *adjusted_mode =
> > -   _state->base.adjusted_mode;
> > +   int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
> > +   int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
> >  
> > /*
> >  * FIXME psr2_support is messed up. It's both computed
> > @@ -462,9 +462,10 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> > if (!dev_priv->psr.psr2_support)
> > return false;
> >  
> > -   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> > -   if (adjusted_mode->crtc_hdisplay > 3640 ||
> > -   adjusted_mode->crtc_vdisplay > 2304) {
> > +   if (crtc_h > 4096 || crtc_v > 2304) {
> > +   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > +   return false;
> > +   } else if (IS_GEN9(dev_priv) && (crtc_h > 3640 || crtc_v > 2304)) {
> 
> I would suggest introducing max_w/h or something similar so that you
> don't have to duplicate the actual code.

I was going to suggest same thing. So it gets more clear that it is
per platform based and avoid duplication of code

> 
> When debugging things from logs one might want to know both the requested
> size and the max. So printing those out might be a good idea.
> 
> > DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > return false;
> > }
> > -- 
> > 2.14.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake (rev2)
URL   : https://patchwork.freedesktop.org/series/39238/
State : success

== Summary ==

Series 39238v2 drm/i915/psr: Update PSR2 resolution check for Cannonlake
https://patchwork.freedesktop.org/api/1.0/series/39238/revisions/2/mbox/

 Known issues:

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:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:419s
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:478s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:389s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:407s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:291s
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:384s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:449s
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:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
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:432s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
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:404s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
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:389s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:504s

7fe823aaeff7c50eeaf9b238a179b41771e08f9e drm-tip: 2018y-03m-01d-15h-58m-23s UTC 
integration manifest
5a3ccdd925b6 drm/i915/psr: Update PSR2 resolution check for Cannonlake

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8205/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/psr: Update PSR2 resolution check for Cannonlake

[Pandiyan, Dhinakaran]

On Thu, 2018-03-01 at 23:47 +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 01:27:09PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> > to be safe.
> > 
> > v2: Use local variables for resolution limits and print them (Ville)
> > 
> > Cc: Ville Syrjälä 
> > Cc: Rodrigo Vivi 
> > Cc: Elio Martinez Monroy 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 14 --
> >  1 file changed, 8 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 05770790a4e9..66d04a8dd99e 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -451,8 +451,9 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> >  {
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > -   const struct drm_display_mode *adjusted_mode =
> > -   _state->base.adjusted_mode;
> > +   int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
> > +   int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
> 
> I'd probably call these hdisp/vdisp or something like that. "crtc_h" makes
> me think it's a height of a plane in crtc (pipe source) coordinates.

and h/vdisplay are specifically related to the mode?

> 
> > +   int max_h, max_v;
I guess this is okay then?

> >  
> > /*
> >  * FIXME psr2_support is messed up. It's both computed
> > @@ -462,10 +463,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> > if (!dev_priv->psr.psr2_support)
> > return false;
> >  
> > -   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> > -   if (adjusted_mode->crtc_hdisplay > 3640 ||
> > -   adjusted_mode->crtc_vdisplay > 2304) {
> > -   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > +   max_h = INTEL_GEN(dev_priv) >= 10 ? 4096 : 3640;
> > +   max_v = 2304;
> 
> GLK should use the higher limit too no?

Yeah, I just checked and it makes sense to update GLK too.

> 
> Looking at the *future* stuff for this it looks like we'll be getting
> different limits again soon. So I'd prep for that day by making this 
> a full blown if ladder from the start.
> 
> > +   if (crtc_h > max_h || crtc_v > max_v) {
> > +   DRM_DEBUG_KMS("PSR2 not enabled, resolution %dx%d > max 
> > supported %dx%d\n",
> > + crtc_h, crtc_v, max_h, max_v);
> > return false;
> > }
> >  
> > -- 
> > 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/uc: Start preparing GuC/HuC for reset

[Daniele Ceraolo Spurio]

On 26/02/18 23:50, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-02-27 06:54:46)



On 2/27/2018 2:22 AM, Chris Wilson wrote:

Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11)

As you said we do always reset GuC no matter the value of the modparam,
but that does not reset the doorbell HW. If we're coming out of S3 and
the state as been preserved this will cause the doorbell HW to be left
in an unclean state, which could cause spurious doorbell interrupts to
be sent to GuC, not sure how the firmware handles those. The code as
moved since last time I looked at this in detail and I think we're now
most likely going to overwrite those unclean doorbells, but there are
unlikely corner cases (preempt context failing to be created) where we
might not do so.

I'm still going "wait, we can put the device into D3 and the GuC is
still powered?" Something feels wrong if the GuC retains state after the
HW is powered down.

GuC will be powered down, with RC6. Just that firmware in WOPCM can get
wiped off if
memory is reset/powered down during resume. In case of mem sleep
generally WOPCM stays intact and if we exit
RC6 on resume from sleep, firmware will be restored into GuC without
driver intervention.
But since we do full GPU reset as part of sanitize we have to load it
from driver again.


On resume, we don't know if we are coming from module load, resume from
S3, resume S3+RST, resume from S4, or resume from kexec. (S3+RST, kexec
are truly without our knowledge, the others we could feed the
information through but RST makes that moot.) Ergo, you cannot know if
the right fw image is loaded and aiui you should treat the state as
undefined and always reload. Does that make sense? Is there a way you
can query what fw is loaded and so skip instead?
-Chris



Not sure if there is already a way to query the FW version, but we could 
ask for a new H2G to be added if there isn't. However, even if the 
firmware version matches, if we can't confirm it is exactly the one we 
loaded (and not a reload of the same version) there is no guarantee that 
its internal state is what we expect. Also, we would have to stop doing 
full gpu resets around suspend/resume which I doubt it is something we want.


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/psr: Update PSR2 resolution check for Cannonlake

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 01:27:09PM -0800, Dhinakaran Pandiyan wrote:
> In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
> to be safe.
> 
> v2: Use local variables for resolution limits and print them (Ville)
> 
> Cc: Ville Syrjälä 
> Cc: Rodrigo Vivi 
> Cc: Elio Martinez Monroy 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 05770790a4e9..66d04a8dd99e 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -451,8 +451,9 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - const struct drm_display_mode *adjusted_mode =
> - _state->base.adjusted_mode;
> + int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
> + int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;

I'd probably call these hdisp/vdisp or something like that. "crtc_h" makes
me think it's a height of a plane in crtc (pipe source) coordinates.

> + int max_h, max_v;
>  
>   /*
>* FIXME psr2_support is messed up. It's both computed
> @@ -462,10 +463,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   if (!dev_priv->psr.psr2_support)
>   return false;
>  
> - /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> - if (adjusted_mode->crtc_hdisplay > 3640 ||
> - adjusted_mode->crtc_vdisplay > 2304) {
> - DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> + max_h = INTEL_GEN(dev_priv) >= 10 ? 4096 : 3640;
> + max_v = 2304;

GLK should use the higher limit too no?

Looking at the *future* stuff for this it looks like we'll be getting
different limits again soon. So I'd prep for that day by making this 
a full blown if ladder from the start.

> + if (crtc_h > max_h || crtc_v > max_v) {
> + DRM_DEBUG_KMS("PSR2 not enabled, resolution %dx%d > max 
> supported %dx%d\n",
> +   crtc_h, crtc_v, max_h, max_v);
>   return false;
>   }
>  
> -- 
> 2.14.1

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

[Intel-gfx] [PATCH v2] drm/i915/psr: Update PSR2 resolution check for Cannonlake

[Dhinakaran Pandiyan]

In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms
to be safe.

v2: Use local variables for resolution limits and print them (Ville)

Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
Cc: Elio Martinez Monroy 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 05770790a4e9..66d04a8dd99e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -451,8 +451,9 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   const struct drm_display_mode *adjusted_mode =
-   _state->base.adjusted_mode;
+   int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
+   int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
+   int max_h, max_v;
 
/*
 * FIXME psr2_support is messed up. It's both computed
@@ -462,10 +463,11 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
if (!dev_priv->psr.psr2_support)
return false;
 
-   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
-   if (adjusted_mode->crtc_hdisplay > 3640 ||
-   adjusted_mode->crtc_vdisplay > 2304) {
-   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
+   max_h = INTEL_GEN(dev_priv) >= 10 ? 4096 : 3640;
+   max_v = 2304;
+   if (crtc_h > max_h || crtc_v > max_v) {
+   DRM_DEBUG_KMS("PSR2 not enabled, resolution %dx%d > max 
supported %dx%d\n",
+ crtc_h, crtc_v, max_h, max_v);
return false;
}
 
-- 
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: failure for drm/i915/psr: Update PSR2 resolution check for Cannonlake

[Patchwork]

== Series Details ==

Series: drm/i915/psr: Update PSR2 resolution check for Cannonlake
URL   : https://patchwork.freedesktop.org/series/39238/
State : failure

== Summary ==

Series 39238v1 drm/i915/psr: Update PSR2 resolution check for Cannonlake
https://patchwork.freedesktop.org/api/1.0/series/39238/revisions/1/mbox/

 Possible new issues:

Test gem_ctx_switch:
Subgroup basic-default:
pass   -> INCOMPLETE (fi-cnl-y3)

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:425s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:380s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:491s
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: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:473s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:461s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-cnl-y3total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0  
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:409s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:511s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
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:446s
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:457s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
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:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:591s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:519s
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:481s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:411s
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:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:500s

7fe823aaeff7c50eeaf9b238a179b41771e08f9e drm-tip: 2018y-03m-01d-15h-58m-23s UTC 
integration manifest
e3f41cf6527e drm/i915/psr: Update PSR2 resolution check for Cannonlake

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8204/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/psr: Update PSR2 resolution check for Cannonlake

[Pandiyan, Dhinakaran]

On Thu, 2018-03-01 at 22:47 +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote:
> > In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to
> > be safe.
> > 
> > Cc: Rodrigo Vivi 
> > Cc: Elio Martinez Monroy 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 05770790a4e9..2a2c696c4109 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -451,8 +451,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> >  {
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > -   const struct drm_display_mode *adjusted_mode =
> > -   _state->base.adjusted_mode;
> > +   int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
> > +   int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
> >  
> > /*
> >  * FIXME psr2_support is messed up. It's both computed
> > @@ -462,9 +462,10 @@ static bool intel_psr2_config_valid(struct intel_dp 
> > *intel_dp,
> > if (!dev_priv->psr.psr2_support)
> > return false;
> >  
> > -   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> > -   if (adjusted_mode->crtc_hdisplay > 3640 ||
> > -   adjusted_mode->crtc_vdisplay > 2304) {
> > +   if (crtc_h > 4096 || crtc_v > 2304) {
> > +   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > +   return false;
> > +   } else if (IS_GEN9(dev_priv) && (crtc_h > 3640 || crtc_v > 2304)) {
> 
> I would suggest introducing max_w/h or something similar so that you
> don't have to duplicate the actual code.
> 
> When debugging things from logs one might want to know both the requested
> size and the max. So printing those out might be a good idea.

Agreed on both points.


> 
> > DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > return false;
> > }
> > -- 
> > 2.14.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/psr: Update PSR2 resolution check for Cannonlake

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 12:38:58PM -0800, Dhinakaran Pandiyan wrote:
> In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to
> be safe.
> 
> Cc: Rodrigo Vivi 
> Cc: Elio Martinez Monroy 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 05770790a4e9..2a2c696c4109 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -451,8 +451,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> - const struct drm_display_mode *adjusted_mode =
> - _state->base.adjusted_mode;
> + int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
> + int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
>  
>   /*
>* FIXME psr2_support is messed up. It's both computed
> @@ -462,9 +462,10 @@ static bool intel_psr2_config_valid(struct intel_dp 
> *intel_dp,
>   if (!dev_priv->psr.psr2_support)
>   return false;
>  
> - /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> - if (adjusted_mode->crtc_hdisplay > 3640 ||
> - adjusted_mode->crtc_vdisplay > 2304) {
> + if (crtc_h > 4096 || crtc_v > 2304) {
> + DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> + return false;
> + } else if (IS_GEN9(dev_priv) && (crtc_h > 3640 || crtc_v > 2304)) {

I would suggest introducing max_w/h or something similar so that you
don't have to duplicate the actual code.

When debugging things from logs one might want to know both the requested
size and the max. So printing those out might be a good idea.

>   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
>   return false;
>   }
> -- 
> 2.14.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH] drm/i915/psr: Update PSR2 resolution check for Cannonlake

[Dhinakaran Pandiyan]

In fact, apply the Cannonlake resolution check for all > Gen-9 platforms to
be safe.

Cc: Rodrigo Vivi 
Cc: Elio Martinez Monroy 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 05770790a4e9..2a2c696c4109 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -451,8 +451,8 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
-   const struct drm_display_mode *adjusted_mode =
-   _state->base.adjusted_mode;
+   int crtc_h = crtc_state->base.adjusted_mode.crtc_hdisplay;
+   int crtc_v = crtc_state->base.adjusted_mode.crtc_vdisplay;
 
/*
 * FIXME psr2_support is messed up. It's both computed
@@ -462,9 +462,10 @@ static bool intel_psr2_config_valid(struct intel_dp 
*intel_dp,
if (!dev_priv->psr.psr2_support)
return false;
 
-   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
-   if (adjusted_mode->crtc_hdisplay > 3640 ||
-   adjusted_mode->crtc_vdisplay > 2304) {
+   if (crtc_h > 4096 || crtc_v > 2304) {
+   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
+   return false;
+   } else if (IS_GEN9(dev_priv) && (crtc_h > 3640 || crtc_v > 2304)) {
DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
return false;
}
-- 
2.14.1

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/perf: fix perf stream opening lock (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: fix perf stream opening lock (rev2)
URL   : https://patchwork.freedesktop.org/series/39112/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#105055
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-pwrite:
skip   -> PASS   (shard-snb) fdo#101623 +1
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#105055 https://bugs.freedesktop.org/show_bug.cgi?id=105055
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3461 pass:1818 dwarn:1   dfail:0   fail:8   skip:1633 
time:12226s
shard-hswtotal:3419 pass:1743 dwarn:1   dfail:0   fail:2   skip:1671 
time:11350s
shard-snbtotal:3461 pass:1360 dwarn:1   dfail:0   fail:1   skip:2099 
time:s
Blacklisted hosts:
shard-kbltotal:3461 pass:1943 dwarn:1   dfail:0   fail:7   skip:1510 
time:9517s

== Logs ==

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

[Intel-gfx] *cringe* at adding a parameter to workaround issues.

[Marc Herbert]

Hi Jani,

> *cringe* at adding a parameter to workaround issues.

I understand that *each* parameter has the potential to *multiply* the total
number of configurations and that the resulting combinatorial explosion is
absolutely not scalable and sustainable from a validation perspective. No
one should expect to get support here when options like this one are set to
a non-default value.

When something breaks on the other hand, transparent _test_ knobs like this
one have proved invaluable countless times to help troubleshoot and isolate
issues. It's at least 10 times more productive to ask a non-expert in some
opposite timezone "please test again after rebooting with this parameter"
compared to "test again after applying this patch, recompiling, etc." -
assuming the latter has any chance of success at all.  I'm speaking from
actual experience as we are routinely experiencing both type of situations.

I hope the "unsafe" part of "i915_param_named_unsafe" provides a permanent
solution to both problems by making a clear distinction between the only one
single true supported configuration on one hand versus test datapoints
on the other hand.  Same for "tainted", sysfs or else.

Marc

___
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: Register definitions for DP Phy compiance

[Patchwork]

== Series Details ==

Series: drm/i915: Register definitions for DP Phy compiance
URL   : https://patchwork.freedesktop.org/series/39233/
State : success

== Summary ==

Series 39233v1 drm/i915: Register definitions for DP Phy compiance
https://patchwork.freedesktop.org/api/1.0/series/39233/revisions/1/mbox/

 Known issues:

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

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:430s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
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:279s
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: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:459s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:292s
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:388s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:495s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
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:518s
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:478s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:412s
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:514s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:499s
fi-cnl-y3 failed to collect. IGT log at Patchwork_8203/fi-cnl-y3/run0.log

7fe823aaeff7c50eeaf9b238a179b41771e08f9e drm-tip: 2018y-03m-01d-15h-58m-23s UTC 
integration manifest
daca9f902211 drm/i915: Register definitions for DP Phy compiance

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: Register definitions for DP Phy compiance

[clinton . a . taylor]

From: Clint Taylor 

DisplayPort Phy compliance test patterns register definitions.

Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/i915_reg.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 95a2e51..91152c9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8702,6 +8702,24 @@ enum skl_power_gate {
 #define  DDI_BUF_BALANCE_LEG_ENABLE(1 << 31)
 #define DDI_BUF_TRANS_HI(port, i)  _MMIO(_PORT(port, _DDI_BUF_TRANS_A, 
_DDI_BUF_TRANS_B) + (i) * 8 + 4)
 
+/* DDI DP Compliance Control */
+#define DDI_DP_COMP_CTL_A  0x640F0
+#define DDI_DP_COMP_CTL_B  0x641F0
+#define DDI_DP_COMP_CTL(port) _MMIO_PORT(port, DDI_DP_COMP_CTL_A, 
DDI_DP_COMP_CTL_B)
+#define  DDI_DP_COMP_CTL_ENABLE(1 << 31)
+#define  DDI_DP_COMP_CTL_D10_2 (0 << 28)
+#define  DDI_DP_COMP_CTL_SCRAMBLED_0   (1 << 28)
+#define  DDI_DP_COMP_CTL_PRBS7 (2 << 28)
+#define  DDI_DP_COMP_CTL_CUSTOM80  (3 << 28)
+#define  DDI_DP_COMP_CTL_HBR2  (4 << 28)
+#define  DDI_DP_COMP_CTL_SCRAMBLED_1   (5 << 28)
+#define  DDI_DP_COMP_CTL_HBR2_RESET(0xFC << 0)
+
+/* DDI DP Compliance Pattern */
+#define DDI_DP_COMP_PAT_A  0x640f4
+#define DDI_DP_COMP_PAT_B  0x641f4
+#define DDI_DP_COMP_PAT(port, i) _MMIO(_PORT(port, DDI_DP_COMP_PAT_A, 
DDI_DP_COMP_PAT_B) + (i) * 4) /* 3 dwords */
+
 /* Sideband Interface (SBI) is programmed indirectly, via
  * SBI_ADDR, which contains the register offset; and SBI_DATA,
  * which contains the payload */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 11:00:40AM -0800, Rodrigo Vivi wrote:
> On Thu, Mar 01, 2018 at 08:43:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote:
> > > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran 
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > > > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > > > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > > > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > > > > > > >>> _post_plane_update()
> > > > > > > > > > >>> takes care of flushing when a flip is scheduled, this 
> > > > > > > > > > >>> should be
> > > > > > > > > > >>> sufficient for PSR and FBC.
> > > > > > > > > > >> Makes sense.
> > > > > > > > > > >>  
> > > > > > > > > > > I also think this might speed up the flips a bit by 
> > > > > > > > > > > avoiding flushes. 
> > > > > > > > > > >
> > > > > > > > > > >>> Cc: Paulo Zanoni 
> > > > > > > > > > >>> Cc: Ville Syrjälä 
> > > > > > > > > > >>> Cc: Chris Wilson 
> > > > > > > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > > > > >>> 
> > > > > > > > > > >> Also
> > > > > > > > > > >> Cc: Maarten Lankhorst 
> > > > > > > > > > >> to validate the flow through atomic.
> > > > > > > > > > >> -Chris
> > > > > > > > > > >>
> > > > > > > > > > Page flips used to do intel_frontbuffer_flip_prepare here, 
> > > > > > > > > > followed by intel_frontbuffer_flip_complete. I think it 
> > > > > > > > > > would make sense to change the patch to do that?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I have no context why it was removed, I'll have to understand 
> > > > > > > > > that
> > > > > > > > > change and get back to you.
> > > > > > > > 
> > > > > > > > Since we supposedly have hw nuke for both fbc and psr there 
> > > > > > > > doesn't seem
> > > > > > > > to be much need to do anything for flips. I guess DRRS is the 
> > > > > > > > only
> > > > > > > > thing that kinda needs it (not really, just avoids flipping 
> > > > > > > > with the
> > > > > > > > slow timings). But I think DRRS should really be tied into the 
> > > > > > > > vblank
> > > > > > > > stuff somehow so that we switch to the fast timings whenever a 
> > > > > > > > vblank
> > > > > > > > interrupts are enabled.
> > > > > > > 
> > > > > > > Oh, I guess VLV/CHV PSR is what would need this. To do that 
> > > > > > > properly
> > > > > > > (ie. main link off) I think we'd basically need to do a full 
> > > > > > > modeset
> > > > > > > when exiting PSR, so it should probably handled somewhere higher 
> > > > > > > up
> > > > > > > during modeset, and for other uses the frontbuffer tracking
> > > > > > > should perhaps just schedule a work to do the full modeset.
> > > > > > > 
> > > > > > The mention of "full modeset" got me thinking. I believe you said 
> > > > > > full
> > > > > > modeset because the link needs to be trained on PSR exit if it was 
> > > > > > off.
> > > > > > But, link off isn't supported on VLV/CHV
> > > > > > 
> > > > > > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > > > /* On VLV and CHV only standby mode is supported. */
> > > > > > dev_priv->psr.link_standby = true;
> > > > > 
> > > > > I think that's just because we've been lazy and done it. I think even
> > > > > with the link off we'd need to reprogram all planes at least.
> > > > 
> > > > Not had coffee yet today, and it shows. Let me rewrite that entire 
> > > > thing:
> > > > 
> > > > I think that's just because we've been lazy and not done it (link off 
> > > > mode).
> > > 
> > > I agree with you here. This was probably exactly what was missing.
> > > But, how to do this without flickering (blinking?!) the screen?
> > > 
> > > > I think even without the link off we'd need to reprogram all planes at 
> > > > least.
> > > 
> > > on VLV/CHV or everywhere? and why do you think that?
> > 
> > VLV/CHV. I believe the hw implements PSR by simplty turning off the
> > planes (and pipes+dplls for link off), but it doesn't have any automagic
> > stuff for recovering the original state. It's all up to the driver.
> > 
> > IIRC Rodrigo even confirmed this at some point, or at least he had to
> > 

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Pandiyan, Dhinakaran]

On Thu, 2018-03-01 at 11:00 -0800, Rodrigo Vivi wrote:
> On Thu, Mar 01, 2018 at 08:43:05PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote:
> > > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > > > > > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran 
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > > > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > > > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > > > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > > > > > > >>> _post_plane_update()
> > > > > > > > > > >>> takes care of flushing when a flip is scheduled, this 
> > > > > > > > > > >>> should be
> > > > > > > > > > >>> sufficient for PSR and FBC.
> > > > > > > > > > >> Makes sense.
> > > > > > > > > > >>  
> > > > > > > > > > > I also think this might speed up the flips a bit by 
> > > > > > > > > > > avoiding flushes. 
> > > > > > > > > > >
> > > > > > > > > > >>> Cc: Paulo Zanoni 
> > > > > > > > > > >>> Cc: Ville Syrjälä 
> > > > > > > > > > >>> Cc: Chris Wilson 
> > > > > > > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > > > > >>> 
> > > > > > > > > > >> Also
> > > > > > > > > > >> Cc: Maarten Lankhorst 
> > > > > > > > > > >> to validate the flow through atomic.
> > > > > > > > > > >> -Chris
> > > > > > > > > > >>
> > > > > > > > > > Page flips used to do intel_frontbuffer_flip_prepare here, 
> > > > > > > > > > followed by intel_frontbuffer_flip_complete. I think it 
> > > > > > > > > > would make sense to change the patch to do that?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I have no context why it was removed, I'll have to understand 
> > > > > > > > > that
> > > > > > > > > change and get back to you.
> > > > > > > > 
> > > > > > > > Since we supposedly have hw nuke for both fbc and psr there 
> > > > > > > > doesn't seem
> > > > > > > > to be much need to do anything for flips. I guess DRRS is the 
> > > > > > > > only
> > > > > > > > thing that kinda needs it (not really, just avoids flipping 
> > > > > > > > with the
> > > > > > > > slow timings). But I think DRRS should really be tied into the 
> > > > > > > > vblank
> > > > > > > > stuff somehow so that we switch to the fast timings whenever a 
> > > > > > > > vblank
> > > > > > > > interrupts are enabled.
> > > > > > > 
> > > > > > > Oh, I guess VLV/CHV PSR is what would need this. To do that 
> > > > > > > properly
> > > > > > > (ie. main link off) I think we'd basically need to do a full 
> > > > > > > modeset
> > > > > > > when exiting PSR, so it should probably handled somewhere higher 
> > > > > > > up
> > > > > > > during modeset, and for other uses the frontbuffer tracking
> > > > > > > should perhaps just schedule a work to do the full modeset.
> > > > > > > 
> > > > > > The mention of "full modeset" got me thinking. I believe you said 
> > > > > > full
> > > > > > modeset because the link needs to be trained on PSR exit if it was 
> > > > > > off.
> > > > > > But, link off isn't supported on VLV/CHV
> > > > > > 
> > > > > > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > > > /* On VLV and CHV only standby mode is supported. */
> > > > > > dev_priv->psr.link_standby = true;
> > > > > 
> > > > > I think that's just because we've been lazy and done it. I think even
> > > > > with the link off we'd need to reprogram all planes at least.
> > > > 
> > > > Not had coffee yet today, and it shows. Let me rewrite that entire 
> > > > thing:
> > > > 
> > > > I think that's just because we've been lazy and not done it (link off 
> > > > mode).
> > > 
> > > I agree with you here. This was probably exactly what was missing.
> > > But, how to do this without flickering (blinking?!) the screen?
> > > 
> > > > I think even without the link off we'd need to reprogram all planes at 
> > > > least.
> > > 
> > > on VLV/CHV or everywhere? and why do you think that?
> > 
> > VLV/CHV. I believe the hw implements PSR by simplty turning off the
> > planes (and pipes+dplls for link off), but it doesn't have any automagic
> > stuff for recovering the original state. It's all up to the driver.
> > 
> > IIRC Rodrigo even confirmed this at some point, or at least he had to
> > trigger a 

Re: [Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

[Chris Wilson]

Quoting Michel Thierry (2018-03-01 18:07:03)
> So change timeout_ts and use time_after64 in gen11_gt_engine_intr.

We only need u32 for the duration.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[John Spotswood]

On Thu, 2018-03-01 at 17:35 +0530, Sagar Arun Kamble wrote:
> 
> On 3/1/2018 1:32 PM, Chris Wilson wrote:
> > 
> > Quoting Michel Thierry (2018-02-28 22:07:51)
> > > 
> > > On 28/02/18 12:26, Michel Thierry wrote:
> > > > 
> > > > On 28/02/18 10:42, Piotr Piórkowski wrote:
> > > > > 
> > > > > In the i915 driver, there is a function,
> > > > > intel_guc_init_params(),
> > > > > which initializes the GuC parameter block which is passed
> > > > > into
> > > > > the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
> > > > > GfxGtType and GfxCoreFamily unused by GuC.
> > > > > 
> > > > > This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
> > > > > GfxCoreFamily parameters and also unnecessary functions
> > > > > get_gt_type() and get_core_family().
> > > > > 
> > > > Hi,
> > > > 
> > > > Looking at the fw code, you're partially right, GfxGtType is
> > > > ignored...
> > > > but GfxCoreFamily isn't.
> > > > 
> > > Unless whoever wrote the fw was smart enough to forget to call
> > > the
> > > function that is reading GfxCoreFamily... I didn't count on that.
> > Is the intention to use GfxCoreFamily documented, i.e. are they
> > expecting it part of the interface and may re-instantiate the check
> > "because it was always supposed to exist" in some future version?
> Usage of GfxCoreFamily is only in SLPC and for platform specific 
> initialization and might be removed in future interfaces.
> If needed, we can add as part of SLPC patches.
Michel and I have traced through the FW code, and both parameters are
unused.  GfxCoreFamily does appear to be set in the FW, and it gets
passed into SLPC, but then it never gets used.  I have confirmed with
FW developers that these parameters have been removed for future gens.
> > 
> > -Chris
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Rodrigo Vivi]

On Thu, Mar 01, 2018 at 08:43:05PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote:
> > On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote:
> > > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > > > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran 
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > > > > > >>> _post_plane_update()
> > > > > > > > > >>> takes care of flushing when a flip is scheduled, this 
> > > > > > > > > >>> should be
> > > > > > > > > >>> sufficient for PSR and FBC.
> > > > > > > > > >> Makes sense.
> > > > > > > > > >>  
> > > > > > > > > > I also think this might speed up the flips a bit by 
> > > > > > > > > > avoiding flushes. 
> > > > > > > > > >
> > > > > > > > > >>> Cc: Paulo Zanoni 
> > > > > > > > > >>> Cc: Ville Syrjälä 
> > > > > > > > > >>> Cc: Chris Wilson 
> > > > > > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > > > >>> 
> > > > > > > > > >> Also
> > > > > > > > > >> Cc: Maarten Lankhorst 
> > > > > > > > > >> to validate the flow through atomic.
> > > > > > > > > >> -Chris
> > > > > > > > > >>
> > > > > > > > > Page flips used to do intel_frontbuffer_flip_prepare here, 
> > > > > > > > > followed by intel_frontbuffer_flip_complete. I think it would 
> > > > > > > > > make sense to change the patch to do that?
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I have no context why it was removed, I'll have to understand 
> > > > > > > > that
> > > > > > > > change and get back to you.
> > > > > > > 
> > > > > > > Since we supposedly have hw nuke for both fbc and psr there 
> > > > > > > doesn't seem
> > > > > > > to be much need to do anything for flips. I guess DRRS is the only
> > > > > > > thing that kinda needs it (not really, just avoids flipping with 
> > > > > > > the
> > > > > > > slow timings). But I think DRRS should really be tied into the 
> > > > > > > vblank
> > > > > > > stuff somehow so that we switch to the fast timings whenever a 
> > > > > > > vblank
> > > > > > > interrupts are enabled.
> > > > > > 
> > > > > > Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> > > > > > (ie. main link off) I think we'd basically need to do a full modeset
> > > > > > when exiting PSR, so it should probably handled somewhere higher up
> > > > > > during modeset, and for other uses the frontbuffer tracking
> > > > > > should perhaps just schedule a work to do the full modeset.
> > > > > > 
> > > > > The mention of "full modeset" got me thinking. I believe you said full
> > > > > modeset because the link needs to be trained on PSR exit if it was 
> > > > > off.
> > > > > But, link off isn't supported on VLV/CHV
> > > > > 
> > > > > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > >   /* On VLV and CHV only standby mode is supported. */
> > > > >   dev_priv->psr.link_standby = true;
> > > > 
> > > > I think that's just because we've been lazy and done it. I think even
> > > > with the link off we'd need to reprogram all planes at least.
> > > 
> > > Not had coffee yet today, and it shows. Let me rewrite that entire thing:
> > > 
> > > I think that's just because we've been lazy and not done it (link off 
> > > mode).
> > 
> > I agree with you here. This was probably exactly what was missing.
> > But, how to do this without flickering (blinking?!) the screen?
> > 
> > > I think even without the link off we'd need to reprogram all planes at 
> > > least.
> > 
> > on VLV/CHV or everywhere? and why do you think that?
> 
> VLV/CHV. I believe the hw implements PSR by simplty turning off the
> planes (and pipes+dplls for link off), but it doesn't have any automagic
> stuff for recovering the original state. It's all up to the driver.
> 
> IIRC Rodrigo even confirmed this at some point, or at least he had to
> trigger a plane update to get something visible on the screen.

My memory is terrible. But this makes so much sense and in sync
with some vague memory flashes here :)

And probably what blocked me for looking there besides the
other bugs on core platforms was my disbelieve that would
be possible without seeing any blink of a blank screen 

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Yaodong Li]

On 03/01/2018 05:37 AM, Michal Wajdeczko wrote:
On Thu, 01 Mar 2018 02:01:39 +0100, Jackie Li  
wrote:




+
+    err = write_and_verify(dev_priv, GUC_WOPCM_SIZE,
+   dev_priv->wopcm.guc.size,


you should use wopcm-> instead dev_priv->wopcm. (same below)


+   GUC_WOPCM_SIZE_MASK | GUC_WOPCM_SIZE_LOCKED,
+   GUC_WOPCM_SIZE_LOCKED);


bikeshed: we should set BASE first, then SIZE ;)

I'd like to keep the sequence it as how the existing code is doing this.
Plus It is only called once during init, and now it works perfectly.:-)



+    if (err)
+    goto err_out;
+
+    huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
+    mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
+    err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
+   dev_priv->wopcm.guc.base | huc_agent, mask,
+   GUC_WOPCM_OFFSET_VALID);


as the only supported HuC scenario for us is always with
HUC_LOADING_AGENT_GUC, maybe we should always set this bit,
but only add to mask for check conditionally? otherwise we
couldn't run first without and later with HuC... just asking


I assume what you are asking is how to deal with the use case that
we first run without HuC firmware, then we unload the driver module
and come back with a HuC FW?

In this case, we need to also recalculate the GuC region and we need
also the reg values accordingly. Unfortunately, we cannot do it now once
the regs were locked.


with function description and use wopcm pointer fixed,

Reviewed-by: Michal Wajdeczko 

Thanks again for the review.:-)
-Jackie

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 10:35:48AM -0800, Rodrigo Vivi wrote:
> On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > 
> > > > 
> > > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > > > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran 
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > > > > >>> _post_plane_update()
> > > > > > > > >>> takes care of flushing when a flip is scheduled, this 
> > > > > > > > >>> should be
> > > > > > > > >>> sufficient for PSR and FBC.
> > > > > > > > >> Makes sense.
> > > > > > > > >>  
> > > > > > > > > I also think this might speed up the flips a bit by avoiding 
> > > > > > > > > flushes. 
> > > > > > > > >
> > > > > > > > >>> Cc: Paulo Zanoni 
> > > > > > > > >>> Cc: Ville Syrjälä 
> > > > > > > > >>> Cc: Chris Wilson 
> > > > > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > > >>> 
> > > > > > > > >> Also
> > > > > > > > >> Cc: Maarten Lankhorst 
> > > > > > > > >> to validate the flow through atomic.
> > > > > > > > >> -Chris
> > > > > > > > >>
> > > > > > > > Page flips used to do intel_frontbuffer_flip_prepare here, 
> > > > > > > > followed by intel_frontbuffer_flip_complete. I think it would 
> > > > > > > > make sense to change the patch to do that?
> > > > > > > > 
> > > > > > > 
> > > > > > > I have no context why it was removed, I'll have to understand that
> > > > > > > change and get back to you.
> > > > > > 
> > > > > > Since we supposedly have hw nuke for both fbc and psr there doesn't 
> > > > > > seem
> > > > > > to be much need to do anything for flips. I guess DRRS is the only
> > > > > > thing that kinda needs it (not really, just avoids flipping with the
> > > > > > slow timings). But I think DRRS should really be tied into the 
> > > > > > vblank
> > > > > > stuff somehow so that we switch to the fast timings whenever a 
> > > > > > vblank
> > > > > > interrupts are enabled.
> > > > > 
> > > > > Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> > > > > (ie. main link off) I think we'd basically need to do a full modeset
> > > > > when exiting PSR, so it should probably handled somewhere higher up
> > > > > during modeset, and for other uses the frontbuffer tracking
> > > > > should perhaps just schedule a work to do the full modeset.
> > > > > 
> > > > The mention of "full modeset" got me thinking. I believe you said full
> > > > modeset because the link needs to be trained on PSR exit if it was off.
> > > > But, link off isn't supported on VLV/CHV
> > > > 
> > > > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > > /* On VLV and CHV only standby mode is supported. */
> > > > dev_priv->psr.link_standby = true;
> > > 
> > > I think that's just because we've been lazy and done it. I think even
> > > with the link off we'd need to reprogram all planes at least.
> > 
> > Not had coffee yet today, and it shows. Let me rewrite that entire thing:
> > 
> > I think that's just because we've been lazy and not done it (link off mode).
> 
> I agree with you here. This was probably exactly what was missing.
> But, how to do this without flickering (blinking?!) the screen?
> 
> > I think even without the link off we'd need to reprogram all planes at 
> > least.
> 
> on VLV/CHV or everywhere? and why do you think that?

VLV/CHV. I believe the hw implements PSR by simplty turning off the
planes (and pipes+dplls for link off), but it doesn't have any automagic
stuff for recovering the original state. It's all up to the driver.

IIRC Rodrigo even confirmed this at some point, or at least he had to
trigger a plane update to get something visible on the screen.

-- 
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 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Rodrigo Vivi]

On Thu, Mar 01, 2018 at 01:22:50PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> > On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > > 
> > > 
> > > 
> > > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > > > >>> _post_plane_update()
> > > > > > > >>> takes care of flushing when a flip is scheduled, this should 
> > > > > > > >>> be
> > > > > > > >>> sufficient for PSR and FBC.
> > > > > > > >> Makes sense.
> > > > > > > >>  
> > > > > > > > I also think this might speed up the flips a bit by avoiding 
> > > > > > > > flushes. 
> > > > > > > >
> > > > > > > >>> Cc: Paulo Zanoni 
> > > > > > > >>> Cc: Ville Syrjälä 
> > > > > > > >>> Cc: Chris Wilson 
> > > > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > > > >>> 
> > > > > > > >> Also
> > > > > > > >> Cc: Maarten Lankhorst 
> > > > > > > >> to validate the flow through atomic.
> > > > > > > >> -Chris
> > > > > > > >>
> > > > > > > Page flips used to do intel_frontbuffer_flip_prepare here, 
> > > > > > > followed by intel_frontbuffer_flip_complete. I think it would 
> > > > > > > make sense to change the patch to do that?
> > > > > > > 
> > > > > > 
> > > > > > I have no context why it was removed, I'll have to understand that
> > > > > > change and get back to you.
> > > > > 
> > > > > Since we supposedly have hw nuke for both fbc and psr there doesn't 
> > > > > seem
> > > > > to be much need to do anything for flips. I guess DRRS is the only
> > > > > thing that kinda needs it (not really, just avoids flipping with the
> > > > > slow timings). But I think DRRS should really be tied into the vblank
> > > > > stuff somehow so that we switch to the fast timings whenever a vblank
> > > > > interrupts are enabled.
> > > > 
> > > > Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> > > > (ie. main link off) I think we'd basically need to do a full modeset
> > > > when exiting PSR, so it should probably handled somewhere higher up
> > > > during modeset, and for other uses the frontbuffer tracking
> > > > should perhaps just schedule a work to do the full modeset.
> > > > 
> > > The mention of "full modeset" got me thinking. I believe you said full
> > > modeset because the link needs to be trained on PSR exit if it was off.
> > > But, link off isn't supported on VLV/CHV
> > > 
> > > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > >   /* On VLV and CHV only standby mode is supported. */
> > >   dev_priv->psr.link_standby = true;
> > 
> > I think that's just because we've been lazy and done it. I think even
> > with the link off we'd need to reprogram all planes at least.
> 
> Not had coffee yet today, and it shows. Let me rewrite that entire thing:
> 
> I think that's just because we've been lazy and not done it (link off mode).

I agree with you here. This was probably exactly what was missing.
But, how to do this without flickering (blinking?!) the screen?

> I think even without the link off we'd need to reprogram all planes at least.

on VLV/CHV or everywhere? and why do you think that?

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

Re: [Intel-gfx] [PATCH v11 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

[Yaodong Li]

On 03/01/2018 05:14 AM, Michal Wajdeczko wrote:
On Thu, 01 Mar 2018 02:01:38 +0100, Jackie Li  
wrote:



On CNL A0 and Gen9, there's a hardware restriction that requires the
available GuC WOPCM size to be larger than or equal to HuC firmware 
size.


This patch adds new verification code to ensure the available GuC WOPCM
size to be larger than or equal to HuC firmware size on both Gen9 and 
CNL

A0.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

v8:
 - Renamed variables and functions to avoid ambiguity (Joonas)
 - Updated commit message and comments to be more comprehensive (Sagar)

v9:
 - Moved code that is not related to restriction check into a separate
   patch and updated the commit message accordingly (Sagar/Michal)
 - Avoided to call uc_get_fw_size for better layer isolation (Michal)

v10:
 - Shorten function names and reorganized size_check code to have clear
   isolation (Joonas)
 - Removed unnecessary comments (Joonas)

v11:
 - Fixed logic error in size check (Michal)

BSpec: 10875

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

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

index bb78043..b30d7ff 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -107,8 +107,26 @@ static inline int gen9_check_dword_gap(u32 
guc_wopcm_base, u32 guc_wopcm_size)

 return 0;
 }
+static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 
huc_fw_size)

+{
+    /*
+ * On Gen9 & CNL A0, hardware requires the total available GuC 
WOPCM

+ * size to be larger than or equal to HuC firmware size. Otherwise,
+ * firmware uploading would fail.
+ */
+    if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
+    DRM_ERROR("HuC fw(%uKiB) won't fit in GuC WOPCM(%uKiB).\n",
+  huc_fw_size / 1024,
+  (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);


bikeshed: in earlier patches in similar error messages, you used
"HuC FW (%KiB)" and didn't provide available space. Maybe simplest
way to unify and minimize the code is to add one "failed" tag in
wopcm_init function where you can print all values used for partitioning:

failed:
DRM_ERROR("Failed to partition %uKiB WOPCM (%d)\n", 
wopcm->size/1024, err);

DRM_ERROR("HuC FW size=%uKiB\n", ...);
DRM_ERROR("GuC FW size=%uKiB\n", ...);
return err;

I will keep it as it is now to save some time since I was told to keep 
these message

at the point where the error happened.:-)

+    return -E2BIG;
+    }
+
+    return 0;
+}
+
 static inline int check_hw_restriction(struct drm_i915_private *i915,
-   u32 guc_wopcm_base, u32 guc_wopcm_size)
+   u32 guc_wopcm_base, u32 guc_wopcm_size,
+   u32 huc_fw_size)
 {
 int err = 0;
@@ -117,7 +135,10 @@ static inline int check_hw_restriction(struct 
drm_i915_private *i915,

 if (err)
 return err;
-    return 0;
+    if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, 
CNL_REVID_A0))

+    err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+
+    return err;
 }
/**
@@ -186,7 +207,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 return -E2BIG;
 }
-    err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size);
+    err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+   huc_fw_size);
 if (err) {
 DRM_ERROR("Failed to meet HW restriction.\n");
 return err;


but bikeshed is not critical, so

Reviewed-by: Michal Wajdeczko 

Thanks,
-Jackie

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

Re: [Intel-gfx] [PATCH v11 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

[Yaodong Li]

On 03/01/2018 04:56 AM, Michal Wajdeczko wrote:
On Thu, 01 Mar 2018 02:01:36 +0100, Jackie Li  
wrote:




+    if (guc_fw_size >= wopcm->size) {
+    DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
+  guc_fw_size / 1024);
+    return -E2BIG;
+    }
+
+    if (huc_fw_size >= wopcm->size) {
+    DRM_ERROR("HuC FW (%uKiB) is too big to fit in WOPCM.",
+  huc_fw_size / 1024);
+    return -E2BIG;
+    }
+
+    /* Hardware requires GuC WOPCM base to be 16K aligned. */
+    guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
+   GUC_WOPCM_OFFSET_ALIGNMENT);
+    if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
+    DRM_ERROR("GuC WOPCM base(%uKiB) is too big.\n",
+  guc_wopcm_base / 1024);
+    return -E2BIG;
+    }


hmm, all above checks are very unlikely, and are also covered by the
next check below, so maybe we can drop them?

These checks make sure these values are in a known range. so that we
don't need to worry about wrap around issues. e.g.
guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd may
wrap around if we don't have (guc_wopcm_base + ctx_rsvd) >= wopcm->size.



+
+    guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
+    /*
+ * GuC WOPCM size must be multiple of 4K pages. We've got the 
maximum
+ * WOPCM size available for GuC. Trim the size value to 4K 
boundary.

+ */
+    guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
+
+    DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
+ guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+


bikeshed: [n, m) notation suggests range n..m, so maybe better to use

DRM_DEBUG_DRIVER("Calculated GuC WOPCM: base %uKiB size %uKiB\n",
I'd like to keep it as [n, m) to suggest it's a region and to align with 
other comments

in the code.



+    /*
+ * GuC WOPCM size needs to be big enough to include all GuC 
firmware,

+ * extra 8KiB stack for GuC firmware and GUC_WOPCM_RESERVED.
+ */
+    guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+    if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
+    DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
+  (guc_fw_size + guc_wopcm_rsvd) / 1024,
+  guc_wopcm_size / 1024);


hmm, maybe to simplify calculations (and match them directly with 
diagram)

we should introduce guc_wopcm_size_min:

guc_wopcm_size_min = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED + 
guc_fw_size;

if (guc_wopcm_size_min > guc_wopcm_size) {
DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
    guc_wopcm_size_min/1024, guc_wopcm_size/1024);

As we discussed, we need find the maximum size value to meet the HW 
requirement. So maybe

I need pass this comment as well.:-)

+    return -E2BIG;
+    }
+
+    err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size);
+    if (err) {
+    DRM_ERROR("Failed to meet HW restriction.\n");
+    return err;
+    }
+
+    wopcm->guc.base = guc_wopcm_base;
+    wopcm->guc.size = guc_wopcm_size;
+
+    return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_wopcm.h 
b/drivers/gpu/drm/i915/intel_wopcm.h

new file mode 100644
index 000..39d4847
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_wopcm.h
@@ -0,0 +1,34 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2017-2018 Intel Corporation
+ */
+
+#ifndef _INTEL_WOPCM_H_
+#define _INTEL_WOPCM_H_
+
+#include 
+
+/**
+ * struct intel_wopcm - overall WOPCM info and WOPCM regions.
+ * @size: size of overall WOPCM.


bikeshed: maybe better to place this doc would be inside struct
to do not mix documentation style ?

Prefer to keep as it is now:-)



+ * @guc: GuC WOPCM Region info.
+ */
+struct intel_wopcm {
+    u32 size;
+    struct {
+    /**
+ * @base: GuC WOPCM base which is offset from WOPCM base.
+ */
+    u32 base;
+    /**
+ * @size: size of the GuC WOPCM region.
+ */
+    u32 size;
+    } guc;
+};
+
+void intel_wopcm_init_early(struct intel_wopcm *wopcm);
+int intel_wopcm_init(struct intel_wopcm *wopcm);
+
+#endif


only few bikesheds plus one suggestion, with that:

Reviewed-by: Michal Wajdeczko 

Thanks for the review.
-Jackie

___
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/icl: local_clock returns an u64

[Patchwork]

== Series Details ==

Series: drm/i915/icl: local_clock returns an u64
URL   : https://patchwork.freedesktop.org/series/39231/
State : success

== Summary ==

Series 39231v1 drm/i915/icl: local_clock returns an u64
https://patchwork.freedesktop.org/api/1.0/series/39231/revisions/1/mbox/

 Known issues:

Test gem_exec_reloc:
Subgroup basic-write-cpu:
pass   -> INCOMPLETE (fi-byt-j1900) fdo#102657
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
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:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:486s
fi-byt-j1900 total:77   pass:67   dwarn:0   dfail:0   fail:0   skip:9  
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:288s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
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:454s
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:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
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:423s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:482s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:408s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
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:396s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:496s

7fe823aaeff7c50eeaf9b238a179b41771e08f9e drm-tip: 2018y-03m-01d-15h-58m-23s UTC 
integration manifest
51aa0cc8c1e8 drm/i915/icl: local_clock returns an u64

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8202/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/icl: local_clock returns an u64

[Michel Thierry]

On 3/1/2018 10:07 AM, Michel Thierry wrote:

So change timeout_ts and use time_after64 in gen11_gt_engine_intr.



I just read Chris' original comment about this, so ignore the patch,

"The squash should be made, but time_after64 is no more correct since 
the native 32b/64b wrapped arithmetic is accurate. So what can be done 
here is remove the casts and use time_after32() if we truly cared."


-Michel


Fixes: 51951ae7ed00 ("drm/i915/icl: Interrupt handling").
Suggested-by: Tvrtko Ursulin  (long time ago)
Signed-off-by: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Oscar Mateo 
Cc: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eacb08034776..45f10db757e2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2813,7 +2813,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
  {
void __iomem * const regs = i915->regs;
-   u32 timeout_ts;
+   u64 timeout_ts;
u32 ident;
  
  	raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));

@@ -2826,7 +2826,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
do {
ident = raw_reg_read(regs, GEN11_INTR_IDENTITY_REG(bank));
} while (!(ident & GEN11_INTR_DATA_VALID) &&
-!time_after32(local_clock() >> 10, timeout_ts));
+!time_after64(local_clock() >> 10, timeout_ts));
  
  	if (unlikely(!(ident & GEN11_INTR_DATA_VALID))) {

DRM_ERROR("INTR_IDENTITY_REG%u:%u 0x%08x not valid!\n",


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

[Intel-gfx] [PATCH] drm/i915/icl: local_clock returns an u64

[Michel Thierry]

So change timeout_ts and use time_after64 in gen11_gt_engine_intr.

Fixes: 51951ae7ed00 ("drm/i915/icl: Interrupt handling").
Suggested-by: Tvrtko Ursulin  (long time ago)
Signed-off-by: Michel Thierry 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Oscar Mateo 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eacb08034776..45f10db757e2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2813,7 +2813,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
 const unsigned int bank, const unsigned int bit)
 {
void __iomem * const regs = i915->regs;
-   u32 timeout_ts;
+   u64 timeout_ts;
u32 ident;
 
raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));
@@ -2826,7 +2826,7 @@ gen11_gt_engine_intr(struct drm_i915_private * const i915,
do {
ident = raw_reg_read(regs, GEN11_INTR_IDENTITY_REG(bank));
} while (!(ident & GEN11_INTR_DATA_VALID) &&
-!time_after32(local_clock() >> 10, timeout_ts));
+!time_after64(local_clock() >> 10, timeout_ts));
 
if (unlikely(!(ident & GEN11_INTR_DATA_VALID))) {
DRM_ERROR("INTR_IDENTITY_REG%u:%u 0x%08x not valid!\n",
-- 
2.16.2

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

Re: [Intel-gfx] i915 vs checkpatch

[Rodrigo Vivi]

On Thu, Mar 01, 2018 at 06:13:31PM +0200, Jani Nikula wrote:
> 
> I went through the recent checkpatch reports, and here's my take.
> 
> On Thu, 01 Mar 2018, Arkadiusz Hiler  wrote:
> >  2. Which of the checkpatch checks we want to disabled for i915?
> 
> I'd like to have these silenced:
> 
> CHECK: No space is necessary after a cast
> WARNING: line over 80 characters
> WARNING: quoted string split across lines
> 
> I'd prefer we conform to the last two too, but there's just too much
> noise and too many cases where we explicitly should ignore them.
> 
> For the time being, I think we may have to silence these ones too, but
> I'd like us to discuss enforcing them:
> 
> CHECK: Prefer kernel type 'u16' over 'uint16_t'
> CHECK: Prefer kernel type 'u32' over 'uint32_t'
> CHECK: Prefer kernel type 'u64' over 'uint64_t'
> CHECK: Prefer kernel type 'u8' over 'uint8_t'
> CHECK: Prefer using the BIT macro
> 
> The BIT macros is one that I'd consider accepting a one-time conversion
> of i915_reg.h and after that use it exclusively. But up to debate.

For this one I just wonder if we would need to do a massive
change before. Because it would get ugly to have mixed cases.

ack on all the rest of the list here on this email.

> 
> >  3. How strongly do we want to enforce the rest?
> 
> It depends on the case. Some of the warnings are notes to check, will be
> emitted even for correct code, and can't be automatically enforced.
> 
> Of the recently reported ones, I'd like to enforce:
> 
> CHECK: Alignment should match open parenthesis
> CHECK: Blank lines aren't necessary after an open brace '{'
> CHECK: Lines should not end with a '('
> CHECK: Please don't use multiple blank lines
> CHECK: Please use a blank line after function/struct/union/enum declarations
> CHECK: Unbalanced braces around else statement
> CHECK: Unnecessary parentheses around 'level >= 1'
> CHECK: Unnecessary parentheses around 'pipe == PIPE_A'
> CHECK: braces {} should be used on all arms of this statement
> CHECK: multiple assignments should be avoided
> CHECK: spaces preferred around that '*' (ctx:VxV)
> CHECK: spaces preferred around that '<<' (ctx:VxV)
> CHECK: spinlock_t definition without comment
> CHECK: struct mutex definition without comment
> ERROR: Missing Signed-off-by: line(s)
> ERROR: Unrecognized email address: Foo Bar  ERROR: code indent should use tabs where possible
> ERROR: spaces required around that '=' (ctx:VxW)
> ERROR: trailing whitespace
> WARNING: 'consistancy' may be misspelled - perhaps 'consistency'?
> WARNING: 'writting' may be misspelled - perhaps 'writing'?
> WARNING: Missing a blank line after declarations
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> WARNING: Statements should start on a tabstop
> WARNING: please, no space before tabs
> WARNING: please, no spaces at the start of a line
> WARNING: suspect code indent for conditional statements (8, 17)
> 
> These ones should be double checked by author/reviewer/committer. These
> can't be automatically enforced:
> 
> CHECK: Macro argument reuse 'info' - possible side-effects?
> ERROR: Macros with complex values should be enclosed in parentheses
> WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather 
> than BUG() or BUG_ON()
> WARNING: Macros with flow control statements should be avoided
> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
> line)
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> 
> If we have the filtering in place in dim, we could require the committer
> to pass a parameter to dim to apply patches with the above warnings.
> 
> >  4. Do we want to change what's already in the tree, for compliance?
> 
> With the exception of the BIT() macro, I still think not. But patch
> series touching existing code should move towards compliance (for want
> of a better word).
> 
> 
> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dim-tools mailing list
> dim-to...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 4/6] kms_writeback: Add writeback-check-output

[Liviu Dudau]

From: Brian Starkey 

Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.

Signed-off-by: Brian Starkey 
---
 tests/kms_writeback.c | 123 ++
 1 file changed, 123 insertions(+)

diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index d922213d..af896e05 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -30,6 +30,7 @@
 #include "igt.h"
 #include "igt_core.h"
 #include "igt_fb.h"
+#include "sw_sync.h"
 
 /* We need to define these ourselves until we get an updated libdrm */
 #ifndef DRM_MODE_CONNECTOR_WRITEBACK
@@ -259,6 +260,115 @@ static void writeback_fb_id(igt_output_t *output, 
igt_fb_t *valid_fb, igt_fb_t *
igt_assert(ret == 0);
 }
 
+static void fill_fb(igt_fb_t *fb, double color[3])
+{
+   cairo_t *cr = igt_get_cairo_ctx(fb->fd, fb);
+   igt_assert(cr);
+
+   igt_paint_color(cr, 0, 0, fb->width, fb->height,
+   color[0], color[1], color[2]);
+}
+
+static void get_and_wait_out_fence(igt_output_t *output)
+{
+   int ret, out_fence = out_fence = 
igt_output_get_last_writeback_out_fence(output);
+   igt_assert(out_fence >= 0);
+
+   ret = sync_fence_wait(out_fence, 1000);
+   igt_assert(ret == 0);
+   close(out_fence);
+}
+
+static void writeback_seqence(igt_output_t *output, igt_plane_t *plane,
+ igt_fb_t *in_fb, igt_fb_t *out_fbs[], int 
n_commits)
+{
+   int i, color_idx = 0;
+   double in_fb_colors[2][3] = {
+   { 1.0, 0.0, 0.0 },
+   { 0.0, 1.0, 0.0 },
+   };
+   double clear_color[3] = { 1.0, 1.0, 1.0 };
+   igt_crc_t cleared_crc, out_expected;
+
+   for (i = 0; i < n_commits; i++, color_idx++) {
+   /* Change the input color each time */
+   fill_fb(in_fb, in_fb_colors[color_idx % 2]);
+
+   if (out_fbs[i]) {
+   igt_crc_t out_before;
+
+   /* Get the expected CRC */
+   fill_fb(out_fbs[i], in_fb_colors[color_idx % 2]);
+   igt_fb_get_crc(out_fbs[i], _expected);
+
+   fill_fb(out_fbs[i], clear_color);
+   if (i == 0)
+   igt_fb_get_crc(out_fbs[i], _crc);
+   igt_fb_get_crc(out_fbs[i], _before);
+   igt_assert_crc_equal(_crc, _before);
+   }
+
+   /* Commit */
+   igt_plane_set_fb(plane, in_fb);
+   igt_output_set_writeback_fb(output, out_fbs[i]);
+   if (out_fbs[i])
+   igt_output_request_writeback_out_fence(output);
+   igt_display_commit_atomic(output->display,
+ DRM_MODE_ATOMIC_ALLOW_MODESET,
+ NULL);
+   if (out_fbs[i])
+   get_and_wait_out_fence(output);
+
+   /* Make sure the old output buffer is untouched */
+   if (i > 0 && out_fbs[i - 1] && (out_fbs[i] != out_fbs[i - 1])) {
+   igt_crc_t out_prev;
+   igt_fb_get_crc(out_fbs[i - 1], _prev);
+   igt_assert_crc_equal(_crc, _prev);
+   }
+
+   /* Make sure this output buffer is written */
+   if (out_fbs[i]) {
+   igt_crc_t out_after;
+   igt_fb_get_crc(out_fbs[i], _after);
+   igt_assert_crc_equal(_expected, _after);
+
+   /* And clear it, for the next time */
+   fill_fb(out_fbs[i], clear_color);
+   }
+   }
+}
+
+static void writeback_check_output(igt_output_t *output, igt_plane_t *plane,
+  igt_fb_t *input_fb, igt_fb_t *output_fb)
+{
+   igt_fb_t *out_fbs[2] = { 0 };
+   igt_fb_t second_out_fb;
+   int ret;
+
+   /* One commit, with a writeback. */
+   writeback_seqence(output, plane, input_fb, _fb, 1);
+
+   /* Two commits, the second with no writeback */
+   out_fbs[0] = output_fb;
+   writeback_seqence(output, plane, input_fb, out_fbs, 2);
+
+   /* Two commits, both with writeback */
+   out_fbs[1] = output_fb;
+   writeback_seqence(output, plane, input_fb, out_fbs, 2);
+
+   ret = igt_create_fb(output_fb->fd, output_fb->width, output_fb->height,
+   DRM_FORMAT_XRGB,
+   igt_fb_mod_to_tiling(0),
+   _out_fb);
+   igt_require(ret > 0);
+
+   /* Two commits, with different writeback buffers */
+   out_fbs[1] = _out_fb;
+   writeback_seqence(output, plane, input_fb, out_fbs, 2);
+
+   igt_remove_fb(output_fb->fd, _out_fb);
+}
+
 igt_main
 {
igt_display_t display;
@@ 

[Intel-gfx] [PATCH i-g-t 5/6] lib/igt_kms: Add igt_output_clone_pipe for cloning

[Liviu Dudau]

From: Brian Starkey 

An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()

Signed-off-by: Brian Starkey 
---
 lib/igt_kms.c | 99 ---
 lib/igt_kms.h |  5 +++
 2 files changed, 66 insertions(+), 38 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index d558c1b8..23fb064f 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1646,6 +1646,17 @@ static void igt_display_log_shift(igt_display_t 
*display, int shift)
igt_assert(display->log_shift >= 0);
 }
 
+static int igt_output_idx(igt_output_t *output)
+{
+   int i;
+
+   for (i = 0; i < output->display->n_outputs; i++)
+   if (>display->outputs[i] == output)
+   return i;
+
+   return -1;
+}
+
 static void igt_output_refresh(igt_output_t *output)
 {
igt_display_t *display = output->display;
@@ -2133,42 +2144,6 @@ void igt_display_fini(igt_display_t *display)
display->pipes = NULL;
 }
 
-static void igt_display_refresh(igt_display_t *display)
-{
-   igt_output_t *output;
-   int i;
-
-   unsigned long pipes_in_use = 0;
-
-   /* Check that two outputs aren't trying to use the same pipe */
-   for (i = 0; i < display->n_outputs; i++) {
-   output = >outputs[i];
-
-   if (output->pending_pipe != PIPE_NONE) {
-   if (pipes_in_use & (1 << output->pending_pipe))
-   goto report_dup;
-
-   pipes_in_use |= 1 << output->pending_pipe;
-   }
-
-   if (output->force_reprobe)
-   igt_output_refresh(output);
-   }
-
-   return;
-
-report_dup:
-   for (; i > 0; i--) {
-   igt_output_t *b = >outputs[i - 1];
-
-   igt_assert_f(output->pending_pipe !=
-b->pending_pipe,
-"%s and %s are both trying to use pipe %s\n",
-igt_output_name(output), igt_output_name(b),
-kmstest_pipe_name(output->pending_pipe));
-   }
-}
-
 static igt_pipe_t *igt_output_get_driving_pipe(igt_output_t *output)
 {
igt_display_t *display = output->display;
@@ -2192,6 +2167,39 @@ static igt_pipe_t 
*igt_output_get_driving_pipe(igt_output_t *output)
return >pipes[pipe];
 }
 
+static void igt_display_refresh(igt_display_t *display)
+{
+   igt_output_t *output;
+   igt_pipe_t *pipe;
+   int i;
+
+   unsigned long pipes_in_use = 0;
+
+   /* Check that outputs and pipes agree wrt. cloning */
+   for (i = 0; i < display->n_outputs; i++) {
+   output = >outputs[i];
+   unsigned long pending_crtc_idx_mask = 1 << output->pending_pipe;
+
+   pipe = igt_output_get_driving_pipe(output);
+   if (pipe) {
+   igt_assert_f(pipe->outputs & (1 << 
igt_output_idx(output)),
+"Output %s not expected to be using pipe 
%s\n",
+igt_output_name(output),
+kmstest_pipe_name(pipe->pipe));
+
+   if (pipes_in_use & pending_crtc_idx_mask)
+   LOG(display, "Output %s clones pipe %s\n",
+   igt_output_name(output),
+   kmstest_pipe_name(pipe->pipe));
+   }
+
+   pipes_in_use |= pending_crtc_idx_mask;
+
+   if (output->force_reprobe)
+   igt_output_refresh(output);
+   }
+}
+
 static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe, int plane_idx)
 {
igt_require_f(plane_idx >= 0 && plane_idx < pipe->n_planes,
@@ -3344,6 +3352,7 @@ void igt_output_override_mode(igt_output_t *output, 
drmModeModeInfo *mode)
output->use_override_mode = !!mode;
 
if (pipe) {
+   igt_debug("overriding pipe mode in %s way\n", 
output->display->is_atomic ? "atomic" : "legacy");
if (output->display->is_atomic)
igt_pipe_obj_replace_prop_blob(pipe, IGT_CRTC_MODE_ID, 
igt_output_get_mode(output), sizeof(*mode));
else
@@ -3351,6 +3360,16 @@ void igt_output_override_mode(igt_output_t *output, 
drmModeModeInfo *mode)
}
 }
 
+void igt_output_clone_pipe(igt_output_t *output, enum pipe pipe)
+{
+   igt_display_t *display = output->display;
+   uint32_t current_clones = display->pipes[pipe].outputs;
+
+   igt_output_set_pipe(output, pipe);
+
+   display->pipes[pipe].outputs |= current_clones;
+}
+
 /*
  * igt_output_set_pipe:
  * @output: Target output for which the pipe is being set to
@@ -3367,11 +3386,15 @@ void igt_output_set_pipe(igt_output_t *output, enum 
pipe pipe)
 
igt_assert(output->name);
 
-   if (output->pending_pipe != 

[Intel-gfx] [PATCH i-g-t 2/6] kms_writeback: Add initial writeback tests

[Liviu Dudau]

From: Brian Starkey 

Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.

Signed-off-by: Brian Starkey 
---
 lib/igt_kms.c  |   7 +-
 lib/igt_kms.h  |   8 ++
 tests/Makefile.sources |   1 +
 tests/kms_writeback.c  | 352 +
 tests/meson.build  |   1 +
 5 files changed, 365 insertions(+), 4 deletions(-)
 create mode 100644 tests/kms_writeback.c

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 00d9d2e2..d558c1b8 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -2267,8 +2267,7 @@ static uint32_t igt_plane_get_fb_id(igt_plane_t *plane)
 /*
  * Add position and fb changes of a plane to the atomic property set
  */
-static void
-igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe,
+void igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe,
drmModeAtomicReq *req)
 {
igt_display_t *display = pipe->display;
@@ -2878,7 +2877,7 @@ igt_pipe_obj_replace_prop_blob(igt_pipe_t *pipe, enum 
igt_atomic_crtc_properties
 /*
  * Add crtc property changes to the atomic property set
  */
-static void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, 
drmModeAtomicReq *req)
+void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicReq 
*req)
 {
int i;
 
@@ -2902,7 +2901,7 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t 
*pipe_obj, drmModeAtomicRe
 /*
  * Add connector property changes to the atomic property set
  */
-static void igt_atomic_prepare_connector_commit(igt_output_t *output, 
drmModeAtomicReq *req)
+void igt_atomic_prepare_connector_commit(igt_output_t *output, 
drmModeAtomicReq *req)
 {
 
int i;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 59ccc4c6..f38fd0a0 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -581,6 +581,12 @@ extern void igt_output_replace_prop_blob(igt_output_t 
*output,
 enum igt_atomic_connector_properties 
prop,
 const void *ptr, size_t length);
 
+void igt_atomic_prepare_plane_commit(igt_plane_t *plane, igt_pipe_t *pipe,
+   drmModeAtomicReq *req);
+
+
+void igt_atomic_prepare_crtc_commit(igt_pipe_t *pipe_obj, drmModeAtomicReq 
*req);
+
 /**
  * igt_pipe_obj_has_prop:
  * @pipe: Pipe to check.
@@ -670,6 +676,8 @@ extern void igt_pipe_obj_replace_prop_blob(igt_pipe_t *pipe,
 
 void igt_pipe_refresh(igt_display_t *display, enum pipe pipe, bool force);
 
+void igt_atomic_prepare_connector_commit(igt_output_t *output, 
drmModeAtomicReq *req);
+
 void igt_enable_connectors(void);
 void igt_reset_connectors(void);
 
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 23f859be..9cfa474d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -212,6 +212,7 @@ TESTS_progs = \
kms_tv_load_detect \
kms_universal_plane \
kms_vblank \
+   kms_writeback \
meta_test \
perf \
perf_pmu \
diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
new file mode 100644
index ..d922213d
--- /dev/null
+++ b/tests/kms_writeback.c
@@ -0,0 +1,352 @@
+/*
+ * (C) COPYRIGHT 2017 ARM Limited. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "igt_core.h"
+#include "igt_fb.h"
+
+/* We need to define these ourselves until we get an updated libdrm */
+#ifndef DRM_MODE_CONNECTOR_WRITEBACK
+#define DRM_MODE_CONNECTOR_WRITEBACK   18
+#endif
+
+static drmModePropertyBlobRes *get_writeback_formats_blob(igt_output_t *output)
+{
+   drmModePropertyBlobRes *blob = NULL;
+   uint64_t blob_id;
+   int ret;
+
+   ret = kmstest_get_property(output->display->drm_fd,
+ 

[Intel-gfx] [PATCH i-g-t 0/6] igt: Add support for testing writeback connectors

[Liviu Dudau]

We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.

Changelog:
 - This is basically a v3 of the i-g-t tests, except I've now dropped
   all the changes that were trying to split the CRC functionality out
   of lib/igt_debugfs.c. v2 is here:
   https://lists.freedesktop.org/archives/intel-gfx/2017-July/133154.html
 - Added meson support for builting the kms_writeback test

Brian Starkey (6):
  lib/igt_kms: Add writeback support in lib/
  kms_writeback: Add initial writeback tests
  lib: Add function to hash a framebuffer
  kms_writeback: Add writeback-check-output
  lib/igt_kms: Add igt_output_clone_pipe for cloning
  kms_writeback: Add tests using a cloned output

 lib/igt_fb.c   |  65 ++
 lib/igt_fb.h   |   5 +
 lib/igt_kms.c  | 178 +
 lib/igt_kms.h  |  27 +++
 tests/Makefile.sources |   1 +
 tests/kms_writeback.c  | 531 +
 tests/meson.build  |   1 +
 7 files changed, 765 insertions(+), 43 deletions(-)
 create mode 100644 tests/kms_writeback.c

-- 
2.16.1

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

[Intel-gfx] [PATCH i-g-t 3/6] lib: Add function to hash a framebuffer

[Liviu Dudau]

From: Brian Starkey 

To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.

Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
(which can take advantage of word-access speedup), we can do the hash
on a cached copy, which is much faster (10x speedup on my platform).

Signed-off-by: Brian Starkey 
---
 lib/igt_fb.c | 65 
 lib/igt_fb.h |  5 +
 2 files changed, 70 insertions(+)

diff --git a/lib/igt_fb.c b/lib/igt_fb.c
index 7404ba7c..1501006e 100644
--- a/lib/igt_fb.c
+++ b/lib/igt_fb.c
@@ -1705,3 +1705,68 @@ bool igt_fb_supported_format(uint32_t drm_format)
 
return false;
 }
+
+/*
+ * This implements the FNV-1a hashing algorithm instead of CRC, for
+ * simplicity
+ * http://www.isthe.com/chongo/tech/comp/fnv/index.html
+ *
+ * hash = offset_basis
+ * for each octet_of_data to be hashed
+ * hash = hash xor octet_of_data
+ * hash = hash * FNV_prime
+ * return hash
+ *
+ * 32 bit offset_basis = 2166136261
+ * 32 bit FNV_prime = 224 + 28 + 0x93 = 16777619
+ */
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc)
+{
+#define FNV1a_OFFSET_BIAS 2166136261
+#define FNV1a_PRIME 16777619
+   uint32_t hash;
+   void *map;
+   char *ptr, *line = NULL;
+   int x, y, cpp = igt_drm_format_to_bpp(fb->drm_format) / 8;
+
+   if (fb->is_dumb)
+   map = kmstest_dumb_map_buffer(fb->fd, fb->gem_handle, fb->size,
+ PROT_READ);
+   else
+   map = gem_mmap__gtt(fb->fd, fb->gem_handle, fb->size,
+   PROT_READ);
+   ptr = map;
+
+   /*
+* Framebuffers are often uncached, which can make byte-wise accesses
+* very slow. We copy each line of the FB into a local buffer to speed
+* up the hashing.
+*/
+   line = malloc(fb->stride);
+   if (!line) {
+   munmap(map, fb->size);
+   return -ENOMEM;
+   }
+
+   hash = FNV1a_OFFSET_BIAS;
+
+   for (y = 0; y < fb->height; y++, ptr += fb->stride) {
+
+   memcpy(line, ptr, fb->stride);
+
+   for (x = 0; x < fb->width * cpp; x++) {
+   hash ^= line[x];
+   hash *= FNV1a_PRIME;
+   }
+   }
+
+   crc->n_words = 1;
+   crc->crc[0] = hash;
+
+   free(line);
+   munmap(map, fb->size);
+
+   return 0;
+#undef FNV1a_OFFSET_BIAS
+#undef FNV1a_PRIME
+}
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index 023b069d..bc615516 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -36,6 +36,8 @@
 
 #include 
 
+#include "igt_debugfs.h"
+
 /**
  * igt_fb_t:
  * @fb_id: KMS ID of the framebuffer
@@ -164,5 +166,8 @@ uint32_t igt_drm_format_to_bpp(uint32_t drm_format);
 const char *igt_format_str(uint32_t drm_format);
 bool igt_fb_supported_format(uint32_t drm_format);
 
+/* Get a hash for a framebuffer */
+int igt_fb_get_crc(struct igt_fb *fb, igt_crc_t *crc);
+
 #endif /* __IGT_FB_H__ */
 
-- 
2.16.1

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

[Intel-gfx] [PATCH i-g-t 1/6] lib/igt_kms: Add writeback support in lib/

[Liviu Dudau]

From: Brian Starkey 

Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.

Signed-off-by: Brian Starkey 
---
 lib/igt_kms.c | 72 ++-
 lib/igt_kms.h | 14 
 2 files changed, 85 insertions(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 022abfe7..00d9d2e2 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -190,7 +190,10 @@ const char 
*igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
"CRTC_ID",
"DPMS",
-   "Broadcast RGB"
+   "Broadcast RGB",
+   "WRITEBACK_PIXEL_FORMATS",
+   "WRITEBACK_FB_ID",
+   "WRITEBACK_OUT_FENCE_PTR"
 };
 
 /*
@@ -452,6 +455,7 @@ static const struct type_name connector_type_names[] = {
{ DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
{ DRM_MODE_CONNECTOR_DSI, "DSI" },
{ DRM_MODE_CONNECTOR_DPI, "DPI" },
+   { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
{}
 };
 
@@ -1947,6 +1951,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
output->force_reprobe = true;
output->id = resources->connectors[i];
output->display = display;
+   output->writeback_out_fence_fd = -1;
 
igt_output_refresh(output);
}
@@ -2040,6 +2045,43 @@ igt_output_t *igt_output_from_connector(igt_display_t 
*display,
return found;
 }
 
+void igt_output_set_writeback_fb(igt_output_t *output, struct igt_fb *fb)
+{
+   igt_display_t *display = output->display;
+   struct kmstest_connector_config *config = >config;
+
+   if (config->connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK)
+   return;
+
+   LOG(display, "%s: output_set_writeback_fb(%d)\n", output->name,
+   fb ? fb->fb_id : 0);
+
+   output->writeback_fb = fb;
+}
+
+static void igt_output_reset_writeback_out_fence(igt_output_t *output)
+{
+   if (output->writeback_out_fence_fd >= 0) {
+   close(output->writeback_out_fence_fd);
+   output->writeback_out_fence_fd = -1;
+   }
+}
+
+void igt_output_request_writeback_out_fence(igt_output_t *output)
+{
+   igt_output_reset_writeback_out_fence(output);
+   igt_output_set_prop_value(output, IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR,
+ (ptrdiff_t)>writeback_out_fence_fd);
+}
+
+int igt_output_get_last_writeback_out_fence(igt_output_t *output)
+{
+   int fd = output->writeback_out_fence_fd;
+   output->writeback_out_fence_fd = -1;
+
+   return fd;
+}
+
 static void igt_pipe_fini(igt_pipe_t *pipe)
 {
int i;
@@ -2063,6 +2105,8 @@ static void igt_pipe_fini(igt_pipe_t *pipe)
 static void igt_output_fini(igt_output_t *output)
 {
kmstest_free_connector_config(>config);
+   if (output->writeback_out_fence_fd >= 0)
+   close(output->writeback_out_fence_fd);
free(output->name);
output->name = NULL;
 }
@@ -2879,6 +2923,31 @@ static void 
igt_atomic_prepare_connector_commit(igt_output_t *output, drmModeAto
  output->props[i],
  output->values[i]));
}
+
+   if (output->writeback_fb)
+   output->writeback_fb = NULL;
+
+   igt_output_reset_writeback_out_fence(output);
+}
+
+static void handle_writeback_out_fences(igt_display_t *display, uint32_t 
flags, int ret)
+{
+   int i;
+
+   for (i = 0; i < display->n_outputs; i++) {
+   igt_output_t *output = >outputs[i];
+
+   if (!output->config.connector)
+   continue;
+
+   if (!igt_output_is_prop_changed(output, 
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR))
+   continue;
+
+   igt_output_clear_prop_changed(output, 
IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR);
+
+   if (ret || (flags & DRM_MODE_ATOMIC_TEST_ONLY))
+   igt_assert(output->writeback_out_fence_fd == -1);
+   }
 }
 
 /*
@@ -2929,6 +2998,7 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
}
 
ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+   handle_writeback_out_fences(display, flags, ret);
 
drmModeAtomicFree(req);
return ret;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 1c46186e..59ccc4c6 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -38,6 +38,10 @@
 #include "igt_fb.h"
 #include "ioctl_wrappers.h"
 
+#ifndef DRM_MODE_CONNECTOR_WRITEBACK
+#define DRM_MODE_CONNECTOR_WRITEBACK   18
+#endif
+
 /* Low-level helpers with kmstest_ prefix */
 
 /**
@@ -120,6 +124,9 @@ enum igt_atomic_connector_properties {
IGT_CONNECTOR_CRTC_ID,
IGT_CONNECTOR_DPMS,
IGT_CONNECTOR_BROADCAST_RGB,
+   IGT_CONNECTOR_WRITEBACK_PIXEL_FORMATS,
+   

[Intel-gfx] [PATCH i-g-t 6/6] kms_writeback: Add tests using a cloned output

[Liviu Dudau]

From: Brian Starkey 

Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.

Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.

Signed-off-by: Brian Starkey 
---
 tests/kms_writeback.c | 76 ---
 1 file changed, 66 insertions(+), 10 deletions(-)

diff --git a/tests/kms_writeback.c b/tests/kms_writeback.c
index af896e05..5da7086f 100644
--- a/tests/kms_writeback.c
+++ b/tests/kms_writeback.c
@@ -56,7 +56,8 @@ static drmModePropertyBlobRes 
*get_writeback_formats_blob(igt_output_t *output)
return blob;
 }
 
-static bool check_writeback_config(igt_display_t *display, igt_output_t 
*output)
+static bool check_writeback_config(igt_display_t *display, igt_output_t 
*output,
+  int pipe, igt_output_t **clone)
 {
igt_fb_t input_fb, output_fb;
igt_plane_t *plane;
@@ -98,6 +99,27 @@ static bool check_writeback_config(igt_display_t *display, 
igt_output_t *output)
 
ret = igt_display_try_commit_atomic(display, DRM_MODE_ATOMIC_TEST_ONLY |
DRM_MODE_ATOMIC_ALLOW_MODESET, 
NULL);
+   if (!ret && clone) {
+   /* Try and find a clone */
+   int i, newret;
+   *clone = NULL;
+
+   for (i = 0; i < display->n_outputs; i++) {
+   igt_output_t *second_output = >outputs[i];
+   if (output != second_output &&
+   igt_pipe_connector_valid(pipe, second_output)) {
+
+   igt_output_clone_pipe(second_output, pipe);
+   newret = igt_display_try_commit_atomic(display, 
DRM_MODE_ATOMIC_TEST_ONLY |
+   
DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);
+   igt_output_set_pipe(second_output, PIPE_NONE);
+   if (!newret) {
+   *clone = second_output;
+   break;
+   }
+   }
+   }
+   }
igt_plane_set_fb(plane, NULL);
igt_remove_fb(display->drm_fd, _fb);
igt_remove_fb(display->drm_fd, _fb);
@@ -105,7 +127,8 @@ static bool check_writeback_config(igt_display_t *display, 
igt_output_t *output)
return !ret;
 }
 
-static igt_output_t *kms_writeback_get_output(igt_display_t *display)
+static igt_output_t *kms_writeback_get_output(igt_display_t *display, enum 
pipe *pipe,
+ igt_output_t **clone)
 {
int i;
 
@@ -121,10 +144,16 @@ static igt_output_t 
*kms_writeback_get_output(igt_display_t *display)
for (j = 0; j < igt_display_get_n_pipes(display); j++) {
igt_output_set_pipe(output, j);
 
-   if (check_writeback_config(display, output)) {
+   if (check_writeback_config(display, output, j, clone)) {
igt_debug("Using connector %u:%s on pipe %d\n",
  
output->config.connector->connector_id,
  output->name, j);
+   if (clone && *clone)
+   igt_debug("Cloning to connector 
%u:%s\n",
+ 
(*clone)->config.connector->connector_id,
+ (*clone)->name);
+   if (pipe)
+   *pipe = j;
return output;
}
}
@@ -165,9 +194,6 @@ static int do_writeback_test(igt_output_t *output, uint32_t 
flags,
igt_pipe_t *pipe_obj = >pipes[pipe];
igt_plane_t *plane;
 
-   /*
-* Add CRTC Properties to the property set
-*/
igt_atomic_prepare_crtc_commit(pipe_obj, req);
 
for_each_plane_on_pipe(display, pipe, plane) {
@@ -311,6 +337,9 @@ static void writeback_seqence(igt_output_t *output, 
igt_plane_t *plane,
/* Commit */
igt_plane_set_fb(plane, in_fb);
igt_output_set_writeback_fb(output, out_fbs[i]);
+   igt_output_set_prop_value(output, IGT_CONNECTOR_WRITEBACK_FB_ID,
+ out_fbs[i] ? out_fbs[i]->fb_id : 0);
+
if (out_fbs[i])
igt_output_request_writeback_out_fence(output);
igt_display_commit_atomic(output->display,
@@ -372,10 +401,11 @@ static void writeback_check_output(igt_output_t *output, 
igt_plane_t *plane,
 igt_main
 {
igt_display_t display;
-   

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

[Patchwork]

== Series Details ==

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

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-a-ts-continuation-modeset:
skip   -> PASS   (shard-snb)
Subgroup pipe-b-ts-continuation-modeset:
skip   -> PASS   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-external:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +2
Test kms_chv_cursor_fail:
Subgroup pipe-b-64x64-bottom-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185 +2
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-pwrite:
pass   -> DMESG-FAIL (shard-apl) fdo#101623
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-apl) fdo#99912
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755

shard-apltotal:3446 pass:1809 dwarn:1   dfail:1   fail:7   skip:1625 
time:11410s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11799s
shard-snbtotal:3460 pass:1356 dwarn:4   dfail:0   fail:1   skip:2099 
time:6632s
Blacklisted hosts:
shard-kbltotal:3392 pass:1907 dwarn:1   dfail:0   fail:7   skip:1476 
time:9158s

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/1] drm/i915/uc: Make GuC/HuC fw fetch and 
loading functions/file structure symmetric
URL   : https://patchwork.freedesktop.org/series/39224/
State : success

== Summary ==

Series 39224v1 series starting with [v3,1/1] drm/i915/uc: Make GuC/HuC fw fetch 
and loading functions/file structure symmetric
https://patchwork.freedesktop.org/api/1.0/series/39224/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#105310

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
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:495s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:483s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:460s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:390s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:570s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:580s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
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:389s
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:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:262  dwarn:1   dfail:0   fail:1   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:521s
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:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:409s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:505s

7fe823aaeff7c50eeaf9b238a179b41771e08f9e drm-tip: 2018y-03m-01d-15h-58m-23s UTC 
integration manifest
5b17f9eb12a5 drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file 
structure symmetric

== Logs ==

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

[Intel-gfx] [CI i-g-t] don't look

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

1.
We need to tell the compiler mmio access cannot be optimized away
(volatile).

2.
We need to ensure we don't exit with forcewake left on. Signal threads
to exit in a controlled fashion and install atexit handler just in case.

v2: HACK

Signed-off-by: Tvrtko Ursulin 
---
 tests/gen7_forcewake_mt.c | 36 +---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9e8ac..04a93afc839f 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -30,6 +30,8 @@
  *
  */
 
+#pragma GCC optimize ("O0")
+
 #include "igt.h"
 #include 
 #include 
@@ -44,6 +46,7 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround required 
for"
 
 struct thread {
pthread_t thread;
+   bool run;
void *mmio;
int fd;
int bit;
@@ -106,10 +109,11 @@ static void *igfx_get_mmio(void)
 static void *thread(void *arg)
 {
struct thread *t = arg;
-   uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
+   volatile uint32_t *forcewake_mt =
+   (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
uint32_t bit = 1 << t->bit;
 
-   while (1) {
+   while (t->run) {
*forcewake_mt = bit << 16 | bit;
igt_assert(*forcewake_mt & bit);
*forcewake_mt = bit << 16;
@@ -121,13 +125,33 @@ static void *thread(void *arg)
 
 #define MI_STORE_REGISTER_MEM   (0x24<<23)
 
+static void *mmio_base;
+
+static void cleanup(int sig)
+{
+   volatile uint32_t *forcewake_mt =
+   (uint32_t *)((char *)mmio_base + FORCEWAKE_MT);
+   unsigned int bit;
+
+   for (bit = 2; bit < 16; bit++) {
+   *forcewake_mt = (1 << bit) << 16;
+   if (*forcewake_mt & (1 << bit))
+   igt_warn("Failed to restore bit %u!\n", bit);
+   }
+}
+
 igt_simple_main
 {
struct thread t[16];
int i;
 
+   mmio_base = igfx_get_mmio();
+
t[0].fd = drm_open_driver(DRIVER_INTEL);
-   t[0].mmio = igfx_get_mmio();
+   t[0].run = true;
+   t[0].mmio = mmio_base;
+
+   igt_install_exit_handler(cleanup);
 
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -201,4 +225,10 @@ igt_simple_main
 
usleep(1000);
}
+
+   for (i = 2; i < 16; i++)
+   t[i].run = false;
+
+   for (i = 2; i < 16; i++)
+   pthread_join(t[i].thread, NULL);
 }
-- 
2.14.1

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

[Intel-gfx] [PATCH v3 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Sagar Arun Kamble]

GuC load function is named intel_guc_fw_upload() and HuC load function is
named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.

While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()

v2: Changed patch to update HuC functions instead of changing
guc_fw_upload and update file structure. (Michal Wajdeczko)

v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Anusha Srivatsa 
Reviewed-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/Makefile   |   3 +-
 drivers/gpu/drm/i915/intel_guc_fw.c |  10 +--
 drivers/gpu/drm/i915/intel_huc.c| 154 +
 drivers/gpu/drm/i915/intel_huc.h|   2 +-
 drivers/gpu/drm/i915/intel_huc_fw.c | 166 
 drivers/gpu/drm/i915/intel_huc_fw.h |  15 
 drivers/gpu/drm/i915/intel_uc.c |   2 +-
 7 files changed, 191 insertions(+), 161 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_fw.c
 create mode 100644 drivers/gpu/drm/i915/intel_huc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 881d712..1bd9bc5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,7 +89,8 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
- intel_huc.o
+ intel_huc.o \
+ intel_huc_fw.o
 
 # autogenerated null render state
 i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 3b09329..d07f2b9 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -269,15 +269,15 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw, struct 
i915_vma *vma)
 }
 
 /**
- * intel_guc_fw_upload() - finish preparing the GuC for activity
+ * intel_guc_fw_upload() - load GuC uCode to device
  * @guc: intel_guc structure
  *
- * Called during driver loading and also after a GPU reset.
+ * Called from intel_uc_init_hw() during driver load, resume from sleep and
+ * after a GPU reset.
  *
- * The main action required here it to load the GuC uCode into the device.
  * The firmware image should have already been fetched into memory by the
- * earlier call to intel_guc_init(), so here we need only check that
- * worked, and then transfer the image to the h/w.
+ * earlier call to intel_uc_init_fw(), so here we need to only check that
+ * fetch succeeded, and then transfer the image to the h/w.
  *
  * Return: non-zero code on error
  */
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index ef9a05d..e37f58e 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -27,161 +27,9 @@
 #include "intel_huc.h"
 #include "i915_drv.h"
 
-/**
- * DOC: HuC Firmware
- *
- * Motivation:
- * GEN9 introduces a new dedicated firmware for usage in media HEVC (High
- * Efficiency Video Coding) operations. Userspace can use the firmware
- * capabilities by adding HuC specific commands to batch buffers.
- *
- * Implementation:
- * The same firmware loader is used as the GuC. However, the actual
- * loading to HW is deferred until GEM initialization is done.
- *
- * Note that HuC firmware loading must be done before GuC loading.
- */
-
-#define BXT_HUC_FW_MAJOR 01
-#define BXT_HUC_FW_MINOR 07
-#define BXT_BLD_NUM 1398
-
-#define SKL_HUC_FW_MAJOR 01
-#define SKL_HUC_FW_MINOR 07
-#define SKL_BLD_NUM 1398
-
-#define KBL_HUC_FW_MAJOR 02
-#define KBL_HUC_FW_MINOR 00
-#define KBL_BLD_NUM 1810
-
-#define HUC_FW_PATH(platform, major, minor, bld_num) \
-   "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
-   __stringify(minor) "_" __stringify(bld_num) ".bin"
-
-#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_HUC_FW_MAJOR, \
-   SKL_HUC_FW_MINOR, SKL_BLD_NUM)
-MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
-
-#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
-   BXT_HUC_FW_MINOR, BXT_BLD_NUM)
-MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
-
-#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_HUC_FW_MAJOR, \
-   KBL_HUC_FW_MINOR, KBL_BLD_NUM)
-MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
-
-static void huc_fw_select(struct intel_uc_fw *huc_fw)
-{
-   struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
-   struct drm_i915_private *dev_priv = huc_to_i915(huc);
-
-   GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
-
-   if (!HAS_HUC(dev_priv))
-   return;
-
-   if 

Re: [Intel-gfx] i915 vs checkpatch

[Jani Nikula]

I went through the recent checkpatch reports, and here's my take.

On Thu, 01 Mar 2018, Arkadiusz Hiler  wrote:
>  2. Which of the checkpatch checks we want to disabled for i915?

I'd like to have these silenced:

CHECK: No space is necessary after a cast
WARNING: line over 80 characters
WARNING: quoted string split across lines

I'd prefer we conform to the last two too, but there's just too much
noise and too many cases where we explicitly should ignore them.

For the time being, I think we may have to silence these ones too, but
I'd like us to discuss enforcing them:

CHECK: Prefer kernel type 'u16' over 'uint16_t'
CHECK: Prefer kernel type 'u32' over 'uint32_t'
CHECK: Prefer kernel type 'u64' over 'uint64_t'
CHECK: Prefer kernel type 'u8' over 'uint8_t'
CHECK: Prefer using the BIT macro

The BIT macros is one that I'd consider accepting a one-time conversion
of i915_reg.h and after that use it exclusively. But up to debate.

>  3. How strongly do we want to enforce the rest?

It depends on the case. Some of the warnings are notes to check, will be
emitted even for correct code, and can't be automatically enforced.

Of the recently reported ones, I'd like to enforce:

CHECK: Alignment should match open parenthesis
CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Lines should not end with a '('
CHECK: Please don't use multiple blank lines
CHECK: Please use a blank line after function/struct/union/enum declarations
CHECK: Unbalanced braces around else statement
CHECK: Unnecessary parentheses around 'level >= 1'
CHECK: Unnecessary parentheses around 'pipe == PIPE_A'
CHECK: braces {} should be used on all arms of this statement
CHECK: multiple assignments should be avoided
CHECK: spaces preferred around that '*' (ctx:VxV)
CHECK: spaces preferred around that '<<' (ctx:VxV)
CHECK: spinlock_t definition without comment
CHECK: struct mutex definition without comment
ERROR: Missing Signed-off-by: line(s)
ERROR: Unrecognized email address: Foo Bar   4. Do we want to change what's already in the tree, for compliance?

With the exception of the BIT() macro, I still think not. But patch
series touching existing code should move towards compliance (for want
of a better word).


BR,
Jani.


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

Re: [Intel-gfx] [PATCH igt v2] igt/gem_ctx_switch: Exercise all engines at once

[Antonio Argenziano]

On 28/02/18 23:51, Chris Wilson wrote:

Just a small variant to apply a continuous context-switch load to all
engines.

v2: Adapt to for_each_physical_engine() and sane gem_context_create()

Signed-off-by: Chris Wilson 
Cc: Antonio Argenziano 


LGTM.

Reviewed-by: Antonio Argenziano 
___
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 [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch and 
loading functions/file structure symmetric
URL   : https://patchwork.freedesktop.org/series/39220/
State : success

== Summary ==

Series 39220v1 series starting with [v2,1/1] drm/i915/uc: Make GuC/HuC fw fetch 
and loading functions/file structure symmetric
https://patchwork.freedesktop.org/api/1.0/series/39220/revisions/1/mbox/

 Known issues:

Test kms_chamelium:
Subgroup dp-hpd-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#105310 +8
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:492s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:279s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
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:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:459s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:390s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
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:386s
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: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:452s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
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:497s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:588s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:435s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:520s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:489s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:500s

61da3e8943e4b5e643e3d72f3a925227fe4cb84c drm-tip: 2018y-03m-01d-13h-30m-46s UTC 
integration manifest
99fb8616aeef drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file 
structure symmetric

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Sagar Arun Kamble]

On 3/1/2018 8:21 PM, Michal Wajdeczko wrote:
On Thu, 01 Mar 2018 15:47:22 +0100, Sagar Arun Kamble 
 wrote:


GuC load function is named intel_guc_fw_upload() and HuC load 
function is

named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.

While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()

v2: Changed patch to update HuC functions instead of changing
    guc_fw_upload and update file structure. (Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Anusha Srivatsa 


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

index 40039db..5d6e804 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -26,6 +26,7 @@
 #define _INTEL_HUC_H_
#include "intel_uc_fw.h"
+#include "intel_huc_fw.h"


hmm, as we don't need anything from this header, maybe we can drop it ?
fw_init_early called from huc.c and fw_upload from uc.c which can access 
through intel_huc.h.

Similar to GuC. Not including huc_fw.h directly in huc.c or uc.c



struct intel_huc {
 /* Generic uC firmware management */
@@ -35,7 +36,6 @@ struct intel_huc {
 };
void intel_huc_init_early(struct intel_huc *huc);
-int intel_huc_init_hw(struct intel_huc *huc);
 int intel_huc_auth(struct intel_huc *huc);
#endif
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c 
b/drivers/gpu/drm/i915/intel_huc_fw.c

new file mode 100644
index 000..d83a63d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright © 2016-2018 Intel Corporation


I think there was agreement to use SPDX license identifiers only.


Ah. right. will update. Thanks

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

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

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

+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "intel_huc_fw.h"
+#include "i915_drv.h"
+
+/**
+ * DOC: HuC Firmware
+ *
+ * Motivation:
+ * GEN9 introduces a new dedicated firmware for usage in media HEVC 
(High

+ * Efficiency Video Coding) operations. Userspace can use the firmware
+ * capabilities by adding HuC specific commands to batch buffers.
+ *
+ * Implementation:
+ * The same firmware loader is used as the GuC. However, the actual
+ * loading to HW is deferred until GEM initialization is done.
+ *
+ * Note that HuC firmware loading must be done before GuC loading.
+ */
+
+#define BXT_HUC_FW_MAJOR 01
+#define BXT_HUC_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
+#define SKL_HUC_FW_MAJOR 01
+#define SKL_HUC_FW_MINOR 07
+#define SKL_BLD_NUM 1398
+
+#define KBL_HUC_FW_MAJOR 02
+#define KBL_HUC_FW_MINOR 00
+#define KBL_BLD_NUM 1810
+
+#define HUC_FW_PATH(platform, major, minor, bld_num) \
+    "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
+    __stringify(minor) "_" __stringify(bld_num) ".bin"
+
+#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_HUC_FW_MAJOR, \
+    SKL_HUC_FW_MINOR, SKL_BLD_NUM)
+MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
+
+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
+    BXT_HUC_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
+#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_HUC_FW_MAJOR, \
+    KBL_HUC_FW_MINOR, KBL_BLD_NUM)
+MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
+
+static void huc_fw_select(struct intel_uc_fw *huc_fw)
+{
+    struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
+    struct drm_i915_private *dev_priv = huc_to_i915(huc);
+
+    GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
+
+    if (!HAS_HUC(dev_priv))
+    return;
+
+    if (i915_modparams.huc_firmware_path) {
+    huc_fw->path = 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: don't leak the pin_map on error

[Patchwork]

== Series Details ==

Series: drm/i915: don't leak the pin_map on error
URL   : https://patchwork.freedesktop.org/series/39207/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-right-edge:
dmesg-warn -> PASS   (shard-snb) fdo#105185
Test kms_cursor_crc:
Subgroup cursor-256x256-suspend:
pass   -> DMESG-WARN (shard-snb) fdo#103375
Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> DMESG-FAIL (shard-apl) fdo#101623
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup oa-exponents:
pass   -> INCOMPLETE (shard-apl) fdo#102254

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

shard-apltotal:3447 pass:1810 dwarn:1   dfail:1   fail:7   skip:1626 
time:11875s
shard-hswtotal:3460 pass:1766 dwarn:1   dfail:0   fail:2   skip:1690 
time:11727s
shard-snbtotal:3460 pass:1358 dwarn:2   dfail:0   fail:1   skip:2099 
time:6637s
Blacklisted hosts:
shard-kbltotal:3460 pass:1935 dwarn:1   dfail:0   fail:14  skip:1510 
time:9510s

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Michal Wajdeczko]

On Thu, 01 Mar 2018 15:47:22 +0100, Sagar Arun Kamble  
 wrote:



GuC load function is named intel_guc_fw_upload() and HuC load function is
named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.

While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()

v2: Changed patch to update HuC functions instead of changing
guc_fw_upload and update file structure. (Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/Makefile   |   3 +-
 drivers/gpu/drm/i915/intel_guc_fw.c |  10 +-
 drivers/gpu/drm/i915/intel_huc.c| 154 +-
 drivers/gpu/drm/i915/intel_huc.h|   2 +-
 drivers/gpu/drm/i915/intel_huc_fw.c | 184  


 drivers/gpu/drm/i915/intel_huc_fw.h |  33 +++
 drivers/gpu/drm/i915/intel_uc.c |   2 +-
 7 files changed, 227 insertions(+), 161 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_fw.c
 create mode 100644 drivers/gpu/drm/i915/intel_huc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile  
b/drivers/gpu/drm/i915/Makefile

index 881d712..1bd9bc5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,7 +89,8 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
- intel_huc.o
+ intel_huc.o \
+ intel_huc_fw.o
# autogenerated null render state
 i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c  
b/drivers/gpu/drm/i915/intel_guc_fw.c

index 3b09329..d07f2b9 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -269,15 +269,15 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw,  
struct i915_vma *vma)

 }
/**
- * intel_guc_fw_upload() - finish preparing the GuC for activity
+ * intel_guc_fw_upload() - load GuC uCode to device
  * @guc: intel_guc structure
  *
- * Called during driver loading and also after a GPU reset.
+ * Called from intel_uc_init_hw() during driver load, resume from sleep  
and

+ * after a GPU reset.
  *
- * The main action required here it to load the GuC uCode into the  
device.
  * The firmware image should have already been fetched into memory by  
the

- * earlier call to intel_guc_init(), so here we need only check that
- * worked, and then transfer the image to the h/w.
+ * earlier call to intel_uc_init_fw(), so here we need to only check  
that

+ * fetch succeeded, and then transfer the image to the h/w.
  *
  * Return: non-zero code on error
  */
diff --git a/drivers/gpu/drm/i915/intel_huc.c  
b/drivers/gpu/drm/i915/intel_huc.c

index ef9a05d..e37f58e 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -27,161 +27,9 @@
 #include "intel_huc.h"
 #include "i915_drv.h"
-/**
- * DOC: HuC Firmware
- *
- * Motivation:
- * GEN9 introduces a new dedicated firmware for usage in media HEVC  
(High

- * Efficiency Video Coding) operations. Userspace can use the firmware
- * capabilities by adding HuC specific commands to batch buffers.
- *
- * Implementation:
- * The same firmware loader is used as the GuC. However, the actual
- * loading to HW is deferred until GEM initialization is done.
- *
- * Note that HuC firmware loading must be done before GuC loading.
- */
-
-#define BXT_HUC_FW_MAJOR 01
-#define BXT_HUC_FW_MINOR 07
-#define BXT_BLD_NUM 1398
-
-#define SKL_HUC_FW_MAJOR 01
-#define SKL_HUC_FW_MINOR 07
-#define SKL_BLD_NUM 1398
-
-#define KBL_HUC_FW_MAJOR 02
-#define KBL_HUC_FW_MINOR 00
-#define KBL_BLD_NUM 1810
-
-#define HUC_FW_PATH(platform, major, minor, bld_num) \
-   "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
-   __stringify(minor) "_" __stringify(bld_num) ".bin"
-
-#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_HUC_FW_MAJOR, \
-   SKL_HUC_FW_MINOR, SKL_BLD_NUM)
-MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
-
-#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
-   BXT_HUC_FW_MINOR, BXT_BLD_NUM)
-MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
-
-#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_HUC_FW_MAJOR, \
-   KBL_HUC_FW_MINOR, KBL_BLD_NUM)
-MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
-
-static void huc_fw_select(struct intel_uc_fw *huc_fw)
-{
-   struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
-   struct drm_i915_private *dev_priv = huc_to_i915(huc);
-
-   GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
-
-   if (!HAS_HUC(dev_priv))
-   return;
-
-   if (i915_modparams.huc_firmware_path) {
-

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/icl: Prepare for more rings
URL   : https://patchwork.freedesktop.org/series/39102/
State : warning

== Summary ==

 Possible new issues:

Test kms_frontbuffer_tracking:
Subgroup fbc-2p-primscrn-shrfb-pgflip-blt:
pass   -> SKIP   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +2
Test kms_cursor_crc:
Subgroup cursor-64x64-suspend:
pass   -> INCOMPLETE (shard-hsw) fdo#103540
Test kms_flip:
Subgroup 2x-flip-vs-expired-vblank:
pass   -> FAIL   (shard-hsw) fdo#102887
Subgroup 2x-modeset-vs-vblank-race-interruptible:
pass   -> FAIL   (shard-hsw) fdo#103060
Subgroup 2x-wf_vblank-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-pri-shrfb-draw-pwrite:
pass   -> DMESG-FAIL (shard-apl) fdo#101623
Subgroup fbc-1p-primscrn-spr-indfb-draw-render:
pass   -> FAIL   (shard-apl) fdo#103167 +1
Test perf:
Subgroup oa-exponents:
pass   -> INCOMPLETE (shard-apl) fdo#102254

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
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
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-apltotal:3447 pass:1809 dwarn:1   dfail:1   fail:9   skip:1626 
time:11959s
shard-hswtotal:3382 pass:1723 dwarn:1   dfail:0   fail:5   skip:1651 
time:11205s
shard-snbtotal:3460 pass:1357 dwarn:3   dfail:0   fail:1   skip:2099 
time:6674s
Blacklisted hosts:
shard-kbltotal:3383 pass:1906 dwarn:1   dfail:0   fail:7   skip:1467 
time:8941s

== Logs ==

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

Re: [Intel-gfx] [PATCH i-g-t] tests/gen7_forcewake_mt: Fix test

[Tvrtko Ursulin]

On 01/03/2018 14:41, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-03-01 14:32:17)

+static void *mmio_base;
+
+static void cleanup(int sig)
+{
+   volatile uint32_t *forcewake_mt =
+   (uint32_t *)((char *)mmio_base + FORCEWAKE_MT);
+   unsigned int bit;
+
+   for (bit = 2; bit < 16; bit++) {
+   *forcewake_mt = (1 << bit) << 16;
+   if (*forcewake_mt & (1 << bit))
+   igt_warn("Failed to restore bit %u!\n", bit);
+   }


Is the exit handler called after threads are terminated... I don't think
so, my understanding are the threads are terminated by process shutdown
not libc.


Yes, my bad. At least we'll see if orderly thread exit makes any difference.

Regards,

Tvrtko

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

[Intel-gfx] [PATCH v2 1/1] drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric

[Sagar Arun Kamble]

GuC load function is named intel_guc_fw_upload() and HuC load function is
named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.

While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()

v2: Changed patch to update HuC functions instead of changing
guc_fw_upload and update file structure. (Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Winiarski 
Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/Makefile   |   3 +-
 drivers/gpu/drm/i915/intel_guc_fw.c |  10 +-
 drivers/gpu/drm/i915/intel_huc.c| 154 +-
 drivers/gpu/drm/i915/intel_huc.h|   2 +-
 drivers/gpu/drm/i915/intel_huc_fw.c | 184 
 drivers/gpu/drm/i915/intel_huc_fw.h |  33 +++
 drivers/gpu/drm/i915/intel_uc.c |   2 +-
 7 files changed, 227 insertions(+), 161 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc_fw.c
 create mode 100644 drivers/gpu/drm/i915/intel_huc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 881d712..1bd9bc5 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,7 +89,8 @@ i915-y += intel_uc.o \
  intel_guc_fw.o \
  intel_guc_log.o \
  intel_guc_submission.o \
- intel_huc.o
+ intel_huc.o \
+ intel_huc_fw.o
 
 # autogenerated null render state
 i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c 
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 3b09329..d07f2b9 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -269,15 +269,15 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw, struct 
i915_vma *vma)
 }
 
 /**
- * intel_guc_fw_upload() - finish preparing the GuC for activity
+ * intel_guc_fw_upload() - load GuC uCode to device
  * @guc: intel_guc structure
  *
- * Called during driver loading and also after a GPU reset.
+ * Called from intel_uc_init_hw() during driver load, resume from sleep and
+ * after a GPU reset.
  *
- * The main action required here it to load the GuC uCode into the device.
  * The firmware image should have already been fetched into memory by the
- * earlier call to intel_guc_init(), so here we need only check that
- * worked, and then transfer the image to the h/w.
+ * earlier call to intel_uc_init_fw(), so here we need to only check that
+ * fetch succeeded, and then transfer the image to the h/w.
  *
  * Return: non-zero code on error
  */
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index ef9a05d..e37f58e 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -27,161 +27,9 @@
 #include "intel_huc.h"
 #include "i915_drv.h"
 
-/**
- * DOC: HuC Firmware
- *
- * Motivation:
- * GEN9 introduces a new dedicated firmware for usage in media HEVC (High
- * Efficiency Video Coding) operations. Userspace can use the firmware
- * capabilities by adding HuC specific commands to batch buffers.
- *
- * Implementation:
- * The same firmware loader is used as the GuC. However, the actual
- * loading to HW is deferred until GEM initialization is done.
- *
- * Note that HuC firmware loading must be done before GuC loading.
- */
-
-#define BXT_HUC_FW_MAJOR 01
-#define BXT_HUC_FW_MINOR 07
-#define BXT_BLD_NUM 1398
-
-#define SKL_HUC_FW_MAJOR 01
-#define SKL_HUC_FW_MINOR 07
-#define SKL_BLD_NUM 1398
-
-#define KBL_HUC_FW_MAJOR 02
-#define KBL_HUC_FW_MINOR 00
-#define KBL_BLD_NUM 1810
-
-#define HUC_FW_PATH(platform, major, minor, bld_num) \
-   "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
-   __stringify(minor) "_" __stringify(bld_num) ".bin"
-
-#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_HUC_FW_MAJOR, \
-   SKL_HUC_FW_MINOR, SKL_BLD_NUM)
-MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
-
-#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_HUC_FW_MAJOR, \
-   BXT_HUC_FW_MINOR, BXT_BLD_NUM)
-MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
-
-#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_HUC_FW_MAJOR, \
-   KBL_HUC_FW_MINOR, KBL_BLD_NUM)
-MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
-
-static void huc_fw_select(struct intel_uc_fw *huc_fw)
-{
-   struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw);
-   struct drm_i915_private *dev_priv = huc_to_i915(huc);
-
-   GEM_BUG_ON(huc_fw->type != INTEL_UC_FW_TYPE_HUC);
-
-   if (!HAS_HUC(dev_priv))
-   return;
-
-   if (i915_modparams.huc_firmware_path) {
-   huc_fw->path = i915_modparams.huc_firmware_path;
-   huc_fw->major_ver_wanted = 0;
- 

Re: [Intel-gfx] [PATCH i-g-t] tests/gen7_forcewake_mt: Fix test

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-01 14:32:17)
> +static void *mmio_base;
> +
> +static void cleanup(int sig)
> +{
> +   volatile uint32_t *forcewake_mt =
> +   (uint32_t *)((char *)mmio_base + FORCEWAKE_MT);
> +   unsigned int bit;
> +
> +   for (bit = 2; bit < 16; bit++) {
> +   *forcewake_mt = (1 << bit) << 16;
> +   if (*forcewake_mt & (1 << bit))
> +   igt_warn("Failed to restore bit %u!\n", bit);
> +   }

Is the exit handler called after threads are terminated... I don't think
so, my understanding are the threads are terminated by process shutdown
not libc.
-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/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset (rev2)
URL   : https://patchwork.freedesktop.org/series/39129/
State : success

== Summary ==

Series 39129v2 drm/i915/gen9: Disable FBC on planes with a misaligned Y-offset
https://patchwork.freedesktop.org/api/1.0/series/39129/revisions/2/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
fail   -> PASS   (fi-gdg-551) fdo#102575
Test kms_chamelium:
Subgroup hdmi-hpd-fast:
fail   -> SKIP   (fi-kbl-7500u) fdo#105310 +4

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
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:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
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:482s
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:454s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:575s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:407s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:414s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:412s
fi-kbl-7500u total:288  pass:260  dwarn:0   dfail:0   fail:4   skip:24  
time:479s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:486s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:421s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:483s
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:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
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:389s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:499s

61da3e8943e4b5e643e3d72f3a925227fe4cb84c drm-tip: 2018y-03m-01d-13h-30m-46s UTC 
integration manifest
3e61c0c72b96 drm/i915/gen9, gen10: Disable FBC on planes with a misaligned 
Y-offset

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 07:58:07PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 3/1/2018 6:54 PM, Ville Syrjälä wrote:
> > On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 2/24/2018 12:55 AM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> While we want to potentially support multiple different gamma/degamma
> >>> LUT sizes we can (and should) at least check that the blob length
> >>> is a multiple of the LUT entry size.
> >> I dint understand the exact idea behind doing this, how is this going to
> >> benefit ? May be a bit more description ?
> > The benefit is rejecting garbage fed in from userspace.
> >
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>drivers/gpu/drm/drm_atomic.c | 15 +++
> >>>1 file changed, 11 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> >>> index 8945357212ba..933edec0299d 100644
> >>> --- a/drivers/gpu/drm/drm_atomic.c
> >>> +++ b/drivers/gpu/drm/drm_atomic.c
> >>> @@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct 
> >>> drm_device *dev,
> >>>struct drm_property_blob 
> >>> **blob,
> >>>uint64_t blob_id,
> >>>ssize_t expected_size,
> >>> +  ssize_t expected_size_mod,
> >>>bool *replaced)
> >>>{
> >>>   struct drm_property_blob *new_blob = NULL;
> >>> @@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct 
> >>> drm_device *dev,
> >>>   if (new_blob == NULL)
> >>>   return -EINVAL;
> >>>
> >>> - if (expected_size > 0 && expected_size != new_blob->length) {
> >>> + if (expected_size > 0 &&
> >>> + new_blob->length != expected_size) {
> >>> + drm_property_blob_put(new_blob);
> >>> + return -EINVAL;
> >>> + }
> >> One line needed here, matching the previous if() pattern
> > What line? Don't understand.
> I mean, I can see a blank line before previous if() condition, so lets 
> keep the same pattern for this if() too

OTOH the two ifs are related so maybe just keep them together? Doesn't
actually matter to me though.

> 
> - Shashank
> >>> + if (expected_size_mod > 0 &&
> >>> + new_blob->length % expected_size_mod != 0) {
> >>>   drm_property_blob_put(new_blob);
> >>>   return -EINVAL;
> >>>   }
> >>> @@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc 
> >>> *crtc,
> >>>   ret = drm_atomic_replace_property_blob_from_id(dev,
> >>>   >degamma_lut,
> >>>   val,
> >>> - -1,
> >>> + -1, sizeof(struct drm_color_lut),
> >>>   );
> >>>   state->color_mgmt_changed |= replaced;
> >>>   return ret;
> >>> @@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc 
> >>> *crtc,
> >>>   ret = drm_atomic_replace_property_blob_from_id(dev,
> >>>   >ctm,
> >>>   val,
> >>> - sizeof(struct drm_color_ctm),
> >>> + sizeof(struct drm_color_ctm), -1,
> >>>   );
> >>>   state->color_mgmt_changed |= replaced;
> >>>   return ret;
> >>> @@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc 
> >>> *crtc,
> >>>   ret = drm_atomic_replace_property_blob_from_id(dev,
> >>>   >gamma_lut,
> >>>   val,
> >>> - -1,
> >>> + -1, sizeof(struct drm_color_lut),
> >>>   );
> >>>   state->color_mgmt_changed |= replaced;
> >>>   return ret;

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

[Intel-gfx] [PATCH i-g-t] tests/gen7_forcewake_mt: Fix test

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

1.
We need to tell the compiler mmio access cannot be optimized away
(volatile).

2.
We need to ensure we don't exit with forcewake left on. Signal threads
to exit in a controlled fashion and install atexit handler just in case.

Signed-off-by: Tvrtko Ursulin 
---
50% speculation, compile tested only!
---
 tests/gen7_forcewake_mt.c | 34 +++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/tests/gen7_forcewake_mt.c b/tests/gen7_forcewake_mt.c
index 07320ef9e8ac..a2dc33bbb9dd 100644
--- a/tests/gen7_forcewake_mt.c
+++ b/tests/gen7_forcewake_mt.c
@@ -44,6 +44,7 @@ IGT_TEST_DESCRIPTION("Exercise a suspect workaround required 
for"
 
 struct thread {
pthread_t thread;
+   bool run;
void *mmio;
int fd;
int bit;
@@ -106,10 +107,11 @@ static void *igfx_get_mmio(void)
 static void *thread(void *arg)
 {
struct thread *t = arg;
-   uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
+   volatile uint32_t *forcewake_mt =
+   (uint32_t *)((char *)t->mmio + FORCEWAKE_MT);
uint32_t bit = 1 << t->bit;
 
-   while (1) {
+   while (t->run) {
*forcewake_mt = bit << 16 | bit;
igt_assert(*forcewake_mt & bit);
*forcewake_mt = bit << 16;
@@ -121,13 +123,33 @@ static void *thread(void *arg)
 
 #define MI_STORE_REGISTER_MEM   (0x24<<23)
 
+static void *mmio_base;
+
+static void cleanup(int sig)
+{
+   volatile uint32_t *forcewake_mt =
+   (uint32_t *)((char *)mmio_base + FORCEWAKE_MT);
+   unsigned int bit;
+
+   for (bit = 2; bit < 16; bit++) {
+   *forcewake_mt = (1 << bit) << 16;
+   if (*forcewake_mt & (1 << bit))
+   igt_warn("Failed to restore bit %u!\n", bit);
+   }
+}
+
 igt_simple_main
 {
struct thread t[16];
int i;
 
+   mmio_base = igfx_get_mmio();
+
t[0].fd = drm_open_driver(DRIVER_INTEL);
-   t[0].mmio = igfx_get_mmio();
+   t[0].run = true;
+   t[0].mmio = mmio_base;
+
+   igt_install_exit_handler(cleanup);
 
for (i = 2; i < 16; i++) {
t[i] = t[0];
@@ -201,4 +223,10 @@ igt_simple_main
 
usleep(1000);
}
+
+   for (i = 2; i < 16; i++)
+   t[i].run = false;
+
+   for (i = 2; i < 16; i++)
+   pthread_join(t[i].thread, NULL);
 }
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Sharma, Shashank]

Regards

Shashank


On 3/1/2018 6:54 PM, Ville Syrjälä wrote:

On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 2/24/2018 12:55 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

While we want to potentially support multiple different gamma/degamma
LUT sizes we can (and should) at least check that the blob length
is a multiple of the LUT entry size.

I dint understand the exact idea behind doing this, how is this going to
benefit ? May be a bit more description ?

The benefit is rejecting garbage fed in from userspace.


Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/drm_atomic.c | 15 +++
   1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8945357212ba..933edec0299d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
 struct drm_property_blob **blob,
 uint64_t blob_id,
 ssize_t expected_size,
+ssize_t expected_size_mod,
 bool *replaced)
   {
struct drm_property_blob *new_blob = NULL;
@@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
if (new_blob == NULL)
return -EINVAL;
   
-		if (expected_size > 0 && expected_size != new_blob->length) {

+   if (expected_size > 0 &&
+   new_blob->length != expected_size) {
+   drm_property_blob_put(new_blob);
+   return -EINVAL;
+   }

One line needed here, matching the previous if() pattern

What line? Don't understand.
I mean, I can see a blank line before previous if() condition, so lets 
keep the same pattern for this if() too


- Shashank

+   if (expected_size_mod > 0 &&
+   new_blob->length % expected_size_mod != 0) {
drm_property_blob_put(new_blob);
return -EINVAL;
}
@@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>ctm,
val,
-   sizeof(struct drm_color_ctm),
+   sizeof(struct drm_color_ctm), -1,
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>gamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;


___
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: don't leak the pin_map on error (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: don't leak the pin_map on error (rev2)
URL   : https://patchwork.freedesktop.org/series/39207/
State : success

== Summary ==

Series 39207v2 drm/i915: don't leak the pin_map on error
https://patchwork.freedesktop.org/api/1.0/series/39207/revisions/2/mbox/

 Known issues:

Test kms_chamelium:
Subgroup hdmi-hpd-fast:
fail   -> SKIP   (fi-kbl-7500u) fdo#105310 +4
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:419s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:479s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
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:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:407s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
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:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:260  dwarn:0   dfail:0   fail:4   skip:24  
time:482s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:451s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:489s
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:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
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:492s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
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:519s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:496s

61da3e8943e4b5e643e3d72f3a925227fe4cb84c drm-tip: 2018y-03m-01d-13h-30m-46s UTC 
integration manifest
f4d55bef5760 drm/i915: don't leak the pin_map on error

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8198/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/gen9, gen10: Disable FBC on planes with a misaligned Y-offset

[Imre Deak]

Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may
cause pipe FIFO underruns and flickers, so disable FBC on such a config.

I tried the followings to work around the issue:
- enable each HW work around in ILK_DPFC_CHICKEN
- disable each compression algorithm in ILK_DPFC_CONTROL
- disable low-power watermarks
None of the above got rid of the problem. I haven't found this issue in
the Bspec/WA database either.

Besides the igt testcase below (yet to be merged) an easy way to
reproduce the issue is to enable a plane with FBC and a plane Y-offset
not aligned to 4 and then just enable/disable FBC in a loop, keeping the
plane enabled.

I could trigger the problem on BXT/GLK/SKL/CNL, so assume for now that it's
only present on GEN9 and GEN10.

v2: (Ville)
- Run the test/apply the WA on CNL as well.
- Use IS_GEN() instead of INTEL_GEN().
- Fix spelling.

Cc: Paulo Zanoni 
Cc: Ville Syrjälä 
Testcase: igt/kms_plane/plane-clipping-pipe-A-planes
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_fbc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 38b036c499d9..d225de828f38 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -859,6 +859,16 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
 
+   /*
+* Work around a problem on GEN9+ HW, where enabling FBC on a plane
+* having a Y offset that isn't divisible by 4 causes FIFO underrun
+* and screen flicker.
+*/
+   if (IS_GEN(dev_priv, 9, 10) && (fbc->state_cache.plane.adjusted_y & 3)) 
{
+   fbc->no_fbc_reason = "plane Y offset is misaligned";
+   return false;
+   }
+
return true;
 }
 
-- 
2.13.2

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

Re: [Intel-gfx] [PATCH v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Michal Wajdeczko]

On Thu, 01 Mar 2018 02:01:39 +0100, Jackie Li  wrote:

GuC WOPCM registers are write-once registers. Current driver code  
accesses
these registers without checking the accessibility to these registers  
which

will lead to unpredictable driver behaviors if these registers were touch
by other components (such as faulty BIOS code).

This patch moves the GuC WOPCM registers updating code into
intel_guc_wopcm.c and adds check before and after the update to GuC WOPCM


s/intel_guc_wopcm/intel_wopcm
s/before and after/after


registers so that we can make sure the driver is in a known state before
and after writing to these write-once registers.

v6:
 - Made sure module reloading won't bug the kernel while doing
   locking status checking

v7:
 - Fixed patch format issues

v8:
 - Fixed coding style issue on register lock bit macro definition (Sagar)

v9:
 - Avoided to use redundant !! to cast uint to bool (Chris)
 - Return error code instead of GEM_BUG_ON for locked with invalid  
register

   values case (Sagar)
 - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
 - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
   WOPCM offset register based on the presence of HuC firmware (Michal)
 - Use bit fields instead of macros for GuC WOPCM flags (Michal)

v10:
 - Refined variable names, removed redundant comments (Joonas)
 - Introduced lockable_reg to handle the write once register write and
   propagate the write error to caller (Joonas)
 - Used lockable_reg abstraction to avoid locking bit check on generic
   i915_reg_t (Michal)
 - Added log message for error paths (Michal)
 - Removed hw_updated flag and only relies on real hardware status

v11:
 - Replaced lockable_reg with simplified function (Michal)
 - Used new macros for locking bits of WOPCM size/offset registers  
instead

   of using BIT(0) directly (Michal)
 - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC
   WOPCM register setup instead of calling from intel_uc_init_hw()  
(Michal)


BSpec: 10875, 10833

Cc: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/i915_gem.c  |  6 
 drivers/gpu/drm/i915/intel_guc_reg.h |  3 ++
 drivers/gpu/drm/i915/intel_uc.c  |  5 ---
 drivers/gpu/drm/i915/intel_wopcm.c   | 63  


 drivers/gpu/drm/i915/intel_wopcm.h   |  1 +
 5 files changed, 73 insertions(+), 5 deletions(-)

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

index d31ad0b..662d670 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5122,6 +5122,12 @@ int i915_gem_init_hw(struct drm_i915_private  
*dev_priv)

goto out;
}
+   ret = intel_wopcm_init_hw(_priv->wopcm);
+   if (ret) {
+   DRM_ERROR("Enabling WOPCM failed (%d)\n", ret);
+   goto out;
+   }
+
/* We can't enable contexts until all firmware is loaded */
ret = intel_uc_init_hw(dev_priv);
if (ret) {
diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h  
b/drivers/gpu/drm/i915/intel_guc_reg.h

index 01963d0..d860847 100644
--- a/drivers/gpu/drm/i915/intel_guc_reg.h
+++ b/drivers/gpu/drm/i915/intel_guc_reg.h
@@ -66,15 +66,18 @@
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   GUC_WOPCM_OFFSET_VALID (1<<0)
 #define   HUC_LOADING_AGENT_VCR  (0<<1)
 #define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_SHIFT   14
+#define   GUC_WOPCM_OFFSET_MASK  (0x3 << 
GUC_WOPCM_OFFSET_SHIFT)
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
#define HUC_STATUS2 _MMIO(0xD3B0)
 #define   HUC_FW_VERIFIED   (1<<7)
#define GUC_WOPCM_SIZE  _MMIO(0xc050)
+#define   GUC_WOPCM_SIZE_LOCKED  (1<<0)
 #define   GUC_WOPCM_SIZE_SHIFT 12
 #define   GUC_WOPCM_SIZE_MASK(0xf << GUC_WOPCM_SIZE_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_uc.c  
b/drivers/gpu/drm/i915/intel_uc.c

index 964e49f..58186f2 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -341,11 +341,6 @@ int intel_uc_init_hw(struct drm_i915_private  
*dev_priv)

guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
-   /* init WOPCM */
-   I915_WRITE(GUC_WOPCM_SIZE, dev_priv->wopcm.guc.size);
-   I915_WRITE(DMA_GUC_WOPCM_OFFSET,
-  dev_priv->wopcm.guc.base | HUC_LOADING_AGENT_GUC);
-
/* WaEnableuKernelHeaderValidFix:skl */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
if (IS_GEN9(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c  

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 06:43:21PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 2/24/2018 12:55 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> >
> > While we want to potentially support multiple different gamma/degamma
> > LUT sizes we can (and should) at least check that the blob length
> > is a multiple of the LUT entry size.
> I dint understand the exact idea behind doing this, how is this going to 
> benefit ? May be a bit more description ?

The benefit is rejecting garbage fed in from userspace.

> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/drm_atomic.c | 15 +++
> >   1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 8945357212ba..933edec0299d 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct 
> > drm_device *dev,
> >  struct drm_property_blob **blob,
> >  uint64_t blob_id,
> >  ssize_t expected_size,
> > +ssize_t expected_size_mod,
> >  bool *replaced)
> >   {
> > struct drm_property_blob *new_blob = NULL;
> > @@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct 
> > drm_device *dev,
> > if (new_blob == NULL)
> > return -EINVAL;
> >   
> > -   if (expected_size > 0 && expected_size != new_blob->length) {
> > +   if (expected_size > 0 &&
> > +   new_blob->length != expected_size) {
> > +   drm_property_blob_put(new_blob);
> > +   return -EINVAL;
> > +   }
> One line needed here, matching the previous if() pattern

What line? Don't understand.

> > +   if (expected_size_mod > 0 &&
> > +   new_blob->length % expected_size_mod != 0) {
> > drm_property_blob_put(new_blob);
> > return -EINVAL;
> > }
> > @@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >degamma_lut,
> > val,
> > -   -1,
> > +   -1, sizeof(struct drm_color_lut),
> > );
> > state->color_mgmt_changed |= replaced;
> > return ret;
> > @@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >ctm,
> > val,
> > -   sizeof(struct drm_color_ctm),
> > +   sizeof(struct drm_color_ctm), -1,
> > );
> > state->color_mgmt_changed |= replaced;
> > return ret;
> > @@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >gamma_lut,
> > val,
> > -   -1,
> > +   -1, sizeof(struct drm_color_lut),
> > );
> > state->color_mgmt_changed |= replaced;
> > return ret;

-- 
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 v11 4/6] drm/i915: Add HuC firmware size related restriction for Gen9 and CNL A0

[Michal Wajdeczko]

On Thu, 01 Mar 2018 02:01:38 +0100, Jackie Li  wrote:


On CNL A0 and Gen9, there's a hardware restriction that requires the
available GuC WOPCM size to be larger than or equal to HuC firmware size.

This patch adds new verification code to ensure the available GuC WOPCM
size to be larger than or equal to HuC firmware size on both Gen9 and CNL
A0.

v6:
 - Extended HuC FW size check against GuC WOPCM size to all
   Gen9 and CNL A0 platforms

v7:
 - Fixed patch format issues

v8:
 - Renamed variables and functions to avoid ambiguity (Joonas)
 - Updated commit message and comments to be more comprehensive (Sagar)

v9:
 - Moved code that is not related to restriction check into a separate
   patch and updated the commit message accordingly (Sagar/Michal)
 - Avoided to call uc_get_fw_size for better layer isolation (Michal)

v10:
 - Shorten function names and reorganized size_check code to have clear
   isolation (Joonas)
 - Removed unnecessary comments (Joonas)

v11:
 - Fixed logic error in size check (Michal)

BSpec: 10875

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: John Spotswood 
Cc: Jeff McGee 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

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

index bb78043..b30d7ff 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -107,8 +107,26 @@ static inline int gen9_check_dword_gap(u32  
guc_wopcm_base, u32 guc_wopcm_size)

return 0;
 }
+static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32  
huc_fw_size)

+{
+   /*
+* On Gen9 & CNL A0, hardware requires the total available GuC WOPCM
+* size to be larger than or equal to HuC firmware size. Otherwise,
+* firmware uploading would fail.
+*/
+   if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) {
+   DRM_ERROR("HuC fw(%uKiB) won't fit in GuC WOPCM(%uKiB).\n",
+ huc_fw_size / 1024,
+ (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024);


bikeshed: in earlier patches in similar error messages, you used
"HuC FW (%KiB)" and didn't provide available space. Maybe simplest
way to unify and minimize the code is to add one "failed" tag in
wopcm_init function where you can print all values used for partitioning:

failed:
	DRM_ERROR("Failed to partition %uKiB WOPCM (%d)\n", wopcm->size/1024,  
err);

DRM_ERROR("HuC FW size=%uKiB\n", ...);
DRM_ERROR("GuC FW size=%uKiB\n", ...);
return err;


+   return -E2BIG;
+   }
+
+   return 0;
+}
+
 static inline int check_hw_restriction(struct drm_i915_private *i915,
-  u32 guc_wopcm_base, u32 guc_wopcm_size)
+  u32 guc_wopcm_base, u32 guc_wopcm_size,
+  u32 huc_fw_size)
 {
int err = 0;
@@ -117,7 +135,10 @@ static inline int check_hw_restriction(struct  
drm_i915_private *i915,

if (err)
return err;
-   return 0;
+   if (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))
+   err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size);
+
+   return err;
 }
/**
@@ -186,7 +207,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return -E2BIG;
}
-   err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size);
+   err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+  huc_fw_size);
if (err) {
DRM_ERROR("Failed to meet HW restriction.\n");
return err;


but bikeshed is not critical, so

Reviewed-by: Michal Wajdeczko 
___
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/perf: fix perf stream opening lock (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: fix perf stream opening lock (rev2)
URL   : https://patchwork.freedesktop.org/series/39112/
State : success

== Summary ==

Series 39112v2 drm/i915/perf: fix perf stream opening lock
https://patchwork.freedesktop.org/api/1.0/series/39112/revisions/2/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
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-c:
dmesg-warn -> PASS   (fi-cnl-y3) fdo#104951
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:490s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:475s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:452s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:389s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:573s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:402s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:289s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:406s
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:410s
fi-kbl-7500u total:288  pass:260  dwarn:0   dfail:0   fail:9   skip:19  
time:425s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:490s
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:425s
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:521s
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:478s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s
Blacklisted hosts:
fi-cfl-u total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:498s

412f3a76adc8967613b219df785a979b510a205e drm-tip: 2018y-03m-01d-12h-19m-34s UTC 
integration manifest
3244f7b252b5 drm/i915/perf: fix perf stream opening lock

== Logs ==

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

Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

[Sharma, Shashank]

Regards

Shashank


On 2/24/2018 12:55 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

While we want to potentially support multiple different gamma/degamma
LUT sizes we can (and should) at least check that the blob length
is a multiple of the LUT entry size.
I dint understand the exact idea behind doing this, how is this going to 
benefit ? May be a bit more description ?


Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/drm_atomic.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8945357212ba..933edec0299d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -413,6 +413,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
 struct drm_property_blob **blob,
 uint64_t blob_id,
 ssize_t expected_size,
+ssize_t expected_size_mod,
 bool *replaced)
  {
struct drm_property_blob *new_blob = NULL;
@@ -422,7 +423,13 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
if (new_blob == NULL)
return -EINVAL;
  
-		if (expected_size > 0 && expected_size != new_blob->length) {

+   if (expected_size > 0 &&
+   new_blob->length != expected_size) {
+   drm_property_blob_put(new_blob);
+   return -EINVAL;
+   }

One line needed here, matching the previous if() pattern

+   if (expected_size_mod > 0 &&
+   new_blob->length % expected_size_mod != 0) {
drm_property_blob_put(new_blob);
return -EINVAL;
}
@@ -470,7 +477,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -478,7 +485,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>ctm,
val,
-   sizeof(struct drm_color_ctm),
+   sizeof(struct drm_color_ctm), -1,
);
state->color_mgmt_changed |= replaced;
return ret;
@@ -486,7 +493,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
ret = drm_atomic_replace_property_blob_from_id(dev,
>gamma_lut,
val,
-   -1,
+   -1, sizeof(struct drm_color_lut),
);
state->color_mgmt_changed |= replaced;
return ret;


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

Re: [Intel-gfx] [PATCH v11 3/6] drm/i915: Add support to return CNL specific reserved WOPCM size

[Michal Wajdeczko]

On Thu, 01 Mar 2018 02:01:37 +0100, Jackie Li  wrote:


CNL has its specific reserved GuC WOPCM size for RC6 and other hardware
contexts.

This patch updates the code to return CNL specific reserved GuC WOPCM  
size

for RC6 and other hardware contexts so that the GuC WOPCM size can be
calculated correctly for CNL.

v9:
 - Created a new patch for these changes originally made in v8 4/6 patch  
of

   this series (Sagar/Michal)

v10:
 - Used if-else ladder to the returning of context sizes (Joonas)

v11:
 - Removed GUC_ prefix from context size macro (Michal)

Bspec: 12690

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


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

Re: [Intel-gfx] [PATCH v11 2/6] drm/i915: Implement dynamic GuC WOPCM offset and size calculation

[Michal Wajdeczko]

On Thu, 01 Mar 2018 02:01:36 +0100, Jackie Li  wrote:


Hardware may have specific restrictions on GuC WOPCM offset and size. On
Gen9, the value of the GuC WOPCM size register needs to be larger than  
the

value of GuC WOPCM offset register + a Gen9 specific offset (144KB) for
reserved GuC WOPCM. Fail to enforce such a restriction on GuC WOPCM size
will lead to GuC firmware execution failures. On the other hand, with
current static GuC WOPCM offset and size values (512KB for both offset  
and
size), the GuC WOPCM size verification will fail on Gen9 even if it can  
be

fixed by lowering the GuC WOPCM offset by calculating its value based on
HuC firmware size (which is likely less than 200KB on Gen9), so that we  
can

have a GuC WOPCM size value which is large enough to pass the GuC WOPCM
size check.

This patch updates the reserved GuC WOPCM size for RC6 context on Gen9 to
24KB to strictly align with the Gen9 GuC WOPCM layout. It also adds  
support

to verify the GuC WOPCM size aganist the Gen9 hardware restrictions. To
meet all above requirements, let's provide dynamic partitioning of the
WOPCM that will be based on platform specific HuC/GuC firmware sizes.

v2:
 - Removed intel_wopcm_init (Ville/Sagar/Joonas)
 - Renamed and Moved the intel_wopcm_partition into intel_guc (Sagar)
 - Removed unnecessary function calls (Joonas)
 - Init GuC WOPCM partition as soon as firmware fetching is completed

v3:
 - Fixed indentation issues (Chris)
 - Removed layering violation code (Chris/Michal)
 - Created separat files for GuC wopcm code  (Michal)
 - Used inline function to avoid code duplication (Michal)

v4:
 - Preset the GuC WOPCM top during early GuC init (Chris)
 - Fail intel_uc_init_hw() as soon as GuC WOPCM partitioning failed

v5:
 - Moved GuC DMA WOPCM register updating code into intel_wopcm.c
 - Took care of the locking status before writing to GuC DMA
   Write-Once registers. (Joonas)

v6:
 - Made sure the GuC WOPCM size to be multiple of 4K (4K aligned)

v8:
 - Updated comments and fixed naming issues (Sagar/Joonas)
 - Updated commit message to include more description about the hardware
   restriction on GuC WOPCM size (Sagar)

v9:
 - Minor changes variable names and code comments (Sagar)
 - Added detailed GuC WOPCM layout drawing (Sagar/Michal)
 - Refined macro definitions to be reader friendly (Michal)
 - Removed redundent check to valid flag (Michal)
 - Unified first parameter for exported GuC WOPCM functions (Michal)
 - Refined the name and parameter list of hardware restriction checking
   functions (Michal)

v10:
 - Used shorter function name for internal functions (Joonas)
 - Moved init-ealry function into c file (Joonas)
 - Consolidated and removed redundant size checks (Joonas/Michal)
 - Removed unnecessary unlikely() from code which is only called once
   during boot (Joonas)
 - More fixes to kernel-doc format and content (Michal)
 - Avoided the use of PAGE_MASK for 4K pages (Michal)
 - Added error log messages to error paths (Michal)

v11:
 - Replaced intel_guc_wopcm with more generic intel_wopcm and attached
   intel_wopcm to drm_i915_private instead intel_guc (Michal)
 - dynamic calculation of GuC non-wopcm memory start (a.k.a WOPCM Top
   offset from GuC WOPCM base) (Michal)
 - Moved WOPCM marco definitions into .c source file (Michal)
 - Exported WOPCM layout diagram as kernel-doc (Michal)

Bspec: 12690

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---
 drivers/gpu/drm/i915/Makefile   |   3 +-
 drivers/gpu/drm/i915/i915_drv.c |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   8 ++
 drivers/gpu/drm/i915/i915_gem.c |   4 +
 drivers/gpu/drm/i915/i915_gem_context.c |   5 +-
 drivers/gpu/drm/i915/intel_guc.c|  66 ---
 drivers/gpu/drm/i915/intel_guc.h|  16 ++-
 drivers/gpu/drm/i915/intel_guc_reg.h|   8 +-
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c |   6 +-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  13 +--
 drivers/gpu/drm/i915/intel_uc_fw.h  |  16 +++
 drivers/gpu/drm/i915/intel_wopcm.c  | 195  


 drivers/gpu/drm/i915/intel_wopcm.h  |  34 ++
 14 files changed, 337 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_wopcm.c
 create mode 100644 drivers/gpu/drm/i915/intel_wopcm.h

diff --git a/drivers/gpu/drm/i915/Makefile  
b/drivers/gpu/drm/i915/Makefile

index 

Re: [Intel-gfx] [PATCH 3/4] drm/i915/icl: Prepare for more rings

[Mika Kuoppala]

Mika Kuoppala  writes:

> From: Tvrtko Ursulin 
>
> Gen11 will add more VCS and VECS rings so prepare the
> infrastructure to support that.
>
> Bspec: 7021
>
> v2: Rebase.
> v3: Rebase.
> v4: Rebase.
> v5: Rebase.
> v6:
>   - Update for POR changes. (Daniele Ceraolo Spurio)
>   - Add provisional guc engine ids - to be checked and confirmed.
> v7:
>   - Rebased.
>   - Added the new ring masks.
>   - Added the new HW ids.
> v8:
>   - Introduce I915_MAX_VCS/VECS to avoid magic numbers (Michal)
>
> v9: increase MAX_ENGINE_INSTANCE to 3
>
> Cc: Michal Wajdeczko 
> Signed-off-by: Tvrtko Ursulin 
> Signed-off-by: Rodrigo Vivi 
> Signed-off-by: Oscar Mateo 
> Signed-off-by: Daniele Ceraolo Spurio 
> Reviewed-by: Oscar Mateo 

Pushed. Thanks for patch and review.
-Mika
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915/icl: Interrupt handling

[Mika Kuoppala]

Paulo Zanoni  writes:

> Em Ter, 2018-02-27 às 11:51 -0800, Daniele Ceraolo Spurio escreveu:
>> 
>> On 20/02/18 07:37, Mika Kuoppala wrote:
>> > v2: Rebase.
>> > 
>> > v3:
>> >* Remove DPF, it has been removed from SKL+.
>> >* Fix -internal rebase wrt. execlists interrupt handling.
>> > 
>> > v4: Rebase.
>> > 
>> > v5:
>> >* Updated for POR changes. (Daniele Ceraolo Spurio)
>> >* Merged with irq handling fixes by Daniele Ceraolo Spurio:
>> >* Simplify the code by using gen8_cs_irq_handler.
>> >* Fix interrupt handling for the upstream kernel.
>> > 
>> > v6:
>> >* Remove early bringup debug messages (Tvrtko)
>> >* Add NB about arbitrary spin wait timeout (Tvrtko)
>> > 
>> > v7 (from Paulo):
>> >* Don't try to write RO bits to registers.
>> >* Don't check for PCH types that don't exist. PCH interrupts are
>> > not
>> >  here yet.
>> > 
>> > v9:
>> >* squashed in selector and shared register handling (Daniele)
>> >* skip writing of irq if data is not valid (Daniele)
>> >* use time_after32 (Chris)
>> >* use I915_MAX_VCS and I915_MAX_VECS (Daniele)
>> >* remove fake pm interrupt handling for later patch (Mika)
>> > 
>> > v10:
>> >* Direct processing of banks. clear banks early (Chris)
>> >* remove poll on valid bit, only clear valid bit (Mika)
>> >* use raw accessors, better naming (Chris)
>> > 
>> > v11:
>> >* adapt to raw_reg_[read|write]
>> >* bring back polling the valid bit (Daniele)
>> > 
>> > Cc: Tvrtko Ursulin 
>> > Cc: Daniele Ceraolo Spurio 
>> > Cc: Chris Wilson 
>> > Cc: Oscar Mateo 
>> > Signed-off-by: Tvrtko Ursulin 
>> > Signed-off-by: Rodrigo Vivi 
>> > Signed-off-by: Daniele Ceraolo Spurio > > com>
>> > Signed-off-by: Oscar Mateo 
>> > Signed-off-by: Paulo Zanoni 
>> > Signed-off-by: Mika Kuoppala 
>> > ---
>> >   drivers/gpu/drm/i915/i915_irq.c | 229
>> > 
>> >   drivers/gpu/drm/i915/intel_pm.c |   7 +-
>> >   2 files changed, 235 insertions(+), 1 deletion(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index 17de6cef2a30..a79f47ac742a 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct
>> > drm_i915_private *dev_priv)
>> >if (READ_ONCE(rps->interrupts_enabled))
>> >return;
>> >   
>> > +  if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
>> > +  return;
>> > +
>> >spin_lock_irq(_priv->irq_lock);
>> >WARN_ON_ONCE(rps->pm_iir);
>> >WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & dev_priv-
>> > >pm_rps_events);
>> > @@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct
>> > drm_i915_private *dev_priv)
>> >if (!READ_ONCE(rps->interrupts_enabled))
>> >return;
>> >   
>> > +  if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
>> > +  return;
>> > +
>> >spin_lock_irq(_priv->irq_lock);
>> >rps->interrupts_enabled = false;
>> >   
>> > @@ -2755,6 +2761,150 @@ static void __fini_wedge(struct wedge_me
>> > *w)
>> > (W)->i915; 
>> >\
>> > __fini_wedge((W)))
>> >   
>> > +static __always_inline void
>> > +gen11_cs_irq_handler(struct intel_engine_cs * const engine, const
>> > u32 iir)
>> > +{
>> > +  gen8_cs_irq_handler(engine, iir, 0);
>> > +}
>> > +
>> > +static void
>> > +gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
>> > +  const unsigned int bank,
>> > +  const unsigned int engine_n,
>> > +  const u16 iir)
>> > +{
>> > +  struct intel_engine_cs ** const engine = i915->engine;
>> > +
>> > +  switch (bank) {
>> > +  case 0:
>> > +  switch (engine_n) {
>> > +
>> > +  case GEN11_RCS0:
>> > +  return gen11_cs_irq_handler(engine[RCS],
>> > iir);
>> > +
>> > +  case GEN11_BCS:
>> > +  return gen11_cs_irq_handler(engine[BCS],
>> > iir);
>> > +  }
>> > +  case 1:
>> > +  switch (engine_n) {
>> > +
>> > +  case GEN11_VCS(0):
>> > +  return
>> > gen11_cs_irq_handler(engine[_VCS(0)], iir);
>> > +  case GEN11_VCS(1):
>> > +  return
>> > gen11_cs_irq_handler(engine[_VCS(1)], iir);
>> > +  case GEN11_VCS(2):
>> > +  return
>> > gen11_cs_irq_handler(engine[_VCS(2)], iir);
>> > +  case GEN11_VCS(3):
>> > +  return
>> > gen11_cs_irq_handler(engine[_VCS(3)], iir);
>> > +
>> > +  case GEN11_VECS(0):
>> > +  return
>> > gen11_cs_irq_handler(engine[_VECS(0)], iir);
>> > +  

Re: [Intel-gfx] [PATCH] drm/i915/guc: Removed unused GuC parameters.

[Sagar Arun Kamble]

On 3/1/2018 1:32 PM, Chris Wilson wrote:

Quoting Michel Thierry (2018-02-28 22:07:51)

On 28/02/18 12:26, Michel Thierry wrote:

On 28/02/18 10:42, Piotr Piórkowski wrote:

In the i915 driver, there is a function, intel_guc_init_params(),
which initializes the GuC parameter block which is passed into
the GuC. There is parameter GUC_CTL_DEVICE_INFO with values
GfxGtType and GfxCoreFamily unused by GuC.

This patch remove GUC_CTL_DEVICE_INFO with GfxGtType and
GfxCoreFamily parameters and also unnecessary functions
get_gt_type() and get_core_family().


Hi,

Looking at the fw code, you're partially right, GfxGtType is ignored...
but GfxCoreFamily isn't.


Unless whoever wrote the fw was smart enough to forget to call the
function that is reading GfxCoreFamily... I didn't count on that.

Is the intention to use GfxCoreFamily documented, i.e. are they
expecting it part of the interface and may re-instantiate the check
"because it was always supposed to exist" in some future version?
Usage of GfxCoreFamily is only in SLPC and for platform specific 
initialization and might be removed in future interfaces.

If needed, we can add as part of SLPC patches.

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


--
Thanks,
Sagar

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

[Patchwork]

== Series Details ==

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

== Summary ==

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

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
pass   -> INCOMPLETE (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:413s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:429s
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:490s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
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:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:389s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:290s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:384s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:450s
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:448s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:590s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:427s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:495s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:522s
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:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

cbdd6b720f3f7d315a60dc220e4269206faa0944 drm-tip: 2018y-03m-01d-10h-44m-15s UTC 
integration manifest
941bfc3d7c79 drm/i915: Replace open-coded wait-for loop

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: don't leak the pin_map on error

[Matthew Auld]

Add some onion to populate_lr_context.

v2: prefer err_unpin_ctx
drop the fixes tag, worst case we just spew a warn before everything
is cleaned up and balance is restored

Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_lrc.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 14288743909f..8b232926a05c 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2318,8 +2318,10 @@ populate_lr_context(struct i915_gem_context *ctx,
 
defaults = i915_gem_object_pin_map(engine->default_state,
   I915_MAP_WB);
-   if (IS_ERR(defaults))
-   return PTR_ERR(defaults);
+   if (IS_ERR(defaults)) {
+   ret = PTR_ERR(defaults);
+   goto err_unpin_ctx;
+   }
 
memcpy(vaddr + start, defaults + start, engine->context_size);
i915_gem_object_unpin_map(engine->default_state);
@@ -2337,9 +2339,9 @@ populate_lr_context(struct i915_gem_context *ctx,
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
   CTX_CTRL_ENGINE_CTX_SAVE_INHIBIT);
 
+err_unpin_ctx:
i915_gem_object_unpin_map(ctx_obj);
-
-   return 0;
+   return ret;
 }
 
 static int execlists_context_deferred_alloc(struct i915_gem_context *ctx,
-- 
2.14.3

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 12:51:45PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> > 
> > 
> > 
> > On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > > >>> _post_plane_update()
> > > > > > >>> takes care of flushing when a flip is scheduled, this should be
> > > > > > >>> sufficient for PSR and FBC.
> > > > > > >> Makes sense.
> > > > > > >>  
> > > > > > > I also think this might speed up the flips a bit by avoiding 
> > > > > > > flushes. 
> > > > > > >
> > > > > > >>> Cc: Paulo Zanoni 
> > > > > > >>> Cc: Ville Syrjälä 
> > > > > > >>> Cc: Chris Wilson 
> > > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > > >>> 
> > > > > > >> Also
> > > > > > >> Cc: Maarten Lankhorst 
> > > > > > >> to validate the flow through atomic.
> > > > > > >> -Chris
> > > > > > >>
> > > > > > Page flips used to do intel_frontbuffer_flip_prepare here, followed 
> > > > > > by intel_frontbuffer_flip_complete. I think it would make sense to 
> > > > > > change the patch to do that?
> > > > > > 
> > > > > 
> > > > > I have no context why it was removed, I'll have to understand that
> > > > > change and get back to you.
> > > > 
> > > > Since we supposedly have hw nuke for both fbc and psr there doesn't seem
> > > > to be much need to do anything for flips. I guess DRRS is the only
> > > > thing that kinda needs it (not really, just avoids flipping with the
> > > > slow timings). But I think DRRS should really be tied into the vblank
> > > > stuff somehow so that we switch to the fast timings whenever a vblank
> > > > interrupts are enabled.
> > > 
> > > Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> > > (ie. main link off) I think we'd basically need to do a full modeset
> > > when exiting PSR, so it should probably handled somewhere higher up
> > > during modeset, and for other uses the frontbuffer tracking
> > > should perhaps just schedule a work to do the full modeset.
> > > 
> > The mention of "full modeset" got me thinking. I believe you said full
> > modeset because the link needs to be trained on PSR exit if it was off.
> > But, link off isn't supported on VLV/CHV
> > 
> > else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > /* On VLV and CHV only standby mode is supported. */
> > dev_priv->psr.link_standby = true;
> 
> I think that's just because we've been lazy and done it. I think even
> with the link off we'd need to reprogram all planes at least.

Not had coffee yet today, and it shows. Let me rewrite that entire thing:

I think that's just because we've been lazy and not done it (link off mode).
I think even without the link off we'd need to reprogram all planes at least.

-- 
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 igt 4/5] igt/gem_exec_capture: Exercise readback of userptr

[Michał Winiarski]

On Wed, Feb 28, 2018 at 03:51:37PM +, Chris Wilson wrote:
> EXEC_OBJECT_CAPTURE extends the type of buffers we may read during error
> capture. Previously we knew that we would only see batch buffers (which
> limited the objects to being from gem_create()), but now we need to
> check that any buffer the user can create can be read. The first
> alternate buffer type is a userptr.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  tests/gem_exec_capture.c | 35 ---
>  1 file changed, 32 insertions(+), 3 deletions(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 vs checkpatch

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 12:43:22PM +0200, Jani Nikula wrote:
> On Thu, 01 Mar 2018, Arkadiusz Hiler  wrote:
> > Since not so long ago our CI is running and reporting sparse and
> > checkpatch. Sparse is doing just fine but I had to disable checkpatch
> > for the time being - too much "false" positives causing people to
> > complain. It's simply confusing to see one thing in the code, and
> > fitting your change in only to get a report that it's wrong.
> >
> > We are explicitly going against couple of the recommendations it tries
> > to enforce, e.g. not using BIT macro, splitting quoted strings:
> > https://lists.freedesktop.org/archives/intel-gfx/2018-February/156613.html
> >
> > IMHO we should make a couple of decisions here:
> >  1. Do we really want to use the checkpatch / have CI reports?
> 
> I think yes, for the benefit of both patch authors and reviewers. For
> the most part, we do want to encourage uniform style.
> 
> >  2. Which of the checkpatch checks we want to disabled for i915?
> 
> One low hanging fruit is to ignore the CHECK messages, or drop the
> --strict option to checkpatch.pl in CI, although I think some of them
> are nice.

IMO the strict vs. not split is totally arbitrary. Some really obviously
correct warning are only enabled with strict, whereas even w/o strict
you get some warnings that are just plain silly. Thus I think strict
does more good than harm.

> 
> >  3. How strongly do we want to enforce the rest?
> 
> That's a tough one. With code movement, you want the code to remain the
> same instead of changing at the same time. And some of the warnings are
> subjective. For example, I'd prefer to stick with the 80 column rule but
> only when it makes sense. ;)
> 
> Another example, I would like to move towards kernel types over uint8_t
> and friends. However, when you have code surrounded by uint8_t and
> friends, it's often better to stick with the style around you.
> 
> >  4. Do we want to change what's already in the tree, for compliance?
> 
> No. I don't think we should encourage mindless checkpatch fixes.
> 
> Does checkpatch support disabling checks or do you have to filter them
> out from the output?
> 
> BR,
> Jani.
> 
> 
> >
> > Recent-ish drm-tip, vanilla checkpatch on i915 reports:
> > total: 399 errors, 3573 warnings, 209374 lines checked
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dim-tools mailing list
> dim-to...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools

-- 
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] sna/uxa: Fix colormap handling at screen depth 30.

[Ville Syrjälä]

On Thu, Mar 01, 2018 at 02:20:48AM +0100, Mario Kleiner wrote:
> The various clut handling functions like a setup
> consistent with the x-screen color depth. Otherwise
> we observe improper sampling in the gamma tables
> at depth 30.
> 
> Therefore replace hard-coded bitsPerRGB = 8 by actual
> bits per channel scrn->rgbBits. Also use this for call
> to xf86HandleColormaps().
> 
> Tested for uxa and sna at depths 8, 16, 24 and 30 on
> IvyBridge, and tested at depth 24 and 30 that xgamma
> and gamma table animations work, and with measurement
> equipment to make sure identity gamma ramps actually
> are identity mappings at the output.

You mean identity mapping at 8bpc? We don't support higher precision
gamma on pre-bdw atm, and the ddx doesn't use the higher precision
stuff even on bdw+. I'm working on fixing both, but it turned out to
be a bit more work than I anticipated so will take a while.

> 
> Signed-off-by: Mario Kleiner 
> ---
>  src/sna/sna_driver.c   | 5 +++--
>  src/uxa/intel_driver.c | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c
> index 2643e6c..9c4bcd4 100644
> --- a/src/sna/sna_driver.c
> +++ b/src/sna/sna_driver.c
> @@ -1145,7 +1145,7 @@ sna_screen_init(SCREEN_INIT_ARGS_DECL)
>   if (!miInitVisuals(, , , , ,
>  ,
>  ((unsigned long)1 << (scrn->bitsPerPixel - 1)),
> -8, -1))
> +scrn->rgbBits, -1))
>   return FALSE;
>  
>   if (!miScreenInit(screen, NULL,
> @@ -1217,7 +1217,8 @@ sna_screen_init(SCREEN_INIT_ARGS_DECL)
>   return FALSE;
>  
>   if (sna->mode.num_real_crtc &&
> - !xf86HandleColormaps(screen, 256, 8, sna_load_palette, NULL,
> + !xf86HandleColormaps(screen, 1 << scrn->rgbBits, scrn->rgbBits,
> +  sna_load_palette, NULL,
>CMAP_RELOAD_ON_MODE_SWITCH |
>CMAP_PALETTED_TRUECOLOR))

I already forgot what this does prior to your randr fix. IIRC bumping
the 8 alone would cause the thing to segfault, but I guess bumping both
was fine?

Hmm. So the server always initializes crtc->gamma_size to 256
(which does match the normal hw LUT size), and so before your
fix we will always get gamma_slots==0 at >8bpc and so the hw LUT
is never actually updated?

>   return FALSE;
> diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
> index 3703c41..88c749e 100644
> --- a/src/uxa/intel_driver.c
> +++ b/src/uxa/intel_driver.c
> @@ -991,7 +991,8 @@ I830ScreenInit(SCREEN_INIT_ARGS_DECL)
>   if (!miCreateDefColormap(screen))
>   return FALSE;
>  
> - if (!xf86HandleColormaps(screen, 256, 8, I830LoadPalette, NULL,
> + if (!xf86HandleColormaps(screen, 1 << scrn->rgbBits, scrn->rgbBits,
> +  I830LoadPalette, NULL,
>CMAP_RELOAD_ON_MODE_SWITCH |
>CMAP_PALETTED_TRUECOLOR)) {
>   return FALSE;
> -- 
> 2.7.4
> 
> ___
> 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 v11 1/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset

[Michal Wajdeczko]

On Thu, 01 Mar 2018 02:01:35 +0100, Jackie Li  wrote:


GuC related exported functions should start with "intel_guc_" prefix and
pass intel_guc as the first parameter since its GuC related. Current
guc_ggtt_offset() failed to follow this code convention and this is a
problem for future patches that needs to access intel_guc data to verify
the GGTT offset against the GuC WOPCM top.

This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and  
updates

the related code to pass intel_guc pointer to this function call, so that
we can have a unified coding style for GuC code and also enable the  
future

patches to get GuC related data from intel_guc to do the offset
verification. Meanwhile, this patch also moves the GUC_GGTT_TOP from
intel_guc_regs.h to intel_guc.h since it is not GuC register related
definition.

v8:
 - Fixed coding style issues and moved GUC_GGTT_TOP to intel_guc.h  
(Sagar)

 - Updated commit message to explain to reason and motivation to add
   intel_guc as the first parameter of intel_guc_ggtt_offset (Chris)

v9:
 - Fixed code alignment issue due to line break (Chris)

v10:
 - Removed unnecessary comments, redundant code and avoided reuse  
variable

   to avoid potential issues (Joonas)

Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Sagar Arun Kamble  (v8)
Reviewed-by: Joonas Lahtinen  (v9)
Signed-off-by: Jackie Li 
---


Reviewed-by: Michal Wajdeczko 

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

[Intel-gfx] [PATCH v2] drm/i915/perf: fix perf stream opening lock

[Lionel Landwerlin]

We're seeing on CI that some contexts don't have the programmed OA
period timer that directs the OA unit on how often to write reports.

The issue is that we're not holding the drm lock from when we edit the
context images down to when we set the exclusive_stream variable. This
leaves a window for the deferred context allocation to call
i915_oa_init_reg_state() that will not program the expected OA timer
value, because we haven't set the exclusive_stream yet.

v2: Drop need_lock from gen8_configure_all_contexts() (Matt)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matthew Auld 
Reviewed-by: Chris Wilson 
Fixes: 701f8231a2f ("drm/i915/perf: prune OA configs")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
---
 drivers/gpu/drm/i915/i915_perf.c | 40 +---
 1 file changed, 13 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2741b1bc7095..abaca6edeb71 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1303,9 +1303,8 @@ static void i915_oa_stream_destroy(struct 
i915_perf_stream *stream)
 */
mutex_lock(_priv->drm.struct_mutex);
dev_priv->perf.oa.exclusive_stream = NULL;
-   mutex_unlock(_priv->drm.struct_mutex);
-
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
+   mutex_unlock(_priv->drm.struct_mutex);
 
free_oa_buffer(dev_priv);
 
@@ -1756,22 +1755,13 @@ static int gen8_switch_to_updated_kernel_context(struct 
drm_i915_private *dev_pr
  * Note: it's only the RCS/Render context that has any OA state.
  */
 static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
-  const struct i915_oa_config *oa_config,
-  bool interruptible)
+  const struct i915_oa_config *oa_config)
 {
struct i915_gem_context *ctx;
int ret;
unsigned int wait_flags = I915_WAIT_LOCKED;
 
-   if (interruptible) {
-   ret = i915_mutex_lock_interruptible(_priv->drm);
-   if (ret)
-   return ret;
-
-   wait_flags |= I915_WAIT_INTERRUPTIBLE;
-   } else {
-   mutex_lock(_priv->drm.struct_mutex);
-   }
+   lockdep_assert_held(_priv->drm.struct_mutex);
 
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
@@ -1819,8 +1809,6 @@ static int gen8_configure_all_contexts(struct 
drm_i915_private *dev_priv,
}
 
  out:
-   mutex_unlock(_priv->drm.struct_mutex);
-
return ret;
 }
 
@@ -1863,7 +1851,7 @@ static int gen8_enable_metric_set(struct drm_i915_private 
*dev_priv,
 * to make sure all slices/subslices are ON before writing to NOA
 * registers.
 */
-   ret = gen8_configure_all_contexts(dev_priv, oa_config, true);
+   ret = gen8_configure_all_contexts(dev_priv, oa_config);
if (ret)
return ret;
 
@@ -1878,7 +1866,7 @@ static int gen8_enable_metric_set(struct drm_i915_private 
*dev_priv,
 static void gen8_disable_metric_set(struct drm_i915_private *dev_priv)
 {
/* Reset all contexts' slices/subslices configurations. */
-   gen8_configure_all_contexts(dev_priv, NULL, false);
+   gen8_configure_all_contexts(dev_priv, NULL);
 
I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
  ~GT_NOA_ENABLE));
@@ -1888,7 +1876,7 @@ static void gen8_disable_metric_set(struct 
drm_i915_private *dev_priv)
 static void gen10_disable_metric_set(struct drm_i915_private *dev_priv)
 {
/* Reset all contexts' slices/subslices configurations. */
-   gen8_configure_all_contexts(dev_priv, NULL, false);
+   gen8_configure_all_contexts(dev_priv, NULL);
 
/* Make sure we disable noa to save power. */
I915_WRITE(RPM_CONFIG1,
@@ -2138,6 +2126,10 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (ret)
goto err_oa_buf_alloc;
 
+   ret = i915_mutex_lock_interruptible(_priv->drm);
+   if (ret)
+   goto err_lock;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
  stream->oa_config);
if (ret)
@@ -2145,23 +2137,17 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
 
stream->ops = _oa_stream_ops;
 
-   /* Lock device for exclusive_stream access late because
-* enable_metric_set() might lock as well on gen8+.
-*/
-   ret = i915_mutex_lock_interruptible(_priv->drm);
-   if (ret)
-   goto err_lock;
-

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: don't leak the pin_map on error

[Patchwork]

== Series Details ==

Series: drm/i915: don't leak the pin_map on error
URL   : https://patchwork.freedesktop.org/series/39207/
State : success

== Summary ==

Series 39207v1 drm/i915: don't leak the pin_map on error
https://patchwork.freedesktop.org/api/1.0/series/39207/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_chamelium:
Subgroup dp-crc-fast:
pass   -> DMESG-FAIL (fi-kbl-7500u) fdo#103841
Subgroup dp-edid-read:
pass   -> FAIL   (fi-kbl-7500u) fdo#102505
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
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:477s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:277s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s
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:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:388s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:561s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:415s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:289s
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:385s
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:450s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:261  dwarn:1   dfail:1   fail:1   skip:24  
time:448s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:490s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:421s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:520s
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:476s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:393s

4f93bc69c016e696a7ea97c6f894d9bab8a905d8 drm-tip: 2018y-03m-01d-09h-30m-35s UTC 
integration manifest
82bf88c2b4c7 drm/i915: don't leak the pin_map on error

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

[Michal Wajdeczko]

On Thu, 01 Mar 2018 11:28:03 +0100, Sagar Arun Kamble  
 wrote:





On 3/1/2018 3:36 PM, Michal Wajdeczko wrote:
On Thu, 01 Mar 2018 09:18:18 +0100, Sagar Arun Kamble  
 wrote:



GuC and HuC get loaded from intel_uc_init_hw. HuC load function is
named intel_huc_init_hw, however GuC load function is still named in
old style as intel_guc_fw_upload. Update it and the function doc. for
both functions.
Move of GuC load function's def. & decl. to intel_guc.c|h seems  
necessary
as it is more about core GuC functionality and not so much about fw  
itself.

This can be done in later patch if needed.



Function intel_guc_fw_upload() was named this way on purpose to follow
object-verb naming pattern, where our object is GuC FW (hence file name
intel_guc_fw.*)

There was a plan to unify this approach with HuC but in the opposite  
way:

by moving HuC firmware selection code to intel_huc_fw.* but since only
one function will be left in intel_huc.c this action was deferred.


Thanks for background on this.

Note that there will be nothing wrong to call fw_upload functions from
our uc_init_hw function:

intel_uc_init_hw()
  intel_uc_reset()
  intel_huc_fw_upload()
Will just do HuC name change (s/intel_huc_init_hw/intel_huc_fw_upload/)  
and comments update. HuC related move can be done later.

Is that ok?


Hmm, I've mixed feelings, as on one hand, this small step will unify
fw_upload calls, but at the same time it will break object-verb pattern
in intel_huc.* files ... so maybe we should do it only right?


intel_guc_fw_upload()
  intel_guc_enable_comm()
  intel_huc_auth()


/Michal

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

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 11:55:39PM +, Souza, Jose wrote:
> On Wed, 2018-02-28 at 13:09 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 28, 2018 at 12:57:07AM +, Souza, Jose wrote:
> > > On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> > > > On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> > > > wrote:
> > > > > When PSR/PSR2/GTC is enabled hardware can do AUX transactions
> > > > > by it
> > > > > self, so lets use the mutex register that is available in gen9+
> > > > > to
> > > > > avoid concurrent access by hardware and driver.
> > > > > Older gen handling will be done separated.
> > > > > 
> > > > > Reference: https://01.org/sites/default/files/documentation/int
> > > > > el-g
> > > > > fx-prm-osrc-skl-vol12-display.pdf
> > > > > Page 198 - AUX programming sequence
> > > > > 
> > > > > Reviewed-by: Dhinakaran Pandiyan  > > > > >
> > > > > Reviewed-by: Rodrigo Vivi 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > > 
> > > > > Changelog:
> > > > > v2
> > > > > - removed the PSR dependency, now getting lock all the times
> > > > > when
> > > > > available
> > > > > - renamed functions to avoid nested calls
> > > > > - moved register bits right after the DP_AUX_CH_MUTEX()
> > > > > - removed 'drm/i915: keep AUX powered while PSR is enabled'
> > > > > Dhinakaran Pandiyan will sent a better and final version
> > > > > v3
> > > > > - rebased on top of Ville's AUX series
> > > > > - moved port registers to above DP_AUX_CH_MUTEX()
> > > > > - using intel_wait_for_register() instead of the internal
> > > > > version
> > > > > v4
> > > > > - removed virtual function to get mutex register address
> > > > > - enabling the mutex back only on aux channel init
> > > > > - added the aux channel name to the timeout debug message
> > > > > v5
> > > > > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > > > > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > > > > 
> > > > >  drivers/gpu/drm/i915/i915_reg.h |  9 
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 47
> > > > > +
> > > > >  2 files changed, 56 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > > b/drivers/gpu/drm/i915/i915_reg.h
> > > > > index eea5b2c537d4..bce2e6dad4c4 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > > @@ -5385,6 +5385,15 @@ enum {
> > > > >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> > > > >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> > > > >  
> > > > > +#define _DPA_AUX_CH_MUTEX(dev_priv-
> > > > > > info.display_mmio_offset + 0x6402C)
> > > > > 
> > > > > +#define _DPB_AUX_CH_MUTEX(dev_priv-
> > > > > > info.display_mmio_offset + 0x6412C)
> > > > > 
> > > > > +#define _DPC_AUX_CH_MUTEX(dev_priv-
> > > > > > info.display_mmio_offset + 0x6422C)
> > > > > 
> > > > > +#define _DPD_AUX_CH_MUTEX(dev_priv-
> > > > > > info.display_mmio_offset + 0x6432C)
> > > > > 
> > > > > +#define _DPF_AUX_CH_MUTEX(dev_priv-
> > > > > > info.display_mmio_offset + 0x6452C)
> > > > > 
> > > > > +#define DP_AUX_CH_MUTEX(aux_ch)  _MMIO_PORT(aux_ch,
> > > > > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > > > > +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> > > > > +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> > > > > +
> > > > >  /*
> > > > >   * Computing GMCH M and N values for the Display Port link
> > > > >   *
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -1081,6 +1081,42 @@ static uint32_t
> > > > > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > > > >   aux_clock_divi
> > > > > der)
> > > > > ;
> > > > >  }
> > > > >  
> > > > > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > > > > +{
> > > > > + struct intel_digital_port *intel_dig_port =
> > > > > dp_to_dig_port(intel_dp);
> > > > > + struct drm_i915_private *dev_priv =
> > > > > + to_i915(intel_dig_port-
> > > > > >base.base.dev);
> > > > > +
> > > > > + if (INTEL_GEN(dev_priv) < 9)
> > > > > + return true;
> > > > > +
> > > > > + /* Spec says that mutex is acquired when status bit is
> > > > > read as unset,
> > > > > +  * here waiting for 2msec(+-4 aux transactions) before
> > > > > give up.
> > > > > +  */
> > > > > + if (intel_wait_for_register(dev_priv,
> > > > > DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > > > > + DP_AUX_CH_MUTEX_STATUS, 0,
> > > > > 2))
> > > > > 

Re: [Intel-gfx] [PATCH 4/5] drm/i915/frontbuffer: Remove early frontbuffer flush in prepare_plane_fb()

[Ville Syrjälä]

On Wed, Feb 28, 2018 at 11:38:56PM +, Pandiyan, Dhinakaran wrote:
> 
> 
> 
> On Wed, 2018-02-28 at 22:38 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 28, 2018 at 10:28:13PM +0200, Ville Syrjälä wrote:
> > > On Sat, Feb 24, 2018 at 03:24:55AM +, Pandiyan, Dhinakaran wrote:
> > > > 
> > > > 
> > > > 
> > > > On Mon, 2018-02-19 at 10:07 +0100, Maarten Lankhorst wrote:
> > > > > Op 16-02-18 om 20:27 schreef Pandiyan, Dhinakaran:
> > > > > > On Fri, 2018-02-16 at 08:55 +, Chris Wilson wrote:
> > > > > >> Quoting Dhinakaran Pandiyan (2018-02-16 04:33:21)
> > > > > >>> Preparing a framebuffer should not require a flush. 
> > > > > >>> _post_plane_update()
> > > > > >>> takes care of flushing when a flip is scheduled, this should be
> > > > > >>> sufficient for PSR and FBC.
> > > > > >> Makes sense.
> > > > > >>  
> > > > > > I also think this might speed up the flips a bit by avoiding 
> > > > > > flushes. 
> > > > > >
> > > > > >>> Cc: Paulo Zanoni 
> > > > > >>> Cc: Ville Syrjälä 
> > > > > >>> Cc: Chris Wilson 
> > > > > >>> Signed-off-by: Dhinakaran Pandiyan 
> > > > > >> Also
> > > > > >> Cc: Maarten Lankhorst 
> > > > > >> to validate the flow through atomic.
> > > > > >> -Chris
> > > > > >>
> > > > > Page flips used to do intel_frontbuffer_flip_prepare here, followed 
> > > > > by intel_frontbuffer_flip_complete. I think it would make sense to 
> > > > > change the patch to do that?
> > > > > 
> > > > 
> > > > I have no context why it was removed, I'll have to understand that
> > > > change and get back to you.
> > > 
> > > Since we supposedly have hw nuke for both fbc and psr there doesn't seem
> > > to be much need to do anything for flips. I guess DRRS is the only
> > > thing that kinda needs it (not really, just avoids flipping with the
> > > slow timings). But I think DRRS should really be tied into the vblank
> > > stuff somehow so that we switch to the fast timings whenever a vblank
> > > interrupts are enabled.
> > 
> > Oh, I guess VLV/CHV PSR is what would need this. To do that properly
> > (ie. main link off) I think we'd basically need to do a full modeset
> > when exiting PSR, so it should probably handled somewhere higher up
> > during modeset, and for other uses the frontbuffer tracking
> > should perhaps just schedule a work to do the full modeset.
> > 
> The mention of "full modeset" got me thinking. I believe you said full
> modeset because the link needs to be trained on PSR exit if it was off.
> But, link off isn't supported on VLV/CHV
> 
> else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
>   /* On VLV and CHV only standby mode is supported. */
>   dev_priv->psr.link_standby = true;

I think that's just because we've been lazy and done it. I think even
with the link off we'd need to reprogram all planes at least.

-- 
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 v11 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers

[Chris Wilson]

Quoting Jackie Li (2018-03-01 01:01:39)
> GuC WOPCM registers are write-once registers. Current driver code accesses
> these registers without checking the accessibility to these registers which
> will lead to unpredictable driver behaviors if these registers were touch
> by other components (such as faulty BIOS code).
> 
> This patch moves the GuC WOPCM registers updating code into
> intel_guc_wopcm.c and adds check before and after the update to GuC WOPCM
> registers so that we can make sure the driver is in a known state before
> and after writing to these write-once registers.
> 
> v6:
>  - Made sure module reloading won't bug the kernel while doing
>locking status checking
> 
> v7:
>  - Fixed patch format issues
> 
> v8:
>  - Fixed coding style issue on register lock bit macro definition (Sagar)
> 
> v9:
>  - Avoided to use redundant !! to cast uint to bool (Chris)
>  - Return error code instead of GEM_BUG_ON for locked with invalid register
>values case (Sagar)
>  - Updated guc_wopcm_hw_init to use guc_wopcm as first parameter (Michal)
>  - Added code to set and validate the HuC_LOADING_AGENT_GUC bit in GuC
>WOPCM offset register based on the presence of HuC firmware (Michal)
>  - Use bit fields instead of macros for GuC WOPCM flags (Michal)
> 
> v10:
>  - Refined variable names, removed redundant comments (Joonas)
>  - Introduced lockable_reg to handle the write once register write and
>propagate the write error to caller (Joonas)
>  - Used lockable_reg abstraction to avoid locking bit check on generic
>i915_reg_t (Michal)
>  - Added log message for error paths (Michal)
>  - Removed hw_updated flag and only relies on real hardware status
> 
> v11:
>  - Replaced lockable_reg with simplified function (Michal)
>  - Used new macros for locking bits of WOPCM size/offset registers instead
>of using BIT(0) directly (Michal)
>  - use intel_wopcm_init_hw() called from intel_gem_init_hw() to do GuC
>WOPCM register setup instead of calling from intel_uc_init_hw() (Michal)
> 
> BSpec: 10875, 10833
> 
> Cc: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 

Michal, your turn! Joonas, Sagar and myself did the first 3, so the
fourth must be yours for the royal flush ;)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915/guc: s/intel_guc_fw_upload/intel_guc_init_hw/

[Patchwork]

== Series Details ==

Series: series starting with [1/1] drm/i915/guc: 
s/intel_guc_fw_upload/intel_guc_init_hw/
URL   : https://patchwork.freedesktop.org/series/39192/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945 +1
Test gem_partial_pwrite_pread:
Subgroup write-snoop:
incomplete -> PASS   (shard-hsw) fdo#103540
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185 +1
Test kms_flip:
Subgroup flip-vs-expired-vblank-interruptible:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-ts-check:
pass   -> FAIL   (shard-hsw) fdo#100368
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:3335 pass:1758 dwarn:1   dfail:0   fail:6   skip:1566 
time:11069s
shard-hswtotal:3460 pass:1766 dwarn:1   dfail:0   fail:2   skip:1690 
time:11737s
shard-snbtotal:3460 pass:1358 dwarn:2   dfail:0   fail:1   skip:2099 
time:6646s
Blacklisted hosts:
shard-kbltotal:3442 pass:1914 dwarn:11  dfail:0   fail:7   skip:1509 
time:9271s

== Logs ==

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

Re: [Intel-gfx] i915 vs checkpatch

[Jani Nikula]

On Thu, 01 Mar 2018, Arkadiusz Hiler  wrote:
> Since not so long ago our CI is running and reporting sparse and
> checkpatch. Sparse is doing just fine but I had to disable checkpatch
> for the time being - too much "false" positives causing people to
> complain. It's simply confusing to see one thing in the code, and
> fitting your change in only to get a report that it's wrong.
>
> We are explicitly going against couple of the recommendations it tries
> to enforce, e.g. not using BIT macro, splitting quoted strings:
> https://lists.freedesktop.org/archives/intel-gfx/2018-February/156613.html
>
> IMHO we should make a couple of decisions here:
>  1. Do we really want to use the checkpatch / have CI reports?

I think yes, for the benefit of both patch authors and reviewers. For
the most part, we do want to encourage uniform style.

>  2. Which of the checkpatch checks we want to disabled for i915?

One low hanging fruit is to ignore the CHECK messages, or drop the
--strict option to checkpatch.pl in CI, although I think some of them
are nice.

>  3. How strongly do we want to enforce the rest?

That's a tough one. With code movement, you want the code to remain the
same instead of changing at the same time. And some of the warnings are
subjective. For example, I'd prefer to stick with the 80 column rule but
only when it makes sense. ;)

Another example, I would like to move towards kernel types over uint8_t
and friends. However, when you have code surrounded by uint8_t and
friends, it's often better to stick with the style around you.

>  4. Do we want to change what's already in the tree, for compliance?

No. I don't think we should encourage mindless checkpatch fixes.

Does checkpatch support disabling checks or do you have to filter them
out from the output?

BR,
Jani.


>
> Recent-ish drm-tip, vanilla checkpatch on i915 reports:
> total: 399 errors, 3573 warnings, 209374 lines checked

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/icl: Prepare for more rings

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/icl: Prepare for more rings
URL   : https://patchwork.freedesktop.org/series/39102/
State : success

== Summary ==

Series 39102v1 series starting with [CI,1/2] drm/i915/icl: Prepare for more 
rings
https://patchwork.freedesktop.org/api/1.0/series/39102/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test prime_vgem:
Subgroup basic-fence-flip:
fail   -> PASS   (fi-ilk-650) fdo#104008

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
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:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:278s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:477s
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:452s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:397s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:180  dwarn:0   dfail:0   fail:0   skip:108 
time:291s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
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:446s
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:453s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:420s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:501s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
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:469s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:521s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s

4f93bc69c016e696a7ea97c6f894d9bab8a905d8 drm-tip: 2018y-03m-01d-09h-30m-35s UTC 
integration manifest
7c05e1f55596 drm/i915/icl: Interrupt handling
9fb6e26f81ee drm/i915/icl: Prepare for more rings

== Logs ==

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