[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/xelpd: break feature inheritance

[Patchwork]

== Series Details ==

Series: drm/i915/xelpd: break feature inheritance
URL   : https://patchwork.freedesktop.org/series/91422/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10214 -> Patchwork_20352


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][1] ([i915#2782] / [i915#2940] / 
[i915#3462]) -> [DMESG-FAIL][2] ([i915#3462])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10214/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20352/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-cfl-8700k:   [FAIL][3] ([i915#3363]) -> [FAIL][4] ([i915#2426] / 
[i915#3363])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10214/fi-cfl-8700k/igt@run...@aborted.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20352/fi-cfl-8700k/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][5] ([i915#3462]) -> [FAIL][6] ([i915#1602] / 
[i915#2029])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10214/fi-bdw-5557u/igt@run...@aborted.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20352/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][7] ([i915#1436] / [i915#3363]) -> [FAIL][8] 
([i915#1436] / [i915#2426] / [i915#3363])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10214/fi-kbl-guc/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20352/fi-kbl-guc/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][9] ([i915#3363] / [i915#3462]) -> [FAIL][10] 
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10214/fi-cml-u2/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20352/fi-cml-u2/igt@run...@aborted.html
- fi-cml-s:   [FAIL][11] ([i915#3363] / [i915#3462]) -> [FAIL][12] 
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10214/fi-cml-s/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20352/fi-cml-s/igt@run...@aborted.html

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

  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2082]: https://gitlab.freedesktop.org/drm/intel/issues/2082
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462


Participating hosts (43 -> 39)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10214 -> Patchwork_20352

  CI-20190529: 20190529
  CI_DRM_10214: 2bba812cf661cf2ffa2874a30d4a2c8fcb3937cc @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6104: f8f81bd3752f3126a47d9dbba2d0ab29f7c17a19 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20352: 1d29f900b190af8631473b80ba724478045d44a9 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

1d29f900b190 drm/i915/xelpd: break feature inheritance

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/xelpd: break feature inheritance

[Lucas De Marchi]

It's becoming pretty cumbersome to track the features enabled going back
to GEN7. Gather the XE_LPD display features together in XE_LPD_FEATURES
macro so they are sufficient to describe the display features.

In ADL-P's device_info we set has_psr_hw_tracking to 0 as it would
otherwise be enabled since it is inheriting from GEN12_FEATURES.

Signed-off-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/i915_pci.c | 50 +++--
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 83b500bb170c..5e8348f506b8 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -939,15 +939,48 @@ static const struct intel_device_info adl_s_info = {
.dma_mask_size = 46,
 };
 
+#define XE_LPD_CURSOR_OFFSETS \
+   .cursor_offsets = { \
+   [PIPE_A] = CURSOR_A_OFFSET, \
+   [PIPE_B] = IVB_CURSOR_B_OFFSET, \
+   [PIPE_C] = IVB_CURSOR_C_OFFSET, \
+   [PIPE_D] = TGL_CURSOR_D_OFFSET, \
+   }
+
 #define XE_LPD_FEATURES \
-   .display.ver = 13,  \
-   .display.has_psr_hw_tracking = 0,   \
-   .abox_mask = GENMASK(1, 0), \
-   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), \
-   .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |  \
-   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  \
-   .dbuf.size = 4096,  \
-   .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
BIT(DBUF_S4)
+   .abox_mask = GENMASK(1, 0), 
\
+   .color = { .degamma_lut_size = 33, .gamma_lut_size = 262145 },  
\
+   .cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |  
\
+   BIT(TRANSCODER_C) | BIT(TRANSCODER_D),  
\
+   .dbuf.size = 4096,  
\
+   .dbuf.slice_mask = BIT(DBUF_S1) | BIT(DBUF_S2) | BIT(DBUF_S3) | 
\
+   BIT(DBUF_S4),   
\
+   .display.has_ddi = 1,   
\
+   .display.has_dmc = 1,   
\
+   .display.has_dp_mst = 1,
\
+   .display.has_dsb = 1,   
\
+   .display.has_dsc = 1,   
\
+   .display.has_fbc = 1,   
\
+   .display.has_fpga_dbg = 1,  
\
+   .display.has_hdcp = 1,  
\
+   .display.has_hotplug = 1,   
\
+   .display.has_ipc = 1,   
\
+   .display.has_psr = 1,   
\
+   .display.ver = 13,  
\
+   .pipe_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C) | BIT(PIPE_D), 
\
+   .pipe_offsets = {   
\
+   [TRANSCODER_A] = PIPE_A_OFFSET, 
\
+   [TRANSCODER_B] = PIPE_B_OFFSET, 
\
+   [TRANSCODER_C] = PIPE_C_OFFSET, 
\
+   [TRANSCODER_D] = PIPE_D_OFFSET, 
\
+   },  
\
+   .trans_offsets = {  
\
+   [TRANSCODER_A] = TRANSCODER_A_OFFSET,   
\
+   [TRANSCODER_B] = TRANSCODER_B_OFFSET,   
\
+   [TRANSCODER_C] = TRANSCODER_C_OFFSET,   
\
+   [TRANSCODER_D] = TRANSCODER_D_OFFSET,   
\
+   },  
\
+   XE_LPD_CURSOR_OFFSETS
 
 static const struct intel_device_info adl_p_info = {
GEN12_FEATURES,
@@ -956,6 +989,7 @@ static const struct intel_device_info adl_p_info = {
.has_cdclk_crawl = 1,
.require_force_probe = 1,
.display.has_modular_fia = 1,
+   .display.has_psr_hw_tracking = 0,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
.ppgtt_size = 48,
-- 
2.31.1

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

Re: [Intel-gfx] [CI 4/4] drm/i915/adl_p: Load DMC

[Lucas De Marchi]

On Fri, Jun 11, 2021 at 12:43:55PM -0700, Anusha Srivatsa wrote:

Load DMC v2.10 on ADLP. The release notes mention that
this version enables few power savings features.

v2: Add DMC_PATH() for ADLP (Lucas)

Cc: Lucas De Marchi 
Cc: Clint Taylor 
Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 18e0d225a478..f8789d4543bf 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -45,6 +45,10 @@

#define GEN12_DMC_MAX_FW_SIZE   ICL_DMC_MAX_FW_SIZE

+#define ADLP_DMC_PATH  DMC_PATH(adlp, 2, 10)
+#define ADLP_DMC_VERSION_REQUIRED  DMC_VERSION(2, 10)
+MODULE_FIRMWARE(ADLP_DMC_PATH);
+
#define ADLS_DMC_PATH   DMC_PATH(adls, 2, 01)
#define ADLS_DMC_VERSION_REQUIRED   DMC_VERSION(2, 1)
MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -724,7 +728,11 @@ void intel_dmc_ucode_init(struct drm_i915_private 
*dev_priv)
 */
intel_dmc_runtime_pm_get(dev_priv);

-   if (IS_ALDERLAKE_S(dev_priv)) {
+   if (IS_ALDERLAKE_P(dev_priv)) {
+   dmc->fw_path = ADLP_DMC_PATH;
+   dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
+   dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
+   } else if (IS_ALDERLAKE_S(dev_priv)) {
dmc->fw_path = ADLS_DMC_PATH;
dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
--
2.25.0

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

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

Re: [Intel-gfx] [CI 2/4] drm/i915/xelpd: Pipe A DMC plugging

[Lucas De Marchi]

On Fri, Jun 11, 2021 at 12:43:53PM -0700, Anusha Srivatsa wrote:

This patch adds Pipe A plumbing to the already
existing parsing and loading functions which is
taken care of in the prep patches. Adding MAX_DMC_FW
to keep track for both Main and Pipe A DMC while loading
the respective blobs.

Also adding present field in dmc_info.
s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
fw_info_matches_stepping() helper. CSR_PROGRAM() should now
take the starting address of the particular blob (Main or Pipe)
and not hardcode it.

v2: Add dmc_offset and start_mmioaddr fields for dmc_info struct.

v3: Add a missing corner cases of stepping-substepping combination in
fw_info_matches_stepping() helper.

v4: Add macro for start_mmioaddr for V1 package. Simplify code
in dmc_set_fw_offset (Lucas)

Cc: Souza, Jose 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
.../drm/i915/display/intel_display_debugfs.c  |   4 +-
.../drm/i915/display/intel_display_power.c|   5 +-
drivers/gpu/drm/i915/display/intel_dmc.c  | 131 ++
drivers/gpu/drm/i915/display/intel_dmc.h  |   4 +
drivers/gpu/drm/i915/i915_reg.h   |   2 +-
5 files changed, 85 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 88bb05d5c483..2a1c39a0e56e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)

seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
+   seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >= 
12));
+   seq_printf(m, "Pipe A fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));

if (!intel_dmc_has_payload(dev_priv))
goto out;
@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)

out:
seq_printf(m, "program base: 0x%08x\n",
-  intel_de_read(dev_priv, DMC_PROGRAM(0)));
+  intel_de_read(dev_priv, 
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
seq_printf(m, "ssp base: 0x%08x\n",
   intel_de_read(dev_priv, DMC_SSP_BASE));
seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv, DMC_HTP_SKL));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4298ae684d7d..285380079aab 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private 
*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(0)),
- "DMC program storage start is NULL\n");
+ !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),
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 269a57d936ab..18e0d225a478 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -96,6 +96,7 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
#define PACKAGE_V2_MAX_FW_INFO_ENTRIES  32
#define DMC_V1_MAX_MMIO_COUNT   8
#define DMC_V3_MAX_MMIO_COUNT   20
+#define DMC_V1_MMIO_START_RANGE0x8

struct intel_css_header {
/* 0x09 for DMC */
@@ -317,8 +318,7 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = &dev_priv->dmc;
-   struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
-   u32 i, fw_size;
+   u32 id, i;

if (!HAS_DMC(dev_priv)) {
drm_err(&dev_priv->drm,
@@ -332,20 +332,25 @@ void intel_dmc_load_program(struct drm_i915_private 
*dev_priv)
return;
}

-   fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(&dev_priv->runtime_pm);

preempt_disable();

-   for (i = 0; i < fw_size; i++)
-   intel_uncore_write_fw(&dev_priv->uncore, DMC_PROGRAM(i),
- dmc_info->payload[i]);
+   for (id = 0; id < DMC_FW_MAX; id++) {
+   for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
+   in

[Intel-gfx] ✗ Fi.CI.IGT: failure for GuC submission / DRM scheduler integration plan + new uAPI

[Patchwork]

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI
URL   : https://patchwork.freedesktop.org/series/91417/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10213_full -> Patchwork_20351_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/shard-glk7/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/shard-glk1/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html

  

### Piglit changes ###

 Possible regressions 

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitxor-abs-neg-int-ivec3 
(NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][3] +7 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/pig-icl-1065g7/spec@glsl-1.30@execution@built-in-functi...@fs-op-bitxor-abs-neg-int-ivec3.html

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitxor-not-ivec2-int 
(NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][4]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/pig-icl-1065g7/spec@glsl-1.30@execution@built-in-functi...@fs-op-bitxor-not-ivec2-int.html

  
New tests
-

  New tests have been introduced between CI_DRM_10213_full and 
Patchwork_20351_full:

### New Piglit tests (9) ###

  * spec@glsl-1.30@execution@built-in-functions@fs-asinh-vec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@fs-op-assign-bitand-uvec4-uvec4:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitand-ivec2-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitand-not-ivec3-ivec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitxor-abs-neg-int-ivec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitxor-not-ivec2-int:
- Statuses : 1 crash(s)
- Exec time: [0.46] s

  * spec@glsl-1.30@execution@built-in-functions@fs-op-bitxor-not-ivec3-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@vs-op-add-uvec2-uvec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.30@execution@built-in-functions@vs-op-assign-rshift-uvec3-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@fbdev@nullptr:
- shard-glk:  [PASS][5] -> [DMESG-WARN][6] ([i915#118] / [i915#95])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/shard-glk1/igt@fb...@nullptr.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/shard-glk8/igt@fb...@nullptr.html

  * igt@gem_ctx_isolation@preservation-s3@vecs0:
- shard-apl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/shard-apl1/igt@gem_ctx_isolation@preservation...@vecs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/shard-apl6/igt@gem_ctx_isolation@preservation...@vecs0.html

  * igt@gem_ctx_persistence@clone:
- shard-snb:  NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1099]) +6 
similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/shard-snb6/igt@gem_ctx_persiste...@clone.html

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

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

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC submission / DRM scheduler integration plan + new uAPI

[Patchwork]

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI
URL   : https://patchwork.freedesktop.org/series/91417/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10213 -> Patchwork_20351


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-tgl-1115g4}:[FAIL][1] ([i915#1888]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live@objects:
- {fi-tgl-dsi}:   [DMESG-WARN][3] ([i915#2867]) -> [PASS][4] +10 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-tgl-dsi/igt@i915_selftest@l...@objects.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-tgl-dsi/igt@i915_selftest@l...@objects.html

  
 Warnings 

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

  * igt@i915_selftest@live@execlists:
- fi-cfl-8109u:   [INCOMPLETE][7] ([i915#3462]) -> [DMESG-FAIL][8] 
([i915#3462])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-bsw-nick:[DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10] 
([i915#2782] / [i915#2940] / [i915#3462])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][11] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][12] ([i915#1436] / [i915#3363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-skl-6600u/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-skl-6600u/igt@run...@aborted.html
- fi-cfl-8109u:   [FAIL][13] ([i915#3363]) -> [FAIL][14] ([i915#2426] / 
[i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-cfl-8109u/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-cfl-8109u/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][15] ([i915#3363] / [k.org#202321]) -> 
[FAIL][16] ([i915#2426] / [i915#3363] / [k.org#202321])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-glk-dsi/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-glk-dsi/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][17] ([i915#3462]) -> [FAIL][18] ([i915#1602] / 
[i915#2029])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-bdw-5557u/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][19] ([i915#1436] / [i915#3363]) -> [FAIL][20] 
([i915#1436] / [i915#2426] / [i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-soraka/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][21] ([i915#1436] / [i915#3363]) -> [FAIL][22] 
([i915#1436] / [i915#2426] / [i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-guc/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-kbl-guc/igt@run...@aborted.html
- fi-cml-s:   [FAIL][23] ([i915#3363] / [i915#3462]) -> [FAIL][24] 
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-cml-s/igt@run...@aborted.html
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-cml-s/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][25] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][26] ([i915#1436] / [i915#3363])
   [25]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-7567u/igt@run...@aborted.html
   [26]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20351/fi-kbl-7567u/igt@run...@aborted.html

  
  {name}: This element is suppressed. This means it is ignored when computing
  the

[Intel-gfx] ✗ Fi.CI.DOCS: warning for GuC submission / DRM scheduler integration plan + new uAPI

[Patchwork]

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI
URL   : https://patchwork.freedesktop.org/series/91417/
State : warning

== Summary ==

$ make htmldocs 2>&1 > /dev/null | grep i915
/home/cidrm/kernel/Documentation/gpu/rfc/i915_scheduler:138: 
./Documentation/gpu/rfc/i915_parallel_execbuf.h:30: WARNING: Error in 
"code-block" directive:


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

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC submission / DRM scheduler integration plan + new uAPI

[Patchwork]

== Series Details ==

Series: GuC submission / DRM scheduler integration plan + new uAPI
URL   : https://patchwork.freedesktop.org/series/91417/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
2a85231e7bad drm/doc/rfc: i915 GuC submission / DRM scheduler
-:35: WARNING:BAD_SIGN_OFF: Duplicate signature
#35: 
Cc: Jason Ekstrand 

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

-:47: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#47: FILE: Documentation/gpu/rfc/i915_scheduler.rst:1:
+=

total: 0 errors, 3 warnings, 0 checks, 98 lines checked
2ba86c355a5b drm/doc/rfc: i915 new parallel submission uAPI plan
-:39: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does 
MAINTAINERS need updating?
#39: 
new file mode 100644

-:44: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier 
tag in line 1
#44: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:1:
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */

-:72: WARNING:TYPO_SPELLING: 'inteface' may be misspelled - perhaps 'interface'?
#72: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:29:
+ * inteface.


-:159: WARNING:PREFER_DEFINED_ATTRIBUTE_MACRO: Prefer __packed over 
__attribute__((packed))
#159: FILE: Documentation/gpu/rfc/i915_parallel_execbuf.h:116:
+} __attribute__ ((packed));

-:224: WARNING:REPEATED_WORD: Possible repeated word: 'in'
#224: FILE: Documentation/gpu/rfc/i915_scheduler.rst:145:
+in in the drm_i915_gem_exec_object2 list or the first N if 
I915_EXEC_BATCH_FIRST

total: 0 errors, 5 warnings, 0 checks, 179 lines checked


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

[Intel-gfx] ✗ Fi.CI.IGT: failure for Pipe DMC Support (rev7)

[Patchwork]

== Series Details ==

Series: Pipe DMC Support (rev7)
URL   : https://patchwork.freedesktop.org/series/90445/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10213_full -> Patchwork_20350_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][1] -> [DMESG-WARN][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/shard-iclb5/igt@i915_pm...@dc6-psr.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/shard-iclb7/igt@i915_pm...@dc6-psr.html

  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/shard-glk7/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/shard-glk2/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html

  

### Piglit changes ###

 Possible regressions 

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@flat-gl_backsecondarycolor-smooth-gl_secondarycolor
 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [INCOMPLETE][5] +7 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/pig-icl-1065g7/spec@glsl-1.30@linker@interpolation-qualifiers@flat-gl_backsecondarycolor-smooth-gl_secondarycolor.html

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@unused-default-gl_backsecondarycolor-unused-noperspective-gl_secondarycolor
 (NEW):
- {pig-icl-1065g7}:   NOTRUN -> [CRASH][6] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/pig-icl-1065g7/spec@glsl-1.30@linker@interpolation-qualifiers@unused-default-gl_backsecondarycolor-unused-noperspective-gl_secondarycolor.html

  * spec@glsl-1.50@execution@texelfetch@gs-texelfetch-usampler2darray (NEW):
- pig-snb-2600:   NOTRUN -> [FAIL][7]
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/pig-snb-2600/spec@glsl-1.50@execution@texelfe...@gs-texelfetch-usampler2darray.html

  
New tests
-

  New tests have been introduced between CI_DRM_10213_full and 
Patchwork_20350_full:

### New Piglit tests (11) ###

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@default-gl_backsecondarycolor-flat-gl_frontsecondarycolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@flat-gl_backsecondarycolor-default-gl_secondarycolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@flat-gl_backsecondarycolor-smooth-gl_secondarycolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@flat-gl_backsecondarycolor-unused-gl_secondarycolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@noperspective-gl_backcolor-default-gl_frontcolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@noperspective-gl_backcolor-smooth-gl_frontcolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@unused-default-gl_backsecondarycolor-unused-noperspective-gl_secondarycolor:
- Statuses : 1 crash(s)
- Exec time: [0.46] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@unused-default-gl_backsecondarycolor-unused-smooth-gl_secondarycolor:
- Statuses : 1 crash(s)
- Exec time: [0.41] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@unused-flat-gl_backsecondarycolor-unused-default-gl_secondarycolor:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * 
spec@glsl-1.30@linker@interpolation-qualifiers@unused-noperspective-gl_frontcolor-unused-smooth-gl_color:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s

  * spec@glsl-1.50@execution@texelfetch@gs-texelfetch-usampler2darray:
- Statuses : 1 fail(s)
- Exec time: [0.22] s

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@idempotent:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/shard-snb2/igt@gem_ctx_persiste...@idempotent.html

  * igt@gem_ctx_persistence@ma

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Steer MCR reads to lowest potential slice/subslice

[Matt Roper]

On Fri, Jun 11, 2021 at 05:35:53AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Steer MCR reads to lowest potential slice/subslice
> URL   : https://patchwork.freedesktop.org/series/91367/
> State : failure
> 
> == Summary ==
> 
> CI Bug Log - changes from CI_DRM_10206_full -> Patchwork_20340_full
> 
> 
> Summary
> ---
> 
>   **FAILURE**
> 
>   Serious unknown changes coming with Patchwork_20340_full absolutely need to 
> be
>   verified manually.
>   
>   If you think the reported changes have nothing to do with the changes
>   introduced in Patchwork_20340_full, please notify your bug team to allow 
> them
>   to document this new failure mode, which will reduce false positives in CI.
> 
>   
> 
> Possible new issues
> ---
> 
>   Here are the unknown changes that may have been introduced in 
> Patchwork_20340_full:
> 
> ### IGT changes ###
> 
>  Possible regressions 
> 
>   * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd:
> - shard-iclb: NOTRUN -> [DMESG-WARN][1]
>[1]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-iclb6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html
> 
>   * igt@i915_selftest@perf@engine_cs:
> - shard-iclb: [PASS][2] -> [DMESG-WARN][3] +36 similar issues
>[2]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10206/shard-iclb8/igt@i915_selftest@perf@engine_cs.html
>[3]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-iclb7/igt@i915_selftest@perf@engine_cs.html

Steering to the minconfig does seem to have successfully fixed the issue
on EHL/JSL according to the BAT results.  However the code changes
uncovered a similar issue on ICL.  From experimenting on ICL, it appears
that if you don't steer to the minconfig, you can sometimes get random
garbage (rather than 0's) when render power gating is enabled.  CI
wasn't flagging a workaround warning on ICL all along only because we
were reading back random garbage that just happened to have a '1' in the
relevant bit.

So the problem now is that the fls() -> ffs() conversion didn't actually
get us to the minconfig on this ICL system.  Since there are two types
of multicast registers on gen11 (subslice multicast and l3bank
multicast), we currently pick our subslice target by &'ing those two
masks together.  Unfortunately the minconfig subslice may not also be a
suitable l3bank, so even using ffs() instead of fls() on the
intersection will give us a "bad" steering ID.

It looks like there will be cases where we can't just always use the
same steering value for both the subslice multicast registers and the
l3bank multicast registers; we'll probably want to steer to the
minconfig subslice by default and then explicitly re-steer to a valid
l3bank in cases where we can't find a suitable value for both.  I
already have some patches that do something similar for steering on
upcoming platforms, so I'll get those reorganized so that we can use
them on these platforms as well.


Matt

> 
>   * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled:
> - shard-glk:  [PASS][4] -> [FAIL][5]
>[4]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10206/shard-glk1/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html
>[5]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-glk8/igt@kms_draw_...@draw-method-rgb565-mmap-wc-untiled.html
> 
>   
> Known issues
> 
> 
>   Here are the changes found in Patchwork_20340_full that come from known 
> issues:
> 
> ### IGT changes ###
> 
>  Issues hit 
> 
>   * igt@gem_create@create-massive:
> - shard-snb:  NOTRUN -> [DMESG-WARN][6] ([i915#3002])
>[6]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-snb5/igt@gem_cre...@create-massive.html
> 
>   * igt@gem_ctx_persistence@legacy-engines-queued:
> - shard-snb:  NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#1099]) +6 
> similar issues
>[7]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-queued.html
> 
>   * igt@gem_ctx_persistence@many-contexts:
> - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2410])
>[8]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10206/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html
>[9]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html
> 
>   * igt@gem_eio@in-flight-contexts-10ms:
> - shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#3063])
>[10]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10206/shard-tglb1/igt@gem_...@in-flight-contexts-10ms.html
>[11]: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20340/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html
> 
>   * igt@gem_exec_fair@basic-flow@rcs0:
> - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])

[Intel-gfx] [PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Matthew Brost]

Add entry for i915 new parallel submission uAPI plan.

v2:
 (Daniel Vetter):
  - Expand logical order explaination
  - Add dummy header
  - Only allow N BBs in execbuf IOCTL
  - Configure parallel submission per slot not per gem context
v3:
 (Marcin Ślusarz):
  - Lot's of typos / bad english fixed
 (Tvrtko Ursulin):
  - Consistent pseudo code, clean up wording in descriptions
v4:
 (Daniel Vetter)
  - Drop flags
  - Add kernel doc
  - Reword a few things / fix typos
 (Tvrtko)
  - Reword a few things / fix typos

Cc: Tvrtko Ursulin 
Cc: Tony Ye 
CC: Carl Zhang 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Signed-off-by: Matthew Brost 
Acked-by: Daniel Vetter 
---
 Documentation/gpu/rfc/i915_parallel_execbuf.h | 117 ++
 Documentation/gpu/rfc/i915_scheduler.rst  |  59 -
 2 files changed, 175 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h

diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..c22af3a359e4
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,117 @@
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
i915_context_engines_parallel_submit */
+
+/**
+ * struct drm_i915_context_engines_parallel_submit - Configure engine for
+ * parallel submission.
+ *
+ * Setup a slot in the context engine map to allow multiple BBs to be submitted
+ * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the 
GPU
+ * in parallel. Multiple hardware contexts are created internally in the i915
+ * run these BBs. Once a slot is configured for N BBs only N BBs can be
+ * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user
+ * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how
+ * many BBs there are based on the slot's configuration. The N BBs are the last
+ * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set.
+ *
+ * The default placement behavior is to create implicit bonds between each
+ * context if each context maps to more than 1 physical engine (e.g. context is
+ * a virtual engine). Also we only allow contexts of same engine class and 
these
+ * contexts must be in logically contiguous order. Examples of the placement
+ * behavior described below. Lastly, the default is to not allow BBs to
+ * preempted mid BB rather insert coordinated preemption on all hardware
+ * contexts between each set of BBs. Flags may be added in the future to change
+ * bott of these default behaviors.
+ *
+ * Returns -EINVAL if hardware context placement configuration is invalid or if
+ * the placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * inteface.
+ *
+ * .. code-block::
+ *
+ * Example 1 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=1,
+ *  engines=CS[0],CS[1])
+ *
+ * Results in the following valid placement:
+ * CS[0], CS[1]
+ *
+ * Example 2 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ *  engines=CS[0],CS[2],CS[1],CS[3])
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ * CS[2], CS[3]
+ *
+ * This can also be thought of as 2 virtual engines described by 2-D array
+ * in the engines the field with bonds placed between each index of the
+ * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to
+ * CS[3].
+ * VE[0] = CS[0], CS[2]
+ * VE[1] = CS[1], CS[3]
+ *
+ * Example 3 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ *  engines=CS[0],CS[1],CS[1],CS[3])
+ *
+ * Results in the following valid and invalid placements:
+ * CS[0], CS[1]
+ * CS[1], CS[3] - Not logical contiguous, return -EINVAL
+ */
+struct drm_i915_context_engines_parallel_submit {
+   /**
+* @base: base user extension.
+*/
+   struct i915_user_extension base;
+
+   /**
+* @engine_index: slot for parallel engine
+*/
+   __u16 engine_index;
+
+   /**
+* @width: number of contexts per parallel engine
+*/
+   __u16 width;
+
+   /**
+* @num_siblings: number of siblings per context
+*/
+   __u16 num_siblings;
+
+   /**
+* @mbz16: reserved for future use; mu

[Intel-gfx] [PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler

[Matthew Brost]

Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.

v2:
 (Daniel Vetter)
  - Expand explaination of why bonding isn't supported for GuC
submission
  - CC some of the DRM scheduler maintainers
  - Add priority inheritance / boosting use case
  - Add reasoning for removing in order assumptions
 (Daniel Stone)
  - Add links to priority spec
v4:
 (Tvrtko)
  - Add TODOs section
 (Daniel Vetter)
  - Pull in 1 line from following patch

Cc: Christian König 
Cc: Luben Tuikov 
Cc: Alex Deucher 
Cc: Steven Price 
Cc: Jon Bloomfield 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Daniel Vetter 
Cc: Jason Ekstrand 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Matthew Brost 
Reviewed-by: Daniel Vetter 
Acked-by: Dave Airlie 
---
 Documentation/gpu/rfc/i915_scheduler.rst | 91 
 Documentation/gpu/rfc/index.rst  |  4 ++
 2 files changed, 95 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst

diff --git a/Documentation/gpu/rfc/i915_scheduler.rst 
b/Documentation/gpu/rfc/i915_scheduler.rst
new file mode 100644
index ..7acd386a6b49
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_scheduler.rst
@@ -0,0 +1,91 @@
+=
+I915 GuC Submission/DRM Scheduler Section
+=
+
+Upstream plan
+=
+For upstream the overall plan for landing GuC submission and integrating the
+i915 with the DRM scheduler is:
+
+* Merge basic GuC submission
+   * Basic submission support for all gen11+ platforms
+   * Not enabled by default on any current platforms but can be enabled via
+ modparam enable_guc
+   * Lots of rework will need to be done to integrate with DRM scheduler so
+ no need to nit pick everything in the code, it just should be
+ functional, no major coding style / layering errors, and not regress
+ execlists
+   * Update IGTs / selftests as needed to work with GuC submission
+   * Enable CI on supported platforms for a baseline
+   * Rework / get CI heathly for GuC submission in place as needed
+* Merge new parallel submission uAPI
+   * Bonding uAPI completely incompatible with GuC submission, plus it has
+ severe design issues in general, which is why we want to retire it no
+ matter what
+   * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step
+ which configures a slot with N contexts
+   * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to
+ a slot in a single execbuf IOCTL and the batches run on the GPU in
+ paralllel
+   * Initially only for GuC submission but execlists can be supported if
+ needed
+* Convert the i915 to use the DRM scheduler
+   * GuC submission backend fully integrated with DRM scheduler
+   * All request queues removed from backend (e.g. all backpressure
+ handled in DRM scheduler)
+   * Resets / cancels hook in DRM scheduler
+   * Watchdog hooks into DRM scheduler
+   * Lots of complexity of the GuC backend can be pulled out once
+ integrated with DRM scheduler (e.g. state machine gets
+ simplier, locking gets simplier, etc...)
+   * Execlists backend will minimum required to hook in the DRM scheduler
+   * Legacy interface
+   * Features like timeslicing / preemption / virtual engines would
+ be difficult to integrate with the DRM scheduler and these
+ features are not required for GuC submission as the GuC does
+ these things for us
+   * ROI low on fully integrating into DRM scheduler
+   * Fully integrating would add lots of complexity to DRM
+ scheduler
+   * Port i915 priority inheritance / boosting feature in DRM scheduler
+   * Used for i915 page flip, may be useful to other DRM drivers as
+ well
+   * Will be an optional feature in the DRM scheduler
+   * Remove in-order completion assumptions from DRM scheduler
+   * Even when using the DRM scheduler the backends will handle
+ preemption, timeslicing, etc... so it is possible for jobs to
+ finish out of order
+   * Pull out i915 priority levels and use DRM priority levels
+   * Optimize DRM scheduler as needed
+
+TODOs for GuC submission upstream
+=
+
+* Need an update to GuC firmware / i915 to enable error state capture
+* Open source tool to decode GuC logs
+* Public GuC spec
+
+New uAPI for basic GuC submission
+=
+No major changes are required to the uAPI for basic GuC submission. The only
+change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
+This attribute i

[Intel-gfx] [PATCH 0/2] GuC submission / DRM scheduler integration plan + new uAPI

[Matthew Brost]

Subject and patches say it all.

v2: Address comments, patches have details of changes
v3: Address comments, patches have details of changes
v4: Address comments, patches have details of changes

Signed-off-by: Matthew Brost 

Matthew Brost (2):
  drm/doc/rfc: i915 GuC submission / DRM scheduler
  drm/doc/rfc: i915 new parallel submission uAPI plan

 Documentation/gpu/rfc/i915_parallel_execbuf.h | 117 ++
 Documentation/gpu/rfc/i915_scheduler.rst  | 148 ++
 Documentation/gpu/rfc/index.rst   |   4 +
 3 files changed, 269 insertions(+)
 create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
 create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst

-- 
2.28.0

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

Re: [Intel-gfx] [PATCH v2] drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary crtc

[Navare, Manasi]

On Thu, Jun 10, 2021 at 12:05:28PM +0300, Jani Nikula wrote:
> Add a single point of truth for figuring out the primary/secondary crtc
> for bigjoiner instead of duplicating the magic pipe +/- 1 in multiple
> places.
> 
> Also fix the pipe validity checks to properly take non-contiguous pipes
> into account. The current checks may theoretically overflow
> i915->pipe_to_crtc_mapping[pipe], albeit with a warning, due to fused
> off pipes, as INTEL_NUM_PIPES() returns the actual number of pipes on
> the platform, and the check is for INTEL_NUM_PIPES() == pipe + 1.
> 
> Prefer primary/secondary terminology going forward.
> 
> v2:
> - Improved abstractions for pipe validity etc.
> 
> Fixes: 8a029c113b17 ("drm/i915/dp: Modify VDSC helpers to configure DSC for 
> Bigjoiner slave")
> Fixes: d961eb20adb6 ("drm/i915/bigjoiner: atomic commit changes for 
> uncompressed joiner")
> Cc: Animesh Manna 
> Cc: Manasi Navare 
> Cc: Vandita Kulkarni 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Dropped patch 2/2 [1], as the pipes need to be adjacent for big joiner,
> even if pipes have been fused off.
> 
> [1] 
> https://patchwork.freedesktop.org/patch/msgid/20210603122842.22496-2-jani.nik...@intel.com
> ---
>  drivers/gpu/drm/i915/display/intel_display.c  |  7 ++--
>  .../drm/i915/display/intel_display_types.h|  8 
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 40 +--
>  drivers/gpu/drm/i915/display/intel_vdsc.h |  1 +
>  4 files changed, 40 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 362bff9beb5c..3bad4e00f7be 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -9618,7 +9618,6 @@ static int intel_atomic_check_bigjoiner(struct 
> intel_atomic_state *state,
>   struct intel_crtc_state *old_crtc_state,
>   struct intel_crtc_state *new_crtc_state)
>  {
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>   struct intel_crtc_state *slave_crtc_state, *master_crtc_state;
>   struct intel_crtc *slave, *master;
>  
> @@ -9634,15 +9633,15 @@ static int intel_atomic_check_bigjoiner(struct 
> intel_atomic_state *state,
>   if (!new_crtc_state->bigjoiner)
>   return 0;
>  
> - if (1 + crtc->pipe >= INTEL_NUM_PIPES(dev_priv)) {
> + slave = intel_dsc_get_bigjoiner_secondary(crtc);
> + if (!slave) {
>   DRM_DEBUG_KMS("[CRTC:%d:%s] Big joiner configuration requires "
> "CRTC + 1 to be used, doesn't exist\n",
> crtc->base.base.id, crtc->base.name);
>   return -EINVAL;
>   }
>  
> - slave = new_crtc_state->bigjoiner_linked_crtc =
> - intel_get_crtc_for_pipe(dev_priv, crtc->pipe + 1);
> + new_crtc_state->bigjoiner_linked_crtc = slave;
>   slave_crtc_state = intel_atomic_get_crtc_state(&state->base, slave);
>   master = crtc;
>   if (IS_ERR(slave_crtc_state))
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 15e91a99c8b9..7d64d8487fbe 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1723,6 +1723,14 @@ vlv_pipe_to_channel(enum pipe pipe)
>   }
>  }
>  
> +static inline bool intel_pipe_valid(struct drm_i915_private *i915, enum pipe 
> pipe)
> +{
> + return (pipe >= 0 &&
> + pipe < ARRAY_SIZE(i915->pipe_to_crtc_mapping) &&
> + INTEL_INFO(i915)->pipe_mask & BIT(pipe) &&
> + i915->pipe_to_crtc_mapping[pipe]);

So no need to check INTEL_NUM_PIPES as long as the index exists in 
pipe_to_crtc_mappings correct?

> +}
> +
>  static inline struct intel_crtc *
>  intel_get_first_crtc(struct drm_i915_private *dev_priv)
>  {
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 7121b66bf96d..85749370508c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -1106,6 +1106,27 @@ static i915_reg_t dss_ctl2_reg(const struct 
> intel_crtc_state *crtc_state)
>   return is_pipe_dsc(crtc_state) ? ICL_PIPE_DSS_CTL2(pipe) : DSS_CTL2;
>  }
>  
> +static struct intel_crtc *
> +_get_crtc_for_pipe(struct drm_i915_private *i915, enum pipe pipe)
> +{
> + if (!intel_pipe_valid(i915, pipe))
> + return NULL;
> +
> + return intel_get_crtc_for_pipe(i915, pipe);
> +}

Can we not include intel_pipe_valid() check in intel_get_crtc_for_pipe() so 
that any other function that calls intel_get_crtc_for_pipe() also
validates the pipe ?

Manasi


> +
> +struct intel_crtc *
> +intel_dsc_get_bigjoiner_secondary(const struct intel_crtc *primary_crtc)
> +{
> + return _get_crtc_for_pipe(to_i915(primary_crtc->

[Intel-gfx] ✓ Fi.CI.BAT: success for Pipe DMC Support (rev7)

[Patchwork]

== Series Details ==

Series: Pipe DMC Support (rev7)
URL   : https://patchwork.freedesktop.org/series/90445/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10213 -> Patchwork_20350


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Possible fixes 

  * igt@gem_exec_suspend@basic-s0:
- {fi-tgl-1115g4}:[FAIL][1] ([i915#1888]) -> [PASS][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s0.html

  * igt@i915_selftest@live@objects:
- {fi-tgl-dsi}:   [DMESG-WARN][3] ([i915#2867]) -> [PASS][4] +10 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-tgl-dsi/igt@i915_selftest@l...@objects.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-tgl-dsi/igt@i915_selftest@l...@objects.html

  
 Warnings 

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

  * igt@i915_selftest@live@execlists:
- fi-icl-u2:  [INCOMPLETE][7] ([i915#2782] / [i915#3462]) -> 
[DMESG-FAIL][8] ([i915#3462])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][9] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][10] ([i915#1436] / [i915#3363])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-skl-6600u/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][11] ([i915#2782] / [i915#3363]) -> [FAIL][12] 
([i915#2426] / [i915#2782] / [i915#3363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-icl-u2/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-icl-u2/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][13] ([i915#1436] / [i915#3363]) -> [FAIL][14] 
([i915#1436] / [i915#2426] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-soraka/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-7500u:   [FAIL][15] ([i915#1436] / [i915#3363]) -> [FAIL][16] 
([i915#1436] / [i915#2426] / [i915#3363])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-7500u/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-kbl-7500u/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][17] ([i915#1436] / [i915#3363]) -> [FAIL][18] 
([i915#1436] / [i915#2426] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-guc/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][19] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][20] ([i915#1436] / [i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10213/fi-kbl-7567u/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20350/fi-kbl-7567u/igt@run...@aborted.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#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#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012
  [i915#3049]: https://gitlab.freedesktop.org/drm/intel/issues/3049
  [i915#3276]: https://gitlab.freedesktop.org/drm/intel/issues/3276
  [i915#3277]: https://gitlab.freedesktop.org/d

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Pipe DMC Support (rev7)

[Patchwork]

== Series Details ==

Series: Pipe DMC Support (rev7)
URL   : https://patchwork.freedesktop.org/series/90445/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct 
i915_vma *[assigned] vma
+drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] 
__iomem *[assigned] iomem
+drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type 
in assignment (different address spaces)
+drivers/gpu/drm/i915/gem/i915_gem_ttm.c:564:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy 
expression type 31
+drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 
'intel_gt_reset_trylock' - different lock contexts for basic block
+drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain 
integer as NULL pointer
+drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 
16777216
+drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 
16777216
+./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative 
(-262080)
+./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative 
(-262080)
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen11_fwtable_write8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read64' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_read8' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write16' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write32' - different lock contexts for basic block
+./include/linux/spinlock.h:409:9: warning: context imbalance in 
'gen12_fwtable_write8' - different lock contexts for basic block
+./include/li

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Pipe DMC Support (rev7)

[Patchwork]

== Series Details ==

Series: Pipe DMC Support (rev7)
URL   : https://patchwork.freedesktop.org/series/90445/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
f4c89ab48cfd drm/i915/dmc: Introduce DMC_FW_MAIN
519b42fb4bf9 drm/i915/xelpd: Pipe A DMC plugging
-:48: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#48: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:587:
+  intel_de_read(dev_priv, 
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));

-:63: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#63: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:965:
+
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),

total: 0 errors, 2 warnings, 0 checks, 287 lines checked
82459c72a5a5 drm/i915/adl_p: Pipe B DMC Support
99f3d8c71c86 drm/i915/adl_p: Load DMC


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Document the Virtual Engine uAPI

[Patchwork]

== Series Details ==

Series: drm/i915: Document the Virtual Engine uAPI
URL   : https://patchwork.freedesktop.org/series/91406/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212_full -> Patchwork_20349_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-iclb2/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#658])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@feature_discov...@psr2.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-iclb4/igt@feature_discov...@psr2.html

  * igt@gem_ctx_isolation@preservation-s3@bcs0:
- shard-apl:  [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +2 similar 
issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-apl7/igt@gem_ctx_isolation@preservation...@bcs0.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-apl2/igt@gem_ctx_isolation@preservation...@bcs0.html

  * igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-hostile.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2410])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html

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

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2849])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb:  NOTRUN -> [FAIL][18] ([i915#2389]) +2 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][19] -> [SKIP][20] ([i915#2190])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-tglb6/igt@gem_huc_c...@huc-copy.html
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#2190])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-iclb2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_offset@clear:
- shard-iclb: [PASS][22] -> [FAIL][23] ([i915#3160])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb8/igt@gem_mmap_off...@clear.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-iclb7/igt@gem_mmap_off...@clear.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][24] ([i915#2658])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/shard-apl8/igt@gem_pr...@exhaustion.html

  * igt@gem_render_copy@yf-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][25] ([i915#768])
   [25]: 
https://

Re: [Intel-gfx] [RFC PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan

[Matthew Brost]

On Fri, Jun 04, 2021 at 07:59:05PM +0200, Daniel Vetter wrote:
> On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> > Add entry for i915 new parallel submission uAPI plan.
> > 
> > v2:
> >  (Daniel Vetter):
> >   - Expand logical order explaination
> >   - Add dummy header
> >   - Only allow N BBs in execbuf IOCTL
> >   - Configure parallel submission per slot not per gem context
> > v3:
> >  (Marcin Ślusarz):
> >   - Lot's of typos / bad english fixed
> >  (Tvrtko Ursulin):
> >   - Consistent pseudo code, clean up wording in descriptions
> > 
> > Cc: Tvrtko Ursulin 
> > Cc: Tony Ye 
> > CC: Carl Zhang 
> > Cc: Daniel Vetter 
> > Cc: Jason Ekstrand 
> > Signed-off-by: Matthew Brost 
> > ---
> >  Documentation/gpu/rfc/i915_parallel_execbuf.h | 145 ++
> >  Documentation/gpu/rfc/i915_scheduler.rst  |  55 ++-
> >  2 files changed, 198 insertions(+), 2 deletions(-)
> >  create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
> > 
> > diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h 
> > b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > new file mode 100644
> > index ..20de206e3ab4
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> > @@ -0,0 +1,145 @@
> > +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see 
> > i915_context_engines_parallel_submit */
> > +
> > +/*
> > + * i915_context_engines_parallel_submit:
> 
> So the idea is to make these kerneldoc and pull them into the rfc section.
> Then when we merge, move them to the real uapi section, like what Matt has
> done for lmem.
> 

Yep, will fix in next rev.

> > + *
> > + * Setup a slot in the context engine map to allow multiple BBs to be 
> > submitted
> > + * in a single execbuf IOCTL. Those BBs will then be scheduled to run on 
> > the GPU
> > + * in parallel. Multiple hardware contexts are created internally in the 
> > i915
> > + * run these BBs. Once a slot is configured for N BBs only N BBs can be
> > + * submitted in each execbuf IOCTL and this is implicit behavior e.g. The 
> > user
> > + * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL know 
> > how
> > + * many BBs there are based on the slots configuration. The N BBs are the 
> > last N
> > + * buffer objects for first N if I915_EXEC_BATCH_FIRST is set.
> 
> s/for/or/
> 
> > + *
> > + * There are two currently defined ways to control the placement of the
> > + * hardware contexts on physical engines: default behavior (no flags) and
> > + * I915_PARALLEL_IMPLICIT_BONDS (a flag). More flags may be added the in 
> > the
> > + * future as new hardware / use cases arise. Details of how to use this
> > + * interface above the flags field in this structure.
> > + *
> > + * Returns -EINVAL if hardware context placement configuration is invalid 
> > or if
> > + * the placement configuration isn't supported on the platform / submission
> > + * interface.
> > + * Returns -ENODEV if extension isn't supported on the platform / 
> > submission
> > + * inteface.
> > + */
> > +struct i915_context_engines_parallel_submit {
> > +   struct i915_user_extension base;
> > +
> > +   __u16 engine_index; /* slot for parallel engine */
> 
> Kernel doc here for the inline comments too.
>

Yep.
 
> > +   __u16 width;/* number of contexts per parallel engine */
> > +   __u16 num_siblings; /* number of siblings per context */
> > +   __u16 mbz16;
> > +/*
> > + * Default placement behavior (currently unsupported):
> > + *
> > + * Allow BBs to be placed on any available engine instance. In this case 
> > each
> > + * context's engine mask indicates where that context can be placed. It is
> > + * implied in this mode that all contexts have mutual exclusive placement.
> > + * e.g. If one context is running CSX[0] no other contexts can run on 
> > CSX[0]).
> > + *
> > + * Example 1 pseudo code:
> > + * CSX,Y[N] = generic engine class X or Y, logical instance N
> > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > + * set_engines(INVALID)
> > + * set_parallel(engine_index=0, width=2, num_siblings=2,
> > + * engines=CSX[0],CSX[1],CSY[0],CSY[1])
> > + *
> > + * Results in the following valid placements:
> > + * CSX[0], CSY[0]
> > + * CSX[0], CSY[1]
> > + * CSX[1], CSY[0]
> > + * CSX[1], CSY[1]
> > + *
> > + * This can also be thought of as 2 virtual engines described by 2-D array 
> > in
> > + * the engines the field:
> > + * VE[0] = CSX[0], CSX[1]
> > + * VE[1] = CSY[0], CSY[1]
> > + *
> > + * Example 2 pseudo code:
> > + * CSX[Y] = generic engine of same class X, logical instance N
> > + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> > + * set_engines(INVALID)
> > + * set_parallel(engine_index=0, width=2, num_siblings=3,
> > + * engines=CSX[0],CSX[1],CSX[2],CSX[0],CSX[1],CSX[2])
> > + *
> > + * Results in the following valid placements:
> > + * CSX[0], CSX[1]
> > + * CSX[0], CSX[2]
> > + * CSX[1], CSX[0]
> > + * CSX[1], CSX[2]

[Intel-gfx] [CI 2/4] drm/i915/xelpd: Pipe A DMC plugging

[Anusha Srivatsa]

This patch adds Pipe A plumbing to the already
existing parsing and loading functions which is
taken care of in the prep patches. Adding MAX_DMC_FW
to keep track for both Main and Pipe A DMC while loading
the respective blobs.

Also adding present field in dmc_info.
s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
fw_info_matches_stepping() helper. CSR_PROGRAM() should now
take the starting address of the particular blob (Main or Pipe)
and not hardcode it.

v2: Add dmc_offset and start_mmioaddr fields for dmc_info struct.

v3: Add a missing corner cases of stepping-substepping combination in
fw_info_matches_stepping() helper.

v4: Add macro for start_mmioaddr for V1 package. Simplify code
in dmc_set_fw_offset (Lucas)

Cc: Souza, Jose 
Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
---
 .../drm/i915/display/intel_display_debugfs.c  |   4 +-
 .../drm/i915/display/intel_display_power.c|   5 +-
 drivers/gpu/drm/i915/display/intel_dmc.c  | 131 ++
 drivers/gpu/drm/i915/display/intel_dmc.h  |   4 +
 drivers/gpu/drm/i915/i915_reg.h   |   2 +-
 5 files changed, 85 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 88bb05d5c483..2a1c39a0e56e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
 
seq_printf(m, "fw loaded: %s\n", 
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
+   seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >= 
12));
+   seq_printf(m, "Pipe A fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
 
if (!intel_dmc_has_payload(dev_priv))
goto out;
@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
 
 out:
seq_printf(m, "program base: 0x%08x\n",
-  intel_de_read(dev_priv, DMC_PROGRAM(0)));
+  intel_de_read(dev_priv, 
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
seq_printf(m, "ssp base: 0x%08x\n",
   intel_de_read(dev_priv, DMC_SSP_BASE));
seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv, DMC_HTP_SKL));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4298ae684d7d..285380079aab 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private 
*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(0)),
- "DMC program storage start is NULL\n");
+ !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),
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 269a57d936ab..18e0d225a478 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -96,6 +96,7 @@ MODULE_FIRMWARE(BXT_DMC_PATH);
 #define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
 #define DMC_V1_MAX_MMIO_COUNT  8
 #define DMC_V3_MAX_MMIO_COUNT  20
+#define DMC_V1_MMIO_START_RANGE0x8
 
 struct intel_css_header {
/* 0x09 for DMC */
@@ -317,8 +318,7 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
 void intel_dmc_load_program(struct drm_i915_private *dev_priv)
 {
struct intel_dmc *dmc = &dev_priv->dmc;
-   struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
-   u32 i, fw_size;
+   u32 id, i;
 
if (!HAS_DMC(dev_priv)) {
drm_err(&dev_priv->drm,
@@ -332,20 +332,25 @@ void intel_dmc_load_program(struct drm_i915_private 
*dev_priv)
return;
}
 
-   fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(&dev_priv->runtime_pm);
 
preempt_disable();
 
-   for (i = 0; i < fw_size; i++)
-   intel_uncore_write_fw(&dev_priv->uncore, DMC_PROGRAM(i),
- dmc_info->payload[i]);
+   for (id = 0; id < DMC_FW_MAX; id++) {
+   for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
+   intel_uncore_write_fw(&dev_priv->uncore,
+ 
DMC_PROGRAM(d

[Intel-gfx] [CI 1/4] drm/i915/dmc: Introduce DMC_FW_MAIN

[Anusha Srivatsa]

This is a prep patch for Pipe DMC plugging.

Add dmc_info struct in intel_dmc to have all common fields
shared between all DMC's in the package.
Add DMC_FW_MAIN(dmc_id 0) to refer to the blob.

v2: Remove dmc_offset and start_mmioaddr from dmc_info struct (Jose)

Cc: Souza, Jose 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 38 +---
 drivers/gpu/drm/i915/display/intel_dmc.h | 18 +++
 2 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 97308da28059..269a57d936ab 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -239,7 +239,7 @@ struct stepping_info {
 
 bool intel_dmc_has_payload(struct drm_i915_private *i915)
 {
-   return i915->dmc.dmc_payload;
+   return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
 }
 
 static const struct stepping_info skl_stepping_info[] = {
@@ -316,7 +316,8 @@ static void gen9_set_dc_state_debugmask(struct 
drm_i915_private *dev_priv)
  */
 void intel_dmc_load_program(struct drm_i915_private *dev_priv)
 {
-   u32 *payload = dev_priv->dmc.dmc_payload;
+   struct intel_dmc *dmc = &dev_priv->dmc;
+   struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
u32 i, fw_size;
 
if (!HAS_DMC(dev_priv)) {
@@ -325,26 +326,26 @@ void intel_dmc_load_program(struct drm_i915_private 
*dev_priv)
return;
}
 
-   if (!intel_dmc_has_payload(dev_priv)) {
+   if (!dev_priv->dmc.dmc_info[DMC_FW_MAIN].payload) {
drm_err(&dev_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
 
-   fw_size = dev_priv->dmc.dmc_fw_size;
+   fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(&dev_priv->runtime_pm);
 
preempt_disable();
 
for (i = 0; i < fw_size; i++)
intel_uncore_write_fw(&dev_priv->uncore, DMC_PROGRAM(i),
- payload[i]);
+ dmc_info->payload[i]);
 
preempt_enable();
 
-   for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
-   intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
-  dev_priv->dmc.mmiodata[i]);
+   for (i = 0; i < dmc_info->mmio_count; i++) {
+   intel_de_write(dev_priv, dmc_info->mmioaddr[i],
+  dmc_info->mmiodata[i]);
}
 
dev_priv->dmc.dc_state = 0;
@@ -401,13 +402,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
   size_t rem_size)
 {
struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+   struct dmc_fw_info *dmc_info = &dmc->dmc_info[DMC_FW_MAIN];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
u8 *payload;
 
-   BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+   BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
 
/*
 * Check if we can access common fields, we will checkc again below
@@ -469,10 +471,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
mmioaddr[i]);
return 0;
}
-   dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
-   dmc->mmiodata[i] = mmiodata[i];
+   dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
+   dmc_info->mmiodata[i] = mmiodata[i];
}
-   dmc->mmio_count = mmio_count;
+   dmc_info->mmio_count = mmio_count;
 
rem_size -= header_len_bytes;
 
@@ -485,14 +487,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
drm_err(&i915->drm, "DMC FW too big (%u bytes)\n", 
payload_size);
return 0;
}
-   dmc->dmc_fw_size = dmc_header->fw_size;
+   dmc_info->dmc_fw_size = dmc_header->fw_size;
 
-   dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
-   if (!dmc->dmc_payload)
+   dmc_info->payload = kmalloc(payload_size, GFP_KERNEL);
+   if (!dmc_info->payload)
return 0;
 
payload = (u8 *)(dmc_header) + header_len_bytes;
-   memcpy(dmc->dmc_payload, payload, payload_size);
+   memcpy(dmc_info->payload, payload, payload_size);
 
return header_len_bytes + payload_size;
 
@@ -827,5 +829,5 @@ void intel_dmc_ucode_fini(struct drm_i915_private *dev_priv)
intel_dmc_ucode_suspend(dev_priv);
drm_WARN_ON(&dev_priv->drm, dev_priv->dmc.wakeref);
 
-   kfree(dev_priv->dmc.dmc_payload);
+   kfree(dev_priv->dmc.dmc_info[D

[Intel-gfx] [CI 3/4] drm/i915/adl_p: Pipe B DMC Support

[Anusha Srivatsa]

ADLP requires us to load both Pipe A and Pipe B.
Plug Pipe B loading support.

Cc: Lucas De Marchi 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Lucas De Marchi 
---
 drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 ++
 drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2a1c39a0e56e..db38891a9ef0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -546,6 +546,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "path: %s\n", dmc->fw_path);
seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >= 
12));
seq_printf(m, "Pipe A fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
+   seq_printf(m, "Pipe B fw support: %s\n", 
yesno(IS_ALDERLAKE_P(dev_priv)));
+   seq_printf(m, "Pipe B fw loaded: %s\n", 
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
 
if (!intel_dmc_has_payload(dev_priv))
goto out;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h 
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 007a284b0ef0..c3c00ff03869 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -19,6 +19,7 @@ struct drm_i915_private;
 enum {
DMC_FW_MAIN = 0,
DMC_FW_PIPEA,
+   DMC_FW_PIPEB,
DMC_FW_MAX
 };
 
-- 
2.25.0

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

[Intel-gfx] [CI 4/4] drm/i915/adl_p: Load DMC

[Anusha Srivatsa]

Load DMC v2.10 on ADLP. The release notes mention that
this version enables few power savings features.

v2: Add DMC_PATH() for ADLP (Lucas)

Cc: Lucas De Marchi 
Cc: Clint Taylor 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c 
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 18e0d225a478..f8789d4543bf 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -45,6 +45,10 @@
 
 #define GEN12_DMC_MAX_FW_SIZE  ICL_DMC_MAX_FW_SIZE
 
+#define ADLP_DMC_PATH  DMC_PATH(adlp, 2, 10)
+#define ADLP_DMC_VERSION_REQUIRED  DMC_VERSION(2, 10)
+MODULE_FIRMWARE(ADLP_DMC_PATH);
+
 #define ADLS_DMC_PATH  DMC_PATH(adls, 2, 01)
 #define ADLS_DMC_VERSION_REQUIRED  DMC_VERSION(2, 1)
 MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -724,7 +728,11 @@ void intel_dmc_ucode_init(struct drm_i915_private 
*dev_priv)
 */
intel_dmc_runtime_pm_get(dev_priv);
 
-   if (IS_ALDERLAKE_S(dev_priv)) {
+   if (IS_ALDERLAKE_P(dev_priv)) {
+   dmc->fw_path = ADLP_DMC_PATH;
+   dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
+   dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
+   } else if (IS_ALDERLAKE_S(dev_priv)) {
dmc->fw_path = ADLS_DMC_PATH;
dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
-- 
2.25.0

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

[Intel-gfx] [CI 0/4] Pipe DMC Support

[Anusha Srivatsa]

One change from previous verison is a fix of SKL
regression. Corner cases for stepping-substepping
combination was missing from fw_info_matches_stepping()
helper. Luckily SKL was the only platform in CI that came
under this category and DMC refused to load.

v2: SKL fix tested on SKL.

v3: Minor changes in Pipe DMC plugging patch
as suggested by Lucas
 
v4: Remove the sanity check for MMIO that no longer
apply to newer platforms.(Anusha)

Anusha Srivatsa (4):
  drm/i915/dmc: Introduce DMC_FW_MAIN
  drm/i915/xelpd: Pipe A DMC plugging
  drm/i915/adl_p: Pipe B DMC Support
  drm/i915/adl_p: Load DMC

 .../drm/i915/display/intel_display_debugfs.c  |   6 +-
 .../drm/i915/display/intel_display_power.c|   5 +-
 drivers/gpu/drm/i915/display/intel_dmc.c  | 165 ++
 drivers/gpu/drm/i915/display/intel_dmc.h  |  23 ++-
 drivers/gpu/drm/i915/i915_reg.h   |   2 +-
 5 files changed, 123 insertions(+), 78 deletions(-)

-- 
2.25.0

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Move system memory to TTM for discrete (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev2)
URL   : https://patchwork.freedesktop.org/series/90898/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10212_full -> Patchwork_20347_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk9/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-glk5/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][3] ([fdo#111827])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-iclb2/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#658])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@feature_discov...@psr2.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-iclb6/igt@feature_discov...@psr2.html

  * igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-hostile.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][7] -> [DMESG-WARN][8] ([i915#180])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-kbl3/igt@gem_...@in-flight-suspend.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-kbl1/igt@gem_...@in-flight-suspend.html

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

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar 
issue
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2389])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-contexts-forked:
- shard-glk:  [PASS][15] -> [DMESG-WARN][16] ([i915#118] / 
[i915#95]) +1 similar issue
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk9/igt@gem_exec_whis...@basic-contexts-forked.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked.html

  * igt@gem_huc_copy@huc-copy:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#2190])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-iclb2/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@big-copy-odd:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#307])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk9/igt@gem_mmap_...@big-copy-odd.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-glk5/igt@gem_mmap_...@big-copy-odd.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-iclb: [PASS][20] -> [FAIL][21] ([i915#2428])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb3/igt@gem_mmap_...@cpuset-medium-copy.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/shard-iclb3/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][22] ([i91

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915/display: Drop FIXME about turn off infoframes"

[Souza, Jose]

On Thu, 2021-06-10 at 23:52 +, Patchwork wrote:
Patch Details
Series: Revert "drm/i915/display: Drop FIXME about turn off infoframes"
URL:https://patchwork.freedesktop.org/series/91350/
State:  failure
Details:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20337/index.html
CI Bug Log - changes from CI_DRM_10205_full -> Patchwork_20337_full
Summary

FAILURE

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

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

Possible new issues

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

IGT changes
Possible regressions

  *   igt@kms_draw_crc@draw-method-xrgb2101010-mmap-wc-xtiled:
 *   shard-skl: 
PASS
 -> 
FAIL

This patch is only bringing back a comment, not related.

Pushed, thanks for the review Ville.

Known issues

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

IGT changes
Issues hit

  *   igt@gem_ctx_isolation@preservation-s3@rcs0:

 *   shard-kbl: 
PASS
 -> 
DMESG-WARN
 ([i915#180]) +2 similar issues
  *   igt@gem_ctx_persistence@clone:

 *   shard-snb: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#1099]) +4 similar issues
  *   igt@gem_exec_fair@basic-flow@rcs0:

 *   shard-skl: NOTRUN -> 
SKIP
 ([fdo#109271]) +51 similar issues
  *   igt@gem_exec_fair@basic-none@rcs0:

 *   shard-kbl: 
PASS
 -> 
FAIL
 ([i915#2842]) +1 similar issue
  *   igt@gem_exec_fair@basic-pace-solo@rcs0:

 *   shard-kbl: NOTRUN -> 
FAIL
 ([i915#2842])
  *   igt@gem_exec_fair@basic-pace@vcs0:

 *   shard-kbl: 
PASS
 -> 
SKIP
 ([fdo#109271])
  *   igt@gem_exec_parallel@engines@fds:

 *   shard-iclb: 
PASS
 -> 
INCOMPLETE
 ([i915#1895])
  *   igt@gem_exec_reloc@basic-write-cpu-active:

 *   shard-skl: 
PASS
 -> 
DMESG-WARN
 ([i915#1982])
  *   igt@gem_exec_whisper@basic-fds-all:

 *   shard-glk: 
PASS
 -> 
DMESG-WARN
 ([i915#118] / [i915#95])
  *   igt@gem_huc_copy@huc-copy:

 *   shard-apl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#2190])

 *   shard-skl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#2190])

  *   igt@gem_mmap_gtt@big-copy:

 *   shard-skl: 
PASS
 -> 
FAIL
 ([i915#307])
  *   igt@gem_userptr_blits@dmabuf-sync:

 *   shard-apl: NOTRUN -> 
SKIP
 ([fdo#109271] / [i915#3323])
  *   igt@gem_userptr_blits@input-checking:

 *   shard-skl: NOTRUN -> 
DMESG-WARN

Re: [Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0

[Matthew Brost]

On Thu, Jun 10, 2021 at 03:35:57PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 10.06.2021 06:36, Matthew Brost wrote:
> > As part of enabling GuC submission [1] we need to update to the latest
> > and greatest firmware. This series does that. This is a destructive
> > change. e.g. Without all the patches in this series it will break the
> 
> not really 'all'
> 

Yea, typo. I updated the comment below to say 'most' but missed this one.

> > i915 driver. As such, after we review most of these patches they will
> > squashed into a single patch for merging.
> 
> I assume final series will looks as follows:
> 
> 1  = hxg
> 2+3+5+6+7+8+4+10+11+13 = ctb/ads/fw
> 12 = log
> 9  = rst
>

Seems right to me.
 
> > 
> > v2: Address comments, looking for remaning RBs so patches can be
> 
> typo
>

Not seeing the typo.
 
> and likely series should be generated with -v 2 option too
>

Didn't know about -v2 option. Will use going forward.

Matt
 
> 
> > squashed and sent for CI
> > 
> > Signed-off-by: Matthew Brost 
> > 
> > [1] https://patchwork.freedesktop.org/series/89844/i
> > 
> > John Harrison (3):
> >   drm/i915/guc: Support per context scheduling policies
> >   drm/i915/guc: Unified GuC log
> >   drm/i915/guc: Update firmware to v62.0.0
> > 
> > Michal Wajdeczko (10):
> >   drm/i915/guc: Introduce unified HXG messages
> >   drm/i915/guc: Update MMIO based communication
> >   drm/i915/guc: Update CTB response status definition
> >   drm/i915/guc: Add flag for mark broken CTB
> >   drm/i915/guc: New definition of the CTB descriptor
> >   drm/i915/guc: New definition of the CTB registration action
> >   drm/i915/guc: New CTB based communication
> >   drm/i915/doc: Include GuC ABI documentation
> >   drm/i915/guc: Kill guc_clients.ct_pool
> >   drm/i915/guc: Kill ads.client_info
> > 
> >  Documentation/gpu/i915.rst|   8 +
> >  .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
> >  .../gt/uc/abi/guc_communication_ctb_abi.h | 128 +--
> >  .../gt/uc/abi/guc_communication_mmio_abi.h|  65 ++--
> >  .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++
> >  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 107 --
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  45 +--
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 356 +-
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +-
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  75 +---
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  29 +-
> >  drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|   6 +-
> >  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  26 +-
> >  13 files changed, 750 insertions(+), 421 deletions(-)
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/13] Update firmware to v62.0.0

[Matthew Brost]

On Mon, Jun 07, 2021 at 03:19:11PM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > As part of enabling GuC submission [1] we need to update to the latest
> > and greatest firmware. This series does that. This is a destructive
> > change. e.g. Without all the patches in this series it will break the
> > i915 driver. As such, after we review all of these patches they will
> > squashed into a single patch for merging.
> 
> Can you resubmit with an added HAX patch for enable_guc=2 after the first
> round of review? none of the machines in CI seems to have attempted to load
> the guc, not even cfl-guc and kbl-guc. If all the reviews are good maybe
> just resubmit the squashed patch and the enablement with a CI tag, so we can
> merge once we get the results.
> 

Done on trybot, results looks good.
https://patchwork.freedesktop.org/series/91341/

Matt

> Daniele
> 
> > 
> > Signed-off-by: Matthew Brost 
> > 
> > [1] https://patchwork.freedesktop.org/series/89844/
> > 
> > John Harrison (3):
> >drm/i915/guc: Support per context scheduling policies
> >drm/i915/guc: Unified GuC log
> >drm/i915/guc: Update firmware to v62.0.0
> > 
> > Michal Wajdeczko (10):
> >drm/i915/guc: Introduce unified HXG messages
> >drm/i915/guc: Update MMIO based communication
> >drm/i915/guc: Update CTB response status definition
> >drm/i915/guc: Add flag for mark broken CTB
> >drm/i915/guc: New definition of the CTB descriptor
> >drm/i915/guc: New definition of the CTB registration action
> >drm/i915/guc: New CTB based communication
> >drm/i915/doc: Include GuC ABI documentation
> >drm/i915/guc: Kill guc_clients.ct_pool
> >drm/i915/guc: Kill ads.client_info
> > 
> >   Documentation/gpu/i915.rst|   8 +
> >   .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
> >   .../gt/uc/abi/guc_communication_ctb_abi.h | 130 +--
> >   .../gt/uc/abi/guc_communication_mmio_abi.h|  63 ++--
> >   .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 213 +++
> >   drivers/gpu/drm/i915/gt/uc/intel_guc.c| 107 --
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|  45 +--
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 355 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  75 +---
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  29 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_log.h|   6 +-
> >   drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  26 +-
> >   13 files changed, 750 insertions(+), 420 deletions(-)
> > 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [CI 2/4] drm/i915/xelpd: Pipe A DMC plugging

[Srivatsa, Anusha]

> -Original Message-
> From: De Marchi, Lucas 
> Sent: Wednesday, June 9, 2021 11:22 PM
> To: Srivatsa, Anusha 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [CI 2/4] drm/i915/xelpd: Pipe A DMC plugging
> 
> On Fri, Jun 04, 2021 at 12:01:26PM -0700, Anusha Srivatsa wrote:
> >This patch adds Pipe A plumbing to the already existing parsing and
> >loading functions which is taken care of in the prep patches. Adding
> >MAX_DMC_FW to keep track for both Main and Pipe A DMC while loading
> the
> >respective blobs.
> >
> >Also adding present field in dmc_info.
> >s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
> >fw_info_matches_stepping() helper. CSR_PROGRAM() should now take
> the
> >starting address of the particular blob (Main or Pipe) and not hardcode
> >it.
> >
> >v2: Add dmc_offset and start_mmioaddr fields for dmc_info struct.
> >
> >v3: Add a missing corner cases of stepping-substepping combination in
> >fw_info_matches_stepping() helper.
> >
> >Cc: Souza, Jose 
> >Cc: Lucas De Marchi 
> >Signed-off-by: Anusha Srivatsa 
> >---
> > .../drm/i915/display/intel_display_debugfs.c  |   4 +-
> > .../drm/i915/display/intel_display_power.c|   5 +-
> > drivers/gpu/drm/i915/display/intel_dmc.c  | 130 +++---
> > drivers/gpu/drm/i915/display/intel_dmc.h  |   4 +
> > drivers/gpu/drm/i915/i915_reg.h   |   2 +-
> > 5 files changed, 89 insertions(+), 56 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >index 88bb05d5c483..2a1c39a0e56e 100644
> >--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> >@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void
> >*unused)
> >
> > seq_printf(m, "fw loaded: %s\n",
> yesno(intel_dmc_has_payload(dev_priv)));
> > seq_printf(m, "path: %s\n", dmc->fw_path);
> >+seq_printf(m, "Pipe A fw support: %s\n",
> yesno(INTEL_GEN(dev_priv) >= 12));
> >+seq_printf(m, "Pipe A fw loaded: %s\n",
> >+yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
> >
> > if (!intel_dmc_has_payload(dev_priv))
> > goto out;
> >@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void
> >*unused)
> >
> > out:
> > seq_printf(m, "program base: 0x%08x\n",
> >-   intel_de_read(dev_priv, DMC_PROGRAM(0)));
> >+   intel_de_read(dev_priv,
> >+DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
> > seq_printf(m, "ssp base: 0x%08x\n",
> >intel_de_read(dev_priv, DMC_SSP_BASE));
> > seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv,
> DMC_HTP_SKL));
> >diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> >b/drivers/gpu/drm/i915/display/intel_display_power.c
> >index 3e1f6ec61514..b7d4993feca6 100644
> >--- a/drivers/gpu/drm/i915/display/intel_display_power.c
> >+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> >@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private
> >*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(0)),
> >-  "DMC program storage start is NULL\n");
> >+  !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),
> >diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> >b/drivers/gpu/drm/i915/display/intel_dmc.c
> >index b78cb44731fe..09f65ad71f7e 100644
> >--- a/drivers/gpu/drm/i915/display/intel_dmc.c
> >+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> >@@ -317,8 +317,7 @@ static void gen9_set_dc_state_debugmask(struct
> >drm_i915_private *dev_priv)  void intel_dmc_load_program(struct
> >drm_i915_private *dev_priv)  {
> > struct intel_dmc *dmc = &dev_priv->dmc;
> >-struct dmc_fw_info *dmc_info = &dmc-
> >dmc_info[DMC_FW_MAIN];
> >-u32 i, fw_size;
> >+u32 id, i;
> >
> > if (!HAS_DMC(dev_priv)) {
> > drm_err(&dev_priv->drm,
> >@@ -332,20 +331,25 @@ void intel_dmc_load_program(struct
> drm_i915_private *dev_priv)
> > return;
> > }
> >
> >-fw_size = dmc_info->dmc_fw_size;
> > assert_rpm_wakelock_held(&dev_priv->runtime_pm);
> >
> > preempt_disable();
> >
> >-for (i = 0; i < fw_size; i++)
> >-intel_uncore_write_fw(&dev_priv->uncore,
> DMC_PROGRAM(i),
> >-  dmc_info->payload[i]);
> >+for (id = 0; id < DMC_FW_MAX; id++) {
> >+for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
> >+   

Re: [Intel-gfx] [PATCH 07/13] drm/i915/guc: New definition of the CTB registration action

[Matthew Brost]

On Thu, Jun 10, 2021 at 03:19:50PM +0200, Michal Wajdeczko wrote:
> 
> 
> On 10.06.2021 06:38, Matthew Brost wrote:
> > On Wed, Jun 09, 2021 at 10:07:21PM +0200, Michal Wajdeczko wrote:
> >>
> >>
> >> On 09.06.2021 19:36, John Harrison wrote:
> >>> On 6/7/2021 18:23, Daniele Ceraolo Spurio wrote:
>  On 6/7/2021 11:03 AM, Matthew Brost wrote:
> > From: Michal Wajdeczko 
> >
> > Definition of the CTB registration action has changed.
> > Add some ABI documentation and implement required changes.
> >
> > Signed-off-by: Michal Wajdeczko 
> > Signed-off-by: Matthew Brost 
> > Cc: Piotr Piórkowski  #4
> > ---
> >   .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 107 ++
> >   .../gt/uc/abi/guc_communication_ctb_abi.h |   4 -
> >   drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  76 -
> >   3 files changed, 152 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > index 90efef8a73e4..6426fc183692 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > @@ -6,6 +6,113 @@
> >   #ifndef _ABI_GUC_ACTIONS_ABI_H
> >   #define _ABI_GUC_ACTIONS_ABI_H
> >   +/**
> > + * DOC: HOST2GUC_REGISTER_CTB
> > + *
> > + * This message is used as part of the `CTB based communication`_
> > setup.
> > + *
> > + * This message must be sent as `MMIO HXG Message`_.
> > + *
> > + *
> > +---+---+--+
> >
> > + *  |   | Bits  |
> > Description  |
> > + *
> > +===+===+==+
> >
> > + *  | 0 |    31 | ORIGIN =
> > GUC_HXG_ORIGIN_HOST_    |
> > + *  |
> > +---+--+
> > + *  |   | 30:28 | TYPE =
> > GUC_HXG_TYPE_REQUEST_ |
> > + *  |
> > +---+--+
> > + *  |   | 27:16 | DATA0 =
> > MBZ  |
> > + *  |
> > +---+--+
> > + *  |   |  15:0 | ACTION = _`GUC_ACTION_HOST2GUC_REGISTER_CTB` =
> > 0x5200    |
> 
>  Specs says 4505
> 
> > + *
> > +---+---+--+
> >
> > + *  | 1 | 31:12 | RESERVED =
> > MBZ   |
> > + *  |
> > +---+--+
> > + *  |   |  11:8 | **TYPE** - type for the `CT
> > Buffer`_ |
> > + *  |   |
> > |  |
> > + *  |   |   |   - _`GUC_CTB_TYPE_HOST2GUC` =
> > 0 |
> > + *  |   |   |   - _`GUC_CTB_TYPE_GUC2HOST` =
> > 1 |
> > + *  |
> > +---+--+
> > + *  |   |   7:0 | **SIZE** - size of the `CT Buffer`_ in 4K units
> > minus 1  |
> > + *
> > +---+---+--+
> >
> > + *  | 2 |  31:0 | **DESC_ADDR** - GGTT address of the `CTB
> > Descriptor`_    |
> > + *
> > +---+---+--+
> >
> > + *  | 3 |  31:0 | **BUFF_ADDF** - GGTT address of the `CT
> > Buffer`_ |
> > + *
> > +---+---+--+
> >
> > +*
> > + *
> > +---+---+--+
> >
> > + *  |   | Bits  |
> > Description  |
> > + *
> > +===+===+==+
> >
> > + *  | 0 |    31 | ORIGIN =
> > GUC_HXG_ORIGIN_GUC_ |
> > + *  |
> > +---+--+
> > + *  |   | 30:28 | TYPE =
> > GUC_HXG_TYPE_RESPONSE_SUCCESS_    |
> > + *  |
> > +---+--+
> > + *  |   |  27:0 | DATA0 =
> > MBZ  |
> > + *
> > +---+---+--+
> >
> > + */
> > +#define GUC_ACTION_HOST2GUC_REGISTER_CTB    0x4505 // 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gen11: use ffs for minconfig slice/subslice

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: use ffs for minconfig slice/subslice
URL   : https://patchwork.freedesktop.org/series/91398/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10212_full -> Patchwork_20346_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-iclb: [PASS][1] -> [DMESG-WARN][2] +65 similar issues
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb3/igt@kms_frontbuffer_track...@fbc-suspend.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-iclb8/igt@kms_frontbuffer_track...@fbc-suspend.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][3] ([fdo#111827])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-iclb2/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][4] -> [SKIP][5] ([i915#658])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@feature_discov...@psr2.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-iclb7/igt@feature_discov...@psr2.html

  * igt@gem_create@create-clear:
- shard-skl:  [PASS][6] -> [FAIL][7] ([i915#3160])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-skl9/igt@gem_cre...@create-clear.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-skl7/igt@gem_cre...@create-clear.html

  * igt@gem_ctx_persistence@engines-queued:
- shard-snb:  NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-snb5/igt@gem_ctx_persiste...@engines-queued.html

  * igt@gem_eio@in-flight-suspend:
- shard-kbl:  [PASS][9] -> [DMESG-WARN][10] ([i915#180])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-kbl3/igt@gem_...@in-flight-suspend.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-kbl1/igt@gem_...@in-flight-suspend.html

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

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-none@vecs0:
- shard-apl:  [PASS][16] -> [FAIL][17] ([i915#2842] / [i915#3468])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][18] -> [FAIL][19] ([i915#2842])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][20] -> [FAIL][21] ([i915#2849])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][22] -> [SKIP][23] ([i915#2190])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb2/igt@gem_huc_c...@huc-copy.html
   [23]: 
https://intel-gfx-ci.01.o

Re: [Intel-gfx] [PATCH] Revert "drm/i915/display: Drop FIXME about turn off infoframes"

[Ville Syrjälä]

On Thu, Jun 10, 2021 at 12:45:27PM -0700, José Roberto de Souza wrote:
> Looks this FIXME is still valid as we need a way to tell LSPCON to
> stop sending infoframes, so reverting it.
> 
> This reverts commit 3f409e4cd579b287a6c41d017e62c392f7997193.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 390869bd6b633..0b7fef527e202 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2810,6 +2810,7 @@ static void intel_ddi_pre_enable(struct 
> intel_atomic_state *state,
>   conn_state);
>  
>   /* FIXME precompute everything properly */
> + /* FIXME how do we turn infoframes off again? */
>   if (dig_port->lspcon.active && dig_port->dp.has_hdmi_sink)
>   dig_port->set_infoframes(encoder,
>crtc_state->has_infoframe,
> -- 
> 2.32.0

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

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/display: Drop FIXME about turn off infoframes

[Ville Syrjälä]

On Thu, Jun 10, 2021 at 05:44:12PM +, Souza, Jose wrote:
> On Thu, 2021-06-10 at 15:18 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 09, 2021 at 07:25:36PM +, Souza, Jose wrote:
> > > On Tue, 2021-06-08 at 10:26 +0300, Ville Syrjälä wrote:
> > > > On Fri, May 14, 2021 at 04:22:47PM -0700, José Roberto de Souza wrote:
> > > > > intel_dp_set_infoframes() call in intel_ddi_post_disable_dp() will
> > > > > take care to disable all enabled infoframes.
> > > > > 
> > > > > Cc: Ville Syrjälä 
> > > > > Signed-off-by: José Roberto de Souza 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/display/intel_ddi.c | 1 -
> > > > >  1 file changed, 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
> > > > > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > > index 5bc5528f3091..d3bc5a1a936a 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > > > > @@ -2762,7 +2762,6 @@ static void intel_ddi_pre_enable(struct 
> > > > > intel_atomic_state *state,
> > > > >   conn_state);
> > > > >  
> > > > >   /* FIXME precompute everything properly */
> > > > > - /* FIXME how do we turn infoframes off again? */
> > > > 
> > > > The FIXME was there for LSPCON and shouldn't have been removed.
> > > > No one has yet figured out how to do this.
> > > 
> > > intel_ddi_post_disable_dp()->intel_dp_set_infoframes() will be executed 
> > > for LSPCON, or am I missing something?
> > 
> > LSPCON generates its own infoframes, so turning off the video DIP does
> > diddly squat.
> > 
> 
> It would not be the lspcon job to do so when DP -> lspcon video is off?

LSPCON is a blackbox and no one knows what it actually does. Which is
pretty much the point of the FIXME.

> Anyways will be sending the revert in a few minutes, please review that if we 
> really need this fixme back.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Document the Virtual Engine uAPI

[Patchwork]

== Series Details ==

Series: drm/i915: Document the Virtual Engine uAPI
URL   : https://patchwork.freedesktop.org/series/91406/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212 -> Patchwork_20349


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

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

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#2283])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][3] ([i915#3462])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][4] ([fdo#109271]) +5 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[DMESG-FAIL][5] ([i915#3462]) -> [INCOMPLETE][6] 
([i915#2782] / [i915#2940] / [i915#3462])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][7] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][8] ([i915#1436] / [i915#3363])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-skl-6600u/igt@run...@aborted.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-skl-6600u/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][9] ([i915#1602] / [i915#2029]) -> [FAIL][10] 
([i915#3462])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bdw-5557u/igt@run...@aborted.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][11] ([i915#1436] / [i915#3363]) -> [FAIL][12] 
([i915#1436] / [i915#2426] / [i915#3363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-soraka/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][14] ([i915#1436] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-guc/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20349/fi-kbl-guc/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533


Participating hosts (46 -> 39)
--

  Additional (1): fi-jsl-1 
  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan bat-adlp-4 
bat-adls-4 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10212 -> Patchwork_20349

  CI-20190529: 20190529
  CI_DRM_10212: d6a4e59ffc78a058586d57930708ba706d765be4 @ 
git

Re: [Intel-gfx] [PATCH] drm/i915/gen11: use ffs for minconfig slice/subslice

[Ville Syrjälä]

On Fri, Jun 11, 2021 at 08:04:09PM +0530, Tejas Upadhyay wrote:
> w/a on gen11 platforms not working as expected and causing
> more harm on the RC6 flow. Because of subslice steering
> disturbance w/a read is failing. By using ffs we can default
> steering of slice/sublice to minconfig hence w/a will pass
> and any warns will go away.
> 
> Fixes: fb899dd8ea9c ("drm/i915: Apply Wa_1406680159:icl,ehl as an engine 
> workaround")
> Cc: Mika Kuoppala 
> Cc: Matt Roper 
> Signed-off-by: Tejas Upadhyay 
> ---
>  drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 +++---
>  drivers/gpu/drm/i915/intel_pm.c | 10 +++---
>  2 files changed, 18 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index b62d1e31a645..68b14141088a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -991,13 +991,21 @@ wa_init_mcr(struct drm_i915_private *i915, struct 
> i915_wa_list *wal)
>   l3_en = ~0;
>   }
>  
> - slice = fls(sseu->slice_mask) - 1;
> - subslice = fls(l3_en & intel_sseu_get_subslices(sseu, slice));
> + if (GRAPHICS_VER(i915) == 11) {
> + slice = ffs(sseu->slice_mask) - 1;
> + subslice = ffs(l3_en & intel_sseu_get_subslices(sseu, slice));
> + } else {
> + slice = fls(sseu->slice_mask) - 1;
> + subslice = fls(l3_en & intel_sseu_get_subslices(sseu, slice));
> + }
>   if (!subslice) {
>   drm_warn(&i915->drm,
>"No common index found between subslice mask %x and L3 
> bank mask %x!\n",
>intel_sseu_get_subslices(sseu, slice), l3_en);
> - subslice = fls(l3_en);
> + if (GRAPHICS_VER(i915) == 11)
> + subslice = ffs(l3_en);
> + else
> + subslice = fls(l3_en);
>   drm_WARN_ON(&i915->drm, !subslice);
>   }
>   subslice--;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 45fefa0ed160..d1352ec3546a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4049,9 +4049,13 @@ skl_ddb_entry_for_slices(struct drm_i915_private 
> *dev_priv, u8 slice_mask,
>   ddb->end = 0;
>   return;
>   }
> -
> - ddb->start = (ffs(slice_mask) - 1) * slice_size;
> - ddb->end = fls(slice_mask) * slice_size;
> + if (GRAPHICS_VER(dev_priv) == 11) {
> + ddb->start = (fls(slice_mask) - 1) * slice_size;
> + ddb->end = ffs(slice_mask) * slice_size;
> + } else {
> + ddb->start = (ffs(slice_mask) - 1) * slice_size;
> + ddb->end = fls(slice_mask) * slice_size;
> + }

This code has nothing to do with GT slices.

>  
>   WARN_ON(ddb->start >= ddb->end);
>   WARN_ON(ddb->end > INTEL_INFO(dev_priv)->dbuf.size);
> -- 
> 2.31.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix busy ioctl commentary

[Patchwork]

== Series Details ==

Series: drm/i915: Fix busy ioctl commentary
URL   : https://patchwork.freedesktop.org/series/91394/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212_full -> Patchwork_20345_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-iclb7/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#658])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@feature_discov...@psr2.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-iclb5/igt@feature_discov...@psr2.html

  * igt@gem_create@create-clear:
- shard-glk:  [PASS][4] -> [FAIL][5] ([i915#3160])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk7/igt@gem_cre...@create-clear.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-glk8/igt@gem_cre...@create-clear.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-tglb: [PASS][7] -> [TIMEOUT][8] ([i915#3063])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb5/igt@gem_...@in-flight-contexts-10ms.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-tglb3/igt@gem_...@in-flight-contexts-10ms.html

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

  * igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html

  * igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2842])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-iclb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs1:
- shard-kbl:  [PASS][14] -> [FAIL][15] ([i915#2842])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs1.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][16] -> [FAIL][17] ([i915#2842])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][18] ([i915#2389])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

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

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-glk:  [PASS][20] -> [FAIL][21] ([i915#307]) +1 similar issue
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk9/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-glk9/igt@gem_mmap_...@cpuset-big-copy-xy.html

  * igt@gem_mmap_gtt@cpuset-medium-copy:
- shard-iclb: [PASS][22] -> [FAIL][23] ([i915#307])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb3/igt@gem_mmap_...@cpuset-medium-copy.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-iclb4/igt@gem_mmap_...@cpuset-medium-copy.html

  * igt@gem_render_copy@yf-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][24] ([i915#768])
   [24]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/shard-iclb7/igt@gem_render_c...@yf-tiled-mc-ccs-to-vebox-y-tiled.html

  * igt@gem_userptr_blits@coherency-sync:
  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move system memory to TTM for discrete (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev2)
URL   : https://patchwork.freedesktop.org/series/90898/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212 -> Patchwork_20347


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

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

  
Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-cfl-8109u:   [INCOMPLETE][2] ([i915#3462]) -> [DMESG-FAIL][3] 
([i915#3462])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-cfl-8109u/igt@i915_selftest@l...@execlists.html
- fi-bsw-nick:[DMESG-FAIL][4] ([i915#3462]) -> [INCOMPLETE][5] 
([i915#2782] / [i915#2940] / [i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-bsw-nick/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][6] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][7] ([i915#1436] / [i915#3363])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-skl-6600u/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-skl-6600u/igt@run...@aborted.html
- fi-cfl-8109u:   [FAIL][8] ([i915#3363]) -> [FAIL][9] ([i915#2426] / 
[i915#3363])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-cfl-8109u/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-cfl-8109u/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][10] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][11] ([i915#3363] / [k.org#202321])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-glk-dsi/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][12] ([i915#1436] / [i915#3363]) -> [FAIL][13] 
([i915#1436] / [i915#2426] / [i915#3363])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-soraka/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][14] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][15] ([i915#1436] / [i915#3363])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-guc/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20347/fi-kbl-guc/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (46 -> 39)
--

  Additional (1): fi-jsl-1 
  Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-guc fi-bsw-cyan bat-adlp-4 
bat-adls-4 fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10212 -> Patchwork_20347

  CI-20190529: 20190529
  CI_DRM_10212: d6a4e59ff

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA

[Patchwork]

== Series Details ==

Series: Restricted DMA
URL   : https://patchwork.freedesktop.org/series/91401/
State : failure

== Summary ==

Applying: swiotlb: Refactor swiotlb init functions
Applying: swiotlb: Refactor swiotlb_create_debugfs
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
Applying: swiotlb: Add restricted DMA pool initialization
Applying: swiotlb: Update is_swiotlb_buffer to add a struct device argument
Applying: swiotlb: Update is_swiotlb_active to add a struct device argument
Applying: swiotlb: Bounce data from/to restricted DMA pool if available
Applying: swiotlb: Move alloc_size to find_slots
Applying: swiotlb: Refactor swiotlb_tbl_unmap_single
Applying: dma-direct: Add a new wrapper __dma_direct_free_pages()
Applying: swiotlb: Add restricted DMA alloc/free support.
Applying: dma-direct: Allocate memory from restricted DMA pool if available
Applying: dt-bindings: of: Add restricted DMA pool
Applying: of: Add plumbing for restricted DMA pool
error: sha1 information is lacking or useless (drivers/of/address.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0014 of: Add plumbing for restricted DMA pool
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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Move system memory to TTM for discrete (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Move system memory to TTM for discrete (rev2)
URL   : https://patchwork.freedesktop.org/series/90898/
State : warning

== Summary ==

$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/i915/gem/i915_gem_ttm.c:667:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?
-O:drivers/gpu/drm/i915/gem/i915_gem_ttm.c:564:38: warning: symbol 
'i915_gem_ttm_obj_ops' was not declared. Should it be static?


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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable (rev2)
URL   : https://patchwork.freedesktop.org/series/91372/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212_full -> Patchwork_20344_full


Summary
---

  **SUCCESS**

  No regressions found.

  

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][1] ([fdo#111827])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-iclb8/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][2] -> [SKIP][3] ([i915#658])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@feature_discov...@psr2.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-iclb6/igt@feature_discov...@psr2.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][5] -> [FAIL][6] ([i915#2842])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2849])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2389])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_exec_whisper@basic-fds-forked:
- shard-glk:  [PASS][10] -> [DMESG-WARN][11] ([i915#118] / 
[i915#95])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk7/igt@gem_exec_whis...@basic-fds-forked.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-glk3/igt@gem_exec_whis...@basic-fds-forked.html

  * igt@gem_huc_copy@huc-copy:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#2190])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-iclb8/igt@gem_huc_c...@huc-copy.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-glk:  [PASS][13] -> [FAIL][14] ([i915#307])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk9/igt@gem_mmap_...@big-copy-xy.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-glk2/igt@gem_mmap_...@big-copy-xy.html

  * igt@gem_pread@exhaustion:
- shard-apl:  NOTRUN -> [WARN][15] ([i915#2658])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-apl6/igt@gem_pr...@exhaustion.html

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

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

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3323])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-apl7/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@input-checking:
- shard-apl:  NOTRUN -> [DMESG-WARN][19] ([i915#3002]) +1 similar 
issue
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-apl8/igt@gem_userptr_bl...@input-checking.html

  * igt@gen7_exec_parse@chained-batch:
- shard-iclb: NOTRUN -> [SKIP][20] ([fdo#109289])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-iclb8/igt@gen7_exec_pa...@chained-batch.html

  * igt@gen9_exec_parse@allowed-single:
- shard-skl:  [PASS][21] -> [DMESG-WARN][22] ([i915#1436] / 
[i915#716])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-skl7/igt@gen9_exec_pa...@allowed-single.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/shard-skl5/igt@gen9_exec_pa...@allowed-single.html

  * igt@i915_pm_dc@dc6-psr:
- shard-skl:  [PASS][23] -> [FAIL][24] ([i915#454])
   [23]

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen11: use ffs for minconfig slice/subslice

[Patchwork]

== Series Details ==

Series: drm/i915/gen11: use ffs for minconfig slice/subslice
URL   : https://patchwork.freedesktop.org/series/91398/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212 -> Patchwork_20346


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

  * igt@i915_selftest@live@execlists:
- {fi-ehl-2}: [DMESG-FAIL][1] ([i915#1222]) -> [DMESG-FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-ehl-2/igt@i915_selftest@l...@execlists.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-ehl-2/igt@i915_selftest@l...@execlists.html
- {fi-jsl-1}: NOTRUN -> [DMESG-FAIL][3]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-jsl-1/igt@i915_selftest@l...@execlists.html

  * igt@i915_selftest@live@gt_engines:
- {fi-ehl-2}: [DMESG-FAIL][4] ([i915#1222]) -> [FAIL][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-ehl-2/igt@i915_selftest@live@gt_engines.html
- {fi-jsl-1}: NOTRUN -> [FAIL][6] +1 similar issue
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-jsl-1/igt@i915_selftest@live@gt_engines.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][7] ([i915#2283])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][8] ([i915#3462])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][9] ([fdo#109271]) +5 similar issues
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@i915_module_load@reload:
- {fi-ehl-2}: [DMESG-WARN][10] ([i915#1222]) -> [PASS][11] +33 
similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-ehl-2/igt@i915_module_l...@reload.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-ehl-2/igt@i915_module_l...@reload.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[DMESG-FAIL][12] ([i915#3462]) -> [INCOMPLETE][13] 
([i915#2782] / [i915#2940] / [i915#3462])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-icl-u2:  [INCOMPLETE][14] ([i915#2782] / [i915#3462]) -> 
[DMESG-FAIL][15] ([i915#3462])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-icl-u2/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][16] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][17] ([i915#1436] / [i915#3363])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-skl-6600u/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][18] ([i915#2782] / [i915#3363]) -> [FAIL][19] 
([i915#2426] / [i915#2782] / [i915#3363])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-icl-u2/igt@run...@aborted.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-icl-u2/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][20] ([i915#1602] / [i915#2029]) -> [FAIL][21] 
([i915#3462])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bdw-5557u/igt@run...@aborted.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][22] ([i915#1436] / [i915#3363]) -> [FAIL][23] 
([i915#1436] / [i915#2426] / [i915#3363])
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-soraka/igt@run...@aborted.html
   [23]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20346/fi-kbl-soraka/igt@run...@aborted.html
- fi-cml-u2:  [FAIL][24] ([i915#3

Re: [Intel-gfx] [PATCH] drm/i915: Document the Virtual Engine uAPI

[Daniel Vetter]

On Fri, Jun 11, 2021 at 6:31 PM Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> A little bit of documentation covering the topics of engine discovery,
> context engine maps and virtual engines. It is not very detailed but
> supposed to be a starting point of giving a brief high level overview of
> general principles and intended use cases.
>
> Signed-off-by: Tvrtko Ursulin 

This is great stuff, but I think it'd be better within the uapi
headers and then pulled in. It's not very customary, but you can write
very extensive kerneldoc for an uapi struct, and I think for uapi
that's a pretty good approach. So including all the examples and
everything.

I'm bringing this up and the very next section is the Locking guide.
And clearly that thing did not work out as documentation, I feel like
just dumping lots of docs into i915.rst is a good place for where they
disappear and get forgotten :-(

Thanks, Daniel

> ---
>  Documentation/gpu/i915.rst | 184 +
>  1 file changed, 184 insertions(+)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..8e5ab299c31f 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -335,6 +335,190 @@ for execution also include a list of all locations 
> within buffers that
>  refer to GPU-addresses so that the kernel can edit the buffer correctly.
>  This process is dubbed relocation.
>
> +Engine Discovery uAPI
> +-
> +
> +Engine discovery uAPI is a way of enumerating physical engines present in a 
> GPU
> +associated with an open i915 DRM file descriptor. This supersedes the old 
> way of
> +using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like
> +`I915_PARAM_HAS_BLT`.
> +
> +The need for this interface came starting with Icelake and newer GPUs, which
> +started to establish a pattern of having multiple engines of a same class, 
> where
> +not all instances were always completely functionally equivalent.
> +
> +Entry point for this uapi is `DRM_IOCTL_I915_QUERY` with the
> +`DRM_I915_QUERY_ENGINE_INFO` as the queried item id.
> +
> +Example for getting the list of engines:
> +
> +.. code-block:: C
> +
> +   struct drm_i915_query_engine_info *info;
> +   struct drm_i915_query_item item = {
> +   .query_id = DRM_I915_QUERY_ENGINE_INFO;
> +   };
> +   struct drm_i915_query query = {
> +   .num_items = 1,
> +   .items_ptr = (uintptr_t)&item,
> +   };
> +   int err, i;
> +
> +   // First query the size of the blob we need, this needs to be large
> +   // enough to hold our array of engines. The kernel will fill out the
> +   // item.length for us, which is the number of bytes we need.
> +   //
> +   // Alternatively a large buffer can be allocated straight away 
> enabling
> +   // querying in one pass, in which case item.length should contain the
> +   // length of the provided buffer.
> +   err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query);
> +   if (err) ...
> +
> +   info = calloc(1, item.length);
> +   // Now that we allocated the required number of bytes, we call the 
> ioctl
> +   // again, this time with the data_ptr pointing to our newly allocated
> +   // blob, which the kernel can then populate with info on all engines.
> +   item.data_ptr = (uintptr_t)&info,
> +
> +   err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query);
> +   if (err) ...
> +
> +   // We can now access each engine in the array
> +   for (i = 0; i < info->num_engines; i++) {
> +   struct drm_i915_engine_info einfo = info->engines[i];
> +   u16 class = einfo.engine.class;
> +   u16 instance = einfo.engine.instance;
> +   
> +   }
> +
> +   free(info);
> +
> +Each of the enumerated engines, apart from being defined by its class and
> +instance (see `struct i915_engine_class_instance`), also can have flags and
> +capabilities defined as documented in i915_drm.h.
> +
> +For instance video engines which support HEVC encoding will have the
> +`I915_VIDEO_CLASS_CAPABILITY_HEVC` capability bit set.
> +
> +Engine discovery only fully comes to its own when combined with the new way 
> of
> +addressing engines when submitting batch buffers using contexts with engine
> +maps configured.
> +
> +Context Engine Map uAPI
> +---
> +
> +Context engine map is a new way of addressing engines when submitting batch-
> +buffers, replacing the existing way of using identifiers like `I915_EXEC_BLT`
> +inside the flags field of `struct drm_i915_gem_execbuffer2`.
> +
> +To use it created GEM contexts need to be configured with a list of engines
> +the user is intending to submit to. This is accomplished using the
> +`I915_CONTEXT_PARAM_ENGINES` parameter and `struct 
> i915_context_param_engines`.
> +
> +For such contexts the `I915_EXEC_RING_MASK` field becomes an index into the
> +configured map.
> +
> +Exam

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/ttm: Use TTM for system memory

[Matthew Auld]

On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
 wrote:
>
> For discrete, use TTM for both cached and WC system memory. That means
> we currently rely on the TTM memory accounting / shrinker. For cached
> system memory we should consider remaining shmem-backed, which can be
> implemented from our ttm_tt_populate calback. We can then also reuse our
> own very elaborate shrinker for that memory.
>
> Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix busy ioctl commentary

[Patchwork]

== Series Details ==

Series: drm/i915: Fix busy ioctl commentary
URL   : https://patchwork.freedesktop.org/series/91394/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212 -> Patchwork_20345


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

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

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][2] ([i915#2283])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][3] ([i915#3462])
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][4] ([fdo#109271]) +5 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[DMESG-FAIL][5] ([i915#3462]) -> [INCOMPLETE][6] 
([i915#2782] / [i915#2940] / [i915#3462])
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-icl-u2:  [INCOMPLETE][7] ([i915#2782] / [i915#3462]) -> 
[DMESG-FAIL][8] ([i915#3462])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-icl-u2/igt@i915_selftest@l...@execlists.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-icl-u2/igt@i915_selftest@l...@execlists.html
- fi-cml-s:   [DMESG-FAIL][9] ([i915#3462]) -> [INCOMPLETE][10] 
([i915#3462])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-cml-s/igt@i915_selftest@l...@execlists.html
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-cml-s/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][11] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][12] ([i915#1436] / [i915#3363])
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-skl-6600u/igt@run...@aborted.html
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-skl-6600u/igt@run...@aborted.html
- fi-icl-u2:  [FAIL][13] ([i915#2782] / [i915#3363]) -> [FAIL][14] 
([i915#2426] / [i915#2782] / [i915#3363])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-icl-u2/igt@run...@aborted.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-icl-u2/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][15] ([i915#1602] / [i915#2029]) -> [FAIL][16] 
([i915#3462])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bdw-5557u/igt@run...@aborted.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][17] ([i915#1436] / [i915#3363]) -> [FAIL][18] 
([i915#1436] / [i915#2426] / [i915#3363])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-soraka/igt@run...@aborted.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-guc: [FAIL][19] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][20] ([i915#1436] / [i915#3363])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-guc/igt@run...@aborted.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-kbl-guc/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][21] ([i915#2426] / [i915#3363]) -> [FAIL][22] 
([i915#3363])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-cfl-guc/igt@run...@aborted.html
   [22]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20345/fi-cfl-guc/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?i

[Intel-gfx] [PATCH] drm/i915: Document the Virtual Engine uAPI

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

A little bit of documentation covering the topics of engine discovery,
context engine maps and virtual engines. It is not very detailed but
supposed to be a starting point of giving a brief high level overview of
general principles and intended use cases.

Signed-off-by: Tvrtko Ursulin 
---
 Documentation/gpu/i915.rst | 184 +
 1 file changed, 184 insertions(+)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 42ce0196930a..8e5ab299c31f 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -335,6 +335,190 @@ for execution also include a list of all locations within 
buffers that
 refer to GPU-addresses so that the kernel can edit the buffer correctly.
 This process is dubbed relocation.
 
+Engine Discovery uAPI
+-
+
+Engine discovery uAPI is a way of enumerating physical engines present in a GPU
+associated with an open i915 DRM file descriptor. This supersedes the old way 
of
+using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like
+`I915_PARAM_HAS_BLT`.
+
+The need for this interface came starting with Icelake and newer GPUs, which
+started to establish a pattern of having multiple engines of a same class, 
where
+not all instances were always completely functionally equivalent.
+
+Entry point for this uapi is `DRM_IOCTL_I915_QUERY` with the
+`DRM_I915_QUERY_ENGINE_INFO` as the queried item id.
+
+Example for getting the list of engines:
+
+.. code-block:: C
+
+   struct drm_i915_query_engine_info *info;
+   struct drm_i915_query_item item = {
+   .query_id = DRM_I915_QUERY_ENGINE_INFO;
+   };
+   struct drm_i915_query query = {
+   .num_items = 1,
+   .items_ptr = (uintptr_t)&item,
+   };
+   int err, i;
+
+   // First query the size of the blob we need, this needs to be large
+   // enough to hold our array of engines. The kernel will fill out the
+   // item.length for us, which is the number of bytes we need.
+   //
+   // Alternatively a large buffer can be allocated straight away enabling
+   // querying in one pass, in which case item.length should contain the
+   // length of the provided buffer.
+   err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query);
+   if (err) ...
+
+   info = calloc(1, item.length);
+   // Now that we allocated the required number of bytes, we call the ioctl
+   // again, this time with the data_ptr pointing to our newly allocated
+   // blob, which the kernel can then populate with info on all engines.
+   item.data_ptr = (uintptr_t)&info,
+
+   err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query);
+   if (err) ...
+
+   // We can now access each engine in the array
+   for (i = 0; i < info->num_engines; i++) {
+   struct drm_i915_engine_info einfo = info->engines[i];
+   u16 class = einfo.engine.class;
+   u16 instance = einfo.engine.instance;
+   
+   }
+
+   free(info);
+
+Each of the enumerated engines, apart from being defined by its class and
+instance (see `struct i915_engine_class_instance`), also can have flags and
+capabilities defined as documented in i915_drm.h.
+
+For instance video engines which support HEVC encoding will have the
+`I915_VIDEO_CLASS_CAPABILITY_HEVC` capability bit set.
+
+Engine discovery only fully comes to its own when combined with the new way of
+addressing engines when submitting batch buffers using contexts with engine
+maps configured.
+
+Context Engine Map uAPI
+---
+
+Context engine map is a new way of addressing engines when submitting batch-
+buffers, replacing the existing way of using identifiers like `I915_EXEC_BLT`
+inside the flags field of `struct drm_i915_gem_execbuffer2`.
+
+To use it created GEM contexts need to be configured with a list of engines
+the user is intending to submit to. This is accomplished using the
+`I915_CONTEXT_PARAM_ENGINES` parameter and `struct i915_context_param_engines`.
+
+For such contexts the `I915_EXEC_RING_MASK` field becomes an index into the
+configured map.
+
+Example of creating such context and submitting against it:
+
+.. code-block:: C
+
+   I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 2) = {
+   .engines = { { I915_ENGINE_CLASS_RENDER, 0 },
+{ I915_ENGINE_CLASS_COPY, 0 } }
+   };
+   struct drm_i915_gem_context_create_ext_setparam p_engines = {
+   .base = {
+   .name = I915_CONTEXT_CREATE_EXT_SETPARAM,
+   },
+   .param = {
+   .param = I915_CONTEXT_PARAM_ENGINES,
+   .value = to_user_pointer(&engines),
+   .size = sizeof(engines),
+   },
+   };
+   struct drm_i915_gem_context_create_ext create = {
+   .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS,
+   

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move

[Matthew Auld]

On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
 wrote:
>
> After a TTM move we need to update the i915 gem flags and caching
> settings to reflect the new placement.
> Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
> various ways we previously used to detect this.
> Finally, initialize the TTM object reserved to be able to update
> flags and caching before anyone else gets hold of the object.

Hmm, why do we need to update it after a move? Is it not static? i.e
we just consider the mm.placements/region to determine the correct
domain and cache tracking? Or maybe it doesn't really matter either
way?

>
> Signed-off-by: Thomas Hellström 
> ---
> v2:
> - Style fixes (Reported by Matthew Auld)
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 112 +++-
>  1 file changed, 90 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 33ab47f1e05b..45ef1d101937 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -70,6 +70,17 @@ static struct ttm_placement i915_sys_placement = {
> .busy_placement = &lmem0_sys_placement_flags[1],
>  };
>
> +static bool gpu_binds_iomem(struct ttm_resource *mem)
> +{
> +   return mem->mem_type != TTM_PL_SYSTEM;
> +}
> +
> +static bool cpu_maps_iomem(struct ttm_resource *mem)
> +{
> +   /* Once / if we support GGTT, this is also false for cached ttm_tts */
> +   return mem->mem_type != TTM_PL_SYSTEM;
> +}
> +
>  static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
>
>  static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
> @@ -175,6 +186,41 @@ static void i915_ttm_free_cached_io_st(struct 
> drm_i915_gem_object *obj)
> obj->ttm.cached_io_st = NULL;
>  }
>
> +static void
> +i915_ttm_adjust_domains_after_cpu_move(struct drm_i915_gem_object *obj)
> +{
> +   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> +
> +   if (cpu_maps_iomem(bo->resource) || bo->ttm->caching != ttm_cached) {
> +   obj->write_domain = I915_GEM_DOMAIN_WC;
> +   obj->read_domains = I915_GEM_DOMAIN_WC;
> +   } else {
> +   obj->write_domain = I915_GEM_DOMAIN_CPU;
> +   obj->read_domains = I915_GEM_DOMAIN_CPU;
> +   }
> +}
> +
> +static void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj)
> +{
> +   struct drm_i915_private *i915 = to_i915(obj->base.dev);
> +   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> +   unsigned int cache_level;
> +
> +   obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
> +
> +   obj->mem_flags |= cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM :
> +   I915_BO_FLAG_STRUCT_PAGE;
> +
> +   if ((HAS_LLC(i915) || HAS_SNOOP(i915)) && 
> !gpu_binds_iomem(bo->resource) &&
> +   bo->ttm->caching == ttm_cached) {
> +   cache_level = I915_CACHE_LLC;
> +   } else {
> +   cache_level = I915_CACHE_NONE;
> +   }

Nit: no need for the braces.

> +
> +   i915_gem_object_set_cache_coherency(obj, cache_level);
> +}
> +
>  static void i915_ttm_purge(struct drm_i915_gem_object *obj)
>  {
> struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> @@ -190,8 +236,10 @@ static void i915_ttm_purge(struct drm_i915_gem_object 
> *obj)
>
> /* TTM's purge interface. Note that we might be reentering. */
> ret = ttm_bo_validate(bo, &place, &ctx);
> -
> if (!ret) {
> +   obj->write_domain = 0;
> +   obj->read_domains = 0;
> +   i915_ttm_adjust_gem_after_move(obj);
> i915_ttm_free_cached_io_st(obj);
> obj->mm.madv = __I915_MADV_PURGED;
> }
> @@ -273,12 +321,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object 
> *obj,
>  struct ttm_resource *res)
>  {
> struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> -   struct ttm_resource_manager *man =
> -   ttm_manager_type(bo->bdev, res->mem_type);
>
> -   if (man->use_tt)
> +   if (!gpu_binds_iomem(res))
> return i915_ttm_tt_get_st(bo->ttm);
>
> +   /*
> +* If CPU mapping differs, we need to add the ttm_tt pages to
> +* the resulting st. Might make sense for GGTT.
> +*/
> +   GEM_WARN_ON(!cpu_maps_iomem(res));
> return intel_region_ttm_node_to_st(obj->mm.region, res);
>  }
>
> @@ -290,8 +341,6 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, 
> bool evict,
> struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> struct ttm_resource_manager *dst_man =
> ttm_manager_type(bo->bdev, dst_mem->mem_type);
> -   struct ttm_resource_manager *src_man =
> -   ttm_manager_type(bo->bdev, bo->resource->mem_type);
> struct intel_memory_region *dst_reg, *src_reg;
> union {
>

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/xelpd: Enabling dithering after the CC1

[Patchwork]

== Series Details ==

Series: drm/i915/xelpd: Enabling dithering after the CC1
URL   : https://patchwork.freedesktop.org/series/91383/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10212_full -> Patchwork_20343_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
- shard-skl:  [PASS][1] -> [FAIL][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-skl6/igt@kms_draw_...@draw-method-rgb565-blt-ytiled.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-skl7/igt@kms_draw_...@draw-method-rgb565-blt-ytiled.html

  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk9/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-glk8/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html

  
 Warnings 

  * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled:
- shard-glk:  [FAIL][5] ([i915#3451]) -> [FAIL][6]
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk8/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-glk7/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@drm_mm@all@color_evict_range:
- shard-skl:  [PASS][7] -> [INCOMPLETE][8] ([i915#198] / 
[i915#2485])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-skl1/igt@drm_mm@all@color_evict_range.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-skl5/igt@drm_mm@all@color_evict_range.html

  * igt@feature_discovery@chamelium:
- shard-iclb: NOTRUN -> [SKIP][9] ([fdo#111827])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-iclb5/igt@feature_discov...@chamelium.html

  * igt@feature_discovery@psr2:
- shard-iclb: [PASS][10] -> [SKIP][11] ([i915#658])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb2/igt@feature_discov...@psr2.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-iclb8/igt@feature_discov...@psr2.html

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2410])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-tglb8/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-skl:  [PASS][15] -> [TIMEOUT][16] ([i915#3063])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-skl8/igt@gem_...@in-flight-contexts-10ms.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-skl10/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk:  [PASS][17] -> [FAIL][18] ([i915#2842])
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html

  * igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#2849])
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-iclb1/igt@gem_exec_fair@basic-throt...@rcs0.html

  * igt@gem_exec_reloc@basic-wide-active@vcs1:
- shard-iclb: NOTRUN -> [FAIL][21] ([i915#2389])
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html

  * igt@gem_huc_copy@huc-copy:
- shard-iclb: 

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Update object placement flags to be mutable

[Matthew Auld]

On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
 wrote:
>
> The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
> I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
> much of our code. Introduce a new mem_flags member to hold these
> and make sure checks for these flags being set are either done
> under the object lock or with pages properly pinned. The flags
> will change during migration under the object lock.
>
> Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable (rev2)
URL   : https://patchwork.freedesktop.org/series/91372/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212 -> Patchwork_20344


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

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

  * igt@amdgpu/amd_basic@cs-gfx:
- fi-skl-6700k2:  NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-skl-6700k2/igt@amdgpu/amd_ba...@cs-gfx.html

  * igt@amdgpu/amd_basic@cs-sdma:
- fi-kbl-guc: NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-kbl-guc/igt@amdgpu/amd_ba...@cs-sdma.html
- fi-cfl-8109u:   NOTRUN -> [SKIP][4] ([fdo#109271]) +17 similar issues
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-cfl-8109u/igt@amdgpu/amd_ba...@cs-sdma.html
- fi-kbl-7500u:   NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-kbl-7500u/igt@amdgpu/amd_ba...@cs-sdma.html

  * igt@amdgpu/amd_basic@memory-alloc:
- fi-cml-u2:  NOTRUN -> [SKIP][6] ([fdo#109315]) +17 similar issues
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-cml-u2/igt@amdgpu/amd_ba...@memory-alloc.html

  * igt@amdgpu/amd_basic@query-info:
- fi-bsw-kefka:   NOTRUN -> [SKIP][7] ([fdo#109271]) +17 similar issues
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-bsw-kefka/igt@amdgpu/amd_ba...@query-info.html
- fi-glk-dsi: NOTRUN -> [SKIP][8] ([fdo#109271]) +17 similar issues
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-glk-dsi/igt@amdgpu/amd_ba...@query-info.html
- fi-kbl-8809g:   NOTRUN -> [SKIP][9] ([fdo#109271])
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-kbl-8809g/igt@amdgpu/amd_ba...@query-info.html

  * igt@amdgpu/amd_basic@semaphore:
- fi-icl-y:   NOTRUN -> [SKIP][10] ([fdo#109315]) +17 similar issues
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html
- fi-bsw-nick:NOTRUN -> [SKIP][11] ([fdo#109271]) +17 similar issues
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-bsw-nick/igt@amdgpu/amd_ba...@semaphore.html
- fi-bdw-5557u:   NOTRUN -> [SKIP][12] ([fdo#109271]) +23 similar issues
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html

  * igt@amdgpu/amd_basic@userptr:
- fi-bxt-dsi: NOTRUN -> [SKIP][13] ([fdo#109271]) +17 similar issues
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-bxt-dsi/igt@amdgpu/amd_ba...@userptr.html

  * igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2:  NOTRUN -> [SKIP][14] ([fdo#109315]) +17 similar issues
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-cml-s:   NOTRUN -> [SKIP][15] ([fdo#109315]) +17 similar issues
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-cml-s/igt@amdgpu/amd_cs_...@nop-compute0.html

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

  * igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u:   NOTRUN -> [SKIP][17] ([fdo#109271]) +17 similar issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
- fi-cfl-8700k:   NOTRUN -> [SKIP][18] ([fdo#109271]) +17 similar issues
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html

  * igt@amdgpu/amd_cs_nop@sync-gfx0:
- fi-kbl-7567u:   NOTRUN -> [SKIP][19] ([fdo#109271]) +17 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-kbl-7567u/igt@amdgpu/amd_cs_...@sync-gfx0.html

  * igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-x1275:   NOTRUN -> [SKIP][20] ([fdo#109271]) +17 similar issues
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20344/fi-kbl-x1275/igt@amdgpu/amd_pr...@amd-to-i915.html

  * igt@cor

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/ttm: Calculate the object placement at get_pages time

[Matthew Auld]

On Fri, 11 Jun 2021 at 15:55, Thomas Hellström
 wrote:
>
> Instead of relying on a static placement, calculate at get_pages() time.
> This should work for LMEM regions and system for now. For stolen we need
> to take preallocated range into account. That well be added later.

That will be

>
> Signed-off-by: Thomas Hellström 
> ---
> v2:
> - Fixed a style issue (Reported by Matthew Auld)
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 92 ++---
>  drivers/gpu/drm/i915/intel_region_ttm.c |  8 ++-
>  drivers/gpu/drm/i915/intel_region_ttm.h |  2 +
>  3 files changed, 75 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 45ef1d101937..fd3d11728229 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -24,6 +24,11 @@
>  #define I915_TTM_PRIO_NO_PAGES  1
>  #define I915_TTM_PRIO_HAS_PAGES 2
>
> +/*
> + * Size of struct ttm_place vector in on-stack struct ttm_placement allocs
> + */
> +#define I915_TTM_MAX_PLACEMENTS 10

I915_TTM_MAX_PLACEMENTS INTEL_REGION_UNKNOWN ?

> +
>  /**
>   * struct i915_ttm_tt - TTM page vector with additional private information
>   * @ttm: The base TTM page vector.
> @@ -42,32 +47,18 @@ struct i915_ttm_tt {
> struct sg_table *cached_st;
>  };
>
> -static const struct ttm_place lmem0_sys_placement_flags[] = {
> -   {
> -   .fpfn = 0,
> -   .lpfn = 0,
> -   .mem_type = I915_PL_LMEM0,
> -   .flags = 0,
> -   }, {
> -   .fpfn = 0,
> -   .lpfn = 0,
> -   .mem_type = I915_PL_SYSTEM,
> -   .flags = 0,
> -   }
> -};
> -
> -static struct ttm_placement i915_lmem0_placement = {
> -   .num_placement = 1,
> -   .placement = &lmem0_sys_placement_flags[0],
> -   .num_busy_placement = 1,
> -   .busy_placement = &lmem0_sys_placement_flags[0],
> +static const struct ttm_place sys_placement_flags = {
> +   .fpfn = 0,
> +   .lpfn = 0,
> +   .mem_type = I915_PL_SYSTEM,
> +   .flags = 0,
>  };
>
>  static struct ttm_placement i915_sys_placement = {
> .num_placement = 1,
> -   .placement = &lmem0_sys_placement_flags[1],
> +   .placement = &sys_placement_flags,
> .num_busy_placement = 1,
> -   .busy_placement = &lmem0_sys_placement_flags[1],
> +   .busy_placement = &sys_placement_flags,
>  };
>
>  static bool gpu_binds_iomem(struct ttm_resource *mem)
> @@ -83,6 +74,55 @@ static bool cpu_maps_iomem(struct ttm_resource *mem)
>
>  static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
>
> +static enum ttm_caching
> +i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
> +{
> +   /*
> +* Objects only allowed in system get cached cpu-mappings.
> +* Other objects get WC mapping for now. Even if in system.
> +*/
> +   if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
> +   obj->mm.n_placements <= 1)
> +   return ttm_cached;
> +
> +   return ttm_write_combined;
> +}
> +
> +static void
> +i915_ttm_place_from_region(const struct intel_memory_region *mr,
> +  struct ttm_place *place)
> +{
> +   memset(place, 0, sizeof(*place));
> +   place->mem_type = intel_region_to_ttm_type(mr);
> +}
> +
> +static void
> +i915_ttm_placement_from_obj(const struct drm_i915_gem_object *obj,
> +   struct ttm_place *requested,
> +   struct ttm_place *busy,
> +   struct ttm_placement *placement)
> +{
> +   unsigned int num_allowed = obj->mm.n_placements;
> +   unsigned int i;
> +
> +   placement->num_placement = 1;
> +   i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
> +  obj->mm.region, requested);
> +
> +   /* Cache this on object? */
> +   placement->num_busy_placement = num_allowed;
> +   for (i = 0; i < placement->num_busy_placement; ++i)
> +   i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
> +
> +   if (num_allowed == 0) {
> +   *busy = *requested;
> +   placement->num_busy_placement = 1;
> +   }
> +
> +   placement->placement = requested;
> +   placement->busy_placement = busy;
> +}
> +
>  static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
>  uint32_t page_flags)
>  {
> @@ -100,7 +140,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
> ttm_buffer_object *bo,
> man->use_tt)
> page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
>
> -   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, ttm_write_combined);
> +   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
> + i915_ttm_select_tt_caching(obj));
> if (ret) {
> kfree(i915_tt);
>

Re: [Intel-gfx] [PATCH v9 06/14] swiotlb: Update is_swiotlb_active to add a struct device argument

[Claire Chang]

I don't have the HW to verify the change. Hopefully I use the right
device struct for is_swiotlb_active.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v9 03/14] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used

[Claire Chang]

I'm not sure if this would break arch/x86/pci/sta2x11-fixup.c
swiotlb_late_init_with_default_size is called here
https://elixir.bootlin.com/linux/v5.13-rc5/source/arch/x86/pci/sta2x11-fixup.c#L60

On Fri, Jun 11, 2021 at 11:27 PM Claire Chang  wrote:
>
> Always have the pointer to the swiotlb pool used in struct device. This
> could help simplify the code for other pools.
>
> Signed-off-by: Claire Chang 
> ---
>  drivers/of/device.c | 3 +++
>  include/linux/device.h  | 4 
>  include/linux/swiotlb.h | 8 
>  kernel/dma/swiotlb.c| 8 
>  4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index c5a9473a5fb1..1defdf15ba95 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -165,6 +165,9 @@ int of_dma_configure_id(struct device *dev, struct 
> device_node *np,
>
> arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
>
> +   if (IS_ENABLED(CONFIG_SWIOTLB))
> +   swiotlb_set_io_tlb_default_mem(dev);
> +
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_configure_id);
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 4443e12238a0..2e9a378c9100 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -432,6 +432,7 @@ struct dev_links_info {
>   * @dma_pools: Dma pools (if dma'ble device).
>   * @dma_mem:   Internal for coherent mem override.
>   * @cma_area:  Contiguous memory area for dma allocations
> + * @dma_io_tlb_mem: Pointer to the swiotlb pool used.  Not for driver use.
>   * @archdata:  For arch-specific additions.
>   * @of_node:   Associated device tree node.
>   * @fwnode:Associated device node supplied by platform firmware.
> @@ -540,6 +541,9 @@ struct device {
>  #ifdef CONFIG_DMA_CMA
> struct cma *cma_area;   /* contiguous memory area for dma
>allocations */
> +#endif
> +#ifdef CONFIG_SWIOTLB
> +   struct io_tlb_mem *dma_io_tlb_mem;
>  #endif
> /* arch specific additions */
> struct dev_archdata archdata;
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 216854a5e513..008125ccd509 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -108,6 +108,11 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
> return mem && paddr >= mem->start && paddr < mem->end;
>  }
>
> +static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
> +{
> +   dev->dma_io_tlb_mem = io_tlb_default_mem;
> +}
> +
>  void __init swiotlb_exit(void);
>  unsigned int swiotlb_max_segment(void);
>  size_t swiotlb_max_mapping_size(struct device *dev);
> @@ -119,6 +124,9 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
>  {
> return false;
>  }
> +static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
> +{
> +}
>  static inline void swiotlb_exit(void)
>  {
>  }
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 8a3e2b3b246d..29b950ab1351 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -344,7 +344,7 @@ void __init swiotlb_exit(void)
>  static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t 
> size,
>enum dma_data_direction dir)
>  {
> -   struct io_tlb_mem *mem = io_tlb_default_mem;
> +   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
> phys_addr_t orig_addr = mem->slots[index].orig_addr;
> size_t alloc_size = mem->slots[index].alloc_size;
> @@ -426,7 +426,7 @@ static unsigned int wrap_index(struct io_tlb_mem *mem, 
> unsigned int index)
>  static int find_slots(struct device *dev, phys_addr_t orig_addr,
> size_t alloc_size)
>  {
> -   struct io_tlb_mem *mem = io_tlb_default_mem;
> +   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> unsigned long boundary_mask = dma_get_seg_boundary(dev);
> dma_addr_t tbl_dma_addr =
> phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
> @@ -503,7 +503,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, 
> phys_addr_t orig_addr,
> size_t mapping_size, size_t alloc_size,
> enum dma_data_direction dir, unsigned long attrs)
>  {
> -   struct io_tlb_mem *mem = io_tlb_default_mem;
> +   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> unsigned int offset = swiotlb_align_offset(dev, orig_addr);
> unsigned int i;
> int index;
> @@ -554,7 +554,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, 
> phys_addr_t tlb_addr,
>   size_t mapping_size, enum dma_data_direction 
> dir,
>   unsigned long attrs)
>  {
> -   struct io_tlb_mem *mem = io_tlb_default_mem;
> +   struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
> unsigned long flags;
> unsigned int offset = swiotlb_align_

Re: [Intel-gfx] [PATCH v8 00/15] Restricted DMA

[Claire Chang]

v9 here: https://lore.kernel.org/patchwork/cover/1445081/

On Mon, Jun 7, 2021 at 11:28 AM Claire Chang  wrote:
>
> On Sat, Jun 5, 2021 at 1:48 AM Will Deacon  wrote:
> >
> > Hi Claire,
> >
> > On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote:
> > > This series implements mitigations for lack of DMA access control on
> > > systems without an IOMMU, which could result in the DMA accessing the
> > > system memory at unexpected times and/or unexpected addresses, possibly
> > > leading to data leakage or corruption.
> > >
> > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is
> > > not behind an IOMMU. As PCI-e, by design, gives the device full access to
> > > system memory, a vulnerability in the Wi-Fi firmware could easily escalate
> > > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a
> > > full chain of exploits; [2], [3]).
> > >
> > > To mitigate the security concerns, we introduce restricted DMA. Restricted
> > > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a
> > > specially allocated region and does memory allocation from the same 
> > > region.
> > > The feature on its own provides a basic level of protection against the 
> > > DMA
> > > overwriting buffer contents at unexpected times. However, to protect
> > > against general data leakage and system memory corruption, the system 
> > > needs
> > > to provide a way to restrict the DMA to a predefined memory region (this 
> > > is
> > > usually done at firmware level, e.g. MPU in ATF on some ARM platforms 
> > > [4]).
> > >
> > > [1a] 
> > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
> > > [1b] 
> > > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
> > > [2] https://blade.tencent.com/en/advisories/qualpwn/
> > > [3] 
> > > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/
> > > [4] 
> > > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132
> > >
> > > v8:
> > > - Fix reserved-memory.txt and add the reg property in example.
> > > - Fix sizeof for of_property_count_elems_of_size in
> > >   drivers/of/address.c#of_dma_set_restricted_buffer.
> > > - Apply Will's suggestion to try the OF node having DMA configuration in
> > >   drivers/of/address.c#of_dma_set_restricted_buffer.
> > > - Fix typo in the comment of 
> > > drivers/of/address.c#of_dma_set_restricted_buffer.
> > > - Add error message for PageHighMem in
> > >   kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to
> > >   rmem_swiotlb_setup.
> > > - Fix the message string in rmem_swiotlb_setup.
> >
> > Thanks for the v8. It works for me out of the box on arm64 under KVM, so:
> >
> > Tested-by: Will Deacon 
> >
> > Note that something seems to have gone wrong with the mail threading, so
> > the last 5 patches ended up as a separate thread for me. Probably worth
> > posting again with all the patches in one place, if you can.
>
> Thanks for testing.
>
> Christoph also added some comments in v7, so I'll prepare v9.
>
> >
> > Cheers,
> >
> > Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v9 14/14] of: Add plumbing for restricted DMA pool

[Claire Chang]

If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.

Signed-off-by: Claire Chang 
---
 drivers/of/address.c| 33 +
 drivers/of/device.c |  3 +++
 drivers/of/of_private.h |  6 ++
 3 files changed, 42 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 3b2acca7e363..c8066d95ff0e 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1001,6 +1002,38 @@ int of_dma_get_range(struct device_node *np, const 
struct bus_dma_region **map)
of_node_put(node);
return ret;
 }
+
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np)
+{
+   struct device_node *node, *of_node = dev->of_node;
+   int count, i;
+
+   count = of_property_count_elems_of_size(of_node, "memory-region",
+   sizeof(u32));
+   /*
+* If dev->of_node doesn't exist or doesn't contain memory-region, try
+* the OF node having DMA configuration.
+*/
+   if (count <= 0) {
+   of_node = np;
+   count = of_property_count_elems_of_size(
+   of_node, "memory-region", sizeof(u32));
+   }
+
+   for (i = 0; i < count; i++) {
+   node = of_parse_phandle(of_node, "memory-region", i);
+   /*
+* There might be multiple memory regions, but only one
+* restricted-dma-pool region is allowed.
+*/
+   if (of_device_is_compatible(node, "restricted-dma-pool") &&
+   of_device_is_available(node))
+   return of_reserved_mem_device_init_by_idx(dev, of_node,
+ i);
+   }
+
+   return 0;
+}
 #endif /* CONFIG_HAS_DMA */
 
 /**
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1defdf15ba95..ba4656e77502 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -168,6 +168,9 @@ int of_dma_configure_id(struct device *dev, struct 
device_node *np,
if (IS_ENABLED(CONFIG_SWIOTLB))
swiotlb_set_io_tlb_default_mem(dev);
 
+   if (!iommu)
+   return of_dma_set_restricted_buffer(dev, np);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(of_dma_configure_id);
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 631489f7f8c0..376462798f7e 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -163,12 +163,18 @@ struct bus_dma_region;
 #if defined(CONFIG_OF_ADDRESS) && defined(CONFIG_HAS_DMA)
 int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map);
+int of_dma_set_restricted_buffer(struct device *dev, struct device_node *np);
 #else
 static inline int of_dma_get_range(struct device_node *np,
const struct bus_dma_region **map)
 {
return -ENODEV;
 }
+static inline int of_dma_set_restricted_buffer(struct device *dev,
+  struct device_node *np)
+{
+   return -ENODEV;
+}
 #endif
 
 void fdt_init_reserved_mem(void);
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 13/14] dt-bindings: of: Add restricted DMA pool

[Claire Chang]

Introduce the new compatible string, restricted-dma-pool, for restricted
DMA. One can specify the address and length of the restricted DMA memory
region by restricted-dma-pool in the reserved-memory node.

Signed-off-by: Claire Chang 
---
 .../reserved-memory/reserved-memory.txt   | 36 +--
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt 
b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
index e8d3096d922c..46804f24df05 100644
--- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -51,6 +51,23 @@ compatible (optional) - standard definition
   used as a shared pool of DMA buffers for a set of devices. It can
   be used by an operating system to instantiate the necessary pool
   management subsystem if necessary.
+- restricted-dma-pool: This indicates a region of memory meant to be
+  used as a pool of restricted DMA buffers for a set of devices. The
+  memory region would be the only region accessible to those devices.
+  When using this, the no-map and reusable properties must not be set,
+  so the operating system can create a virtual mapping that will be 
used
+  for synchronization. The main purpose for restricted DMA is to
+  mitigate the lack of DMA access control on systems without an IOMMU,
+  which could result in the DMA accessing the system memory at
+  unexpected times and/or unexpected addresses, possibly leading to 
data
+  leakage or corruption. The feature on its own provides a basic level
+  of protection against the DMA overwriting buffer contents at
+  unexpected times. However, to protect against general data leakage 
and
+  system memory corruption, the system needs to provide way to lock 
down
+  the memory access, e.g., MPU. Note that since coherent allocation
+  needs remapping, one must set up another device coherent pool by
+  shared-dma-pool and use dma_alloc_from_dev_coherent instead for 
atomic
+  coherent allocation.
 - vendor specific string in the form ,[-]
 no-map (optional) - empty property
 - Indicates the operating system must not create a virtual mapping
@@ -85,10 +102,11 @@ memory-region-names (optional) - a list of names, one for 
each corresponding
 
 Example
 ---
-This example defines 3 contiguous regions are defined for Linux kernel:
+This example defines 4 contiguous regions for Linux kernel:
 one default of all device drivers (named linux,cma@7200 and 64MiB in size),
-one dedicated to the framebuffer device (named framebuffer@7800, 8MiB), and
-one for multimedia processing (named multimedia-memory@7700, 64MiB).
+one dedicated to the framebuffer device (named framebuffer@7800, 8MiB),
+one for multimedia processing (named multimedia-memory@7700, 64MiB), and
+one for restricted dma pool (named restricted_dma_reserved@0x5000, 64MiB).
 
 / {
#address-cells = <1>;
@@ -120,6 +138,11 @@ one for multimedia processing (named 
multimedia-memory@7700, 64MiB).
compatible = "acme,multimedia-memory";
reg = <0x7700 0x400>;
};
+
+   restricted_dma_reserved: restricted_dma_reserved {
+   compatible = "restricted-dma-pool";
+   reg = <0x5000 0x400>;
+   };
};
 
/* ... */
@@ -138,4 +161,11 @@ one for multimedia processing (named 
multimedia-memory@7700, 64MiB).
memory-region = <&multimedia_reserved>;
/* ... */
};
+
+   pcie_device: pcie_device@0,0 {
+   reg = <0x8301 0x0 0x 0x0 0x0010
+  0x8301 0x0 0x0010 0x0 0x0010>;
+   memory-region = <&restricted_dma_mem_reserved>;
+   /* ... */
+   };
 };
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 12/14] dma-direct: Allocate memory from restricted DMA pool if available

[Claire Chang]

The restricted DMA pool is preferred if available.

The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock down the memory access, e.g., MPU.

Note that since coherent allocation needs remapping, one must set up
another device coherent pool by shared-dma-pool and use
dma_alloc_from_dev_coherent instead for atomic coherent allocation.

Signed-off-by: Claire Chang 
---
 kernel/dma/direct.c | 37 -
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index eb4098323bbc..73fc4c659ba7 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -78,6 +78,9 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t 
phys, size_t size)
 static void __dma_direct_free_pages(struct device *dev, struct page *page,
size_t size)
 {
+   if (IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL) &&
+   swiotlb_free(dev, page, size))
+   return;
dma_free_contiguous(dev, page, size);
 }
 
@@ -92,7 +95,17 @@ static struct page *__dma_direct_alloc_pages(struct device 
*dev, size_t size,
 
gfp |= dma_direct_optimal_gfp_mask(dev, dev->coherent_dma_mask,
   &phys_limit);
-   page = dma_alloc_contiguous(dev, size, gfp);
+   if (IS_ENABLED(CONFIG_DMA_RESTRICTED_POOL)) {
+   page = swiotlb_alloc(dev, size);
+   if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
+   __dma_direct_free_pages(dev, page, size);
+   page = NULL;
+   }
+   return page;
+   }
+
+   if (!page)
+   page = dma_alloc_contiguous(dev, size, gfp);
if (page && !dma_coherent_ok(dev, page_to_phys(page), size)) {
dma_free_contiguous(dev, page, size);
page = NULL;
@@ -148,7 +161,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
gfp |= __GFP_NOWARN;
 
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
-   !force_dma_unencrypted(dev)) {
+   !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO);
if (!page)
return NULL;
@@ -161,18 +174,23 @@ void *dma_direct_alloc(struct device *dev, size_t size,
}
 
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
-   !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
-   !dev_is_dma_coherent(dev))
+   !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+   !is_dev_swiotlb_force(dev))
return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);
 
/*
 * Remapping or decrypting memory may block. If either is required and
 * we can't block, allocate the memory from the atomic pools.
+* If restricted DMA (i.e., is_dev_swiotlb_force) is required, one must
+* set up another device coherent pool by shared-dma-pool and use
+* dma_alloc_from_dev_coherent instead.
 */
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
!gfpflags_allow_blocking(gfp) &&
(force_dma_unencrypted(dev) ||
-(IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && 
!dev_is_dma_coherent(dev
+(IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
+ !dev_is_dma_coherent(dev))) &&
+   !is_dev_swiotlb_force(dev))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
 
/* we always manually zero the memory once we are done */
@@ -253,15 +271,15 @@ void dma_direct_free(struct device *dev, size_t size,
unsigned int page_order = get_order(size);
 
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
-   !force_dma_unencrypted(dev)) {
+   !force_dma_unencrypted(dev) && !is_dev_swiotlb_force(dev)) {
/* cpu_addr is a struct page cookie, not a kernel address */
dma_free_contiguous(dev, cpu_addr, size);
return;
}
 
if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
-   !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
-   !dev_is_dma_coherent(dev)) {
+   !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && !dev_is_dma_coherent(dev) &&
+   !is_dev_swiotlb_force(dev)) {
arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
return;
}
@@ -289,7 +307,8 @@ struct page *dma_direct_alloc_pages(struct device *dev, 
size_t size,
void *ret;
 
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
-   force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp))
+   force_dma_unencrypted(dev) && !gfpflags_allow_blocking(gfp) &&
+  

[Intel-gfx] [PATCH v9 11/14] swiotlb: Add restricted DMA alloc/free support.

[Claire Chang]

Add the functions, swiotlb_{alloc,free} to support the memory allocation
from restricted DMA pool.

Signed-off-by: Claire Chang 
---
 include/linux/swiotlb.h | 15 +++
 kernel/dma/swiotlb.c| 35 +--
 2 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 8200c100fe10..d3374497a4f8 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -162,4 +162,19 @@ static inline void swiotlb_adjust_size(unsigned long size)
 extern void swiotlb_print_info(void);
 extern void swiotlb_set_max_segment(unsigned int);
 
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+struct page *swiotlb_alloc(struct device *dev, size_t size);
+bool swiotlb_free(struct device *dev, struct page *page, size_t size);
+#else
+static inline struct page *swiotlb_alloc(struct device *dev, size_t size)
+{
+   return NULL;
+}
+static inline bool swiotlb_free(struct device *dev, struct page *page,
+   size_t size)
+{
+   return false;
+}
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
+
 #endif /* __LINUX_SWIOTLB_H */
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index a6562573f090..0a19858da5b8 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -461,8 +461,9 @@ static int find_slots(struct device *dev, phys_addr_t 
orig_addr,
 
index = wrap = wrap_index(mem, ALIGN(mem->index, stride));
do {
-   if ((slot_addr(tbl_dma_addr, index) & iotlb_align_mask) !=
-   (orig_addr & iotlb_align_mask)) {
+   if (orig_addr &&
+   (slot_addr(tbl_dma_addr, index) & iotlb_align_mask) !=
+   (orig_addr & iotlb_align_mask)) {
index = wrap_index(mem, index + 1);
continue;
}
@@ -702,6 +703,36 @@ late_initcall(swiotlb_create_default_debugfs);
 #endif
 
 #ifdef CONFIG_DMA_RESTRICTED_POOL
+struct page *swiotlb_alloc(struct device *dev, size_t size)
+{
+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
+   phys_addr_t tlb_addr;
+   int index;
+
+   if (!mem)
+   return NULL;
+
+   index = find_slots(dev, 0, size);
+   if (index == -1)
+   return NULL;
+
+   tlb_addr = slot_addr(mem->start, index);
+
+   return pfn_to_page(PFN_DOWN(tlb_addr));
+}
+
+bool swiotlb_free(struct device *dev, struct page *page, size_t size)
+{
+   phys_addr_t tlb_addr = page_to_phys(page);
+
+   if (!is_swiotlb_buffer(dev, tlb_addr))
+   return false;
+
+   release_slots(dev, tlb_addr);
+
+   return true;
+}
+
 static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
struct device *dev)
 {
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 10/14] dma-direct: Add a new wrapper __dma_direct_free_pages()

[Claire Chang]

Add a new wrapper __dma_direct_free_pages() that will be useful later
for swiotlb_free().

Signed-off-by: Claire Chang 
---
 kernel/dma/direct.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 078f7087e466..eb4098323bbc 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -75,6 +75,12 @@ static bool dma_coherent_ok(struct device *dev, phys_addr_t 
phys, size_t size)
min_not_zero(dev->coherent_dma_mask, dev->bus_dma_limit);
 }
 
+static void __dma_direct_free_pages(struct device *dev, struct page *page,
+   size_t size)
+{
+   dma_free_contiguous(dev, page, size);
+}
+
 static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
gfp_t gfp)
 {
@@ -237,7 +243,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
return NULL;
}
 out_free_pages:
-   dma_free_contiguous(dev, page, size);
+   __dma_direct_free_pages(dev, page, size);
return NULL;
 }
 
@@ -273,7 +279,7 @@ void dma_direct_free(struct device *dev, size_t size,
else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
arch_dma_clear_uncached(cpu_addr, size);
 
-   dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size);
+   __dma_direct_free_pages(dev, dma_direct_to_page(dev, dma_addr), size);
 }
 
 struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
@@ -310,7 +316,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, 
size_t size,
*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
return page;
 out_free_pages:
-   dma_free_contiguous(dev, page, size);
+   __dma_direct_free_pages(dev, page, size);
return NULL;
 }
 
@@ -329,7 +335,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
if (force_dma_unencrypted(dev))
set_memory_encrypted((unsigned long)vaddr, 1 << page_order);
 
-   dma_free_contiguous(dev, page, size);
+   __dma_direct_free_pages(dev, page, size);
 }
 
 #if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 09/14] swiotlb: Refactor swiotlb_tbl_unmap_single

[Claire Chang]

Add a new function, release_slots, to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.

Signed-off-by: Claire Chang 
---
 kernel/dma/swiotlb.c | 35 ---
 1 file changed, 20 insertions(+), 15 deletions(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 364c6c822063..a6562573f090 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -554,27 +554,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, 
phys_addr_t orig_addr,
return tlb_addr;
 }
 
-/*
- * tlb_addr is the physical address of the bounce buffer to unmap.
- */
-void swiotlb_tbl_unmap_single(struct device *hwdev, phys_addr_t tlb_addr,
- size_t mapping_size, enum dma_data_direction dir,
- unsigned long attrs)
+static void release_slots(struct device *dev, phys_addr_t tlb_addr)
 {
-   struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long flags;
-   unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
+   unsigned int offset = swiotlb_align_offset(dev, tlb_addr);
int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
int nslots = nr_slots(mem->slots[index].alloc_size + offset);
int count, i;
 
-   /*
-* First, sync the memory before unmapping the entry
-*/
-   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
-   (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
-   swiotlb_bounce(hwdev, tlb_addr, mapping_size, DMA_FROM_DEVICE);
-
/*
 * Return the buffer to the free list by setting the corresponding
 * entries to indicate the number of contiguous entries available.
@@ -609,6 +597,23 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, 
phys_addr_t tlb_addr,
spin_unlock_irqrestore(&mem->lock, flags);
 }
 
+/*
+ * tlb_addr is the physical address of the bounce buffer to unmap.
+ */
+void swiotlb_tbl_unmap_single(struct device *dev, phys_addr_t tlb_addr,
+ size_t mapping_size, enum dma_data_direction dir,
+ unsigned long attrs)
+{
+   /*
+* First, sync the memory before unmapping the entry
+*/
+   if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
+   (dir == DMA_FROM_DEVICE || dir == DMA_BIDIRECTIONAL))
+   swiotlb_bounce(dev, tlb_addr, mapping_size, DMA_FROM_DEVICE);
+
+   release_slots(dev, tlb_addr);
+}
+
 void swiotlb_sync_single_for_device(struct device *dev, phys_addr_t tlb_addr,
size_t size, enum dma_data_direction dir)
 {
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 08/14] swiotlb: Move alloc_size to find_slots

[Claire Chang]

Move the maintenance of alloc_size to find_slots for better code
reusability later.

Signed-off-by: Claire Chang 
---
 kernel/dma/swiotlb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e5ccc198d0a7..364c6c822063 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -486,8 +486,11 @@ static int find_slots(struct device *dev, phys_addr_t 
orig_addr,
return -1;
 
 found:
-   for (i = index; i < index + nslots; i++)
+   for (i = index; i < index + nslots; i++) {
mem->slots[i].list = 0;
+   mem->slots[i].alloc_size =
+   alloc_size - ((i - index) << IO_TLB_SHIFT);
+   }
for (i = index - 1;
 io_tlb_offset(i) != IO_TLB_SEGSIZE - 1 &&
 mem->slots[i].list; i--)
@@ -542,11 +545,8 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, 
phys_addr_t orig_addr,
 * This is needed when we sync the memory.  Then we sync the buffer if
 * needed.
 */
-   for (i = 0; i < nr_slots(alloc_size + offset); i++) {
+   for (i = 0; i < nr_slots(alloc_size + offset); i++)
mem->slots[index + i].orig_addr = slot_addr(orig_addr, i);
-   mem->slots[index + i].alloc_size =
-   alloc_size - (i << IO_TLB_SHIFT);
-   }
tlb_addr = slot_addr(mem->start, index) + offset;
if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
(dir == DMA_TO_DEVICE || dir == DMA_BIDIRECTIONAL))
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 07/14] swiotlb: Bounce data from/to restricted DMA pool if available

[Claire Chang]

Regardless of swiotlb setting, the restricted DMA pool is preferred if
available.

The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system
needs to provide a way to lock down the memory access, e.g., MPU.

Note that is_dev_swiotlb_force doesn't check if
swiotlb_force == SWIOTLB_FORCE. Otherwise the memory allocation behavior
with default swiotlb will be changed by the following patche
("dma-direct: Allocate memory from restricted DMA pool if available").

Signed-off-by: Claire Chang 
---
 include/linux/swiotlb.h | 10 +-
 kernel/dma/direct.c |  3 ++-
 kernel/dma/direct.h |  3 ++-
 kernel/dma/swiotlb.c|  1 +
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 06cf17a80f5c..8200c100fe10 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -85,6 +85,7 @@ extern enum swiotlb_force swiotlb_force;
  * unmap calls.
  * @debugfs:   The dentry to debugfs.
  * @late_alloc:%true if allocated using the page allocator
+ * @force_swiotlb: %true if swiotlb is forced
  */
 struct io_tlb_mem {
phys_addr_t start;
@@ -95,6 +96,7 @@ struct io_tlb_mem {
spinlock_t lock;
struct dentry *debugfs;
bool late_alloc;
+   bool force_swiotlb;
struct io_tlb_slot {
phys_addr_t orig_addr;
size_t alloc_size;
@@ -115,6 +117,11 @@ static inline void swiotlb_set_io_tlb_default_mem(struct 
device *dev)
dev->dma_io_tlb_mem = io_tlb_default_mem;
 }
 
+static inline bool is_dev_swiotlb_force(struct device *dev)
+{
+   return dev->dma_io_tlb_mem->force_swiotlb;
+}
+
 void __init swiotlb_exit(void);
 unsigned int swiotlb_max_segment(void);
 size_t swiotlb_max_mapping_size(struct device *dev);
@@ -126,8 +133,9 @@ static inline bool is_swiotlb_buffer(struct device *dev, 
phys_addr_t paddr)
 {
return false;
 }
-static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
+static inline bool is_dev_swiotlb_force(struct device *dev)
 {
+   return false;
 }
 static inline void swiotlb_exit(void)
 {
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 7a88c34d0867..078f7087e466 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -496,7 +496,8 @@ size_t dma_direct_max_mapping_size(struct device *dev)
 {
/* If SWIOTLB is active, use its maximum mapping size */
if (is_swiotlb_active(dev) &&
-   (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
+   (dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE ||
+is_dev_swiotlb_force(dev)))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
 }
diff --git a/kernel/dma/direct.h b/kernel/dma/direct.h
index 13e9e7158d94..f94813674e23 100644
--- a/kernel/dma/direct.h
+++ b/kernel/dma/direct.h
@@ -87,7 +87,8 @@ static inline dma_addr_t dma_direct_map_page(struct device 
*dev,
phys_addr_t phys = page_to_phys(page) + offset;
dma_addr_t dma_addr = phys_to_dma(dev, phys);
 
-   if (unlikely(swiotlb_force == SWIOTLB_FORCE))
+   if (unlikely(swiotlb_force == SWIOTLB_FORCE) ||
+   is_dev_swiotlb_force(dev))
return swiotlb_map(dev, phys, size, dir, attrs);
 
if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 21e99907edd6..e5ccc198d0a7 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -714,6 +714,7 @@ static int rmem_swiotlb_device_init(struct reserved_mem 
*rmem,
return -ENOMEM;
 
swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false, true);
+   mem->force_swiotlb = true;
 
rmem->priv = mem;
 
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 06/14] swiotlb: Update is_swiotlb_active to add a struct device argument

[Claire Chang]

Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.

Signed-off-by: Claire Chang 
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
 drivers/pci/xen-pcifront.c   | 2 +-
 include/linux/swiotlb.h  | 4 ++--
 kernel/dma/direct.c  | 2 +-
 kernel/dma/swiotlb.c | 4 ++--
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ce6b664b10aa..89a894354263 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -42,7 +42,7 @@ static int i915_gem_object_get_pages_internal(struct 
drm_i915_gem_object *obj)
 
max_order = MAX_ORDER;
 #ifdef CONFIG_SWIOTLB
-   if (is_swiotlb_active()) {
+   if (is_swiotlb_active(obj->base.dev->dev)) {
unsigned int max_segment;
 
max_segment = swiotlb_max_segment();
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index f4c2e46b6fe1..2ca9d9a9e5d5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -276,7 +276,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
}
 
 #if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
-   need_swiotlb = is_swiotlb_active();
+   need_swiotlb = is_swiotlb_active(dev->dev);
 #endif
 
ret = ttm_device_init(&drm->ttm.bdev, &nouveau_bo_driver, drm->dev->dev,
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b7a8f3a1921f..0d56985bfe81 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -693,7 +693,7 @@ static int pcifront_connect_and_init_dma(struct 
pcifront_device *pdev)
 
spin_unlock(&pcifront_dev_lock);
 
-   if (!err && !is_swiotlb_active()) {
+   if (!err && !is_swiotlb_active(&pdev->xdev->dev)) {
err = pci_xen_swiotlb_init_late();
if (err)
dev_err(&pdev->xdev->dev, "Could not setup SWIOTLB!\n");
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 921b469c6ad2..06cf17a80f5c 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -118,7 +118,7 @@ static inline void swiotlb_set_io_tlb_default_mem(struct 
device *dev)
 void __init swiotlb_exit(void);
 unsigned int swiotlb_max_segment(void);
 size_t swiotlb_max_mapping_size(struct device *dev);
-bool is_swiotlb_active(void);
+bool is_swiotlb_active(struct device *dev);
 void __init swiotlb_adjust_size(unsigned long size);
 #else
 #define swiotlb_force SWIOTLB_NO_FORCE
@@ -141,7 +141,7 @@ static inline size_t swiotlb_max_mapping_size(struct device 
*dev)
return SIZE_MAX;
 }
 
-static inline bool is_swiotlb_active(void)
+static inline bool is_swiotlb_active(struct device *dev)
 {
return false;
 }
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 84c9feb5474a..7a88c34d0867 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -495,7 +495,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
 size_t dma_direct_max_mapping_size(struct device *dev)
 {
/* If SWIOTLB is active, use its maximum mapping size */
-   if (is_swiotlb_active() &&
+   if (is_swiotlb_active(dev) &&
(dma_addressing_limited(dev) || swiotlb_force == SWIOTLB_FORCE))
return swiotlb_max_mapping_size(dev);
return SIZE_MAX;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index c4a071d6a63f..21e99907edd6 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -666,9 +666,9 @@ size_t swiotlb_max_mapping_size(struct device *dev)
return ((size_t)IO_TLB_SIZE) * IO_TLB_SEGSIZE;
 }
 
-bool is_swiotlb_active(void)
+bool is_swiotlb_active(struct device *dev)
 {
-   return io_tlb_default_mem != NULL;
+   return dev->dma_io_tlb_mem != NULL;
 }
 EXPORT_SYMBOL_GPL(is_swiotlb_active);
 
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 05/14] swiotlb: Update is_swiotlb_buffer to add a struct device argument

[Claire Chang]

Update is_swiotlb_buffer to add a struct device argument. This will be
useful later to allow for restricted DMA pool.

Signed-off-by: Claire Chang 
---
 drivers/iommu/dma-iommu.c | 12 ++--
 drivers/xen/swiotlb-xen.c |  2 +-
 include/linux/swiotlb.h   |  7 ---
 kernel/dma/direct.c   |  6 +++---
 kernel/dma/direct.h   |  6 +++---
 5 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5d96fcc45fec..1a6a08908245 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -506,7 +506,7 @@ static void __iommu_dma_unmap_swiotlb(struct device *dev, 
dma_addr_t dma_addr,
 
__iommu_dma_unmap(dev, dma_addr, size);
 
-   if (unlikely(is_swiotlb_buffer(phys)))
+   if (unlikely(is_swiotlb_buffer(dev, phys)))
swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
 }
 
@@ -577,7 +577,7 @@ static dma_addr_t __iommu_dma_map_swiotlb(struct device 
*dev, phys_addr_t phys,
}
 
iova = __iommu_dma_map(dev, phys, aligned_size, prot, dma_mask);
-   if (iova == DMA_MAPPING_ERROR && is_swiotlb_buffer(phys))
+   if (iova == DMA_MAPPING_ERROR && is_swiotlb_buffer(dev, phys))
swiotlb_tbl_unmap_single(dev, phys, org_size, dir, attrs);
return iova;
 }
@@ -783,7 +783,7 @@ static void iommu_dma_sync_single_for_cpu(struct device 
*dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(phys, size, dir);
 
-   if (is_swiotlb_buffer(phys))
+   if (is_swiotlb_buffer(dev, phys))
swiotlb_sync_single_for_cpu(dev, phys, size, dir);
 }
 
@@ -796,7 +796,7 @@ static void iommu_dma_sync_single_for_device(struct device 
*dev,
return;
 
phys = iommu_iova_to_phys(iommu_get_dma_domain(dev), dma_handle);
-   if (is_swiotlb_buffer(phys))
+   if (is_swiotlb_buffer(dev, phys))
swiotlb_sync_single_for_device(dev, phys, size, dir);
 
if (!dev_is_dma_coherent(dev))
@@ -817,7 +817,7 @@ static void iommu_dma_sync_sg_for_cpu(struct device *dev,
if (!dev_is_dma_coherent(dev))
arch_sync_dma_for_cpu(sg_phys(sg), sg->length, dir);
 
-   if (is_swiotlb_buffer(sg_phys(sg)))
+   if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_sync_single_for_cpu(dev, sg_phys(sg),
sg->length, dir);
}
@@ -834,7 +834,7 @@ static void iommu_dma_sync_sg_for_device(struct device *dev,
return;
 
for_each_sg(sgl, sg, nelems, i) {
-   if (is_swiotlb_buffer(sg_phys(sg)))
+   if (is_swiotlb_buffer(dev, sg_phys(sg)))
swiotlb_sync_single_for_device(dev, sg_phys(sg),
   sg->length, dir);
 
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 24d11861ac7d..0c4fb34f11ab 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -100,7 +100,7 @@ static int is_xen_swiotlb_buffer(struct device *dev, 
dma_addr_t dma_addr)
 * in our domain. Therefore _only_ check address within our domain.
 */
if (pfn_valid(PFN_DOWN(paddr)))
-   return is_swiotlb_buffer(paddr);
+   return is_swiotlb_buffer(dev, paddr);
return 0;
 }
 
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index ec0c01796c8a..921b469c6ad2 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -2,6 +2,7 @@
 #ifndef __LINUX_SWIOTLB_H
 #define __LINUX_SWIOTLB_H
 
+#include 
 #include 
 #include 
 #include 
@@ -102,9 +103,9 @@ struct io_tlb_mem {
 };
 extern struct io_tlb_mem *io_tlb_default_mem;
 
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
 {
-   struct io_tlb_mem *mem = io_tlb_default_mem;
+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
 
return mem && paddr >= mem->start && paddr < mem->end;
 }
@@ -121,7 +122,7 @@ bool is_swiotlb_active(void);
 void __init swiotlb_adjust_size(unsigned long size);
 #else
 #define swiotlb_force SWIOTLB_NO_FORCE
-static inline bool is_swiotlb_buffer(phys_addr_t paddr)
+static inline bool is_swiotlb_buffer(struct device *dev, phys_addr_t paddr)
 {
return false;
 }
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index f737e3347059..84c9feb5474a 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -343,7 +343,7 @@ void dma_direct_sync_sg_for_device(struct device *dev,
for_each_sg(sgl, sg, nents, i) {
phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg));
 
-   if (unlikely(is_swiotlb_buffer(paddr)))
+   if (unlikely(is_swiotlb_buffer(dev, paddr)))
swiotlb_sync_single_for_device(dev, paddr, sg->length,

[Intel-gfx] [PATCH v9 04/14] swiotlb: Add restricted DMA pool initialization

[Claire Chang]

Add the initialization function to create restricted DMA pools from
matching reserved-memory nodes.

Signed-off-by: Claire Chang 
---
 include/linux/swiotlb.h |  3 +-
 kernel/dma/Kconfig  | 14 
 kernel/dma/swiotlb.c| 75 +
 3 files changed, 91 insertions(+), 1 deletion(-)

diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 008125ccd509..ec0c01796c8a 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -72,7 +72,8 @@ extern enum swiotlb_force swiotlb_force;
  * range check to see if the memory was in fact allocated by this
  * API.
  * @nslabs:The number of IO TLB blocks (in groups of 64) between @start and
- * @end. This is command line adjustable via setup_io_tlb_npages.
+ * @end. For default swiotlb, this is command line adjustable via
+ * setup_io_tlb_npages.
  * @used:  The number of used IO TLB block.
  * @list:  The free list describing the number of free entries available
  * from each index.
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 77b405508743..3e961dc39634 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -80,6 +80,20 @@ config SWIOTLB
bool
select NEED_DMA_MAP_STATE
 
+config DMA_RESTRICTED_POOL
+   bool "DMA Restricted Pool"
+   depends on OF && OF_RESERVED_MEM
+   select SWIOTLB
+   help
+ This enables support for restricted DMA pools which provide a level of
+ DMA memory protection on systems with limited hardware protection
+ capabilities, such as those lacking an IOMMU.
+
+ For more information see
+ 

+ and .
+ If unsure, say "n".
+
 #
 # Should be selected if we can mmap non-coherent mappings to userspace.
 # The only thing that is really required is a way to set an uncached bit
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 29b950ab1351..c4a071d6a63f 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -39,6 +39,13 @@
 #ifdef CONFIG_DEBUG_FS
 #include 
 #endif
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+#include 
+#include 
+#include 
+#include 
+#include 
+#endif
 
 #include 
 #include 
@@ -688,3 +695,71 @@ static int __init swiotlb_create_default_debugfs(void)
 late_initcall(swiotlb_create_default_debugfs);
 
 #endif
+
+#ifdef CONFIG_DMA_RESTRICTED_POOL
+static int rmem_swiotlb_device_init(struct reserved_mem *rmem,
+   struct device *dev)
+{
+   struct io_tlb_mem *mem = rmem->priv;
+   unsigned long nslabs = rmem->size >> IO_TLB_SHIFT;
+
+   /*
+* Since multiple devices can share the same pool, the private data,
+* io_tlb_mem struct, will be initialized by the first device attached
+* to it.
+*/
+   if (!mem) {
+   mem = kzalloc(struct_size(mem, slots, nslabs), GFP_KERNEL);
+   if (!mem)
+   return -ENOMEM;
+
+   swiotlb_init_io_tlb_mem(mem, rmem->base, nslabs, false, true);
+
+   rmem->priv = mem;
+
+   if (IS_ENABLED(CONFIG_DEBUG_FS)) {
+   mem->debugfs =
+   debugfs_create_dir(rmem->name, debugfs_dir);
+   swiotlb_create_debugfs_files(mem);
+   }
+   }
+
+   dev->dma_io_tlb_mem = mem;
+
+   return 0;
+}
+
+static void rmem_swiotlb_device_release(struct reserved_mem *rmem,
+   struct device *dev)
+{
+   dev->dma_io_tlb_mem = io_tlb_default_mem;
+}
+
+static const struct reserved_mem_ops rmem_swiotlb_ops = {
+   .device_init = rmem_swiotlb_device_init,
+   .device_release = rmem_swiotlb_device_release,
+};
+
+static int __init rmem_swiotlb_setup(struct reserved_mem *rmem)
+{
+   unsigned long node = rmem->fdt_node;
+
+   if (of_get_flat_dt_prop(node, "reusable", NULL) ||
+   of_get_flat_dt_prop(node, "linux,cma-default", NULL) ||
+   of_get_flat_dt_prop(node, "linux,dma-default", NULL) ||
+   of_get_flat_dt_prop(node, "no-map", NULL))
+   return -EINVAL;
+
+   if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base {
+   pr_err("Restricted DMA pool must be accessible within the 
linear mapping.");
+   return -EINVAL;
+   }
+
+   rmem->ops = &rmem_swiotlb_ops;
+   pr_info("Reserved memory: created restricted DMA pool at %pa, size %ld 
MiB\n",
+   &rmem->base, (unsigned long)rmem->size / SZ_1M);
+   return 0;
+}
+
+RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
+#endif /* CONFIG_DMA_RESTRICTED_POOL */
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 03/14] swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used

[Claire Chang]

Always have the pointer to the swiotlb pool used in struct device. This
could help simplify the code for other pools.

Signed-off-by: Claire Chang 
---
 drivers/of/device.c | 3 +++
 include/linux/device.h  | 4 
 include/linux/swiotlb.h | 8 
 kernel/dma/swiotlb.c| 8 
 4 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index c5a9473a5fb1..1defdf15ba95 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -165,6 +165,9 @@ int of_dma_configure_id(struct device *dev, struct 
device_node *np,
 
arch_setup_dma_ops(dev, dma_start, size, iommu, coherent);
 
+   if (IS_ENABLED(CONFIG_SWIOTLB))
+   swiotlb_set_io_tlb_default_mem(dev);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(of_dma_configure_id);
diff --git a/include/linux/device.h b/include/linux/device.h
index 4443e12238a0..2e9a378c9100 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -432,6 +432,7 @@ struct dev_links_info {
  * @dma_pools: Dma pools (if dma'ble device).
  * @dma_mem:   Internal for coherent mem override.
  * @cma_area:  Contiguous memory area for dma allocations
+ * @dma_io_tlb_mem: Pointer to the swiotlb pool used.  Not for driver use.
  * @archdata:  For arch-specific additions.
  * @of_node:   Associated device tree node.
  * @fwnode:Associated device node supplied by platform firmware.
@@ -540,6 +541,9 @@ struct device {
 #ifdef CONFIG_DMA_CMA
struct cma *cma_area;   /* contiguous memory area for dma
   allocations */
+#endif
+#ifdef CONFIG_SWIOTLB
+   struct io_tlb_mem *dma_io_tlb_mem;
 #endif
/* arch specific additions */
struct dev_archdata archdata;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 216854a5e513..008125ccd509 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -108,6 +108,11 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
return mem && paddr >= mem->start && paddr < mem->end;
 }
 
+static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
+{
+   dev->dma_io_tlb_mem = io_tlb_default_mem;
+}
+
 void __init swiotlb_exit(void);
 unsigned int swiotlb_max_segment(void);
 size_t swiotlb_max_mapping_size(struct device *dev);
@@ -119,6 +124,9 @@ static inline bool is_swiotlb_buffer(phys_addr_t paddr)
 {
return false;
 }
+static inline void swiotlb_set_io_tlb_default_mem(struct device *dev)
+{
+}
 static inline void swiotlb_exit(void)
 {
 }
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8a3e2b3b246d..29b950ab1351 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -344,7 +344,7 @@ void __init swiotlb_exit(void)
 static void swiotlb_bounce(struct device *dev, phys_addr_t tlb_addr, size_t 
size,
   enum dma_data_direction dir)
 {
-   struct io_tlb_mem *mem = io_tlb_default_mem;
+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
int index = (tlb_addr - mem->start) >> IO_TLB_SHIFT;
phys_addr_t orig_addr = mem->slots[index].orig_addr;
size_t alloc_size = mem->slots[index].alloc_size;
@@ -426,7 +426,7 @@ static unsigned int wrap_index(struct io_tlb_mem *mem, 
unsigned int index)
 static int find_slots(struct device *dev, phys_addr_t orig_addr,
size_t alloc_size)
 {
-   struct io_tlb_mem *mem = io_tlb_default_mem;
+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned long boundary_mask = dma_get_seg_boundary(dev);
dma_addr_t tbl_dma_addr =
phys_to_dma_unencrypted(dev, mem->start) & boundary_mask;
@@ -503,7 +503,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *dev, 
phys_addr_t orig_addr,
size_t mapping_size, size_t alloc_size,
enum dma_data_direction dir, unsigned long attrs)
 {
-   struct io_tlb_mem *mem = io_tlb_default_mem;
+   struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
unsigned int offset = swiotlb_align_offset(dev, orig_addr);
unsigned int i;
int index;
@@ -554,7 +554,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, 
phys_addr_t tlb_addr,
  size_t mapping_size, enum dma_data_direction dir,
  unsigned long attrs)
 {
-   struct io_tlb_mem *mem = io_tlb_default_mem;
+   struct io_tlb_mem *mem = hwdev->dma_io_tlb_mem;
unsigned long flags;
unsigned int offset = swiotlb_align_offset(hwdev, tlb_addr);
int index = (tlb_addr - offset - mem->start) >> IO_TLB_SHIFT;
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 02/14] swiotlb: Refactor swiotlb_create_debugfs

[Claire Chang]

Split the debugfs creation to make the code reusable for supporting
different bounce buffer pools, e.g. restricted DMA pool.

Signed-off-by: Claire Chang 
---
 kernel/dma/swiotlb.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 1a1208c81e85..8a3e2b3b246d 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -64,6 +64,9 @@
 enum swiotlb_force swiotlb_force;
 
 struct io_tlb_mem *io_tlb_default_mem;
+#ifdef CONFIG_DEBUG_FS
+static struct dentry *debugfs_dir;
+#endif
 
 /*
  * Max segment that we can provide which (if pages are contingous) will
@@ -664,18 +667,24 @@ EXPORT_SYMBOL_GPL(is_swiotlb_active);
 
 #ifdef CONFIG_DEBUG_FS
 
-static int __init swiotlb_create_debugfs(void)
+static void swiotlb_create_debugfs_files(struct io_tlb_mem *mem)
 {
-   struct io_tlb_mem *mem = io_tlb_default_mem;
-
-   if (!mem)
-   return 0;
-   mem->debugfs = debugfs_create_dir("swiotlb", NULL);
debugfs_create_ulong("io_tlb_nslabs", 0400, mem->debugfs, &mem->nslabs);
debugfs_create_ulong("io_tlb_used", 0400, mem->debugfs, &mem->used);
+}
+
+static int __init swiotlb_create_default_debugfs(void)
+{
+   struct io_tlb_mem *mem = io_tlb_default_mem;
+
+   debugfs_dir = debugfs_create_dir("swiotlb", NULL);
+   if (mem) {
+   mem->debugfs = debugfs_dir;
+   swiotlb_create_debugfs_files(mem);
+   }
return 0;
 }
 
-late_initcall(swiotlb_create_debugfs);
+late_initcall(swiotlb_create_default_debugfs);
 
 #endif
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 01/14] swiotlb: Refactor swiotlb init functions

[Claire Chang]

Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
initialization to make the code reusable.

Signed-off-by: Claire Chang 
---
 kernel/dma/swiotlb.c | 53 ++--
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8ca7d505d61c..1a1208c81e85 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -168,9 +168,32 @@ void __init swiotlb_update_mem_attributes(void)
memset(vaddr, 0, bytes);
 }
 
-int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
+   unsigned long nslabs, bool late_alloc,
+   bool memory_decrypted)
 {
+   void *vaddr = phys_to_virt(start);
unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
+
+   mem->nslabs = nslabs;
+   mem->start = start;
+   mem->end = mem->start + bytes;
+   mem->index = 0;
+   mem->late_alloc = late_alloc;
+   spin_lock_init(&mem->lock);
+   for (i = 0; i < mem->nslabs; i++) {
+   mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
+   mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
+   mem->slots[i].alloc_size = 0;
+   }
+
+   if (memory_decrypted)
+   set_memory_decrypted((unsigned long)vaddr, bytes >> PAGE_SHIFT);
+   memset(vaddr, 0, bytes);
+}
+
+int __init swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose)
+{
struct io_tlb_mem *mem;
size_t alloc_size;
 
@@ -186,16 +209,8 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long 
nslabs, int verbose)
if (!mem)
panic("%s: Failed to allocate %zu bytes align=0x%lx\n",
  __func__, alloc_size, PAGE_SIZE);
-   mem->nslabs = nslabs;
-   mem->start = __pa(tlb);
-   mem->end = mem->start + bytes;
-   mem->index = 0;
-   spin_lock_init(&mem->lock);
-   for (i = 0; i < mem->nslabs; i++) {
-   mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
-   mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
-   mem->slots[i].alloc_size = 0;
-   }
+
+   swiotlb_init_io_tlb_mem(mem, __pa(tlb), nslabs, false, false);
 
io_tlb_default_mem = mem;
if (verbose)
@@ -282,7 +297,6 @@ swiotlb_late_init_with_default_size(size_t default_size)
 int
 swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
 {
-   unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
struct io_tlb_mem *mem;
 
if (swiotlb_force == SWIOTLB_NO_FORCE)
@@ -297,20 +311,7 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
if (!mem)
return -ENOMEM;
 
-   mem->nslabs = nslabs;
-   mem->start = virt_to_phys(tlb);
-   mem->end = mem->start + bytes;
-   mem->index = 0;
-   mem->late_alloc = 1;
-   spin_lock_init(&mem->lock);
-   for (i = 0; i < mem->nslabs; i++) {
-   mem->slots[i].list = IO_TLB_SEGSIZE - io_tlb_offset(i);
-   mem->slots[i].orig_addr = INVALID_PHYS_ADDR;
-   mem->slots[i].alloc_size = 0;
-   }
-
-   set_memory_decrypted((unsigned long)tlb, bytes >> PAGE_SHIFT);
-   memset(tlb, 0, bytes);
+   swiotlb_init_io_tlb_mem(mem, virt_to_phys(tlb), nslabs, true, true);
 
io_tlb_default_mem = mem;
swiotlb_print_info();
-- 
2.32.0.272.g935e593368-goog

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

[Intel-gfx] [PATCH v9 00/14] Restricted DMA

[Claire Chang]

This series implements mitigations for lack of DMA access control on
systems without an IOMMU, which could result in the DMA accessing the
system memory at unexpected times and/or unexpected addresses, possibly
leading to data leakage or corruption.

For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is
not behind an IOMMU. As PCI-e, by design, gives the device full access to
system memory, a vulnerability in the Wi-Fi firmware could easily escalate
to a full system exploit (remote wifi exploits: [1a], [1b] that shows a
full chain of exploits; [2], [3]).

To mitigate the security concerns, we introduce restricted DMA. Restricted
DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a
specially allocated region and does memory allocation from the same region.
The feature on its own provides a basic level of protection against the DMA
overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption, the system needs
to provide a way to restrict the DMA to a predefined memory region (this is
usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]).

[1a] 
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html
[1b] 
https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html
[2] https://blade.tencent.com/en/advisories/qualpwn/
[3] 
https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/
[4] 
https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132

v9:
Address the comments in v7 to
  - set swiotlb active pool to dev->dma_io_tlb_mem
  - get rid of get_io_tlb_mem
  - dig out the device struct for is_swiotlb_active
  - move debugfs_create_dir out of swiotlb_create_debugfs
  - do set_memory_decrypted conditionally in swiotlb_init_io_tlb_mem
  - use IS_ENABLED in kernel/dma/direct.c
  - fix redefinition of 'of_dma_set_restricted_buffer'

v8:
- Fix reserved-memory.txt and add the reg property in example.
- Fix sizeof for of_property_count_elems_of_size in
  drivers/of/address.c#of_dma_set_restricted_buffer.
- Apply Will's suggestion to try the OF node having DMA configuration in
  drivers/of/address.c#of_dma_set_restricted_buffer.
- Fix typo in the comment of drivers/of/address.c#of_dma_set_restricted_buffer.
- Add error message for PageHighMem in
  kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to
  rmem_swiotlb_setup.
- Fix the message string in rmem_swiotlb_setup.
https://lore.kernel.org/patchwork/cover/1437112/

v7:
Fix debugfs, PageHighMem and comment style in rmem_swiotlb_device_init
https://lore.kernel.org/patchwork/cover/1431031/

v6:
Address the comments in v5
https://lore.kernel.org/patchwork/cover/1423201/

v5:
Rebase on latest linux-next
https://lore.kernel.org/patchwork/cover/1416899/

v4:
- Fix spinlock bad magic
- Use rmem->name for debugfs entry
- Address the comments in v3
https://lore.kernel.org/patchwork/cover/1378113/

v3:
Using only one reserved memory region for both streaming DMA and memory
allocation.
https://lore.kernel.org/patchwork/cover/1360992/

v2:
Building on top of swiotlb.
https://lore.kernel.org/patchwork/cover/1280705/

v1:
Using dma_map_ops.
https://lore.kernel.org/patchwork/cover/1271660/


Claire Chang (14):
  swiotlb: Refactor swiotlb init functions
  swiotlb: Refactor swiotlb_create_debugfs
  swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used
  swiotlb: Add restricted DMA pool initialization
  swiotlb: Update is_swiotlb_buffer to add a struct device argument
  swiotlb: Update is_swiotlb_active to add a struct device argument
  swiotlb: Bounce data from/to restricted DMA pool if available
  swiotlb: Move alloc_size to find_slots
  swiotlb: Refactor swiotlb_tbl_unmap_single
  dma-direct: Add a new wrapper __dma_direct_free_pages()
  swiotlb: Add restricted DMA alloc/free support.
  dma-direct: Allocate memory from restricted DMA pool if available
  dt-bindings: of: Add restricted DMA pool
  of: Add plumbing for restricted DMA pool

 .../reserved-memory/reserved-memory.txt   |  36 ++-
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   2 +-
 drivers/gpu/drm/nouveau/nouveau_ttm.c |   2 +-
 drivers/iommu/dma-iommu.c |  12 +-
 drivers/of/address.c  |  33 +++
 drivers/of/device.c   |   6 +
 drivers/of/of_private.h   |   6 +
 drivers/pci/xen-pcifront.c|   2 +-
 drivers/xen/swiotlb-xen.c |   2 +-
 include/linux/device.h|   4 +
 include/linux/swiotlb.h   |  45 +++-
 kernel/dma/Kconfig|  14 +
 kernel/dma/direct.c   |  62 +++--
 kernel/dma/direct.h   |   9 +-
 kernel/dma/swiotlb.c  | 242 +++

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable (rev2)
URL   : https://patchwork.freedesktop.org/series/91372/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
172f162a8949 drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#13: 
<3> [324.942939] BUG: sleeping function called from invalid context at 
kernel/softirq.c:888

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


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

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

[Daniel Vetter]

On Fri, Jun 11, 2021 at 12:03:31PM +0200, Christian König wrote:
> Am 11.06.21 um 11:33 schrieb Daniel Vetter:
> > On Fri, Jun 11, 2021 at 09:42:07AM +0200, Christian König wrote:
> > > Am 11.06.21 um 09:20 schrieb Daniel Vetter:
> > > > On Fri, Jun 11, 2021 at 8:55 AM Christian König
> > > >  wrote:
> > > > > Am 10.06.21 um 22:42 schrieb Daniel Vetter:
> > > > > > On Thu, Jun 10, 2021 at 10:10 PM Jason Ekstrand 
> > > > > >  wrote:
> > > > > > > On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand 
> > > > > > >  wrote:
> > > > > > > > On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter 
> > > > > > > >  wrote:
> > > > > > > > > On Thu, Jun 10, 2021 at 11:39 AM Christian König
> > > > > > > > >  wrote:
> > > > > > > > > > Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:
> > > > > > > > > > > On 09/06/2021 22:29, Jason Ekstrand wrote:
> > > > > > > > > > > > We've tried to keep it somewhat contained by doing most 
> > > > > > > > > > > > of the hard work
> > > > > > > > > > > > to prevent access of recycled objects via 
> > > > > > > > > > > > dma_fence_get_rcu_safe().
> > > > > > > > > > > > However, a quick grep of kernel sources says that, of 
> > > > > > > > > > > > the 30 instances
> > > > > > > > > > > > of dma_fence_get_rcu*, only 11 of them use 
> > > > > > > > > > > > dma_fence_get_rcu_safe().
> > > > > > > > > > > > It's likely there bear traps in DRM and related 
> > > > > > > > > > > > subsystems just waiting
> > > > > > > > > > > > for someone to accidentally step in them.
> > > > > > > > > > > ...because dma_fence_get_rcu_safe apears to be about 
> > > > > > > > > > > whether the
> > > > > > > > > > > *pointer* to the fence itself is rcu protected, not about 
> > > > > > > > > > > the fence
> > > > > > > > > > > object itself.
> > > > > > > > > > Yes, exactly that.
> > > > > > > > The fact that both of you think this either means that I've 
> > > > > > > > completely
> > > > > > > > missed what's going on with RCUs here (possible but, in this 
> > > > > > > > case, I
> > > > > > > > think unlikely) or RCUs on dma fences should scare us all.
> > > > > > > Taking a step back for a second and ignoring SLAB_TYPESAFE_BY_RCU 
> > > > > > > as
> > > > > > > such,  I'd like to ask a slightly different question:  What are 
> > > > > > > the
> > > > > > > rules about what is allowed to be done under the RCU read lock and
> > > > > > > what guarantees does a driver need to provide?
> > > > > > > 
> > > > > > > I think so far that we've all agreed on the following:
> > > > > > > 
> > > > > > > 1. Freeing an unsignaled fence is ok as long as it doesn't 
> > > > > > > have any
> > > > > > > pending callbacks.  (Callbacks should hold a reference anyway).
> > > > > > > 
> > > > > > > 2. The pointer race solved by dma_fence_get_rcu_safe is real 
> > > > > > > and
> > > > > > > requires the loop to sort out.
> > > > > > > 
> > > > > > > But let's say I have a dma_fence pointer that I got from, say, 
> > > > > > > calling
> > > > > > > dma_resv_excl_fence() under rcu_read_lock().  What am I allowed 
> > > > > > > to do
> > > > > > > with it under the RCU lock?  What assumptions can I make?  Is this
> > > > > > > code, for instance, ok?
> > > > > > > 
> > > > > > > rcu_read_lock();
> > > > > > > fence = dma_resv_excl_fence(obj);
> > > > > > > idle = !fence || test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, 
> > > > > > > &fence->flags);
> > > > > > > rcu_read_unlock();
> > > > > > > 
> > > > > > > This code very much looks correct under the following assumptions:
> > > > > > > 
> > > > > > > 1. A valid fence pointer stays alive under the RCU read lock
> > > > > > > 2. SIGNALED_BIT is set-once (it's never unset after being 
> > > > > > > set).
> > > > > > > 
> > > > > > > However, if it were, we wouldn't have dma_resv_test_singnaled(), 
> > > > > > > now
> > > > > > > would we? :-)
> > > > > > > 
> > > > > > > The moment you introduce ANY dma_fence recycling that recycles a
> > > > > > > dma_fence within a single RCU grace period, all your assumptions 
> > > > > > > break
> > > > > > > down.  SLAB_TYPESAFE_BY_RCU is just one way that i915 does this.  
> > > > > > > We
> > > > > > > also have a little i915_request recycler to try and help with 
> > > > > > > memory
> > > > > > > pressure scenarios in certain critical sections that also doesn't
> > > > > > > respect RCU grace periods.  And, as mentioned multiple times, our
> > > > > > > recycling leaks into every other driver because, thanks to i915's
> > > > > > > choice, the above 4-line code snippet isn't valid ANYWHERE in the
> > > > > > > kernel.
> > > > > > > 
> > > > > > > So the question I'm raising isn't so much about the rules today.
> > > > > > > Today, we live in the wild wild west where everything is YOLO.  
> > > > > > > But
> > > > > > > where do we want to go?  Do we like this wild west world?  So we 
> > > > > > > want
> > > > > > > more consistency under the RCU read lock?  If so, what do we want 
> > > > > > > the
> > > > > > > rules to be?
> > > > > > > 

[Intel-gfx] [PATCH v2 3/4] drm/i915/ttm: Calculate the object placement at get_pages time

[Thomas Hellström]

Instead of relying on a static placement, calculate at get_pages() time.
This should work for LMEM regions and system for now. For stolen we need
to take preallocated range into account. That well be added later.

Signed-off-by: Thomas Hellström 
---
v2:
- Fixed a style issue (Reported by Matthew Auld)
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 92 ++---
 drivers/gpu/drm/i915/intel_region_ttm.c |  8 ++-
 drivers/gpu/drm/i915/intel_region_ttm.h |  2 +
 3 files changed, 75 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 45ef1d101937..fd3d11728229 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -24,6 +24,11 @@
 #define I915_TTM_PRIO_NO_PAGES  1
 #define I915_TTM_PRIO_HAS_PAGES 2
 
+/*
+ * Size of struct ttm_place vector in on-stack struct ttm_placement allocs
+ */
+#define I915_TTM_MAX_PLACEMENTS 10
+
 /**
  * struct i915_ttm_tt - TTM page vector with additional private information
  * @ttm: The base TTM page vector.
@@ -42,32 +47,18 @@ struct i915_ttm_tt {
struct sg_table *cached_st;
 };
 
-static const struct ttm_place lmem0_sys_placement_flags[] = {
-   {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = I915_PL_LMEM0,
-   .flags = 0,
-   }, {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = I915_PL_SYSTEM,
-   .flags = 0,
-   }
-};
-
-static struct ttm_placement i915_lmem0_placement = {
-   .num_placement = 1,
-   .placement = &lmem0_sys_placement_flags[0],
-   .num_busy_placement = 1,
-   .busy_placement = &lmem0_sys_placement_flags[0],
+static const struct ttm_place sys_placement_flags = {
+   .fpfn = 0,
+   .lpfn = 0,
+   .mem_type = I915_PL_SYSTEM,
+   .flags = 0,
 };
 
 static struct ttm_placement i915_sys_placement = {
.num_placement = 1,
-   .placement = &lmem0_sys_placement_flags[1],
+   .placement = &sys_placement_flags,
.num_busy_placement = 1,
-   .busy_placement = &lmem0_sys_placement_flags[1],
+   .busy_placement = &sys_placement_flags,
 };
 
 static bool gpu_binds_iomem(struct ttm_resource *mem)
@@ -83,6 +74,55 @@ static bool cpu_maps_iomem(struct ttm_resource *mem)
 
 static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
 
+static enum ttm_caching
+i915_ttm_select_tt_caching(const struct drm_i915_gem_object *obj)
+{
+   /*
+* Objects only allowed in system get cached cpu-mappings.
+* Other objects get WC mapping for now. Even if in system.
+*/
+   if (obj->mm.region->type == INTEL_MEMORY_SYSTEM &&
+   obj->mm.n_placements <= 1)
+   return ttm_cached;
+
+   return ttm_write_combined;
+}
+
+static void
+i915_ttm_place_from_region(const struct intel_memory_region *mr,
+  struct ttm_place *place)
+{
+   memset(place, 0, sizeof(*place));
+   place->mem_type = intel_region_to_ttm_type(mr);
+}
+
+static void
+i915_ttm_placement_from_obj(const struct drm_i915_gem_object *obj,
+   struct ttm_place *requested,
+   struct ttm_place *busy,
+   struct ttm_placement *placement)
+{
+   unsigned int num_allowed = obj->mm.n_placements;
+   unsigned int i;
+
+   placement->num_placement = 1;
+   i915_ttm_place_from_region(num_allowed ? obj->mm.placements[0] :
+  obj->mm.region, requested);
+
+   /* Cache this on object? */
+   placement->num_busy_placement = num_allowed;
+   for (i = 0; i < placement->num_busy_placement; ++i)
+   i915_ttm_place_from_region(obj->mm.placements[i], busy + i);
+
+   if (num_allowed == 0) {
+   *busy = *requested;
+   placement->num_busy_placement = 1;
+   }
+
+   placement->placement = requested;
+   placement->busy_placement = busy;
+}
+
 static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
 uint32_t page_flags)
 {
@@ -100,7 +140,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
man->use_tt)
page_flags |= TTM_PAGE_FLAG_ZERO_ALLOC;
 
-   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, ttm_write_combined);
+   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags,
+ i915_ttm_select_tt_caching(obj));
if (ret) {
kfree(i915_tt);
return NULL;
@@ -465,10 +506,13 @@ static int i915_ttm_get_pages(struct drm_i915_gem_object 
*obj)
.no_wait_gpu = false,
};
struct sg_table *st;
+   struct ttm_place requested, busy[I915_TTM_MAX_PLACEMENTS];
+   struct ttm_placement placement;
int ret;
 
/* Move to the requested placement. */
-   ret = ttm_bo_valid

[Intel-gfx] [PATCH v2 4/4] drm/i915/ttm: Use TTM for system memory

[Thomas Hellström]

For discrete, use TTM for both cached and WC system memory. That means
we currently rely on the TTM memory accounting / shrinker. For cached
system memory we should consider remaining shmem-backed, which can be
implemented from our ttm_tt_populate calback. We can then also reuse our
own very elaborate shrinker for that memory.

Signed-off-by: Thomas Hellström 
---
v2:
- Fix IS_ERR_OR_NULL() check to IS_ERR() (Reported by Matthew Auld)
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 22 ++
 drivers/gpu/drm/i915/i915_drv.h|  3 ---
 drivers/gpu/drm/i915/intel_memory_region.c |  7 ++-
 drivers/gpu/drm/i915/intel_memory_region.h |  8 
 4 files changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index fd3d11728229..0940c1d7c5e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -755,3 +755,25 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
/* i915 wants -ENXIO when out of memory region space. */
return (ret == -ENOSPC) ? -ENXIO : ret;
 }
+
+static const struct intel_memory_region_ops ttm_system_region_ops = {
+   .init_object = __i915_gem_ttm_object_init,
+};
+
+struct intel_memory_region *
+i915_gem_ttm_system_setup(struct drm_i915_private *i915,
+ u16 type, u16 instance)
+{
+   struct intel_memory_region *mr;
+
+   mr = intel_memory_region_create(i915, 0,
+   totalram_pages() << PAGE_SHIFT,
+   PAGE_SIZE, 0,
+   type, instance,
+   &ttm_system_region_ops);
+   if (IS_ERR(mr))
+   return mr;
+
+   intel_memory_region_set_name(mr, "system-ttm");
+   return mr;
+}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38ff2fb89744..9643bebb951d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1751,9 +1751,6 @@ void i915_gem_cleanup_userptr(struct drm_i915_private 
*dev_priv);
 void i915_gem_init_early(struct drm_i915_private *dev_priv);
 void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
 
-struct intel_memory_region *i915_gem_shmem_setup(struct drm_i915_private *i915,
-u16 type, u16 instance);
-
 static inline void i915_gem_drain_freed_objects(struct drm_i915_private *i915)
 {
/*
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c 
b/drivers/gpu/drm/i915/intel_memory_region.c
index 12fb5423fd5e..0b016bdb8b84 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -220,7 +220,12 @@ int intel_memory_regions_hw_probe(struct drm_i915_private 
*i915)
instance = intel_region_map[i].instance;
switch (type) {
case INTEL_MEMORY_SYSTEM:
-   mem = i915_gem_shmem_setup(i915, type, instance);
+   if (IS_DGFX(i915))
+   mem = i915_gem_ttm_system_setup(i915, type,
+   instance);
+   else
+   mem = i915_gem_shmem_setup(i915, type,
+  instance);
break;
case INTEL_MEMORY_STOLEN_LOCAL:
mem = i915_gem_stolen_lmem_setup(i915, type, instance);
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h 
b/drivers/gpu/drm/i915/intel_memory_region.h
index c7e635d62e1a..1a2bb9fc9de5 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -143,4 +143,12 @@ void intel_memory_region_unreserve(struct 
intel_memory_region *mem);
 int intel_memory_region_reserve(struct intel_memory_region *mem,
resource_size_t offset,
resource_size_t size);
+
+struct intel_memory_region *
+i915_gem_ttm_system_setup(struct drm_i915_private *i915,
+ u16 type, u16 instance);
+struct intel_memory_region *
+i915_gem_shmem_setup(struct drm_i915_private *i915,
+u16 type, u16 instance);
+
 #endif
-- 
2.31.1

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

[Intel-gfx] [PATCH v2 2/4] drm/i915/ttm: Adjust gem flags and caching settings after a move

[Thomas Hellström]

After a TTM move we need to update the i915 gem flags and caching
settings to reflect the new placement.
Also introduce gpu_binds_iomem() and cpu_maps_iomem() to clean up the
various ways we previously used to detect this.
Finally, initialize the TTM object reserved to be able to update
flags and caching before anyone else gets hold of the object.

Signed-off-by: Thomas Hellström 
---
v2:
- Style fixes (Reported by Matthew Auld)
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 112 +++-
 1 file changed, 90 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 33ab47f1e05b..45ef1d101937 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -70,6 +70,17 @@ static struct ttm_placement i915_sys_placement = {
.busy_placement = &lmem0_sys_placement_flags[1],
 };
 
+static bool gpu_binds_iomem(struct ttm_resource *mem)
+{
+   return mem->mem_type != TTM_PL_SYSTEM;
+}
+
+static bool cpu_maps_iomem(struct ttm_resource *mem)
+{
+   /* Once / if we support GGTT, this is also false for cached ttm_tts */
+   return mem->mem_type != TTM_PL_SYSTEM;
+}
+
 static void i915_ttm_adjust_lru(struct drm_i915_gem_object *obj);
 
 static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
@@ -175,6 +186,41 @@ static void i915_ttm_free_cached_io_st(struct 
drm_i915_gem_object *obj)
obj->ttm.cached_io_st = NULL;
 }
 
+static void
+i915_ttm_adjust_domains_after_cpu_move(struct drm_i915_gem_object *obj)
+{
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+
+   if (cpu_maps_iomem(bo->resource) || bo->ttm->caching != ttm_cached) {
+   obj->write_domain = I915_GEM_DOMAIN_WC;
+   obj->read_domains = I915_GEM_DOMAIN_WC;
+   } else {
+   obj->write_domain = I915_GEM_DOMAIN_CPU;
+   obj->read_domains = I915_GEM_DOMAIN_CPU;
+   }
+}
+
+static void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+   unsigned int cache_level;
+
+   obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
+
+   obj->mem_flags |= cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM :
+   I915_BO_FLAG_STRUCT_PAGE;
+
+   if ((HAS_LLC(i915) || HAS_SNOOP(i915)) && 
!gpu_binds_iomem(bo->resource) &&
+   bo->ttm->caching == ttm_cached) {
+   cache_level = I915_CACHE_LLC;
+   } else {
+   cache_level = I915_CACHE_NONE;
+   }
+
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+}
+
 static void i915_ttm_purge(struct drm_i915_gem_object *obj)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
@@ -190,8 +236,10 @@ static void i915_ttm_purge(struct drm_i915_gem_object *obj)
 
/* TTM's purge interface. Note that we might be reentering. */
ret = ttm_bo_validate(bo, &place, &ctx);
-
if (!ret) {
+   obj->write_domain = 0;
+   obj->read_domains = 0;
+   i915_ttm_adjust_gem_after_move(obj);
i915_ttm_free_cached_io_st(obj);
obj->mm.madv = __I915_MADV_PURGED;
}
@@ -273,12 +321,15 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
 struct ttm_resource *res)
 {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
-   struct ttm_resource_manager *man =
-   ttm_manager_type(bo->bdev, res->mem_type);
 
-   if (man->use_tt)
+   if (!gpu_binds_iomem(res))
return i915_ttm_tt_get_st(bo->ttm);
 
+   /*
+* If CPU mapping differs, we need to add the ttm_tt pages to
+* the resulting st. Might make sense for GGTT.
+*/
+   GEM_WARN_ON(!cpu_maps_iomem(res));
return intel_region_ttm_node_to_st(obj->mm.region, res);
 }
 
@@ -290,8 +341,6 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool 
evict,
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
struct ttm_resource_manager *dst_man =
ttm_manager_type(bo->bdev, dst_mem->mem_type);
-   struct ttm_resource_manager *src_man =
-   ttm_manager_type(bo->bdev, bo->resource->mem_type);
struct intel_memory_region *dst_reg, *src_reg;
union {
struct ttm_kmap_iter_tt tt;
@@ -332,34 +381,36 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, 
bool evict,
if (IS_ERR(dst_st))
return PTR_ERR(dst_st);
 
-   /* If we start mapping GGTT, we can no longer use man::use_tt here. */
-   dst_iter = dst_man->use_tt ?
+   dst_iter = !cpu_maps_iomem(dst_mem) ?
ttm_kmap_iter_tt_init(&_dst_iter.tt, bo->ttm) :
ttm_kmap_iter_iomap_init(&_dst_iter.io, &dst_reg->iomap,
   

[Intel-gfx] [PATCH v2 1/4] drm/i915: Update object placement flags to be mutable

[Thomas Hellström]

The object ops i915_GEM_OBJECT_HAS_IOMEM and the object
I915_BO_ALLOC_STRUCT_PAGE flags are considered immutable by
much of our code. Introduce a new mem_flags member to hold these
and make sure checks for these flags being set are either done
under the object lock or with pages properly pinned. The flags
will change during migration under the object lock.

Signed-off-by: Thomas Hellström 
v2:
- Unconditionally set VM_IO on our VMAs in line with the rest core gem
  and TTM. Since the bo might be migrated while the VMA is still alive,
  there is no sense, whether or not it maps iomem might change.
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 12 +++---
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 38 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h| 14 ++-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 20 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 10 +++--
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |  4 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |  4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |  5 +--
 .../drm/i915/gem/selftests/i915_gem_mman.c|  4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|  3 +-
 14 files changed, 79 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ce6b664b10aa..13b217f75055 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -177,8 +177,8 @@ i915_gem_object_create_internal(struct drm_i915_private 
*i915,
return ERR_PTR(-ENOMEM);
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
-   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class,
-I915_BO_ALLOC_STRUCT_PAGE);
+   i915_gem_object_init(obj, &i915_gem_object_internal_ops, &lock_class, 
0);
+   obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
 
/*
 * Mark the object as volatile, such that the pages are marked as
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 2fd155742bd2..6497a2dbdab9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -684,7 +684,7 @@ __assign_mmap_offset(struct drm_i915_gem_object *obj,
 
if (mmap_type != I915_MMAP_TYPE_GTT &&
!i915_gem_object_has_struct_page(obj) &&
-   !i915_gem_object_type_has(obj, I915_GEM_OBJECT_HAS_IOMEM))
+   !i915_gem_object_has_iomem(obj))
return -ENODEV;
 
mmo = mmap_offset_attach(obj, mmap_type, file);
@@ -708,7 +708,12 @@ __assign_mmap_offset_handle(struct drm_file *file,
if (!obj)
return -ENOENT;
 
+   err = i915_gem_object_lock_interruptible(obj, NULL);
+   if (err)
+   goto out_put;
err = __assign_mmap_offset(obj, mmap_type, offset, file);
+   i915_gem_object_unlock(obj);
+out_put:
i915_gem_object_put(obj);
return err;
 }
@@ -932,10 +937,7 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct 
*vma)
return PTR_ERR(anon);
}
 
-   vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
-
-   if (i915_gem_object_has_iomem(obj))
-   vma->vm_flags |= VM_IO;
+   vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP | VM_IO;
 
/*
 * We keep the ref on mmo->obj, not vm_file, but we require
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index cf18c430d51f..07e8ff9a8aae 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -475,6 +475,44 @@ bool i915_gem_object_migratable(struct drm_i915_gem_object 
*obj)
return obj->mm.n_placements > 1;
 }
 
+/**
+ * i915_gem_object_has_struct_page - Whether the object is page-backed
+ * @obj: The object to query.
+ *
+ * This function should only be called while the object is locked or pinned,
+ * otherwise the page backing may change under the caller.
+ *
+ * Return: True if page-backed, false otherwise.
+ */
+bool i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
+{
+#ifdef CONFIG_LOCKDEP
+   if (IS_DGFX(to_i915(obj->base.dev)) &&
+   i915_gem_object_evictable((void __force *)obj))
+   assert_object_held_shared(obj);
+#endif
+   return obj->mem_flags & I915_BO_FLAG_STRUCT_PAGE;
+}
+
+/**
+ * i915_gem_object_has_iomem - Whether the object is iomem-backed
+ * @obj: The object to query.
+ *
+ * This function should only be called while the object is locked or pinned,
+ * otherwise the iomem backing may change under the caller.
+ *
+ * Retur

[Intel-gfx] [PATCH v2 0/4] drm/i915: Move system memory to TTM for discrete

[Thomas Hellström]

Early implementation of moving system memory for discrete cards over to
TTM. We first add the notion of objects being migratable under the object
lock to i915 gem, and add some asserts to verify that objects are either
locked or pinned when the placement is checked by the gem code.

Patch 2 and 3 deals with updating the i915 gem bookkeeping after a TTM move,
Patch 4 moves system over from shmem to TTM for discrete

Note that the mock device doesn't consider itself discrete so the TTM
system path is not checked by the mock selftests.

v2:
- Style fixes (reported by Matthew Auld)
- Drop the last patch (migration) It needs selftests and some additional work.
- Unconditionally add VM_IO at mmap time.

Thomas Hellström (4):
  drm/i915: Update object placement flags to be mutable
  drm/i915/ttm: Adjust gem flags and caching settings after a move
  drm/i915/ttm: Calculate the object placement at get_pages time
  drm/i915/ttm: Use TTM for system memory

 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  12 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c|  38 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  14 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  20 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_phys.c  |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 224 ++
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   4 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   4 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   5 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|   4 +-
 .../drm/i915/gem/selftests/i915_gem_phys.c|   3 +-
 drivers/gpu/drm/i915/i915_drv.h   |   3 -
 drivers/gpu/drm/i915/intel_memory_region.c|   7 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   8 +
 drivers/gpu/drm/i915/intel_region_ttm.c   |   8 +-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   2 +
 19 files changed, 278 insertions(+), 96 deletions(-)

-- 
2.31.1

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

[Intel-gfx] [PATCH] drm/i915/gen11: use ffs for minconfig slice/subslice

[Tejas Upadhyay]

w/a on gen11 platforms not working as expected and causing
more harm on the RC6 flow. Because of subslice steering
disturbance w/a read is failing. By using ffs we can default
steering of slice/sublice to minconfig hence w/a will pass
and any warns will go away.

Fixes: fb899dd8ea9c ("drm/i915: Apply Wa_1406680159:icl,ehl as an engine 
workaround")
Cc: Mika Kuoppala 
Cc: Matt Roper 
Signed-off-by: Tejas Upadhyay 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 +++---
 drivers/gpu/drm/i915/intel_pm.c | 10 +++---
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index b62d1e31a645..68b14141088a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -991,13 +991,21 @@ wa_init_mcr(struct drm_i915_private *i915, struct 
i915_wa_list *wal)
l3_en = ~0;
}
 
-   slice = fls(sseu->slice_mask) - 1;
-   subslice = fls(l3_en & intel_sseu_get_subslices(sseu, slice));
+   if (GRAPHICS_VER(i915) == 11) {
+   slice = ffs(sseu->slice_mask) - 1;
+   subslice = ffs(l3_en & intel_sseu_get_subslices(sseu, slice));
+   } else {
+   slice = fls(sseu->slice_mask) - 1;
+   subslice = fls(l3_en & intel_sseu_get_subslices(sseu, slice));
+   }
if (!subslice) {
drm_warn(&i915->drm,
 "No common index found between subslice mask %x and L3 
bank mask %x!\n",
 intel_sseu_get_subslices(sseu, slice), l3_en);
-   subslice = fls(l3_en);
+   if (GRAPHICS_VER(i915) == 11)
+   subslice = ffs(l3_en);
+   else
+   subslice = fls(l3_en);
drm_WARN_ON(&i915->drm, !subslice);
}
subslice--;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 45fefa0ed160..d1352ec3546a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4049,9 +4049,13 @@ skl_ddb_entry_for_slices(struct drm_i915_private 
*dev_priv, u8 slice_mask,
ddb->end = 0;
return;
}
-
-   ddb->start = (ffs(slice_mask) - 1) * slice_size;
-   ddb->end = fls(slice_mask) * slice_size;
+   if (GRAPHICS_VER(dev_priv) == 11) {
+   ddb->start = (fls(slice_mask) - 1) * slice_size;
+   ddb->end = ffs(slice_mask) * slice_size;
+   } else {
+   ddb->start = (ffs(slice_mask) - 1) * slice_size;
+   ddb->end = fls(slice_mask) * slice_size;
+   }
 
WARN_ON(ddb->start >= ddb->end);
WARN_ON(ddb->end > INTEL_INFO(dev_priv)->dbuf.size);
-- 
2.31.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/xelpd: Enabling dithering after the CC1

[Patchwork]

== Series Details ==

Series: drm/i915/xelpd: Enabling dithering after the CC1
URL   : https://patchwork.freedesktop.org/series/91383/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10212 -> Patchwork_20343


Summary
---

  **SUCCESS**

  No regressions found.

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

Possible new issues
---

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

### IGT changes ###

 Suppressed 

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

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

  
Known issues


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

### IGT changes ###

 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-bsw-nick:[DMESG-FAIL][2] ([i915#3462]) -> [INCOMPLETE][3] 
([i915#2782] / [i915#2940] / [i915#3462])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-bsw-kefka:   [INCOMPLETE][4] ([i915#2782] / [i915#2940] / 
[i915#3462]) -> [DMESG-FAIL][5] ([i915#3462])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][6] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][7] ([i915#1436] / [i915#3363])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-skl-6600u/igt@run...@aborted.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/fi-skl-6600u/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][8] ([i915#2426] / [i915#3363] / 
[k.org#202321]) -> [FAIL][9] ([i915#3363] / [k.org#202321])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-glk-dsi/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-soraka:  [FAIL][10] ([i915#1436] / [i915#3363]) -> [FAIL][11] 
([i915#1436] / [i915#2426] / [i915#3363])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-soraka/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/fi-kbl-soraka/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][12] ([i915#1436] / [i915#3363]) -> [FAIL][13] 
([i915#1436] / [i915#2426] / [i915#3363])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10212/fi-kbl-7567u/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20343/fi-kbl-7567u/igt@run...@aborted.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1222]: https://gitlab.freedesktop.org/drm/intel/issues/1222
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
  [i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
  [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
  [i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
  [i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
  [k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321


Participating hosts (46 -> 40)
--

  Additional (1): fi-jsl-1 
  Missing(7): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan bat-adlp-4 bat-adls-4 
fi-bdw-samus bat-jsl-1 


Build changes
-

  * Linux: CI_DRM_10212 -> Patchwork_20343

  CI-20190529: 20190529
  CI_DRM_10212: d6a4e59ffc78a058586d57930708ba706d765be4 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6104: f8f81bd3752f3126a47d9dbba2d0ab29f7c17a19 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20343: 5e4918ee506ba4b64adad276b98e55616cf6a7b4 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5e4918ee506b drm/i915/xelpd: Enabling dithering after the CC1

== Logs ==

For more details see: 
https:/

Re: [Intel-gfx] [PATCH] drm/i915: Fix busy ioctl commentary

[Matthew Auld]

On Fri, 11 Jun 2021 at 14:22, Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> Just tidy one instance of incorrect context parameter name and a stray
> sentence ending from before reporting was converted to be class based.
>
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

[Christian König]

Am 11.06.21 um 11:33 schrieb Daniel Vetter:

On Fri, Jun 11, 2021 at 09:42:07AM +0200, Christian König wrote:

Am 11.06.21 um 09:20 schrieb Daniel Vetter:

On Fri, Jun 11, 2021 at 8:55 AM Christian König
 wrote:

Am 10.06.21 um 22:42 schrieb Daniel Vetter:

On Thu, Jun 10, 2021 at 10:10 PM Jason Ekstrand  wrote:

On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand  wrote:

On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter  wrote:

On Thu, Jun 10, 2021 at 11:39 AM Christian König
 wrote:

Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:

On 09/06/2021 22:29, Jason Ekstrand wrote:

We've tried to keep it somewhat contained by doing most of the hard work
to prevent access of recycled objects via dma_fence_get_rcu_safe().
However, a quick grep of kernel sources says that, of the 30 instances
of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_safe().
It's likely there bear traps in DRM and related subsystems just waiting
for someone to accidentally step in them.

...because dma_fence_get_rcu_safe apears to be about whether the
*pointer* to the fence itself is rcu protected, not about the fence
object itself.

Yes, exactly that.

The fact that both of you think this either means that I've completely
missed what's going on with RCUs here (possible but, in this case, I
think unlikely) or RCUs on dma fences should scare us all.

Taking a step back for a second and ignoring SLAB_TYPESAFE_BY_RCU as
such,  I'd like to ask a slightly different question:  What are the
rules about what is allowed to be done under the RCU read lock and
what guarantees does a driver need to provide?

I think so far that we've all agreed on the following:

1. Freeing an unsignaled fence is ok as long as it doesn't have any
pending callbacks.  (Callbacks should hold a reference anyway).

2. The pointer race solved by dma_fence_get_rcu_safe is real and
requires the loop to sort out.

But let's say I have a dma_fence pointer that I got from, say, calling
dma_resv_excl_fence() under rcu_read_lock().  What am I allowed to do
with it under the RCU lock?  What assumptions can I make?  Is this
code, for instance, ok?

rcu_read_lock();
fence = dma_resv_excl_fence(obj);
idle = !fence || test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags);
rcu_read_unlock();

This code very much looks correct under the following assumptions:

1. A valid fence pointer stays alive under the RCU read lock
2. SIGNALED_BIT is set-once (it's never unset after being set).

However, if it were, we wouldn't have dma_resv_test_singnaled(), now
would we? :-)

The moment you introduce ANY dma_fence recycling that recycles a
dma_fence within a single RCU grace period, all your assumptions break
down.  SLAB_TYPESAFE_BY_RCU is just one way that i915 does this.  We
also have a little i915_request recycler to try and help with memory
pressure scenarios in certain critical sections that also doesn't
respect RCU grace periods.  And, as mentioned multiple times, our
recycling leaks into every other driver because, thanks to i915's
choice, the above 4-line code snippet isn't valid ANYWHERE in the
kernel.

So the question I'm raising isn't so much about the rules today.
Today, we live in the wild wild west where everything is YOLO.  But
where do we want to go?  Do we like this wild west world?  So we want
more consistency under the RCU read lock?  If so, what do we want the
rules to be?

One option would be to accept the wild-west world we live in and say
"The RCU read lock gains you nothing.  If you want to touch the guts
of a dma_fence, take a reference".  But, at that point, we're eating
two atomics for every time someone wants to look at a dma_fence.  Do
we want that?

Alternatively, and this what I think Daniel and I were trying to
propose here, is that we place some constraints on dma_fence
recycling.  Specifically that, under the RCU read lock, the fence
doesn't suddenly become a new fence.  All of the immutability and
once-mutability guarantees of various bits of dma_fence hold as long
as you have the RCU read lock.

Yeah this is suboptimal. Too many potential bugs, not enough benefits.

This entire __rcu business started so that there would be a lockless
way to get at fences, or at least the exclusive one. That did not
really pan out. I think we have a few options:

- drop the idea of rcu/lockless dma-fence access outright. A quick
sequence of grabbing the lock, acquiring the dma_fence and then
dropping your lock again is probably plenty good. There's a lot of
call_rcu and other stuff we could probably delete. I have no idea what
the perf impact across all the drivers would be.

The question is maybe not the perf impact, but rather if that is
possible over all.

IIRC we now have some cases in TTM where RCU is mandatory and we simply
don't have any other choice than using it.

Adding Thomas Hellstrom.

Where is that stuff? If we end up with all the dma_resv locking
complexity just for an oddball, then I think that would be rather big
bummer.

This is during buffer de

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/xelpd: Enabling dithering after the CC1

[Patchwork]

== Series Details ==

Series: drm/i915/xelpd: Enabling dithering after the CC1
URL   : https://patchwork.freedesktop.org/series/91383/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
5e4918ee506b drm/i915/xelpd: Enabling dithering after the CC1
-:30: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'crtc_state->pipe_bpp == 36'
#30: FILE: drivers/gpu/drm/i915/display/intel_color.c:1593:
+   if (!crtc_state->dither_force_disable &&
+   (crtc_state->pipe_bpp == 36))

-:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#31: FILE: drivers/gpu/drm/i915/display/intel_color.c:1594:
+   if (!crtc_state->dither_force_disable &&
+   (crtc_state->pipe_bpp == 36))

-:53: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'crtc_state->pipe_bpp != 36'
#53: FILE: drivers/gpu/drm/i915/display/intel_display.c:5771:
+   if (crtc_state->dither && (crtc_state->pipe_bpp != 36))

-:56: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 
'crtc_state->pipe_bpp == 36'
#56: FILE: drivers/gpu/drm/i915/display/intel_display.c:5774:
+   if (crtc_state->dither && (crtc_state->pipe_bpp == 36) && 
(DISPLAY_VER(dev_priv) < 13))

total: 0 errors, 0 warnings, 4 checks, 43 lines checked


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

[Intel-gfx] [PATCH] drm/i915: Fix busy ioctl commentary

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Just tidy one instance of incorrect context parameter name and a stray
sentence ending from before reporting was converted to be class based.

Signed-off-by: Tvrtko Ursulin 
---
 include/uapi/drm/i915_drm.h | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index c2c7759b7d2e..a1cb4aa035a9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1348,12 +1348,11 @@ struct drm_i915_gem_busy {
 * reading from the object simultaneously.
 *
 * The value of each engine class is the same as specified in the
-* I915_CONTEXT_SET_ENGINES parameter and via perf, i.e.
+* I915_CONTEXT_PARAM_ENGINES context parameter and via perf, i.e.
 * I915_ENGINE_CLASS_RENDER, I915_ENGINE_CLASS_COPY, etc.
-* reported as active itself. Some hardware may have parallel
-* execution engines, e.g. multiple media engines, which are
-* mapped to the same class identifier and so are not separately
-* reported for busyness.
+* Some hardware may have parallel execution engines, e.g. multiple
+* media engines, which are mapped to the same class identifier and so
+* are not separately reported for busyness.
 *
 * Caveat emptor:
 * Only the boolean result of this query is reliable; that is whether
-- 
2.30.2

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

Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant

[Srinivas, Vidya]

Hello Bhanu,

I have uploaded version 3 where I have not removed primary plane.
Instead I have added a commit of the primary plane and I have changed alpha.
This passes on Gen11 systems.

Kindly check https://patchwork.freedesktop.org/patch/438831/?series=90828&rev=3 
and suggest.

Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Friday, June 11, 2021 1:00 PM
To: Modem, Bhanuprakash ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is 
also not helping.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash 
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

> From: Intel-gfx  On Behalf Of 
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: 
> Don't set primary fb color in coverage-vs-premult-vs-constant
> 
> Patch removes setting primary fb color in 
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11 
> systems.

I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and 
"pixel blend mode"), is this test failing on a particular plane?

- Bhanu

> Similar change has already been done in tests constant_alpha_min and 
> basic_alpha where the test runs on all planes but dont set the primary 
> fb color.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t 
> *data, enum pipe pipe, igt_plane_t
>   igt_display_t *display = &data->display;
>   igt_crc_t ref_crc = {}, crc = {};
> 
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(&display->pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), &data->gray_fb);
> -
>   igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
>   igt_plane_set_fb(plane, &data->argb_fb_cov_7e);
>   igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Intel]

On 6/11/21 1:13 PM, Joonas Lahtinen wrote:

Quoting Joonas Lahtinen (2021-06-11 13:40:56)

Quoting Maarten Lankhorst (2021-06-11 12:27:15)

Pull request for drm-misc-next and drm-intel-gt-next.

topic/i915-ttm-2021-06-11:
drm-misc and drm-intel pull request for topic/i915-ttm:
- Convert i915 lmem handling to ttm.
- Add a patch to temporarily add a driver_private member to vma_node.
- Use this to allow mixed object mmap handling for i915.
The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:

   Merge tag 'exynos-drm-next-for-v5.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next 
(2021-06-11 14:19:12 +1000)

This base is not in drm-misc-next or drm-intel-gt-next, so effectively
we would end up pulling 478 extra commits from drm-next as a result. And
also causing all the warnings for those commits. I don't think we should
do that?

The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
"Merge tag 'drm-intel-gt-next-2021-05-28' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next"
Should we re-do the topic branch based on that?

This problem seems to come from the fact that only the PR from yesterday
that got merged to drm-next had the dependency patches. The previous
backmerge of drm-next was requested too early.

I've solved this with least hassle by backmerging drm-next again and
then applying the PR to drm-intel-gt-next.


Yeah, that was motivated by our first i915 ttm patches IIRC depending on 
some recent changes in TTM, and then in addition we made changes to TTM 
that we were asked to merge through drm-misc-next to avoid conflicts. In 
hindsight it might have actually been better to merge the TTM changes 
through drm-intel-gt-next and take responsibility of resolving i915/TTM 
conflicts as they appear in drm-tip...


/Thomas


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

Re: [Intel-gfx] [PATCH 06/10] vfio/mdev: Remove CONFIG_VFIO_MDEV_DEVICE

[Cornelia Huck]

On Mon, Jun 07 2021, Jason Gunthorpe  wrote:

> For some reason the vfio_mdev shim mdev_driver has its own module and
> kconfig. As the next patch requires access to it from mdev.ko merge the
> two modules together and remove VFIO_MDEV_DEVICE.
>
> A later patch deletes this driver entirely.
>
> Signed-off-by: Jason Gunthorpe 
> ---
>  Documentation/s390/vfio-ap.rst   |  1 -
>  arch/s390/Kconfig|  2 +-
>  drivers/gpu/drm/i915/Kconfig |  2 +-
>  drivers/vfio/mdev/Kconfig|  7 ---
>  drivers/vfio/mdev/Makefile   |  3 +--
>  drivers/vfio/mdev/mdev_core.c| 16 ++--
>  drivers/vfio/mdev/mdev_private.h |  2 ++
>  drivers/vfio/mdev/vfio_mdev.c| 24 +---
>  samples/Kconfig  |  6 +++---
>  9 files changed, 23 insertions(+), 40 deletions(-)

I think you missed my earlier

Reviewed-by: Cornelia Huck 

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

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add relocation exceptions for two other platforms (rev6)

[Zbigniew Kempczyński]

On Fri, Jun 11, 2021 at 10:41:19AM +, Patchwork wrote:
>Patch Details
> 
>Series:  drm/i915: Add relocation exceptions for two other platforms 
> (rev6)  
>URL: https://patchwork.freedesktop.org/series/89594/   
>   
>State:   failure   
>   
>Details: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/index.html 
> 
>   CI Bug Log - changes from CI_DRM_10209_full -> Patchwork_20342_full
> 
> Summary
> 
>FAILURE
> 
>Serious unknown changes coming with Patchwork_20342_full absolutely need
>to be
>verified manually.
> 
>If you think the reported changes have nothing to do with the changes
>introduced in Patchwork_20342_full, 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_20342/index.html
> 
> Possible new issues
> 
>Here are the unknown changes that may have been introduced in
>Patchwork_20342_full:
> 
>   IGT changes
> 
> Possible regressions
> 
>  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
>   * shard-glk: PASS -> INCOMPLETE

Unrelated, patch enables relocations on ADL when require_force_probe flag is 
set.

--
Zbigniew

> 
> Known issues
> 
>Here are the changes found in Patchwork_20342_full that come from known
>issues:
> 
>   IGT changes
> 
> Issues hit
> 
>  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
> 
>   * shard-snb: NOTRUN -> SKIP (fdo#109271 / i915#1099) +3 similar
> issues
>  * igt@gem_ctx_persistence@smoketest:
> 
>   * shard-kbl: PASS -> FAIL (i915#2896)
>  * igt@gem_eio@unwedge-stress:
> 
>   * shard-snb: NOTRUN -> FAIL (i915#3354)
>  * igt@gem_exec_fair@basic-none-vip@rcs0:
> 
>   * shard-kbl: PASS -> FAIL (i915#2842)
>  * igt@gem_exec_fair@basic-none@vcs1:
> 
>   * shard-iclb: NOTRUN -> FAIL (i915#2842)
>  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
> 
>   * shard-iclb: PASS -> FAIL (i915#307)
>  * igt@gem_pwrite@basic-exhaustion:
> 
>   * shard-kbl: NOTRUN -> WARN (i915#2658)
>  * igt@gem_userptr_blits@dmabuf-sync:
> 
>   * shard-apl: NOTRUN -> SKIP (fdo#109271 / i915#3323)
>  * igt@gem_userptr_blits@vma-merge:
> 
>   * shard-apl: NOTRUN -> FAIL (i915#3318)
> 
>   * shard-kbl: NOTRUN -> FAIL (i915#3318)
> 
>  * igt@gen9_exec_parse@bb-large:
> 
>   * shard-apl: NOTRUN -> FAIL (i915#3296)
>  * igt@i915_pm_dc@dc6-dpms:
> 
>   * shard-skl: NOTRUN -> FAIL (i915#454)
>  * igt@i915_pm_dc@dc6-psr:
> 
>   * shard-skl: PASS -> FAIL (i915#454)
>  * igt@i915_selftest@live@execlists:
> 
>   * shard-apl: NOTRUN -> DMESG-FAIL (i915#3462)
>  * igt@i915_suspend@debugfs-reader:
> 
>   * shard-skl: PASS -> INCOMPLETE (i915#198)
>  * igt@kms_ccs@pipe-a-ccs-on-another-bo:
> 
>   * shard-snb: NOTRUN -> SKIP (fdo#109271) +336 similar issues
>  * igt@kms_ccs@pipe-c-ccs-on-another-bo:
> 
>   * shard-skl: NOTRUN -> SKIP (fdo#109271 / fdo#111304)
>  * igt@kms_chamelium@hdmi-aspect-ratio:
> 
>   * shard-kbl: NOTRUN -> SKIP (fdo#109271 / fdo#111827) +5 similar
> issues
>  * igt@kms_chamelium@hdmi-mode-timings:
> 
>   * shard-snb: NOTRUN -> SKIP (fdo#109271 / fdo#111827) +20 similar
> issues
>  * igt@kms_color_chamelium@pipe-a-ctm-limited-range:
> 
>   * shard-apl: NOTRUN -> SKIP (fdo#109271 / fdo#111827) +16 similar
> issues
>  * igt@kms_color_chamelium@pipe-d-degamma:
> 
>   * shard-skl: NOTRUN -> SKIP (fdo#109271 / fdo#111827) +3 similar
> issues
>  * igt@kms_content_protection@atomic-dpms:
> 
>   * shard-kbl: NOTRUN -> TIMEOUT (i915#1319)
>  * igt@kms_cursor_crc@pipe-b-cursor-suspend:
> 
>   * shard-kbl: NOTRUN -> DMESG-WARN (i915#180)
>  * igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen:
> 
>   * shard-glk: PASS -> FAIL (i915#3444)
>  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
> 
>   * shard-kbl: PASS -> DMESG-WARN (i915#180) +1 similar issue
> 
>   * shard-apl: PASS -> DMESG-WARN (i915#180)
> 
>  * igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1:
> 
>   * shard-skl: PASS -> FAIL (i915#2122)
>  * igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile:
> 
>   * shard-skl: NOTRUN -> SKIP (fdo#109271 / i915#2642)
>  * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
> 
>   * shard-apl: NOTRUN -> SKIP (fdo#109271 / i915#2672)
>  * 
> igt@kms_frontbuffer_tracking@fbcpsr-2p-primscrn-spr-indfb-draw-mmap-gtt:
> 
>   * shard-skl: NOTRUN -> SKIP (fdo#109271) +35 similar issues
>  * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-ren

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

[Christian König]

Am 11.06.21 um 09:20 schrieb Daniel Vetter:

On Fri, Jun 11, 2021 at 8:55 AM Christian König
 wrote:

Am 10.06.21 um 22:42 schrieb Daniel Vetter:

On Thu, Jun 10, 2021 at 10:10 PM Jason Ekstrand  wrote:

On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand  wrote:

On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter  wrote:

On Thu, Jun 10, 2021 at 11:39 AM Christian König
 wrote:

Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:

On 09/06/2021 22:29, Jason Ekstrand wrote:

We've tried to keep it somewhat contained by doing most of the hard work
to prevent access of recycled objects via dma_fence_get_rcu_safe().
However, a quick grep of kernel sources says that, of the 30 instances
of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_safe().
It's likely there bear traps in DRM and related subsystems just waiting
for someone to accidentally step in them.

...because dma_fence_get_rcu_safe apears to be about whether the
*pointer* to the fence itself is rcu protected, not about the fence
object itself.

Yes, exactly that.

The fact that both of you think this either means that I've completely
missed what's going on with RCUs here (possible but, in this case, I
think unlikely) or RCUs on dma fences should scare us all.

Taking a step back for a second and ignoring SLAB_TYPESAFE_BY_RCU as
such,  I'd like to ask a slightly different question:  What are the
rules about what is allowed to be done under the RCU read lock and
what guarantees does a driver need to provide?

I think so far that we've all agreed on the following:

   1. Freeing an unsignaled fence is ok as long as it doesn't have any
pending callbacks.  (Callbacks should hold a reference anyway).

   2. The pointer race solved by dma_fence_get_rcu_safe is real and
requires the loop to sort out.

But let's say I have a dma_fence pointer that I got from, say, calling
dma_resv_excl_fence() under rcu_read_lock().  What am I allowed to do
with it under the RCU lock?  What assumptions can I make?  Is this
code, for instance, ok?

rcu_read_lock();
fence = dma_resv_excl_fence(obj);
idle = !fence || test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags);
rcu_read_unlock();

This code very much looks correct under the following assumptions:

   1. A valid fence pointer stays alive under the RCU read lock
   2. SIGNALED_BIT is set-once (it's never unset after being set).

However, if it were, we wouldn't have dma_resv_test_singnaled(), now
would we? :-)

The moment you introduce ANY dma_fence recycling that recycles a
dma_fence within a single RCU grace period, all your assumptions break
down.  SLAB_TYPESAFE_BY_RCU is just one way that i915 does this.  We
also have a little i915_request recycler to try and help with memory
pressure scenarios in certain critical sections that also doesn't
respect RCU grace periods.  And, as mentioned multiple times, our
recycling leaks into every other driver because, thanks to i915's
choice, the above 4-line code snippet isn't valid ANYWHERE in the
kernel.

So the question I'm raising isn't so much about the rules today.
Today, we live in the wild wild west where everything is YOLO.  But
where do we want to go?  Do we like this wild west world?  So we want
more consistency under the RCU read lock?  If so, what do we want the
rules to be?

One option would be to accept the wild-west world we live in and say
"The RCU read lock gains you nothing.  If you want to touch the guts
of a dma_fence, take a reference".  But, at that point, we're eating
two atomics for every time someone wants to look at a dma_fence.  Do
we want that?

Alternatively, and this what I think Daniel and I were trying to
propose here, is that we place some constraints on dma_fence
recycling.  Specifically that, under the RCU read lock, the fence
doesn't suddenly become a new fence.  All of the immutability and
once-mutability guarantees of various bits of dma_fence hold as long
as you have the RCU read lock.

Yeah this is suboptimal. Too many potential bugs, not enough benefits.

This entire __rcu business started so that there would be a lockless
way to get at fences, or at least the exclusive one. That did not
really pan out. I think we have a few options:

- drop the idea of rcu/lockless dma-fence access outright. A quick
sequence of grabbing the lock, acquiring the dma_fence and then
dropping your lock again is probably plenty good. There's a lot of
call_rcu and other stuff we could probably delete. I have no idea what
the perf impact across all the drivers would be.

The question is maybe not the perf impact, but rather if that is
possible over all.

IIRC we now have some cases in TTM where RCU is mandatory and we simply
don't have any other choice than using it.

Adding Thomas Hellstrom.

Where is that stuff? If we end up with all the dma_resv locking
complexity just for an oddball, then I think that would be rather big
bummer.


This is during buffer destruction. See the call to dma_resv_copy_fences().

But that is basically just using a dma_resv function which acc

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2021-06-11 13:40:56)
> Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> > Pull request for drm-misc-next and drm-intel-gt-next.
> > 
> > topic/i915-ttm-2021-06-11:
> > drm-misc and drm-intel pull request for topic/i915-ttm:
> > - Convert i915 lmem handling to ttm.
> > - Add a patch to temporarily add a driver_private member to vma_node.
> > - Use this to allow mixed object mmap handling for i915.
> > The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> > 
> >   Merge tag 'exynos-drm-next-for-v5.14' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> > drm-next (2021-06-11 14:19:12 +1000)
> 
> This base is not in drm-misc-next or drm-intel-gt-next, so effectively
> we would end up pulling 478 extra commits from drm-next as a result. And
> also causing all the warnings for those commits. I don't think we should
> do that?
> 
> The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
> "Merge tag 'drm-intel-gt-next-2021-05-28' of 
> git://anongit.freedesktop.org/drm/drm-intel into drm-next"
> Should we re-do the topic branch based on that?

This problem seems to come from the fact that only the PR from yesterday
that got merged to drm-next had the dependency patches. The previous
backmerge of drm-next was requested too early.

I've solved this with least hassle by backmerging drm-next again and
then applying the PR to drm-intel-gt-next.

I think drm-misc-next should do the same (exact commit was
1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2).

Regards, Joonas

> However the DIM docs[1] indeed do say: "For topic branches shared within
> the gpu/drm subsystem, base it on the latest drm-next branch." I think
> the docs don't take into account the current period where drm-next is
> being actively updated as we speak.
> 
> Should we update the docs to use 'git merge-base' or something else?
> 
> Regards, Joonas
> 
> [1]: 
> https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cross-subsystem-topic-branches
> 
> > 
> > are available in the Git repository at:
> > 
> >   git://anongit.freedesktop.org/drm/drm-misc tags/topic/i915-ttm-2021-06-11
> > 
> > for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:
> > 
> >   drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 +0200)
> > 
> > 
> > drm-misc and drm-intel pull request for topic/i915-ttm:
> > - Convert i915 lmem handling to ttm.
> > - Add a patch to temporarily add a driver_private member to vma_node.
> > - Use this to allow mixed object mmap handling for i915.
> > 
> > 
> > Maarten Lankhorst (2):
> >   drm/vma: Add a driver_private member to vma_node.
> >   drm/i915: Use ttm mmap handling for ttm bo's.
> > 
> > Thomas Hellström (2):
> >   drm/i915/ttm: Introduce a TTM i915 gem object backend
> >   drm/i915/lmem: Verify checks for lmem residency
> > 
> >  drivers/gpu/drm/drm_gem.c  |   9 -
> >  drivers/gpu/drm/i915/Makefile  |   1 +
> >  drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
> >  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
> >  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  83 ++-
> >  drivers/gpu/drm/i915/gem/i915_gem_object.c | 143 +++--
> >  drivers/gpu/drm/i915/gem/i915_gem_object.h |  19 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_object_types.h   |  30 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   3 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_region.c |   6 +-
> >  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 647 
> > +
> >  drivers/gpu/drm/i915/gem/i915_gem_ttm.h|  48 ++
> >  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c |  90 +--
> >  drivers/gpu/drm/i915/gt/intel_region_lmem.c|   3 +-
> >  drivers/gpu/drm/i915/i915_gem.c|   5 +-
> >  drivers/gpu/drm/i915/intel_memory_region.c |   1 -
> >  drivers/gpu/drm/i915/intel_memory_region.h |   1 -
> >  drivers/gpu/drm/i915/intel_region_ttm.c|   8 +-
> >  drivers/gpu/drm/i915/intel_region_ttm.h|  11 +-
> >  drivers/gpu/drm/i915/selftests/igt_mmap.c  |  25 +-
> >  drivers/gpu/drm/i915/selftests/igt_mmap.h  |  12 +-
> >  include/drm/drm_vma_manager.h  |   2 +-
> >  24 files changed, 1039 insertions(+), 250 deletions(-)
> >  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> >  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

[Christian König]

Am 10.06.21 um 22:42 schrieb Daniel Vetter:

On Thu, Jun 10, 2021 at 10:10 PM Jason Ekstrand  wrote:

On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand  wrote:

On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter  wrote:

On Thu, Jun 10, 2021 at 11:39 AM Christian König
 wrote:

Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:

On 09/06/2021 22:29, Jason Ekstrand wrote:

We've tried to keep it somewhat contained by doing most of the hard work
to prevent access of recycled objects via dma_fence_get_rcu_safe().
However, a quick grep of kernel sources says that, of the 30 instances
of dma_fence_get_rcu*, only 11 of them use dma_fence_get_rcu_safe().
It's likely there bear traps in DRM and related subsystems just waiting
for someone to accidentally step in them.

...because dma_fence_get_rcu_safe apears to be about whether the
*pointer* to the fence itself is rcu protected, not about the fence
object itself.

Yes, exactly that.

The fact that both of you think this either means that I've completely
missed what's going on with RCUs here (possible but, in this case, I
think unlikely) or RCUs on dma fences should scare us all.

Taking a step back for a second and ignoring SLAB_TYPESAFE_BY_RCU as
such,  I'd like to ask a slightly different question:  What are the
rules about what is allowed to be done under the RCU read lock and
what guarantees does a driver need to provide?

I think so far that we've all agreed on the following:

  1. Freeing an unsignaled fence is ok as long as it doesn't have any
pending callbacks.  (Callbacks should hold a reference anyway).

  2. The pointer race solved by dma_fence_get_rcu_safe is real and
requires the loop to sort out.

But let's say I have a dma_fence pointer that I got from, say, calling
dma_resv_excl_fence() under rcu_read_lock().  What am I allowed to do
with it under the RCU lock?  What assumptions can I make?  Is this
code, for instance, ok?

rcu_read_lock();
fence = dma_resv_excl_fence(obj);
idle = !fence || test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags);
rcu_read_unlock();

This code very much looks correct under the following assumptions:

  1. A valid fence pointer stays alive under the RCU read lock
  2. SIGNALED_BIT is set-once (it's never unset after being set).

However, if it were, we wouldn't have dma_resv_test_singnaled(), now
would we? :-)

The moment you introduce ANY dma_fence recycling that recycles a
dma_fence within a single RCU grace period, all your assumptions break
down.  SLAB_TYPESAFE_BY_RCU is just one way that i915 does this.  We
also have a little i915_request recycler to try and help with memory
pressure scenarios in certain critical sections that also doesn't
respect RCU grace periods.  And, as mentioned multiple times, our
recycling leaks into every other driver because, thanks to i915's
choice, the above 4-line code snippet isn't valid ANYWHERE in the
kernel.

So the question I'm raising isn't so much about the rules today.
Today, we live in the wild wild west where everything is YOLO.  But
where do we want to go?  Do we like this wild west world?  So we want
more consistency under the RCU read lock?  If so, what do we want the
rules to be?

One option would be to accept the wild-west world we live in and say
"The RCU read lock gains you nothing.  If you want to touch the guts
of a dma_fence, take a reference".  But, at that point, we're eating
two atomics for every time someone wants to look at a dma_fence.  Do
we want that?

Alternatively, and this what I think Daniel and I were trying to
propose here, is that we place some constraints on dma_fence
recycling.  Specifically that, under the RCU read lock, the fence
doesn't suddenly become a new fence.  All of the immutability and
once-mutability guarantees of various bits of dma_fence hold as long
as you have the RCU read lock.

Yeah this is suboptimal. Too many potential bugs, not enough benefits.

This entire __rcu business started so that there would be a lockless
way to get at fences, or at least the exclusive one. That did not
really pan out. I think we have a few options:

- drop the idea of rcu/lockless dma-fence access outright. A quick
sequence of grabbing the lock, acquiring the dma_fence and then
dropping your lock again is probably plenty good. There's a lot of
call_rcu and other stuff we could probably delete. I have no idea what
the perf impact across all the drivers would be.


The question is maybe not the perf impact, but rather if that is 
possible over all.


IIRC we now have some cases in TTM where RCU is mandatory and we simply 
don't have any other choice than using it.



- try to make all drivers follow some stricter rules. The trouble is
that at least with radeon dma_fence callbacks aren't even very
reliable (that's why it has its own dma_fence_wait implementation), so
things are wobbly anyway.

- live with the current situation, but radically delete all unsafe
interfaces. I.e. nothing is allowed to directly deref an rcu fence
pointer, everything goes through dma_fence_g

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add relocation exceptions for two other platforms (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915: Add relocation exceptions for two other platforms (rev6)
URL   : https://patchwork.freedesktop.org/series/89594/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10209_full -> Patchwork_20342_full


Summary
---

  **FAILURE**

  Serious unknown changes coming with Patchwork_20342_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_20342_full, 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_20342/index.html

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-glk9/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-glk1/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +3 
similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_ctx_persistence@smoketest:
- shard-kbl:  [PASS][4] -> [FAIL][5] ([i915#2896])
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-kbl2/igt@gem_ctx_persiste...@smoketest.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-kbl3/igt@gem_ctx_persiste...@smoketest.html

  * igt@gem_eio@unwedge-stress:
- shard-snb:  NOTRUN -> [FAIL][6] ([i915#3354])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-snb6/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl:  [PASS][7] -> [FAIL][8] ([i915#2842])
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-kbl3/igt@gem_exec_fair@basic-none-...@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_20342/shard-iclb4/igt@gem_exec_fair@basic-n...@vcs1.html

  * igt@gem_mmap_gtt@cpuset-big-copy-xy:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#307])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy-xy.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-xy.html

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

  * igt@gem_userptr_blits@dmabuf-sync:
- shard-apl:  NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3323])
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-apl1/igt@gem_userptr_bl...@dmabuf-sync.html

  * igt@gem_userptr_blits@vma-merge:
- shard-apl:  NOTRUN -> [FAIL][14] ([i915#3318])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-apl8/igt@gem_userptr_bl...@vma-merge.html
- shard-kbl:  NOTRUN -> [FAIL][15] ([i915#3318])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-kbl7/igt@gem_userptr_bl...@vma-merge.html

  * igt@gen9_exec_parse@bb-large:
- shard-apl:  NOTRUN -> [FAIL][16] ([i915#3296])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-apl8/igt@gen9_exec_pa...@bb-large.html

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

  * igt@i915_pm_dc@dc6-psr:
- shard-skl:  [PASS][18] -> [FAIL][19] ([i915#454])
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-skl4/igt@i915_pm...@dc6-psr.html
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-skl6/igt@i915_pm...@dc6-psr.html

  * igt@i915_selftest@live@execlists:
- shard-apl:  NOTRUN -> [DMESG-FAIL][20] ([i915#3462])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/shard-apl1/igt@i915_selftest@l...@execlists.html

  * igt@i915_suspend@debugfs-rea

Re: [Intel-gfx] [PULL] topic/i915-ttm

[Joonas Lahtinen]

Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> Pull request for drm-misc-next and drm-intel-gt-next.
> 
> topic/i915-ttm-2021-06-11:
> drm-misc and drm-intel pull request for topic/i915-ttm:
> - Convert i915 lmem handling to ttm.
> - Add a patch to temporarily add a driver_private member to vma_node.
> - Use this to allow mixed object mmap handling for i915.
> The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:
> 
>   Merge tag 'exynos-drm-next-for-v5.14' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into 
> drm-next (2021-06-11 14:19:12 +1000)

This base is not in drm-misc-next or drm-intel-gt-next, so effectively
we would end up pulling 478 extra commits from drm-next as a result. And
also causing all the warnings for those commits. I don't think we should
do that?

The common ancestor would be ccd1950c2f7e38ae45aeefb99a08b39407cd6c63
"Merge tag 'drm-intel-gt-next-2021-05-28' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next"
Should we re-do the topic branch based on that?

However the DIM docs[1] indeed do say: "For topic branches shared within
the gpu/drm subsystem, base it on the latest drm-next branch." I think
the docs don't take into account the current period where drm-next is
being actively updated as we speak.

Should we update the docs to use 'git merge-base' or something else?

Regards, Joonas

[1]: 
https://drm.pages.freedesktop.org/maintainer-tools/dim.html#cross-subsystem-topic-branches

> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm-misc tags/topic/i915-ttm-2021-06-11
> 
> for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:
> 
>   drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 +0200)
> 
> 
> drm-misc and drm-intel pull request for topic/i915-ttm:
> - Convert i915 lmem handling to ttm.
> - Add a patch to temporarily add a driver_private member to vma_node.
> - Use this to allow mixed object mmap handling for i915.
> 
> 
> Maarten Lankhorst (2):
>   drm/vma: Add a driver_private member to vma_node.
>   drm/i915: Use ttm mmap handling for ttm bo's.
> 
> Thomas Hellström (2):
>   drm/i915/ttm: Introduce a TTM i915 gem object backend
>   drm/i915/lmem: Verify checks for lmem residency
> 
>  drivers/gpu/drm/drm_gem.c  |   9 -
>  drivers/gpu/drm/i915/Makefile  |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
>  drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
>  drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
>  drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
>  drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  83 ++-
>  drivers/gpu/drm/i915/gem/i915_gem_object.c | 143 +++--
>  drivers/gpu/drm/i915/gem/i915_gem_object.h |  19 +-
>  drivers/gpu/drm/i915/gem/i915_gem_object_types.h   |  30 +-
>  drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   3 +-
>  drivers/gpu/drm/i915/gem/i915_gem_region.c |   6 +-
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 647 
> +
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.h|  48 ++
>  drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c |  90 +--
>  drivers/gpu/drm/i915/gt/intel_region_lmem.c|   3 +-
>  drivers/gpu/drm/i915/i915_gem.c|   5 +-
>  drivers/gpu/drm/i915/intel_memory_region.c |   1 -
>  drivers/gpu/drm/i915/intel_memory_region.h |   1 -
>  drivers/gpu/drm/i915/intel_region_ttm.c|   8 +-
>  drivers/gpu/drm/i915/intel_region_ttm.h|  11 +-
>  drivers/gpu/drm/i915/selftests/igt_mmap.c  |  25 +-
>  drivers/gpu/drm/i915/selftests/igt_mmap.h  |  12 +-
>  include/drm/drm_vma_manager.h  |   2 +-
>  24 files changed, 1039 insertions(+), 250 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>  create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable
URL   : https://patchwork.freedesktop.org/series/91372/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10209_full -> Patchwork_20341_full


Summary
---

  **FAILURE**

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

  

Possible new issues
---

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

### IGT changes ###

 Possible regressions 

  * igt@kms_flip@2x-flip-vs-suspend@ab-hdmi-a1-hdmi-a2:
- shard-glk:  [PASS][1] -> [INCOMPLETE][2]
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-glk9/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-glk9/igt@kms_flip@2x-flip-vs-susp...@ab-hdmi-a1-hdmi-a2.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-onoff:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-onoff.html
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-onoff.html

  
Known issues


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

### IGT changes ###

 Issues hit 

  * igt@gem_ctx_persistence@legacy-engines-mixed-process:
- shard-snb:  NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +1 
similar issue
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed-process.html

  * igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2410])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html

  * igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: [PASS][8] -> [TIMEOUT][9] ([i915#3070])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-iclb5/igt@gem_...@in-flight-contexts-10ms.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-iclb3/igt@gem_...@in-flight-contexts-10ms.html

  * igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][10] -> [TIMEOUT][11] ([i915#2369] / 
[i915#3063])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-tglb7/igt@gem_...@unwedge-stress.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-tglb3/igt@gem_...@unwedge-stress.html
- shard-iclb: [PASS][12] -> [TIMEOUT][13] ([i915#2369] / 
[i915#2481] / [i915#3070])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-iclb5/igt@gem_...@unwedge-stress.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-iclb4/igt@gem_...@unwedge-stress.html
- shard-snb:  NOTRUN -> [FAIL][14] ([i915#3354])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-snb7/igt@gem_...@unwedge-stress.html

  * igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk:  [PASS][15] -> [FAIL][16] ([i915#2842])
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-glk6/igt@gem_exec_fair@basic-none-r...@rcs0.html

  * igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl:  [PASS][17] -> [FAIL][18] ([i915#2842]) +2 similar 
issues
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html
   [18]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html

  * igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-kbl:  NOTRUN -> [FAIL][19] ([i915#2389]) +4 similar issues
   [19]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-kbl7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html

  * igt@gem_exec_whisper@basic-fds-forked:
- shard-glk:  [PASS][20] -> [DMESG-WARN][21] ([i915#118] / 
[i915#95])
   [20]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/shard-glk2/igt@gem_exec_whis...@basic-fds-forked.html
   [21]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20341/shard-glk9/igt@gem_exec_whis...@basic-fds-forked.html

  * igt@gem_mmap_gtt@big-copy-xy:
- shard-glk:  [PASS][22] 

[Intel-gfx] [PATCH] drm/i915/xelpd: Enabling dithering after the CC1

[Nischal Varide]

If the panel is 12bpc then Dithering is not enabled in the Legacy
dithering block , instead its Enabled after the C1 CC1 pipe post
color space conversion.For a 6bpc pannel Dithering is enabled in
Legacy block.

Signed-off-by: Nischal Varide 
---
 drivers/gpu/drm/i915/display/intel_color.c   |  7 +++
 drivers/gpu/drm/i915/display/intel_display.c | 11 ++-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_color.c 
b/drivers/gpu/drm/i915/display/intel_color.c
index dab892d2251b..c7af583200c4 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -1574,6 +1574,7 @@ static int glk_color_check(struct intel_crtc_state 
*crtc_state)
 static u32 icl_gamma_mode(const struct intel_crtc_state *crtc_state)
 {
u32 gamma_mode = 0;
+   struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
 
if (crtc_state->hw.degamma_lut)
gamma_mode |= PRE_CSC_GAMMA_ENABLE;
@@ -1588,6 +1589,12 @@ static u32 icl_gamma_mode(const struct intel_crtc_state 
*crtc_state)
else
gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED;
 
+   if (DISPLAY_VER(i915) >= 13) {
+   if (!crtc_state->dither_force_disable &&
+   (crtc_state->pipe_bpp == 36))
+   gamma_mode |= POST_CC1_DITHER_ENABLE;
+   }
+
return gamma_mode;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 362bff9beb5c..3a7feb246745 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5762,7 +5762,16 @@ static void bdw_set_pipemisc(const struct 
intel_crtc_state *crtc_state)
break;
}
 
-   if (crtc_state->dither)
+   /*
+* If 12bpc panel then, Enables dithering after the CC1 pipe
+* post color space conversion and not here for display_ver
+* greater than or equal to thirteen.
+*/
+
+   if (crtc_state->dither && (crtc_state->pipe_bpp != 36))
+   val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
+
+   if (crtc_state->dither && (crtc_state->pipe_bpp == 36) && 
(DISPLAY_VER(dev_priv) < 13))
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
 
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e915ec034c98..33dba13fa94d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7743,6 +7743,7 @@ enum {
 #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
 #define  PRE_CSC_GAMMA_ENABLE  (1 << 31)
 #define  POST_CSC_GAMMA_ENABLE (1 << 30)
+#define  POST_CC1_DITHER_ENABLE (1 << 26)
 #define  GAMMA_MODE_MODE_MASK  (3 << 0)
 #define  GAMMA_MODE_MODE_8BIT  (0 << 0)
 #define  GAMMA_MODE_MODE_10BIT (1 << 0)
-- 
2.29.2

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

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

[Daniel Vetter]

On Fri, Jun 11, 2021 at 09:42:07AM +0200, Christian König wrote:
> Am 11.06.21 um 09:20 schrieb Daniel Vetter:
> > On Fri, Jun 11, 2021 at 8:55 AM Christian König
> >  wrote:
> > > Am 10.06.21 um 22:42 schrieb Daniel Vetter:
> > > > On Thu, Jun 10, 2021 at 10:10 PM Jason Ekstrand  
> > > > wrote:
> > > > > On Thu, Jun 10, 2021 at 8:35 AM Jason Ekstrand  
> > > > > wrote:
> > > > > > On Thu, Jun 10, 2021 at 6:30 AM Daniel Vetter 
> > > > > >  wrote:
> > > > > > > On Thu, Jun 10, 2021 at 11:39 AM Christian König
> > > > > > >  wrote:
> > > > > > > > Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin:
> > > > > > > > > On 09/06/2021 22:29, Jason Ekstrand wrote:
> > > > > > > > > > We've tried to keep it somewhat contained by doing most of 
> > > > > > > > > > the hard work
> > > > > > > > > > to prevent access of recycled objects via 
> > > > > > > > > > dma_fence_get_rcu_safe().
> > > > > > > > > > However, a quick grep of kernel sources says that, of the 
> > > > > > > > > > 30 instances
> > > > > > > > > > of dma_fence_get_rcu*, only 11 of them use 
> > > > > > > > > > dma_fence_get_rcu_safe().
> > > > > > > > > > It's likely there bear traps in DRM and related subsystems 
> > > > > > > > > > just waiting
> > > > > > > > > > for someone to accidentally step in them.
> > > > > > > > > ...because dma_fence_get_rcu_safe apears to be about whether 
> > > > > > > > > the
> > > > > > > > > *pointer* to the fence itself is rcu protected, not about the 
> > > > > > > > > fence
> > > > > > > > > object itself.
> > > > > > > > Yes, exactly that.
> > > > > > The fact that both of you think this either means that I've 
> > > > > > completely
> > > > > > missed what's going on with RCUs here (possible but, in this case, I
> > > > > > think unlikely) or RCUs on dma fences should scare us all.
> > > > > Taking a step back for a second and ignoring SLAB_TYPESAFE_BY_RCU as
> > > > > such,  I'd like to ask a slightly different question:  What are the
> > > > > rules about what is allowed to be done under the RCU read lock and
> > > > > what guarantees does a driver need to provide?
> > > > > 
> > > > > I think so far that we've all agreed on the following:
> > > > > 
> > > > >1. Freeing an unsignaled fence is ok as long as it doesn't have any
> > > > > pending callbacks.  (Callbacks should hold a reference anyway).
> > > > > 
> > > > >2. The pointer race solved by dma_fence_get_rcu_safe is real and
> > > > > requires the loop to sort out.
> > > > > 
> > > > > But let's say I have a dma_fence pointer that I got from, say, calling
> > > > > dma_resv_excl_fence() under rcu_read_lock().  What am I allowed to do
> > > > > with it under the RCU lock?  What assumptions can I make?  Is this
> > > > > code, for instance, ok?
> > > > > 
> > > > > rcu_read_lock();
> > > > > fence = dma_resv_excl_fence(obj);
> > > > > idle = !fence || test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags);
> > > > > rcu_read_unlock();
> > > > > 
> > > > > This code very much looks correct under the following assumptions:
> > > > > 
> > > > >1. A valid fence pointer stays alive under the RCU read lock
> > > > >2. SIGNALED_BIT is set-once (it's never unset after being set).
> > > > > 
> > > > > However, if it were, we wouldn't have dma_resv_test_singnaled(), now
> > > > > would we? :-)
> > > > > 
> > > > > The moment you introduce ANY dma_fence recycling that recycles a
> > > > > dma_fence within a single RCU grace period, all your assumptions break
> > > > > down.  SLAB_TYPESAFE_BY_RCU is just one way that i915 does this.  We
> > > > > also have a little i915_request recycler to try and help with memory
> > > > > pressure scenarios in certain critical sections that also doesn't
> > > > > respect RCU grace periods.  And, as mentioned multiple times, our
> > > > > recycling leaks into every other driver because, thanks to i915's
> > > > > choice, the above 4-line code snippet isn't valid ANYWHERE in the
> > > > > kernel.
> > > > > 
> > > > > So the question I'm raising isn't so much about the rules today.
> > > > > Today, we live in the wild wild west where everything is YOLO.  But
> > > > > where do we want to go?  Do we like this wild west world?  So we want
> > > > > more consistency under the RCU read lock?  If so, what do we want the
> > > > > rules to be?
> > > > > 
> > > > > One option would be to accept the wild-west world we live in and say
> > > > > "The RCU read lock gains you nothing.  If you want to touch the guts
> > > > > of a dma_fence, take a reference".  But, at that point, we're eating
> > > > > two atomics for every time someone wants to look at a dma_fence.  Do
> > > > > we want that?
> > > > > 
> > > > > Alternatively, and this what I think Daniel and I were trying to
> > > > > propose here, is that we place some constraints on dma_fence
> > > > > recycling.  Specifically that, under the RCU read lock, the fence
> > > > > doesn't suddenly become a new fence.  All of the immutability and
> > > > > once-mutability guarantees of 

[Intel-gfx] [PULL] topic/i915-ttm

[Maarten Lankhorst]

Pull request for drm-misc-next and drm-intel-gt-next.

topic/i915-ttm-2021-06-11:
drm-misc and drm-intel pull request for topic/i915-ttm:
- Convert i915 lmem handling to ttm.
- Add a patch to temporarily add a driver_private member to vma_node.
- Use this to allow mixed object mmap handling for i915.
The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2:

  Merge tag 'exynos-drm-next-for-v5.14' of 
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next 
(2021-06-11 14:19:12 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/topic/i915-ttm-2021-06-11

for you to fetch changes up to cf3e3e86d77970211e0983130e896ae242601003:

  drm/i915: Use ttm mmap handling for ttm bo's. (2021-06-11 10:53:25 +0200)


drm-misc and drm-intel pull request for topic/i915-ttm:
- Convert i915 lmem handling to ttm.
- Add a patch to temporarily add a driver_private member to vma_node.
- Use this to allow mixed object mmap handling for i915.


Maarten Lankhorst (2):
  drm/vma: Add a driver_private member to vma_node.
  drm/i915: Use ttm mmap handling for ttm bo's.

Thomas Hellström (2):
  drm/i915/ttm: Introduce a TTM i915 gem object backend
  drm/i915/lmem: Verify checks for lmem residency

 drivers/gpu/drm/drm_gem.c  |   9 -
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/display/intel_display.c   |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_create.c |   9 +-
 drivers/gpu/drm/i915/gem/i915_gem_lmem.c   | 126 ++--
 drivers/gpu/drm/i915/gem/i915_gem_lmem.h   |   5 -
 drivers/gpu/drm/i915/gem/i915_gem_mman.c   |  83 ++-
 drivers/gpu/drm/i915/gem/i915_gem_object.c | 143 +++--
 drivers/gpu/drm/i915/gem/i915_gem_object.h |  19 +-
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h   |  30 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c  |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_region.c |   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 647 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h|  48 ++
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c |  90 +--
 drivers/gpu/drm/i915/gt/intel_region_lmem.c|   3 +-
 drivers/gpu/drm/i915/i915_gem.c|   5 +-
 drivers/gpu/drm/i915/intel_memory_region.c |   1 -
 drivers/gpu/drm/i915/intel_memory_region.h |   1 -
 drivers/gpu/drm/i915/intel_region_ttm.c|   8 +-
 drivers/gpu/drm/i915/intel_region_ttm.h|  11 +-
 drivers/gpu/drm/i915/selftests/igt_mmap.c  |  25 +-
 drivers/gpu/drm/i915/selftests/igt_mmap.h  |  12 +-
 include/drm/drm_vma_manager.h  |   2 +-
 24 files changed, 1039 insertions(+), 250 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.c
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm.h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add relocation exceptions for two other platforms

[Rodrigo Vivi]

On Fri, Jun 11, 2021 at 08:09:00AM +0200, Zbigniew Kempczyński wrote:
> On Thu, Jun 10, 2021 at 10:36:12AM -0400, Rodrigo Vivi wrote:
> > On Thu, Jun 10, 2021 at 12:39:55PM +0200, Zbigniew Kempczyński wrote:
> > > We have established previously we stop using relocations starting
> > > from gen12 platforms with Tigerlake as an exception. We keep this
> > > statement but we want to enable relocations conditionally for
> > > Rocketlake and Alderlake under require_force_probe flag set.
> > > 
> > > Keeping relocations under require_force_probe flag is interim solution
> > > until IGTs will be rewritten to use softpin.
> > 
> > hmm... to be really honest I'm not so happy that we are introducing
> > a new criteria to the force_probe.
> > 
> > The criteria was to have a functional driver and not to track uapi.
> > 
> > But on the other hand I do recognize that the current definition
> > of the flag allows that, because we have established that with
> > this behavior, the "driver for new Intel graphics devices that
> > are recognized but not properly supported by this kernel version"
> > (as stated in the Kconfig for the DRM_I915_FORCE_PROBE).
> > 
> > However...
> > 
> > > 
> > > v2: - remove inline from function definition (Jani)
> > > - fix indentation
> > > 
> > > v3: change to GRAPHICS_VER() (Zbigniew)
> > > 
> > > Signed-off-by: Zbigniew Kempczyński 
> > > Cc: Dave Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Jason Ekstrand 
> > > Acked-by: Dave Airlie 
> > > ---
> > >  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 +++
> > >  1 file changed, 19 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index a8abc9af5ff4..30c4f0549ea0 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -491,16 +491,30 @@ eb_unreserve_vma(struct eb_vma *ev)
> > >   ev->flags &= ~__EXEC_OBJECT_RESERVED;
> > >  }
> > >  
> > > +static bool platform_has_relocs_enabled(const struct i915_execbuffer *eb)
> > > +{
> > > + /*
> > > +  * Relocations are disallowed starting from gen12 with Tigerlake
> > > +  * as an exception. We allow temporarily use relocations for Rocketlake
> > > +  * and Alderlake when require_force_probe flag is set.
> > > +  */
> > > + if (GRAPHICS_VER(eb->i915) < 12 || IS_TIGERLAKE(eb->i915))
> > > + return true;
> > > +
> > > + if (INTEL_INFO(eb->i915)->require_force_probe &&
> > > + (IS_ROCKETLAKE(eb->i915)
> > 
> > This ship has sailed... RKL is not protected by this flag any longer.
> > Should this be on the TGL side now?
> 
> +Lucas
> 
> I think no, RKL has relocations disabled so we cannot put it to TGL side.
> So if RKL is already released then putting it under require_force_probe 
> flag is wrong and only I can do is to remove it from that condition. 
> There's no option to unblock RKL on IGT CI until we rewrite all the tests.
> We have to rely then on ADL* with require_force_probe flag to check how
> ADL will work with relocations. 

So... I'm confused now. I'm missing the point of this patch then.
I thought the reason was to protect from any user space to attempt to
use the relocation, unless using the force_probe temporarily only for
these platforms.
But if I'm understanding correctly now it is only to silence CI?!
Is that the case?
Is the CI noise so bad?

> 
> > 
> > >  || IS_ALDERLAKE_S(eb->i915) ||
> > > +  IS_ALDERLAKE_P(eb->i915)))
> > 
> > How to ensure that we will easily catch this when removing the
> > flag?
> > 
> > I mean, should we have a GEM_BUG or drm_err message when these
> > platforms in this list has not the required_force_probe?
> 
> I don't think we need GEM_BUG()/drm_err() - when IGT tests will support
> both - reloc + no-reloc - then condition will be limited to:
> 
> if (GRAPHICS_VER(eb->i915) < 12 || IS_TIGERLAKE(eb->i915))
> return true;
>  
> return false;
> 
> so require_force_probe condition will be deleted and we won't need it
> anymore (IGTs will be ready).

yes...
but then, when we remove the flag we will forget to come here and remove
this check.

Oh, and I just thought that we might need drm_error when the protection
doesn't exist for the platform, but also a drm_info to the user to tell
this is a temporary accepted behavior, but that will be removed later

The concern is if any other userspace was using the flag and suddently move to a
version without the flag, it would be considered a regression...

> 
> --
> Zbigniew
> 
> > 
> > > + return true;
> > > +
> > > + return false;
> > > +}
> > > +
> > >  static int
> > >  eb_validate_vma(struct i915_execbuffer *eb,
> > >   struct drm_i915_gem_exec_object2 *entry,
> > >   struct i915_vma *vma)
> > >  {
> > > - /* Relocations are disallowed for all platforms after TGL-LP.  This
> > > -  * also covers all platforms with local memory.
> > > -  */

Re: [Intel-gfx] [PATCH v4 13/17] drm/i915/pxp: Enable PXP power management

[Rodrigo Vivi]

On Thu, Jun 10, 2021 at 03:58:13PM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 6/2/2021 9:20 AM, Rodrigo Vivi wrote:
> > On Mon, May 24, 2021 at 10:47:59PM -0700, Daniele Ceraolo Spurio wrote:
> > > From: "Huang, Sean Z" 
> > > 
> > > During the power event S3+ sleep/resume, hardware will lose all the
> > > encryption keys for every hardware session, even though the
> > > session state might still be marked as alive after resume. Therefore,
> > > we should consider the session as dead on suspend and invalidate all the
> > > objects. The session will be automatically restarted on the first
> > > protected submission on resume.
> > > 
> > > v2: runtime suspend also invalidates the keys
> > > v3: fix return codes, simplify rpm ops (Chris), use the new worker func
> > > v4: invalidate the objects on suspend, don't re-create the arb sesson on
> > > resume (delayed to first submission).
> > > 
> > > Signed-off-by: Huang, Sean Z 
> > > Signed-off-by: Daniele Ceraolo Spurio 
> > > Cc: Chris Wilson 
> > > Cc: Rodrigo Vivi 
> > > ---
> > >   drivers/gpu/drm/i915/Makefile|  1 +
> > >   drivers/gpu/drm/i915/gt/intel_gt_pm.c| 15 +++-
> > >   drivers/gpu/drm/i915/i915_drv.c  |  2 +
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 11 --
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_pm.c  | 40 
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_pm.h  | 23 +++
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 38 ++-
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_tee.c |  9 +
> > >   8 files changed, 124 insertions(+), 15 deletions(-)
> > >   create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
> > >   create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
> > > 
> > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> > > index 29331bbb3e98..9cce0bf9a50f 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -278,6 +278,7 @@ i915-$(CONFIG_DRM_I915_PXP) += \
> > >   pxp/intel_pxp.o \
> > >   pxp/intel_pxp_cmd.o \
> > >   pxp/intel_pxp_irq.o \
> > > + pxp/intel_pxp_pm.o \
> > >   pxp/intel_pxp_session.o \
> > >   pxp/intel_pxp_tee.o
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
> > > b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > > index aef3084e8b16..91151a02f7a2 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > > @@ -19,6 +19,7 @@
> > >   #include "intel_rc6.h"
> > >   #include "intel_rps.h"
> > >   #include "intel_wakeref.h"
> > > +#include "pxp/intel_pxp_pm.h"
> > >   static void user_forcewake(struct intel_gt *gt, bool suspend)
> > >   {
> > > @@ -265,6 +266,8 @@ int intel_gt_resume(struct intel_gt *gt)
> > >   intel_uc_resume(>->uc);
> > > + intel_pxp_resume(>->pxp);
> > > +
> > >   user_forcewake(gt, false);
> > >   out_fw:
> > > @@ -299,6 +302,7 @@ void intel_gt_suspend_prepare(struct intel_gt *gt)
> > >   user_forcewake(gt, true);
> > >   wait_for_suspend(gt);
> > > + intel_pxp_suspend(>->pxp);
> > >   intel_uc_suspend(>->uc);
> > >   }
> > > @@ -349,6 +353,7 @@ void intel_gt_suspend_late(struct intel_gt *gt)
> > >   void intel_gt_runtime_suspend(struct intel_gt *gt)
> > >   {
> > > + intel_pxp_suspend(>->pxp);
> > >   intel_uc_runtime_suspend(>->uc);
> > >   GT_TRACE(gt, "\n");
> > > @@ -356,11 +361,19 @@ void intel_gt_runtime_suspend(struct intel_gt *gt)
> > >   int intel_gt_runtime_resume(struct intel_gt *gt)
> > >   {
> > > + int ret;
> > > +
> > >   GT_TRACE(gt, "\n");
> > >   intel_gt_init_swizzling(gt);
> > >   intel_ggtt_restore_fences(gt->ggtt);
> > > - return intel_uc_runtime_resume(>->uc);
> > > + ret = intel_uc_runtime_resume(>->uc);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + intel_pxp_resume(>->pxp);
> > > +
> > > + return 0;
> > >   }
> > >   static ktime_t __intel_gt_get_awake_time(const struct intel_gt *gt)
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 2f06bb7b3ed2..6543e5577709 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -68,6 +68,8 @@
> > >   #include "gt/intel_gt_pm.h"
> > >   #include "gt/intel_rc6.h"
> > > +#include "pxp/intel_pxp_pm.h"
> > > +
> > >   #include "i915_debugfs.h"
> > >   #include "i915_drv.h"
> > >   #include "i915_ioc32.h"
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c 
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > > index a230d0034e50..9e5847c653f2 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
> > > @@ -9,6 +9,7 @@
> > >   #include "gt/intel_gt_irq.h"
> > >   #include "i915_irq.h"
> > >   #include "i915_reg.h"
> > > +#include "intel_runtime_pm.h"
> > >   /**
> > >* intel_pxp_irq_handler -

Re: [Intel-gfx] [PATCH v4 12/17] drm/i915/pxp: start the arb session on demand

[Rodrigo Vivi]

On Thu, Jun 10, 2021 at 03:44:37PM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 6/2/2021 11:14 AM, Rodrigo Vivi wrote:
> > On Mon, May 24, 2021 at 10:47:58PM -0700, Daniele Ceraolo Spurio wrote:
> > > Now that we can handle destruction and re-creation of the arb session,
> > > we can postpone the start of the session to the first submission that
> > > requires it, to avoid keeping it running with no user.
> > > 
> > > Signed-off-by: Daniele Ceraolo Spurio 
> > > ---
> > >   .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  8 ++--
> > >   drivers/gpu/drm/i915/pxp/intel_pxp.c  | 37 ---
> > >   drivers/gpu/drm/i915/pxp/intel_pxp.h  |  4 +-
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  |  2 +-
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  6 +--
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_tee.c  | 10 +
> > >   drivers/gpu/drm/i915/pxp/intel_pxp_types.h|  3 ++
> > >   7 files changed, 39 insertions(+), 31 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> > > b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > index a11e9d5767bf..c08e28847064 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > > @@ -2948,9 +2948,11 @@ eb_select_engine(struct i915_execbuffer *eb)
> > >   intel_gt_pm_get(ce->engine->gt);
> > >   if (i915_gem_context_uses_protected_content(eb->gem_context)) {
> > > - err = intel_pxp_wait_for_arb_start(&ce->engine->gt->pxp);
> > > - if (err)
> > > - goto err;
> > > + if (!intel_pxp_is_active(&ce->engine->gt->pxp)) {
> > > + err = intel_pxp_start(&ce->engine->gt->pxp);
> > > + if (err)
> > > + goto err;
> > > + }
> > >   if (i915_gem_context_invalidated(eb->gem_context)) {
> > >   err = -EACCES;
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c 
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > index f713d3423cea..2291c68fd3a0 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
> > > @@ -77,6 +77,7 @@ void intel_pxp_init(struct intel_pxp *pxp)
> > >   init_completion(&pxp->termination);
> > >   complete_all(&pxp->termination);
> > > + mutex_init(&pxp->arb_mutex);
> > >   INIT_WORK(&pxp->session_work, intel_pxp_session_work);
> > >   ret = create_vcs_context(pxp);
> > > @@ -113,7 +114,7 @@ void intel_pxp_mark_termination_in_progress(struct 
> > > intel_pxp *pxp)
> > >   reinit_completion(&pxp->termination);
> > >   }
> > > -static void intel_pxp_queue_termination(struct intel_pxp *pxp)
> > > +static void pxp_queue_termination(struct intel_pxp *pxp)
> > >   {
> > >   struct intel_gt *gt = pxp_to_gt(pxp);
> > > @@ -132,31 +133,41 @@ static void intel_pxp_queue_termination(struct 
> > > intel_pxp *pxp)
> > >* the arb session is restarted from the irq work when we receive the
> > >* termination completion interrupt
> > >*/
> > > -int intel_pxp_wait_for_arb_start(struct intel_pxp *pxp)
> > > +int intel_pxp_start(struct intel_pxp *pxp)
> > >   {
> > > + int ret = 0;
> > > +
> > >   if (!intel_pxp_is_enabled(pxp))
> > > - return 0;
> > > + return -ENODEV;
> > > +
> > > + mutex_lock(&pxp->arb_mutex);
> > > +
> > > + if (pxp->arb_is_valid)
> > > + goto unlock;
> > > +
> > > + pxp_queue_termination(pxp);
> > >   if (!wait_for_completion_timeout(&pxp->termination,
> > > -  msecs_to_jiffies(100)))
> > > - return -ETIMEDOUT;
> > > + msecs_to_jiffies(100))) {
> > > + ret = -ETIMEDOUT;
> > > + goto unlock;
> > > + }
> > > +
> > > + /* make sure the compiler doesn't optimize the double access */
> > > + barrier();
> > >   if (!pxp->arb_is_valid)
> > > - return -EIO;
> > > + ret = -EIO;
> > > - return 0;
> > > +unlock:
> > > + mutex_unlock(&pxp->arb_mutex);
> > > + return ret;
> > >   }
> > >   void intel_pxp_init_hw(struct intel_pxp *pxp)
> > >   {
> > >   kcr_pxp_enable(pxp_to_gt(pxp));
> > >   intel_pxp_irq_enable(pxp);
> > > -
> > > - /*
> > > -  * the session could've been attacked while we weren't loaded, so
> > > -  * handle it as if it was and re-create it.
> > > -  */
> > > - intel_pxp_queue_termination(pxp);
> > >   }
> > >   void intel_pxp_fini_hw(struct intel_pxp *pxp)
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h 
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > index 91c1a2056309..1f9871e64096 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > @@ -32,7 +32,7 @@ void intel_pxp_init_hw(struct intel_pxp *pxp);
> > >   void intel_pxp_fini_hw(struct intel_pxp *pxp);
> > >   void intel_pxp_mark_termination_in_progress(str

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms

[Srinivas, Vidya]

Hello Ville,

Apologies for bothering you.
Kms_prime goes through vgem_gem_dumb_create where the pitch gets calculated 
which is not 64 byte aligned.

kms_prime->vgem_gem_dumb_create->intel_framebuffer_init which reports plane 0 
pitch (5464) must be at least 64 byte aligned.

We have submitted this patch for kernel 
https://patchwork.freedesktop.org/patch/436199/ also for the same.
If we try to align stride in IGT after it gets back from vgem_gem_dumb_ioctl, 
Kernel gives error - [drm:intel_fill_fb_info] fb too big for bo (need 4227072 
bytes, have 4198400 bytes).

As a workaround (if the above kernel patch does not go through) we submitted 
this https://patchwork.freedesktop.org/patch/435794/.

Can you kindly help suggest which is the better way? If not both - kindly guide 
us how we can address this issue. Thank you so much.

Regards
Vidya

-Original Message-
From: Srinivas, Vidya 
Sent: Monday, May 31, 2021 8:18 PM
To: 'Ville Syrjälä' 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin, 
Charlton 
Subject: RE: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms

Hello Ville,

Thank you very much.
Before reaching our i915's i915_gem_dumb_create, it goes to 
vgem_gem_dumb_create for kms_prime.

The pitch gets calculated there and it is not 64 byte aligned. Due to this, 
intel_framebuffer_init reports "pitch must be 64 byte aligned"
and framebuffer creation fails. I tried submitting vgem patch where 64 byte 
alignment can be done in vgem_gem_dumb_create and that also passes. But we did 
not get approval yet as few of them felt, vgem is generic and other platforms 
might fail if we do 64 byte alignment there.

Kindly suggest. Thanks a lot.

Regards
Vidya

-Original Message-
From: Ville Syrjälä 
Sent: Monday, May 31, 2021 7:48 PM
To: Srinivas, Vidya 
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin, 
Charlton 
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 
byte for Intel platforms

On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> For Intel platforms, pitch needs to be 64 byte aligned.
> Kernel code vgem_gem_dumb_create which is platform generic code doesnt 
> do the alignment. This causes frame buffer creation to fail on Intel 
> platforms where the pitch is not 64 byte aligned.
> 
> tests: test run on Intel platforms with panel resolution 1366x768
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_prime.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> 8cb2ca2a9dc3..fdc941fe8100 100644
> --- a/tests/kms_prime.c
> +++ b/tests/kms_prime.c
> @@ -51,6 +51,8 @@ static struct {
>   { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x },  };
>  
> +bool check_platform;
> +
>  IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
>  
>  static bool has_prime_import(int fd)
> @@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct 
> dumb_bo *scratch,
>   scratch->bpp = 32;
>  
>   scratch->handle = kmstest_dumb_create(exporter_fd,
> - scratch->width,
> + check_platform? ALIGN(scratch->width, 64): 
> scratch->width,

The dumb_create ioctl already does this for us.

>   scratch->height,
>   scratch->bpp,
>   &scratch->pitch,
> @@ -262,6 +264,7 @@ igt_main
>  
>   /* ANY = anything that is not VGEM */
>   first_fd = __drm_open_driver_another(0, DRIVER_ANY | 
> DRIVER_VGEM);
> + check_platform = is_i915_device(first_fd);
>   igt_require(first_fd >= 0);
>  
>   second_fd = __drm_open_driver_another(1, DRIVER_ANY | 
> DRIVER_VGEM);
> --
> 2.7.4
> 
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev

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

Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't set primary fb color in coverage-vs-premult-vs-constant

[Srinivas, Vidya]

Thank you Bhanu. This test is failing on all planes > 0. Only plane 0 passes.
If I skip plane 1, it fails on 2 and so on.
Changing the way CRC is being collected also is not helping. Adding vblank is 
also not helping.

Regards
Vidya

-Original Message-
From: Modem, Bhanuprakash  
Sent: Friday, June 11, 2021 9:11 AM
To: Srinivas, Vidya ; 
intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Don't 
set primary fb color in coverage-vs-premult-vs-constant

> From: Intel-gfx  On Behalf Of 
> Vidya Srinivas
> Sent: Tuesday, June 1, 2021 7:38 PM
> To: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: 
> Don't set primary fb color in coverage-vs-premult-vs-constant
> 
> Patch removes setting primary fb color in 
> coverage-vs-premult-vs-constant as this is causing CRC mismatch on few Gen11 
> systems.

I am not sure how Primary plane's bg color causing CRC mismatch.
Also, as this test runs on all planes (those are having the props "alpha" and 
"pixel blend mode"), is this test failing on a particular plane?

- Bhanu

> Similar change has already been done in tests constant_alpha_min and 
> basic_alpha where the test runs on all planes but dont set the primary 
> fb color.
> 
> Signed-off-by: Vidya Srinivas 
> ---
>  tests/kms_plane_alpha_blend.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/tests/kms_plane_alpha_blend.c 
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749 
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t 
> *data, enum pipe pipe, igt_plane_t
>   igt_display_t *display = &data->display;
>   igt_crc_t ref_crc = {}, crc = {};
> 
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> - igt_plane_set_fb(igt_pipe_get_plane_type(&display->pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), &data->gray_fb);
> -
>   igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE, "Coverage");
>   igt_plane_set_fb(plane, &data->argb_fb_cov_7e);
>   igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add relocation exceptions for two other platforms (rev6)

[Patchwork]

== Series Details ==

Series: drm/i915: Add relocation exceptions for two other platforms (rev6)
URL   : https://patchwork.freedesktop.org/series/89594/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_10209 -> Patchwork_20342


Summary
---

  **SUCCESS**

  No regressions found.

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

Known issues


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

### IGT changes ###

 Issues hit 

  * igt@core_hotunplug@unbind-rebind:
- fi-bdw-5557u:   NOTRUN -> [WARN][1] ([i915#2283])
   [1]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html

  * igt@i915_selftest@live@execlists:
- fi-bdw-5557u:   NOTRUN -> [DMESG-FAIL][2] ([i915#3462])
   [2]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-bdw-5557u/igt@i915_selftest@l...@execlists.html

  * igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u:   NOTRUN -> [SKIP][3] ([fdo#109271]) +5 similar issues
   [3]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html

  
 Possible fixes 

  * igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-1115g4}:[DMESG-FAIL][4] ([i915#541]) -> [PASS][5]
   [4]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-tgl-1115g4/igt@i915_selftest@live@gt_heartbeat.html
   [5]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-tgl-1115g4/igt@i915_selftest@live@gt_heartbeat.html

  
 Warnings 

  * igt@i915_selftest@live@execlists:
- fi-cml-s:   [DMESG-FAIL][6] ([i915#3462]) -> [INCOMPLETE][7] 
([i915#3462])
   [6]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-cml-s/igt@i915_selftest@l...@execlists.html
   [7]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-cml-s/igt@i915_selftest@l...@execlists.html

  * igt@runner@aborted:
- fi-skl-6600u:   [FAIL][8] ([i915#1436] / [i915#3363]) -> [FAIL][9] 
([i915#1436] / [i915#2426] / [i915#3363])
   [8]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-skl-6600u/igt@run...@aborted.html
   [9]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-skl-6600u/igt@run...@aborted.html
- fi-kbl-r:   [FAIL][10] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][11] ([i915#1436] / [i915#3363])
   [10]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-kbl-r/igt@run...@aborted.html
   [11]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-kbl-r/igt@run...@aborted.html
- fi-bdw-5557u:   [FAIL][12] ([i915#1602] / [i915#2029]) -> [FAIL][13] 
([i915#3462])
   [12]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-bdw-5557u/igt@run...@aborted.html
   [13]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-bdw-5557u/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][14] ([i915#3363]) -> [FAIL][15] ([i915#2426] / 
[i915#3363])
   [14]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-cfl-guc/igt@run...@aborted.html
   [15]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-cfl-guc/igt@run...@aborted.html
- fi-kbl-7567u:   [FAIL][16] ([i915#1436] / [i915#2426] / [i915#3363]) 
-> [FAIL][17] ([i915#1436] / [i915#3363])
   [16]: 
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10209/fi-kbl-7567u/igt@run...@aborted.html
   [17]: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20342/fi-kbl-7567u/igt@run...@aborted.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
  [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
  [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
  [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
  [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
  [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283
  [i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
  [i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
  [i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
  [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541


Participating hosts (44 -> 40)
--

  Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-hsw-4200u 


Build changes
-

  * Linux: CI_DRM_10209 -> Patchwork_20342

  CI-20190529: 20190529
  CI_DRM_10209: a86fe137c0ea2e44c75b4b6c3f447af677508679 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6104: f8f81bd3752f3126a47d9dbba2d0ab29f7c17a19 @ 
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_20342: 1c0bccbe90d81101674d0e63fca938e2e6e55c4e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==