* [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
@ 2022-01-20 22:16 Casey Bowman
2022-01-20 22:16 ` [Intel-gfx] [RFC PATCH 1/1] i915/drm: Split out x86 and arm64 functionality Casey Bowman
` (7 more replies)
0 siblings, 8 replies; 13+ messages in thread
From: Casey Bowman @ 2022-01-20 22:16 UTC (permalink / raw)
To: intel-gfx
Cc: ville.syrjala, wayne.boyer, jani.nikula, lucas.demarchi,
daniel.vetter, michael.cheng
In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.
I would like to address the following:
1. How do we want to split architecture calls? Different object files
per platform? Separate function calls within the same object file?
2. How do we address dummy functions? If we have a function call that is
used for one or more platforms, but is not used in another, what should
we do for this case?
I've given an example of splitting an architecture call
in my patch with run_as_guest() being split into different
implementations for x86 and arm64 in separate object files, sharing
a single header.
Another suggestion from Michael (michael.cheng@intel.com) involved
using a single object file, a single header, and splitting various
functions calls via ifdefs in the header file.
I would appreciate any input on how we can avoid scaling issues when
including multiple architectures and multiple functions (as the number
of function calls will inevitably increase with more architectures).
Casey Bowman (1):
i915/drm: Split out x86 and arm64 functionality
drivers/gpu/drm/i915/Makefile | 4 +++
drivers/gpu/drm/i915/i915_drv.h | 6 +---
drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
5 files changed, 87 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_platform.h
create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
--
2.25.1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] [RFC PATCH 1/1] i915/drm: Split out x86 and arm64 functionality
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
@ 2022-01-20 22:16 ` Casey Bowman
2022-01-20 23:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Splitting up platform-specific calls Patchwork
` (6 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Casey Bowman @ 2022-01-20 22:16 UTC (permalink / raw)
To: intel-gfx
Cc: ville.syrjala, wayne.boyer, jani.nikula, lucas.demarchi,
daniel.vetter, michael.cheng
Some x86 checks are unnecessary on arm64 systems, so they
are being split out to avoid being used. There may be
further arm64 implementations created in the future for
this area, so it's better to split this out now.
Signed-off-by: Casey Bowman <casey.g.bowman@intel.com>
---
drivers/gpu/drm/i915/Makefile | 4 +++
drivers/gpu/drm/i915/i915_drv.h | 6 +---
drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
5 files changed, 87 insertions(+), 5 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_platform.h
create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 213c5f9fae32..dd66fe57934d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -320,6 +320,10 @@ i915-y += intel_gvt.o
include $(src)/gvt/Makefile
endif
+# Architecture-specific calls
+i915-$(CONFIG_X86) += i915_platform_x86.o
+i915-$(CONFIG_ARM64) += i915_platform_arm64.o
+
obj-$(CONFIG_DRM_I915) += i915.o
obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 290dfd40c7b3..e688270c8257 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -107,6 +107,7 @@
#include "gt/intel_timeline.h"
#include "i915_vma.h"
+#include "i915_platform.h"
/* General customization:
*/
@@ -1543,11 +1544,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define INTEL_DISPLAY_ENABLED(dev_priv) \
(drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)), !(dev_priv)->params.disable_display)
-static inline bool run_as_guest(void)
-{
- return !hypervisor_is_type(X86_HYPER_NATIVE);
-}
-
#define HAS_D12_PLANE_MINIMIZATION(dev_priv) (IS_ROCKETLAKE(dev_priv) || \
IS_ALDERLAKE_S(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_platform.h b/drivers/gpu/drm/i915/i915_platform.h
new file mode 100644
index 000000000000..300f93d20f58
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_platform.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef _I915_PLATFORM_
+#define _I915_PLATFORM_
+
+#include <linux/types.h>
+#include <linux/bug.h>
+
+/* Start of i915_drv functionality */
+bool run_as_guest(void);
+/* End of i915_drv functionality */
+
+#endif
diff --git a/drivers/gpu/drm/i915/i915_platform_arm64.c b/drivers/gpu/drm/i915/i915_platform_arm64.c
new file mode 100644
index 000000000000..95692c4dc75f
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_platform_arm64.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/*
+ * Read before adding/removing content!
+ *
+ * Ensure that all functions defined here are also defined
+ * in the i915_platform_x86.c file.
+ *
+ * If the function is a dummy function, be sure to add
+ * a DRM_WARN() call to note that the function is a
+ * dummy function to users so that we can better track
+ * any issues that arise due to changes in either file.
+ *
+ * Also be sure to label Start/End of sections where
+ * functions originate from. These files will host
+ * architecture-specific content from a myriad of files,
+ * labeling the sections will help devs keep track of
+ * where the calls interact.
+ */
+
+#include "i915_platform.h"
+
+/* Start of i915_drv functionality */
+/* Intel VT-d is not used on ARM64 systems */
+bool run_as_guest(void)
+{
+ WARN(1, "%s not supported on arm64 platforms.", __func__);
+ return false;
+}
+/* End of i915_drv functionality */
diff --git a/drivers/gpu/drm/i915/i915_platform_x86.c b/drivers/gpu/drm/i915/i915_platform_x86.c
new file mode 100644
index 000000000000..9a7174ad2147
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_platform_x86.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/*
+ * Read before adding/removing content!
+ *
+ * Ensure that all functions defined here are also defined
+ * in the i915_platform_arm64.c file.
+ *
+ * If the function is a dummy function, be sure to add
+ * a DRM_WARN() call to note that the function is a
+ * dummy function to users so that we can better track
+ * any issues that arise due to changes in either file.
+ *
+ * Also be sure to label Start/End of sections where
+ * functions originate from. These files will host
+ * architecture-specific content from a myriad of files,
+ * labeling the sections will help devs keep track of
+ * where the calls interact.
+ */
+
+#include "i915_platform.h"
+
+#include <asm/hypervisor.h>
+
+/* Start of i915_drv functionality */
+bool run_as_guest(void)
+{
+ return !hypervisor_is_type(X86_HYPER_NATIVE);
+}
+/* End of i915_drv functionality */
--
2.25.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
2022-01-20 22:16 ` [Intel-gfx] [RFC PATCH 1/1] i915/drm: Split out x86 and arm64 functionality Casey Bowman
@ 2022-01-20 23:58 ` Patchwork
2022-01-20 23:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
` (5 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2022-01-20 23:58 UTC (permalink / raw)
To: Casey Bowman; +Cc: intel-gfx
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cfedaf9b9519 i915/drm: Split out x86 and arm64 functionality
-:53: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating?
#53:
new file mode 100644
-:112: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#112: FILE: drivers/gpu/drm/i915/i915_platform_arm64.c:33:
+}
+/* End of i915_drv functionality */
-:151: CHECK:LINE_SPACING: Please use a blank line after function/struct/union/enum declarations
#151: FILE: drivers/gpu/drm/i915/i915_platform_x86.c:33:
+}
+/* End of i915_drv functionality */
total: 0 errors, 1 warnings, 2 checks, 110 lines checked
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
2022-01-20 22:16 ` [Intel-gfx] [RFC PATCH 1/1] i915/drm: Split out x86 and arm64 functionality Casey Bowman
2022-01-20 23:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Splitting up platform-specific calls Patchwork
@ 2022-01-20 23:59 ` Patchwork
2022-01-21 0:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
` (4 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2022-01-20 23:59 UTC (permalink / raw)
To: Casey Bowman; +Cc: intel-gfx
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
` (2 preceding siblings ...)
2022-01-20 23:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
@ 2022-01-21 0:34 ` Patchwork
2022-01-21 4:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
` (3 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2022-01-21 0:34 UTC (permalink / raw)
To: Casey Bowman; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5774 bytes --]
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11115 -> Patchwork_22048
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/index.html
Participating hosts (42 -> 42)
------------------------------
Additional (2): bat-jsl-2 fi-pnv-d510
Missing (2): fi-bsw-cyan fi-bdw-samus
Known issues
------------
Here are the changes found in Patchwork_22048 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-snb-2600/igt@amdgpu/amd_cs_nop@sync-fork-compute0.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][2] -> [INCOMPLETE][3] ([i915#4547])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770: [PASS][4] -> [INCOMPLETE][5] ([i915#4785])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510: NOTRUN -> [SKIP][6] ([fdo#109271]) +57 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-pnv-d510/igt@prime_vgem@basic-userptr.html
* igt@runner@aborted:
- fi-skl-6600u: NOTRUN -> [FAIL][7] ([i915#2722] / [i915#4312])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-skl-6600u/igt@runner@aborted.html
- fi-hsw-4770: NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#1436] / [i915#4312])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-hsw-4770/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rpls-1}: [INCOMPLETE][9] ([i915#4898]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/bat-rpls-1/igt@gem_exec_suspend@basic-s3@smem.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/bat-rpls-1/igt@gem_exec_suspend@basic-s3@smem.html
* igt@i915_selftest@live@gtt:
- fi-bdw-5557u: [DMESG-FAIL][11] -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/fi-bdw-5557u/igt@i915_selftest@live@gtt.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-bdw-5557u/igt@i915_selftest@live@gtt.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600: [INCOMPLETE][13] ([i915#3921]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* Linux: CI_DRM_11115 -> Patchwork_22048
CI-20190529: 20190529
CI_DRM_11115: 4e12213687264ffccb45d72fe638f94d3ca666bd @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6329: 38f656fdd61119105ecfa2c4dac157cd7dcad204 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22048: cfedaf9b9519ab335e7ccd4bc2e474dcd49f117c @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cfedaf9b9519 i915/drm: Split out x86 and arm64 functionality
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/index.html
[-- Attachment #2: Type: text/html, Size: 5583 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
` (3 preceding siblings ...)
2022-01-21 0:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2022-01-21 4:03 ` Patchwork
2022-02-03 23:58 ` [Intel-gfx] [RFC PATCH 0/1] " Casey Bowman
` (2 subsequent siblings)
7 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2022-01-21 4:03 UTC (permalink / raw)
To: Casey Bowman; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30259 bytes --]
== Series Details ==
Series: Splitting up platform-specific calls
URL : https://patchwork.freedesktop.org/series/99126/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11115_full -> Patchwork_22048_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_22048_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22048_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22048_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_schedule@smoketest-all:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-tglb2/igt@gem_exec_schedule@smoketest-all.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-tglb6/igt@gem_exec_schedule@smoketest-all.html
#### Warnings ####
* igt@runner@aborted:
- shard-apl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8]) ([fdo#109271] / [i915#180] / [i915#1814] / [i915#3002] / [i915#4312]) -> ([FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14]) ([i915#180] / [i915#1814] / [i915#3002] / [i915#4312])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl2/igt@runner@aborted.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl6/igt@runner@aborted.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl1/igt@runner@aborted.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl1/igt@runner@aborted.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl1/igt@runner@aborted.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl8/igt@runner@aborted.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@runner@aborted.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@runner@aborted.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@runner@aborted.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl6/igt@runner@aborted.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl8/igt@runner@aborted.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@runner@aborted.html
Known issues
------------
Here are the changes found in Patchwork_22048_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_ctx_isolation@preservation-s3@rcs0:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl3/igt@gem_ctx_isolation@preservation-s3@rcs0.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl8/igt@gem_ctx_isolation@preservation-s3@rcs0.html
* igt@gem_ctx_persistence@engines-queued:
- shard-snb: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#1099])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-snb4/igt@gem_ctx_persistence@engines-queued.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][18] -> [TIMEOUT][19] ([i915#2481] / [i915#3070])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb8/igt@gem_eio@unwedge-stress.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb2/igt@gem_eio@unwedge-stress.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][20] -> [SKIP][21] ([i915#4525])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb1/igt@gem_exec_balancer@parallel-keep-in-fence.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb3/igt@gem_exec_balancer@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][22] -> [FAIL][23] ([i915#2846])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk8/igt@gem_exec_fair@basic-deadline.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk8/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][24] -> [FAIL][25] ([i915#2842])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-tglb3/igt@gem_exec_fair@basic-flow@rcs0.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-tglb3/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][26] -> [FAIL][27] ([i915#2842])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb4/igt@gem_exec_fair@basic-none-share@rcs0.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb1/igt@gem_exec_fair@basic-none-share@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-glk: [PASS][28] -> [FAIL][29] ([i915#2842])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk5/igt@gem_exec_fair@basic-none-vip@rcs0.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk2/igt@gem_exec_fair@basic-none-vip@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl: [PASS][30] -> [FAIL][31] ([i915#2842]) +3 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl4/igt@gem_exec_fair@basic-pace@rcs0.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl7/igt@gem_exec_fair@basic-pace@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][32] ([i915#2842])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb4/igt@gem_exec_fair@basic-pace@vcs1.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][33] -> [FAIL][34] ([i915#2849])
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb3/igt@gem_exec_fair@basic-throttle@rcs0.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb6/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_exec_params@no-vebox:
- shard-skl: NOTRUN -> [SKIP][35] ([fdo#109271]) +153 similar issues
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl1/igt@gem_exec_params@no-vebox.html
* igt@gem_exec_schedule@pi-ringfull@vecs0:
- shard-skl: NOTRUN -> [INCOMPLETE][36] ([i915#4374])
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl3/igt@gem_exec_schedule@pi-ringfull@vecs0.html
* igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-glk: [PASS][37] -> [DMESG-WARN][38] ([i915#118])
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk6/igt@gem_exec_whisper@basic-contexts-priority-all.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk4/igt@gem_exec_whisper@basic-contexts-priority-all.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][39] ([fdo#109271] / [i915#4613]) +1 similar issue
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl8/igt@gem_lmem_swapping@heavy-random.html
* igt@gem_lmem_swapping@parallel-multi:
- shard-skl: NOTRUN -> [SKIP][40] ([fdo#109271] / [i915#4613]) +1 similar issue
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl6/igt@gem_lmem_swapping@parallel-multi.html
* igt@gem_pread@exhaustion:
- shard-skl: NOTRUN -> [WARN][41] ([i915#2658])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl6/igt@gem_pread@exhaustion.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-kbl: NOTRUN -> [SKIP][42] ([fdo#109271] / [i915#3323])
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@gem_userptr_blits@dmabuf-sync.html
- shard-skl: NOTRUN -> [SKIP][43] ([fdo#109271] / [i915#3323])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl3/igt@gem_userptr_blits@dmabuf-sync.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][44] -> [DMESG-WARN][45] ([i915#180])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl3/igt@gem_workarounds@suspend-resume-fd.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@gem_workarounds@suspend-resume-fd.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: [PASS][46] -> [DMESG-WARN][47] ([i915#1436] / [i915#716])
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl9/igt@gen9_exec_parse@allowed-single.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl8/igt@gen9_exec_parse@allowed-single.html
* igt@i915_pm_dc@dc6-dpms:
- shard-kbl: NOTRUN -> [FAIL][48] ([i915#454])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- shard-apl: NOTRUN -> [SKIP][49] ([fdo#109271]) +48 similar issues
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl4/igt@i915_pm_rpm@modeset-lpsp-stress.html
* igt@i915_pm_rpm@sysfs-read:
- shard-snb: NOTRUN -> [SKIP][50] ([fdo#109271]) +21 similar issues
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-snb4/igt@i915_pm_rpm@sysfs-read.html
* igt@kms_async_flips@alternate-sync-async-flip:
- shard-skl: [PASS][51] -> [FAIL][52] ([i915#2521])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl10/igt@kms_async_flips@alternate-sync-async-flip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip:
- shard-skl: NOTRUN -> [SKIP][53] ([fdo#109271] / [i915#3777])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl1/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-hflip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip:
- shard-apl: NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#3777])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl4/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][55] ([i915#3743])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl6/igt@kms_big_fb@y-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
* igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-skl: NOTRUN -> [SKIP][56] ([fdo#109271] / [i915#3886]) +6 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl1/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][57] ([fdo#109271] / [i915#3886]) +2 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl4/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-tglb: NOTRUN -> [SKIP][58] ([i915#3689] / [i915#3886])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-tglb5/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs_cc:
- shard-kbl: NOTRUN -> [SKIP][59] ([fdo#109271] / [i915#3886]) +3 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium@hdmi-mode-timings:
- shard-kbl: NOTRUN -> [SKIP][60] ([fdo#109271] / [fdo#111827]) +5 similar issues
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl7/igt@kms_chamelium@hdmi-mode-timings.html
* igt@kms_color_chamelium@pipe-b-ctm-negative:
- shard-snb: NOTRUN -> [SKIP][61] ([fdo#109271] / [fdo#111827])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-snb4/igt@kms_color_chamelium@pipe-b-ctm-negative.html
* igt@kms_color_chamelium@pipe-c-ctm-0-25:
- shard-apl: NOTRUN -> [SKIP][62] ([fdo#109271] / [fdo#111827]) +5 similar issues
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl4/igt@kms_color_chamelium@pipe-c-ctm-0-25.html
* igt@kms_color_chamelium@pipe-d-ctm-red-to-blue:
- shard-skl: NOTRUN -> [SKIP][63] ([fdo#109271] / [fdo#111827]) +11 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl1/igt@kms_color_chamelium@pipe-d-ctm-red-to-blue.html
* igt@kms_cursor_crc@pipe-c-cursor-64x21-onscreen:
- shard-apl: [PASS][64] -> [DMESG-WARN][65] ([i915#62]) +38 similar issues
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl3/igt@kms_cursor_crc@pipe-c-cursor-64x21-onscreen.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@kms_cursor_crc@pipe-c-cursor-64x21-onscreen.html
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-apl: [PASS][66] -> [DMESG-WARN][67] ([i915#533] / [i915#62])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl3/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@kms_cursor_legacy@cursor-vs-flip-toggle.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-skl: [PASS][68] -> [FAIL][69] ([i915#2346])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl9/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl8/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][70] -> [INCOMPLETE][71] ([i915#180] / [i915#636])
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl7/igt@kms_fbcon_fbt@fbc-suspend.html
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank@a-edp1:
- shard-skl: [PASS][72] -> [FAIL][73] ([i915#79])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl9/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl8/igt@kms_flip@flip-vs-expired-vblank@a-edp1.html
* igt@kms_flip@flip-vs-suspend@b-edp1:
- shard-skl: [PASS][74] -> [INCOMPLETE][75] ([i915#4839])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl4/igt@kms_flip@flip-vs-suspend@b-edp1.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl4/igt@kms_flip@flip-vs-suspend@b-edp1.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling:
- shard-iclb: [PASS][76] -> [SKIP][77] ([i915#3701])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb8/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling.html
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-downscaling.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling:
- shard-glk: [PASS][78] -> [FAIL][79] ([i915#4911]) +1 similar issue
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk5/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk8/igt@kms_flip_scaled_crc@flip-32bpp-ytileccs-to-64bpp-ytile-upscaling.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt:
- shard-kbl: NOTRUN -> [SKIP][80] ([fdo#109271]) +61 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-indfb-msflip-blt.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][81] -> [FAIL][82] ([i915#1188])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl7/igt@kms_hdr@bpc-switch-suspend.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl1/igt@kms_hdr@bpc-switch-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-d-frame-sequence:
- shard-kbl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#533]) +1 similar issue
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-d-frame-sequence.html
- shard-skl: NOTRUN -> [SKIP][84] ([fdo#109271] / [i915#533])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl3/igt@kms_pipe_crc_basic@nonblocking-crc-pipe-d-frame-sequence.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> [FAIL][85] ([fdo#108145] / [i915#265]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][86] ([i915#265])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl4/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-c-alpha-basic:
- shard-kbl: NOTRUN -> [FAIL][87] ([fdo#108145] / [i915#265])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@kms_plane_alpha_blend@pipe-c-alpha-basic.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-apl: NOTRUN -> [SKIP][88] ([fdo#109271] / [i915#658])
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl8/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
* igt@kms_psr2_su@page_flip-p010:
- shard-kbl: NOTRUN -> [SKIP][89] ([fdo#109271] / [i915#658])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@kms_psr2_su@page_flip-p010.html
* igt@kms_psr2_su@page_flip-xrgb8888:
- shard-skl: NOTRUN -> [SKIP][90] ([fdo#109271] / [i915#658]) +1 similar issue
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl1/igt@kms_psr2_su@page_flip-xrgb8888.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][91] -> [SKIP][92] ([fdo#109441]) +1 similar issue
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-glk: [PASS][93] -> [FAIL][94] ([i915#31])
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk8/igt@kms_setmode@basic.html
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk4/igt@kms_setmode@basic.html
* igt@kms_universal_plane@disable-primary-vs-flip-pipe-b:
- shard-apl: [PASS][95] -> [DMESG-WARN][96] ([i915#1982] / [i915#62])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl4/igt@kms_universal_plane@disable-primary-vs-flip-pipe-b.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@kms_universal_plane@disable-primary-vs-flip-pipe-b.html
* igt@sysfs_clients@fair-3:
- shard-kbl: NOTRUN -> [SKIP][97] ([fdo#109271] / [i915#2994]) +1 similar issue
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@sysfs_clients@fair-3.html
- shard-skl: NOTRUN -> [SKIP][98] ([fdo#109271] / [i915#2994]) +3 similar issues
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl3/igt@sysfs_clients@fair-3.html
#### Possible fixes ####
* igt@gem_eio@in-flight-suspend:
- shard-skl: [INCOMPLETE][99] ([i915#4843]) -> [PASS][100]
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl7/igt@gem_eio@in-flight-suspend.html
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl6/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [SKIP][101] ([i915#4525]) -> [PASS][102]
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb6/igt@gem_exec_balancer@parallel-out-fence.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb4/igt@gem_exec_balancer@parallel-out-fence.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: [FAIL][103] ([i915#2842]) -> [PASS][104] +5 similar issues
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl6/igt@gem_exec_fair@basic-none-solo@rcs0.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl3/igt@gem_exec_fair@basic-none-solo@rcs0.html
- shard-apl: [FAIL][105] ([i915#2842]) -> [PASS][106]
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl3/igt@gem_exec_fair@basic-none-solo@rcs0.html
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl8/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [FAIL][107] ([i915#2842]) -> [PASS][108]
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-tglb5/igt@gem_exec_fair@basic-pace-share@rcs0.html
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-tglb5/igt@gem_exec_fair@basic-pace-share@rcs0.html
- shard-glk: [FAIL][109] ([i915#2842]) -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk7/igt@gem_exec_fair@basic-pace-share@rcs0.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk7/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_softpin@allocator-evict-all-engines:
- shard-glk: [FAIL][111] ([i915#4171]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk8/igt@gem_softpin@allocator-evict-all-engines.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk4/igt@gem_softpin@allocator-evict-all-engines.html
* igt@i915_module_load@reload:
- shard-skl: [DMESG-WARN][113] ([i915#1982]) -> [PASS][114]
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl3/igt@i915_module_load@reload.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl4/igt@i915_module_load@reload.html
* igt@i915_suspend@fence-restore-tiled2untiled:
- shard-snb: [INCOMPLETE][115] -> [PASS][116]
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-snb7/igt@i915_suspend@fence-restore-tiled2untiled.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-snb4/igt@i915_suspend@fence-restore-tiled2untiled.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen:
- shard-glk: [DMESG-WARN][117] ([i915#118]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk9/igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk3/igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-kbl: [DMESG-WARN][119] ([i915#180]) -> [PASS][120] +1 similar issue
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl1/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl7/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling:
- shard-iclb: [SKIP][121] ([i915#3701]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb4/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile-downscaling.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-apl: [DMESG-WARN][123] ([i915#180]) -> [PASS][124] +3 similar issues
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl8/igt@kms_frontbuffer_tracking@fbc-suspend.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl8/igt@kms_frontbuffer_tracking@fbc-suspend.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [FAIL][125] ([i915#1188]) -> [PASS][126]
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl7/igt@kms_hdr@bpc-switch.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl9/igt@kms_hdr@bpc-switch.html
* igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [SKIP][127] ([fdo#109441]) -> [PASS][128] +1 similar issue
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb8/igt@kms_psr@psr2_cursor_plane_move.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
* igt@perf@polling:
- shard-skl: [FAIL][129] ([i915#1542]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl9/igt@perf@polling.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-skl8/igt@perf@polling.html
* igt@perf@polling-parameterized:
- shard-glk: [FAIL][131] ([i915#1542]) -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-glk6/igt@perf@polling-parameterized.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-glk7/igt@perf@polling-parameterized.html
#### Warnings ####
* igt@i915_pm_dc@dc3co-vpb-simulation:
- shard-iclb: [SKIP][133] ([i915#658]) -> [SKIP][134] ([i915#588])
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb1/igt@i915_pm_dc@dc3co-vpb-simulation.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb2/igt@i915_pm_dc@dc3co-vpb-simulation.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-apl: [FAIL][135] ([fdo#108145] / [i915#265]) -> [DMESG-FAIL][136] ([fdo#108145] / [i915#265] / [i915#62])
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl3/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@kms_plane_alpha_blend@pipe-b-alpha-basic.html
* igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
- shard-iclb: [SKIP][137] ([i915#2920]) -> [SKIP][138] ([fdo#111068] / [i915#658])
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb2/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb5/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
* igt@kms_psr2_su@page_flip-xrgb8888:
- shard-iclb: [SKIP][139] ([fdo#109642] / [fdo#111068] / [i915#658]) -> [FAIL][140] ([i915#4148])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-iclb1/igt@kms_psr2_su@page_flip-xrgb8888.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-iclb2/igt@kms_psr2_su@page_flip-xrgb8888.html
* igt@kms_sysfs_edid_timing:
- shard-apl: [FAIL][141] ([IGT#2]) -> [DMESG-FAIL][142] ([IGT#2] / [i915#62])
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-apl3/igt@kms_sysfs_edid_timing.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-apl7/igt@kms_sysfs_edid_timing.html
* igt@runner@aborted:
- shard-kbl: ([FAIL][143], [FAIL][144], [FAIL][145], [FAIL][146]) ([i915#1436] / [i915#180] / [i915#1814] / [i915#3002] / [i915#4312]) -> ([FAIL][147], [FAIL][148], [FAIL][149], [FAIL][150]) ([i915#180] / [i915#3002] / [i915#4312] / [i915#92])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl6/igt@runner@aborted.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl1/igt@runner@aborted.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl1/igt@runner@aborted.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-kbl1/igt@runner@aborted.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@runner@aborted.html
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@runner@aborted.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@runner@aborted.html
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/shard-kbl1/igt@runner@aborted.html
- shard-skl: ([FAIL][151], [FAIL][152], [FAIL][153], [FAIL][154]) ([i915#2029] / [i915#3002] / [i915#4312]) -> ([FAIL][155], [FAIL][156], [FAIL][157], [FAIL][158], [FAIL][159]) ([i915#1436] / [i915#2426] / [i915#3002] / [i915#4312])
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl4/igt@runner@aborted.html
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11115/shard-skl8/igt@runner@aborted.html
[153]: https://intel-gfx-ci.01.or
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22048/index.html
[-- Attachment #2: Type: text/html, Size: 33631 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
` (4 preceding siblings ...)
2022-01-21 4:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2022-02-03 23:58 ` Casey Bowman
2022-02-07 13:02 ` Jani Nikula
2022-02-07 15:36 ` Tvrtko Ursulin
7 siblings, 0 replies; 13+ messages in thread
From: Casey Bowman @ 2022-02-03 23:58 UTC (permalink / raw)
To: intel-gfx; +Cc: Jani Nikula, Daniel Vetter
CC'ing more reviewers for comments.
On 1/20/22 14:16, Casey Bowman wrote:
> In this RFC I would like to ask the community their thoughts
> on how we can best handle splitting architecture-specific
> calls.
>
> I would like to address the following:
>
> 1. How do we want to split architecture calls? Different object files
> per platform? Separate function calls within the same object file?
>
> 2. How do we address dummy functions? If we have a function call that is
> used for one or more platforms, but is not used in another, what should
> we do for this case?
>
> I've given an example of splitting an architecture call
> in my patch with run_as_guest() being split into different
> implementations for x86 and arm64 in separate object files, sharing
> a single header.
>
> Another suggestion from Michael (michael.cheng@intel.com) involved
> using a single object file, a single header, and splitting various
> functions calls via ifdefs in the header file.
>
> I would appreciate any input on how we can avoid scaling issues when
> including multiple architectures and multiple functions (as the number
> of function calls will inevitably increase with more architectures).
>
> Casey Bowman (1):
> i915/drm: Split out x86 and arm64 functionality
>
> drivers/gpu/drm/i915/Makefile | 4 +++
> drivers/gpu/drm/i915/i915_drv.h | 6 +---
> drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
> drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
> drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_platform.h
> create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
> create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
` (5 preceding siblings ...)
2022-02-03 23:58 ` [Intel-gfx] [RFC PATCH 0/1] " Casey Bowman
@ 2022-02-07 13:02 ` Jani Nikula
2022-02-09 5:07 ` Casey Bowman
2022-02-07 15:36 ` Tvrtko Ursulin
7 siblings, 1 reply; 13+ messages in thread
From: Jani Nikula @ 2022-02-07 13:02 UTC (permalink / raw)
To: Casey Bowman, intel-gfx
Cc: lucas.demarchi, daniel.vetter, ville.syrjala, michael.cheng
On Thu, 20 Jan 2022, Casey Bowman <casey.g.bowman@intel.com> wrote:
> In this RFC I would like to ask the community their thoughts
> on how we can best handle splitting architecture-specific
> calls.
>
> I would like to address the following:
>
> 1. How do we want to split architecture calls? Different object files
> per platform? Separate function calls within the same object file?
>
> 2. How do we address dummy functions? If we have a function call that is
> used for one or more platforms, but is not used in another, what should
> we do for this case?
>
> I've given an example of splitting an architecture call
> in my patch with run_as_guest() being split into different
> implementations for x86 and arm64 in separate object files, sharing
> a single header.
>
> Another suggestion from Michael (michael.cheng@intel.com) involved
> using a single object file, a single header, and splitting various
> functions calls via ifdefs in the header file.
>
> I would appreciate any input on how we can avoid scaling issues when
> including multiple architectures and multiple functions (as the number
> of function calls will inevitably increase with more architectures).
Personally I think the functionality is best kept organized by, well,
functionality, not by platform. Otherwise the platform files will
contain all sorts of code with the only common denominator being the
platform.
You're also likely to have static platform specific functions, which
would needlessly have to be made non-static if the split was by files.
I'd just put the implementations for different platforms next to each
other:
#if IS_ENABLED(CONFIG_X86)
...
#elif IS_ENABLED(CONFIG_ARM64)
...
#endif
Usually the declarations would be identical and there'd only be one,
without #ifs in the header.
BR,
Jani.
>
> Casey Bowman (1):
> i915/drm: Split out x86 and arm64 functionality
>
> drivers/gpu/drm/i915/Makefile | 4 +++
> drivers/gpu/drm/i915/i915_drv.h | 6 +---
> drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
> drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
> drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_platform.h
> create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
> create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
` (6 preceding siblings ...)
2022-02-07 13:02 ` Jani Nikula
@ 2022-02-07 15:36 ` Tvrtko Ursulin
2022-02-09 5:25 ` Casey Bowman
7 siblings, 1 reply; 13+ messages in thread
From: Tvrtko Ursulin @ 2022-02-07 15:36 UTC (permalink / raw)
To: Casey Bowman, intel-gfx
Cc: michael.cheng, jani.nikula, lucas.demarchi, daniel.vetter, ville.syrjala
On 20/01/2022 22:16, Casey Bowman wrote:
> In this RFC I would like to ask the community their thoughts
> on how we can best handle splitting architecture-specific
> calls.
>
> I would like to address the following:
>
> 1. How do we want to split architecture calls? Different object files
> per platform? Separate function calls within the same object file?
If we are talking about per-platform divergence of significant functions (not necessarily in size but their height position in the i915 stack) I agree with Jani that top-level per platform organisation is not the best choice.
On the other hand I doubt that there should be many, if any, such functions. In practice I think it should be only low level stuff which diverges.
On a concrete example..
> 2. How do we address dummy functions? If we have a function call that is
> used for one or more platforms, but is not used in another, what should
> we do for this case?
... depends on the situation. Sometimes a flavour of "warn on once" can be okay I guess, but also why not build bug on? Because..
>
> I've given an example of splitting an architecture call
> in my patch with run_as_guest() being split into different
> implementations for x86 and arm64 in separate object files, sharing
> a single header.
... run_as_guest may be a very tricky example, given it is called from intel_vtd_active which has a number of callers.
What is correct behaviour on Arm in this example? None of these call sites will run on Arm? Or that you expect the warn on added in this patch to trigger as a demonstration? If so, what is the plan going forward? We can take one example and talk about it hypothetically:
./i915_driver.c: drm_printf(p, "iommu: %s\n", enableddisabled(intel_vtd_active(i915)));
What is the "fix" (refactor) for Arm here? Looks like a new top-level function is needed which does not carry the intel_vtd_ prefix but something more generic. That one could then legitimately "warn on once", while for intel_vtd_active it would be wrong to do so.
And when I say it is needed.. well perhaps it is not strictly needed in this case, but in some other cases I think we go back to the problem I stated some months ago and that is that I suspect use of intel_vtd_active is overloaded. I think it is currently used to answer all these questions: 1. Is the IOMMU active, just for information.; 2. Is the IOMMU active and we want to counteract the performance hit by say using huge pages, adjusting the display bandwidth calculations or whatever. (In which case we also may want to distinguish between pass-through and translation modes.); 3. Is a potentially buggy IOMMU active and we need to work around it. All these under one kind of worked with one iommu implementation but does it with a different IOMMU?
Which I mean leads to end conclusion that this particular function is a tricky example to answer the questions asked. :)
>
> Another suggestion from Michael (michael.cheng@intel.com) involved
> using a single object file, a single header, and splitting various
> functions calls via ifdefs in the header file.
In principle, mostly what you have outlined sounds acceptable to me, with the difference that I would not use i915_platform, but for this particular example something like i915_hypervisor prefix.
Then I would prepare i915 with the same scheme kernel uses, not just for source file divergence, but header file as well. That is:
some_source.c:
#include "i915_hypervisor.h"
i915_hypervisor.h:
#include "platform/i915_hypervisor.h"
Then in i915 root you could have:
platforms/x86/include/platform/i915_hypervisor.h
platforms/arm/include/platform/i915_hypervisor.h
And some kbuild stuff to make that work. Is this doable and does it make sense? Per-platform source files could live in there as well.
Same scheme for i915_clflush would work as well.
Regards,
Tvrtko
>
> I would appreciate any input on how we can avoid scaling issues when
> including multiple architectures and multiple functions (as the number
> of function calls will inevitably increase with more architectures).
>
> Casey Bowman (1):
> i915/drm: Split out x86 and arm64 functionality
>
> drivers/gpu/drm/i915/Makefile | 4 +++
> drivers/gpu/drm/i915/i915_drv.h | 6 +---
> drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
> drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
> drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_platform.h
> create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
> create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-02-07 13:02 ` Jani Nikula
@ 2022-02-09 5:07 ` Casey Bowman
0 siblings, 0 replies; 13+ messages in thread
From: Casey Bowman @ 2022-02-09 5:07 UTC (permalink / raw)
To: Jani Nikula, intel-gfx
Cc: lucas.demarchi, daniel.vetter, ville.syrjala, michael.cheng
On 2/7/22 05:02, Jani Nikula wrote:
> On Thu, 20 Jan 2022, Casey Bowman <casey.g.bowman@intel.com> wrote:
>> In this RFC I would like to ask the community their thoughts
>> on how we can best handle splitting architecture-specific
>> calls.
>>
>> I would like to address the following:
>>
>> 1. How do we want to split architecture calls? Different object files
>> per platform? Separate function calls within the same object file?
>>
>> 2. How do we address dummy functions? If we have a function call that is
>> used for one or more platforms, but is not used in another, what should
>> we do for this case?
>>
>> I've given an example of splitting an architecture call
>> in my patch with run_as_guest() being split into different
>> implementations for x86 and arm64 in separate object files, sharing
>> a single header.
>>
>> Another suggestion from Michael (michael.cheng@intel.com) involved
>> using a single object file, a single header, and splitting various
>> functions calls via ifdefs in the header file.
>>
>> I would appreciate any input on how we can avoid scaling issues when
>> including multiple architectures and multiple functions (as the number
>> of function calls will inevitably increase with more architectures).
> Personally I think the functionality is best kept organized by, well,
> functionality, not by platform. Otherwise the platform files will
> contain all sorts of code with the only common denominator being the
> platform.
>
> You're also likely to have static platform specific functions, which
> would needlessly have to be made non-static if the split was by files.
>
> I'd just put the implementations for different platforms next to each
> other:
>
> #if IS_ENABLED(CONFIG_X86)
> ...
> #elif IS_ENABLED(CONFIG_ARM64)
> ...
> #endif
>
> Usually the declarations would be identical and there'd only be one,
> without #ifs in the header.
Thanks for the feedback, Jani.
I think this is the proper takeaway for future functions that do have
separate implementations for differing architectures.
As for null behavior, as in the example I gave, I think Tvrtko is right
about run_as_guest being a tricky example. I think I need to
re-evaluate that function and think of another solution altogether
for that instance.
I think this will also be the precedent for null cases, where we will
need to rethink implementations for cases that don't really have
some arch-specific implementation other than returning null
(though some exceptions may exist).
>
> BR,
> Jani.
>
>> Casey Bowman (1):
>> i915/drm: Split out x86 and arm64 functionality
>>
>> drivers/gpu/drm/i915/Makefile | 4 +++
>> drivers/gpu/drm/i915/i915_drv.h | 6 +---
>> drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
>> drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
>> drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
>> 5 files changed, 87 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/i915_platform.h
>> create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
>> create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-02-07 15:36 ` Tvrtko Ursulin
@ 2022-02-09 5:25 ` Casey Bowman
2022-02-10 11:10 ` Tvrtko Ursulin
0 siblings, 1 reply; 13+ messages in thread
From: Casey Bowman @ 2022-02-09 5:25 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Cc: michael.cheng, jani.nikula, lucas.demarchi, daniel.vetter, ville.syrjala
On 2/7/22 07:36, Tvrtko Ursulin wrote:
>
> On 20/01/2022 22:16, Casey Bowman wrote:
>> In this RFC I would like to ask the community their thoughts
>> on how we can best handle splitting architecture-specific
>> calls.
>>
>> I would like to address the following:
>>
>> 1. How do we want to split architecture calls? Different object files
>> per platform? Separate function calls within the same object file?
>
> If we are talking about per-platform divergence of significant
> functions (not necessarily in size but their height position in the
> i915 stack) I agree with Jani that top-level per platform organisation
> is not the best choice.
>
> On the other hand I doubt that there should be many, if any, such
> functions. In practice I think it should be only low level stuff which
> diverges.
I agree, as said with my reply to Jani, I think maybe going forward for
arch-specific code, #if IS_ENABLED calls should be used sparingly, only
in the cases where we do have that arch-specific implementation (like
low level calls), instead of just a 'return null', as in my case.
>
> On a concrete example..
>
>> 2. How do we address dummy functions? If we have a function call that is
>> used for one or more platforms, but is not used in another, what should
>> we do for this case?
>
> ... depends on the situation. Sometimes a flavour of "warn on once"
> can be okay I guess, but also why not build bug on? Because..
True, with Jani's and your comments, I'm thinking that in the case of
when we look at a potential arch-specific function where we're just
returning null or something similar, we should be re-evaluating the
function and seeing if we should make a different change there.
>
>>
>> I've given an example of splitting an architecture call
>> in my patch with run_as_guest() being split into different
>> implementations for x86 and arm64 in separate object files, sharing
>> a single header.
>
> ... run_as_guest may be a very tricky example, given it is called from
> intel_vtd_active which has a number of callers.
>
> What is correct behaviour on Arm in this example? None of these call
> sites will run on Arm? Or that you expect the warn on added in this
> patch to trigger as a demonstration? If so, what is the plan going
> forward? We can take one example and talk about it hypothetically:
>
> ./i915_driver.c: drm_printf(p, "iommu: %s\n",
> enableddisabled(intel_vtd_active(i915)));
>
> What is the "fix" (refactor) for Arm here? Looks like a new top-level
> function is needed which does not carry the intel_vtd_ prefix but
> something more generic. That one could then legitimately "warn on
> once", while for intel_vtd_active it would be wrong to do so.
Good point, run_as_guest might be a bit more challenging of an example.
In my mind, I was thinking of just simply returning null for arm64 here
as I don't believe arm64 would be making use of iommu for our cases (at
least, in the short term).
I think this example function specifically needs to get reworked, as you
mentioned, in some way, possibly refactoring intel_vtd_active or
something along those lines.
>
> And when I say it is needed.. well perhaps it is not strictly needed
> in this case, but in some other cases I think we go back to the
> problem I stated some months ago and that is that I suspect use of
> intel_vtd_active is overloaded. I think it is currently used to answer
> all these questions: 1. Is the IOMMU active, just for information.; 2.
> Is the IOMMU active and we want to counteract the performance hit by
> say using huge pages, adjusting the display bandwidth calculations or
> whatever. (In which case we also may want to distinguish between
> pass-through and translation modes.); 3. Is a potentially buggy IOMMU
> active and we need to work around it. All these under one kind of
> worked with one iommu implementation but does it with a different IOMMU?
>
> Which I mean leads to end conclusion that this particular function is
> a tricky example to answer the questions asked. :)
>
>>
>> Another suggestion from Michael (michael.cheng@intel.com) involved
>> using a single object file, a single header, and splitting various
>> functions calls via ifdefs in the header file.
>
> In principle, mostly what you have outlined sounds acceptable to me,
> with the difference that I would not use i915_platform, but for this
> particular example something like i915_hypervisor prefix.
>
> Then I would prepare i915 with the same scheme kernel uses, not just
> for source file divergence, but header file as well. That is:
>
> some_source.c:
>
> #include "i915_hypervisor.h"
>
> i915_hypervisor.h:
>
> #include "platform/i915_hypervisor.h"
>
> Then in i915 root you could have:
>
> platforms/x86/include/platform/i915_hypervisor.h
> platforms/arm/include/platform/i915_hypervisor.h
>
> And some kbuild stuff to make that work. Is this doable and does it
> make sense? Per-platform source files could live in there as well.
>
> Same scheme for i915_clflush would work as well.
I like the idea of getting more specific for the calls here, but I'm
somewhat afraid of obfuscating these functions to their own files in
addition to scaling issues if we do have more and more arch-specific
calls, along with more architectures in the future.
This just seems like it could blow up the driver in what could
ultimately be unnecessary organization for a fewer number of calls if we
just add a few platforms and different calls.
What do you think?
Regards,
Casey
>
> Regards,
>
> Tvrtko
>
>>
>> I would appreciate any input on how we can avoid scaling issues when
>> including multiple architectures and multiple functions (as the number
>> of function calls will inevitably increase with more architectures).
>>
>> Casey Bowman (1):
>> i915/drm: Split out x86 and arm64 functionality
>>
>> drivers/gpu/drm/i915/Makefile | 4 +++
>> drivers/gpu/drm/i915/i915_drv.h | 6 +---
>> drivers/gpu/drm/i915/i915_platform.h | 16 +++++++++++
>> drivers/gpu/drm/i915/i915_platform_arm64.c | 33 ++++++++++++++++++++++
>> drivers/gpu/drm/i915/i915_platform_x86.c | 33 ++++++++++++++++++++++
>> 5 files changed, 87 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/i915_platform.h
>> create mode 100644 drivers/gpu/drm/i915/i915_platform_arm64.c
>> create mode 100644 drivers/gpu/drm/i915/i915_platform_x86.c
>>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-02-09 5:25 ` Casey Bowman
@ 2022-02-10 11:10 ` Tvrtko Ursulin
2022-02-10 20:12 ` Casey Bowman
0 siblings, 1 reply; 13+ messages in thread
From: Tvrtko Ursulin @ 2022-02-10 11:10 UTC (permalink / raw)
To: Casey Bowman, intel-gfx
Cc: michael.cheng, jani.nikula, lucas.demarchi, daniel.vetter, ville.syrjala
On 09/02/2022 05:25, Casey Bowman wrote:
>
> On 2/7/22 07:36, Tvrtko Ursulin wrote:
>>
>> On 20/01/2022 22:16, Casey Bowman wrote:
>>> In this RFC I would like to ask the community their thoughts
>>> on how we can best handle splitting architecture-specific
>>> calls.
>>>
>>> I would like to address the following:
>>>
>>> 1. How do we want to split architecture calls? Different object files
>>> per platform? Separate function calls within the same object file?
>>
>> If we are talking about per-platform divergence of significant
>> functions (not necessarily in size but their height position in the
>> i915 stack) I agree with Jani that top-level per platform organisation
>> is not the best choice.
>>
>> On the other hand I doubt that there should be many, if any, such
>> functions. In practice I think it should be only low level stuff which
>> diverges.
> I agree, as said with my reply to Jani, I think maybe going forward for
> arch-specific code, #if IS_ENABLED calls should be used sparingly, only
> in the cases where we do have that arch-specific implementation (like
> low level calls), instead of just a 'return null', as in my case.
>>
>> On a concrete example..
>>
>>> 2. How do we address dummy functions? If we have a function call that is
>>> used for one or more platforms, but is not used in another, what should
>>> we do for this case?
>>
>> ... depends on the situation. Sometimes a flavour of "warn on once"
>> can be okay I guess, but also why not build bug on? Because..
> True, with Jani's and your comments, I'm thinking that in the case of
> when we look at a potential arch-specific function where we're just
> returning null or something similar, we should be re-evaluating the
> function and seeing if we should make a different change there.
>>
>>>
>>> I've given an example of splitting an architecture call
>>> in my patch with run_as_guest() being split into different
>>> implementations for x86 and arm64 in separate object files, sharing
>>> a single header.
>>
>> ... run_as_guest may be a very tricky example, given it is called from
>> intel_vtd_active which has a number of callers.
>>
>> What is correct behaviour on Arm in this example? None of these call
>> sites will run on Arm? Or that you expect the warn on added in this
>> patch to trigger as a demonstration? If so, what is the plan going
>> forward? We can take one example and talk about it hypothetically:
>>
>> ./i915_driver.c: drm_printf(p, "iommu: %s\n",
>> enableddisabled(intel_vtd_active(i915)));
>>
>> What is the "fix" (refactor) for Arm here? Looks like a new top-level
>> function is needed which does not carry the intel_vtd_ prefix but
>> something more generic. That one could then legitimately "warn on
>> once", while for intel_vtd_active it would be wrong to do so.
>
> Good point, run_as_guest might be a bit more challenging of an example.
>
> In my mind, I was thinking of just simply returning null for arm64 here
> as I don't believe arm64 would be making use of iommu for our cases (at
> least, in the short term).
> I think this example function specifically needs to get reworked, as you
> mentioned, in some way, possibly refactoring intel_vtd_active or
> something along those lines.
>
>>
>> And when I say it is needed.. well perhaps it is not strictly needed
>> in this case, but in some other cases I think we go back to the
>> problem I stated some months ago and that is that I suspect use of
>> intel_vtd_active is overloaded. I think it is currently used to answer
>> all these questions: 1. Is the IOMMU active, just for information.; 2.
>> Is the IOMMU active and we want to counteract the performance hit by
>> say using huge pages, adjusting the display bandwidth calculations or
>> whatever. (In which case we also may want to distinguish between
>> pass-through and translation modes.); 3. Is a potentially buggy IOMMU
>> active and we need to work around it. All these under one kind of
>> worked with one iommu implementation but does it with a different IOMMU?
>>
>> Which I mean leads to end conclusion that this particular function is
>> a tricky example to answer the questions asked. :)
>>
>>>
>>> Another suggestion from Michael (michael.cheng@intel.com) involved
>>> using a single object file, a single header, and splitting various
>>> functions calls via ifdefs in the header file.
>>
>> In principle, mostly what you have outlined sounds acceptable to me,
>> with the difference that I would not use i915_platform, but for this
>> particular example something like i915_hypervisor prefix.
>>
>> Then I would prepare i915 with the same scheme kernel uses, not just
>> for source file divergence, but header file as well. That is:
>>
>> some_source.c:
>>
>> #include "i915_hypervisor.h"
>>
>> i915_hypervisor.h:
>>
>> #include "platform/i915_hypervisor.h"
>>
>> Then in i915 root you could have:
>>
>> platforms/x86/include/platform/i915_hypervisor.h
>> platforms/arm/include/platform/i915_hypervisor.h
>>
>> And some kbuild stuff to make that work. Is this doable and does it
>> make sense? Per-platform source files could live in there as well.
>>
>> Same scheme for i915_clflush would work as well.
>
> I like the idea of getting more specific for the calls here, but I'm
> somewhat afraid of obfuscating these functions to their own files in
> addition to scaling issues if we do have more and more arch-specific
> calls, along with more architectures in the future.
>
> This just seems like it could blow up the driver in what could
> ultimately be unnecessary organization for a fewer number of calls if we
> just add a few platforms and different calls.
> What do you think?
I don't have a good crystal ball to see how many of these you would end
up during the Arm porting effort, just my gut feeling that it shouldn't
be a problem to add a few files.
And I don't think it would be obfuscating anything, on the contrary it
makes things very clear in respect where the platform dependent boundary
is and what are all the bits that diverge per platforms.
Personally I would just do this all as part of your other series which
touches clflush and in that way establish a pattern from the start. Plus
that way I sleep easy not thinking how we started penalizing old
platforms with needless new function calls on hot paths. But it is my
opinion only and other people may think differently.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls
2022-02-10 11:10 ` Tvrtko Ursulin
@ 2022-02-10 20:12 ` Casey Bowman
0 siblings, 0 replies; 13+ messages in thread
From: Casey Bowman @ 2022-02-10 20:12 UTC (permalink / raw)
To: Tvrtko Ursulin, intel-gfx
Cc: michael.cheng, jani.nikula, lucas.demarchi, daniel.vetter, ville.syrjala
On 2/10/22 03:10, Tvrtko Ursulin wrote:
>
> On 09/02/2022 05:25, Casey Bowman wrote:
>>
>> On 2/7/22 07:36, Tvrtko Ursulin wrote:
>>>
>>> On 20/01/2022 22:16, Casey Bowman wrote:
>>>> In this RFC I would like to ask the community their thoughts
>>>> on how we can best handle splitting architecture-specific
>>>> calls.
>>>>
>>>> I would like to address the following:
>>>>
>>>> 1. How do we want to split architecture calls? Different object files
>>>> per platform? Separate function calls within the same object file?
>>>
>>> If we are talking about per-platform divergence of significant
>>> functions (not necessarily in size but their height position in the
>>> i915 stack) I agree with Jani that top-level per platform
>>> organisation is not the best choice.
>>>
>>> On the other hand I doubt that there should be many, if any, such
>>> functions. In practice I think it should be only low level stuff
>>> which diverges.
>> I agree, as said with my reply to Jani, I think maybe going forward
>> for arch-specific code, #if IS_ENABLED calls should be used
>> sparingly, only in the cases where we do have that arch-specific
>> implementation (like low level calls), instead of just a 'return
>> null', as in my case.
>>>
>>> On a concrete example..
>>>
>>>> 2. How do we address dummy functions? If we have a function call
>>>> that is
>>>> used for one or more platforms, but is not used in another, what
>>>> should
>>>> we do for this case?
>>>
>>> ... depends on the situation. Sometimes a flavour of "warn on once"
>>> can be okay I guess, but also why not build bug on? Because..
>> True, with Jani's and your comments, I'm thinking that in the case of
>> when we look at a potential arch-specific function where we're just
>> returning null or something similar, we should be re-evaluating the
>> function and seeing if we should make a different change there.
>>>
>>>>
>>>> I've given an example of splitting an architecture call
>>>> in my patch with run_as_guest() being split into different
>>>> implementations for x86 and arm64 in separate object files, sharing
>>>> a single header.
>>>
>>> ... run_as_guest may be a very tricky example, given it is called
>>> from intel_vtd_active which has a number of callers.
>>>
>>> What is correct behaviour on Arm in this example? None of these call
>>> sites will run on Arm? Or that you expect the warn on added in this
>>> patch to trigger as a demonstration? If so, what is the plan going
>>> forward? We can take one example and talk about it hypothetically:
>>>
>>> ./i915_driver.c: drm_printf(p, "iommu: %s\n",
>>> enableddisabled(intel_vtd_active(i915)));
>>>
>>> What is the "fix" (refactor) for Arm here? Looks like a new
>>> top-level function is needed which does not carry the intel_vtd_
>>> prefix but something more generic. That one could then legitimately
>>> "warn on once", while for intel_vtd_active it would be wrong to do so.
>>
>> Good point, run_as_guest might be a bit more challenging of an example.
>>
>> In my mind, I was thinking of just simply returning null for arm64
>> here as I don't believe arm64 would be making use of iommu for our
>> cases (at least, in the short term).
>> I think this example function specifically needs to get reworked, as
>> you mentioned, in some way, possibly refactoring intel_vtd_active or
>> something along those lines.
>>
>>>
>>> And when I say it is needed.. well perhaps it is not strictly needed
>>> in this case, but in some other cases I think we go back to the
>>> problem I stated some months ago and that is that I suspect use of
>>> intel_vtd_active is overloaded. I think it is currently used to
>>> answer all these questions: 1. Is the IOMMU active, just for
>>> information.; 2. Is the IOMMU active and we want to counteract the
>>> performance hit by say using huge pages, adjusting the display
>>> bandwidth calculations or whatever. (In which case we also may want
>>> to distinguish between pass-through and translation modes.); 3. Is a
>>> potentially buggy IOMMU active and we need to work around it. All
>>> these under one kind of worked with one iommu implementation but
>>> does it with a different IOMMU?
>>>
>>> Which I mean leads to end conclusion that this particular function
>>> is a tricky example to answer the questions asked. :)
>>>
>>>>
>>>> Another suggestion from Michael (michael.cheng@intel.com) involved
>>>> using a single object file, a single header, and splitting various
>>>> functions calls via ifdefs in the header file.
>>>
>>> In principle, mostly what you have outlined sounds acceptable to me,
>>> with the difference that I would not use i915_platform, but for this
>>> particular example something like i915_hypervisor prefix.
>>>
>>> Then I would prepare i915 with the same scheme kernel uses, not just
>>> for source file divergence, but header file as well. That is:
>>>
>>> some_source.c:
>>>
>>> #include "i915_hypervisor.h"
>>>
>>> i915_hypervisor.h:
>>>
>>> #include "platform/i915_hypervisor.h"
>>>
>>> Then in i915 root you could have:
>>>
>>> platforms/x86/include/platform/i915_hypervisor.h
>>> platforms/arm/include/platform/i915_hypervisor.h
>>>
>>> And some kbuild stuff to make that work. Is this doable and does it
>>> make sense? Per-platform source files could live in there as well.
>>>
>>> Same scheme for i915_clflush would work as well.
>>
>> I like the idea of getting more specific for the calls here, but I'm
>> somewhat afraid of obfuscating these functions to their own files in
>> addition to scaling issues if we do have more and more arch-specific
>> calls, along with more architectures in the future.
>>
>> This just seems like it could blow up the driver in what could
>> ultimately be unnecessary organization for a fewer number of calls if
>> we just add a few platforms and different calls.
>> What do you think?
>
> I don't have a good crystal ball to see how many of these you would
> end up during the Arm porting effort, just my gut feeling that it
> shouldn't be a problem to add a few files.
>
> And I don't think it would be obfuscating anything, on the contrary it
> makes things very clear in respect where the platform dependent
> boundary is and what are all the bits that diverge per platforms.
Fair enough, I'll look into writing up something as an update for
further review.
>
> Personally I would just do this all as part of your other series which
> touches clflush and in that way establish a pattern from the start.
> Plus that way I sleep easy not thinking how we started penalizing old
> platforms with needless new function calls on hot paths. But it is my
> opinion only and other people may think differently.
I believe that series is authored by Michael, not myself :P
But I do agree with trying to establishing a precedent here for future,
similar calls.
It would definitely be helpful to get more opinions for consensus on
this, as we know there's many ways to go about this.
In the meantime, to form a basic guideline that others can help mold, I
believe the precedent as of the moment for porting i915 functionality
for other architectures is:
- If the functionality has low-level code that must be ported to another
arch, use #if IS_ENABLED to split out the function calls by arch config
(this should be sparingly used).
- If the functionality is specific to x86 architecture (has library
calls that only pertain to x86), split out the call to a platform
dependent area (so long as there isn't an already-existing generic call
available that can be used in a refactor).
Does this sort of guideline make sense/sound correct? I want to make
something we can reference when porting various pieces of functionality
throughout the driver.
Regards,
Casey
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-02-10 20:12 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-20 22:16 [Intel-gfx] [RFC PATCH 0/1] Splitting up platform-specific calls Casey Bowman
2022-01-20 22:16 ` [Intel-gfx] [RFC PATCH 1/1] i915/drm: Split out x86 and arm64 functionality Casey Bowman
2022-01-20 23:58 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Splitting up platform-specific calls Patchwork
2022-01-20 23:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-21 0:34 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-01-21 4:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-02-03 23:58 ` [Intel-gfx] [RFC PATCH 0/1] " Casey Bowman
2022-02-07 13:02 ` Jani Nikula
2022-02-09 5:07 ` Casey Bowman
2022-02-07 15:36 ` Tvrtko Ursulin
2022-02-09 5:25 ` Casey Bowman
2022-02-10 11:10 ` Tvrtko Ursulin
2022-02-10 20:12 ` Casey Bowman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.