date:20220318

[Intel-gfx] ✓ Fi.CI.IGT: success for Splitting intel-gtt calls for non-x86 platforms

2022-03-18 Thread Patchwork

== Series Details ==

Series: Splitting intel-gtt calls for non-x86 platforms
URL   : https://patchwork.freedesktop.org/series/101552/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11385_full -> Patchwork_22618_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Known issues


  Here are the changes found in Patchwork_22618_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@kms:
- shard-tglb: [PASS][1] -> [FAIL][2] ([i915#232])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/shard-tglb8/igt@gem_...@kms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-tglb2/igt@gem_...@kms.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/shard-iclb1/igt@gem_exec_balan...@parallel-balancer.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_balancer@parallel-contexts:
- shard-kbl:  NOTRUN -> [DMESG-WARN][5] ([i915#5076])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-kbl7/igt@gem_exec_balan...@parallel-contexts.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][6] -> [FAIL][7] ([i915#2842])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-glk4/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][11] ([fdo#109283])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-tglb3/igt@gem_exec_par...@no-blt.html

  * igt@gem_exec_params@no-vebox:
- shard-skl:  NOTRUN -> [SKIP][12] ([fdo#109271]) +168 similar 
issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-skl10/igt@gem_exec_par...@no-vebox.html

  * igt@gem_exec_whisper@basic-queues-forked:
- shard-glk:  NOTRUN -> [DMESG-WARN][13] ([i915#118])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-glk4/igt@gem_exec_whis...@basic-queues-forked.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-skl:  NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +2 
similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-skl1/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@random:
- shard-kbl:  NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-kbl7/igt@gem_lmem_swapp...@random.html

  * igt@kms_async_flips@crc:
- shard-skl:  NOTRUN -> [FAIL][16] ([i915#4272])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-skl10/igt@kms_async_fl...@crc.html

  * igt@kms_big_fb@linear-8bpp-rotate-90:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110725] / [fdo#111614])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-iclb7/igt@kms_big...@linear-8bpp-rotate-90.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL][18] ([i915#3743])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-skl4/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html

  * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-apl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3777])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-apl3/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-hflip:
- shard-kbl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3777]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/shard-kbl4/igt@kms_big...@y-tiled-max-hw-stride-32bpp-rotate-180-hflip.html

  * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-skl:  NOTRUN -> [FAIL

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Require INTEL_GTT to depend on X86

2022-03-18 Thread Lucas De Marchi


On Fri, Mar 18, 2022 at 07:00:41PM -0700, Casey Bowman wrote:

The intel-gtt module is not used on other, non-x86 platforms, so we
will restrict it to x86 platforms only.

Signed-off-by: Casey Bowman 


this should probably be the second patch, not the first.



Reviewed-by: Lucas De Marchi 


Lucas De Marchi



---
drivers/gpu/drm/i915/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 63db8bcf03bf..b381e14863a6 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -4,7 +4,7 @@ config DRM_I915
depends on DRM
depends on X86 && PCI
depends on !PREEMPT_RT
-   select INTEL_GTT
+   select INTEL_GTT if X86
select INTERVAL_TREE
# we need shmfs for the swappable backing store, and in particular
# the shmem_readpage() which depends upon tmpfs
--
2.25.1

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Split intel-gtt functions by arch

2022-03-18 Thread Lucas De Marchi


On Fri, Mar 18, 2022 at 07:00:42PM -0700, Casey Bowman wrote:

Some functions defined in the intel-gtt module are used in several
areas, but is only supported on x86 platforms.

By separating these calls and their static underlying functions to
area, we are able to compile out these functions for non-x86 builds
and provide stubs for the non-x86 implementations.



I like the direction this is going now. See comments below.


Signed-off-by: Casey Bowman 
---
drivers/gpu/drm/i915/Makefile   |   2 +
drivers/gpu/drm/i915/gt/intel_ggtt.c|  97 +
drivers/gpu/drm/i915/gt/intel_gt.c  |   6 +-
drivers/gpu/drm/i915/gt/intel_gtt.h |  10 ++
drivers/gpu/drm/i915/gt/intel_gtt_support.c | 113 
drivers/gpu/drm/i915/gt/intel_gtt_support.h |  39 +++
6 files changed, 171 insertions(+), 96 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gtt_support.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gtt_support.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 61b078bd1b32..cc332cb6833b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -124,6 +124,8 @@ gt-y += \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
+# x86 intel-gtt module support
+gt-$(CONFIG_X86) += gt/intel_gtt_support.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 04191fe2ee34..db2f1b12c273 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -3,14 +3,12 @@
 * Copyright © 2020 Intel Corporation
 */

-#include 
#include 

#include 
#include 

#include 
-#include 

#include "gem/i915_gem_lmem.h"

@@ -21,6 +19,7 @@
#include "i915_vgpu.h"

#include "intel_gtt.h"
+#include "intel_gtt_support.h"
#include "gen8_ppgtt.h"

static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
@@ -98,7 +97,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
 * Certain Gen5 chipsets require idling the GPU before
 * unmapping anything from the GTT when VT-d is enabled.
 */
-static bool needs_idle_maps(struct drm_i915_private *i915)
+bool needs_idle_maps(struct drm_i915_private *i915)


why didn't you move this function together? It's only used by
i915_gmch_probe()

If it was something generic that needed to be exported, you'd need to
rename it to respect the namespace.

but here I think you can just move it to the new file.


{
/*
 * Query intel_iommu to see if we need the workaround. Presumably that
@@ -229,11 +228,6 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
}

-static void gmch_ggtt_invalidate(struct i915_ggtt *ggtt)
-{
-   intel_gtt_chipset_flush();
-}
-
u64 gen8_ggtt_pte_encode(dma_addr_t addr,
 enum i915_cache_level level,
 u32 flags)
@@ -467,37 +461,7 @@ static void gen6_ggtt_clear_range(struct 
i915_address_space *vm,
iowrite32(scratch_pte, >t_base[i]);
}

-static void i915_ggtt_insert_page(struct i915_address_space *vm,
- dma_addr_t addr,
- u64 offset,
- enum i915_cache_level cache_level,
- u32 unused)
-{
-   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
-   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
-
-   intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
-}
-
-static void i915_ggtt_insert_entries(struct i915_address_space *vm,
-struct i915_vma_resource *vma_res,
-enum i915_cache_level cache_level,
-u32 unused)
-{
-   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
-   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
-
-   intel_gtt_insert_sg_entries(vma_res->bi.pages, vma_res->start >> 
PAGE_SHIFT,
-   flags);
-}
-
-static void i915_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
-   intel_gtt_clear_range(start >> PAGE_SHIFT, length >> PAGE_SHIFT);
-}
-
-static void ggtt_bind_vma(struct i915_address_space *vm,
+void ggtt_bind_vma(struct i915_address_space *vm,
  struct i915_vm_pt_stash *stash,
  struct i915_vma_resource *vma_res,
  enum i915_cache_level cache_level,
@@ -521,7 +485,7 @@ static void ggtt_bind_vma(struct i915_address_space *vm,
vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
}

-static void ggtt_unbind_vma(struct i915_address_space *vm,
+void ggtt_unbind_vma(struct i915_address_space *vm,
struct i915_vma_resource *vma_res)
{

[Intel-gfx] ✓ Fi.CI.BAT: success for Splitting intel-gtt calls for non-x86 platforms

2022-03-18 Thread Patchwork

== Series Details ==

Series: Splitting intel-gtt calls for non-x86 platforms
URL   : https://patchwork.freedesktop.org/series/101552/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11385 -> Patchwork_22618


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/index.html

Participating hosts (46 -> 38)
--

  Missing(8): fi-bxt-dsi fi-bdw-5557u shard-tglu bat-adlm-1 fi-bsw-cyan 
fi-pnv-d510 shard-rkl fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22618:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@gt_lrc:
- {bat-adlp-6}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/bat-adlp-6/igt@i915_selftest@live@gt_lrc.html

  
Known issues


  Here are the changes found in Patchwork_22618 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-x1275:   [PASS][3] -> [DMESG-FAIL][4] ([i915#5334])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/fi-kbl-x1275/igt@i915_selftest@live@gt_heartbeat.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/fi-kbl-x1275/igt@i915_selftest@live@gt_heartbeat.html

  * igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#3921])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11385/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22618/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
  [i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270
  [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
  [i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
  [i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342
  [i915#5356]: https://gitlab.freedesktop.org/drm/intel/issues/5356


Build changes
-

  * Linux: CI_DRM_11385 -> Patchwork_22618

  CI-20190529: 20190529
  CI_DRM_11385: 3babe046f5f5544ec772cd443f9d5ca24e342348 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6386: 0fcd59ad25b2960c0b654f90dfe4dd9e7c7b874d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22618: 6fb28942812c08593386bbfaf5e15c47bc4eddfb @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

6fb28942812c drm/i915/gt: Split intel-gtt functions by arch
71b8a3999b05 drm/i915: Require INTEL_GTT to depend on X86

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Splitting intel-gtt calls for non-x86 platforms

2022-03-18 Thread Patchwork

== Series Details ==

Series: Splitting intel-gtt calls for non-x86 platforms
URL   : https://patchwork.freedesktop.org/series/101552/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Splitting intel-gtt calls for non-x86 platforms

2022-03-18 Thread Patchwork

== Series Details ==

Series: Splitting intel-gtt calls for non-x86 platforms
URL   : https://patchwork.freedesktop.org/series/101552/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
71b8a3999b05 drm/i915: Require INTEL_GTT to depend on X86
6fb28942812c drm/i915/gt: Split intel-gtt functions by arch
-:112: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#112: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:465:
+void ggtt_bind_vma(struct i915_address_space *vm,
  struct i915_vm_pt_stash *stash,

-:121: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#121: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:489:
+void ggtt_unbind_vma(struct i915_address_space *vm,
struct i915_vma_resource *vma_res)

-:231: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#231: FILE: drivers/gpu/drm/i915/gt/intel_gtt.h:551:
+void ggtt_bind_vma(struct i915_address_space *vm,
+ struct i915_vm_pt_stash *stash,

-:236: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#236: FILE: drivers/gpu/drm/i915/gt/intel_gtt.h:556:
+void ggtt_unbind_vma(struct i915_address_space *vm,
+   struct i915_vma_resource *vma_res);

-:249: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#249: 
new file mode 100644

-:270: WARNING:MEMORY_BARRIER: memory barrier without comment
#270: FILE: drivers/gpu/drm/i915/gt/intel_gtt_support.c:17:
+   wmb();

-:305: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#305: FILE: drivers/gpu/drm/i915/gt/intel_gtt_support.c:52:
+static void i915_ggtt_clear_range(struct i915_address_space *vm,
+u64 start, u64 length)

-:397: WARNING:RETURN_VOID: void function return statements are not generally 
useful
#397: FILE: drivers/gpu/drm/i915/gt/intel_gtt_support.h:25:
+   return;
+}

-:398: CHECK:LINE_SPACING: Please use a blank line after 
function/struct/union/enum declarations
#398: FILE: drivers/gpu/drm/i915/gt/intel_gtt_support.h:26:
+}
+static inline int i915_gmch_probe(struct i915_ggtt *ggtt)

total: 0 errors, 3 warnings, 6 checks, 355 lines checked

[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101551/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11384_full -> Patchwork_22617_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22617_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22617_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22617_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_workarounds@suspend-resume:
- shard-kbl:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-kbl7/igt@gem_workarou...@suspend-resume.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-kbl6/igt@gem_workarou...@suspend-resume.html

  
Known issues


  Here are the changes found in Patchwork_22617_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][3] ([i915#4991])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-kbl4/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl:  NOTRUN -> [DMESG-WARN][4] ([i915#180]) +3 similar 
issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
- shard-apl:  NOTRUN -> [DMESG-WARN][5] ([i915#180])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-apl3/igt@gem_ctx_isolation@preservation...@vcs0.html

  * igt@gem_eio@in-flight-immediate:
- shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#3063])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-tglb3/igt@gem_...@in-flight-immediate.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-tglb8/igt@gem_...@in-flight-immediate.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-glk6/igt@gem_exec_fair@basic-p...@vecs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-glk3/igt@gem_exec_fair@basic-p...@vecs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][15] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][16] ([fdo#109283])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-tglb6/igt@gem_exec_par...@no-blt.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +5 
similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-skl10/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_lmem_swapping@parallel-random:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-apl6/igt@gem_lmem_swapp...@parallel-random.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/shard-iclb5/igt@gem_...@create-valid-protected-context.html

  * igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-apl:  NOTRUN -> [SKIP][20] ([fdo#109271]) +34 similar issues
   [20]: 
https://intel-gfx-

[Intel-gfx] [PATCH 1/2] drm/i915: Require INTEL_GTT to depend on X86

2022-03-18 Thread Casey Bowman

The intel-gtt module is not used on other, non-x86 platforms, so we
will restrict it to x86 platforms only.

Signed-off-by: Casey Bowman 
---
 drivers/gpu/drm/i915/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 63db8bcf03bf..b381e14863a6 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -4,7 +4,7 @@ config DRM_I915
depends on DRM
depends on X86 && PCI
depends on !PREEMPT_RT
-   select INTEL_GTT
+   select INTEL_GTT if X86
select INTERVAL_TREE
# we need shmfs for the swappable backing store, and in particular
# the shmem_readpage() which depends upon tmpfs
-- 
2.25.1

[Intel-gfx] [PATCH 2/2] drm/i915/gt: Split intel-gtt functions by arch

2022-03-18 Thread Casey Bowman

Some functions defined in the intel-gtt module are used in several
areas, but is only supported on x86 platforms.

By separating these calls and their static underlying functions to
area, we are able to compile out these functions for non-x86 builds
and provide stubs for the non-x86 implementations.

Signed-off-by: Casey Bowman 
---
 drivers/gpu/drm/i915/Makefile   |   2 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c|  97 +
 drivers/gpu/drm/i915/gt/intel_gt.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h |  10 ++
 drivers/gpu/drm/i915/gt/intel_gtt_support.c | 113 
 drivers/gpu/drm/i915/gt/intel_gtt_support.h |  39 +++
 6 files changed, 171 insertions(+), 96 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gtt_support.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gtt_support.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 61b078bd1b32..cc332cb6833b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -124,6 +124,8 @@ gt-y += \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
+# x86 intel-gtt module support
+gt-$(CONFIG_X86) += gt/intel_gtt_support.o
 # autogenerated null render state
 gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 04191fe2ee34..db2f1b12c273 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -3,14 +3,12 @@
  * Copyright © 2020 Intel Corporation
  */
 
-#include 
 #include 
 
 #include 
 #include 
 
 #include 
-#include 
 
 #include "gem/i915_gem_lmem.h"
 
@@ -21,6 +19,7 @@
 #include "i915_vgpu.h"
 
 #include "intel_gtt.h"
+#include "intel_gtt_support.h"
 #include "gen8_ppgtt.h"
 
 static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
@@ -98,7 +97,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *i915)
  * Certain Gen5 chipsets require idling the GPU before
  * unmapping anything from the GTT when VT-d is enabled.
  */
-static bool needs_idle_maps(struct drm_i915_private *i915)
+bool needs_idle_maps(struct drm_i915_private *i915)
 {
/*
 * Query intel_iommu to see if we need the workaround. Presumably that
@@ -229,11 +228,6 @@ static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
 }
 
-static void gmch_ggtt_invalidate(struct i915_ggtt *ggtt)
-{
-   intel_gtt_chipset_flush();
-}
-
 u64 gen8_ggtt_pte_encode(dma_addr_t addr,
 enum i915_cache_level level,
 u32 flags)
@@ -467,37 +461,7 @@ static void gen6_ggtt_clear_range(struct 
i915_address_space *vm,
iowrite32(scratch_pte, >t_base[i]);
 }
 
-static void i915_ggtt_insert_page(struct i915_address_space *vm,
- dma_addr_t addr,
- u64 offset,
- enum i915_cache_level cache_level,
- u32 unused)
-{
-   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
-   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
-
-   intel_gtt_insert_page(addr, offset >> PAGE_SHIFT, flags);
-}
-
-static void i915_ggtt_insert_entries(struct i915_address_space *vm,
-struct i915_vma_resource *vma_res,
-enum i915_cache_level cache_level,
-u32 unused)
-{
-   unsigned int flags = (cache_level == I915_CACHE_NONE) ?
-   AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
-
-   intel_gtt_insert_sg_entries(vma_res->bi.pages, vma_res->start >> 
PAGE_SHIFT,
-   flags);
-}
-
-static void i915_ggtt_clear_range(struct i915_address_space *vm,
- u64 start, u64 length)
-{
-   intel_gtt_clear_range(start >> PAGE_SHIFT, length >> PAGE_SHIFT);
-}
-
-static void ggtt_bind_vma(struct i915_address_space *vm,
+void ggtt_bind_vma(struct i915_address_space *vm,
  struct i915_vm_pt_stash *stash,
  struct i915_vma_resource *vma_res,
  enum i915_cache_level cache_level,
@@ -521,7 +485,7 @@ static void ggtt_bind_vma(struct i915_address_space *vm,
vma_res->page_sizes_gtt = I915_GTT_PAGE_SIZE;
 }
 
-static void ggtt_unbind_vma(struct i915_address_space *vm,
+void ggtt_unbind_vma(struct i915_address_space *vm,
struct i915_vma_resource *vma_res)
 {
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
@@ -1149,54 +1113,6 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
return ggtt_probe_common(ggtt, size);
 }
 
-static void i915_gmch_remove(struct i915_address_space *vm)
-{
-   intel_gmch_remove();
-}
-
-static int i915_gmch_probe(struct i915_ggtt *ggtt

[Intel-gfx] [PATCH 0/2] Splitting intel-gtt calls for non-x86 platforms

2022-03-18 Thread Casey Bowman

The intel-gtt module defines some functions used by i915, but they are
only supported by x86 platforms. In order to bring i915 to a more
arch-neutral state, we split out these functions and provide stubs in
the case of non-x86 builds.

There may be a better filename choice for the files used in splitting
the calls, it's very much open to discussion.

Casey Bowman (2):
  drm/i915: Require INTEL_GTT to depend on X86
  drm/i915/gt: Split intel-gtt functions by arch

 drivers/gpu/drm/i915/Kconfig|   2 +-
 drivers/gpu/drm/i915/Makefile   |   2 +
 drivers/gpu/drm/i915/gt/intel_ggtt.c|  97 +
 drivers/gpu/drm/i915/gt/intel_gt.c  |   6 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h |  10 ++
 drivers/gpu/drm/i915/gt/intel_gtt_support.c | 113 
 drivers/gpu/drm/i915/gt/intel_gtt_support.h |  39 +++
 7 files changed, 172 insertions(+), 97 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gtt_support.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gtt_support.h

-- 
2.25.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101549/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11384_full -> Patchwork_22616_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22616_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22616_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22616_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_whisper@basic-fds:
- shard-skl:  NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-skl2/igt@gem_exec_whis...@basic-fds.html

  * igt@i915_selftest@mock@requests:
- shard-kbl:  [PASS][2] -> [DMESG-FAIL][3]
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-kbl4/igt@i915_selftest@m...@requests.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-kbl4/igt@i915_selftest@m...@requests.html
- shard-tglb: [PASS][4] -> [DMESG-FAIL][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-tglb7/igt@i915_selftest@m...@requests.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-tglb8/igt@i915_selftest@m...@requests.html
- shard-apl:  [PASS][6] -> [DMESG-FAIL][7]
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-apl2/igt@i915_selftest@m...@requests.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-apl1/igt@i915_selftest@m...@requests.html
- shard-glk:  [PASS][8] -> [DMESG-FAIL][9]
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-glk6/igt@i915_selftest@m...@requests.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-glk4/igt@i915_selftest@m...@requests.html
- shard-snb:  [PASS][10] -> [DMESG-FAIL][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-snb7/igt@i915_selftest@m...@requests.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-snb2/igt@i915_selftest@m...@requests.html
- shard-iclb: [PASS][12] -> [DMESG-FAIL][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-iclb5/igt@i915_selftest@m...@requests.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-iclb7/igt@i915_selftest@m...@requests.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@mock@requests:
- {shard-tglu}:   [PASS][14] -> [DMESG-FAIL][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-tglu-4/igt@i915_selftest@m...@requests.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-tglu-4/igt@i915_selftest@m...@requests.html
- {shard-rkl}:[PASS][16] -> [DMESG-FAIL][17]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-rkl-5/igt@i915_selftest@m...@requests.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-rkl-2/igt@i915_selftest@m...@requests.html

  
Known issues


  Here are the changes found in Patchwork_22616_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-kbl:  NOTRUN -> [DMESG-WARN][18] ([i915#4991])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-kbl3/igt@gem_cre...@create-massive.html

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-apl:  NOTRUN -> [DMESG-WARN][19] ([i915#180])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-apl7/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_ctx_shared@q-smoketest-all:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118]) +1 
similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-glk4/igt@gem_ctx_sha...@q-smoketest-all.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-glk4/igt@gem_ctx_sha...@q-smoketest-all.html

  * igt@gem_eio@kms:
- shard-tglb: [PASS][22] -> [FAIL][23] ([i915#232])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/shard-tglb6/igt@gem_...@kms.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/shard-tglb1/igt@gem_...@kms.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][24] ([i915#4547])
   [24]: 
https://intel-gfx-c

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101551/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11384 -> Patchwork_22617


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/index.html

Participating hosts (39 -> 40)
--

  Additional (5): bat-dg2-8 bat-dg2-9 fi-pnv-d510 bat-jsl-2 bat-jsl-1 
  Missing(4): fi-bsw-cyan shard-rkl shard-tglu fi-kbl-8809g 

Known issues


  Here are the changes found in Patchwork_22617 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#5341])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271]) +57 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][4] ([i915#4785]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  
 Warnings 

  * igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [SKIP][6] ([fdo#109271]) -> [FAIL][7] ([i915#579])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22617/fi-kbl-guc/igt@i915_pm_...@basic-rte.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5192]: https://gitlab.freedesktop.org/drm/intel/issues/5192
  [i915#5193]: https://gitlab.freedesktop.org/drm/intel/issues/5193
  [i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5275]: https://gitlab.freedesktop.org/drm/intel/issues/5275
  [i915#5276]: https://gitlab.freedesktop.org/drm/intel/issues/5276
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
  [i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579


Build changes
-

  * Linux: CI_DRM_11384 -> Patchwork_22617

  CI-20190529: 20190529
  CI_DRM_11384: 76874531ffae416833

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101551/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101549/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11384 -> Patchwork_22616


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/index.html

Participating hosts (39 -> 40)
--

  Additional (4): bat-dg2-8 bat-jsl-2 bat-dg2-9 bat-jsl-1 
  Missing(3): fi-bsw-cyan shard-rkl shard-tglu 

Known issues


  Here are the changes found in Patchwork_22616 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#109315]) +17 
similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][2] ([i915#2426] / [i915#4312])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/fi-bdw-5557u/igt@run...@aborted.html

  
 Possible fixes 

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][3] ([i915#4785]) -> [PASS][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11384/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22616/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3003]: https://gitlab.freedesktop.org/drm/intel/issues/3003
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
  [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
  [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
  [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
  [i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
  [i915#5068]: https://gitlab.freedesktop.org/drm/intel/issues/5068
  [i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
  [i915#5192]: https://gitlab.freedesktop.org/drm/intel/issues/5192
  [i915#5193]: https://gitlab.freedesktop.org/drm/intel/issues/5193
  [i915#5195]: https://gitlab.freedesktop.org/drm/intel/issues/5195
  [i915#5270]: https://gitlab.freedesktop.org/drm/intel/issues/5270
  [i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
  [i915#5275]: https://gitlab.freedesktop.org/drm/intel/issues/5275
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
  [i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
  [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
  [i915#5356]: https://gitlab.freedesktop.org/drm/intel/issues/5356


Build changes
-

  * Linux: CI_DRM_11384 -> Patchwork_22616

  CI-20190529: 20190529
  CI_DRM_11384: 76874531ffae41683316380bd6d6227bbba12148 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6386: 0fcd59ad25b2960c0b654f90dfe4dd9e7c7b874d @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22616: 59ae69ae1370b0bd1623aed7a71c421e6c25538c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

59ae69ae1370 drm/i915/gt: Adding new sysfs frequency attributes
a85aedc94158 drm/i915/gt: Create per-tile RPS sysfs interfaces
a4492f268173 drm/i915/gt: Create per-tile RC6 sysfs interface
287368b2d564 drm/i915/gt: create

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101551/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e394242076f2 drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
e56e16681fc9 drm/i915/gt: add gt_is_root() helper
5bf72a0d1d73 drm/i915: Prepare for multiple GTs
-:249: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id__' - possible 
side-effects?
#249: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:103:
+#define for_each_gt(gt__, i915__, id__) \
+   for ((id__) = 0; \
+(id__) < I915_MAX_GT; \
+(id__)++) \
+   for_each_if(((gt__) = (i915__)->gt[(id__)]))

total: 0 errors, 0 warnings, 1 checks, 444 lines checked
3dbb22f19314 drm/i915/gt: create per-tile sysfs interface
-:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#72: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 196 lines checked
e051f78dc8fa drm/i915/gt: Create per-tile RC6 sysfs interface
-:121: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#121: 
new file mode 100644

-:157: CHECK:SPACING: No space is necessary after a cast
#157: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:32:
+   ret = (op == INTEL_GT_SYSFS_MAX) ? 0 : (u32) -1;

total: 0 errors, 1 warnings, 1 checks, 453 lines checked
557499c5d443 drm/i915/gt: Create per-tile RPS sysfs interfaces
-:320: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_mode' - possible 
side-effects?
#320: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:458:
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
+   struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, 
_show, _store); \
+   struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, 
_mode, _show, _store)

-:320: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_show' - possible 
side-effects?
#320: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:458:
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
+   struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, 
_show, _store); \
+   struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, 
_mode, _show, _store)

-:320: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_store' - possible 
side-effects?
#320: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:458:
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
+   struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, 
_show, _store); \
+   struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, 
_mode, _show, _store)

-:334: CHECK:CAMELCASE: Avoid CamelCase: 
#334: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:472:
+static INTEL_GT_RPS_SYSFS_ATTR_RO(RPn_freq_mhz);

-:348: CHECK:CAMELCASE: Avoid CamelCase: 
#348: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:486:
+   &dev_attr_##s##_RPn_freq_mhz.attr, \

total: 0 errors, 0 warnings, 5 checks, 503 lines checked
42ca62b1fbf5 drm/i915/gt: Add sysfs throttle frequency interfaces
-:87: CHECK:SPACING: No space is necessary after a cast
#87: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:521:
+   (struct intel_gt_bool_throttle_attr *) attr;

total: 0 errors, 0 warnings, 1 checks, 147 lines checked

[Intel-gfx] [PATCH v7 7/7] drm/i915/gt: Add sysfs throttle frequency interfaces

2022-03-18 Thread Andi Shyti

From: Sujaritha Sundaresan 

Throttling here refers to the GT frequency being clipped. Each of
the throttle reason attributes will have a 0 or 1 value depending
upon whether there is throttling and also the specific reason for
it.

The following is a brief description of the sysfs throttle
frequency attributes added:

 - throttle_reason_status: when set indicates that there is GT
   frequency clipping.

 - throttle_reason_pl1: when set indicates that PBM PL1 (platform
   or package PL1) has caused GT frequency clipping.

 - throttle_reason_pl2: when set indicates that PBM PL2 or PL3
   (platform or package PL2 or PL3) has caused GT frequency
   clipping.

 - throttle_reason_pl4: when set indicates that PL4 or IccMax has
   caused GT frequency clipping.

 - throttle_reason_thermal: when set indicates that Thermal event
   has caused GT frequency clipping.

 - throttle_reason_prochot: when set indicates that PROCHOT# has
   caused GT frequency clipping.

 - throttle_reason_ratl: when set indicates that Running Average
   Thermal Limit has caused GT frequency clipping.

 - throttle_reason_vr_thermalert: when set indicates that Hot VR
   (any processor VR)  has caused GT frequency clipping.

 - throttle_reason_vr_tdc: when set indicates that VR TDC
   (Thermal Design Current)  has caused GT frequency clipping.

Signed-off-by: Sujaritha Sundaresan 
Signed-off-by: Andi Shyti 
Cc: Dale B Stimson 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 74 +
 drivers/gpu/drm/i915/gt/intel_rps.c | 18 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  4 ++
 drivers/gpu/drm/i915/i915_reg.h | 11 +++
 4 files changed, 107 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index b0a1ea95d028e..26cbfa6477d12 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -8,6 +8,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "i915_reg.h"
 #include "i915_sysfs.h"
 #include "intel_gt.h"
 #include "intel_gt_regs.h"
@@ -493,6 +494,69 @@ static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
 static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
 static const struct attribute * const gen6_gt_attrs[]  = GEN6_GT_ATTR;
 
+static ssize_t punit_req_freq_mhz_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   u32 preq = intel_rps_read_punit_req_frequency(>->rps);
+
+   return sysfs_emit(buff, "%u\n", preq);
+}
+
+struct intel_gt_bool_throttle_attr {
+   struct attribute attr;
+   ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+   char *buf);
+   i915_reg_t reg32;
+   u32 mask;
+};
+
+static ssize_t throttle_reason_bool_show(struct device *dev,
+struct device_attribute *attr,
+char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   struct intel_gt_bool_throttle_attr *t_attr =
+   (struct intel_gt_bool_throttle_attr *) attr;
+   bool val = rps_read_mask_mmio(>->rps, t_attr->reg32, t_attr->mask);
+
+   return sysfs_emit(buff, "%u\n", val);
+}
+
+#define INTEL_GT_RPS_BOOL_ATTR_RO(sysfs_func__, mask__) \
+struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
+   .attr = { .name = __stringify(sysfs_func__), .mode = 0444 }, \
+   .show = throttle_reason_bool_show, \
+   .reg32 = GT0_PERF_LIMIT_REASONS, \
+   .mask = mask__, \
+}
+
+static DEVICE_ATTR_RO(punit_req_freq_mhz);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_status, 
GT0_PERF_LIMIT_REASONS_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl1, POWER_LIMIT_1_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl2, POWER_LIMIT_2_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl4, POWER_LIMIT_4_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_thermal, THERMAL_LIMIT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_prochot, PROCHOT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_ratl, RATL_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_thermalert, 
VR_THERMALERT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_tdc, VR_TDC_MASK);
+
+static const struct attribute *freq_attrs[] = {
+   &dev_attr_punit_req_freq_mhz.attr,
+   &attr_throttle_reason_status.attr,
+   &attr_throttle_reason_pl1.attr,
+   &attr_throttle_reason_pl2.attr,
+   &attr_throttle_reason_pl4.attr,
+   &attr_throttle_reason_thermal.attr,
+   &attr_throttle_reason_prochot.attr,
+   &attr_throttle_reason_ratl.attr,
+   &attr_throttle_reason_vr_thermalert.attr,
+   &attr_throttle_reason_vr_tdc.attr,
+

[Intel-gfx] [PATCH v7 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces

2022-03-18 Thread Andi Shyti

Now tiles have their own sysfs interfaces under the gt/
directory. Because RPS is a property that can be configured on a
tile basis, then each tile should have its own interface

The new sysfs structure will have a similar layout for the 4 tile
case:

/sys/.../card0
 ├── gt
 │   ├── gt0
 │   │   ├── id
 │   │   ├── rc6_enable
 │   │   ├── rc6_residency_ms
 │   │   ├── rps_act_freq_mhz
 │   │   ├── rps_boost_freq_mhz
 │   │   ├── rps_cur_freq_mhz
 │   │   ├── rps_max_freq_mhz
 │   │   ├── rps_min_freq_mhz
 │   │   ├── rps_RP0_freq_mhz
 │   │   ├── rps_RP1_freq_mhz
 │   │   └── rps_RPn_freq_mhz
 .   .
 .   .
 .   .
 │   └── gtN
 │   ├── id
 │   ├── rc6_enable
 │   ├── rc6_residency_ms
 │   ├── rps_act_freq_mhz
 │   ├── rps_boost_freq_mhz
 │   ├── rps_cur_freq_mhz
 │   ├── rps_max_freq_mhz
 │   ├── rps_min_freq_mhz
 │   ├── rps_RP0_freq_mhz
 │   ├── rps_RP1_freq_mhz
 │   └── rps_RPn_freq_mhz
 ├── gt_act_freq_mhz   -+
 ├── gt_boost_freq_mhz  |
 ├── gt_cur_freq_mhz|Original interface
 ├── gt_max_freq_mhz+─-> kept as existing ABI;
 ├── gt_min_freq_mhz|it points to gt0/
 ├── gt_RP0_freq_mhz|
 ├── gt_RP1_freq_mhz|
 └── gt_RPn_freq_mhz   -+

The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
writing they loop through all the GTs and write the information
on each interface. When reading they provide the average value
from all the GTs.

This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Signed-off-by: Lucas De Marchi 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 283 
 drivers/gpu/drm/i915/i915_sysfs.c   | 177 
 2 files changed, 283 insertions(+), 177 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 144b004e4de82..b0a1ea95d028e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -14,6 +14,7 @@
 #include "intel_gt_sysfs.h"
 #include "intel_gt_sysfs_pm.h"
 #include "intel_rc6.h"
+#include "intel_rps.h"
 
 #ifdef CONFIG_PM
 enum intel_gt_sysfs_op {
@@ -21,6 +22,30 @@ enum intel_gt_sysfs_op {
INTEL_GT_SYSFS_MAX,
 };
 
+static int
+sysfs_gt_attribute_w_func(struct device *dev, struct device_attribute *attr,
+ int (func)(struct intel_gt *gt, u32 val), u32 val)
+{
+   struct intel_gt *gt;
+   int ret;
+
+   if (!is_object_gt(&dev->kobj)) {
+   int i;
+   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+   for_each_gt(gt, i915, i) {
+   ret = func(gt, val);
+   if (ret)
+   break;
+   }
+   } else {
+   gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   ret = func(gt, val);
+   }
+
+   return ret;
+}
+
 static u32
 sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
  u32 (func)(struct intel_gt *gt),
@@ -62,6 +87,7 @@ sysfs_gt_attribute_r_func(struct device *dev, struct 
device_attribute *attr,
 #define sysfs_gt_attribute_r_min_func(d, a, f) \
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MIN)
 
+/* Frequency interfaces will show the maximum frequency value */
 #define sysfs_gt_attribute_r_max_func(d, a, f) \
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MAX)
 
@@ -238,7 +264,264 @@ static void intel_sysfs_rc6_init(struct intel_gt *gt, 
struct kobject *kobj)
 }
 #endif /* CONFIG_PM */
 
+static u32 __act_freq_mhz_show(struct intel_gt *gt)
+{
+   return intel_rps_read_actual_frequency(>->rps);
+}
+
+static ssize_t act_freq_mhz_show(struct device *dev,
+struct device_attribute *attr, char *buff)
+{
+   u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr,
+   __act_freq_mhz_show);
+
+   return sysfs_emit(buff, "%u\n", actual_freq);
+}
+
+static u32 __cur_freq_mhz_show(struct intel_gt *gt)
+{
+   return intel_rps_get_requested_frequency(>->rps);
+}
+
+static ssize_t cur_freq_mhz_show(struct device *dev,
+struct device_attribute *attr, char *buff)
+{
+   u32 cur

[Intel-gfx] [PATCH v7 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface

2022-03-18 Thread Andi Shyti

Now tiles have their own sysfs interfaces under the gt/
directory. Because RC6 is a property that can be configured on a
tile basis, then each tile should have its own interface

The new sysfs structure will have a similar layout for the 4 tile
case:

/sys/.../card0
 ├── gt
 │   ├── gt0
 │   │   ├── id
 │   │   ├── rc6_enable
 │   │   ├── rc6_residency_ms
 .   .   .
 .   .   .
 .   .
 │   └── gtN
 │   ├── id
 │   ├── rc6_enable
 │   ├── rc6_residency_ms
 │   .
 │   .
 │
 └── power/-+
  ├── rc6_enable|Original interface
  ├── rc6_residency_ms  +->  kept as existing ABI;
  . |it multiplexes over
  . |the GTs
   -+

The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
reading they provide the average value from all the GTs.

This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Signed-off-by: Lucas De Marchi 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c|  19 ++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 244 
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h |  15 ++
 drivers/gpu/drm/i915/i915_sysfs.c   | 128 --
 5 files changed, 279 insertions(+), 128 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 29523848396e4..46af9379803d8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -106,6 +106,7 @@ gt-y += \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
gt/intel_gt_sysfs.o \
+   gt/intel_gt_sysfs_pm.o \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index d508319612944..8ec8bc660c8c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -13,6 +13,7 @@
 #include "i915_sysfs.h"
 #include "intel_gt.h"
 #include "intel_gt_sysfs.h"
+#include "intel_gt_sysfs_pm.h"
 #include "intel_gt_types.h"
 #include "intel_rc6.h"
 
@@ -50,6 +51,11 @@ struct intel_gt *intel_gt_sysfs_get_drvdata(struct device 
*dev,
return kobj_to_gt(kobj);
 }
 
+static struct kobject *gt_get_parent_obj(struct intel_gt *gt)
+{
+   return >->i915->drm.primary->kdev->kobj;
+}
+
 static ssize_t id_show(struct device *dev,
   struct device_attribute *attr,
   char *buf)
@@ -81,6 +87,17 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
 {
struct kobj_gt *kg;
 
+   /*
+* We need to make things right with the
+* ABI compatibility. The files were originally
+* generated under the parent directory.
+*
+* We generate the files only for gt 0
+* to avoid duplicates.
+*/
+   if (gt_is_root(gt))
+   intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
+
kg = kzalloc(sizeof(*kg), GFP_KERNEL);
if (!kg)
goto exit_fail;
@@ -92,6 +109,8 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
if (kobject_add(&kg->base, gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_kobj_put;
 
+   intel_gt_sysfs_pm_init(gt, &kg->base);
+
return;
 
 exit_kobj_put:
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
new file mode 100644
index 0..144b004e4de82
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_regs.h"
+#include "intel_gt_sysfs.h"
+#include "intel_gt_sysfs_pm.h"
+#include "intel_rc6.h"
+
+#ifdef CONFIG_PM
+enum intel_gt_sysfs_op {
+   INTEL_GT_SYSFS_MIN = 0,
+   INTEL_GT_SYSFS_MAX,
+};
+
+static u32
+sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
+ u32 (func)(struct intel_gt *gt),
+ enum intel_gt_sysfs_op op)
+{
+   struct intel_gt *gt;
+   u32 ret;
+
+   ret = (op == INTEL_GT_SYSFS_

[Intel-gfx] [PATCH v7 4/7] drm/i915/gt: create per-tile sysfs interface

2022-03-18 Thread Andi Shyti

Now that we have tiles we want each of them to have its own
interface. A directory "gt/" is created under "cardN/" that will
contain as many diroctories as the tiles.

In the coming patches tile related interfaces will be added. For
now the sysfs gt structure simply has an id interface related
to the current tile count.

The directory structure will follow this scheme:

/sys/.../card0
 └── gt
     ├── gt0
     │   └── id
 :
 :
 └─- gtN
         └── id

This new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Cc: Chris Wilson 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Sujaritha Sundaresan 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_gt.c   |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  34 
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_sysfs.c|   7 +-
 drivers/gpu/drm/i915/i915_sysfs.h|   3 +
 7 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a54e84e054660..29523848396e4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -105,6 +105,7 @@ gt-y += \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
+   gt/intel_gt_sysfs.o \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index cfac4a913642e..5001a6168d566 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -26,6 +26,7 @@
 #include "intel_rc6.h"
 #include "intel_renderstate.h"
 #include "intel_rps.h"
+#include "intel_gt_sysfs.h"
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
@@ -458,6 +459,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>->rps);
 
intel_gt_debugfs_register(gt);
+   intel_gt_sysfs_register(gt);
 }
 
 static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
new file mode 100644
index 0..d508319612944
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_sysfs.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+bool is_object_gt(struct kobject *kobj)
+{
+   return !strncmp(kobj->name, "gt", 2);
+}
+
+static struct intel_gt *kobj_to_gt(struct kobject *kobj)
+{
+   return container_of(kobj, struct kobj_gt, base)->gt;
+}
+
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+   const char *name)
+{
+   struct kobject *kobj = &dev->kobj;
+
+   /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/ or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+   if (!is_object_gt(kobj)) {
+   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+   return to_gt(i915);
+   }
+
+   return kobj_to_gt(kobj);
+}
+
+static ssize_t id_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+
+   return sysfs_emit(buf, "%u\n", gt->info.id);
+}
+static DEVICE_ATTR_RO(id);
+
+static struct attribute *id_attrs[] = {
+   &dev_attr_id.attr,
+   NULL,
+};
+ATTRIBUTE_GROUPS(id);
+
+static void kobj_gt_release(struct kobject *kobj)
+{
+   kfree(kobj);
+}
+
+static struct kobj_type kobj_gt_type = {
+   .release = kobj_gt_release,
+   .sysfs_ops = &kobj_sysfs_ops,
+   .default_groups = id_groups,
+};
+
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+   struct kobj_gt *kg;
+
+   kg = kzalloc(sizeof(*kg), GFP_KERNEL);
+   if (!kg)
+   goto exit_fail;
+
+   kobject_init(&kg->base, &kobj_gt_type);
+   kg->gt = gt;
+
+   /* xfer ownership to sysfs tr

[Intel-gfx] [PATCH v7 3/7] drm/i915: Prepare for multiple GTs

2022-03-18 Thread Andi Shyti

From: Tvrtko Ursulin 

On a multi-tile platform, each tile has its own registers + GGTT
space, and BAR 0 is extended to cover all of them.

Up to four GTs are supported in i915->gt[], with slot zero
shadowing the existing i915->gt0 to enable source compatibility
with legacy driver paths. A for_each_gt macro is added to iterate
over the GTs and will be used by upcoming patches that convert
various parts of the driver to be multi-gt aware.

Only the primary/root tile is initialized for now; the other
tiles will be detected and plugged in by future patches once the
necessary infrastructure is in place to handle them.

Signed-off-by: Abdiel Janulgue 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
Signed-off-by: Andi Shyti 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Reviewed-by: Matt Roper 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_gt.c| 133 --
 drivers/gpu/drm/i915/gt/intel_gt.h|  17 ++-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |   9 +-
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   7 +
 drivers/gpu/drm/i915/i915_driver.c|  28 ++--
 drivers/gpu/drm/i915/i915_drv.h   |   6 +
 drivers/gpu/drm/i915/intel_memory_region.h|   3 +
 drivers/gpu/drm/i915/intel_uncore.c   |  11 +-
 drivers/gpu/drm/i915/intel_uncore.h   |   3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  13 +-
 10 files changed, 184 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index ca875ba3e2a9d..cfac4a913642e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -29,7 +29,7 @@
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
-void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+static void __intel_gt_init_early(struct intel_gt *gt)
 {
spin_lock_init(>->irq_lock);
 
@@ -51,17 +51,23 @@ void __intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
intel_rps_init_early(>->rps);
 }
 
-void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+/* Preliminary initialization of Tile 0 */
+void intel_root_gt_init_early(struct drm_i915_private *i915)
 {
+   struct intel_gt *gt = to_gt(i915);
+
gt->i915 = i915;
gt->uncore = &i915->uncore;
+
+   __intel_gt_init_early(gt);
 }
 
-int intel_gt_probe_lmem(struct intel_gt *gt)
+static int intel_gt_probe_lmem(struct intel_gt *gt)
 {
struct drm_i915_private *i915 = gt->i915;
+   unsigned int instance = gt->info.id;
+   int id = INTEL_REGION_LMEM_0 + instance;
struct intel_memory_region *mem;
-   int id;
int err;
 
mem = intel_gt_setup_lmem(gt);
@@ -76,9 +82,8 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
return err;
}
 
-   id = INTEL_REGION_LMEM_0;
-
mem->id = id;
+   mem->instance = instance;
 
intel_memory_region_set_name(mem, "local%u", mem->instance);
 
@@ -807,16 +812,21 @@ void intel_gt_driver_release(struct intel_gt *gt)
intel_gt_fini_hwconfig(gt);
 }
 
-void intel_gt_driver_late_release(struct intel_gt *gt)
+void intel_gt_driver_late_release_all(struct drm_i915_private *i915)
 {
+   struct intel_gt *gt;
+   unsigned int id;
+
/* We need to wait for inflight RCU frees to release their grip */
rcu_barrier();
 
-   intel_uc_driver_late_release(>->uc);
-   intel_gt_fini_requests(gt);
-   intel_gt_fini_reset(gt);
-   intel_gt_fini_timelines(gt);
-   intel_engines_free(gt);
+   for_each_gt(gt, i915, id) {
+   intel_uc_driver_late_release(>->uc);
+   intel_gt_fini_requests(gt);
+   intel_gt_fini_reset(gt);
+   intel_gt_fini_timelines(gt);
+   intel_engines_free(gt);
+   }
 }
 
 /**
@@ -1013,6 +1023,105 @@ void intel_gt_report_steering(struct drm_printer *p, 
struct intel_gt *gt,
}
 }
 
+static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
+{
+   int ret;
+
+   if (!gt_is_root(gt)) {
+   struct intel_uncore_mmio_debug *mmio_debug;
+   struct intel_uncore *uncore;
+
+   uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+   if (!uncore)
+   return -ENOMEM;
+
+   mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
+   if (!mmio_debug) {
+   kfree(uncore);
+   return -ENOMEM;
+   }
+
+   gt->uncore = uncore;
+   gt->uncore->debug = mmio_debug;
+
+   __intel_gt_init_early(gt);
+   }
+
+   intel_uncore_init_early(gt->uncore, gt);
+
+   ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
+   if (ret)
+   return ret;
+
+   gt->phys_addr = phys_addr;
+
+   r

[Intel-gfx] [PATCH v7 0/7] Introduce multitile support

2022-03-18 Thread Andi Shyti

Hi,

This is the second series that prepares i915 to host multitile
platforms. It introduces the for_each_gt() macro that loops over
the tiles to perform per gt actions.

This patch is a combination of two patches developed originally
by Abdiel, who introduced some refactoring during probe, and then
Tvrtko has added the necessary tools to start using the various
tiles.

The second patch re-organises the sysfs interface to expose the
API for each of the GTs. I decided to prioritise this patch
over others to unblock Sujaritha for further development.

A third series will still follow this.

Thanks Michal and Andrzej for the reviews and support!

Thanks,
Andi

Patchwork: https://patchwork.freedesktop.org/series/98741/

Changelog
=
v6 -> v7
 - fixed a mock selftest error by initializing i915->gt[0]
   (thanks Tvrtko!)
 - removed spurious file added by mistake (thanks Matt!)
 - improved commit log in patch 7 (thanks Suja!)

v5 -> v6
 - address all Michal and Andrzej's reviews that consist mainly
   in code refactoring.

v4 -> v5
 - fixed Michal's reviews.
 - the sysfs patches have been split in 3 parts to make reviews
   easier.
 - Sujaritha's patch on pm throttle has been queued.
 - INTEL_REGION_LMEM has been renamed to INTEL_REGION_LMEM_0
 - added the gt_is_root() helper
 - the sysfs files will be called intel_gt_sysfs_* instead of
   sysfs_gt_*

v3 -> v4
 - fixed Tvrtko's review:
- remove the SYSFS_DEPRECATED_V2 mention from the commit log
- reworded the error message when accessing deprecated files
- errors in sysfs are printed as warnings as they are not
  fatal
- the inline functions are moved to be out of line.
   and some other minor refactoring.

v2 -> v3
 - Added Matt and Sujaritha's r-b for patch 1 and 2.
 - Reworded the commit of patch 2 to underline the fact that the
   interface is useful also when used manually.

v1 -> v2
 - fixed a couple of coding style issues in patch 2.

Andi Shyti (5):
  drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
  drm/i915/gt: add gt_is_root() helper
  drm/i915/gt: create per-tile sysfs interface
  drm/i915/gt: Create per-tile RC6 sysfs interface
  drm/i915/gt: Create per-tile RPS sysfs interfaces

Sujaritha Sundaresan (1):
  drm/i915/gt: Add sysfs throttle frequency interfaces

Tvrtko Ursulin (1):
  drm/i915: Prepare for multiple GTs

 drivers/gpu/drm/i915/Makefile |   2 +
 drivers/gpu/drm/i915/display/intel_fb.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |   2 +-
 .../drm/i915/display/intel_plane_initial.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  |   4 +-
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |   6 +-
 .../drm/i915/gem/selftests/i915_gem_migrate.c |   8 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 135 +++-
 drivers/gpu/drm/i915/gt/intel_gt.h|  22 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |   9 +-
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c  | 122 
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h  |  34 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 601 ++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h   |  15 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   7 +
 drivers/gpu/drm/i915/gt/intel_rps.c   |  18 +
 drivers/gpu/drm/i915/gt/intel_rps.h   |   4 +
 drivers/gpu/drm/i915/i915_driver.c|  28 +-
 drivers/gpu/drm/i915/i915_drv.h   |   8 +
 drivers/gpu/drm/i915/i915_reg.h   |  11 +
 drivers/gpu/drm/i915/i915_sysfs.c | 310 +
 drivers/gpu/drm/i915/i915_sysfs.h |   3 +
 drivers/gpu/drm/i915/intel_memory_region.c|   2 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   7 +-
 drivers/gpu/drm/i915/intel_uncore.c   |  11 +-
 drivers/gpu/drm/i915/intel_uncore.h   |   3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  13 +-
 27 files changed, 1023 insertions(+), 366 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h


base-commit: 76874531ffae41683316380bd6d6227bbba12148
-- 
2.35.1

[Intel-gfx] [PATCH v7 2/7] drm/i915/gt: add gt_is_root() helper

2022-03-18 Thread Andi Shyti

The "gt_is_root(struct intel_gt *gt)" helper return true if the
gt is the root gt, which means that its id is 0. Return false
otherwise.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Andi Shyti 
Reviewed-by: Michal Wajdeczko 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 996f8f3c17b95..ce471aa5c83d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -19,6 +19,11 @@ struct drm_printer;
  ##__VA_ARGS__);   \
 } while (0)
 
+static inline bool gt_is_root(struct intel_gt *gt)
+{
+   return !gt->info.id;
+}
+
 static inline struct intel_gt *uc_to_gt(struct intel_uc *uc)
 {
return container_of(uc, struct intel_gt, uc);
-- 
2.35.1

[Intel-gfx] [PATCH v7 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0

2022-03-18 Thread Andi Shyti

With the upcoming multitile support each tile will have its own
local memory. Mark the current LMEM with the suffix '0' to
emphasise that it belongs to the root tile.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Andi Shyti 
Reviewed-by: Michal Wajdeczko 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fb.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_plane_initial.c| 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  | 4 ++--
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c  | 6 +++---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 8 
 drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 2 +-
 drivers/gpu/drm/i915/intel_memory_region.h| 4 ++--
 9 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 94c57facbb463..e9ad142ac40fa 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1994,7 +1994,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
 
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
-   if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj, 
INTEL_REGION_LMEM)) {
+   if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj, 
INTEL_REGION_LMEM_0)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index a307b4993bcf3..bd6e7c98e751d 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -140,7 +140,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
else if (!ret && HAS_LMEM(dev_priv))
-   ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM);
+   ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0);
/* TODO: Do we need to sync when migration becomes async? */
if (!ret)
ret = i915_gem_object_pin_pages(obj);
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 7979929bb6323..d10f27d0b7b09 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -72,7 +72,7 @@ initial_plane_vma(struct drm_i915_private *i915,
}
 
phys_base = pte & I915_GTT_PAGE_MASK;
-   mem = i915->mm.regions[INTEL_REGION_LMEM];
+   mem = i915->mm.regions[INTEL_REGION_LMEM_0];
 
/*
 * We don't currently expect this to ever be placed in the
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index ede084f36ca93..b2aaf620741e3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -102,7 +102,7 @@ __i915_gem_object_create_lmem_with_ps(struct 
drm_i915_private *i915,
  resource_size_t page_size,
  unsigned int flags)
 {
-   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
 size, page_size, flags);
 }
 
@@ -137,6 +137,6 @@ i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
unsigned int flags)
 {
-   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
 size, 0, flags);
 }
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index b071a58dd6daa..a342fd387d4ef 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -88,7 +88,7 @@ static int igt_dmabuf_import_self(void *arg)
 static int igt_dmabuf_import_same_driver_lmem(void *arg)
 {
struct drm_i915_private *i915 = arg;
-   struct intel_memory_region *lmem = i915->mm.regions[INTEL_REGION_LMEM];
+   struct intel_memory_region *lmem = 
i915->mm.regions[INTEL_REGION_LMEM_0];
struct drm_i915_gem_object *obj;
struct drm_gem_object *import;
struct dma_buf *dmabuf;
@@ -252,10 +252,10 @@ static int igt_dmabuf_import_same_driver_lmem_smem(void 
*arg)
struct drm_i915_private *i915 = arg;

Re: [Intel-gfx] [PATCH v6 0/7] Introduce multitile support

2022-03-18 Thread Andi Shyti

Arghhh Sorry for spamming! I sent the wrong series!

Please ignore this.

Andi

On Sat, Mar 19, 2022 at 12:46:33AM +0200, Andi Shyti wrote:
> Hi,
> 
> This is the second series that prepares i915 to host multitile
> platforms. It introduces the for_each_gt() macro that loops over
> the tiles to perform per gt actions.
> 
> This patch is a combination of two patches developed originally
> by Abdiel, who introduced some refactoring during probe, and then
> Tvrtko has added the necessary tools to start using the various
> tiles.
> 
> The second patch re-organises the sysfs interface to expose the
> API for each of the GTs. I decided to prioritise this patch
> over others to unblock Sujaritha for further development.
> 
> A third series will still follow this.
> 
> Thanks Michal and Andrzej for the reviews and support!
> 
> Thanks,
> Andi
> 
> Patchwork: https://patchwork.freedesktop.org/series/98741/
> 
> Changelog
> =
> v5 -> v6
>  - address all Michal and Andrzej's reviews that consist mainly
>in code refactoring.
> 
> v4 -> v5
>  - fixed Michal's reviews.
>  - the sysfs patches have been split in 3 parts to make reviews
>easier.
>  - Sujaritha's patch on pm throttle has been queued.
>  - INTEL_REGION_LMEM has been renamed to INTEL_REGION_LMEM_0
>  - added the gt_is_root() helper
>  - the sysfs files will be called intel_gt_sysfs_* instead of
>sysfs_gt_*
> 
> v3 -> v4
>  - fixed Tvrtko's review:
> - remove the SYSFS_DEPRECATED_V2 mention from the commit log
> - reworded the error message when accessing deprecated files
> - errors in sysfs are printed as warnings as they are not
>   fatal
> - the inline functions are moved to be out of line.
>and some other minor refactoring.
> 
> v2 -> v3
>  - Added Matt and Sujaritha's r-b for patch 1 and 2.
>  - Reworded the commit of patch 2 to underline the fact that the
>interface is useful also when used manually.
> 
> v1 -> v2
>  - fixed a couple of coding style issues in patch 2.
> 
> Andi Shyti (5):
>   drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
>   drm/i915/gt: add gt_is_root() helper
>   drm/i915/gt: create per-tile sysfs interface
>   drm/i915/gt: Create per-tile RC6 sysfs interface
>   drm/i915/gt: Create per-tile RPS sysfs interfaces
> 
> Sujaritha Sundaresan (1):
>   drm/i915/gt: Adding new sysfs frequency attributes
> 
> Tvrtko Ursulin (1):
>   drm/i915: Prepare for multiple GTs
> 
>  drivers/gpu/drm/i915/Makefile |   2 +
>  drivers/gpu/drm/i915/display/intel_fb.c   |   2 +-
>  drivers/gpu/drm/i915/display/intel_fb_pin.c   |   2 +-
>  .../drm/i915/display/intel_plane_initial.c|   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_lmem.c  |   4 +-
>  .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |   6 +-
>  .../drm/i915/gem/selftests/i915_gem_migrate.c |   8 +-
>  drivers/gpu/drm/i915/gt/intel_gt.c| 135 +++-
>  drivers/gpu/drm/i915/gt/intel_gt.h|  22 +-
>  drivers/gpu/drm/i915/gt/intel_gt_pm.c |   9 +-
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c  | 122 
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h  |  34 +
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 601 ++
>  drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h   |  15 +
>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |   7 +
>  drivers/gpu/drm/i915/gt/intel_rps.c   |  18 +
>  drivers/gpu/drm/i915/gt/intel_rps.h   |   4 +
>  drivers/gpu/drm/i915/i915_driver.c|  28 +-
>  drivers/gpu/drm/i915/i915_drv.h   |   8 +
>  drivers/gpu/drm/i915/i915_reg.h   |  11 +
>  drivers/gpu/drm/i915/i915_sysfs.c | 310 +
>  drivers/gpu/drm/i915/i915_sysfs.h |   3 +
>  drivers/gpu/drm/i915/intel_memory_region.c|   2 +-
>  drivers/gpu/drm/i915/intel_memory_region.h|   7 +-
>  drivers/gpu/drm/i915/intel_uncore.c   |  11 +-
>  drivers/gpu/drm/i915/intel_uncore.h   |   3 +-
>  .../gpu/drm/i915/selftests/mock_gem_device.c  |   7 +-
>  scripts/extract-cert  | Bin 0 -> 17952 bytes
>  28 files changed, 1017 insertions(+), 366 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
>  create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
>  create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
>  create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h
>  create mode 100755 scripts/extract-cert
> 
> -- 
> 2.35.1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101549/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce multitile support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Introduce multitile support
URL   : https://patchwork.freedesktop.org/series/101549/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
ac3a14b22f9a drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
373961700ada drm/i915/gt: add gt_is_root() helper
8fbc02b492a6 drm/i915: Prepare for multiple GTs
-:248: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'id__' - possible 
side-effects?
#248: FILE: drivers/gpu/drm/i915/gt/intel_gt.h:103:
+#define for_each_gt(gt__, i915__, id__) \
+   for ((id__) = 0; \
+(id__) < I915_MAX_GT; \
+(id__)++) \
+   for_each_if(((gt__) = (i915__)->gt[(id__)]))

total: 0 errors, 0 warnings, 1 checks, 429 lines checked
287368b2d564 drm/i915/gt: create per-tile sysfs interface
-:70: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#70: 
new file mode 100644

total: 0 errors, 1 warnings, 0 checks, 196 lines checked
a4492f268173 drm/i915/gt: Create per-tile RC6 sysfs interface
-:121: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#121: 
new file mode 100644

-:157: CHECK:SPACING: No space is necessary after a cast
#157: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:32:
+   ret = (op == INTEL_GT_SYSFS_MAX) ? 0 : (u32) -1;

total: 0 errors, 1 warnings, 1 checks, 453 lines checked
a85aedc94158 drm/i915/gt: Create per-tile RPS sysfs interfaces
-:319: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_mode' - possible 
side-effects?
#319: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:458:
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
+   struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, 
_show, _store); \
+   struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, 
_mode, _show, _store)

-:319: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_show' - possible 
side-effects?
#319: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:458:
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
+   struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, 
_show, _store); \
+   struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, 
_mode, _show, _store)

-:319: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_store' - possible 
side-effects?
#319: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:458:
+#define INTEL_GT_RPS_SYSFS_ATTR(_name, _mode, _show, _store) \
+   struct device_attribute dev_attr_gt_##_name = __ATTR(gt_##_name, _mode, 
_show, _store); \
+   struct device_attribute dev_attr_rps_##_name = __ATTR(rps_##_name, 
_mode, _show, _store)

-:333: CHECK:CAMELCASE: Avoid CamelCase: 
#333: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:472:
+static INTEL_GT_RPS_SYSFS_ATTR_RO(RPn_freq_mhz);

-:347: CHECK:CAMELCASE: Avoid CamelCase: 
#347: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:486:
+   &dev_attr_##s##_RPn_freq_mhz.attr, \

total: 0 errors, 0 warnings, 5 checks, 503 lines checked
59ae69ae1370 drm/i915/gt: Adding new sysfs frequency attributes
-:63: CHECK:SPACING: No space is necessary after a cast
#63: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:521:
+   (struct intel_gt_bool_throttle_attr *) attr;

total: 0 errors, 0 warnings, 1 checks, 147 lines checked

[Intel-gfx] [PATCH v6 7/7] drm/i915/gt: Adding new sysfs frequency attributes

2022-03-18 Thread Andi Shyti

From: Sujaritha Sundaresan 

This patch adds the following new sysfs frequency attributes:

- punit_req_freq_mhz
- throttle_reason_status
- throttle_reason_pl1
- throttle_reason_pl2
- throttle_reason_pl4
- throttle_reason_thermal
- throttle_reason_prochot
- throttle_reason_ratl
- throttle_reason_vr_thermalert
- throttle_reason_vr_tdc

Signed-off-by: Sujaritha Sundaresan 
Cc: Dale B Stimson 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 74 +
 drivers/gpu/drm/i915/gt/intel_rps.c | 18 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  4 ++
 drivers/gpu/drm/i915/i915_reg.h | 11 +++
 4 files changed, 107 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index b0a1ea95d028e..26cbfa6477d12 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -8,6 +8,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "i915_reg.h"
 #include "i915_sysfs.h"
 #include "intel_gt.h"
 #include "intel_gt_regs.h"
@@ -493,6 +494,69 @@ static DEVICE_ATTR_RO(vlv_rpe_freq_mhz);
 static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
 static const struct attribute * const gen6_gt_attrs[]  = GEN6_GT_ATTR;
 
+static ssize_t punit_req_freq_mhz_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   u32 preq = intel_rps_read_punit_req_frequency(>->rps);
+
+   return sysfs_emit(buff, "%u\n", preq);
+}
+
+struct intel_gt_bool_throttle_attr {
+   struct attribute attr;
+   ssize_t (*show)(struct device *dev, struct device_attribute *attr,
+   char *buf);
+   i915_reg_t reg32;
+   u32 mask;
+};
+
+static ssize_t throttle_reason_bool_show(struct device *dev,
+struct device_attribute *attr,
+char *buff)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   struct intel_gt_bool_throttle_attr *t_attr =
+   (struct intel_gt_bool_throttle_attr *) attr;
+   bool val = rps_read_mask_mmio(>->rps, t_attr->reg32, t_attr->mask);
+
+   return sysfs_emit(buff, "%u\n", val);
+}
+
+#define INTEL_GT_RPS_BOOL_ATTR_RO(sysfs_func__, mask__) \
+struct intel_gt_bool_throttle_attr attr_##sysfs_func__ = { \
+   .attr = { .name = __stringify(sysfs_func__), .mode = 0444 }, \
+   .show = throttle_reason_bool_show, \
+   .reg32 = GT0_PERF_LIMIT_REASONS, \
+   .mask = mask__, \
+}
+
+static DEVICE_ATTR_RO(punit_req_freq_mhz);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_status, 
GT0_PERF_LIMIT_REASONS_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl1, POWER_LIMIT_1_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl2, POWER_LIMIT_2_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_pl4, POWER_LIMIT_4_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_thermal, THERMAL_LIMIT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_prochot, PROCHOT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_ratl, RATL_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_thermalert, 
VR_THERMALERT_MASK);
+static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_tdc, VR_TDC_MASK);
+
+static const struct attribute *freq_attrs[] = {
+   &dev_attr_punit_req_freq_mhz.attr,
+   &attr_throttle_reason_status.attr,
+   &attr_throttle_reason_pl1.attr,
+   &attr_throttle_reason_pl2.attr,
+   &attr_throttle_reason_pl4.attr,
+   &attr_throttle_reason_thermal.attr,
+   &attr_throttle_reason_prochot.attr,
+   &attr_throttle_reason_ratl.attr,
+   &attr_throttle_reason_vr_thermalert.attr,
+   &attr_throttle_reason_vr_tdc.attr,
+   NULL
+};
+
 static int intel_sysfs_rps_init(struct intel_gt *gt, struct kobject *kobj,
const struct attribute * const *attrs)
 {
@@ -524,4 +588,14 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct 
kobject *kobj)
drm_warn(>->i915->drm,
 "failed to create gt%u RPS sysfs files (%pe)",
 gt->info.id, ERR_PTR(ret));
+
+   /* end of the legacy interfaces */
+   if (!is_object_gt(kobj))
+   return;
+
+   ret = sysfs_create_files(kobj, freq_attrs);
+   if (ret)
+   drm_warn(>->i915->drm,
+"failed to create gt%u throttle sysfs files (%pe)",
+gt->info.id, ERR_PTR(ret));
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index a9c13b1a30181..6c9fdf7906c50 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+

[Intel-gfx] [PATCH v6 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces

2022-03-18 Thread Andi Shyti

Now tiles have their own sysfs interfaces under the gt/
directory. Because RPS is a property that can be configured on a
tile basis, then each tile should have its own interface

The new sysfs structure will have a similar layout for the 4 tile
case:

/sys/.../card0
 ├── gt
 │   ├── gt0
 │   │   ├── id
 │   │   ├── rc6_enable
 │   │   ├── rc6_residency_ms
 │   │   ├── rps_act_freq_mhz
 │   │   ├── rps_boost_freq_mhz
 │   │   ├── rps_cur_freq_mhz
 │   │   ├── rps_max_freq_mhz
 │   │   ├── rps_min_freq_mhz
 │   │   ├── rps_RP0_freq_mhz
 │   │   ├── rps_RP1_freq_mhz
 │   │   └── rps_RPn_freq_mhz
 .   .
 .   .
 .   .
 │   └── gtN
 │   ├── id
 │   ├── rc6_enable
 │   ├── rc6_residency_ms
 │   ├── rps_act_freq_mhz
 │   ├── rps_boost_freq_mhz
 │   ├── rps_cur_freq_mhz
 │   ├── rps_max_freq_mhz
 │   ├── rps_min_freq_mhz
 │   ├── rps_RP0_freq_mhz
 │   ├── rps_RP1_freq_mhz
 │   └── rps_RPn_freq_mhz
 ├── gt_act_freq_mhz   -+
 ├── gt_boost_freq_mhz  |
 ├── gt_cur_freq_mhz|Original interface
 ├── gt_max_freq_mhz+─-> kept as existing ABI;
 ├── gt_min_freq_mhz|it points to gt0/
 ├── gt_RP0_freq_mhz|
 ├── gt_RP1_freq_mhz|
 └── gt_RPn_freq_mhz   -+

The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
writing they loop through all the GTs and write the information
on each interface. When reading they provide the average value
from all the GTs.

This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Signed-off-by: Lucas De Marchi 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 283 
 drivers/gpu/drm/i915/i915_sysfs.c   | 177 
 2 files changed, 283 insertions(+), 177 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 144b004e4de82..b0a1ea95d028e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -14,6 +14,7 @@
 #include "intel_gt_sysfs.h"
 #include "intel_gt_sysfs_pm.h"
 #include "intel_rc6.h"
+#include "intel_rps.h"
 
 #ifdef CONFIG_PM
 enum intel_gt_sysfs_op {
@@ -21,6 +22,30 @@ enum intel_gt_sysfs_op {
INTEL_GT_SYSFS_MAX,
 };
 
+static int
+sysfs_gt_attribute_w_func(struct device *dev, struct device_attribute *attr,
+ int (func)(struct intel_gt *gt, u32 val), u32 val)
+{
+   struct intel_gt *gt;
+   int ret;
+
+   if (!is_object_gt(&dev->kobj)) {
+   int i;
+   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+   for_each_gt(gt, i915, i) {
+   ret = func(gt, val);
+   if (ret)
+   break;
+   }
+   } else {
+   gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+   ret = func(gt, val);
+   }
+
+   return ret;
+}
+
 static u32
 sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
  u32 (func)(struct intel_gt *gt),
@@ -62,6 +87,7 @@ sysfs_gt_attribute_r_func(struct device *dev, struct 
device_attribute *attr,
 #define sysfs_gt_attribute_r_min_func(d, a, f) \
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MIN)
 
+/* Frequency interfaces will show the maximum frequency value */
 #define sysfs_gt_attribute_r_max_func(d, a, f) \
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MAX)
 
@@ -238,7 +264,264 @@ static void intel_sysfs_rc6_init(struct intel_gt *gt, 
struct kobject *kobj)
 }
 #endif /* CONFIG_PM */
 
+static u32 __act_freq_mhz_show(struct intel_gt *gt)
+{
+   return intel_rps_read_actual_frequency(>->rps);
+}
+
+static ssize_t act_freq_mhz_show(struct device *dev,
+struct device_attribute *attr, char *buff)
+{
+   u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr,
+   __act_freq_mhz_show);
+
+   return sysfs_emit(buff, "%u\n", actual_freq);
+}
+
+static u32 __cur_freq_mhz_show(struct intel_gt *gt)
+{
+   return intel_rps_get_requested_frequency(>->rps);
+}
+
+static ssize_t cur_freq_mhz_show(struct device *dev,
+struct device_attribute *attr, char *buff)
+{
+   u32 cur_freq = sysfs_gt_attribute_r

[Intel-gfx] [PATCH v6 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface

2022-03-18 Thread Andi Shyti

Now tiles have their own sysfs interfaces under the gt/
directory. Because RC6 is a property that can be configured on a
tile basis, then each tile should have its own interface

The new sysfs structure will have a similar layout for the 4 tile
case:

/sys/.../card0
 ├── gt
 │   ├── gt0
 │   │   ├── id
 │   │   ├── rc6_enable
 │   │   ├── rc6_residency_ms
 .   .   .
 .   .   .
 .   .
 │   └── gtN
 │   ├── id
 │   ├── rc6_enable
 │   ├── rc6_residency_ms
 │   .
 │   .
 │
 └── power/-+
  ├── rc6_enable|Original interface
  ├── rc6_residency_ms  +->  kept as existing ABI;
  . |it multiplexes over
  . |the GTs
   -+

The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
reading they provide the average value from all the GTs.

This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Signed-off-by: Lucas De Marchi 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c|  19 ++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 244 
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h |  15 ++
 drivers/gpu/drm/i915/i915_sysfs.c   | 128 --
 5 files changed, 279 insertions(+), 128 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 181d71d5ba3c0..bcc301351aa39 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -106,6 +106,7 @@ gt-y += \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
gt/intel_gt_sysfs.o \
+   gt/intel_gt_sysfs_pm.o \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index d508319612944..8ec8bc660c8c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -13,6 +13,7 @@
 #include "i915_sysfs.h"
 #include "intel_gt.h"
 #include "intel_gt_sysfs.h"
+#include "intel_gt_sysfs_pm.h"
 #include "intel_gt_types.h"
 #include "intel_rc6.h"
 
@@ -50,6 +51,11 @@ struct intel_gt *intel_gt_sysfs_get_drvdata(struct device 
*dev,
return kobj_to_gt(kobj);
 }
 
+static struct kobject *gt_get_parent_obj(struct intel_gt *gt)
+{
+   return >->i915->drm.primary->kdev->kobj;
+}
+
 static ssize_t id_show(struct device *dev,
   struct device_attribute *attr,
   char *buf)
@@ -81,6 +87,17 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
 {
struct kobj_gt *kg;
 
+   /*
+* We need to make things right with the
+* ABI compatibility. The files were originally
+* generated under the parent directory.
+*
+* We generate the files only for gt 0
+* to avoid duplicates.
+*/
+   if (gt_is_root(gt))
+   intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
+
kg = kzalloc(sizeof(*kg), GFP_KERNEL);
if (!kg)
goto exit_fail;
@@ -92,6 +109,8 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
if (kobject_add(&kg->base, gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_kobj_put;
 
+   intel_gt_sysfs_pm_init(gt, &kg->base);
+
return;
 
 exit_kobj_put:
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
new file mode 100644
index 0..144b004e4de82
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_regs.h"
+#include "intel_gt_sysfs.h"
+#include "intel_gt_sysfs_pm.h"
+#include "intel_rc6.h"
+
+#ifdef CONFIG_PM
+enum intel_gt_sysfs_op {
+   INTEL_GT_SYSFS_MIN = 0,
+   INTEL_GT_SYSFS_MAX,
+};
+
+static u32
+sysfs_gt_attribute_r_func(struct device *dev, struct device_attribute *attr,
+ u32 (func)(struct intel_gt *gt),
+ enum intel_gt_sysfs_op op)
+{
+   struct intel_gt *gt;
+   u32 ret;
+
+   ret = (op == INTEL_GT_SYSFS_

[Intel-gfx] [PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface

2022-03-18 Thread Andi Shyti

Now that we have tiles we want each of them to have its own
interface. A directory "gt/" is created under "cardN/" that will
contain as many diroctories as the tiles.

In the coming patches tile related interfaces will be added. For
now the sysfs gt structure simply has an id interface related
to the current tile count.

The directory structure will follow this scheme:

/sys/.../card0
 └── gt
     ├── gt0
     │   └── id
 :
 :
 └─- gtN
         └── id

This new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Sujaritha Sundaresan 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gt/intel_gt.c   |   2 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  34 
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/i915_sysfs.c|   7 +-
 drivers/gpu/drm/i915/i915_sysfs.h|   3 +
 scripts/extract-cert | Bin 0 -> 17952 bytes
 8 files changed, 151 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
 create mode 100755 scripts/extract-cert

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1a771ee5b1d01..181d71d5ba3c0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -105,6 +105,7 @@ gt-y += \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
gt/intel_gt_requests.o \
+   gt/intel_gt_sysfs.o \
gt/intel_gtt.o \
gt/intel_llc.o \
gt/intel_lrc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f66139021049d..a68d3d3c41653 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -26,6 +26,7 @@
 #include "intel_rc6.h"
 #include "intel_renderstate.h"
 #include "intel_rps.h"
+#include "intel_gt_sysfs.h"
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
@@ -458,6 +459,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>->rps);
 
intel_gt_debugfs_register(gt);
+   intel_gt_sysfs_register(gt);
 }
 
 static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
new file mode 100644
index 0..d508319612944
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "i915_drv.h"
+#include "i915_sysfs.h"
+#include "intel_gt.h"
+#include "intel_gt_sysfs.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+bool is_object_gt(struct kobject *kobj)
+{
+   return !strncmp(kobj->name, "gt", 2);
+}
+
+static struct intel_gt *kobj_to_gt(struct kobject *kobj)
+{
+   return container_of(kobj, struct kobj_gt, base)->gt;
+}
+
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
+   const char *name)
+{
+   struct kobject *kobj = &dev->kobj;
+
+   /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/ or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+   if (!is_object_gt(kobj)) {
+   struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+   return to_gt(i915);
+   }
+
+   return kobj_to_gt(kobj);
+}
+
+static ssize_t id_show(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+
+   return sysfs_emit(buf, "%u\n", gt->info.id);
+}
+static DEVICE_ATTR_RO(id);
+
+static struct attribute *id_attrs[] = {
+   &dev_attr_id.attr,
+   NULL,
+};
+ATTRIBUTE_GROUPS(id);
+
+static void kobj_gt_release(struct kobject *kobj)
+{
+   kfree(kobj);
+}
+
+static struct kobj_type kobj_gt_type = {
+   .release = kobj_gt_release,
+   .sysfs_ops = &kobj_sysfs_ops,
+   .default_groups = id_groups,
+};
+
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+   struct kobj_gt *kg;
+
+   kg = kzalloc(sizeof(*kg), GFP_KERNEL);
+   if (!kg)
+   goto exit_fail;
+
+   kobject_init(&kg->base, &kobj_gt_type);

[Intel-gfx] [PATCH v6 3/7] drm/i915: Prepare for multiple GTs

2022-03-18 Thread Andi Shyti

From: Tvrtko Ursulin 

On a multi-tile platform, each tile has its own registers + GGTT
space, and BAR 0 is extended to cover all of them.

Up to four GTs are supported in i915->gt[], with slot zero
shadowing the existing i915->gt0 to enable source compatibility
with legacy driver paths. A for_each_gt macro is added to iterate
over the GTs and will be used by upcoming patches that convert
various parts of the driver to be multi-gt aware.

Only the primary/root tile is initialized for now; the other
tiles will be detected and plugged in by future patches once the
necessary infrastructure is in place to handle them.

Signed-off-by: Abdiel Janulgue 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
Signed-off-by: Andi Shyti 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt.c| 133 --
 drivers/gpu/drm/i915/gt/intel_gt.h|  17 ++-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |   9 +-
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   7 +
 drivers/gpu/drm/i915/i915_driver.c|  28 ++--
 drivers/gpu/drm/i915/i915_drv.h   |   6 +
 drivers/gpu/drm/i915/intel_memory_region.h|   3 +
 drivers/gpu/drm/i915/intel_uncore.c   |  11 +-
 drivers/gpu/drm/i915/intel_uncore.h   |   3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   7 +-
 10 files changed, 178 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 4c077b3c38b73..f66139021049d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -29,7 +29,7 @@
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
-void __intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+static void __intel_gt_init_early(struct intel_gt *gt)
 {
spin_lock_init(>->irq_lock);
 
@@ -51,17 +51,23 @@ void __intel_gt_init_early(struct intel_gt *gt, struct 
drm_i915_private *i915)
intel_rps_init_early(>->rps);
 }
 
-void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+/* Preliminary initialization of Tile 0 */
+void intel_root_gt_init_early(struct drm_i915_private *i915)
 {
+   struct intel_gt *gt = to_gt(i915);
+
gt->i915 = i915;
gt->uncore = &i915->uncore;
+
+   __intel_gt_init_early(gt);
 }
 
-int intel_gt_probe_lmem(struct intel_gt *gt)
+static int intel_gt_probe_lmem(struct intel_gt *gt)
 {
struct drm_i915_private *i915 = gt->i915;
+   unsigned int instance = gt->info.id;
+   int id = INTEL_REGION_LMEM_0 + instance;
struct intel_memory_region *mem;
-   int id;
int err;
 
mem = intel_gt_setup_lmem(gt);
@@ -76,9 +82,8 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
return err;
}
 
-   id = INTEL_REGION_LMEM_0;
-
mem->id = id;
+   mem->instance = instance;
 
intel_memory_region_set_name(mem, "local%u", mem->instance);
 
@@ -801,16 +806,21 @@ void intel_gt_driver_release(struct intel_gt *gt)
intel_gt_fini_buffer_pool(gt);
 }
 
-void intel_gt_driver_late_release(struct intel_gt *gt)
+void intel_gt_driver_late_release(struct drm_i915_private *i915)
 {
+   struct intel_gt *gt;
+   unsigned int id;
+
/* We need to wait for inflight RCU frees to release their grip */
rcu_barrier();
 
-   intel_uc_driver_late_release(>->uc);
-   intel_gt_fini_requests(gt);
-   intel_gt_fini_reset(gt);
-   intel_gt_fini_timelines(gt);
-   intel_engines_free(gt);
+   for_each_gt(gt, i915, id) {
+   intel_uc_driver_late_release(>->uc);
+   intel_gt_fini_requests(gt);
+   intel_gt_fini_reset(gt);
+   intel_gt_fini_timelines(gt);
+   intel_engines_free(gt);
+   }
 }
 
 /**
@@ -1007,6 +1017,105 @@ void intel_gt_report_steering(struct drm_printer *p, 
struct intel_gt *gt,
}
 }
 
+static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)
+{
+   int ret;
+
+   if (!gt_is_root(gt)) {
+   struct intel_uncore_mmio_debug *mmio_debug;
+   struct intel_uncore *uncore;
+
+   uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+   if (!uncore)
+   return -ENOMEM;
+
+   mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
+   if (!mmio_debug) {
+   kfree(uncore);
+   return -ENOMEM;
+   }
+
+   gt->uncore = uncore;
+   gt->uncore->debug = mmio_debug;
+
+   __intel_gt_init_early(gt);
+   }
+
+   intel_uncore_init_early(gt->uncore, gt);
+
+   ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
+   if (ret)
+   return ret;
+
+   gt->phys_addr = phys_addr;
+
+   return 0;
+}
+
+static void
+i

[Intel-gfx] [PATCH v6 2/7] drm/i915/gt: add gt_is_root() helper

2022-03-18 Thread Andi Shyti

The "gt_is_root(struct intel_gt *gt)" helper return true if the
gt is the root gt, which means that its id is 0. Return false
otherwise.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Andi Shyti 
Reviewed-by: Michal Wajdeczko 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 996f8f3c17b95..ce471aa5c83d7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -19,6 +19,11 @@ struct drm_printer;
  ##__VA_ARGS__);   \
 } while (0)
 
+static inline bool gt_is_root(struct intel_gt *gt)
+{
+   return !gt->info.id;
+}
+
 static inline struct intel_gt *uc_to_gt(struct intel_uc *uc)
 {
return container_of(uc, struct intel_gt, uc);
-- 
2.35.1

[Intel-gfx] [PATCH v6 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0

2022-03-18 Thread Andi Shyti

With the upcoming multitile support each tile will have its own
local memory. Mark the current LMEM with the suffix '0' to
emphasise that it belongs to the root tile.

Suggested-by: Michal Wajdeczko 
Signed-off-by: Andi Shyti 
Reviewed-by: Michal Wajdeczko 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fb.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   | 2 +-
 drivers/gpu/drm/i915/display/intel_plane_initial.c| 2 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  | 4 ++--
 drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c  | 6 +++---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 8 
 drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
 drivers/gpu/drm/i915/intel_memory_region.c| 2 +-
 drivers/gpu/drm/i915/intel_memory_region.h| 4 ++--
 9 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index 94c57facbb463..e9ad142ac40fa 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1994,7 +1994,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
 
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
-   if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj, 
INTEL_REGION_LMEM)) {
+   if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj, 
INTEL_REGION_LMEM_0)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c 
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index a307b4993bcf3..bd6e7c98e751d 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -140,7 +140,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
else if (!ret && HAS_LMEM(dev_priv))
-   ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM);
+   ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0);
/* TODO: Do we need to sync when migration becomes async? */
if (!ret)
ret = i915_gem_object_pin_pages(obj);
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 7979929bb6323..d10f27d0b7b09 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -72,7 +72,7 @@ initial_plane_vma(struct drm_i915_private *i915,
}
 
phys_base = pte & I915_GTT_PAGE_MASK;
-   mem = i915->mm.regions[INTEL_REGION_LMEM];
+   mem = i915->mm.regions[INTEL_REGION_LMEM_0];
 
/*
 * We don't currently expect this to ever be placed in the
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index ede084f36ca93..b2aaf620741e3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -102,7 +102,7 @@ __i915_gem_object_create_lmem_with_ps(struct 
drm_i915_private *i915,
  resource_size_t page_size,
  unsigned int flags)
 {
-   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
 size, page_size, flags);
 }
 
@@ -137,6 +137,6 @@ i915_gem_object_create_lmem(struct drm_i915_private *i915,
resource_size_t size,
unsigned int flags)
 {
-   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
+   return 
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
 size, 0, flags);
 }
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index b071a58dd6daa..a342fd387d4ef 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -88,7 +88,7 @@ static int igt_dmabuf_import_self(void *arg)
 static int igt_dmabuf_import_same_driver_lmem(void *arg)
 {
struct drm_i915_private *i915 = arg;
-   struct intel_memory_region *lmem = i915->mm.regions[INTEL_REGION_LMEM];
+   struct intel_memory_region *lmem = 
i915->mm.regions[INTEL_REGION_LMEM_0];
struct drm_i915_gem_object *obj;
struct drm_gem_object *import;
struct dma_buf *dmabuf;
@@ -252,10 +252,10 @@ static int igt_dmabuf_import_same_driver_lmem_smem(void 
*arg)
struct drm_i915_private *i915 = arg;

[Intel-gfx] [PATCH v6 0/7] Introduce multitile support

2022-03-18 Thread Andi Shyti

Hi,

This is the second series that prepares i915 to host multitile
platforms. It introduces the for_each_gt() macro that loops over
the tiles to perform per gt actions.

This patch is a combination of two patches developed originally
by Abdiel, who introduced some refactoring during probe, and then
Tvrtko has added the necessary tools to start using the various
tiles.

The second patch re-organises the sysfs interface to expose the
API for each of the GTs. I decided to prioritise this patch
over others to unblock Sujaritha for further development.

A third series will still follow this.

Thanks Michal and Andrzej for the reviews and support!

Thanks,
Andi

Patchwork: https://patchwork.freedesktop.org/series/98741/

Changelog
=
v5 -> v6
 - address all Michal and Andrzej's reviews that consist mainly
   in code refactoring.

v4 -> v5
 - fixed Michal's reviews.
 - the sysfs patches have been split in 3 parts to make reviews
   easier.
 - Sujaritha's patch on pm throttle has been queued.
 - INTEL_REGION_LMEM has been renamed to INTEL_REGION_LMEM_0
 - added the gt_is_root() helper
 - the sysfs files will be called intel_gt_sysfs_* instead of
   sysfs_gt_*

v3 -> v4
 - fixed Tvrtko's review:
- remove the SYSFS_DEPRECATED_V2 mention from the commit log
- reworded the error message when accessing deprecated files
- errors in sysfs are printed as warnings as they are not
  fatal
- the inline functions are moved to be out of line.
   and some other minor refactoring.

v2 -> v3
 - Added Matt and Sujaritha's r-b for patch 1 and 2.
 - Reworded the commit of patch 2 to underline the fact that the
   interface is useful also when used manually.

v1 -> v2
 - fixed a couple of coding style issues in patch 2.

Andi Shyti (5):
  drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
  drm/i915/gt: add gt_is_root() helper
  drm/i915/gt: create per-tile sysfs interface
  drm/i915/gt: Create per-tile RC6 sysfs interface
  drm/i915/gt: Create per-tile RPS sysfs interfaces

Sujaritha Sundaresan (1):
  drm/i915/gt: Adding new sysfs frequency attributes

Tvrtko Ursulin (1):
  drm/i915: Prepare for multiple GTs

 drivers/gpu/drm/i915/Makefile |   2 +
 drivers/gpu/drm/i915/display/intel_fb.c   |   2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |   2 +-
 .../drm/i915/display/intel_plane_initial.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c  |   4 +-
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |   6 +-
 .../drm/i915/gem/selftests/i915_gem_migrate.c |   8 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 135 +++-
 drivers/gpu/drm/i915/gt/intel_gt.h|  22 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c |   9 +-
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c  | 122 
 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h  |  34 +
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 601 ++
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h   |  15 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |   7 +
 drivers/gpu/drm/i915/gt/intel_rps.c   |  18 +
 drivers/gpu/drm/i915/gt/intel_rps.h   |   4 +
 drivers/gpu/drm/i915/i915_driver.c|  28 +-
 drivers/gpu/drm/i915/i915_drv.h   |   8 +
 drivers/gpu/drm/i915/i915_reg.h   |  11 +
 drivers/gpu/drm/i915/i915_sysfs.c | 310 +
 drivers/gpu/drm/i915/i915_sysfs.h |   3 +
 drivers/gpu/drm/i915/intel_memory_region.c|   2 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   7 +-
 drivers/gpu/drm/i915/intel_uncore.c   |  11 +-
 drivers/gpu/drm/i915/intel_uncore.h   |   3 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   7 +-
 scripts/extract-cert  | Bin 0 -> 17952 bytes
 28 files changed, 1017 insertions(+), 366 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.h
 create mode 100755 scripts/extract-cert

-- 
2.35.1

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: avoid concurrent writes to aux_inv (rev8)

2022-03-18 Thread Patchwork

== Series Details ==

Series: drm/i915: avoid concurrent writes to aux_inv (rev8)
URL   : https://patchwork.freedesktop.org/series/100772/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11382_full -> Patchwork_22614_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22614_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22614_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 12)
--

  No changes in participating hosts

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22614_full:

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_rps@waitboost:
- shard-iclb: [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/shard-iclb5/igt@i915_pm_...@waitboost.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-iclb8/igt@i915_pm_...@waitboost.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_caching@read-writes:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-rkl-5/igt@gem_cach...@read-writes.html

  
Known issues


  Here are the changes found in Patchwork_22614_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-hang@blt:
- shard-skl:  NOTRUN -> [SKIP][4] ([fdo#109271]) +303 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-skl1/igt@gem_ctx_persistence@legacy-engines-h...@blt.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-iclb3/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][7] ([i915#4547])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-skl8/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_endless@dispatch@bcs0:
- shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([i915#3778])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/shard-iclb5/igt@gem_exec_endless@dispa...@bcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-iclb8/igt@gem_exec_endless@dispa...@bcs0.html

  * igt@gem_exec_fair@basic-deadline:
- shard-skl:  NOTRUN -> [FAIL][10] ([i915#2846])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-skl4/igt@gem_exec_f...@basic-deadline.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl:  [PASS][13] -> [FAIL][14] ([i915#2842])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk:  NOTRUN -> [FAIL][15] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_gttfill@basic:
- shard-glk:  [PASS][16] -> [DMESG-WARN][17] ([i915#118])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/shard-glk3/igt@gem_exec_gttf...@basic.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-glk3/igt@gem_exec_gttf...@basic.html

  * igt@gem_exec_params@no-blt:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109283])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-tglb6/igt@gem_exec_par...@no-blt.html

  * igt@gem_huc_copy@huc-copy:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-skl1/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@random:
- shard-skl:  NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/shard-skl6/igt@gem_lmem_swapp...@random.html

  *

Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Add HAS_MBUS_JOINING

2022-03-18 Thread Ville Syrjälä

On Fri, Mar 18, 2022 at 12:55:21PM -0700, José Roberto de Souza wrote:
> This will make easy to extend MBUS joining support to future platforms
> that also supports this feature.
> 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 2 ++
>  drivers/gpu/drm/i915/intel_pm.c | 6 +++---
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 97622d3ccfc2a..0f7f7ebe23cb0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1379,6 +1379,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  #define HAS_PERCTX_PREEMPT_CTRL(i915) \
>   ((GRAPHICS_VER(i915) >= 9) &&  GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
>  
> +#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
> +
>  static inline bool run_as_guest(void)
>  {
>   return !hypervisor_is_type(X86_HYPER_NATIVE);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8ee31c9590a7f..96bb8ecc11668 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6144,7 +6144,7 @@ skl_compute_ddb(struct intel_atomic_state *state)
>   return ret;
>   }
>  
> - if (IS_ALDERLAKE_P(dev_priv))
> + if (HAS_MBUS_JOINING(dev_priv))
>   new_dbuf_state->joined_mbus =
>   adlp_check_mbus_joined(new_dbuf_state->active_pipes);
>  
> @@ -6636,7 +6636,7 @@ void skl_wm_get_hw_state(struct drm_i915_private 
> *dev_priv)
>   to_intel_dbuf_state(dev_priv->dbuf.obj.state);
>   struct intel_crtc *crtc;
>  
> - if (IS_ALDERLAKE_P(dev_priv))
> + if (HAS_MBUS_JOINING(dev_priv))
>   dbuf_state->joined_mbus = intel_de_read(dev_priv, MBUS_CTL) & 
> MBUS_JOIN;
>  
>   for_each_intel_crtc(&dev_priv->drm, crtc) {
> @@ -8299,7 +8299,7 @@ static void update_mbus_pre_enable(struct 
> intel_atomic_state *state)
>   const struct intel_dbuf_state *dbuf_state =
>   intel_atomic_get_new_dbuf_state(state);
>  
> - if (!IS_ALDERLAKE_P(dev_priv))
> + if (!HAS_MBUS_JOINING(dev_priv))
>   return;
>  
>   /*
> -- 
> 2.35.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH 3/3] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL

2022-03-18 Thread Ville Syrjälä

On Fri, Mar 18, 2022 at 12:55:22PM -0700, José Roberto de Souza wrote:
> PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being
> enabled leaving other pipes with a wrong A_CREDIT value in cases
> like when going from one pipe enabled to two pipes and the first
> pipe don't need modeset, similar when going from two or more
> pipes to ones.
> 
> So here moving the PIPE_MBUS_DBOX_CTL programing to be executed before
> the function that enables and updates all necessary pipes.
> Leaving all pipes with the correct value of A_CREDIT.
> 
> As now PIPE_MBUS_DBOX_CTL is being programmed at the right time it
> is also waiting the vblanks after adjust PIPE_MBUS_DBOX_CTL
> as required by specification.
> 
> BSpec: 49213
> BSpec: 50343
> Cc: Ville Syrjälä 
> Cc: Stanislav Lisovskiy 
> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 36 +
>  drivers/gpu/drm/i915/intel_pm.c  | 55 +++-
>  drivers/gpu/drm/i915/intel_pm.h  |  1 +
>  3 files changed, 56 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 2e85ae575423a..4cd2d76058b8c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1821,34 +1821,6 @@ static void glk_pipe_scaler_clock_gating_wa(struct 
> drm_i915_private *dev_priv,
>   intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe), val);
>  }
>  
> -static void icl_pipe_mbus_enable(struct intel_crtc *crtc, bool joined_mbus)
> -{
> - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe;
> - u32 val = intel_de_read(dev_priv, PIPE_MBUS_DBOX_CTL(pipe));
> -
> - val &= ~MBUS_DBOX_A_CREDIT_MASK;
> - /* Wa_22010947358:adl-p */
> - if (IS_ALDERLAKE_P(dev_priv))
> - val |= joined_mbus ? MBUS_DBOX_A_CREDIT(6) : 
> MBUS_DBOX_A_CREDIT(4);
> - else
> - val |= MBUS_DBOX_A_CREDIT(2);
> -
> - val &= ~(MBUS_DBOX_BW_CREDIT_MASK | MBUS_DBOX_B_CREDIT_MASK);
> - if (IS_ALDERLAKE_P(dev_priv)) {
> - val |= MBUS_DBOX_BW_CREDIT(2);
> - val |= MBUS_DBOX_B_CREDIT(8);
> - } else if (DISPLAY_VER(dev_priv) >= 12) {
> - val |= MBUS_DBOX_BW_CREDIT(2);
> - val |= MBUS_DBOX_B_CREDIT(12);
> - } else {
> - val |= MBUS_DBOX_BW_CREDIT(1);
> - val |= MBUS_DBOX_B_CREDIT(8);
> - }
> -
> - intel_de_write(dev_priv, PIPE_MBUS_DBOX_CTL(pipe), val);
> -}
> -
>  static void hsw_set_linetime_wm(const struct intel_crtc_state *crtc_state)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -1984,13 +1956,6 @@ static void hsw_crtc_enable(struct intel_atomic_state 
> *state,
>  
>   intel_initial_watermarks(state, crtc);
>  
> - if (DISPLAY_VER(dev_priv) >= 11) {
> - const struct intel_dbuf_state *dbuf_state =
> - intel_atomic_get_new_dbuf_state(state);
> -
> - icl_pipe_mbus_enable(crtc, dbuf_state->joined_mbus);
> - }
> -
>   if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
>   intel_crtc_vblank_on(new_crtc_state);
>  
> @@ -8589,6 +8554,7 @@ static void intel_atomic_commit_tail(struct 
> intel_atomic_state *state)
>   intel_encoders_update_prepare(state);
>  
>   intel_dbuf_pre_plane_update(state);
> + intel_mbus_dbox_update(state);
>  
>   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
>   if (new_crtc_state->do_async_flip)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 96bb8ecc11668..08ba32e5eb4ad 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6172,7 +6172,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
>   return ret;
>  
>   if (old_dbuf_state->joined_mbus != new_dbuf_state->joined_mbus) 
> {
> - /* TODO: Implement vblank synchronized MBUS joining 
> changes */
>   ret = intel_modeset_all_pipes(state);
>   if (ret)
>   return ret;
> @@ -8365,3 +8364,57 @@ void intel_dbuf_post_plane_update(struct 
> intel_atomic_state *state)
>   gen9_dbuf_slices_update(dev_priv,
>   new_dbuf_state->enabled_slices);
>  }
> +
> +void intel_mbus_dbox_update(struct intel_atomic_state *state)
> +{
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> + struct intel_crtc_state *old_crtc_state, *new_crtc_state;
> + struct intel_dbuf_state *old_dbuf_state, *new_dbuf_state;
> + struct intel_crtc *crtc;
> + int i;
> +
> + if (DISPLAY_VER(i915) < 11 || !state->modeset)
> + return;
> +
> + if (HAS_MBUS_JOINING(i915)) {
> + new_dbuf_state = intel_atomic_get_dbuf_state(state);
>

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Program PIPE_MBUS_DBOX_CTL 
with adl-p values
URL   : https://patchwork.freedesktop.org/series/101545/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11383 -> Patchwork_22615


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22615 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22615, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/index.html

Participating hosts (44 -> 41)
--

  Additional (1): fi-pnv-d510 
  Missing(4): fi-bsw-cyan bat-adlm-1 shard-tglu fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22615:

### IGT changes ###

 Possible regressions 

  * igt@kms_busy@basic@modeset:
- fi-rkl-guc: [PASS][1] -> [DMESG-WARN][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11383/fi-rkl-guc/igt@kms_busy@ba...@modeset.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-rkl-guc/igt@kms_busy@ba...@modeset.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_busy@basic@flip:
- {bat-jsl-1}:[PASS][3] -> [DMESG-WARN][4] +1 similar issue
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11383/bat-jsl-1/igt@kms_busy@ba...@flip.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/bat-jsl-1/igt@kms_busy@ba...@flip.html
- {bat-adlp-6}:   [PASS][5] -> [DMESG-WARN][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11383/bat-adlp-6/igt@kms_busy@ba...@flip.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/bat-adlp-6/igt@kms_busy@ba...@flip.html

  * igt@kms_busy@basic@modeset:
- {bat-jsl-2}:[PASS][7] -> [DMESG-WARN][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11383/bat-jsl-2/igt@kms_busy@ba...@modeset.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/bat-jsl-2/igt@kms_busy@ba...@modeset.html
- {fi-ehl-2}: [PASS][9] -> [DMESG-WARN][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11383/fi-ehl-2/igt@kms_busy@ba...@modeset.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-ehl-2/igt@kms_busy@ba...@modeset.html
- {fi-jsl-1}: [PASS][11] -> [DMESG-WARN][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11383/fi-jsl-1/igt@kms_busy@ba...@modeset.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-jsl-1/igt@kms_busy@ba...@modeset.html

  * igt@runner@aborted:
- {fi-rkl-11600}: NOTRUN -> [FAIL][13]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-rkl-11600/igt@run...@aborted.html
- {fi-adl-ddr5}:  NOTRUN -> [FAIL][14]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-adl-ddr5/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_22615 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-hsw-4770:NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#109315]) 
+17 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-hsw-4770/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][16] ([fdo#109271]) +17 similar issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#5341])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][18] ([fdo#109271]) +57 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bdw-5557u:   NOTRUN -> [FAIL][19] ([i915#2426] / [i915#4312])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-bdw-5557u/igt@run...@aborted.html
- fi-rkl-guc: NOTRUN -> [FAIL][20] ([i915#4312])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-rkl-guc/igt@run...@aborted.html
- fi-tgl-1115g4:  NOTRUN -> [FAIL][21] ([i915#5257])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22615/fi-tgl-1115g4/igt@run...@aborted.html

  
 Possib

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/3] drm/i915/display: Program PIPE_MBUS_DBOX_CTL 
with adl-p values
URL   : https://patchwork.freedesktop.org/series/101545/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH 2/3] drm/i915/display: Add HAS_MBUS_JOINING

2022-03-18 Thread José Roberto de Souza

This will make easy to extend MBUS joining support to future platforms
that also supports this feature.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 drivers/gpu/drm/i915/intel_pm.c | 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 97622d3ccfc2a..0f7f7ebe23cb0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1379,6 +1379,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 #define HAS_PERCTX_PREEMPT_CTRL(i915) \
((GRAPHICS_VER(i915) >= 9) &&  GRAPHICS_VER_FULL(i915) < IP_VER(12, 55))
 
+#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
+
 static inline bool run_as_guest(void)
 {
return !hypervisor_is_type(X86_HYPER_NATIVE);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8ee31c9590a7f..96bb8ecc11668 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6144,7 +6144,7 @@ skl_compute_ddb(struct intel_atomic_state *state)
return ret;
}
 
-   if (IS_ALDERLAKE_P(dev_priv))
+   if (HAS_MBUS_JOINING(dev_priv))
new_dbuf_state->joined_mbus =
adlp_check_mbus_joined(new_dbuf_state->active_pipes);
 
@@ -6636,7 +6636,7 @@ void skl_wm_get_hw_state(struct drm_i915_private 
*dev_priv)
to_intel_dbuf_state(dev_priv->dbuf.obj.state);
struct intel_crtc *crtc;
 
-   if (IS_ALDERLAKE_P(dev_priv))
+   if (HAS_MBUS_JOINING(dev_priv))
dbuf_state->joined_mbus = intel_de_read(dev_priv, MBUS_CTL) & 
MBUS_JOIN;
 
for_each_intel_crtc(&dev_priv->drm, crtc) {
@@ -8299,7 +8299,7 @@ static void update_mbus_pre_enable(struct 
intel_atomic_state *state)
const struct intel_dbuf_state *dbuf_state =
intel_atomic_get_new_dbuf_state(state);
 
-   if (!IS_ALDERLAKE_P(dev_priv))
+   if (!HAS_MBUS_JOINING(dev_priv))
return;
 
/*
-- 
2.35.1

[Intel-gfx] [PATCH 3/3] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL

2022-03-18 Thread José Roberto de Souza

PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being
enabled leaving other pipes with a wrong A_CREDIT value in cases
like when going from one pipe enabled to two pipes and the first
pipe don't need modeset, similar when going from two or more
pipes to ones.

So here moving the PIPE_MBUS_DBOX_CTL programing to be executed before
the function that enables and updates all necessary pipes.
Leaving all pipes with the correct value of A_CREDIT.

As now PIPE_MBUS_DBOX_CTL is being programmed at the right time it
is also waiting the vblanks after adjust PIPE_MBUS_DBOX_CTL
as required by specification.

BSpec: 49213
BSpec: 50343
Cc: Ville Syrjälä 
Cc: Stanislav Lisovskiy 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 36 +
 drivers/gpu/drm/i915/intel_pm.c  | 55 +++-
 drivers/gpu/drm/i915/intel_pm.h  |  1 +
 3 files changed, 56 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 2e85ae575423a..4cd2d76058b8c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1821,34 +1821,6 @@ static void glk_pipe_scaler_clock_gating_wa(struct 
drm_i915_private *dev_priv,
intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe), val);
 }
 
-static void icl_pipe_mbus_enable(struct intel_crtc *crtc, bool joined_mbus)
-{
-   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-   enum pipe pipe = crtc->pipe;
-   u32 val = intel_de_read(dev_priv, PIPE_MBUS_DBOX_CTL(pipe));
-
-   val &= ~MBUS_DBOX_A_CREDIT_MASK;
-   /* Wa_22010947358:adl-p */
-   if (IS_ALDERLAKE_P(dev_priv))
-   val |= joined_mbus ? MBUS_DBOX_A_CREDIT(6) : 
MBUS_DBOX_A_CREDIT(4);
-   else
-   val |= MBUS_DBOX_A_CREDIT(2);
-
-   val &= ~(MBUS_DBOX_BW_CREDIT_MASK | MBUS_DBOX_B_CREDIT_MASK);
-   if (IS_ALDERLAKE_P(dev_priv)) {
-   val |= MBUS_DBOX_BW_CREDIT(2);
-   val |= MBUS_DBOX_B_CREDIT(8);
-   } else if (DISPLAY_VER(dev_priv) >= 12) {
-   val |= MBUS_DBOX_BW_CREDIT(2);
-   val |= MBUS_DBOX_B_CREDIT(12);
-   } else {
-   val |= MBUS_DBOX_BW_CREDIT(1);
-   val |= MBUS_DBOX_B_CREDIT(8);
-   }
-
-   intel_de_write(dev_priv, PIPE_MBUS_DBOX_CTL(pipe), val);
-}
-
 static void hsw_set_linetime_wm(const struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -1984,13 +1956,6 @@ static void hsw_crtc_enable(struct intel_atomic_state 
*state,
 
intel_initial_watermarks(state, crtc);
 
-   if (DISPLAY_VER(dev_priv) >= 11) {
-   const struct intel_dbuf_state *dbuf_state =
-   intel_atomic_get_new_dbuf_state(state);
-
-   icl_pipe_mbus_enable(crtc, dbuf_state->joined_mbus);
-   }
-
if (intel_crtc_is_bigjoiner_slave(new_crtc_state))
intel_crtc_vblank_on(new_crtc_state);
 
@@ -8589,6 +8554,7 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
intel_encoders_update_prepare(state);
 
intel_dbuf_pre_plane_update(state);
+   intel_mbus_dbox_update(state);
 
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->do_async_flip)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96bb8ecc11668..08ba32e5eb4ad 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6172,7 +6172,6 @@ skl_compute_ddb(struct intel_atomic_state *state)
return ret;
 
if (old_dbuf_state->joined_mbus != new_dbuf_state->joined_mbus) 
{
-   /* TODO: Implement vblank synchronized MBUS joining 
changes */
ret = intel_modeset_all_pipes(state);
if (ret)
return ret;
@@ -8365,3 +8364,57 @@ void intel_dbuf_post_plane_update(struct 
intel_atomic_state *state)
gen9_dbuf_slices_update(dev_priv,
new_dbuf_state->enabled_slices);
 }
+
+void intel_mbus_dbox_update(struct intel_atomic_state *state)
+{
+   struct drm_i915_private *i915 = to_i915(state->base.dev);
+   struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+   struct intel_dbuf_state *old_dbuf_state, *new_dbuf_state;
+   struct intel_crtc *crtc;
+   int i;
+
+   if (DISPLAY_VER(i915) < 11 || !state->modeset)
+   return;
+
+   if (HAS_MBUS_JOINING(i915)) {
+   new_dbuf_state = intel_atomic_get_dbuf_state(state);
+   old_dbuf_state = intel_atomic_get_old_dbuf_state(state);
+   }
+
+   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   u32 val;
+
+

[Intel-gfx] [PATCH 1/3] drm/i915/display: Program PIPE_MBUS_DBOX_CTL with adl-p values

2022-03-18 Thread José Roberto de Souza

From: Caz Yokoyama 

B credits set by IFWI do not match with specification default, so here
programming the right value.

Also while at it, taking the oportunity to do a read-modify-write to
all other bit in this register that specification don't ask us to
change.

BSpec: 49213
BSpec: 50343
Cc: Matt Roper 
Cc: Stanislav Lisovskiy 
Signed-off-by: Caz Yokoyama 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_display.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 7cd586d280883..2e85ae575423a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1825,15 +1825,20 @@ static void icl_pipe_mbus_enable(struct intel_crtc 
*crtc, bool joined_mbus)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
-   u32 val;
+   u32 val = intel_de_read(dev_priv, PIPE_MBUS_DBOX_CTL(pipe));
 
+   val &= ~MBUS_DBOX_A_CREDIT_MASK;
/* Wa_22010947358:adl-p */
if (IS_ALDERLAKE_P(dev_priv))
-   val = joined_mbus ? MBUS_DBOX_A_CREDIT(6) : 
MBUS_DBOX_A_CREDIT(4);
+   val |= joined_mbus ? MBUS_DBOX_A_CREDIT(6) : 
MBUS_DBOX_A_CREDIT(4);
else
-   val = MBUS_DBOX_A_CREDIT(2);
+   val |= MBUS_DBOX_A_CREDIT(2);
 
-   if (DISPLAY_VER(dev_priv) >= 12) {
+   val &= ~(MBUS_DBOX_BW_CREDIT_MASK | MBUS_DBOX_B_CREDIT_MASK);
+   if (IS_ALDERLAKE_P(dev_priv)) {
+   val |= MBUS_DBOX_BW_CREDIT(2);
+   val |= MBUS_DBOX_B_CREDIT(8);
+   } else if (DISPLAY_VER(dev_priv) >= 12) {
val |= MBUS_DBOX_BW_CREDIT(2);
val |= MBUS_DBOX_B_CREDIT(12);
} else {
-- 
2.35.1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: avoid concurrent writes to aux_inv (rev8)

2022-03-18 Thread Patchwork

== Series Details ==

Series: drm/i915: avoid concurrent writes to aux_inv (rev8)
URL   : https://patchwork.freedesktop.org/series/100772/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11382 -> Patchwork_22614


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/index.html

Participating hosts (43 -> 41)
--

  Additional (1): fi-pnv-d510 
  Missing(3): fi-bsw-cyan shard-tglu fi-bdw-samus 

Known issues


  Here are the changes found in Patchwork_22614 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_exec@basic:
- fi-bsw-nick:[PASS][1] -> [DMESG-WARN][2] ([i915#3428])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/fi-bsw-nick/igt@gem_ctx_e...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-bsw-nick/igt@gem_ctx_e...@basic.html

  * igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] ([i915#3303])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#5341])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  * igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +57 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-pnv-d510/igt@prime_v...@basic-userptr.html

  * igt@runner@aborted:
- fi-bsw-nick:NOTRUN -> [FAIL][7] ([i915#3428] / [i915#4312])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-bsw-nick/igt@run...@aborted.html
- fi-bdw-5557u:   NOTRUN -> [FAIL][8] ([i915#2426] / [i915#4312])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-bdw-5557u/igt@run...@aborted.html
- fi-hsw-4770:NOTRUN -> [FAIL][9] ([fdo#109271] / [i915#1436] / 
[i915#4312])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-hsw-4770/igt@run...@aborted.html

  
 Possible fixes 

  * igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][10] ([i915#5127]) -> [PASS][11]
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_pm_rpm@module-reload:
- {bat-adlp-6}:   [DMESG-WARN][12] ([i915#3576]) -> [PASS][13]
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/bat-adlp-6/igt@i915_pm_...@module-reload.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/bat-adlp-6/igt@i915_pm_...@module-reload.html

  
 Warnings 

  * igt@amdgpu/amd_prime@i915-to-amd:
- fi-tgl-1115g4:  [SKIP][14] ([fdo#109315] / [i915#1888] / [i915#2575]) 
-> [SKIP][15] ([fdo#109315] / [i915#2575])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11382/fi-tgl-1115g4/igt@amdgpu/amd_pr...@i915-to-amd.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22614/fi-tgl-1115g4/igt@amdgpu/amd_pr...@i915-to-amd.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3428]: https://gitlab.freedesktop.org/drm/intel/issues/3428
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Add preemption changes for Wa_14015141709 (rev2)

2022-03-18 Thread Vudum, Lakshminarayana

Yes, I have re-opened the issue #3812 and re-reported.

-Original Message-
From: Roper, Matthew D  
Sent: Friday, March 18, 2022 10:21 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/dg2: Add preemption changes for 
Wa_14015141709 (rev2)

On Fri, Mar 18, 2022 at 04:51:14AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/dg2: Add preemption changes for Wa_14015141709 (rev2)
> URL   : https://patchwork.freedesktop.org/series/101023/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11379_full -> Patchwork_22602_full 
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_22602_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_22602_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (12 -> 12)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_22602_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_parallel@engines@contexts:
> - shard-iclb: [PASS][1] -> [INCOMPLETE][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-iclb7/igt@gem_exec_parallel@engi...@contexts.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb4/i
> gt@gem_exec_parallel@engi...@contexts.html
> 

Unexpected incomplete with no apparent warnings/errors.  Looks like we 
previously had https://gitlab.freedesktop.org/drm/intel/-/issues/3812
open for this but it wasn't seen for a while and got closed.

This patch doesn't change the behavior of ICL, so it shouldn't be the cause.

Patch applied to drm-intel-gt-next.  Thanks Anusha for the review.


Matt

>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_exec_parallel@fds@vecs0:
> - {shard-rkl}:([PASS][3], [PASS][4]) -> [INCOMPLETE][5]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-rkl-4/igt@gem_exec_parallel@f...@vecs0.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-rkl-5/igt@gem_exec_parallel@f...@vecs0.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-rkl-5/i
> gt@gem_exec_parallel@f...@vecs0.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_22602_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_create@create-massive:
> - shard-apl:  NOTRUN -> [DMESG-WARN][6] ([i915#4991])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-apl8/ig
> t@gem_cre...@create-massive.html
> 
>   * igt@gem_eio@kms:
> - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#232])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-tglb6/igt@gem_...@kms.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb1/i
> gt@gem_...@kms.html
> 
>   * igt@gem_exec_capture@pi@bcs0:
> - shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#4547])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-skl6/ig
> t@gem_exec_capture@p...@bcs0.html
> 
>   * igt@gem_exec_fair@basic-none-rrul@rcs0:
> - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/i
> gt@gem_exec_fair@basic-none-r...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs0:
> - shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
> issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-kbl4/ig
> t@gem_exec_fair@basic-n...@vcs0.html
> 
>   * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb1/i
> gt@gem_exec_fair@basic-pace-sh...@rcs0.html
> 
>   * igt@gem_lmem_swapping@heavy-verify-multi:
> - shard-iclb: NOTRUN -> [SKIP][15] ([i915#4613])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/i
> gt@gem_lmem_swapp...@heavy-verify-multi.html
> 
>   * igt@gem_lmem_swapping@parallel-random-engines:
> - shard-kbl:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg2: Add preemption changes for Wa_14015141709 (rev2)

2022-03-18 Thread Patchwork

== Series Details ==

Series: drm/i915/dg2: Add preemption changes for Wa_14015141709 (rev2)
URL   : https://patchwork.freedesktop.org/series/101023/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11379_full -> Patchwork_22602_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 13)
--

  Additional (1): shard-dg1 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22602_full:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_parallel@fds@vecs0:
- {shard-rkl}:([PASS][1], [PASS][2]) -> [INCOMPLETE][3]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-rkl-4/igt@gem_exec_parallel@f...@vecs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-rkl-5/igt@gem_exec_parallel@f...@vecs0.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-rkl-5/igt@gem_exec_parallel@f...@vecs0.html

  
Known issues


  Here are the changes found in Patchwork_22602_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_create@create-massive:
- shard-apl:  NOTRUN -> [DMESG-WARN][4] ([i915#4991])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-apl8/igt@gem_cre...@create-massive.html

  * igt@gem_eio@kms:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#232])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-tglb6/igt@gem_...@kms.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb1/igt@gem_...@kms.html

  * igt@gem_exec_capture@pi@bcs0:
- shard-skl:  NOTRUN -> [INCOMPLETE][7] ([i915#4547])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-skl6/igt@gem_exec_capture@p...@bcs0.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_parallel@engines@contexts:
- shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([i915#3812])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-iclb7/igt@gem_exec_parallel@engi...@contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb4/igt@gem_exec_parallel@engi...@contexts.html

  * igt@gem_lmem_swapping@heavy-verify-multi:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#4613])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/igt@gem_lmem_swapp...@heavy-verify-multi.html

  * igt@gem_lmem_swapping@parallel-random-engines:
- shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-kbl1/igt@gem_lmem_swapp...@parallel-random-engines.html

  * igt@gem_lmem_swapping@verify-random:
- shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-skl6/igt@gem_lmem_swapp...@verify-random.html

  * igt@gem_pwrite@basic-exhaustion:
- shard-apl:  NOTRUN -> [WARN][18] ([i915#2658])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-apl3/igt@gem_pwr...@basic-exhaustion.html

  * igt@gem_userptr_blits@input-checking:
- shard-kbl:  NOTRUN -> [DMESG-WARN][19] ([i915#4991])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-kbl4/igt@gem_userptr_bl...@input-checking.html

  * igt@gen3_render_linear_blits:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb3/igt@gen3_render_linear_blits.html

  * igt@gen9_exec_parse@allowed-all:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#2856])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/igt@gen9_exec_pa...@allowed-all.html
- shard-glk:  [PASS][22

[Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

2022-03-18 Thread fei . yang

From: Fei Yang 

GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With the MMIO remap feature, we can actually set bit 17 of MI_LRI
instruction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.

Bspec: 45728

Cc: Stuart Summers 
Cc: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Signed-off-by: Fei Yang 
---
 drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 44 +---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
 2 files changed, 11 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 36148887c699..6e83ac06aaf6 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
 }
 
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)
-{
-   static const i915_reg_t vd[] = {
-   GEN12_VD0_AUX_NV,
-   GEN12_VD1_AUX_NV,
-   GEN12_VD2_AUX_NV,
-   GEN12_VD3_AUX_NV,
-   };
-
-   static const i915_reg_t ve[] = {
-   GEN12_VE0_AUX_NV,
-   GEN12_VE1_AUX_NV,
-   };
-
-   if (engine->class == VIDEO_DECODE_CLASS)
-   return vd[engine->instance];
-
-   if (engine->class == VIDEO_ENHANCEMENT_CLASS)
-   return ve[engine->instance];
-
-   GEM_BUG_ON("unknown aux_inv reg\n");
-   return INVALID_MMIO_REG;
-}
-
 static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
 {
*cs++ = MI_LOAD_REGISTER_IMM(1);
@@ -293,10 +269,12 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
if (mode & EMIT_INVALIDATE) {
cmd += 2;
 
-   if (!HAS_FLAT_CCS(rq->engine->i915)) {
+   if (!HAS_FLAT_CCS(rq->engine->i915) &&
+   (rq->engine->class == VIDEO_DECODE_CLASS ||
+rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
-   cmd += 2 * hweight32(aux_inv) + 2;
+   cmd += 4;
}
}
 
@@ -329,14 +307,12 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
mode)
*cs++ = 0; /* value */
 
if (aux_inv) { /* hsdes: 1809175790 */
-   struct intel_engine_cs *engine;
-   unsigned int tmp;
-
-   *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
-   for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
-   *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
-   *cs++ = AUX_INV;
-   }
+   *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
+   if (rq->engine->class == VIDEO_DECODE_CLASS)
+   *cs++ = i915_mmio_reg_offset(GEN12_VD0_AUX_NV);
+   else
+   *cs++ = i915_mmio_reg_offset(GEN12_VE0_AUX_NV);
+   *cs++ = AUX_INV;
*cs++ = MI_NOOP;
}
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index d112ffd56418..4243be030bc1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -144,6 +144,7 @@
 #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
 /* Gen11+. addr = base + (ctx_restore ? offset & GENMASK(12,2) : offset) */
 #define   MI_LRI_LRM_CS_MMIO   REG_BIT(19)
+#define   MI_LRI_MMIO_REMAP_EN REG_BIT(17)
 #define   MI_LRI_FORCE_POSTED  (1<<12)
 #define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
 #define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)
-- 
2.25.1

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

2022-03-18 Thread Yang, Fei

>>   static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
>>   {
>>  *cs++ = MI_LOAD_REGISTER_IMM(1);
>> @@ -296,7 +272,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
>> mode)
>>  if (!HAS_FLAT_CCS(rq->engine->i915)) {
>>  aux_inv = rq->engine->mask & ~BIT(BCS0);
>>  if (aux_inv)
>> -cmd += 2 * hweight32(aux_inv) + 2;
>> +cmd += 4;
>>  }
>>  }
>>   
>> @@ -329,14 +305,16 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 
>> mode)
>>  *cs++ = 0; /* value */
>>   
>>  if (aux_inv) { /* hsdes: 1809175790 */
>> -struct intel_engine_cs *engine;
>> -unsigned int tmp;
>> -
>> -*cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
>> -for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
>> -*cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
>> -*cs++ = AUX_INV;
>> +*cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;
> 
> Cool, I didn't know this exists. First Bspec link I found did not mention 
> these register, but second did.
> That one however (29545) has a worrying "removed by" tag which seems to point 
> to a story suggesting the
> remapping table might be gone on machines with flat ccs?! Could you double 
> check please?

The variable aux_inv is set only if (!HAS_FLAT_CCS(rq->engine->i915)).

>> +if (rq->engine->class == VIDEO_DECODE_CLASS) {
>> +*cs++ = i915_mmio_reg_offset(GEN12_VD0_AUX_NV);
>> +} else if (rq->engine->class == VIDEO_ENHANCEMENT_CLASS) {
>> +*cs++ = i915_mmio_reg_offset(GEN12_VE0_AUX_NV);
>> +} else {
>> +GEM_BUG_ON("unknown aux_inv reg\n");
>> +*cs++ = i915_mmio_reg_offset(INVALID_MMIO_REG);
>
> I'd consider not emitting the LRI if we don't know what to put in unless 
> there is some hidden point to do it?

That's true. I was following the original logic flow here. I think it would be 
better to check for engine class before setting the variable aux_inv.

>
>>  }
>> +*cs++ = AUX_INV;
>>  *cs++ = MI_NOOP;
>>  }
>>   
>> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
>> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
>> index d112ffd56418..2d150eec5c65 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
>> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
>> @@ -144,6 +144,7 @@
>>   #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*(x)-1)
>>   /* Gen11+. addr = base + (ctx_restore ? offset & GENMASK(12,2) : offset) */
>>   #define   MI_LRI_LRM_CS_MMIO   REG_BIT(19)
>> +#define   MI_LRI_MMIO_REMAP_EN  (1 << 17)
>>   #define   MI_LRI_FORCE_POSTED  (1<<12)
>
> Passing observation - three bits, three flavours of expressing them, sigh...
Haha, REG_BIT(17) it is. The other one causes a CHECK:SPACING, but don't want 
to touch that in this patch.

>>   #define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
>>   #define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)

Re: [Intel-gfx] Small bar recovery vs compressed content on DG2

2022-03-18 Thread Daniel Vetter

Maybe also good to add dri-devel to these discussions.

I'm not sure where exactly we landed with dgpu error capture (maybe I
should check the code but it's really w/e here), but I think we can
also toss in "you need a non-recoverable context for error capture to
work on dgpu". Since that simplifies things even more. Maybe Thomas
forgot to add that to the list of restrictions.

Anyway on the "we can't capture lmem-only compressed buffers", I think
that's totally fine. Those are for render targets, and we don't
capture those. Adding Lionel and Ken to confirm.
-Daniel

On Fri, 18 Mar 2022 at 17:26, Bloomfield, Jon  wrote:
>
> @Thomas Hellström - I agree :-)
>
> My question was really to @Joonas Lahtinen, who was saying we could always 
> migrate in the CPU fault handler. I am pushing back on that unless we have no 
> choice. It's the very complication we were trying to avoid with the current 
> SAS. If that's what's needed, then so be it. But I'm asking whether we can 
> instead handle this specially, instead of adding generic complexity to the 
> primary code paths.
>
> Jon
>
> > -Original Message-
> > From: Thomas Hellström 
> > Sent: Friday, March 18, 2022 2:48 AM
> > To: Bloomfield, Jon ; Joonas Lahtinen
> > ; Intel Graphics Development  > g...@lists.freedesktop.org>; Auld, Matthew ; C,
> > Ramalingam ; Vetter, Daniel
> > 
> > Subject: Re: Small bar recovery vs compressed content on DG2
> >
> > Hi,
> >
> > On Thu, 2022-03-17 at 18:21 +, Bloomfield, Jon wrote:
> > > +@Vetter, Daniel
> > >
> > > Let's not start re-inventing this on the fly again. That's how we got
> > > into trouble in the past. The SAS/Whitepaper does currently require
> > > the SMEM+LMEM placement for mappable, for good reasons.
> >
> > Just to avoid any misunderstandings here:
> >
> > We have two hard requirements from Arch that clash, main problem is
> > compressed bos can't be captured on error with current designs.
> >
> > From an engineering point of view we can do little more than list
> > options available to resolve this and whether they are hard or not so
> > hard to implemement. But IMHO Arch needs to agree on what's got to
> > give.
> >
> > Thanks,
> > Thomas
> >
> >
> > >
> > > We cannot 'always migrate to mappable in the fault handler'. Or at
> > > least, this is not as trivial as it is to write in a sentence due to
> > > the need to spill out other active objects, and all the usual
> > > challenges with context synchronization etc. It is possible, perhaps
> > > with a lot of care, but it is challenging to guarantee, easy to
> > > break, and not needed for 99.9% of software. We are trying to
> > > simplify our driver stack.
> > >
> > > If we need a special mechanism for debug, we should devise a special
> > > mechanism, not throw out the general LMEM+SMEM requirement. Are
> > there
> > > any identified first-class clients that require such access, or is it
> > > only debugging tools?
> > >
> > > If only debug, then why can't the tool use a copy engine submission
> > > to access the data in place? Or perhaps a bespoke ioctl to access
> > > this via the KMD (and kmd submitted copy-engine BB)?
> > >
> > > Thanks,
> > >
> > > Jon
> > >
> > > > -Original Message-
> > > > From: Thomas Hellström 
> > > > Sent: Thursday, March 17, 2022 2:35 AM
> > > > To: Joonas Lahtinen ; Bloomfield,
> > > > Jon
> > > > ; Intel Graphics Development  > > > g...@lists.freedesktop.org>; Auld, Matthew ;
> > > > C,
> > > > Ramalingam 
> > > > Subject: Re: Small bar recovery vs compressed content on DG2
> > > >
> > > > On Thu, 2022-03-17 at 10:43 +0200, Joonas Lahtinen wrote:
> > > > > Quoting Thomas Hellström (2022-03-16 09:25:16)
> > > > > > Hi!
> > > > > >
> > > > > > Do we somehow need to clarify in the headers the semantics for
> > > > > > this?
> > > > > >
> > > > > >  From my understanding when discussing the CCS migration series
> > > > > > with
> > > > > > Ram, the kernel will never do any resolving (compressing /
> > > > > > decompressing) migrations or evictions which basically implies
> > > > > > the
> > > > > > following:
> > > > > >
> > > > > > *) Compressed data must have LMEM only placement, otherwise the
> > > > GPU
> > > > > > would read garbage if accessing from SMEM.
> > > > >
> > > > > This has always been the case, so it should be documented in the
> > > > > uAPI
> > > > > headers and kerneldocs.
> > > > >
> > > > > > *) Compressed data can't be assumed to be mappable by the CPU,
> > > > > > because
> > > > > > in order to ensure that on small BAR, the placement needs to be
> > > > > > LMEM+SMEM.
> > > > >
> > > > > Not strictly true, as we could always migrate to the mappable
> > > > > region
> > > > > in
> > > > > the CPU fault handler. Will need the same set of tricks as with
> > > > > limited
> > > > > mappable GGTT in past.
> > > >
> > > > In addition to Matt's reply:
> > > >
> > > > Yes, if there is sufficient space. I'm not sure we want to
> > > > complicate
> > > > this to migrate only part of the buffer

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add CDCLK checks to atomic check phase (rev5)

2022-03-18 Thread Patchwork

== Series Details ==

Series: Add CDCLK checks to atomic check phase (rev5)
URL   : https://patchwork.freedesktop.org/series/101068/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11381 -> Patchwork_22613


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22613 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22613, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/index.html

Participating hosts (47 -> 25)
--

  Additional (1): fi-kbl-8809g 
  Missing(23): fi-rkl-11600 bat-dg1-6 bat-dg1-5 fi-apl-guc fi-pnv-d510 
bat-rpls-1 bat-rpls-2 fi-bdw-5557u shard-tglu fi-adl-ddr5 bat-dg2-8 fi-glk-dsi 
bat-dg2-9 fi-kbl-7500u fi-skl-6700k2 fi-skl-guc fi-cfl-8700k bat-jsl-2 
fi-bsw-cyan fi-cfl-guc fi-kbl-x1275 fi-cfl-8109u fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22613:

### IGT changes ###

 Possible regressions 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-bsw-nick/igt@gem_exec_suspend@basic...@smem.html
- fi-glk-j4005:   [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html
- fi-rkl-guc: [PASS][5] -> [INCOMPLETE][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-rkl-guc/igt@gem_exec_suspend@basic...@smem.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-rkl-guc/igt@gem_exec_suspend@basic...@smem.html
- fi-bsw-kefka:   [PASS][7] -> [INCOMPLETE][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-bsw-kefka/igt@gem_exec_suspend@basic...@smem.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-bsw-kefka/igt@gem_exec_suspend@basic...@smem.html
- fi-bsw-n3050:   [PASS][9] -> [INCOMPLETE][10]
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-bsw-n3050/igt@gem_exec_suspend@basic...@smem.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-bsw-n3050/igt@gem_exec_suspend@basic...@smem.html
- fi-bxt-dsi: [PASS][11] -> [INCOMPLETE][12]
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [PASS][13] -> [INCOMPLETE][14]
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
- {fi-jsl-1}: [PASS][15] -> [INCOMPLETE][16]
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-jsl-1/igt@gem_exec_suspend@basic...@smem.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-jsl-1/igt@gem_exec_suspend@basic...@smem.html
- {fi-tgl-dsi}:   [PASS][17] -> [INCOMPLETE][18]
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/fi-tgl-dsi/igt@gem_exec_suspend@basic...@smem.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-tgl-dsi/igt@gem_exec_suspend@basic...@smem.html
- {bat-adlp-6}:   [PASS][19] -> [INCOMPLETE][20]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11381/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/bat-adlp-6/igt@gem_exec_suspend@basic...@smem.html

  * igt@runner@aborted:
- {bat-jsl-1}:NOTRUN -> [FAIL][21]
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/bat-jsl-1/igt@run...@aborted.html

  
Known issues


  Here are the changes found in Patchwork_22613 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s0@smem:
- fi-kbl-8809g:   NOTRUN -> [DMESG-WARN][22] ([i915#4962]) +1 similar 
issue
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22613/fi-kbl-8809g/igt@gem_exec_suspend@basic...@smem.html

  * igt@gem_huc_copy@huc-copy:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Fix renamed struct field (rev2)

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field (rev2)
URL   : https://patchwork.freedesktop.org/series/101448/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11380_full -> Patchwork_22611_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 13)
--

  Additional (1): shard-dg1 

Known issues


  Here are the changes found in Patchwork_22611_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_capture@pi@rcs0:
- shard-skl:  [PASS][1] -> [INCOMPLETE][2] ([i915#4547])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-skl1/igt@gem_exec_capture@p...@rcs0.html

  * igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-iclb: NOTRUN -> [FAIL][3] ([i915#2842])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb7/igt@gem_exec_fair@basic-none-s...@rcs0.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][4] -> [FAIL][5] ([i915#2842])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
- shard-apl:  [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl3/igt@gem_exec_fair@basic-n...@vecs0.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][8] -> [SKIP][9] ([i915#2190])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-tglb1/igt@gem_huc_c...@huc-copy.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-tglb7/igt@gem_huc_c...@huc-copy.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-iclb: NOTRUN -> [SKIP][10] ([i915#4613])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb3/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-skl7/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#4270])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb8/igt@gem_...@create-valid-protected-context.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#768]) +3 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb8/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109290])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb8/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#3323])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb8/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-skl10/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@dmabuf-unsync:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#3297]) +1 similar issue
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb7/igt@gem_userptr_bl...@dmabuf-unsync.html

  * igt@gen3_render_linear_blits:
- shard-tglb: NOTRUN -> [SKIP][18] ([fdo#109289])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-tglb8/igt@gen3_render_linear_blits.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-skl:  NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#658]) +1 
similar issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-skl10/igt@i915_pm...@dc3co-vpb-simulation.html
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#658])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-iclb8/igt@i915_pm...@dc3co-vpb-simulation.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][21] ([i915#454])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-skl4/igt@i915_pm...@dc6-dpms.html

  * igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: NOTRUN -> [WARN][22] ([i915#1804] / [i915#2684])
   [22]: 
https://intel-gfx-ci.01

Re: [Intel-gfx] [PATCH v5 15/19] drm/i915/dg2: Add DG2 unified compression

2022-03-18 Thread Imre Deak

On Thu, Feb 17, 2022 at 05:15:15PM +, Chery, Nanley G wrote:
> > >> [...]
> > >> --- a/include/uapi/drm/drm_fourcc.h
> > >> +++ b/include/uapi/drm/drm_fourcc.h
> > >> @@ -583,6 +583,28 @@ extern "C" {
> > >>*/
> > >>   #define I915_FORMAT_MOD_4_TILED fourcc_mod_code(INTEL, 9)
> > >>
> > >> +/*
> > >> + * Intel color control surfaces (CCS) for DG2 render compression.
> > >> + *
> > >> + * DG2 uses a new compression format for render compression. The general
> > >> + * layout is the same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
> > >> + * but a new hashing/compression algorithm is used, so a fresh modifier 
> > >> must
> > >> + * be associated with buffers of this type. Render compression uses 128 
> > >> byte
> > >> + * compression blocks.
> > >
> > > I think I've seen a way to configure the compression block size on TGL
> > > at least. I can't find the spec text for that at the moment though...
> > > Could we omit these mentions?
> > 
> > Not sure why general possibility of changing compression block size is 
> > relevant?
> > All hw features can be changed but this defines how this modifier is being
> > implemented.
> 
> I was concerned about compatibility between the different modes, but I've
> looked into the restrictions here and don't see any problems with this.
> 
> > Say you take I915_FORMAT_MOD_4_TILED_DG2_RC_CCS framebuffer including
> > control surface and copy it out, then come back and restore framebuffer with
> > same information. It is expected to be valid?
>
> > /Juha-Pekka
> > 
> > >> + */
> > >> +#define I915_FORMAT_MOD_4_TILED_DG2_RC_CCS fourcc_mod_code(INTEL, 10)
> > >> +
> > >
> > > How about something like:
> > >
> > > The main surface is Tile 4 and at plane index 0. The CCS plane is
> > > hidden from userspace. The main surface pitch is required to be a
> > > multiple of four Tile 4 widths. The CCS is configured with the render
> > > compression format associated with the main surface format.
> 
> Actually, let's omit the last sentence. CCS has always been affected
> by the main surface format, so I don't think there's a need to mention it
> specifically for the DG2 modifier.
>
> We do need to mention the 4-tile-wide pitch requirement though.

Agreed, the DG2 layout of planes and the tile format used - both
different wrt. the GEN12_RC_CCS format - should be described here.

> -Nanley
>  
> > > I think the CCS is technically accessible via the blitter engine,
> > > so the part about the plane being "hidden" may need some tweaking.

Maybe outside of the GEM object? Capturing all the above would you be ok
with the following?:

Intel color control surfaces (CCS) for DG2 render compression.

The main surface is Tile 4 and at plane index 0. The CCS data is stored
outside of the GEM object in a reserved memory area dedicated for the
storage of the CCS data from all GEM objects. The main surface pitch is
required to be a multiple of four Tile 4 widths. 


Intel color control surfaces (CCS) for DG2 media compression.

The main surface is Tile 4 and at plane index 0. For semi-planar formats
like NV12, the UV plane is Tile 4 at plane index 1. The CCS data both for
the main and semi-planar UV planes are stored outside of the GEM object
in a reserved memory area dedicated for the storage of the CCS data from
all GEM objects. The main surface pitch is required to be a multiple of
four Tile 4 widths. 

> > > -Nanley
> > >
> > >> +/*
> > >> + * Intel color control surfaces (CCS) for DG2 media compression.
> > >> + *
> > >> + * DG2 uses a new compression format for media compression. The
> > >> +general
> > >> + * layout is the same as I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS,
> > >> + * but a new hashing/compression algorithm is used, so a fresh
> > >> +modifier must
> > >> + * be associated with buffers of this type. Media compression uses
> > >> +256 byte
> > >> + * compression blocks.
> > >> + */
> > >> +#define I915_FORMAT_MOD_4_TILED_DG2_MC_CCS
> > fourcc_mod_code(INTEL,
> > >> +11)
> > >> +
> > >>   /*
> > >>* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized 
> > >> macroblocks
> > >>*
> > >> --
> > >> 2.20.1
> > >>
>

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add CDCLK checks to atomic check phase (rev5)

2022-03-18 Thread Patchwork

== Series Details ==

Series: Add CDCLK checks to atomic check phase (rev5)
URL   : https://patchwork.freedesktop.org/series/101068/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add CDCLK checks to atomic check phase (rev5)

2022-03-18 Thread Patchwork

== Series Details ==

Series: Add CDCLK checks to atomic check phase (rev5)
URL   : https://patchwork.freedesktop.org/series/101068/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
29531a1812df drm/i915/display: Add CDCLK actions to intel_cdclk_state
f19caadb81b6 drm/i915/display: s/intel_cdclk_can_squash/intel_cdclk_squash
-:28: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#28: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1980:
 {
+

total: 0 errors, 0 warnings, 1 checks, 40 lines checked
4d8ae0d2e4bb drm/i915/display: s/intel_cdclk_can_crawl/intel_cdclk_crawl
-:25: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#25: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1955:
+static bool intel_cdclk_crawl(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_state *a,

total: 0 errors, 0 warnings, 1 checks, 42 lines checked
275c56be3dc3 drm/i915/display: Add cdclk checks to atomic check
-:197: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#197: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:2053:
 {
+

total: 0 errors, 0 warnings, 1 checks, 180 lines checked

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Add preemption changes for Wa_14015141709 (rev2)

2022-03-18 Thread Matt Roper

On Fri, Mar 18, 2022 at 04:51:14AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/dg2: Add preemption changes for Wa_14015141709 (rev2)
> URL   : https://patchwork.freedesktop.org/series/101023/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_11379_full -> Patchwork_22602_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_22602_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_22602_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Participating hosts (12 -> 12)
> --
> 
>   No changes in participating hosts
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_22602_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_exec_parallel@engines@contexts:
> - shard-iclb: [PASS][1] -> [INCOMPLETE][2]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-iclb7/igt@gem_exec_parallel@engi...@contexts.html
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb4/igt@gem_exec_parallel@engi...@contexts.html
> 

Unexpected incomplete with no apparent warnings/errors.  Looks like we
previously had https://gitlab.freedesktop.org/drm/intel/-/issues/3812
open for this but it wasn't seen for a while and got closed.

This patch doesn't change the behavior of ICL, so it shouldn't be the
cause.

Patch applied to drm-intel-gt-next.  Thanks Anusha for the review.


Matt

>   
>  Suppressed 
> 
>   The following results come from untrusted machines, tests, or statuses.
>   They do not affect the overall result.
> 
>   * igt@gem_exec_parallel@fds@vecs0:
> - {shard-rkl}:([PASS][3], [PASS][4]) -> [INCOMPLETE][5]
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-rkl-4/igt@gem_exec_parallel@f...@vecs0.html
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-rkl-5/igt@gem_exec_parallel@f...@vecs0.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-rkl-5/igt@gem_exec_parallel@f...@vecs0.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_22602_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_create@create-massive:
> - shard-apl:  NOTRUN -> [DMESG-WARN][6] ([i915#4991])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-apl8/igt@gem_cre...@create-massive.html
> 
>   * igt@gem_eio@kms:
> - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#232])
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-tglb6/igt@gem_...@kms.html
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb1/igt@gem_...@kms.html
> 
>   * igt@gem_exec_capture@pi@bcs0:
> - shard-skl:  NOTRUN -> [INCOMPLETE][9] ([i915#4547])
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-skl6/igt@gem_exec_capture@p...@bcs0.html
> 
>   * igt@gem_exec_fair@basic-none-rrul@rcs0:
> - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/igt@gem_exec_fair@basic-none-r...@rcs0.html
> 
>   * igt@gem_exec_fair@basic-none@vcs0:
> - shard-kbl:  [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar 
> issue
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
>[12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html
> 
>   * igt@gem_exec_fair@basic-pace-share@rcs0:
> - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
>[13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11379/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>[14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
> 
>   * igt@gem_lmem_swapping@heavy-verify-multi:
> - shard-iclb: NOTRUN -> [SKIP][15] ([i915#4613])
>[15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-iclb3/igt@gem_lmem_swapp...@heavy-verify-multi.html
> 
>   * igt@gem_lmem_swapping@parallel-random-engines:
> - shard-kbl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
>[16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22602/shard-kbl1/igt@gem_lmem_swapp...@parallel-random-engines.html
> 
>   * igt@gem_lmem_swapping@verify-random:
> - shard-skl:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) 
> +1 similar issue
>[17]: 
> h

Re: [Intel-gfx] Small bar recovery vs compressed content on DG2

2022-03-18 Thread Bloomfield, Jon

@Thomas Hellström - I agree :-)

My question was really to @Joonas Lahtinen, who was saying we could always 
migrate in the CPU fault handler. I am pushing back on that unless we have no 
choice. It's the very complication we were trying to avoid with the current 
SAS. If that's what's needed, then so be it. But I'm asking whether we can 
instead handle this specially, instead of adding generic complexity to the 
primary code paths.

Jon

> -Original Message-
> From: Thomas Hellström 
> Sent: Friday, March 18, 2022 2:48 AM
> To: Bloomfield, Jon ; Joonas Lahtinen
> ; Intel Graphics Development  g...@lists.freedesktop.org>; Auld, Matthew ; C,
> Ramalingam ; Vetter, Daniel
> 
> Subject: Re: Small bar recovery vs compressed content on DG2
> 
> Hi,
> 
> On Thu, 2022-03-17 at 18:21 +, Bloomfield, Jon wrote:
> > +@Vetter, Daniel
> >
> > Let's not start re-inventing this on the fly again. That's how we got
> > into trouble in the past. The SAS/Whitepaper does currently require
> > the SMEM+LMEM placement for mappable, for good reasons.
> 
> Just to avoid any misunderstandings here:
> 
> We have two hard requirements from Arch that clash, main problem is
> compressed bos can't be captured on error with current designs.
> 
> From an engineering point of view we can do little more than list
> options available to resolve this and whether they are hard or not so
> hard to implemement. But IMHO Arch needs to agree on what's got to
> give.
> 
> Thanks,
> Thomas
> 
> 
> >
> > We cannot 'always migrate to mappable in the fault handler'. Or at
> > least, this is not as trivial as it is to write in a sentence due to
> > the need to spill out other active objects, and all the usual
> > challenges with context synchronization etc. It is possible, perhaps
> > with a lot of care, but it is challenging to guarantee, easy to
> > break, and not needed for 99.9% of software. We are trying to
> > simplify our driver stack.
> >
> > If we need a special mechanism for debug, we should devise a special
> > mechanism, not throw out the general LMEM+SMEM requirement. Are
> there
> > any identified first-class clients that require such access, or is it
> > only debugging tools?
> >
> > If only debug, then why can't the tool use a copy engine submission
> > to access the data in place? Or perhaps a bespoke ioctl to access
> > this via the KMD (and kmd submitted copy-engine BB)?
> >
> > Thanks,
> >
> > Jon
> >
> > > -Original Message-
> > > From: Thomas Hellström 
> > > Sent: Thursday, March 17, 2022 2:35 AM
> > > To: Joonas Lahtinen ; Bloomfield,
> > > Jon
> > > ; Intel Graphics Development  > > g...@lists.freedesktop.org>; Auld, Matthew ;
> > > C,
> > > Ramalingam 
> > > Subject: Re: Small bar recovery vs compressed content on DG2
> > >
> > > On Thu, 2022-03-17 at 10:43 +0200, Joonas Lahtinen wrote:
> > > > Quoting Thomas Hellström (2022-03-16 09:25:16)
> > > > > Hi!
> > > > >
> > > > > Do we somehow need to clarify in the headers the semantics for
> > > > > this?
> > > > >
> > > > >  From my understanding when discussing the CCS migration series
> > > > > with
> > > > > Ram, the kernel will never do any resolving (compressing /
> > > > > decompressing) migrations or evictions which basically implies
> > > > > the
> > > > > following:
> > > > >
> > > > > *) Compressed data must have LMEM only placement, otherwise the
> > > GPU
> > > > > would read garbage if accessing from SMEM.
> > > >
> > > > This has always been the case, so it should be documented in the
> > > > uAPI
> > > > headers and kerneldocs.
> > > >
> > > > > *) Compressed data can't be assumed to be mappable by the CPU,
> > > > > because
> > > > > in order to ensure that on small BAR, the placement needs to be
> > > > > LMEM+SMEM.
> > > >
> > > > Not strictly true, as we could always migrate to the mappable
> > > > region
> > > > in
> > > > the CPU fault handler. Will need the same set of tricks as with
> > > > limited
> > > > mappable GGTT in past.
> > >
> > > In addition to Matt's reply:
> > >
> > > Yes, if there is sufficient space. I'm not sure we want to
> > > complicate
> > > this to migrate only part of the buffer to mappable on a fault
> > > basis?
> > > Otherwise this is likely to fail.
> > >
> > > One option is to allow cpu-mapping from SYSTEM like TTM is doing
> > > for
> > > evicted buffers, even if SYSTEM is not in the placement list, and
> > > then
> > > migrate back to LMEM for gpu access.
> > >
> > > But can user-space even interpret the compressed data when CPU-
> > > mapping?
> > > without access to the CCS metadata?
> > >
> > > >
> > > > > *) Neither can compressed data be part of a CAPTURE buffer,
> > > > > because
> > > > > that
> > > > > requires the data to be CPU-mappable.
> > > >
> > > > Especially this will be too big of a limitation which we can't
> > > > really
> > > > afford
> > > > when it comes to debugging.
> > >
> > > Same here WRT user-space interpretation.
> > >
> > > This will become especially tricky on small BAR, because

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix renamed struct field

2022-03-18 Thread Vudum, Lakshminarayana

Regression is related to https://gitlab.freedesktop.org/drm/intel/-/issues/4391
All tests - dmesg-warn/dmesg-fail - *ERROR* AUX B/DDI B/PHY B: did not complete 
or timeout within 10ms (status 0xad4003ff)

Re-reported the results.

Lakshmi.
-Original Message-
From: De Marchi, Lucas  
Sent: Friday, March 18, 2022 7:52 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana 
Subject: Re: ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix 
renamed struct field

On Thu, Mar 17, 2022 at 04:14:16AM +, Patchwork wrote:
>== Series Details ==
>
>Series: series starting with [1/2] drm/i915: Fix renamed struct field
>URL   : https://patchwork.freedesktop.org/series/101448/
>State : failure
>
>== Summary ==
>
>CI Bug Log - changes from CI_DRM_11372_full -> Patchwork_22590_full 
>
>
>Summary
>---
>
>  **FAILURE**
>
>  Serious unknown changes coming with Patchwork_22590_full absolutely 
> need to be  verified manually.
>
>  If you think the reported changes have nothing to do with the changes  
> introduced in Patchwork_22590_full, please notify your bug team to 
> allow them  to document this new failure mode, which will reduce false 
> positives in CI.
>
>
>
>Participating hosts (11 -> 11)
>--
>
>  No changes in participating hosts
>
>Possible new issues
>---
>
>  Here are the unknown changes that may have been introduced in 
> Patchwork_22590_full:
>
>### IGT changes ###
>
> Possible regressions 
>
>  * igt@gem_mmap_wc@write-wc-read-gtt:
>- shard-skl:  [PASS][1] -> [INCOMPLETE][2]
>   [1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl9/igt@gem_mmap...@write-wc-read-gtt.html
>   [2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl6/ig
> t@gem_mmap...@write-wc-read-gtt.html

nothing related to this series that only changes the behavior for media engine 
on media_ver >= 11

Lucas De Marchi

>
>
>Known issues
>
>
>  Here are the changes found in Patchwork_22590_full that come from known 
> issues:
>
>### IGT changes ###
>
> Issues hit 
>
>  * igt@gem_ctx_isolation@preservation-s3@vcs0:
>- shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar 
> issues
>   [3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html
>   [4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl7/ig
> t@gem_ctx_isolation@preservation...@vcs0.html
>
>  * igt@gem_exec_capture@pi@rcs0:
>- shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#4547])
>   [5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
>   [6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl4/ig
> t@gem_exec_capture@p...@rcs0.html
>
>  * igt@gem_exec_fair@basic-none@vcs0:
>- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar 
> issues
>   [7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
>   [8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl3/ig
> t@gem_exec_fair@basic-n...@vcs0.html
>
>  * igt@gem_exec_fair@basic-pace-share@rcs0:
>- shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
>   [9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
>   [10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-tglb5/i
> gt@gem_exec_fair@basic-pace-sh...@rcs0.html
>
>  * igt@gem_exec_fair@basic-pace-solo@rcs0:
>- shard-glk:  NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
>   [11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk9/ig
> t@gem_exec_fair@basic-pace-s...@rcs0.html
>
>  * igt@gem_exec_fair@basic-throttle@rcs0:
>- shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842])
>   [12]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
>   [13]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk3/ig
> t@gem_exec_fair@basic-throt...@rcs0.html
>
>  * igt@gem_exec_suspend@basic-s3@smem:
>- shard-apl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +4 
> similar issues
>   [14]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-apl2/igt@gem_exec_suspend@basic...@smem.html
>   [15]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-apl3/ig
> t@gem_exec_suspend@basic...@smem.html
>
>  * igt@gem_lmem_swapping@basic:
>- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
>   [16]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl10/i
> gt@gem_lmem_swapp...@basic.html
>
>  * igt@gem_lmem_swapping@parallel-random-engines:
>- shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
>

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix renamed struct field (rev2)

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field (rev2)
URL   : https://patchwork.freedesktop.org/series/101448/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11380 -> Patchwork_22611


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/index.html

Participating hosts (48 -> 47)
--

  Additional (2): bat-adlm-1 bat-jsl-2 
  Missing(3): shard-dg1 fi-bsw-cyan fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22611:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_frontbuffer_tracking@basic:
- {bat-dg2-9}:[FAIL][1] ([i915#5276]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg2-9/igt@kms_frontbuffer_track...@basic.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-dg2-9/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- {bat-adlm-1}:   NOTRUN -> [INCOMPLETE][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-adlm-1/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
Known issues


  Here are the changes found in Patchwork_22611 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][4] -> [INCOMPLETE][5] ([i915#146])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][6] -> [DMESG-WARN][7] ([i915#1982])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@gem_contexts:
- fi-glk-dsi: [PASS][8] -> [DMESG-WARN][9] ([i915#4391])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/fi-glk-dsi/igt@i915_selftest@live@gem_contexts.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/fi-glk-dsi/igt@i915_selftest@live@gem_contexts.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][10] -> [DMESG-FAIL][11] ([i915#4494] / 
[i915#4957])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [DMESG-WARN][12] ([i915#4391]) -> [PASS][13] +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_big_fb@linear-max-hw-stride-64bpp-rotate-180:
- {shard-rkl}:([SKIP][16], [PASS][17]) ([i915#1845] / [i915#4098]) 
-> [PASS][18]
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-rkl-4/igt@kms_big...@linear-max-hw-stride-64bpp-rotate-180.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-rkl-6/igt@kms_big...@linear-max-hw-stride-64bpp-rotate-180.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-rkl-6/igt@kms_big...@linear-max-hw-stride-64bpp-rotate-180.html

  * igt@kms_cursor_crc@pipe-b-cursor-64x21-rapid-movement:
- {shard-rkl}:([PASS][19], [SKIP][20]) ([fdo#112022] / [i915#4070]) 
-> [PASS][21]
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-rkl-6/igt@kms_cursor_...@pipe-b-cursor-64x21-rapid-movement.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-rkl-4/igt@kms_cursor_...@pipe-b-cursor-64x21-rapid-movement.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/shard-rkl-6/igt@kms_cursor_...@pipe-b-cursor-64x21-rapid-movement.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#10

Re: [Intel-gfx] [PATCH] drm/i915/display/adlp: More voltage swing table updates

2022-03-18 Thread Ville Syrjälä

On Tue, Mar 15, 2022 at 01:51:22PM -0700, José Roberto de Souza wrote:
> A few more updates in the alderlake-P voltage swing tables.
> 
> eDP HBR3 table was the same as icelake one but now it has changes for
> voltage 0 and pre-emphasis 2 line.
> And DP tables also had one line change in each.
> 
> Bspec: 49291
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Ville Syrjälä 

> ---
>  .../drm/i915/display/intel_ddi_buf_trans.c| 22 +++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c 
> b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> index 9a2b14927895e..94e64661b4fdb 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c
> @@ -907,7 +907,7 @@ static const union intel_ddi_buf_trans_entry 
> _adlp_combo_phy_trans_dp_hbr[] = {
>   { .icl = { 0xA, 0x4C, 0x3F, 0x00, 0x00 } }, /* 500   500  0.0   
> */
>   { .icl = { 0xC, 0x73, 0x34, 0x00, 0x0B } }, /* 500   700  2.9   
> */
>   { .icl = { 0x6, 0x7F, 0x2F, 0x00, 0x10 } }, /* 500   900  5.1   
> */
> - { .icl = { 0xC, 0x73, 0x3E, 0x00, 0x01 } }, /* 650   700  0.6   
> */
> + { .icl = { 0xC, 0x7C, 0x3C, 0x00, 0x03 } }, /* 650   700  0.6   
> */
>   { .icl = { 0x6, 0x7F, 0x35, 0x00, 0x0A } }, /* 600   900  3.5   
> */
>   { .icl = { 0x6, 0x7F, 0x3F, 0x00, 0x00 } }, /* 900   900  0.0   
> */
>  };
> @@ -921,7 +921,7 @@ static const union intel_ddi_buf_trans_entry 
> _adlp_combo_phy_trans_dp_hbr2_hbr3[
>   /* NT mV Trans mV db
> */
>   { .icl = { 0xA, 0x35, 0x3F, 0x00, 0x00 } }, /* 350   350  0.0   
> */
>   { .icl = { 0xA, 0x4F, 0x37, 0x00, 0x08 } }, /* 350   500  3.1   
> */
> - { .icl = { 0xC, 0x71, 0x2F, 0x00, 0x10 } }, /* 350   700  6.0   
> */
> + { .icl = { 0xC, 0x71, 0x30, 0x00, 0x0F } }, /* 350   700  6.0   
> */
>   { .icl = { 0x6, 0x7F, 0x2B, 0x00, 0x14 } }, /* 350   900  8.2   
> */
>   { .icl = { 0xA, 0x4C, 0x3F, 0x00, 0x00 } }, /* 500   500  0.0   
> */
>   { .icl = { 0xC, 0x73, 0x34, 0x00, 0x0B } }, /* 500   700  2.9   
> */
> @@ -945,14 +945,28 @@ static const union intel_ddi_buf_trans_entry 
> _adlp_combo_phy_trans_edp_hbr2[] =
>   { .icl = { 0x4, 0x7A, 0x38, 0x00, 0x07 } }, /* 350   350  0.0   
> */
>  };
>  
> +static const union intel_ddi_buf_trans_entry 
> _adlp_combo_phy_trans_dp_hbr2_edp_hbr3[] = {
> + /* NT mV Trans mV db
> */
> + { .icl = { 0xA, 0x35, 0x3F, 0x00, 0x00 } }, /* 350   350  0.0   
> */
> + { .icl = { 0xA, 0x4F, 0x37, 0x00, 0x08 } }, /* 350   500  3.1   
> */
> + { .icl = { 0xC, 0x71, 0x30, 0x00, 0x0f } }, /* 350   700  6.0   
> */
> + { .icl = { 0x6, 0x7F, 0x2B, 0x00, 0x14 } }, /* 350   900  8.2   
> */
> + { .icl = { 0xA, 0x4C, 0x3F, 0x00, 0x00 } }, /* 500   500  0.0   
> */
> + { .icl = { 0xC, 0x73, 0x34, 0x00, 0x0B } }, /* 500   700  2.9   
> */
> + { .icl = { 0x6, 0x7F, 0x2F, 0x00, 0x10 } }, /* 500   900  5.1   
> */
> + { .icl = { 0xC, 0x6C, 0x3C, 0x00, 0x03 } }, /* 650   700  0.6   
> */
> + { .icl = { 0x6, 0x7F, 0x35, 0x00, 0x0A } }, /* 600   900  3.5   
> */
> + { .icl = { 0x6, 0x7F, 0x3F, 0x00, 0x00 } }, /* 900   900  0.0   
> */
> +};
> +
>  static const struct intel_ddi_buf_trans adlp_combo_phy_trans_dp_hbr2_hbr3 = {
>   .entries = _adlp_combo_phy_trans_dp_hbr2_hbr3,
>   .num_entries = ARRAY_SIZE(_adlp_combo_phy_trans_dp_hbr2_hbr3),
>  };
>  
>  static const struct intel_ddi_buf_trans adlp_combo_phy_trans_edp_hbr3 = {
> - .entries = _icl_combo_phy_trans_dp_hbr2_edp_hbr3,
> - .num_entries = ARRAY_SIZE(_icl_combo_phy_trans_dp_hbr2_edp_hbr3),
> + .entries = _adlp_combo_phy_trans_dp_hbr2_edp_hbr3,
> + .num_entries = ARRAY_SIZE(_adlp_combo_phy_trans_dp_hbr2_edp_hbr3),
>  };
>  
>  static const struct intel_ddi_buf_trans adlp_combo_phy_trans_edp_up_to_hbr2 
> = {
> -- 
> 2.35.1

-- 
Ville Syrjälä
Intel

Re: [Intel-gfx] [PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface

2022-03-18 Thread Andrzej Hajda


On 18.03.2022 03:10, Andi Shyti wrote:

Now that we have tiles we want each of them to have its own
interface. A directory "gt/" is created under "cardN/" that will
contain as many diroctories as the tiles.

In the coming patches tile related interfaces will be added. For
now the sysfs gt structure simply has an id interface related
to the current tile count.

The directory structure will follow this scheme:

 /sys/.../card0
  └── gt
      ├── gt0
      │   └── id
  :
 :
 └─- gtN
          └── id

This new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Sujaritha Sundaresan 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/gt/intel_gt.c   |   2 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  34 
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/i915_sysfs.c|   7 +-
  drivers/gpu/drm/i915/i915_sysfs.h|   3 +
  scripts/extract-cert | Bin 0 -> 17952 bytes



With above removed.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dmc: move assert_dmc_loaded() to intel_dmc.c

2022-03-18 Thread Lucas De Marchi


On Fri, Mar 18, 2022 at 11:19:46AM +0200, Jani Nikula wrote:

On Thu, 17 Mar 2022, Lucas De Marchi  wrote:

On Thu, Mar 17, 2022 at 08:36:14PM +0200, Jani Nikula wrote:

Start localizing DMC register and data access to intel_dmc.c.

Signed-off-by: Jani Nikula 
---
drivers/gpu/drm/i915/display/intel_display_power.c | 12 
drivers/gpu/drm/i915/display/intel_dmc.c   | 11 +++
drivers/gpu/drm/i915/display/intel_dmc.h   |  2 ++
3 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index b3efe345567f..6a5695008f7c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -905,18 +905,6 @@ static void bxt_disable_dc9(struct drm_i915_private 
*dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
}

-static void assert_dmc_loaded(struct drm_i915_private *dev_priv)
-{
-   drm_WARN_ONCE(&dev_priv->drm,
- !intel_de_read(dev_priv,
-
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
-"DMC program storage start is NULL\n");
-   drm_WARN_ONCE(&dev_priv->drm, !intel_de_read(dev_priv, DMC_SSP_BASE),
- "DMC SSP Base Not fine\n");
-   drm_WARN_ONCE(&dev_priv->drm, !intel_de_read(dev_priv, DMC_HTP_SKL),
- "DMC HTP Not fine\n");
-}
-
/**
 * intel_display_power_set_target_dc_state - Set target dc state.
 * @dev_priv: i915 device
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 66fd69259e73..63ae16622c3e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -305,6 +305,17 @@ void intel_dmc_load_program(struct drm_i915_private 
*dev_priv)
gen9_set_dc_state_debugmask(dev_priv);
}

+void assert_dmc_loaded(struct drm_i915_private *i915)
+{
+   drm_WARN_ONCE(&i915->drm,
+ !intel_de_read(i915, 
DMC_PROGRAM(i915->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+ "DMC program storage start is NULL\n");
+   drm_WARN_ONCE(&i915->drm, !intel_de_read(i915, DMC_SSP_BASE),
+ "DMC SSP Base Not fine\n");
+   drm_WARN_ONCE(&i915->drm, !intel_de_read(i915, DMC_HTP_SKL),
+ "DMC HTP Not fine\n");
+}
+
static bool fw_info_matches_stepping(const struct intel_fw_info *fw_info,
 const struct stepping_info *si)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h 
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 7c590309a3a9..326f80ad0f31 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -55,4 +55,6 @@ void intel_dmc_ucode_suspend(struct drm_i915_private *i915);
void intel_dmc_ucode_resume(struct drm_i915_private *i915);
bool intel_dmc_has_payload(struct drm_i915_private *i915);

+void assert_dmc_loaded(struct drm_i915_private *i915);



intel_dmc_assert_loaded()?


assert_dmc_loaded() is in line with the display asserts we have:

git grep assert_ -- drivers/gpu/drm/i915/display/*.h

I'd rather stick with that convention for now, and moving away from it
should be a separate conversation.


ok, fair enough.


Reviewed-by: Lucas De Marchi 

thanks
Lucas De Marchi



BR,
Jani.



Lucas De Marchi


+
#endif /* __INTEL_DMC_H__ */
--
2.30.2



--
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v6 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces

2022-03-18 Thread Andrzej Hajda


On 18.03.2022 03:10, Andi Shyti wrote:

Now tiles have their own sysfs interfaces under the gt/
directory. Because RPS is a property that can be configured on a
tile basis, then each tile should have its own interface

The new sysfs structure will have a similar layout for the 4 tile
case:

/sys/.../card0
  ├── gt
  │   ├── gt0
  │   │   ├── id
  │   │   ├── rc6_enable
  │   │   ├── rc6_residency_ms
  │   │   ├── rps_act_freq_mhz
  │   │   ├── rps_boost_freq_mhz
  │   │   ├── rps_cur_freq_mhz
  │   │   ├── rps_max_freq_mhz
  │   │   ├── rps_min_freq_mhz
  │   │   ├── rps_RP0_freq_mhz
  │   │   ├── rps_RP1_freq_mhz
  │   │   └── rps_RPn_freq_mhz
  .   .
  .   .
  .   .
  │   └── gtN
  │   ├── id
  │   ├── rc6_enable
  │   ├── rc6_residency_ms
  │   ├── rps_act_freq_mhz
  │   ├── rps_boost_freq_mhz
  │   ├── rps_cur_freq_mhz
  │   ├── rps_max_freq_mhz
  │   ├── rps_min_freq_mhz
  │   ├── rps_RP0_freq_mhz
  │   ├── rps_RP1_freq_mhz
  │   └── rps_RPn_freq_mhz
  ├── gt_act_freq_mhz   -+
  ├── gt_boost_freq_mhz  |
  ├── gt_cur_freq_mhz|Original interface
  ├── gt_max_freq_mhz+─-> kept as existing ABI;
  ├── gt_min_freq_mhz|it points to gt0/
  ├── gt_RP0_freq_mhz|
  ├── gt_RP1_freq_mhz|
  └── gt_RPn_freq_mhz   -+

The existing interfaces have been kept in their original location
to preserve the existing ABI. They act on all the GTs: when
writing they loop through all the GTs and write the information
on each interface. When reading they provide the average value
from all the GTs.

This patch is not really adding exposing new interfaces (new
ABI) other than adapting the existing one to more tiles. In any
case this new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Signed-off-by: Lucas De Marchi 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix renamed struct field

2022-03-18 Thread Lucas De Marchi


On Thu, Mar 17, 2022 at 04:14:16AM +, Patchwork wrote:

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field
URL   : https://patchwork.freedesktop.org/series/101448/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11372_full -> Patchwork_22590_full


Summary
---

 **FAILURE**

 Serious unknown changes coming with Patchwork_22590_full absolutely need to be
 verified manually.

 If you think the reported changes have nothing to do with the changes
 introduced in Patchwork_22590_full, please notify your bug team to allow them
 to document this new failure mode, which will reduce false positives in CI.



Participating hosts (11 -> 11)
--

 No changes in participating hosts

Possible new issues
---

 Here are the unknown changes that may have been introduced in 
Patchwork_22590_full:

### IGT changes ###

 Possible regressions 

 * igt@gem_mmap_wc@write-wc-read-gtt:
   - shard-skl:  [PASS][1] -> [INCOMPLETE][2]
  [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl9/igt@gem_mmap...@write-wc-read-gtt.html
  [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl6/igt@gem_mmap...@write-wc-read-gtt.html


nothing related to this series that only changes the behavior for media
engine on media_ver >= 11

Lucas De Marchi




Known issues


 Here are the changes found in Patchwork_22590_full that come from known issues:

### IGT changes ###

 Issues hit 

 * igt@gem_ctx_isolation@preservation-s3@vcs0:
   - shard-kbl:  [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +3 similar 
issues
  [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_ctx_isolation@preservation...@vcs0.html
  [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl7/igt@gem_ctx_isolation@preservation...@vcs0.html

 * igt@gem_exec_capture@pi@rcs0:
   - shard-skl:  [PASS][5] -> [INCOMPLETE][6] ([i915#4547])
  [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-skl10/igt@gem_exec_capture@p...@rcs0.html
  [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl4/igt@gem_exec_capture@p...@rcs0.html

 * igt@gem_exec_fair@basic-none@vcs0:
   - shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues
  [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
  [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html

 * igt@gem_exec_fair@basic-pace-share@rcs0:
   - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842])
  [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
  [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

 * igt@gem_exec_fair@basic-pace-solo@rcs0:
   - shard-glk:  NOTRUN -> [FAIL][11] ([i915#2842]) +1 similar issue
  [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html

 * igt@gem_exec_fair@basic-throttle@rcs0:
   - shard-glk:  [PASS][12] -> [FAIL][13] ([i915#2842])
  [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
  [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk3/igt@gem_exec_fair@basic-throt...@rcs0.html

 * igt@gem_exec_suspend@basic-s3@smem:
   - shard-apl:  [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +4 similar 
issues
  [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11372/shard-apl2/igt@gem_exec_suspend@basic...@smem.html
  [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-apl3/igt@gem_exec_suspend@basic...@smem.html

 * igt@gem_lmem_swapping@basic:
   - shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
  [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-skl10/igt@gem_lmem_swapp...@basic.html

 * igt@gem_lmem_swapping@parallel-random-engines:
   - shard-glk:  NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
  [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-glk9/igt@gem_lmem_swapp...@parallel-random-engines.html
   - shard-kbl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
  [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-kbl4/igt@gem_lmem_swapp...@parallel-random-engines.html

 * igt@gem_pxp@reject-modify-context-protection-off-2:
   - shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270])
  [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22590/shard-iclb6/igt@gem_...@reject-modify-context-protection-off-2.html

 * igt@gen3_render_linear_blits:
   - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289])
  [20]: 
https://intel-gfx-ci.01.org/

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Lisovskiy, Stanislav

On Fri, Mar 18, 2022 at 04:38:27PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 16:19 +0200, Lisovskiy, Stanislav wrote:
> > On Fri, Mar 18, 2022 at 02:21:10PM +0200, Souza, Jose wrote:
> > > On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > > > We are currently getting FIFO underruns, in particular
> > > > when PSR2 is enabled. There seem to be no existing workaround
> > > > or patches, which can fix that issue(were expecting some recent
> > > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > > which unfortunately didn't).
> > > > Current idea is that it looks like for some reason the
> > > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > theoretically correct.
> > > > So bump it up a bit by 15%(minimum experimental amount required
> > > > to get it working), if PSR2 is enabled.
> > > > For PSR1 there is no need in this hack, so we limit it only
> > > > to PSR2 and Alderlake.
> > > 
> > > It this workaround meant to be permanent? If yes we should file a HSD and 
> > > get hardware folks feedback.
> > 
> > Nope, I hope we figure out some more elegant solution at some point.
> 
> So please add this information to commit message and code comment.
> 

Yes.

> 
> > 
> > > 
> > > > 
> > > > Signed-off-by: Stanislav Lisovskiy 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
> > > >  1 file changed, 13 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index fda8b701..095b79950788 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > > intel_crtc_state *crtc_state)
> > > > dev_priv->max_cdclk_freq));
> > > > }
> > > >  
> > > 
> > > Please add some comment in the code about this workaround.
> > > 
> > > 
> > > > +   if (IS_ALDERLAKE_P(dev_priv)) {
> > > > +   struct intel_encoder *encoder;
> > > > +
> > > > +   for_each_intel_encoder_with_psr(&dev_priv->drm, 
> > > > encoder) {
> > > > +   struct intel_dp *intel_dp = 
> > > > enc_to_intel_dp(encoder);
> > > > +
> > > > +   if (intel_dp->psr.psr2_enabled) {
> > > 
> > > You should check the has_psr2 in the crtc_state, PSR2 could be disabled 
> > > when this state is committed.
> > > 
> > > > +   min_cdclk = DIV_ROUND_UP(min_cdclk * 
> > > > 100, 85);
> > > 
> > > This is not increasing by 15%.
> > > 
> > > min_cdclk = 500
> > > 500 * 100 = 5
> > > 5 / 85 = 588.235294118
> > > 
> > > While 15% of 500 is 75.
> > > 
> > > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk 
> > > twice.
> > > 
> > > > +   break;
> > 

So 588 here is the number of which 500 constitutes 85 %, i.e those "88,.." are 
15 % of 588,
but not of 500.

Not huge difference though, but needs to be fixed.

> > No, we won't bump up it twice, because we initialize min_cdclk here from 
> > pixel rate initially
> > and only then apply all those dirty hacks and optimizations. There is 
> > similar code above as
> > well.
> > For each crtc we call this function but as starting point always its pixel 
> > rate is used,
> > then the max() of those would be the actual new cdclk.
> 
> It will if you are iterating with for_each_intel_encoder_with_psr() and there 
> is more than one encoder with PSR2 enabled.
> Switching to crtc_state->has_psr2 and then increasing the min_cdclk of the 
> pipe with PSR2 enabled, should fix it.

But we call "break" there, after we meet first encoder with psr2_enabled, we 
exit the for cycle.

Stan

> 
> > 
> > As for 15%, good point took this from expression above in that func, but 
> > indeed this is 
> > no a 15%.
> > 
> > Stan
> > 
> > > > +   }
> > > > +   }
> > > > +   }
> > > > +
> > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > drm_dbg_kms(&dev_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d 
> > > > kHz)\n",
> > > 
>

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Souza, Jose

On Fri, 2022-03-18 at 16:22 +0200, Lisovskiy, Stanislav wrote:
> On Fri, Mar 18, 2022 at 02:27:53PM +0200, Souza, Jose wrote:
> > On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> > > On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > > > We are currently getting FIFO underruns, in particular
> > > > when PSR2 is enabled. There seem to be no existing workaround
> > > > or patches, which can fix that issue(were expecting some recent
> > > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > > which unfortunately didn't).
> > > > Current idea is that it looks like for some reason the
> > > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > > theoretically correct.
> > > > So bump it up a bit by 15%(minimum experimental amount required
> > > > to get it working), if PSR2 is enabled.
> > > > For PSR1 there is no need in this hack, so we limit it only
> > > > to PSR2 and Alderlake.
> > > 
> > > It this workaround meant to be permanent? If yes we should file a HSD and 
> > > get hardware folks feedback.
> > > 
> > > > 
> > > > Signed-off-by: Stanislav Lisovskiy 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
> > > >  1 file changed, 13 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > index fda8b701..095b79950788 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > > intel_crtc_state *crtc_state)
> > > > dev_priv->max_cdclk_freq));
> > > > }
> > > >  
> > > 
> > > Please add some comment in the code about this workaround.
> > > 
> > > 
> > > > +   if (IS_ALDERLAKE_P(dev_priv)) {
> > > > +   struct intel_encoder *encoder;
> > > > +
> > > > +   for_each_intel_encoder_with_psr(&dev_priv->drm, 
> > > > encoder) {
> > > > +   struct intel_dp *intel_dp = 
> > > > enc_to_intel_dp(encoder);
> > > > +
> > > > +   if (intel_dp->psr.psr2_enabled) {
> > > 
> > > You should check the has_psr2 in the crtc_state, PSR2 could be disabled 
> > > when this state is committed.
> > 
> > Ah and if a remember correctly those underruns only happens in a scenario 
> > with 4 pipes enabled? or it also happens with 2 and 3 pipes?
> > Anyways would be better to narrow down the cases where the workaround is 
> > applied.
> > So for at least in a case with a single pipe enabled we can have the lowest 
> > cdclk as possible. 
> 
> I was thinking the same initially, but this underrun is observed in lesser 
> pipe cases, when PSR2 
> is enabled.

Please check if at least the one pipe case really need this WA.

> 
> Stan
> 
> > 
> > > 
> > > > +   min_cdclk = DIV_ROUND_UP(min_cdclk * 
> > > > 100, 85);
> > > 
> > > This is not increasing by 15%.
> > > 
> > > min_cdclk = 500
> > > 500 * 100 = 5
> > > 5 / 85 = 588.235294118
> > > 
> > > While 15% of 500 is 75.
> > > 
> > > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk 
> > > twice.
> > > 
> > > > +   break;
> > > > +   }
> > > > +   }
> > > > +   }
> > > > +
> > > > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > > > drm_dbg_kms(&dev_priv->drm,
> > > > "required cdclk (%d kHz) exceeds max (%d 
> > > > kHz)\n",
> > > 
> >

Re: [Intel-gfx] [PATCH] drm/i915: avoid concurrent writes to aux_inv

2022-03-18 Thread Tvrtko Ursulin




On 18/03/2022 05:26, fei.y...@intel.com wrote:

From: Fei Yang 

GPU hangs have been observed when multiple engines write to the
same aux_inv register at the same time. To avoid this each engine
should only invalidate its own auxiliary table. The function
gen12_emit_flush_xcs() currently invalidate the auxiliary table for
all engines because the rq->engine is not necessarily the engine
eventually carrying out the request, and potentially the engine
could even be a virtual one (with engine->instance being -1).
With the MMIO remap feature, we can actually set bit 17 of MI_LRI
instruction and let the hardware to figure out the local aux_inv
register at runtime to avoid invalidating auxiliary table for all
engines.

Bspec: 45728

Cc: Stuart Summers 
Cc: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Signed-off-by: Fei Yang 
---
  drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 42 +---
  drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  1 +
  2 files changed, 11 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c 
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 36148887c699..d440c5dfb6b7 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -165,30 +165,6 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
  }
  
-static i915_reg_t aux_inv_reg(const struct intel_engine_cs *engine)

-{
-   static const i915_reg_t vd[] = {
-   GEN12_VD0_AUX_NV,
-   GEN12_VD1_AUX_NV,
-   GEN12_VD2_AUX_NV,
-   GEN12_VD3_AUX_NV,
-   };
-
-   static const i915_reg_t ve[] = {
-   GEN12_VE0_AUX_NV,
-   GEN12_VE1_AUX_NV,
-   };
-
-   if (engine->class == VIDEO_DECODE_CLASS)
-   return vd[engine->instance];
-
-   if (engine->class == VIDEO_ENHANCEMENT_CLASS)
-   return ve[engine->instance];
-
-   GEM_BUG_ON("unknown aux_inv reg\n");
-   return INVALID_MMIO_REG;
-}
-
  static u32 *gen12_emit_aux_table_inv(const i915_reg_t inv_reg, u32 *cs)
  {
*cs++ = MI_LOAD_REGISTER_IMM(1);
@@ -296,7 +272,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (!HAS_FLAT_CCS(rq->engine->i915)) {
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
-   cmd += 2 * hweight32(aux_inv) + 2;
+   cmd += 4;
}
}
  
@@ -329,14 +305,16 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)

*cs++ = 0; /* value */
  
  	if (aux_inv) { /* hsdes: 1809175790 */

-   struct intel_engine_cs *engine;
-   unsigned int tmp;
-
-   *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
-   for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
-   *cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
-   *cs++ = AUX_INV;
+   *cs++ = MI_LOAD_REGISTER_IMM(1) | MI_LRI_MMIO_REMAP_EN;


Cool, I didn't know this exists. First Bspec link I found did not 
mention these register, but second did. That one however (29545) has a 
worrying "removed by" tag which seems to point to a story suggesting the 
remapping table might be gone on machines with flat ccs?! Could you 
double check please?



+   if (rq->engine->class == VIDEO_DECODE_CLASS) {
+   *cs++ = i915_mmio_reg_offset(GEN12_VD0_AUX_NV);
+   } else if (rq->engine->class == VIDEO_ENHANCEMENT_CLASS) {
+   *cs++ = i915_mmio_reg_offset(GEN12_VE0_AUX_NV);
+   } else {
+   GEM_BUG_ON("unknown aux_inv reg\n");
+   *cs++ = i915_mmio_reg_offset(INVALID_MMIO_REG);


I'd consider not emitting the LRI if we don't know what to put in unless 
there is some hidden point to do it?



}
+   *cs++ = AUX_INV;
*cs++ = MI_NOOP;
}
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h

index d112ffd56418..2d150eec5c65 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -144,6 +144,7 @@
  #define MI_LOAD_REGISTER_IMM(x)   MI_INSTR(0x22, 2*(x)-1)
  /* Gen11+. addr = base + (ctx_restore ? offset & GENMASK(12,2) : offset) */
  #define   MI_LRI_LRM_CS_MMIO  REG_BIT(19)
+#define   MI_LRI_MMIO_REMAP_EN (1 << 17)
  #define   MI_LRI_FORCE_POSTED (1<<12)


Passing observation - three bits, three flavours of expressing them, sigh...

Regards,

Tvrtko


  #define MI_LOAD_REGISTER_IMM_MAX_REGS (126)
  #define MI_STORE_REGISTER_MEMMI_INSTR(0x24, 1)

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Souza, Jose

On Fri, 2022-03-18 at 16:19 +0200, Lisovskiy, Stanislav wrote:
> On Fri, Mar 18, 2022 at 02:21:10PM +0200, Souza, Jose wrote:
> > On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > > We are currently getting FIFO underruns, in particular
> > > when PSR2 is enabled. There seem to be no existing workaround
> > > or patches, which can fix that issue(were expecting some recent
> > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > which unfortunately didn't).
> > > Current idea is that it looks like for some reason the
> > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > theoretically correct.
> > > So bump it up a bit by 15%(minimum experimental amount required
> > > to get it working), if PSR2 is enabled.
> > > For PSR1 there is no need in this hack, so we limit it only
> > > to PSR2 and Alderlake.
> > 
> > It this workaround meant to be permanent? If yes we should file a HSD and 
> > get hardware folks feedback.
> 
> Nope, I hope we figure out some more elegant solution at some point.

So please add this information to commit message and code comment.  


> 
> > 
> > > 
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index fda8b701..095b79950788 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > intel_crtc_state *crtc_state)
> > >   dev_priv->max_cdclk_freq));
> > >   }
> > >  
> > 
> > Please add some comment in the code about this workaround.
> > 
> > 
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> > 
> > You should check the has_psr2 in the crtc_state, PSR2 could be disabled 
> > when this state is committed.
> > 
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> > 
> > This is not increasing by 15%.
> > 
> > min_cdclk = 500
> > 500 * 100 = 5
> > 5 / 85 = 588.235294118
> > 
> > While 15% of 500 is 75.
> > 
> > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> > 
> > > + break;
> 
> No, we won't bump up it twice, because we initialize min_cdclk here from 
> pixel rate initially
> and only then apply all those dirty hacks and optimizations. There is similar 
> code above as
> well.
> For each crtc we call this function but as starting point always its pixel 
> rate is used,
> then the max() of those would be the actual new cdclk.

It will if you are iterating with for_each_intel_encoder_with_psr() and there 
is more than one encoder with PSR2 enabled.
Switching to crtc_state->has_psr2 and then increasing the min_cdclk of the pipe 
with PSR2 enabled, should fix it.

> 
> As for 15%, good point took this from expression above in that func, but 
> indeed this is 
> no a 15%.
> 
> Stan
> 
> > > + }
> > > + }
> > > + }
> > > +
> > >   if (min_cdclk > dev_priv->max_cdclk_freq) {
> > >   drm_dbg_kms(&dev_priv->drm,
> > >   "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> >

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

2022-03-18 Thread Andi Shyti

Hi Matt and Tvrtko,

> On 18/03/2022 13:25, Matthew Auld wrote:
> > On Fri, 18 Mar 2022 at 08:18, Andi Shyti  wrote:
> > > 
> > > >• igt@i915_selftest@mock@requests:
> > > > 
> > > >□ shard-kbl: PASS -> DMESG-FAIL
> > > > 
> > > >□ shard-tglb: PASS -> DMESG-FAIL
> > > > 
> > > >□ shard-apl: PASS -> DMESG-FAIL
> > > > 
> > > >□ shard-glk: PASS -> DMESG-FAIL
> > > > 
> > > >□ shard-skl: PASS -> DMESG-FAIL
> > > > 
> > > >□ shard-snb: PASS -> DMESG-FAIL
> > > > 
> > > >□ shard-iclb: PASS -> DMESG-FAIL
> > > 
> > > I don't see how these failures can be related to the series I
> > > sent.
> > > 
> > > Maybe a false positive?
> > 
> > AFAICT these look new. Did we forget to do something for the
> > mock_device? Maybe something in patch 3? Nothing is jumping out at
> > me...

it was of course suspicious, but I spent quite a lot of time at
fixing the mock selftests, until I got all greens on trybot. But
then, another refactoring happened...

> Yeah to "sus" :)
> 
> [I like so don't recognise much of that patch I am supposed to be author 
> of... I think it moved on a lot since my version. Anyway.. onto the bug.]
> 
> Module init (executed in order):
> 
>   { .init = i915_mock_selftests }, -> this is the part which runs mock 
> selftests
> ...
>   { .init = i915_pci_register_driver, -> this is the part which sets up 
> i915->gt[0]
> 
> It happens via i915_pci_register_driver -> i915_pci_probe -> 
> i915_driver_probe -> intel_gt_probe_all.
> 
> Mock cleanup does:
> 
> mock_device_release
> 
> + intel_gt_driver_late_release(i915);
> 
>  ->
> 
> + for_each_gt(gt, i915, id) {
> + intel_uc_driver_late_release(>->uc);
> + intel_gt_fini_requests(gt);
> + intel_gt_fini_reset(gt);
> + intel_gt_fini_timelines(gt);
> + intel_engines_free(gt);
> + }
> 
> Hence I think for_each_gt does not see i915->gt[0] being set ergo does 
> nothing.

goot point, I'm missing a

i915->gt[0] = gt;

somewhere, that is supposed to happen in the probe_all. Thanks!

> I also don't like the signature changes like:
> 
> -void intel_gt_driver_late_release(struct intel_gt *gt)
> +void intel_gt_driver_late_release(struct drm_i915_private *i915)
> 
> If it has to live in intel_gt.c, maybe at least use the "_all" suffix more 
> consistently?

yes... not nice indeed. Also Michal complained. I will add the
"_all" suffix. Didn't want to make very long function names at
first.

Andi

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Lisovskiy, Stanislav

On Fri, Mar 18, 2022 at 02:27:53PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> > On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > > We are currently getting FIFO underruns, in particular
> > > when PSR2 is enabled. There seem to be no existing workaround
> > > or patches, which can fix that issue(were expecting some recent
> > > selective fetch update and DBuf bw/SAGV fixes to help,
> > > which unfortunately didn't).
> > > Current idea is that it looks like for some reason the
> > > DBuf prefill time isn't enough once we exit PSR2, despite its
> > > theoretically correct.
> > > So bump it up a bit by 15%(minimum experimental amount required
> > > to get it working), if PSR2 is enabled.
> > > For PSR1 there is no need in this hack, so we limit it only
> > > to PSR2 and Alderlake.
> > 
> > It this workaround meant to be permanent? If yes we should file a HSD and 
> > get hardware folks feedback.
> > 
> > > 
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
> > >  1 file changed, 13 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > index fda8b701..095b79950788 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> > > intel_crtc_state *crtc_state)
> > >   dev_priv->max_cdclk_freq));
> > >   }
> > >  
> > 
> > Please add some comment in the code about this workaround.
> > 
> > 
> > > + if (IS_ALDERLAKE_P(dev_priv)) {
> > > + struct intel_encoder *encoder;
> > > +
> > > + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > > +
> > > + if (intel_dp->psr.psr2_enabled) {
> > 
> > You should check the has_psr2 in the crtc_state, PSR2 could be disabled 
> > when this state is committed.
> 
> Ah and if a remember correctly those underruns only happens in a scenario 
> with 4 pipes enabled? or it also happens with 2 and 3 pipes?
> Anyways would be better to narrow down the cases where the workaround is 
> applied.
> So for at least in a case with a single pipe enabled we can have the lowest 
> cdclk as possible. 

I was thinking the same initially, but this underrun is observed in lesser pipe 
cases, when PSR2 
is enabled.

Stan

> 
> > 
> > > + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> > 
> > This is not increasing by 15%.
> > 
> > min_cdclk = 500
> > 500 * 100 = 5
> > 5 / 85 = 588.235294118
> > 
> > While 15% of 500 is 75.
> > 
> > Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> > 
> > > + break;
> > > + }
> > > + }
> > > + }
> > > +
> > >   if (min_cdclk > dev_priv->max_cdclk_freq) {
> > >   drm_dbg_kms(&dev_priv->drm,
> > >   "required cdclk (%d kHz) exceeds max (%d kHz)\n",
> > 
>

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Lisovskiy, Stanislav

On Fri, Mar 18, 2022 at 02:21:10PM +0200, Souza, Jose wrote:
> On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > We are currently getting FIFO underruns, in particular
> > when PSR2 is enabled. There seem to be no existing workaround
> > or patches, which can fix that issue(were expecting some recent
> > selective fetch update and DBuf bw/SAGV fixes to help,
> > which unfortunately didn't).
> > Current idea is that it looks like for some reason the
> > DBuf prefill time isn't enough once we exit PSR2, despite its
> > theoretically correct.
> > So bump it up a bit by 15%(minimum experimental amount required
> > to get it working), if PSR2 is enabled.
> > For PSR1 there is no need in this hack, so we limit it only
> > to PSR2 and Alderlake.
> 
> It this workaround meant to be permanent? If yes we should file a HSD and get 
> hardware folks feedback.

Nope, I hope we figure out some more elegant solution at some point.

> 
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index fda8b701..095b79950788 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> > intel_crtc_state *crtc_state)
> > dev_priv->max_cdclk_freq));
> > }
> >  
> 
> Please add some comment in the code about this workaround.
> 
> 
> > +   if (IS_ALDERLAKE_P(dev_priv)) {
> > +   struct intel_encoder *encoder;
> > +
> > +   for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > +   if (intel_dp->psr.psr2_enabled) {
> 
> You should check the has_psr2 in the crtc_state, PSR2 could be disabled when 
> this state is committed.
> 
> > +   min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> 
> This is not increasing by 15%.
> 
> min_cdclk = 500
> 500 * 100 = 5
> 5 / 85 = 588.235294118
> 
> While 15% of 500 is 75.
> 
> Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> 
> > +   break;

No, we won't bump up it twice, because we initialize min_cdclk here from pixel 
rate initially
and only then apply all those dirty hacks and optimizations. There is similar 
code above as
well.
For each crtc we call this function but as starting point always its pixel rate 
is used,
then the max() of those would be the actual new cdclk.

As for 15%, good point took this from expression above in that func, but indeed 
this is 
no a 15%.

Stan

> > +   }
> > +   }
> > +   }
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>

Re: [Intel-gfx] [PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface

2022-03-18 Thread Andi Shyti

On Fri, Mar 18, 2022 at 01:19:18PM +, Matthew Auld wrote:
> On 18/03/2022 02:10, Andi Shyti wrote:
> > Now that we have tiles we want each of them to have its own
> > interface. A directory "gt/" is created under "cardN/" that will
> > contain as many diroctories as the tiles.
> > 
> > In the coming patches tile related interfaces will be added. For
> > now the sysfs gt structure simply has an id interface related
> > to the current tile count.
> > 
> > The directory structure will follow this scheme:
> > 
> >  /sys/.../card0
> >   └── gt
> >   ├── gt0
> >   │   └── id
> >   :
> >  :
> >  └─- gtN
> >       └── id
> > 
> > This new set of interfaces will be a basic tool for system
> > managers and administrators when using i915.
> > 
> > Signed-off-by: Andi Shyti 
> > Cc: Matt Roper 
> > Cc: Sujaritha Sundaresan 
> > Cc: Tvrtko Ursulin 
> > Reviewed-by: Sujaritha Sundaresan 
> > ---
> >   drivers/gpu/drm/i915/Makefile|   1 +
> >   drivers/gpu/drm/i915/gt/intel_gt.c   |   2 +
> >   drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
> >   drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  34 
> >   drivers/gpu/drm/i915/i915_drv.h  |   2 +
> >   drivers/gpu/drm/i915/i915_sysfs.c|   7 +-
> >   drivers/gpu/drm/i915/i915_sysfs.h|   3 +
> >   scripts/extract-cert | Bin 0 -> 17952 bytes
> 
> What is extract-cert?

it's the result of a "git add ." ... thanks, I did not notice it.

Andi

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

2022-03-18 Thread Tvrtko Ursulin




On 18/03/2022 13:25, Matthew Auld wrote:

On Fri, 18 Mar 2022 at 08:18, Andi Shyti  wrote:



   • igt@i915_selftest@mock@requests:

   □ shard-kbl: PASS -> DMESG-FAIL

   □ shard-tglb: PASS -> DMESG-FAIL

   □ shard-apl: PASS -> DMESG-FAIL

   □ shard-glk: PASS -> DMESG-FAIL

   □ shard-skl: PASS -> DMESG-FAIL

   □ shard-snb: PASS -> DMESG-FAIL

   □ shard-iclb: PASS -> DMESG-FAIL


I don't see how these failures can be related to the series I
sent.

Maybe a false positive?


AFAICT these look new. Did we forget to do something for the
mock_device? Maybe something in patch 3? Nothing is jumping out at
me...


Yeah to "sus" :)

[I like so don't recognise much of that patch I am supposed to be author of... 
I think it moved on a lot since my version. Anyway.. onto the bug.]

Module init (executed in order):

{ .init = i915_mock_selftests }, -> this is the part which runs mock 
selftests
...
{ .init = i915_pci_register_driver, -> this is the part which sets up 
i915->gt[0]

It happens via i915_pci_register_driver -> i915_pci_probe -> i915_driver_probe 
-> intel_gt_probe_all.

Mock cleanup does:

mock_device_release

+   intel_gt_driver_late_release(i915);

 ->

+   for_each_gt(gt, i915, id) {
+   intel_uc_driver_late_release(>->uc);
+   intel_gt_fini_requests(gt);
+   intel_gt_fini_reset(gt);
+   intel_gt_fini_timelines(gt);
+   intel_engines_free(gt);
+   }

Hence I think for_each_gt does not see i915->gt[0] being set ergo does nothing.

I also don't like the signature changes like:

-void intel_gt_driver_late_release(struct intel_gt *gt)
+void intel_gt_driver_late_release(struct drm_i915_private *i915)

If it has to live in intel_gt.c, maybe at least use the "_all" suffix more 
consistently?

Regards,

Tvrtko

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce multitile support

2022-03-18 Thread Matthew Auld

On Fri, 18 Mar 2022 at 08:18, Andi Shyti  wrote:
>
> >   • igt@i915_selftest@mock@requests:
> >
> >   □ shard-kbl: PASS -> DMESG-FAIL
> >
> >   □ shard-tglb: PASS -> DMESG-FAIL
> >
> >   □ shard-apl: PASS -> DMESG-FAIL
> >
> >   □ shard-glk: PASS -> DMESG-FAIL
> >
> >   □ shard-skl: PASS -> DMESG-FAIL
> >
> >   □ shard-snb: PASS -> DMESG-FAIL
> >
> >   □ shard-iclb: PASS -> DMESG-FAIL
>
> I don't see how these failures can be related to the series I
> sent.
>
> Maybe a false positive?

AFAICT these look new. Did we forget to do something for the
mock_device? Maybe something in patch 3? Nothing is jumping out at
me...

>
> Andi

Re: [Intel-gfx] [PATCH v6 4/7] drm/i915/gt: create per-tile sysfs interface

2022-03-18 Thread Matthew Auld


On 18/03/2022 02:10, Andi Shyti wrote:

Now that we have tiles we want each of them to have its own
interface. A directory "gt/" is created under "cardN/" that will
contain as many diroctories as the tiles.

In the coming patches tile related interfaces will be added. For
now the sysfs gt structure simply has an id interface related
to the current tile count.

The directory structure will follow this scheme:

 /sys/.../card0
  └── gt
      ├── gt0
      │   └── id
  :
 :
 └─- gtN
          └── id

This new set of interfaces will be a basic tool for system
managers and administrators when using i915.

Signed-off-by: Andi Shyti 
Cc: Matt Roper 
Cc: Sujaritha Sundaresan 
Cc: Tvrtko Ursulin 
Reviewed-by: Sujaritha Sundaresan 
---
  drivers/gpu/drm/i915/Makefile|   1 +
  drivers/gpu/drm/i915/gt/intel_gt.c   |   2 +
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 103 +++
  drivers/gpu/drm/i915/gt/intel_gt_sysfs.h |  34 
  drivers/gpu/drm/i915/i915_drv.h  |   2 +
  drivers/gpu/drm/i915/i915_sysfs.c|   7 +-
  drivers/gpu/drm/i915/i915_sysfs.h|   3 +
  scripts/extract-cert | Bin 0 -> 17952 bytes


What is extract-cert?

Re: [Intel-gfx] [PATCH v6 7/7] drm/i915/gt: Adding new sysfs frequency attributes

2022-03-18 Thread Andrzej Hajda


On 18.03.2022 03:10, Andi Shyti wrote:

From: Sujaritha Sundaresan 

This patch adds the following new sysfs frequency attributes:

- punit_req_freq_mhz
- throttle_reason_status
- throttle_reason_pl1
- throttle_reason_pl2
- throttle_reason_pl4
- throttle_reason_thermal
- throttle_reason_prochot
- throttle_reason_ratl
- throttle_reason_vr_thermalert
- throttle_reason_vr_tdc

Signed-off-by: Sujaritha Sundaresan 
Cc: Dale B Stimson 
Signed-off-by: Andi Shyti 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

Re: [Intel-gfx] [PATCH v6 3/7] drm/i915: Prepare for multiple GTs

2022-03-18 Thread Andrzej Hajda


On 18.03.2022 03:10, Andi Shyti wrote:

From: Tvrtko Ursulin 

On a multi-tile platform, each tile has its own registers + GGTT
space, and BAR 0 is extended to cover all of them.

Up to four GTs are supported in i915->gt[], with slot zero
shadowing the existing i915->gt0 to enable source compatibility
with legacy driver paths. A for_each_gt macro is added to iterate
over the GTs and will be used by upcoming patches that convert
various parts of the driver to be multi-gt aware.

Only the primary/root tile is initialized for now; the other
tiles will be detected and plugged in by future patches once the
necessary infrastructure is in place to handle them.

Signed-off-by: Abdiel Janulgue 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Matt Roper 
Signed-off-by: Andi Shyti 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
Reviewed-by: Matt Roper 
---


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Patchwork

== Series Details ==

Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
URL   : https://patchwork.freedesktop.org/series/101533/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11380_full -> Patchwork_22612_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Participating hosts (12 -> 10)
--

  Missing(2): shard-rkl shard-tglu 

Known issues


  Here are the changes found in Patchwork_22612_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][1] -> [TIMEOUT][2] ([i915#3063]) +2 similar 
issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-tglb2/igt@gem_...@in-flight-contexts-10ms.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-tglb6/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#2481] / [i915#3070])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb5/igt@gem_...@unwedge-stress.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb4/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb7/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
- shard-apl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_exec_params@no-vebox:
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271]) +107 similar 
issues
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-skl4/igt@gem_exec_par...@no-vebox.html

  * igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#644])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk9/igt@gem_pp...@flink-and-close-vma-leak.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk5/igt@gem_pp...@flink-and-close-vma-leak.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4270])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_...@create-valid-protected-context.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#768]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_softpin@allocator-evict-all-engines:
- shard-glk:  [PASS][21] -> [FAIL][22] ([i915#4171])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-glk1/igt@gem_soft...@allocator-evict-all-engines.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-glk5/igt@gem_soft...@allocator-evict-all-engines.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][23] ([fdo#109290])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/shard-iclb6/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP]

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Souza, Jose

On Fri, 2022-03-18 at 05:22 -0700, José Roberto de Souza wrote:
> On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> > We are currently getting FIFO underruns, in particular
> > when PSR2 is enabled. There seem to be no existing workaround
> > or patches, which can fix that issue(were expecting some recent
> > selective fetch update and DBuf bw/SAGV fixes to help,
> > which unfortunately didn't).
> > Current idea is that it looks like for some reason the
> > DBuf prefill time isn't enough once we exit PSR2, despite its
> > theoretically correct.
> > So bump it up a bit by 15%(minimum experimental amount required
> > to get it working), if PSR2 is enabled.
> > For PSR1 there is no need in this hack, so we limit it only
> > to PSR2 and Alderlake.
> 
> It this workaround meant to be permanent? If yes we should file a HSD and get 
> hardware folks feedback.
> 
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index fda8b701..095b79950788 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> > intel_crtc_state *crtc_state)
> > dev_priv->max_cdclk_freq));
> > }
> >  
> 
> Please add some comment in the code about this workaround.
> 
> 
> > +   if (IS_ALDERLAKE_P(dev_priv)) {
> > +   struct intel_encoder *encoder;
> > +
> > +   for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> > +   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > +
> > +   if (intel_dp->psr.psr2_enabled) {
> 
> You should check the has_psr2 in the crtc_state, PSR2 could be disabled when 
> this state is committed.

Ah and if a remember correctly those underruns only happens in a scenario with 
4 pipes enabled? or it also happens with 2 and 3 pipes?
Anyways would be better to narrow down the cases where the workaround is 
applied.
So for at least in a case with a single pipe enabled we can have the lowest 
cdclk as possible. 

> 
> > +   min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
> 
> This is not increasing by 15%.
> 
> min_cdclk = 500
> 500 * 100 = 5
> 5 / 85 = 588.235294118
> 
> While 15% of 500 is 75.
> 
> Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.
> 
> > +   break;
> > +   }
> > +   }
> > +   }
> > +
> > if (min_cdclk > dev_priv->max_cdclk_freq) {
> > drm_dbg_kms(&dev_priv->drm,
> > "required cdclk (%d kHz) exceeds max (%d kHz)\n",
>

Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Souza, Jose

On Fri, 2022-03-18 at 10:52 +0200, Stanislav Lisovskiy wrote:
> We are currently getting FIFO underruns, in particular
> when PSR2 is enabled. There seem to be no existing workaround
> or patches, which can fix that issue(were expecting some recent
> selective fetch update and DBuf bw/SAGV fixes to help,
> which unfortunately didn't).
> Current idea is that it looks like for some reason the
> DBuf prefill time isn't enough once we exit PSR2, despite its
> theoretically correct.
> So bump it up a bit by 15%(minimum experimental amount required
> to get it working), if PSR2 is enabled.
> For PSR1 there is no need in this hack, so we limit it only
> to PSR2 and Alderlake.

It this workaround meant to be permanent? If yes we should file a HSD and get 
hardware folks feedback.

> 
> Signed-off-by: Stanislav Lisovskiy 
> ---
>  drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index fda8b701..095b79950788 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
> intel_crtc_state *crtc_state)
>   dev_priv->max_cdclk_freq));
>   }
>  

Please add some comment in the code about this workaround.


> + if (IS_ALDERLAKE_P(dev_priv)) {
> + struct intel_encoder *encoder;
> +
> + for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (intel_dp->psr.psr2_enabled) {

You should check the has_psr2 in the crtc_state, PSR2 could be disabled when 
this state is committed.

> + min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);

This is not increasing by 15%.

min_cdclk = 500
500 * 100 = 5
5 / 85 = 588.235294118

While 15% of 500 is 75.

Also if there is two CRTCs with PSR2 enabled you will bump min_cdclk twice.

> + break;
> + }
> + }
> + }
> +
>   if (min_cdclk > dev_priv->max_cdclk_freq) {
>   drm_dbg_kms(&dev_priv->drm,
>   "required cdclk (%d kHz) exceeds max (%d kHz)\n",

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Patchwork

== Series Details ==

Series: drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used
URL   : https://patchwork.freedesktop.org/series/101533/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11380 -> Patchwork_22612


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/index.html

Participating hosts (48 -> 45)
--

  Additional (2): bat-jsl-2 fi-pnv-d510 
  Missing(5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22612:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@coherency:
- {bat-rpls-2}:   [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_selftest@l...@coherency.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/bat-rpls-2/igt@i915_selftest@l...@coherency.html

  
Known issues


  Here are the changes found in Patchwork_22612 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][3] ([fdo#109271]) +57 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][4] -> [DMESG-FAIL][5] ([i915#4494] / 
[i915#4957])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-c:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#5341])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/fi-pnv-d510/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-c.html

  
 Possible fixes 

  * igt@i915_selftest@live@objects:
- {bat-rpls-2}:   [DMESG-WARN][7] ([i915#4391]) -> [PASS][8] +2 similar 
issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_selftest@l...@objects.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22612/bat-rpls-2/igt@i915_selftest@l...@objects.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5339]: https://gitlab.freedesktop.org/drm/intel/issues/5339
  [i915#5341]: https://gitlab.freedesktop.org/drm/intel/issues/5341
  [i915#5342]: https://gitlab.freedesktop.org/drm/intel/issues/5342


Build changes
-

  * Linux: CI_DRM_11380 -> Patchwork_22612

  CI-20190529: 20190529
  CI_DRM_11380: fe83949cd4316608ea785fc376b6ed444224adad @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6385: f3df40281d93d5a63ee98fa30e90852d780673c9 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_22612: fc7505c5f9a40dbbf242c8c37d63b972eddfbc46 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux comm

[Intel-gfx] ✗ Fi.CI.IGT: failure for Separate panel orientation property creating and value setting

2022-03-18 Thread Patchwork

== Series Details ==

Series: Separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/101530/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11380_full -> Patchwork_22608_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22608_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22608_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22608_full:

### IGT changes ###

 Possible regressions 

  * igt@gem_userptr_blits@huge-split:
- shard-apl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl2/igt@gem_userptr_bl...@huge-split.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-apl8/igt@gem_userptr_bl...@huge-split.html

  
Known issues


  Here are the changes found in Patchwork_22608_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_eio@in-flight-contexts-1us:
- shard-iclb: [PASS][3] -> [TIMEOUT][4] ([i915#3070])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb5/igt@gem_...@in-flight-contexts-1us.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb7/igt@gem_...@in-flight-contexts-1us.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-kbl:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-kbl1/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-apl2/igt@gem_lmem_swapp...@heavy-verify-random.html
- shard-iclb: NOTRUN -> [SKIP][10] ([i915#4613])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb8/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-skl:  NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-skl9/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#4270])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb6/igt@gem_...@create-valid-protected-context.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][13] ([i915#768]) +2 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb6/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109290])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb6/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#3323])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb6/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-skl:  NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-skl4/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gen3_render_linear_blits:
- shard-tglb: NOTRUN -> [SKIP][17] ([fdo#109289])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-tglb8/igt@gen3_render_linear_blits.html

  * igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#658]) +1 
similar issue
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-skl4/igt@i915_pm...@dc3co-vpb-simulation.html
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#658])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/shard-iclb6/igt@i915_pm...@dc3co-vpb-simulation.html

  * igt@i915_pm_dc@dc6-dpms:
- shard-skl:  NOTRUN -> [FAIL][

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add DSC support to MST path

2022-03-18 Thread Lisovskiy, Stanislav

On Thu, Mar 17, 2022 at 06:52:28PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2022 at 06:33:53PM +0200, Stanislav Lisovskiy wrote:
> > Whenever we are not able to get enough timeslots
> > for required PBN, let's try to allocate those
> > using DSC, just same way as we do for SST.
> > 
> > Those patches are experimental yet, i.e not
> > for merging, still need to be tested with
> > proper DSC display, submitting those to check
> > ig nothing else blows up at least.
> > 
> > v2: Add DSC checks to intel_dp_mst_mode_valid_ctx, similar
> > to ones we have in intel_dp_mode_valid(Manasi Navare)
> > 
> > v3: Removed redundant edp condition logic from MST DSC
> > handling(Manasi Navare)
> > 
> > v4:  - Fixed forgotten force_dsc_en condition which was
> >always enabled for testing purposes(Manasi Navare)
> >  - Properly process ret == EDEADLK, thus fixing the
> >regression caused by WARN triggered with modeset_lock.
> > 
> > v5:  - Removed redundant check(Imre Deak)
> > 
> > Acked-by: Imre Deak 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 138 --
> >  drivers/gpu/drm/i915/display/intel_dp.h |  17 +++
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c | 146 +++-
> >  3 files changed, 285 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 9e19165fd175..b04771e495cc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -115,7 +115,6 @@ bool intel_dp_is_edp(struct intel_dp *intel_dp)
> >  }
> >  
> >  static void intel_dp_unset_edid(struct intel_dp *intel_dp);
> > -static int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 
> > dsc_max_bpc);
> >  
> >  /* Is link rate UHBR and thus 128b/132b? */
> >  bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
> > @@ -667,11 +666,12 @@ small_joiner_ram_size_bits(struct drm_i915_private 
> > *i915)
> > return 6144 * 8;
> >  }
> >  
> > -static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > -  u32 link_clock, u32 lane_count,
> > -  u32 mode_clock, u32 mode_hdisplay,
> > -  bool bigjoiner,
> > -  u32 pipe_bpp)
> > +u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *i915,
> > +   u32 link_clock, u32 lane_count,
> > +   u32 mode_clock, u32 mode_hdisplay,
> > +   bool bigjoiner,
> > +   u32 pipe_bpp,
> > +   u32 timeslots)
> >  {
> > u32 bits_per_pixel, max_bpp_small_joiner_ram;
> > int i;
> > @@ -683,7 +683,7 @@ static u16 intel_dp_dsc_get_output_bpp(struct 
> > drm_i915_private *i915,
> >  * for MST -> TimeSlotsPerMTP has to be calculated
> >  */
> > bits_per_pixel = (link_clock * lane_count * 8) /
> > -intel_dp_mode_to_fec_clock(mode_clock);
> > +(intel_dp_mode_to_fec_clock(mode_clock) * timeslots);
> > drm_dbg_kms(&i915->drm, "Max link bpp: %u\n", bits_per_pixel);
> >  
> > /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
> > @@ -737,9 +737,9 @@ static u16 intel_dp_dsc_get_output_bpp(struct 
> > drm_i915_private *i915,
> > return bits_per_pixel << 4;
> >  }
> >  
> > -static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > -  int mode_clock, int mode_hdisplay,
> > -  bool bigjoiner)
> > +u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
> > +   int mode_clock, int mode_hdisplay,
> > +   bool bigjoiner)
> >  {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 min_slice_count, i;
> > @@ -902,8 +902,8 @@ intel_dp_mode_valid_downstream(struct intel_connector 
> > *connector,
> > return MODE_OK;
> >  }
> >  
> > -static bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > -   int hdisplay, int clock)
> > +bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
> > +int hdisplay, int clock)
> >  {
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >  
> > @@ -990,7 +990,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
> > target_clock,
> > mode->hdisplay,
> > bigjoiner,
> > -   pipe_bpp) >> 4;
> > +   pipe_bpp, 1) >> 4;
> > dsc_slice_count =
> > intel_dp_dsc_get_slice

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Fix renamed struct field (rev2)

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field (rev2)
URL   : https://patchwork.freedesktop.org/series/101448/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11380 -> Patchwork_22611


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22611 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22611, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/index.html

Participating hosts (48 -> 45)
--

  Additional (2): bat-adlm-1 bat-jsl-2 
  Missing(5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22611:

### IGT changes ###

 Possible regressions 

  * igt@i915_selftest@live@gem_contexts:
- fi-glk-dsi: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/fi-glk-dsi/igt@i915_selftest@live@gem_contexts.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/fi-glk-dsi/igt@i915_selftest@live@gem_contexts.html

  
 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_frontbuffer_tracking@basic:
- {bat-dg2-9}:[FAIL][3] ([i915#5276]) -> [DMESG-FAIL][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg2-9/igt@kms_frontbuffer_track...@basic.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-dg2-9/igt@kms_frontbuffer_track...@basic.html

  * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- {bat-adlm-1}:   NOTRUN -> [INCOMPLETE][5]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-adlm-1/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html

  
Known issues


  Here are the changes found in Patchwork_22611 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u:   [PASS][6] -> [INCOMPLETE][7] ([i915#146])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html

  * igt@i915_module_load@reload:
- fi-kbl-soraka:  [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/fi-kbl-soraka/igt@i915_module_l...@reload.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/fi-kbl-soraka/igt@i915_module_l...@reload.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][10] -> [DMESG-FAIL][11] ([i915#4494] / 
[i915#4957])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html

  
 Possible fixes 

  * igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}:   [DMESG-WARN][12] ([i915#4391]) -> [PASS][13] +1 
similar issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_pm_...@module-reload.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-rpls-2/igt@i915_pm_...@module-reload.html

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-5:  [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) -> 
[PASS][15]
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22611/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop

Re: [Intel-gfx] [PATCH 2/2] drm/doc: add rfc section for small BAR uapi

2022-03-18 Thread Matthew Auld


On 18/03/2022 09:38, Lionel Landwerlin wrote:

Hey Matthew, all,

This sounds like a good thing to have.
There are a number of DG2 machines where we have a small BAR and this is 
causing more apps to fail.


Anv currently reports 3 memory heaps to the app :

     - local device only (not host visible) -> mapped to lmem
     - device/cpu -> mapped to smem
     - local device but also host visible -> mapped to lmem

So we could use this straight away, by just not putting the 
I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS flag on the allocation of the 
first heap.


One thing I don't see in this proposal is how can we get the size of the 
2 lmem heap : cpu visible, cpu not visible

We could use that to report the appropriate size to the app.
We probably want to report a new drm_i915_memory_region_info and either :
     - put one of the reserve field to use to indicate : cpu visible
     - or define a new enum value in drm_i915_gem_memory_class


Thanks for taking a look at this. Returning the probed CPU visible size 
as part of the region query seems reasonable. Something like:


@@ -3074,8 +3074,18 @@ struct drm_i915_memory_region_info {
/** @unallocated_size: Estimate of memory remaining (-1 = 
unknown) */

__u64 unallocated_size;

-   /** @rsvd1: MBZ */
-   __u64 rsvd1[8];
+   union {
+   /** @rsvd1: MBZ */
+   __u64 rsvd1[8];
+
+   struct {
+   /**
+* @probed_cpu_visible_size: Memory probed by 
the driver

+* that is CPU accessible. (-1 = unknown)
+*/
+   __u64 probed_cpu_visible_size;
+   };
+   };


I will add this in the next version, if no objections.



Cheers,

-Lionel


On 18/02/2022 13:22, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 153 +++
  Documentation/gpu/rfc/i915_small_bar.rst |  40 ++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 197 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h

new file mode 100644
index ..fa65835fd608
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,153 @@
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, 
with added

+ * extension support using struct i915_user_extension.
+ *
+ * Note that in the future we want to have our buffer flags here, at 
least for
+ * the stuff that is immutable. Previously we would have two ioctls, 
one to
+ * create the object with gem_create, and another to apply various 
parameters,
+ * however this creates some ambiguity for the params which are 
considered
+ * immutable. Also in general we're phasing out the various SET/GET 
ioctls.

+ */
+struct __drm_i915_gem_create_ext {
+    /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be 
returned.

+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), like for device 
local-memory.

+ * However in general the final size here should always reflect any
+ * rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS

+ * extension to place the object in device local-memory.
+ */
+    __u64 size;
+    /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+    __u32 handle;
+    /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the 
kernel that

+ * the object will need to be accessed via the CPU.
+ *
+ * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+ * only strictly required on platforms where only some of the device
+ * memory is directly visible or mappable through the CPU, like 
on DG2+.

+ *
+ * One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+ * ensure we can always spill the allocation to system memory, if we
+ * can't place the object in the mappable part of
+ * I915_MEMORY_CLASS_DEVICE.
+ *
+ * Note that buffers that need to be captured with 
EXEC_OBJECT_CAPTURE,
+ * will need to enable this hint, if the object can also be 
placed in
+ * I915_MEMORY_CLASS_DEVICE, starting from DG2+. The execbuf call 
will
+ * throw an error otherwise. This also means that such objects 
will need

+ * I915_MEMORY_CLASS_SYSTEM set as a possible placement.
+ *
+ * Without this hi

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Fix renamed struct field (rev2)

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field (rev2)
URL   : https://patchwork.freedesktop.org/series/101448/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Fix renamed struct field (rev2)

2022-03-18 Thread Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Fix renamed struct field (rev2)
URL   : https://patchwork.freedesktop.org/series/101448/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b789e48254b8 drm/i915: Fix renamed struct field
-:28: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible 
side-effects?
#28: FILE: drivers/gpu/drm/i915/i915_drv.h:925:
+#define MEDIA_VER_FULL(i915)   IP_VER(INTEL_INFO(i915)->media.ver, \
   INTEL_INFO(i915)->media.rel)

total: 0 errors, 0 warnings, 1 checks, 8 lines checked
8fb7ef4924d8 drm/i915: Add logical mapping for video decode engines

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Async flip optimization for DG2 (rev10)

2022-03-18 Thread Patchwork

== Series Details ==

Series: Async flip optimization for DG2 (rev10)
URL   : https://patchwork.freedesktop.org/series/98981/
State : failure

== Summary ==

Applying: drm/i915: Pass plane to watermark calculation functions
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_atomic_plane.h
M   drivers/gpu/drm/i915/intel_pm.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_pm.c
Auto-merging drivers/gpu/drm/i915/display/intel_atomic_plane.h
No changes -- Patch already applied.
Applying: drm/i915: Introduce do_async_flip flag to intel_plane_state
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_atomic_plane.c
M   drivers/gpu/drm/i915/display/intel_display.c
M   drivers/gpu/drm/i915/display/intel_display_types.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_display_types.h
Auto-merging drivers/gpu/drm/i915/display/intel_display.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_display.c
Auto-merging drivers/gpu/drm/i915/display/intel_atomic_plane.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_atomic_plane.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 drm/i915: Introduce do_async_flip flag to intel_plane_state
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Async flip optimization for DG2 (rev10)

2022-03-18 Thread Patchwork

== Series Details ==

Series: Async flip optimization for DG2 (rev10)
URL   : https://patchwork.freedesktop.org/series/98981/
State : failure

== Summary ==

Applying: drm/i915: Pass plane to watermark calculation functions
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_atomic_plane.h
M   drivers/gpu/drm/i915/intel_pm.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_pm.c
Auto-merging drivers/gpu/drm/i915/display/intel_atomic_plane.h
No changes -- Patch already applied.
Applying: drm/i915: Introduce do_async_flip flag to intel_plane_state
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/display/intel_atomic_plane.c
M   drivers/gpu/drm/i915/display/intel_display.c
M   drivers/gpu/drm/i915/display/intel_display_types.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/display/intel_display_types.h
Auto-merging drivers/gpu/drm/i915/display/intel_display.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_display.c
Auto-merging drivers/gpu/drm/i915/display/intel_atomic_plane.c
CONFLICT (content): Merge conflict in 
drivers/gpu/drm/i915/display/intel_atomic_plane.c
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0002 drm/i915: Introduce do_async_flip flag to intel_plane_state
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Re: [Intel-gfx] Small bar recovery vs compressed content on DG2

2022-03-18 Thread Thomas Hellström

Hi,

On Thu, 2022-03-17 at 18:21 +, Bloomfield, Jon wrote:
> +@Vetter, Daniel
> 
> Let's not start re-inventing this on the fly again. That's how we got
> into trouble in the past. The SAS/Whitepaper does currently require
> the SMEM+LMEM placement for mappable, for good reasons.

Just to avoid any misunderstandings here:

We have two hard requirements from Arch that clash, main problem is
compressed bos can't be captured on error with current designs.

>From an engineering point of view we can do little more than list
options available to resolve this and whether they are hard or not so
hard to implemement. But IMHO Arch needs to agree on what's got to
give.

Thanks,
Thomas


> 
> We cannot 'always migrate to mappable in the fault handler'. Or at
> least, this is not as trivial as it is to write in a sentence due to
> the need to spill out other active objects, and all the usual
> challenges with context synchronization etc. It is possible, perhaps
> with a lot of care, but it is challenging to guarantee, easy to
> break, and not needed for 99.9% of software. We are trying to
> simplify our driver stack.
> 
> If we need a special mechanism for debug, we should devise a special
> mechanism, not throw out the general LMEM+SMEM requirement. Are there
> any identified first-class clients that require such access, or is it
> only debugging tools?
> 
> If only debug, then why can't the tool use a copy engine submission
> to access the data in place? Or perhaps a bespoke ioctl to access
> this via the KMD (and kmd submitted copy-engine BB)?
> 
> Thanks,
> 
> Jon
> 
> > -Original Message-
> > From: Thomas Hellström 
> > Sent: Thursday, March 17, 2022 2:35 AM
> > To: Joonas Lahtinen ; Bloomfield,
> > Jon
> > ; Intel Graphics Development  > g...@lists.freedesktop.org>; Auld, Matthew ;
> > C,
> > Ramalingam 
> > Subject: Re: Small bar recovery vs compressed content on DG2
> > 
> > On Thu, 2022-03-17 at 10:43 +0200, Joonas Lahtinen wrote:
> > > Quoting Thomas Hellström (2022-03-16 09:25:16)
> > > > Hi!
> > > > 
> > > > Do we somehow need to clarify in the headers the semantics for
> > > > this?
> > > > 
> > > >  From my understanding when discussing the CCS migration series
> > > > with
> > > > Ram, the kernel will never do any resolving (compressing /
> > > > decompressing) migrations or evictions which basically implies
> > > > the
> > > > following:
> > > > 
> > > > *) Compressed data must have LMEM only placement, otherwise the
> > GPU
> > > > would read garbage if accessing from SMEM.
> > > 
> > > This has always been the case, so it should be documented in the
> > > uAPI
> > > headers and kerneldocs.
> > > 
> > > > *) Compressed data can't be assumed to be mappable by the CPU,
> > > > because
> > > > in order to ensure that on small BAR, the placement needs to be
> > > > LMEM+SMEM.
> > > 
> > > Not strictly true, as we could always migrate to the mappable
> > > region
> > > in
> > > the CPU fault handler. Will need the same set of tricks as with
> > > limited
> > > mappable GGTT in past.
> > 
> > In addition to Matt's reply:
> > 
> > Yes, if there is sufficient space. I'm not sure we want to
> > complicate
> > this to migrate only part of the buffer to mappable on a fault
> > basis?
> > Otherwise this is likely to fail.
> > 
> > One option is to allow cpu-mapping from SYSTEM like TTM is doing
> > for
> > evicted buffers, even if SYSTEM is not in the placement list, and
> > then
> > migrate back to LMEM for gpu access.
> > 
> > But can user-space even interpret the compressed data when CPU-
> > mapping?
> > without access to the CCS metadata?
> > 
> > > 
> > > > *) Neither can compressed data be part of a CAPTURE buffer,
> > > > because
> > > > that
> > > > requires the data to be CPU-mappable.
> > > 
> > > Especially this will be too big of a limitation which we can't
> > > really
> > > afford
> > > when it comes to debugging.
> > 
> > Same here WRT user-space interpretation.
> > 
> > This will become especially tricky on small BAR, because either we
> > need
> > to fit all compressed buffers in the mappable portion, or be able
> > to
> > blit the contents of the capture buffers from within the fence
> > signalling critical section, which will require a lot of work I
> > guess.
> > 
> > /Thomas
> > 
> > 
> > > 
> > > Regards, Joonas
> > > 
> > > > Are we (and user-mode drivers) OK with these restrictions, or
> > > > do we
> > > > need
> > > > to rethink?
> > > > 
> > > > Thanks,
> > > > 
> > > > Thomas
> > > > 
> > > > 
> > 
>

Re: [Intel-gfx] [PATCH 02/11] drm/i915/bios: Make copies of VBT data blocks

2022-03-18 Thread Jani Nikula

On Fri, 18 Mar 2022, Ville Syrjälä  wrote:
> On Thu, Mar 17, 2022 at 09:02:46PM +0200, Jani Nikula wrote:
>> On Thu, 17 Mar 2022, Ville Syrjala  wrote:
>> > From: Ville Syrjälä 
>> >
>> > Make a copy of each VB data block with a guaranteed minimum
>> > size. The extra (if any) will just be left zeroed.
>> 
>> *VBT
>> 
>> >
>> > This means we don't have to worry about going out of bounds
>> > when accessing any of the structure members. Otherwise that
>> > could easliy happen if we simply get the version check wrong,
>> > or if the VBT is broken/malicious.
>> 
>> *easily
>> 
>> >
>> > Signed-off-by: Ville Syrjälä 
>> 
>> The high level question is if we really want to save the copies until
>> driver remove instead of just during parsing. The lifetime should be
>> mentioned in the commit message, with rationale if you have some.
>
> Sure, I'll amend the commit msg a bit.
>
> I think we at least must move away from the "parse VBT once at
> driver init" idea because that won't ever let us deal with the
> panel_type=0xff->check PnP ID thing. I think I even have a few
> real world VBTs in my stash which have panel_type=0xff, so it's
> not just some theoretical thing.
>
> So we must hang onto the blocks at least until we've finished the
> output setup. But I'm thinking we can just keep them permanently
> and even start thinking about moving away from the "parse once,
> stash results somewhere" mentality. Ie. we could just parse on
> demand instead.

That pretty much aligns with what my direction has been with the child
devices. So gradually start throwing away stuff from i915->vbt, and
instead have some accessors on the opaque list of bdb block entries. I
guess it's going to be a lot of functions, but at least their names can
be self-documenting and they can handle the VBT version differences
cleanly.

>
>> I was wondering about making the copies up front instead of as needed,
>> but that means setting up a list for the min sizes. It would clean up
>> the usage (avoids passing around any pointers to original data to the
>> parsers). Then you could use just find_section(i915, BDB_XXX). Dunno.
>
> At least if we go for the parse on demand apporach then we definitely
> want to do that. Avoids having to deal with kmalloc() fails/etc. while
> parsing.

Agreed.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH v1] drm/i915/gem: Don't evict unmappable VMAs when pinning with PIN_MAPPABLE

2022-03-18 Thread Tvrtko Ursulin




On 18/03/2022 07:39, Kasireddy, Vivek wrote:

Hi Tvrtko,



On 17/03/2022 07:23, Vivek Kasireddy wrote:

On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.

This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced -- because there is no space for it in the aperture --
and therefore i915_vma_unbind() is called which unbinds and evicts it.
This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This whole
thing results in a latency of ~10ms and happens every other repaint cycle.


Just out of curiosity - have you looked at where does this 10ms come
from? Like is it simply clearing/writing PTEs so expensive, or there is
more to it? Apologies if I asked this before..

[Kasireddy, Vivek] It appears the ~10ms latency seems to come from the
execution of gen8_ggtt_clear_range() as seen in the trace log:
   weston-4124  [008] 161210.397563: funcgraph_entry:   
|  __i915_vma_evict() {
   weston-4124  [008] 161210.397564: funcgraph_entry:   
|ggtt_unbind_vma() {
   weston-4124  [008] 161210.397564: funcgraph_entry:   
|  gen8_ggtt_clear_range() {
   weston-4124  [008] 161210.408012: funcgraph_exit:   # 10416.281 
us |  }
   weston-4124  [008] 161210.408012: funcgraph_exit:   # 10448.740 
us |}
   weston-4124  [008] 161210.408012: funcgraph_entry:   
|__vma_put_pages() {
   weston-4124  [008] 161210.408013: funcgraph_entry:0.083 us   
|  clear_pages();
   weston-4124  [008] 161210.408013: funcgraph_exit: 0.578 us   
|}
   weston-4124  [008] 161210.408013: funcgraph_exit:   # 10449.622 
us |  }

And, for some reason, I can't get trace-cmd to capture more symbols to
gain more insights. However, gen8_ggtt_clear_range() seems to just do
this:
 for (i = 0; i < num_entries; i++)
 gen8_set_pte(>t_base[i], scratch_pte);
where,
vma's start = 182190080, length = 132710400, first = 44480, num_entries = 32400
and we have
void gen8_set_pte(void __iomem *addr, gen8_pte_t pte)
{
 writeq(pte, addr);
}

Any idea why executing writeq 32400 times would result in a latency
of ~10ms?


Uncached writes I guess, due VT-d workaround being required to avoid 
display engine faulting due overfetching.


Something like https://patchwork.freedesktop.org/series/97492/ would 
have probably resolved this issue as well. I guess time to go and read 
that series in detail.


Regards,

Tvrtko






Therefore, to fix this issue, we just ensure that the misplaced VMA
does not get evicted when we try to pin it with PIN_MAPPABLE -- by
returning early if the mappable/fenceable flag is not set.

Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS (compared to ~59 FPS with
this patch). Since upstream Weston submits a frame ~7ms before the
next vblank, the latencies seen between atomic commit and flip event
are 7, 24 (7 + 16.66), 7, 24. suggesting that it misses the
vblank every other frame.

Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us   |i915_gem_object_set_cache_level();
  i915_gem_object_ggtt_pin_ww() {
0.390 us   |  i915_vma_instance();
0.178 us   |  i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us   |i915_active_acquire_if_busy();
0.475 us   |  }
intel_runtime_pm_get() {
0.087 us   |intel_runtime_pm_acquire();
0.259 us   |  }
__i915_active_wait() {
0.085 us   |i915_active_acquire_if_busy();
0.240 us   |  }
__i915_vma_evict() {
  ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us |  }
10508.516 us |   }

Cc: Tvrtko Ursulin 
Signed-off-by: Vivek Kasireddy 
---
   drivers/gpu/drm/i915/i915_gem.c | 8 +++-
   1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9747924cc57b..7307c5de1c58 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -939,8 +939,1

Re: [Intel-gfx] [PATCH 2/2] drm/doc: add rfc section for small BAR uapi

2022-03-18 Thread Lionel Landwerlin


Hey Matthew, all,

This sounds like a good thing to have.
There are a number of DG2 machines where we have a small BAR and this is 
causing more apps to fail.


Anv currently reports 3 memory heaps to the app :

    - local device only (not host visible) -> mapped to lmem
    - device/cpu -> mapped to smem
    - local device but also host visible -> mapped to lmem

So we could use this straight away, by just not putting the 
I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS flag on the allocation of the 
first heap.


One thing I don't see in this proposal is how can we get the size of the 
2 lmem heap : cpu visible, cpu not visible

We could use that to report the appropriate size to the app.
We probably want to report a new drm_i915_memory_region_info and either :
    - put one of the reserve field to use to indicate : cpu visible
    - or define a new enum value in drm_i915_gem_memory_class

Cheers,

-Lionel


On 18/02/2022 13:22, Matthew Auld wrote:

Add an entry for the new uapi needed for small BAR on DG2+.

Signed-off-by: Matthew Auld 
Cc: Thomas Hellström 
Cc: Jon Bloomfield 
Cc: Daniel Vetter 
Cc: Jordan Justen 
Cc: Kenneth Graunke 
Cc: mesa-...@lists.freedesktop.org
---
  Documentation/gpu/rfc/i915_small_bar.h   | 153 +++
  Documentation/gpu/rfc/i915_small_bar.rst |  40 ++
  Documentation/gpu/rfc/index.rst  |   4 +
  3 files changed, 197 insertions(+)
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
  create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst

diff --git a/Documentation/gpu/rfc/i915_small_bar.h 
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..fa65835fd608
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,153 @@
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that in the future we want to have our buffer flags here, at least for
+ * the stuff that is immutable. Previously we would have two ioctls, one to
+ * create the object with gem_create, and another to apply various parameters,
+ * however this creates some ambiguity for the params which are considered
+ * immutable. Also in general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+   /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*
+* Note that for some devices we have might have further minimum
+* page-size restrictions(larger than 4K), like for device local-memory.
+* However in general the final size here should always reflect any
+* rounding up, if for example using the 
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+* extension to place the object in device local-memory.
+*/
+   __u64 size;
+   /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+   __u32 handle;
+   /**
+* @flags: Optional flags.
+*
+* Supported values:
+*
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that
+* the object will need to be accessed via the CPU.
+*
+* Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+* only strictly required on platforms where only some of the device
+* memory is directly visible or mappable through the CPU, like on DG2+.
+*
+* One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+* ensure we can always spill the allocation to system memory, if we
+* can't place the object in the mappable part of
+* I915_MEMORY_CLASS_DEVICE.
+*
+* Note that buffers that need to be captured with EXEC_OBJECT_CAPTURE,
+* will need to enable this hint, if the object can also be placed in
+* I915_MEMORY_CLASS_DEVICE, starting from DG2+. The execbuf call will
+* throw an error otherwise. This also means that such objects will need
+* I915_MEMORY_CLASS_SYSTEM set as a possible placement.
+*
+* Without this hint, the kernel will assume that non-mappable
+* I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
+* kernel can still migrate the object to the mappable part, as a last
+* resort, if userspace ever CPU faults this object, but this might be
+* expensive, and so ideally should be avoided.
+*/
+#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0)
+   __u32 flags;
+   /**
+* @extensions: The chain of extensions to apply to this object.
+*
+* This will be useful in the future when we need to support several
+* different extensions, and we need to apply more than one when
+* creating the object. See struct i915_user_extension.
+*
+* If we d

[Intel-gfx] ✓ Fi.CI.BAT: success for Separate panel orientation property creating and value setting

2022-03-18 Thread Patchwork

== Series Details ==

Series: Separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/101530/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_11380 -> Patchwork_22608


Summary
---

  **SUCCESS**

  No regressions found.

  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/index.html

Participating hosts (48 -> 44)
--

  Additional (1): bat-jsl-2 
  Missing(5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus 

Possible new issues
---

  Here are the unknown changes that may have been introduced in Patchwork_22608:

### IGT changes ###

 Suppressed 

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@i915_selftest@live@hugepages:
- {bat-rpls-2}:   NOTRUN -> [INCOMPLETE][1]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/bat-rpls-2/igt@i915_selftest@l...@hugepages.html

  
Known issues


  Here are the changes found in Patchwork_22608 that come from known issues:

### IGT changes ###

 Issues hit 

  * igt@i915_selftest@live@hangcheck:
- bat-dg1-6:  [PASS][2] -> [DMESG-FAIL][3] ([i915#4494] / 
[i915#4957])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-bdw-5557u:   NOTRUN -> [INCOMPLETE][4] ([i915#3921])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html

  * igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u:   NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 
similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html

  * igt@kms_setmode@basic-clone-single-crtc:
- fi-bdw-5557u:   NOTRUN -> [SKIP][6] ([fdo#109271]) +14 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/fi-bdw-5557u/igt@kms_setm...@basic-clone-single-crtc.html

  
 Possible fixes 

  * igt@i915_selftest@live@gtt:
- {bat-rpls-2}:   [INCOMPLETE][7] ([i915#4391] / [i915#5337]) -> 
[PASS][8]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_selftest@l...@gtt.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/bat-rpls-2/igt@i915_selftest@l...@gtt.html

  * igt@i915_selftest@live@objects:
- {bat-rpls-2}:   [DMESG-WARN][9] ([i915#4391]) -> [PASS][10] +3 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/bat-rpls-2/igt@i915_selftest@l...@objects.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22608/bat-rpls-2/igt@i915_selftest@l...@objects.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
  [i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
  [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
  [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
  [i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
  [i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
  [i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
  [i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
  [i915#5291]: https://gitlab.freedesktop.org/drm/intel/issues/5291
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [i915#5337]: https://gitlab.freedesktop.org/drm/intel/issues/5337
  [i915#5339]: https://gitl

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add GuC Error Capture Support

2022-03-18 Thread Patchwork

== Series Details ==

Series: Add GuC Error Capture Support
URL   : https://patchwork.freedesktop.org/series/101527/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_11380_full -> Patchwork_22607_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_22607_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_22607_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

Participating hosts (12 -> 11)
--

  Missing(1): shard-rkl 

Possible new issues
---

  Here are the unknown changes that may have been introduced in 
Patchwork_22607_full:

### IGT changes ###

 Possible regressions 

  * 
igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-75@pipe-b-edp-1-downscale-with-pixel-format:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb8/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-b-edp-1-downscale-with-pixel-format.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb2/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-b-edp-1-downscale-with-pixel-format.html

  
Known issues


  Here are the changes found in Patchwork_22607_full that come from known 
issues:

### IGT changes ###

 Issues hit 

  * igt@gem_exec_balancer@parallel-balancer:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-iclb2/igt@gem_exec_balan...@parallel-balancer.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb5/igt@gem_exec_balan...@parallel-balancer.html

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) +1 similar issue
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl:  [PASS][8] -> [FAIL][9] ([i915#2842])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-kbl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
- shard-apl:  [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11380/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html

  * igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-apl2/igt@gem_lmem_swapp...@heavy-verify-random.html

  * igt@gem_lmem_swapping@random-engines:
- shard-skl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 
similar issue
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-skl10/igt@gem_lmem_swapp...@random-engines.html

  * igt@gem_pxp@create-valid-protected-context:
- shard-iclb: NOTRUN -> [SKIP][14] ([i915#4270])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb3/igt@gem_...@create-valid-protected-context.html

  * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][15] ([i915#768]) +2 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb3/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
- shard-iclb: NOTRUN -> [SKIP][16] ([fdo#109290])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb3/igt@gem_userptr_bl...@coherency-sync.html

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#3323])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-iclb3/igt@gem_userptr_bl...@dmabuf-sync.html
- shard-skl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22607/shard-skl6/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@dmabuf-unsync:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#3297]) +1 similar issue
   [19]: 
https://intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915/dmc: don't register DMC debugfs file if there's no DMC

2022-03-18 Thread Jani Nikula

On Thu, 17 Mar 2022, Lucas De Marchi  wrote:
> On Thu, Mar 17, 2022 at 08:36:17PM +0200, Jani Nikula wrote:
>>Register the DMC debugfs file only on platforms that support
>>DMC. There's no point in having a no-op debugfs file.
>
> It seems this would not change much the behavior (fail on open vs fail
> on read). But the code in igt is suspicious:
>
>
>   bool igt_pm_dmc_loaded(int debugfs)
>   {
>   char buf[15];
>   int len;
>
>   len = igt_sysfs_read(debugfs, "i915_dmc_info", buf, sizeof(buf) 
> - 1);
>   if (len < 0)
>   return true; /* no CSR support, no DMC requirement */
>
>  From a quick inspection of igt_sysfs_read() it seems it would just
> return 0 if there's nothing to be read. And it would return < 0 on
> failure to open the file.
>
> These would be the affected tests:
>
> tests/i915/i915_pm_rpm.c:
> tests/i915/i915_pm_lpsp.c:
> tests/i915/i915_pm_dc.c:
>   igt_require(igt_pm_dmc_loaded(data.debugfs_fd));

Ok, I think I'll just drop this patch for now, don't have the time to go
down that rabbit hole...

Thanks,
Jani.

>
>
> Lucas De Marchi
>
>>
>>Signed-off-by: Jani Nikula 
>>---
>> drivers/gpu/drm/i915/display/intel_dmc.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
>>b/drivers/gpu/drm/i915/display/intel_dmc.c
>>index 5de13f978e57..8dfa2aa9f8bd 100644
>>--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>>+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>>@@ -818,9 +818,6 @@ static int intel_dmc_debugfs_status_show(struct seq_file 
>>*m, void *unused)
>>  struct intel_dmc *dmc;
>>  i915_reg_t dc5_reg, dc6_reg = INVALID_MMIO_REG;
>>
>>- if (!HAS_DMC(i915))
>>- return -ENODEV;
>>-
>>  dmc = &i915->dmc;
>>
>>  wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>>@@ -890,6 +887,9 @@ void intel_dmc_debugfs_register(struct drm_i915_private 
>>*i915)
>> {
>>  struct drm_minor *minor = i915->drm.primary;
>>
>>+ if (!HAS_DMC(i915))
>>+ return;
>>+
>>  debugfs_create_file("i915_dmc_info", 0444, minor->debugfs_root,
>>  i915, &intel_dmc_debugfs_status_fops);
>> }
>>-- 
>>2.30.2
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH] drm/i915/display: Add smem fallback allocation for dpt

2022-03-18 Thread Juha-Pekka Heikkila


On 17.3.2022 13.55, Matthew Auld wrote:

On Wed, 16 Mar 2022 at 22:23, Juha-Pekka Heikkila
 wrote:


Add fallback smem allocation for dpt if stolen memory
allocation failed.

Signed-off-by: Juha-Pekka Heikkila 
---
  drivers/gpu/drm/i915/display/intel_dpt.c | 18 ++
  1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index fb0e7e79e0cd..c8b66433d4db 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -10,6 +10,7 @@
  #include "intel_display_types.h"
  #include "intel_dpt.h"
  #include "intel_fb.h"
+#include "gem/i915_gem_internal.h"


Nit: these should be kept sorted



  struct i915_dpt {
 struct i915_address_space vm;
@@ -128,6 +129,10 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
 void __iomem *iomem;
 struct i915_gem_ww_ctx ww;
 int err;
+   u64 pin_flags = 0;
+
+   if (i915_gem_object_is_stolen(dpt->obj))
+   pin_flags |= PIN_MAPPABLE; /* for i915_vma_pin_iomap(stolen) */

 wakeref = intel_runtime_pm_get(&i915->runtime_pm);
 atomic_inc(&i915->gpu_error.pending_fb_pin);
@@ -138,7 +143,7 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space 
*vm)
 continue;

 vma = i915_gem_object_ggtt_pin_ww(dpt->obj, &ww, NULL, 0, 4096,
- HAS_LMEM(i915) ? 0 : 
PIN_MAPPABLE);
+ pin_flags);
 if (IS_ERR(vma)) {
 err = PTR_ERR(vma);
 continue;
@@ -248,10 +253,15 @@ intel_dpt_create(struct intel_framebuffer *fb)

 size = round_up(size * sizeof(gen8_pte_t), I915_GTT_PAGE_SIZE);

-   if (HAS_LMEM(i915))
-   dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
-   else
+   dpt_obj = i915_gem_object_create_lmem(i915, size, 
I915_BO_ALLOC_CONTIGUOUS);
+   if (IS_ERR(dpt_obj) && i915_ggtt_has_aperture(to_gt(i915)->ggtt))
 dpt_obj = i915_gem_object_create_stolen(i915, size);
+   if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
+   drm_dbg_kms(&i915->drm, "fb: [FB:%d] Allocating dpt from 
smem\n",
+   fb->base.base.id);
+
+   dpt_obj = i915_gem_object_create_internal(i915, size);


Looks like we are missing some prerequisite patch to be able to
directly map such memory in vma_pin_iomap?


For these functions I'm more like a consumer, I was following 
suggestions from Chris on this. Is there something extra that should be 
considered in this regard when use it like this?





+   }
 if (IS_ERR(dpt_obj))
 return ERR_CAST(dpt_obj);

--
2.28.0

Re: [Intel-gfx] [PATCH 4/8] drm/i915/dmc: fix i915_reg_t usage

2022-03-18 Thread Jani Nikula

On Thu, 17 Mar 2022, Lucas De Marchi  wrote:
> On Thu, Mar 17, 2022 at 08:36:16PM +0200, Jani Nikula wrote:
>>i915_reg_t is supposed to be a somewhat opaque data type, not to be
>>looked inside.
>>
>>Signed-off-by: Jani Nikula 
>
>
> Reviewed-by: Lucas De Marchi 
>
> but maybe also already clean up the remaining one?
>
> $ git grep "i915_reg_t.*= *{ *}"
> drivers/gpu/drm/i915/display/intel_display_debugfs.c:   i915_reg_t dc5_reg, 
> dc6_reg = {};

So that's the one being fixed here.

> drivers/gpu/drm/i915/gt/intel_ring_submission.c:
> i915_reg_t last_reg = {}; /* keep gcc quiet */

I'll send a separate fix for that, not part of this series.

Thanks,
Jani.

>
> Lucas De Marchi
>
>>---
>> drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
>>b/drivers/gpu/drm/i915/display/intel_dmc.c
>>index 2e11725a0828..5de13f978e57 100644
>>--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>>+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>>@@ -816,7 +816,7 @@ static int intel_dmc_debugfs_status_show(struct seq_file 
>>*m, void *unused)
>>  struct drm_i915_private *i915 = m->private;
>>  intel_wakeref_t wakeref;
>>  struct intel_dmc *dmc;
>>- i915_reg_t dc5_reg, dc6_reg = {};
>>+ i915_reg_t dc5_reg, dc6_reg = INVALID_MMIO_REG;
>>
>>  if (!HAS_DMC(i915))
>>  return -ENODEV;
>>@@ -868,7 +868,7 @@ static int intel_dmc_debugfs_status_show(struct seq_file 
>>*m, void *unused)
>>  }
>>
>>  seq_printf(m, "DC3 -> DC5 count: %d\n", intel_de_read(i915, dc5_reg));
>>- if (dc6_reg.reg)
>>+ if (i915_mmio_reg_valid(dc6_reg))
>>  seq_printf(m, "DC5 -> DC6 count: %d\n",
>> intel_de_read(i915, dc6_reg));
>>
>>-- 
>>2.30.2
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dmc: move assert_dmc_loaded() to intel_dmc.c

2022-03-18 Thread Jani Nikula

On Thu, 17 Mar 2022, Lucas De Marchi  wrote:
> On Thu, Mar 17, 2022 at 08:36:14PM +0200, Jani Nikula wrote:
>>Start localizing DMC register and data access to intel_dmc.c.
>>
>>Signed-off-by: Jani Nikula 
>>---
>> drivers/gpu/drm/i915/display/intel_display_power.c | 12 
>> drivers/gpu/drm/i915/display/intel_dmc.c   | 11 +++
>> drivers/gpu/drm/i915/display/intel_dmc.h   |  2 ++
>> 3 files changed, 13 insertions(+), 12 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
>>b/drivers/gpu/drm/i915/display/intel_display_power.c
>>index b3efe345567f..6a5695008f7c 100644
>>--- a/drivers/gpu/drm/i915/display/intel_display_power.c
>>+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
>>@@ -905,18 +905,6 @@ static void bxt_disable_dc9(struct drm_i915_private 
>>*dev_priv)
>>  intel_pps_unlock_regs_wa(dev_priv);
>> }
>>
>>-static void assert_dmc_loaded(struct drm_i915_private *dev_priv)
>>-{
>>- drm_WARN_ONCE(&dev_priv->drm,
>>-   !intel_de_read(dev_priv,
>>-  
>>DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
>>-  "DMC program storage start is NULL\n");
>>- drm_WARN_ONCE(&dev_priv->drm, !intel_de_read(dev_priv, DMC_SSP_BASE),
>>-   "DMC SSP Base Not fine\n");
>>- drm_WARN_ONCE(&dev_priv->drm, !intel_de_read(dev_priv, DMC_HTP_SKL),
>>-   "DMC HTP Not fine\n");
>>-}
>>-
>> /**
>>  * intel_display_power_set_target_dc_state - Set target dc state.
>>  * @dev_priv: i915 device
>>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
>>b/drivers/gpu/drm/i915/display/intel_dmc.c
>>index 66fd69259e73..63ae16622c3e 100644
>>--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>>+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>>@@ -305,6 +305,17 @@ void intel_dmc_load_program(struct drm_i915_private 
>>*dev_priv)
>>  gen9_set_dc_state_debugmask(dev_priv);
>> }
>>
>>+void assert_dmc_loaded(struct drm_i915_private *i915)
>>+{
>>+ drm_WARN_ONCE(&i915->drm,
>>+   !intel_de_read(i915, 
>>DMC_PROGRAM(i915->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
>>+   "DMC program storage start is NULL\n");
>>+ drm_WARN_ONCE(&i915->drm, !intel_de_read(i915, DMC_SSP_BASE),
>>+   "DMC SSP Base Not fine\n");
>>+ drm_WARN_ONCE(&i915->drm, !intel_de_read(i915, DMC_HTP_SKL),
>>+   "DMC HTP Not fine\n");
>>+}
>>+
>> static bool fw_info_matches_stepping(const struct intel_fw_info *fw_info,
>>   const struct stepping_info *si)
>> {
>>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h 
>>b/drivers/gpu/drm/i915/display/intel_dmc.h
>>index 7c590309a3a9..326f80ad0f31 100644
>>--- a/drivers/gpu/drm/i915/display/intel_dmc.h
>>+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
>>@@ -55,4 +55,6 @@ void intel_dmc_ucode_suspend(struct drm_i915_private *i915);
>> void intel_dmc_ucode_resume(struct drm_i915_private *i915);
>> bool intel_dmc_has_payload(struct drm_i915_private *i915);
>>
>>+void assert_dmc_loaded(struct drm_i915_private *i915);
>
>
> intel_dmc_assert_loaded()?

assert_dmc_loaded() is in line with the display asserts we have:

git grep assert_ -- drivers/gpu/drm/i915/display/*.h

I'd rather stick with that convention for now, and moving away from it
should be a separate conversation.

BR,
Jani.

>
> Lucas De Marchi
>
>>+
>> #endif /* __INTEL_DMC_H__ */
>>-- 
>>2.30.2
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Separate panel orientation property creating and value setting

2022-03-18 Thread Patchwork

== Series Details ==

Series: Separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/101530/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Separate panel orientation property creating and value setting

2022-03-18 Thread Patchwork

== Series Details ==

Series: Separate panel orientation property creating and value setting
URL   : https://patchwork.freedesktop.org/series/101530/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
e49373f13754 gpu: drm: separate panel orientation property creating and value 
setting
-:130: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#130: FILE: drivers/gpu/drm/drm_connector.c:2423:
+ * ^Icreate the connector's panel orientation property$

-:141: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#141: FILE: drivers/gpu/drm/drm_connector.c:2434:
+int drm_connector_init_panel_orientation_property(

-:147: ERROR:SPACING: space required before the open parenthesis '('
#147: FILE: drivers/gpu/drm/drm_connector.c:2440:
+   if(dev->mode_config.panel_orientation_property)

-:151: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#151: FILE: drivers/gpu/drm/drm_connector.c:2444:
+   prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
+   "panel orientation",

-:176: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#176: FILE: include/drm/drm_connector.h:1808:
+int drm_connector_init_panel_orientation_property(

total: 1 errors, 1 warnings, 3 checks, 99 lines checked
10c78f057d39 drm/mediatek: init panel orientation property
a6a047990b09 drm/msm: init panel orientation property
912fd1736584 arm64: dts: mt8183: Add panel rotation

[Intel-gfx] [PATCH] drm/i915/adl_p: Increase CDCLK by 15% if PSR2 is used

2022-03-18 Thread Stanislav Lisovskiy

We are currently getting FIFO underruns, in particular
when PSR2 is enabled. There seem to be no existing workaround
or patches, which can fix that issue(were expecting some recent
selective fetch update and DBuf bw/SAGV fixes to help,
which unfortunately didn't).
Current idea is that it looks like for some reason the
DBuf prefill time isn't enough once we exit PSR2, despite its
theoretically correct.
So bump it up a bit by 15%(minimum experimental amount required
to get it working), if PSR2 is enabled.
For PSR1 there is no need in this hack, so we limit it only
to PSR2 and Alderlake.

Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/display/intel_cdclk.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index fda8b701..095b79950788 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2325,6 +2325,19 @@ int intel_crtc_compute_min_cdclk(const struct 
intel_crtc_state *crtc_state)
dev_priv->max_cdclk_freq));
}
 
+   if (IS_ALDERLAKE_P(dev_priv)) {
+   struct intel_encoder *encoder;
+
+   for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+   if (intel_dp->psr.psr2_enabled) {
+   min_cdclk = DIV_ROUND_UP(min_cdclk * 100, 85);
+   break;
+   }
+   }
+   }
+
if (min_cdclk > dev_priv->max_cdclk_freq) {
drm_dbg_kms(&dev_priv->drm,
"required cdclk (%d kHz) exceeds max (%d kHz)\n",
-- 
2.24.1.485.gad05a3d8e5

1 2 >

1 - 100 of 113 matches

Mail list logo