[Intel-gfx] [PATCH i-g-t v4 2/2] i915/gem_ctx_isolation: Check engine relative registers (revised)
From: Chris Wilson
Some of the non-privileged registers are at the same offset on each
engine. We can improve our coverage for unknown HW layout by using the
reported engine->mmio_base for relative offsets.
Subsequent to sign-off by Chris Wilson, added by Dale B Stimson:
Modify previous "i915/gem_ctx_isolation: Check engine relative registers"
to support alternative mmio_base infrastructure API.
Signed-off-by: Chris Wilson
Signed-off-by: Dale B Stimson
---
lib/i915/gem_mmio_base.c | 7 +-
tests/i915/gem_ctx_isolation.c | 229 -
2 files changed, 141 insertions(+), 95 deletions(-)
diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
index d1b83221a..c712b4431 100644
--- a/lib/i915/gem_mmio_base.c
+++ b/lib/i915/gem_mmio_base.c
@@ -286,13 +286,14 @@ struct eng_mmio_base_table_s
*gem_engine_mmio_base_info_get(int fd_dev)
{
struct eng_mmio_base_table_s *mbp = NULL;
- /* If and when better ways are provided to find the mmio_base
-* information, they may be added them here in order of preference.
+ /* If and when more desirable ways exist to find the mmio_base
+* information, they may be added here, in order of consideration.
*/
#if 0
+ /* Anticipating a future method: */
if (!mbp)
- mbp = _mmio_base_info_get_via_sysfs(fd_dev);
+ mbp = _gem_engine_mmio_base_info_get_sysfs(fd_dev);
#endif
if (!mbp)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 1b66fec11..07ffbb84a 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -70,6 +70,7 @@ static const struct named_register {
uint32_t ignore_bits;
uint32_t write_mask; /* some registers bits do not exist */
bool masked;
+ bool relative;
} nonpriv_registers[] = {
{ "NOPID", NOCTX, RCS0, 0x2094 },
{ "MI_PREDICATE_RESULT_2", NOCTX, RCS0, 0x23bc },
@@ -109,7 +110,6 @@ static const struct named_register {
{ "PS_DEPTH_COUNT_1", GEN8, RCS0, 0x22f8, 2 },
{ "BB_OFFSET", GEN8, RCS0, 0x2158, .ignore_bits = 0x7 },
{ "MI_PREDICATE_RESULT_1", GEN8, RCS0, 0x241c },
- { "CS_GPR", GEN8, RCS0, 0x2600, 32 },
{ "OA_CTX_CONTROL", GEN8, RCS0, 0x2360 },
{ "OACTXID", GEN8, RCS0, 0x2364 },
{ "PS_INVOCATION_COUNT_2", GEN8, RCS0, 0x2448, 2, .write_mask = ~0x3 },
@@ -138,79 +138,56 @@ static const struct named_register {
{ "CTX_PREEMPT", NOCTX /* GEN10 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN11, RCS0, 0x2580, .masked = true },
- { "HDC_CHICKEN1", GEN_RANGE(10, 10), RCS0, 0x7304, .masked = true },
/* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
{ "CTX_PREEMPT", NOCTX /* GEN9 */, RCS0, 0x2248 },
{ "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580, .masked = true },
{ "COMMON_SLICE_CHICKEN2", GEN_RANGE(9, 9), RCS0, 0x7014, .masked =
true },
- { "HDC_CHICKEN1", GEN_RANGE(9, 9), RCS0, 0x7304, .masked = true },
+ { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304, .masked = true },
{ "SLICE_COMMON_ECO_CHICKEN1", GEN_RANGE(11, 11) /* + glk */, RCS0,
0x731c, .masked = true },
{ "L3SQREG4", NOCTX /* GEN9:skl,kbl */, RCS0, 0xb118, .write_mask =
~0x10 },
{ "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194, .masked =
true },
{ "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xe18c, .masked = true },
- { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
{ "BCS_SWCTRL", GEN8, BCS0, 0x22200, .write_mask = 0x3, .masked = true
},
{ "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
{ "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
- { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
- { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
- { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
-
- { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
- { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
- { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
- { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
- { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },
+ { "xCS_GPR", GEN9, ALL, 0x600, 32, .relative = true },
{}
}, ignore_registers[] = {
{ "RCS timestamp", GEN6, ~0u, 0x2358 },
{ "BCS timestamp", GEN7, ~0u, 0x22358 },
- { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
- { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
- { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
-
- { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
- { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
- { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
- { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
- { "VECS timestamp", GEN11, ~0u, 0x1c8358 },
+ { "xCS timestamp", GEN8, ALL, 0x358, .relative = true },
/* huc read only */
- { "BSD0 0x2000", GEN11, ~0u, 0x1c + 0x2000 },
- { "BSD0
[Intel-gfx] [PATCH i-g-t v4 1/2] i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
Signed-off-by: Dale B Stimson
---
lib/Makefile.sources | 2 +
lib/i915/gem_mmio_base.c | 353 +++
lib/i915/gem_mmio_base.h | 19 +++
lib/igt.h| 1 +
lib/meson.build | 1 +
5 files changed, 376 insertions(+)
create mode 100644 lib/i915/gem_mmio_base.c
create mode 100644 lib/i915/gem_mmio_base.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 3e573f267..4c5d50d5d 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -7,6 +7,8 @@ lib_source_list = \
i915/gem_context.h \
i915/gem_engine_topology.c \
i915/gem_engine_topology.h \
+ i915/gem_mmio_base.c\
+ i915/gem_mmio_base.h\
i915/gem_scheduler.c\
i915/gem_scheduler.h\
i915/gem_submission.c \
diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
new file mode 100644
index 0..d1b83221a
--- /dev/null
+++ b/lib/i915/gem_mmio_base.c
@@ -0,0 +1,353 @@
+// Copyright (C) 2020 Intel Corporation
+//
+// SPDX-License-Identifier: MIT
+
+#include
+
+#include
+
+#include "igt.h"
+
+struct eng_mmio_base_s {
+ char name[8];
+ uint32_t mmio_base;
+};
+
+struct eng_mmio_base_table_s {
+ unsigned int mb_cnt;
+ struct eng_mmio_base_s mb_tab[GEM_MAX_ENGINES];
+};
+
+
+static struct eng_mmio_base_table_s *_gem_engine_mmio_info_dup(
+ const struct eng_mmio_base_table_s *mbpi)
+{
+ struct eng_mmio_base_table_s *mbpo;
+ size_t nbytes;
+
+ nbytes = offsetof(typeof(struct eng_mmio_base_table_s),
mb_tab[mbpi->mb_cnt]);
+ mbpo = malloc(nbytes);
+ igt_assert(mbpo);
+ memcpy(mbpo, mbpi, nbytes);
+
+ return mbpo;
+}
+
+void gem_engine_mmio_base_info_free(struct eng_mmio_base_table_s *mbp)
+{
+ if (mbp)
+ free(mbp);
+}
+
+static void _gem_engine_mmio_info_legacy_add(struct eng_mmio_base_table_s *mbp,
+ const char *eng_name, uint32_t mmio_base)
+{
+ if (mmio_base) {
+ strncpy(mbp->mb_tab[mbp->mb_cnt].name, eng_name,
+ sizeof(mbp->mb_tab[0].name));
+ mbp->mb_tab[mbp->mb_cnt].mmio_base = mmio_base;
+ mbp->mb_cnt++;
+ }
+}
+
+/**
+ * _gem_engine_mmio_base_info_get_legacy:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Provides per-engine mmio_base information from legacy built-in values
+ * for the case when the information is not otherwise available.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ */
+static struct eng_mmio_base_table_s *_gem_engine_mmio_base_info_get_legacy(int
fd_dev)
+{
+ int gen;
+ uint32_t mmio_base;
+ struct eng_mmio_base_table_s mbt;
+ struct eng_mmio_base_table_s *mbp;
+
+ memset(, 0, sizeof(mbt));
+
+ gen = intel_gen(intel_get_drm_devid(fd_dev));
+
+ /* The mmio_base values for engine instances 1 and higher cannot
+* be reliability determinated a priori. */
+
+ _gem_engine_mmio_info_legacy_add(, "rcs0", 0x2000);
+ _gem_engine_mmio_info_legacy_add(, "bcs0", 0x22000);
+
+ if (gen < 6)
+ mmio_base = 0x4000;
+ else if (gen < 11)
+ mmio_base = 0x12000;
+ else
+ mmio_base = 0x1c;
+ _gem_engine_mmio_info_legacy_add(, "vcs0", mmio_base);
+
+ if (gen < 11)
+ mmio_base = 0x1a000;
+ else
+ mmio_base = 0x1c8000;
+ _gem_engine_mmio_info_legacy_add(, "vecs0", mmio_base);
+
+ if (mbt.mb_cnt <= 0)
+ return NULL;
+
+ mbp = _gem_engine_mmio_info_dup();
+
+ return mbp;
+}
+
+
+/**
+ * _gem_engine_mmio_base_info_get_debugfs:
+ * @fd_dev: file descriptor upon which device is open or -1 to use defaults.
+ *
+ * Obtains per-engine mmio_base information from debugfs.
+ *
+ * Returns:
+ * Pointer to dynamically allocated struct eng_mmio_base_table_s describing
+ * engine config or NULL.
+ * The allocated size does not include unused engine entries.
+ * If non-NULL, it is caller's responsibility to free.
+ *
+ * Looking in debugfs for per-engine instances of:
+ *
+ * ...
+ * MMIO base:
+ *
+ * Example of relevant lines from debugfs:
+ * vcs0
+ * MMIO base: 0x001c
+ * vcs1
+ * MMIO base: 0x001d
+ *
+ * In order to qualify as the introduction of a new per-engine section, an
+ * input line must consist solely of an engine name. An engine name must
+ * be 7 or fewer characters in length and must consist of an engine class
+ * name of 3 or more lower case characters followed by an instance number.
+ */
+static struct eng_mmio_base_table_s
[Intel-gfx] [RFC i-g-t] lib/i915/gem_mmio_base.c - add support for mmio_base via sysfs
Obtaining mmio_base info via sysfs (if available). This is in addition
to the already existing support for obtaining that data via debugfs.
The use of sysfs data is preferred.
This patch depends upon the following proposed IGT patch, which is not
presently merged:
i915/gem_mmio_base.c - get mmio_base from debugfs (if possible)
The availability of sysfs info for mmio_base depends on the presence of
these two proposed kernel patches, not presently merged:
drm/i915/gt: Expose engine properties via sysfs
drm/i915/gt: Expose engine->mmio_base via sysfs
Signed-off-by: Dale B Stimson
---
lib/i915/gem_mmio_base.c | 79
1 file changed, 79 insertions(+)
diff --git a/lib/i915/gem_mmio_base.c b/lib/i915/gem_mmio_base.c
index 514f87f42..8a29a9150 100644
--- a/lib/i915/gem_mmio_base.c
+++ b/lib/i915/gem_mmio_base.c
@@ -5,8 +5,11 @@
#include
#include
+#include
+#include
#include "igt.h"
+#include "igt_sysfs.h"
struct eng_mmio_base_s {
char name[8];
@@ -102,6 +105,82 @@ static struct eng_mmio_base_table_s
*_gem_engine_mmio_base_info_get_legacy(int f
return mbp;
}
+static struct eng_mmio_base_table_s *_gem_engine_mmio_base_info_get_sysfs(int
fd_dev)
+{
+ struct eng_mmio_base_table_s mbt;
+ struct eng_mmio_base_table_s *mbp = NULL;
+ const size_t name_max = sizeof(mbt.mb_tab[0].name);
+ int fd_top = -1;
+ int fd_engines = -1;
+ int fd_this;
+ int fd_mmio_base;
+ DIR *dirp = NULL;
+ struct dirent *pde;
+ const char *eng_name;
+ ssize_t nb;
+ char rbuf[32];
+ unsigned long int ulv;
+ uint32_t uiv;
+
+ memset(, 0, sizeof(mbt));
+
+ fd_top = igt_sysfs_open(fd_dev);
+ if (fd_top < 0)
+ goto mbsf_cleanup;
+
+ fd_engines = openat(fd_top, "engine", O_RDONLY);
+ if (fd_engines < 0)
+ goto mbsf_cleanup;
+
+ dirp = fdopendir(fd_engines);
+ if (!dirp)
+ goto mbsf_cleanup;
+
+ for (;;) {
+ pde = readdir(dirp);
+ if (!pde)
+ break;
+
+ if ((pde->d_type == DT_DIR) || (pde->d_type == DT_UNKNOWN)) {
+ eng_name = pde->d_name;
+ if (eng_name[0] == '.')
+ continue;
+ fd_this = openat(fd_engines, eng_name, O_RDONLY);
+ if (fd_this < 0)
+ continue;
+ fd_mmio_base = openat(fd_this, "mmio_base", O_RDONLY);
+ close(fd_this);
+ if (fd_mmio_base < 0)
+ goto mbsf_cleanup;
+ nb = read(fd_mmio_base, rbuf, sizeof(rbuf));
+ close(fd_mmio_base);
+ if (nb > 0) {
+ ulv = strtoul(rbuf, NULL, 16);
+ uiv = (uint32_t) ulv;
+
+ strncpy(mbt.mb_tab[mbt.mb_cnt].name,
+ eng_name, name_max);
+ mbt.mb_tab[mbt.mb_cnt].mmio_base = uiv;
+ mbt.mb_cnt++;
+ }
+ }
+ }
+
+ if (mbt.mb_cnt > 0)
+ mbp = _gem_engine_mmio_info_dup();
+
+mbsf_cleanup:
+ if (dirp)
+ closedir(dirp);
+
+ if (fd_engines >= 0)
+ close(fd_engines);
+ if (fd_top >= 0)
+ close(fd_top);
+
+ return mbp;
+}
+
/**
* _gem_engine_mmio_base_info_get_debugfs:
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 0/2] mmio_base via debugfs infrastructure + gem_ctx_isolation
v4: Functionally identical to V3. - Commentary - name of potential future method for getting info from sysfs changed from _mmio_base_info_get_via_sysfs() to _gem_engine_mmio_base_info_get_sysfs(). - Patches squashed in order to avoid compilation break in between, from: i915/gem_ctx_isolation: Check engine relative registers i915/gem_ctx_isolation: Check engine relative registers - Part 2 to: i915/gem_ctx_isolation: Check engine relative registers (revised) - The narrative below has been modified. For the record, a separate patch exists that provides support for the proposed sysfs source of mmio_base information via new function _gem_engine_mmio_base_info_get_sysfs(). It depends on this patch series. It is planned to send it to the ML separately. lib/i915/gem_mmio_base.c - add support for mmio_base via sysfs v3: - Remove v2 early-exit patches (previous 4/5 and 5/5). The underlying issue was addressed via a separately-submitted patch. v2: - Introduce and use igt_exit_early() so that a failed initialization (in igt_fixture) will not attempt to invoke the per-engine loop. - Initialize mmio_base db inside initial igt_fixture instead of after. - Some additional functions handle NULL input mmio_base db pointer. - Variables mbp and mmio_base initialized to NULL/0 so their values will not be uninitialized for --list-subtests. - Failure to obtain an mmio_base db is now igt_debug instead of igt_warn. This patch series provides infrastructure to allow determination of i915 per-engine mmio_base (which is otherwise sometimes hard to get). The provided method uses debugfs mmio_base information if present. Otherwise, a default determination is provided when possible. Also, gem_ctx_isolation is modified to use the new infrastructure. For example, on TGL, gem_ctx_isolation (without these or similar changes) will fail for subtests that use engine vcs1. On 2020-01-27 (most recently), Chris Wilson sent this patch series to the ML: [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use [igt-dev] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative registers plus the following, which are not addressed here: [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls [igt-dev] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property This patch series is: i915/gem_mmio_base.c - get mmio_base from debugfs (if possible) i915/gem_ctx_isolation: Check engine relative registers (revised) The first patch of the earlier series obtains mmio_base information via sysfs, and depends on a proposed kernel change that would provide the mmio_base information via sysfs. The mmio_base information used by this patch series is available through debugfs now (as of kernel 5.4). If the per-engine mmio_base information is ever added to sysfs, a patch is already available to plug that into the infrastructure proposed here as an additional higher-priority source of that information. As compared to the original patch series, this submission replaces the first patch and retains the second patch with modifications to support the changed API. Some differences from the 2020-01-27 patches: The mmio_base information is fetched once into local data structures, and is obtained from them thereafter instead of being fetched from the kernel everytime it is wanted. The function that obtains the mmio_base information is called by a particular test that wants it, and returns a handle through which the mmio_base can be requested for any particular engine. These patches introduce new source files lib/i915/gem_mmio_base.c and lib/i915/gem_mmio_base.h. The 2020-01-27 patch series define function gem_engine_mmio_base() with its first parameter as "fd". The new patch series replace the first parameter with the mmio_base object handle. Chris Wilson (1): i915/gem_ctx_isolation: Check engine relative registers (revised) Dale B Stimson (1): i915/gem_mmio_base.c - get mmio_base from debugfs (if possible) lib/Makefile.sources | 2 + lib/i915/gem_mmio_base.c | 354 + lib/i915/gem_mmio_base.h | 19 ++ lib/igt.h | 1 + lib/meson.build| 1 + tests/i915/gem_ctx_isolation.c | 229 - 6 files changed, 514 insertions(+), 92 deletions(-) create mode 100644 lib/i915/gem_mmio_base.c create mode 100644 lib/i915/gem_mmio_base.h -- 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: success for series starting with [v2,1/2] drm/i915/mst: Set intel_dp_set_m_n() for MST slaves
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/mst: Set intel_dp_set_m_n() for
MST slaves
URL : https://patchwork.freedesktop.org/series/7/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7926_full -> Patchwork_16536_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_16536_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-skl3/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-skl9/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
Known issues
Here are the changes found in Patchwork_16536_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +8 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-iclb4/igt@gem_b...@busy-vcs1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-iclb6/igt@gem_b...@busy-vcs1.html
* igt@gem_caching@read-writes:
- shard-hsw: [PASS][5] -> [FAIL][6] ([i915#694])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-hsw7/igt@gem_cach...@read-writes.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-hsw6/igt@gem_cach...@read-writes.html
* igt@gem_exec_capture@capture-bsd2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +8 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-iclb1/igt@gem_exec_capt...@capture-bsd2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-iclb6/igt@gem_exec_capt...@capture-bsd2.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][9] -> [SKIP][10] ([i915#677])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-iclb5/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-iclb4/igt@gem_exec_sched...@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +4 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-iclb7/igt@gem_exec_sched...@reorder-wide-bsd.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#69]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-skl5/igt@gem_workarou...@suspend-resume-fd.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-skl8/igt@gem_workarou...@suspend-resume-fd.html
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118] /
[i915#95])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-glk6/igt@i915_pm_...@modeset-stress-extra-wait.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html
* igt@kms_color@pipe-a-gamma:
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#1149])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-tglb7/igt@kms_co...@pipe-a-gamma.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-tglb6/igt@kms_co...@pipe-a-gamma.html
* igt@kms_cursor_crc@pipe-c-cursor-128x128-random:
- shard-skl: [PASS][19] -> [FAIL][20] ([i915#54])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-skl1/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-128x128-random.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#72])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7926/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16536/shard-glk3/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-skl: [PASS][23] -> [FAIL][24] ([IGT#5])
[23]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Declare when we enabled timeslicing
== Series Details ==
Series: drm/i915/gt: Declare when we enabled timeslicing
URL : https://patchwork.freedesktop.org/series/73490/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7943 -> Patchwork_16580
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/index.html
Known issues
Here are the changes found in Patchwork_16580 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#877])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [INCOMPLETE][3] ([i915#45]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
- fi-byt-n2820: [INCOMPLETE][5] ([i915#45]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_parallel@basic:
- {fi-ehl-1}: [FAIL][7] ([i915#996]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-ehl-1/igt@gem_exec_paral...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/fi-ehl-1/igt@gem_exec_paral...@basic.html
* igt@i915_selftest@live_active:
- fi-icl-y: [DMESG-FAIL][9] ([i915#765]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-y/igt@i915_selftest@live_active.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/fi-icl-y/igt@i915_selftest@live_active.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#765]: https://gitlab.freedesktop.org/drm/intel/issues/765
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#996]: https://gitlab.freedesktop.org/drm/intel/issues/996
Participating hosts (41 -> 42)
--
Additional (8): fi-kbl-soraka fi-hsw-peppy fi-ivb-3770 fi-cfl-8109u
fi-skl-lmem fi-blb-e6850 fi-bsw-nick fi-skl-6600u
Missing(7): fi-hsw-4200u fi-byt-squawks fi-bwr-2160 fi-ctg-p8600
fi-bsw-kefka fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7943 -> Patchwork_16580
CI-20190529: 20190529
CI_DRM_7943: 865945b076689b2e99bc1c52fad95cec05cff9ed @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16580: 6b4d4ba4c21b25d04e37a9aa0784dd8e8e32073a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6b4d4ba4c21b drm/i915/gt: Declare when we enabled timeslicing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16580/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gt: Declare when we enabled timeslicing
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Declare when we enabled
timeslicing
URL : https://patchwork.freedesktop.org/series/73489/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7943 -> Patchwork_16579
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16579/index.html
Known issues
Here are the changes found in Patchwork_16579 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-guc: [PASS][1] -> [INCOMPLETE][2] ([CI#80] / [fdo#106070]
/ [i915#424])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16579/fi-cfl-guc/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_gt_heartbeat:
- fi-kbl-7500u: [PASS][3] -> [DMESG-FAIL][4] ([fdo#112406])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-kbl-7500u/igt@i915_selftest@live_gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16579/fi-kbl-7500u/igt@i915_selftest@live_gt_heartbeat.html
Possible fixes
* igt@gem_exec_parallel@basic:
- {fi-ehl-1}: [FAIL][5] ([i915#996]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-ehl-1/igt@gem_exec_paral...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16579/fi-ehl-1/igt@gem_exec_paral...@basic.html
* igt@i915_selftest@live_active:
- fi-icl-y: [DMESG-FAIL][7] ([i915#765]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7943/fi-icl-y/igt@i915_selftest@live_active.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16579/fi-icl-y/igt@i915_selftest@live_active.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[CI#80]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/80
[fdo#106070]: https://bugs.freedesktop.org/show_bug.cgi?id=106070
[fdo#112406]: https://bugs.freedesktop.org/show_bug.cgi?id=112406
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#765]: https://gitlab.freedesktop.org/drm/intel/issues/765
[i915#996]: https://gitlab.freedesktop.org/drm/intel/issues/996
Participating hosts (41 -> 41)
--
Additional (6): fi-kbl-soraka fi-bsw-n3050 fi-hsw-peppy fi-cfl-8109u
fi-skl-lmem fi-blb-e6850
Missing(6): fi-hsw-4200u fi-byt-squawks fi-ctg-p8600 fi-gdg-551
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7943 -> Patchwork_16579
CI-20190529: 20190529
CI_DRM_7943: 865945b076689b2e99bc1c52fad95cec05cff9ed @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16579: 25daabe03b8615a03eea700db755531ac0b93a4c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
25daabe03b86 drm/i915/gt: Yield the timeslice if caught waiting on a user
semaphore
777ee926f053 drm/i915/gt: Declare when we enabled timeslicing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16579/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/gt: Declare when we enabled timeslicing
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine.h | 3 ++-
drivers/gpu/drm/i915/gt/intel_engine_user.c | 5 +
include/uapi/drm/i915_drm.h | 1 +
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 29c8c03c5caa..a32dc82a90d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -326,7 +326,8 @@ intel_engine_has_timeslices(const struct intel_engine_cs
*engine)
if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
return false;
- return intel_engine_has_semaphores(engine);
+ return (intel_engine_has_semaphores(engine) &&
+ intel_engine_has_preemption(engine));
}
#endif /* _INTEL_RINGBUFFER_H_ */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 848decee9066..b84fdd722781 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -121,6 +121,11 @@ static void set_scheduler_caps(struct drm_i915_private
*i915)
else
disabled |= BIT(map[i].sched);
}
+
+ if (intel_engine_has_timeslices(engine))
+ enabled |= I915_SCHEDULER_CAP_TIMESLICING;
+ else
+ disabled |= I915_SCHEDULER_CAP_TIMESLICING;
}
i915->caps.scheduler = enabled & ~disabled;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 829c0a48577f..f4d521f51258 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -523,6 +523,7 @@ typedef struct drm_i915_irq_wait {
#define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
#define I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
#define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define I915_SCHEDULER_CAP_TIMESLICING (1ul << 5)
#define I915_PARAM_HUC_STATUS 42
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Declare when we enabled timeslicing
Quoting Chris Wilson (2020-02-14 23:19:16)
> Let userspace know if they can trust timeslicing by including it as part
> of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
>
> Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
> include/uapi/drm/i915_drm.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 848decee9066..760e586b7535 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private
> *i915)
> MAP(HAS_PREEMPTION, PREEMPTION),
> MAP(HAS_SEMAPHORES, SEMAPHORES),
> MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
> + MAP(HAS_SEMAPHORES, TIMESLICES),
Strictly we want HAS_PREEMPTION && HAS_SEMAPHORES before we tell
userspace it can safely rely on timeslicing to yield from
MI_SEMAPHORE_WAIT.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only real complication is that the interrupt is only generated for
the start of the semaphore wait, and is asynchronous to our
process_csb() -- that is, we may not have registered the timeslice before
we see the interrupt. To ensure we don't miss a potential semaphore
blocking forward progress (e.g. selftests/live_timeslice_preempt) we mark
the interrupt and apply it to the next timeslice regardless of whether it
was active at the time.
v2: We use semaphores in preempt-to-busy, within the timeslicing
implementation itself! Ergo, when we do insert a preemption due to an
expired timeslice, the new context may start with the missed semaphore
flagged by the retired context and be yielded, ad infinitum. To avoid
this, read the context id at the time of the semaphore interrupt and
only yield if that context is still active.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 +
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 40 +---
drivers/gpu/drm/i915/i915_reg.h | 1 +
5 files changed, 61 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f6f5e1ec48fc..89f201a5a219 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1288,6 +1288,12 @@ static void intel_engine_print_registers(struct
intel_engine_cs *engine,
if (engine->id == RENDER_CLASS && IS_GEN_RANGE(dev_priv, 4, 7))
drm_printf(m, "\tCCID: 0x%08x\n", ENGINE_READ(engine, CCID));
+ if (HAS_EXECLISTS(dev_priv)) {
+ drm_printf(m, "\tEL_STAT_HI: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_HI));
+ drm_printf(m, "\tEL_STAT_LO: 0x%08x\n",
+ ENGINE_READ(engine, RING_EXECLIST_STATUS_LO));
+ }
drm_printf(m, "\tRING_START: 0x%08x\n",
ENGINE_READ(engine, RING_START));
drm_printf(m, "\tRING_HEAD: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index b23366a81048..24cff658e6e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -156,6 +156,15 @@ struct intel_engine_execlists {
*/
struct i915_priolist default_priolist;
+ /**
+* @yield: CCID at the time of the last semaphore-wait interrupt.
+*
+* Instead of leaving a semaphore busy-spinning on an engine, we would
+* like to switch to another ready context, i.e. yielding the semaphore
+* timeslice.
+*/
+ u32 yield;
+
/**
* @error_interrupt: CS Master EIR
*
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f0e7fd95165a..875bd0392ffc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -39,6 +39,13 @@ cs_irq_handler(struct intel_engine_cs *engine, u32 iir)
}
}
+ if (iir & GT_WAIT_SEMAPHORE_INTERRUPT) {
+ WRITE_ONCE(engine->execlists.yield,
+ ENGINE_READ_FW(engine, RING_EXECLIST_STATUS_HI));
+ if (del_timer(>execlists.timer))
+ tasklet = true;
+ }
+
if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
tasklet = true;
@@ -228,7 +235,8 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
struct intel_uncore *uncore = gt->uncore;
const u32 dmask = irqs << 16 | irqs;
const u32 smask = irqs << 16;
@@ -366,7 +374,8 @@ void gen8_gt_irq_postinstall(struct intel_gt *gt)
const u32 irqs =
GT_CS_MASTER_ERROR_INTERRUPT |
GT_RENDER_USER_INTERRUPT |
- GT_CONTEXT_SWITCH_INTERRUPT;
+ GT_CONTEXT_SWITCH_INTERRUPT |
+ GT_WAIT_SEMAPHORE_INTERRUPT;
const u32 gt_interrupts[] = {
irqs << GEN8_RCS_IRQ_SHIFT | irqs << GEN8_BCS_IRQ_SHIFT,
irqs << GEN8_VCS0_IRQ_SHIFT | irqs << GEN8_VCS1_IRQ_SHIFT,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
[Intel-gfx] [PATCH 1/2] drm/i915/gt: Declare when we enabled timeslicing
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 848decee9066..760e586b7535 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+ MAP(HAS_SEMAPHORES, TIMESLICES),
#undef MAP
};
struct intel_engine_cs *engine;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 829c0a48577f..4dc821ff2333 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -523,6 +523,7 @@ typedef struct drm_i915_irq_wait {
#define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
#define I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
#define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define I915_SCHEDULER_CAP_TIMESLICES(1ul << 5)
#define I915_PARAM_HUC_STATUS 42
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] lib/i915: Don't confuse param.size
On 2020-02-14 19:40:15, Chris Wilson wrote:
> If the context has no engines, it has no engines -- do not override the
> user's setup.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Dale B Stimson
> ---
> lib/i915/gem_engine_topology.c | 19 +++
> 1 file changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
> index 9daa03df4..ca1c1fdb9 100644
> --- a/lib/i915/gem_engine_topology.c
> +++ b/lib/i915/gem_engine_topology.c
> @@ -195,17 +195,6 @@ static int gem_topology_get_param(int fd,
> if (__gem_context_get_param(fd, p))
> return -1; /* using default engine map */
>
> - if (!p->size)
> - return 0;
> -
> - /* size will store the engine count */
> - p->size = (p->size - sizeof(struct i915_context_param_engines)) /
> - (offsetof(struct i915_context_param_engines,
> - engines[1]) -
> - sizeof(struct i915_context_param_engines));
> -
> - igt_assert_f(p->size <= GEM_MAX_ENGINES, "unsupported engine count\n");
> -
> return 0;
> }
>
> @@ -242,7 +231,13 @@ struct intel_engine_data intel_init_engine_list(int fd,
> uint32_t ctx_id)
> query_engine_list(fd, _data);
> ctx_map_engines(fd, _data, );
> } else {
> - /* param.size contains the engine count */
> + /* engine count can be inferred from size */
> + param.size -= sizeof(struct i915_context_param_engines);
> + param.size /= sizeof(struct i915_engine_class_instance);
> +
> + igt_assert_f(param.size <= GEM_MAX_ENGINES,
> + "unsupported engine count\n");
> +
> for (i = 0; i < param.size; i++)
> init_engine(_data.engines[i],
> engines.engines[i].engine_class,
> --
> 2.25.0
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
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/gt: Expand bad CS completion event debug
== Series Details ==
Series: drm/i915/gt: Expand bad CS completion event debug
URL : https://patchwork.freedesktop.org/series/73335/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7924_full -> Patchwork_16532_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_16532_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16532_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_16532_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock_timelines:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb3/igt@i915_selftest@mock_timelines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-iclb8/igt@i915_selftest@mock_timelines.html
- shard-skl: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl7/igt@i915_selftest@mock_timelines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-skl10/igt@i915_selftest@mock_timelines.html
- shard-tglb: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@i915_selftest@mock_timelines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-tglb8/igt@i915_selftest@mock_timelines.html
* igt@runner@aborted:
- shard-tglb: NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-tglb8/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-skl: [PASS][8] -> [INCOMPLETE][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
Known issues
Here are the changes found in Patchwork_16532_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@rcs0-s3:
- shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) +3
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl6/igt@gem_ctx_isolat...@rcs0-s3.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-kbl4/igt@gem_ctx_isolat...@rcs0-s3.html
* igt@gem_ctx_shared@exec-shared-gtt-bsd2:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276]) +7 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb4/igt@gem_ctx_sha...@exec-shared-gtt-bsd2.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-iclb6/igt@gem_ctx_sha...@exec-shared-gtt-bsd2.html
* igt@gem_ctx_shared@exec-single-timeline-bsd:
- shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#110841])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-iclb2/igt@gem_ctx_sha...@exec-single-timeline-bsd.html
* igt@gem_exec_balancer@hang:
- shard-tglb: [PASS][16] -> [TIMEOUT][17] ([fdo#112271])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb1/igt@gem_exec_balan...@hang.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-tglb3/igt@gem_exec_balan...@hang.html
* igt@gem_exec_capture@capture-bsd:
- shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#112146])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb5/igt@gem_exec_capt...@capture-bsd.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-iclb2/igt@gem_exec_capt...@capture-bsd.html
* igt@gem_exec_parallel@vcs1-fds:
- shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#112080]) +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16532/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- shard-hsw: [PASS][22] -> [INCOMPLETE][23] ([CI#80] / [i915#151]
/ [i915#61])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw2/igt@i915_pm_...@modeset-stress-extra-wait.html
[23]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/psr: Force PSR probe only after full initialization (rev3)
== Series Details == Series: drm/i915/psr: Force PSR probe only after full initialization (rev3) URL : https://patchwork.freedesktop.org/series/73436/ State : failure == Summary == Applying: drm/i915/psr: Force PSR probe only after full initialization error: corrupt patch at line 11 error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915/psr: Force PSR probe only after full initialization 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
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
Quoting Antonio Argenziano (2020-02-14 21:49:16)
>
>
> On 14/02/20 11:40, Chris Wilson wrote:
> > Set up a custom engine map with no engines, and check that the
> > for_each_context_engine() correctly iterates over nothing.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/gem_ctx_engines.c | 28
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
> > index 063140e0f..6a2edd1e0 100644
> > --- a/tests/i915/gem_ctx_engines.c
> > +++ b/tests/i915/gem_ctx_engines.c
> > @@ -549,6 +549,31 @@ static void independent(int i915)
> > gem_context_destroy(i915, param.ctx_id);
> > }
> >
> > +static void libapi(int i915)
> > +{
> > + struct i915_context_param_engines engines = {};
>
> Is there a case for invalid engines as well?
One would have to think what the behaviour should be :)
for_each_context_engine() should iterate over every engine defined,
providing you with (e->class, e->instance, e->pretty_name).
Invalid will still have an entry, maybe with "unknown".
for_each_physical_engine would skip invalid entries that are rejected by
the kernel. It's really just
for_each_context_engine()
for_each_if(gem_has_ring())
and I think I should drop the second loop here and focus on testing that
for_each_context_engine() simply reports back the class:inst we put
into the context.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix selftest_mocs for DGFX (rev2)
== Series Details ==
Series: drm/i915/selftests: Fix selftest_mocs for DGFX (rev2)
URL : https://patchwork.freedesktop.org/series/73387/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16577
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16577/index.html
Known issues
Here are the changes found in Patchwork_16577 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [TIMEOUT][2] ([fdo#112271] / [i915#1084])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16577/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16577/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
Possible fixes
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][5] ([i915#424]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16577/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 45)
--
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7942 -> Patchwork_16577
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16577: 9f9e214b4a7dc0d5e5e49a9f0b1224a21120960d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9f9e214b4a7d drm/i915/selftests: Fix selftest_mocs for DGFX
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16577/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
On 14/02/20 11:40, Chris Wilson wrote:
Set up a custom engine map with no engines, and check that the
for_each_context_engine() correctly iterates over nothing.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_engines.c | 28
1 file changed, 28 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index 063140e0f..6a2edd1e0 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -549,6 +549,31 @@ static void independent(int i915)
gem_context_destroy(i915, param.ctx_id);
}
+static void libapi(int i915)
+{
+ struct i915_context_param_engines engines = {};
Is there a case for invalid engines as well?
Acked-by: Antonio Argenziano
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(),
+ .size = sizeof(engines),
+ };
+ const struct intel_execution_engine2 *e;
+ unsigned int count = 0;
+
+ gem_context_set_param(i915, );
+
+ for_each_context_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ for_each_physical_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
igt_main
{
int i915 = -1;
@@ -584,6 +609,9 @@ igt_main
igt_subtest("independent")
independent(i915);
+ igt_subtest("libapi")
+ libapi(i915);
+
igt_fixture
igt_stop_hang_detector();
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Fix selftest_mocs for DGFX (rev2)
== Series Details ==
Series: drm/i915/selftests: Fix selftest_mocs for DGFX (rev2)
URL : https://patchwork.freedesktop.org/series/73387/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9f9e214b4a7d drm/i915/selftests: Fix selftest_mocs for DGFX
-:19: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#19:
> > The format has changed (been reduced?) for DGFX.
> > drm_i915_mocs_entry.l3cc_value is what is still initialized/used.
-:26: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit e6e2ac07118b ("drm/i915: do not
set MOCS control values on dgfx")'
#26:
> commit e6e2ac07118b15f25683fcbd59ea1be73ec9465d
-:119: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 2 errors, 1 warnings, 0 checks, 64 lines checked
___
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: Init lspcon after HPD in intel_dp_detect()
== Series Details ==
Series: drm/i915: Init lspcon after HPD in intel_dp_detect()
URL : https://patchwork.freedesktop.org/series/73480/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16576
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/index.html
Known issues
Here are the changes found in Patchwork_16576 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [FAIL][1] ([i915#694]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [TIMEOUT][3] ([fdo#112271] / [i915#1084]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_exec_paral...@fds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-byt-n2820/igt@gem_exec_paral...@fds.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][5] ([i915#424]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 41)
--
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing(10): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 fi-skl-lmem fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7942 -> Patchwork_16576
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16576: b2ae75309a73a42403618e73da934af0caf97eec @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b2ae75309a73 drm/i915: Init lspcon after HPD in intel_dp_detect()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16576/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] i915/gem_ctx_engines: Exercise 0 engines[]
On 14/02/20 11:40, Chris Wilson wrote:
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
tests/i915/gem_ctx_engines.c | 45
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, , sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, );
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+execbuf.flags <= I915_EXEC_RING_MASK;
+execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, ), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12.
== Series Details == Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12. URL : https://patchwork.freedesktop.org/series/73332/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7924_full -> Patchwork_16531_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16531_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16531_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_16531_full: ### IGT changes ### Possible regressions * igt@gem_exec_async@concurrent-writes-render: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-tglb2/igt@gem_exec_as...@concurrent-writes-render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-tglb1/igt@gem_exec_as...@concurrent-writes-render.html Known issues Here are the changes found in Patchwork_16531_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb8/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@pi-common-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb3/igt@gem_exec_sched...@pi-common-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb1/igt@gem_exec_sched...@pi-common-bsd.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb6/igt@gem_exec_sched...@preempt-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb2/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_partial_pwrite_pread@writes-after-reads: - shard-hsw: [PASS][9] -> [FAIL][10] ([i915#694]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-hsw7/igt@gem_partial_pwrite_pr...@writes-after-reads.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-hsw1/igt@gem_partial_pwrite_pr...@writes-after-reads.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl1/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-skl7/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb6/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103665]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-kbl1/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-kbl4/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-apl2/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-apl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html * igt@prime_vgem@fence-wait-bsd2: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +15 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7924/shard-iclb2/igt@prime_v...@fence-wait-bsd2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16531/shard-iclb5/igt@prime_v...@fence-wait-bsd2.html
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/csr: use intel_de_*() functions for register access
== Series Details == Series: series starting with [1/2] drm/i915/csr: use intel_de_*() functions for register access URL : https://patchwork.freedesktop.org/series/73473/ State : success == Summary == CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16575 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/index.html Known issues Here are the changes found in Patchwork_16575 that come from known issues: ### IGT changes ### Issues hit * igt@gem_close_race@basic-threads: - fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-n2820/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/fi-byt-n2820/igt@gem_close_r...@basic-threads.html * igt@i915_selftest@live_execlists: - fi-icl-y: [PASS][3] -> [DMESG-FAIL][4] ([fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-icl-y/igt@i915_selftest@live_execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/fi-icl-y/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_gtt: - fi-skl-6600u: [PASS][5] -> [TIMEOUT][6] ([fdo#111732] / [fdo#112271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-skl-6600u/igt@i915_selftest@live_gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/fi-skl-6600u/igt@i915_selftest@live_gtt.html - fi-glk-dsi: [PASS][7] -> [TIMEOUT][8] ([fdo#112271] / [i915#690]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-glk-dsi/igt@i915_selftest@live_gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/fi-glk-dsi/igt@i915_selftest@live_gtt.html Possible fixes * igt@i915_selftest@live_gem_contexts: - fi-cfl-8700k: [INCOMPLETE][9] ([i915#424]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html Warnings * igt@gem_close_race@basic-threads: - fi-byt-j1900: [INCOMPLETE][11] ([i915#45]) -> [TIMEOUT][12] ([fdo#112271] / [i915#1084] / [i915#816]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-byt-j1900/igt@gem_close_r...@basic-threads.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/fi-byt-j1900/igt@gem_close_r...@basic-threads.html [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#111732]: https://bugs.freedesktop.org/show_bug.cgi?id=111732 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084 [i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424 [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45 [i915#690]: https://gitlab.freedesktop.org/drm/intel/issues/690 [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816 Participating hosts (47 -> 43) -- Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650 Missing(8): fi-ilk-m540 fi-ehl-1 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7942 -> Patchwork_16575 CI-20190529: 20190529 CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16575: 728c79fc6b4b6c0ceb4e143a76852993a5983fbc @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 728c79fc6b4b drm/i915/display: use intel_de_*() functions for register access 5367ca72657d drm/i915/csr: use intel_de_*() functions for register access == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16575/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/19] drm/i915: Nuke arguments to eb_pin_engine
>-Original Message-
>From: Intel-gfx On Behalf Of
>Maarten Lankhorst
>Sent: Friday, February 14, 2020 5:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 10/19] drm/i915: Nuke arguments to
>eb_pin_engine
>
>Those arguments are already set as eb.file and eb.args, so kill off
>the extra arguments. This will allow us to move eb_pin_engine() to
>after we reserved all BO's.
"move eb_pin_engine() to"
I think you mean "too"? (as in "move eb_pin_engine also"
Or do you mean "move_eb_pin_engine to , after we"?
Other than that,
Acked-by: Michael J. Ruhl
Mike
>
>Signed-off-by: Maarten Lankhorst
>---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>index a27aa85985bd..d96e7649314c 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>@@ -2393,11 +2393,10 @@ static void eb_unpin_engine(struct
>i915_execbuffer *eb)
> }
>
> static unsigned int
>-eb_select_legacy_ring(struct i915_execbuffer *eb,
>-struct drm_file *file,
>-struct drm_i915_gem_execbuffer2 *args)
>+eb_select_legacy_ring(struct i915_execbuffer *eb)
> {
> struct drm_i915_private *i915 = eb->i915;
>+ struct drm_i915_gem_execbuffer2 *args = eb->args;
> unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
>
> if (user_ring_id != I915_EXEC_BSD &&
>@@ -2412,7 +2411,7 @@ eb_select_legacy_ring(struct i915_execbuffer *eb,
> unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
>
> if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
>- bsd_idx = gen8_dispatch_bsd_engine(i915, file);
>+ bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
> } else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
> bsd_idx <= I915_EXEC_BSD_RING2) {
> bsd_idx >>= I915_EXEC_BSD_SHIFT;
>@@ -2437,18 +2436,16 @@ eb_select_legacy_ring(struct i915_execbuffer
>*eb,
> }
>
> static int
>-eb_pin_engine(struct i915_execbuffer *eb,
>-struct drm_file *file,
>-struct drm_i915_gem_execbuffer2 *args)
>+eb_pin_engine(struct i915_execbuffer *eb)
> {
> struct intel_context *ce;
> unsigned int idx;
> int err;
>
> if (i915_gem_context_user_engines(eb->gem_context))
>- idx = args->flags & I915_EXEC_RING_MASK;
>+ idx = eb->args->flags & I915_EXEC_RING_MASK;
> else
>- idx = eb_select_legacy_ring(eb, file, args);
>+ idx = eb_select_legacy_ring(eb);
>
> ce = i915_gem_context_get_engine(eb->gem_context, idx);
> if (IS_ERR(ce))
>@@ -2681,7 +2678,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
> if (unlikely(err))
> goto err_destroy;
>
>- err = eb_pin_engine(, file, args);
>+ err = eb_pin_engine();
> if (unlikely(err))
> goto err_context;
>
>--
>2.25.0.24.g3f081b084b0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/19] drm/i915: Use ww pinning for intel_context_create_request()
>-Original Message-
>From: Intel-gfx On Behalf Of
>Maarten Lankhorst
>Sent: Friday, February 14, 2020 5:31 AM
>To: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] [PATCH 19/19] drm/i915: Use ww pinning for
>intel_context_create_request()
>
>We want to get rid of intel_context_pin(), convert
>intel_context_create_request() first. :)
>
>Signed-off-by: Maarten Lankhorst
>---
> drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
>b/drivers/gpu/drm/i915/gt/intel_context.c
>index 87f9f9e61916..44868b10be0a 100644
>--- a/drivers/gpu/drm/i915/gt/intel_context.c
>+++ b/drivers/gpu/drm/i915/gt/intel_context.c
>@@ -436,15 +436,25 @@ int intel_context_prepare_remote_request(struct
>intel_context *ce,
>
> struct i915_request *intel_context_create_request(struct intel_context *ce)
> {
>+ struct i915_gem_ww_ctx ww;
> struct i915_request *rq;
> int err;
>
>- err = intel_context_pin(ce);
>- if (unlikely(err))
>- return ERR_PTR(err);
>+ i915_gem_ww_ctx_init(, true);
>+retry:
>+ err = intel_context_pin_ww(ce, );
>+ if (!err) {
>+ rq = i915_request_create(ce);
>+ intel_context_unpin(ce);
>+ } else if (err == -EDEADLK) {
>+ err = i915_gem_ww_ctx_backoff();
>+ if (!err)
>+ goto retry;
>+ } else {
>+ rq = ERR_PTR(err);
>+ }
If you have the pathological path:
err = intel_context_pin_ww(cd, &&))
else if (err == -EDEADLK)
err = i915_gem_ww_ctx_backoff() ; (where err != 0)
It appears that you can get to IS_ERR(rq) with rq being garbage from the
stack.
Do you need to preset rq, or set it on:
if (!err)
goto retry;
else
rq = ERR_PTR(err);
?
Thanks,
Mike
>
>- rq = i915_request_create(ce);
>- intel_context_unpin(ce);
>+ i915_gem_ww_ctx_fini();
>
> if (IS_ERR(rq))
> return rq;
>--
>2.25.0.24.g3f081b084b0
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: split
intel_modeset_driver_remove() to pre/post irq uninstall
URL : https://patchwork.freedesktop.org/series/73469/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7942 -> Patchwork_16574
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/index.html
Known issues
Here are the changes found in Patchwork_16574 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#877])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [INCOMPLETE][3] ([i915#424]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7942/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#424]: https://gitlab.freedesktop.org/drm/intel/issues/424
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (47 -> 39)
--
Additional (4): fi-bsw-kefka fi-blb-e6850 fi-cfl-8109u fi-ilk-650
Missing(12): fi-ilk-m540 fi-bdw-5557u fi-hsw-4200u fi-hsw-peppy
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-lmem fi-bdw-samus fi-byt-n2820
fi-skl-6600u fi-kbl-r
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7942 -> Patchwork_16574
CI-20190529: 20190529
CI_DRM_7942: f4805f5a516d0a107438ff0f236c9f4187434819 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5442: 3f6080996885b997685f08ecb8b416b2dc485290 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16574: 8185da98b0f023ec8d2e2aeea5bf81d1a28af187 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8185da98b0f0 drm/i915: split i915_driver_modeset_remove() to pre/post irq
uninstall
5b99455a74fd drm/i915: split intel_modeset_driver_remove() to pre/post irq
uninstall
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16574/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/4] i915/gem_ctx_engine: Exercise for_each_context_engine() with custom engine[]
Set up a custom engine map with no engines, and check that the
for_each_context_engine() correctly iterates over nothing.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_engines.c | 28
1 file changed, 28 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index 063140e0f..6a2edd1e0 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -549,6 +549,31 @@ static void independent(int i915)
gem_context_destroy(i915, param.ctx_id);
}
+static void libapi(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(),
+ .size = sizeof(engines),
+ };
+ const struct intel_execution_engine2 *e;
+ unsigned int count = 0;
+
+ gem_context_set_param(i915, );
+
+ for_each_context_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ for_each_physical_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
igt_main
{
int i915 = -1;
@@ -584,6 +609,9 @@ igt_main
igt_subtest("independent")
independent(i915);
+ igt_subtest("libapi")
+ libapi(i915);
+
igt_fixture
igt_stop_hang_detector();
}
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/4] lib/i915: Don't confuse param.size
If the context has no engines, it has no engines -- do not override the
user's setup.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index 9daa03df4..ca1c1fdb9 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -195,17 +195,6 @@ static int gem_topology_get_param(int fd,
if (__gem_context_get_param(fd, p))
return -1; /* using default engine map */
- if (!p->size)
- return 0;
-
- /* size will store the engine count */
- p->size = (p->size - sizeof(struct i915_context_param_engines)) /
- (offsetof(struct i915_context_param_engines,
- engines[1]) -
- sizeof(struct i915_context_param_engines));
-
- igt_assert_f(p->size <= GEM_MAX_ENGINES, "unsupported engine count\n");
-
return 0;
}
@@ -242,7 +231,13 @@ struct intel_engine_data intel_init_engine_list(int fd,
uint32_t ctx_id)
query_engine_list(fd, _data);
ctx_map_engines(fd, _data, );
} else {
- /* param.size contains the engine count */
+ /* engine count can be inferred from size */
+ param.size -= sizeof(struct i915_context_param_engines);
+ param.size /= sizeof(struct i915_engine_class_instance);
+
+ igt_assert_f(param.size <= GEM_MAX_ENGINES,
+"unsupported engine count\n");
+
for (i = 0; i < param.size; i++)
init_engine(_data.engines[i],
engines.engines[i].engine_class,
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/4] i915/gem_ctx_engines: Exercise 0 engines[]
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_engines.c | 45
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, , sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, );
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+execbuf.flags <= I915_EXEC_RING_MASK;
+execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, ), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 4/4] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
From: Dale B Stimson
Function intel_get_current_engine() should return NULL (instead of
engine 0) if there are no engines.
Function intel_init_engine_list() should not store potential engine
data in the output structure unless the engine is present.
Function intel_init_engine_list() should arguably not filter the static
engine list with gem_has_ring if fd == -1, so that subtests can still
be individually invoked to show subtest FAIL instead of test notrun.
Symptom: A device open failure in gem_ctx_isolation resulted in
an endless __for_each_physical_engine "per-engine" loop with the
purported last potential engine being processed every time.
Diagnosis: device open (or debugfs open) failed, leaving fd == -1.
Control skipped the rest of the initial igt_fixture block, after
which an attempt was made to iterate through engines using macro
__for_each_physical_engine.
Macro __for_each_physical_engine called intel_init_engine_list()
to initialize the loop control data. Because fd == -1,
intel_init_engine_list() fell back to using __for_each_static_engine().
All of the engines in the static engine list are rejected due to
gem_has_ring returning false (because of fd == -1), leaving 0 engines.
That resulted in loop control data with engine_data.nengines == 0
and the data for the last engine considered stored at index 0.
Still in macro __for_each_physical_engine, intel_get_current_engine()
was called to get the engine to process. It should have returned NULL,
but instead returned the engine entry at index 0, which
had received information describing the last potential engine.
This happened without end.
Signed-off-by: Dale B Stimson
Acked-by: Antonio Argenziano
---
lib/i915/gem_engine_topology.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index ca1c1fdb9..1f530bfa3 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -156,10 +156,10 @@ static void query_engine_list(int fd, struct
intel_engine_data *ed)
struct intel_execution_engine2 *
intel_get_current_engine(struct intel_engine_data *ed)
{
- if (!ed->n)
- ed->current_engine = >engines[0];
- else if (ed->n >= ed->nengines)
+ if (ed->n >= ed->nengines)
ed->current_engine = NULL;
+ else if (!ed->n)
+ ed->current_engine = >engines[0];
return ed->current_engine;
}
@@ -211,18 +211,21 @@ struct intel_engine_data intel_init_engine_list(int fd,
uint32_t ctx_id)
igt_debug("using pre-allocated engine list\n");
__for_each_static_engine(e2) {
- struct intel_execution_engine2 *__e2 =
- _data.engines[engine_data.nengines];
-
- strcpy(__e2->name, e2->name);
- __e2->instance = e2->instance;
- __e2->class = e2->class;
- __e2->flags = e2->flags;
- __e2->is_virtual = false;
-
if (igt_only_list_subtests() ||
- gem_has_ring(fd, e2->flags))
+ (fd < 0) ||
+ gem_has_ring(fd, e2->flags)) {
+ struct intel_execution_engine2 *__e2 =
+ _data.engines[
+ engine_data.nengines];
+
+ strcpy(__e2->name, e2->name);
+ __e2->instance = e2->instance;
+ __e2->class = e2->class;
+ __e2->flags = e2->flags;
+ __e2->is_virtual = false;
+
engine_data.nengines++;
+}
}
return engine_data;
}
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX
On 2/14/20 10:29 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2020-02-14 17:56:58)
On 2/12/20 4:49 PM, Brian Welty wrote:
On 2/12/2020 4:34 PM, Chris Wilson wrote:
Quoting Brian Welty (2020-02-13 00:14:18)
For DGFX devices, the MOCS control value is not initialized or used.
Then why is the table populated?
-Chris
The format has changed (been reduced?) for DGFX.
drm_i915_mocs_entry.l3cc_value is what is still initialized/used.
Probably first needed is the patch that defines the table entries for DGFX.
Ugh, I didn't notice this wasn't applied yet. Let me ask about this.
We do have:
commit e6e2ac07118b15f25683fcbd59ea1be73ec9465d
Author: Lucas De Marchi
Date: Thu Oct 24 12:51:21 2019 -0700
drm/i915: do not set MOCS control values on dgfx
So I see no reason not to add this change to the test side to match
that. Maybe we can add an additional check in the test to validate that
all the control_entries are set to 0 in the table on DGFX?
My expectation was that as we were not setting mocs values, we would not
have defined a table for it. However, the table is combined for mocs and
l3cc. l3cc is still used, right?
yes, l3cc is still used. The diff below looks ok to me to keep the
table-driven approach.
Daniele
My ideal would be that our tables did remain the truth value we could
use directly -- that would require splitting the tables though.
If we did something like
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index de1f83100fb6..2c636257f12c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -12,7 +12,8 @@
#include "selftests/igt_spinner.h"
struct live_mocs {
- struct drm_i915_mocs_table table;
+ struct drm_i915_mocs_table mocs;
+ struct drm_i915_mocs_table l3cc;
struct i915_vma *scratch;
void *vaddr;
};
@@ -68,13 +69,32 @@ static struct i915_vma *create_scratch(struct intel_gt *gt)
return vma;
}
+static bool has_l3cc(struct drm_i915_private *i915)
+{
+ return true;
+}
+
+static bool has_mocs(struct drm_i915_private *i915)
+{
+ return !IS_DGFX(i915);
+}
+
static int live_mocs_init(struct live_mocs *arg, struct intel_gt *gt)
{
+ struct drm_i915_mocs_table table;
int err;
- if (!get_mocs_settings(gt->i915, >table))
+ memset(arg, 0, sizeof(*arg));
+
+ if (!get_mocs_settings(gt->i915, ))
return -EINVAL;
+ if (has_l3cc(gt->i915))
+ arg->l3cc = table;
+
+ if (has_mocs(gt->i915))
+ arg->mocs = table;
+
arg->scratch = create_scratch(gt);
if (IS_ERR(arg->scratch))
return PTR_ERR(arg->scratch);
@@ -223,9 +243,9 @@ static int check_mocs_engine(struct live_mocs *arg,
/* Read the mocs tables back using SRM */
offset = i915_ggtt_offset(vma);
if (!err)
- err = read_mocs_table(rq, >table, );
+ err = read_mocs_table(rq, >mocs, );
if (!err && ce->engine->class == RENDER_CLASS)
- err = read_l3cc_table(rq, >table, );
+ err = read_l3cc_table(rq, >l3cc, );
offset -= i915_ggtt_offset(vma);
GEM_BUG_ON(offset > PAGE_SIZE);
@@ -236,9 +256,9 @@ static int check_mocs_engine(struct live_mocs *arg,
/* Compare the results against the expected tables */
vaddr = arg->vaddr;
if (!err)
- err = check_mocs_table(ce->engine, >table, );
+ err = check_mocs_table(ce->engine, >mocs, );
if (!err && ce->engine->class == RENDER_CLASS)
- err = check_l3cc_table(ce->engine, >table, );
+ err = check_l3cc_table(ce->engine, >l3cc, );
if (err)
return err;
we could retain the table driven approach?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_engines: Exercise 0 engines[]
Setup a context with no engines, and make sure we reject all execution
attempts.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_engines.c | 45
1 file changed, 45 insertions(+)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index cb82f08ef..063140e0f 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -242,6 +242,48 @@ static void idempotent(int i915)
gem_context_destroy(i915, p.ctx_id);
}
+static uint32_t batch_create(int i915)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle = gem_create(i915, 4096);
+
+ gem_write(i915, handle, 0, , sizeof(bbe));
+ return handle;
+}
+
+static void none(int i915)
+{
+ struct i915_context_param_engines engines = {};
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(),
+ .size = sizeof(engines),
+ };
+
+ gem_context_set_param(i915, );
+
+ {
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .rsvd1 = p.ctx_id,
+ };
+
+ for (execbuf.flags = 0;
+execbuf.flags <= I915_EXEC_RING_MASK;
+execbuf.flags++)
+ igt_assert_eq(__gem_execbuf(i915, ), -EINVAL);
+
+ gem_close(i915, obj.handle);
+ }
+
+ gem_context_destroy(i915, p.ctx_id);
+}
+
static void execute_one(int i915)
{
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines , I915_EXEC_RING_MASK + 1);
@@ -527,6 +569,9 @@ igt_main
igt_subtest("idempotent")
idempotent(i915);
+ igt_subtest("none")
+ none(i915);
+
igt_subtest("execute-one")
execute_one(i915);
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
Quoting Chris Wilson (2020-02-14 18:54:43)
> +static void libapi(int i915)
> +{
> + I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0);
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0) = {};
or
struct i915_gem_context_param_engines engines = {};
> + struct drm_i915_gem_context_param p = {
> + .ctx_id = gem_context_create(i915),
> + .param = I915_CONTEXT_PARAM_ENGINES,
> + .value = to_user_pointer(),
> + .size = sizeof(engines),
> + };
> + const struct intel_execution_engine2 *e;
> + unsigned int count = 0;
> +
> + gem_context_set_param(i915, );
> +
> + for_each_context_engine(i915, p.ctx_id, e)
> + count++;
> + igt_assert_eq(count, 0);
Of course this says that this for_each_context_engine() loop doesn't
work anyway.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
+static void libapi(int i915)
+{
+ I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 0);
+ struct drm_i915_gem_context_param p = {
+ .ctx_id = gem_context_create(i915),
+ .param = I915_CONTEXT_PARAM_ENGINES,
+ .value = to_user_pointer(),
+ .size = sizeof(engines),
+ };
+ const struct intel_execution_engine2 *e;
+ unsigned int count = 0;
+
+ gem_context_set_param(i915, );
+
+ for_each_context_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ for_each_physical_engine(i915, p.ctx_id, e)
+ count++;
+ igt_assert_eq(count, 0);
+
+ gem_context_destroy(i915, p.ctx_id);
+}
I leave find a home and correcting the whitespace to the reader.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable preemption and sleeping while using the punit sideband
Cherry trail no this problem? sure? my z8350 ezpad always hang freeze on kernel 5.4/5.5/5.6. when i bought it,Linux kernel has been 5.4. v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there is insufficient evidence to implicate a wider problem atm. Similarly, restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre of users. how to make this patch support Cherry trail? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
Quoting Antonio Argenziano (2020-02-14 18:43:01)
>
>
> On 13/02/20 11:26, Dale B Stimson wrote:
> > Function intel_get_current_engine() should return NULL (instead of
> > engine 0) if there are no engines.
> >
> > Function intel_init_engine_list() should not store potential engine
> > data in the output structure unless the engine is present.
> >
> > Function intel_init_engine_list() should arguably not filter the static
> > engine list with gem_has_ring if fd == -1, so that subtests can still
> > be individually invoked to show subtest FAIL instead of test notrun.
> >
> > Symptom: A device open failure in gem_ctx_isolation resulted in
> > an endless __for_each_physical_engine "per-engine" loop with the
> > purported last potential engine being processed every time.
> >
> > Diagnosis: device open (or debugfs open) failed, leaving fd == -1.
> > Control skipped the rest of the initial igt_fixture block, after
> > which an attempt was made to iterate through engines using macro
> > __for_each_physical_engine.
> >
> > Macro __for_each_physical_engine called intel_init_engine_list()
> > to initialize the loop control data. Because fd == -1,
> > intel_init_engine_list() fell back to using __for_each_static_engine().
> > All of the engines in the static engine list are rejected due to
> > gem_has_ring returning false (because of fd == -1), leaving 0 engines.
> > That resulted in loop control data with engine_data.nengines == 0
> > and the data for the last engine considered stored at index 0.
> >
> > Still in macro __for_each_physical_engine, intel_get_current_engine()
> > was called to get the engine to process. It should have returned NULL,
> > but instead returned the engine entry at index 0, which
> > had received information describing the last potential engine.
> > This happened without end.
> >
> > Signed-off-by: Dale B Stimson
> > ---
> > lib/i915/gem_engine_topology.c | 29 -
> > 1 file changed, 16 insertions(+), 13 deletions(-)
> >
> > diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
> > index 9daa03df4..b8ed49bc9 100644
> > --- a/lib/i915/gem_engine_topology.c
> > +++ b/lib/i915/gem_engine_topology.c
> > @@ -156,10 +156,10 @@ static void query_engine_list(int fd, struct
> > intel_engine_data *ed)
> > struct intel_execution_engine2 *
> > intel_get_current_engine(struct intel_engine_data *ed)
> > {
> > - if (!ed->n)
> > - ed->current_engine = >engines[0];
> > - else if (ed->n >= ed->nengines)
> > + if (ed->n >= ed->nengines)
> > ed->current_engine = NULL;
> > + else if (!ed->n)
> > + ed->current_engine = >engines[0];
> >
> > return ed->current_engine;
> > }
> > @@ -222,18 +222,21 @@ struct intel_engine_data intel_init_engine_list(int
> > fd, uint32_t ctx_id)
> > igt_debug("using pre-allocated engine list\n");
> >
> > __for_each_static_engine(e2) {
> > - struct intel_execution_engine2 *__e2 =
> > - _data.engines[engine_data.nengines];
> > -
> > - strcpy(__e2->name, e2->name);
> > - __e2->instance = e2->instance;
> > - __e2->class = e2->class;
> > - __e2->flags = e2->flags;
> > - __e2->is_virtual = false;
> > -
> > if (igt_only_list_subtests() ||
> > - gem_has_ring(fd, e2->flags))
> > + (fd < 0) ||
>
> Patch LGTM, Chris do you have any issues merging this before someone
> implements some tests for the infrastructure?
It seems like a really trivial one to write a test for. 3 minutes
tops... Just do it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
On 13/02/20 11:26, Dale B Stimson wrote:
Function intel_get_current_engine() should return NULL (instead of
engine 0) if there are no engines.
Function intel_init_engine_list() should not store potential engine
data in the output structure unless the engine is present.
Function intel_init_engine_list() should arguably not filter the static
engine list with gem_has_ring if fd == -1, so that subtests can still
be individually invoked to show subtest FAIL instead of test notrun.
Symptom: A device open failure in gem_ctx_isolation resulted in
an endless __for_each_physical_engine "per-engine" loop with the
purported last potential engine being processed every time.
Diagnosis: device open (or debugfs open) failed, leaving fd == -1.
Control skipped the rest of the initial igt_fixture block, after
which an attempt was made to iterate through engines using macro
__for_each_physical_engine.
Macro __for_each_physical_engine called intel_init_engine_list()
to initialize the loop control data. Because fd == -1,
intel_init_engine_list() fell back to using __for_each_static_engine().
All of the engines in the static engine list are rejected due to
gem_has_ring returning false (because of fd == -1), leaving 0 engines.
That resulted in loop control data with engine_data.nengines == 0
and the data for the last engine considered stored at index 0.
Still in macro __for_each_physical_engine, intel_get_current_engine()
was called to get the engine to process. It should have returned NULL,
but instead returned the engine entry at index 0, which
had received information describing the last potential engine.
This happened without end.
Signed-off-by: Dale B Stimson
---
lib/i915/gem_engine_topology.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/lib/i915/gem_engine_topology.c b/lib/i915/gem_engine_topology.c
index 9daa03df4..b8ed49bc9 100644
--- a/lib/i915/gem_engine_topology.c
+++ b/lib/i915/gem_engine_topology.c
@@ -156,10 +156,10 @@ static void query_engine_list(int fd, struct
intel_engine_data *ed)
struct intel_execution_engine2 *
intel_get_current_engine(struct intel_engine_data *ed)
{
- if (!ed->n)
- ed->current_engine = >engines[0];
- else if (ed->n >= ed->nengines)
+ if (ed->n >= ed->nengines)
ed->current_engine = NULL;
+ else if (!ed->n)
+ ed->current_engine = >engines[0];
return ed->current_engine;
}
@@ -222,18 +222,21 @@ struct intel_engine_data intel_init_engine_list(int fd,
uint32_t ctx_id)
igt_debug("using pre-allocated engine list\n");
__for_each_static_engine(e2) {
- struct intel_execution_engine2 *__e2 =
- _data.engines[engine_data.nengines];
-
- strcpy(__e2->name, e2->name);
- __e2->instance = e2->instance;
- __e2->class = e2->class;
- __e2->flags = e2->flags;
- __e2->is_virtual = false;
-
if (igt_only_list_subtests() ||
- gem_has_ring(fd, e2->flags))
+ (fd < 0) ||
Patch LGTM, Chris do you have any issues merging this before someone
implements some tests for the infrastructure?
Acked-by: Antonio Argenziano
+ gem_has_ring(fd, e2->flags)) {
+ struct intel_execution_engine2 *__e2 =
+ _data.engines[
+ engine_data.nengines];
+
+ strcpy(__e2->name, e2->name);
+ __e2->instance = e2->instance;
+ __e2->class = e2->class;
+ __e2->flags = e2->flags;
+ __e2->is_virtual = false;
+
engine_data.nengines++;
+}
}
return engine_data;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX
Quoting Chris Wilson (2020-02-14 18:29:31)
> +static bool has_l3cc(struct drm_i915_private *i915)
> +{
> + return true;
> +}
> +
> +static bool has_mocs(struct drm_i915_private *i915)
> +{
> + return !IS_DGFX(i915);
> +}
> +
> static int live_mocs_init(struct live_mocs *arg, struct intel_gt *gt)
> {
> + struct drm_i915_mocs_table table;
> int err;
>
> - if (!get_mocs_settings(gt->i915, >table))
> + memset(arg, 0, sizeof(*arg));
> +
> + if (!get_mocs_settings(gt->i915, ))
> return -EINVAL;
On top of that, if we did something like return a mask from
get_mocs_settings() for HAS_L3CC | HAS_MOCS (or put it into table) we
can share the init with the main code and reduce potential drift.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for tests/i915/gem_exec_store: remove hard coded engine limit
== Series Details == Series: tests/i915/gem_exec_store: remove hard coded engine limit URL : https://patchwork.freedesktop.org/series/73466/ State : failure == Summary == Applying: tests/i915/gem_exec_store: remove hard coded engine limit error: sha1 information is lacking or useless (tests/i915/gem_exec_store.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 tests/i915/gem_exec_store: remove hard coded engine limit 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
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX
Quoting Daniele Ceraolo Spurio (2020-02-14 17:56:58)
>
>
> On 2/12/20 4:49 PM, Brian Welty wrote:
> >
> > On 2/12/2020 4:34 PM, Chris Wilson wrote:
> >> Quoting Brian Welty (2020-02-13 00:14:18)
> >>> For DGFX devices, the MOCS control value is not initialized or used.
> >>
> >> Then why is the table populated?
> >> -Chris
> >>
> >
> > The format has changed (been reduced?) for DGFX.
> > drm_i915_mocs_entry.l3cc_value is what is still initialized/used.
> > Probably first needed is the patch that defines the table entries for DGFX.
> > Ugh, I didn't notice this wasn't applied yet. Let me ask about this.
> >
>
> We do have:
>
> commit e6e2ac07118b15f25683fcbd59ea1be73ec9465d
> Author: Lucas De Marchi
> Date: Thu Oct 24 12:51:21 2019 -0700
>
> drm/i915: do not set MOCS control values on dgfx
>
> So I see no reason not to add this change to the test side to match
> that. Maybe we can add an additional check in the test to validate that
> all the control_entries are set to 0 in the table on DGFX?
My expectation was that as we were not setting mocs values, we would not
have defined a table for it. However, the table is combined for mocs and
l3cc. l3cc is still used, right?
My ideal would be that our tables did remain the truth value we could
use directly -- that would require splitting the tables though.
If we did something like
diff --git a/drivers/gpu/drm/i915/gt/selftest_mocs.c
b/drivers/gpu/drm/i915/gt/selftest_mocs.c
index de1f83100fb6..2c636257f12c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_mocs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_mocs.c
@@ -12,7 +12,8 @@
#include "selftests/igt_spinner.h"
struct live_mocs {
- struct drm_i915_mocs_table table;
+ struct drm_i915_mocs_table mocs;
+ struct drm_i915_mocs_table l3cc;
struct i915_vma *scratch;
void *vaddr;
};
@@ -68,13 +69,32 @@ static struct i915_vma *create_scratch(struct intel_gt *gt)
return vma;
}
+static bool has_l3cc(struct drm_i915_private *i915)
+{
+ return true;
+}
+
+static bool has_mocs(struct drm_i915_private *i915)
+{
+ return !IS_DGFX(i915);
+}
+
static int live_mocs_init(struct live_mocs *arg, struct intel_gt *gt)
{
+ struct drm_i915_mocs_table table;
int err;
- if (!get_mocs_settings(gt->i915, >table))
+ memset(arg, 0, sizeof(*arg));
+
+ if (!get_mocs_settings(gt->i915, ))
return -EINVAL;
+ if (has_l3cc(gt->i915))
+ arg->l3cc = table;
+
+ if (has_mocs(gt->i915))
+ arg->mocs = table;
+
arg->scratch = create_scratch(gt);
if (IS_ERR(arg->scratch))
return PTR_ERR(arg->scratch);
@@ -223,9 +243,9 @@ static int check_mocs_engine(struct live_mocs *arg,
/* Read the mocs tables back using SRM */
offset = i915_ggtt_offset(vma);
if (!err)
- err = read_mocs_table(rq, >table, );
+ err = read_mocs_table(rq, >mocs, );
if (!err && ce->engine->class == RENDER_CLASS)
- err = read_l3cc_table(rq, >table, );
+ err = read_l3cc_table(rq, >l3cc, );
offset -= i915_ggtt_offset(vma);
GEM_BUG_ON(offset > PAGE_SIZE);
@@ -236,9 +256,9 @@ static int check_mocs_engine(struct live_mocs *arg,
/* Compare the results against the expected tables */
vaddr = arg->vaddr;
if (!err)
- err = check_mocs_table(ce->engine, >table, );
+ err = check_mocs_table(ce->engine, >mocs, );
if (!err && ce->engine->class == RENDER_CLASS)
- err = check_l3cc_table(ce->engine, >table, );
+ err = check_l3cc_table(ce->engine, >l3cc, );
if (err)
return err;
we could retain the table driven approach?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/psr: Force PSR probe only after full initialization
Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR") was forcing the state compute too earlier
causing errors because not everything was initialized, so here
moving to i915_driver_register() when everything is ready and driver
is registering into the rest of the system.
Also fixing the place where it disarm the force probe as during the
atomic check phase errors could happen like the ones due locking and
it would cause PSR to never be enabled if that happens.
Leaving the disarm to the atomic commit phase, intel_psr_enable() or
intel_psr_update() will be called even if the current state do not
allow PSR to be enabled.
v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
Fixes: 60c6a14b489b ("drm/i915/display: Force the state compute phase once to
enable PSR")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
Reported-by: Ross Zwisler
Cc: Gwan-gyeong Mun
Cc: Jani Nikula
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 18 --
drivers/gpu/drm/i915/display/intel_psr.h | 1 +
drivers/gpu/drm/i915/i915_drv.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 2 +-
4 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b4942b6445ae..35bafd281deb 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -936,6 +936,8 @@ void intel_psr_enable(struct intel_dp *intel_dp,
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ intel_psr_force_mode_changed_set(intel_dp, false);
+
if (!crtc_state->has_psr)
return;
@@ -1096,6 +1098,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
struct i915_psr *psr = _priv->psr;
bool enable, psr2_enable;
+ intel_psr_force_mode_changed_set(intel_dp, false);
+
if (!CAN_PSR(dev_priv) || READ_ONCE(psr->dp) != intel_dp)
return;
@@ -1629,7 +1633,7 @@ void intel_psr_atomic_check(struct drm_connector
*connector,
struct drm_crtc_state *crtc_state;
if (!CAN_PSR(dev_priv) || !new_state->crtc ||
- dev_priv->psr.initially_probed)
+ !dev_priv->psr.force_mode_changed)
return;
intel_connector = to_intel_connector(connector);
@@ -1640,5 +1644,15 @@ void intel_psr_atomic_check(struct drm_connector
*connector,
crtc_state = drm_atomic_get_new_crtc_state(new_state->state,
new_state->crtc);
crtc_state->mode_changed = true;
- dev_priv->psr.initially_probed = true;
+}
+
+void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp, bool set)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+
+ if (!CAN_PSR(dev_priv) || !intel_dp || !intel_dp_is_edp(intel_dp) ||
+ intel_dp != dev_priv->psr.dp)
+ return;
+
+ dev_priv->psr.force_mode_changed = set;
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.h
b/drivers/gpu/drm/i915/display/intel_psr.h
index c58a1d438808..27a70468e2b9 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.h
+++ b/drivers/gpu/drm/i915/display/intel_psr.h
@@ -40,5 +40,6 @@ bool intel_psr_enabled(struct intel_dp *intel_dp);
void intel_psr_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
struct drm_connector_state *new_state);
+void intel_psr_force_mode_changed_set(struct intel_dp *intel_dp, bool set);
#endif /* __INTEL_PSR_H__ */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72826e36b165..31fbd034ff82 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -56,6 +56,7 @@
#include "display/intel_hotplug.h"
#include "display/intel_overlay.h"
#include "display/intel_pipe_crc.h"
+#include "display/intel_psr.h"
#include "display/intel_sprite.h"
#include "display/intel_vga.h"
@@ -1348,6 +1349,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_audio_init(dev_priv);
+ intel_psr_force_mode_changed_set(dev_priv->psr.dp, true);
+
/*
* Some ports require correctly set-up hpd registers for detection to
* work properly (leading to ghost connected connector status), e.g. VGA
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index da509d9b8895..773f35015174 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -505,7 +505,7 @@ struct i915_psr {
bool dc3co_enabled;
u32 dc3co_exit_delay;
struct delayed_work dc3co_work;
- bool initially_probed;
+ bool force_mode_changed;
};
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
--
2.25.0
___
Intel-gfx mailing list
[Intel-gfx] [PATCH v4] drm/i915: Init lspcon after HPD in intel_dp_detect()
On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
becomes useless and never responds to cable hotplugging:
[3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
Seems like the lspcon chip on the system in question only gets powered
after the cable is plugged.
So let's call lspcon_init() dynamically to properly initialize the
lspcon chip and make HDMI port work.
Signed-off-by: Kai-Heng Feng
---
v4:
- Trust VBT in intel_infoframe_init().
- Init lspcon in intel_dp_detect().
v3:
- Make sure it's handled under long HPD case.
v2:
- Move lspcon_init() inside of intel_dp_hpd_pulse().
drivers/gpu/drm/i915/display/intel_ddi.c | 17 +
drivers/gpu/drm/i915/display/intel_dp.c | 13 -
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
3 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 33f1dc3d7c1a..ca717434b406 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4741,7 +4741,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
_priv->vbt.ddi_port_info[port];
struct intel_digital_port *intel_dig_port;
struct intel_encoder *encoder;
- bool init_hdmi, init_dp, init_lspcon = false;
+ bool init_hdmi, init_dp;
enum phy phy = intel_port_to_phy(dev_priv, port);
init_hdmi = port_info->supports_dvi || port_info->supports_hdmi;
@@ -4754,7 +4754,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
* is initialized before lspcon.
*/
init_dp = true;
- init_lspcon = true;
init_hdmi = false;
DRM_DEBUG_KMS("VBT says port %c has lspcon\n", port_name(port));
}
@@ -4833,20 +4832,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
goto err;
}
- if (init_lspcon) {
- if (lspcon_init(intel_dig_port))
- /* TODO: handle hdmi info frame part */
- DRM_DEBUG_KMS("LSPCON init success on port %c\n",
- port_name(port));
- else
- /*
-* LSPCON init faied, but DP init was success, so
-* lets try to drive as DP++ port.
-*/
- DRM_ERROR("LSPCON init failed on port %c\n",
- port_name(port));
- }
-
intel_infoframe_init(intel_dig_port);
return;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index c7424e2a04a3..43117aa86292 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5663,8 +5663,19 @@ intel_dp_detect(struct drm_connector *connector,
/* Can't disconnect eDP */
if (intel_dp_is_edp(intel_dp))
status = edp_detect(intel_dp);
- else if (intel_digital_port_connected(encoder))
+ else if (intel_digital_port_connected(encoder)) {
+ if (intel_bios_is_lspcon_present(dev_priv, dig_port->base.port)
&&
+ !dig_port->lspcon.active) {
+ if (lspcon_init(dig_port))
+ DRM_DEBUG_KMS("LSPCON init success on port
%c\n",
+ port_name(dig_port->base.port));
+ else
+ DRM_DEBUG_KMS("LSPCON init failed on port %c\n",
+ port_name(dig_port->base.port));
+ }
+
status = intel_dp_detect_dpcd(intel_dp);
+ }
else
status = connector_status_disconnected;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 93ac0f296852..27a5aa8cefc9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3100,7 +3100,7 @@ void intel_infoframe_init(struct intel_digital_port
*intel_dig_port)
intel_dig_port->set_infoframes = g4x_set_infoframes;
intel_dig_port->infoframes_enabled = g4x_infoframes_enabled;
} else if (HAS_DDI(dev_priv)) {
- if (intel_dig_port->lspcon.active) {
+ if (intel_bios_is_lspcon_present(dev_priv,
intel_dig_port->base.port)) {
intel_dig_port->write_infoframe =
lspcon_write_infoframe;
intel_dig_port->read_infoframe = lspcon_read_infoframe;
intel_dig_port->set_infoframes = lspcon_set_infoframes;
--
2.17.1
___
Intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix selftest_mocs for DGFX
On 2/12/20 4:49 PM, Brian Welty wrote: On 2/12/2020 4:34 PM, Chris Wilson wrote: Quoting Brian Welty (2020-02-13 00:14:18) For DGFX devices, the MOCS control value is not initialized or used. Then why is the table populated? -Chris The format has changed (been reduced?) for DGFX. drm_i915_mocs_entry.l3cc_value is what is still initialized/used. Probably first needed is the patch that defines the table entries for DGFX. Ugh, I didn't notice this wasn't applied yet. Let me ask about this. We do have: commit e6e2ac07118b15f25683fcbd59ea1be73ec9465d Author: Lucas De Marchi Date: Thu Oct 24 12:51:21 2019 -0700 drm/i915: do not set MOCS control values on dgfx So I see no reason not to add this change to the test side to match that. Maybe we can add an additional check in the test to validate that all the control_entries are set to 0 in the table on DGFX? Daniele -Brian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use engine wa list for Wa_1607090982
On Wed, Feb 12, 2020 at 06:57:07PM +0200, Mika Kuoppala wrote:
> This is in mcr range of register, thus we can only verify
> it through mmio. Use engine wa list with mcr range verification
> skip.
>
> Fixes: 0db1a5f8706a ("drm/i915: Implement Wa_1607090982")
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
The headline of this patch is out of sync with the actual workaround
number being used in the code below and in the bspec (same as the patch
that this Fixes). The bspec name for this is Wa_1606931601.
It wasn't originally obvious since the workaround numbers don't match,
but Anusha already has a patch in flight for this workaround here:
https://patchwork.freedesktop.org/series/72433/#rev5
The main difference is that it looks like your patch is adding the
workaround to the "A0 only" section of the engine workarounds function,
whereas Anusha's is adding it for all steppings, which I think is what
the bspec calls for. Do you have additional information that this
should be A0-specific, or was that just an oversight?
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 62b43f538a56..ba86511f1ef9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -598,9 +598,6 @@ static void tgl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val,
> IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 :
> FF_MODE2_TDS_TIMER_MASK);
> -
> - /* Wa_1606931601:tgl */
> - WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
> }
>
> static void
> @@ -1360,6 +1357,11 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> wa_write_or(wal,
> GEN7_FF_THREAD_MODE,
> GEN12_FF_TESSELATION_DOP_GATE_DISABLE);
> +
> + /* Wa_1606931601:tgl */
> + wa_masked_en(wal,
> + GEN7_ROW_CHICKEN2,
> + GEN12_DISABLE_EARLY_READ);
> }
>
> if (IS_GEN(i915, 11)) {
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
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/tgl: Implement Wa_1606931601 (rev5)
== Series Details == Series: drm/i915/tgl: Implement Wa_1606931601 (rev5) URL : https://patchwork.freedesktop.org/series/72433/ State : success == Summary == CI Bug Log - changes from CI_DRM_7922_full -> Patchwork_16530_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16530_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@gem_exec_balan...@smoke.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb6/igt@gem_exec_balan...@smoke.html * igt@gem_exec_schedule@pi-distinct-iova-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb6/igt@gem_exec_sched...@pi-distinct-iova-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@gem_exec_sched...@pi-distinct-iova-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb6/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gen7_exec_parse@basic-offset: - shard-hsw: [PASS][7] -> [FAIL][8] ([i915#694]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw2/igt@gen7_exec_pa...@basic-offset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw2/igt@gen7_exec_pa...@basic-offset.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#79]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk1/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl7/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-kbl1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@flip-vs-wf_vblank-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#34]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl5/igt@kms_flip@flip-vs-wf_vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl5/igt@kms_flip@flip-vs-wf_vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#49]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-pwrite.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-indfb-draw-pwrite.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [24]:
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add Wa_1808121037 to tgl.
On Fri, Feb 14, 2020 at 09:10:38AM -0800, Matt Roper wrote: > On Wed, Feb 12, 2020 at 11:17:28AM -0800, Rafael Antognolli wrote: > > It's not clear whether this workaround is final yet, but the BSpec > > indicates that userspace needs to set bit 9 of this register on demand: > > > >"To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer > >Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA" > > > > BugLink: https://gitlab.freedesktop.org/mesa/mesa/issues/2501 > > Signed-off-by: Rafael Antognolli > > Seems like the right register to whitelist to allow userspace to apply > the workaround. > > Reviewed-by: Matt Roper > > I think we can drop the "Allow userpace to implement this workaround" > part of the comment; that part is self-explanatory given that it's a > whitelist entry. Do you mind if we just tweak the comment while > applying? It looks like the CI shards queue is massive right now so > it's already going to take a long time to get the full results back for > this patch; no need to make it even longer by resubmitting for a trivial > comment shortening. I don't mind it at all, feel free to change it however you want. Thanks! Rafael > > Matt > > > --- > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > > index 62b43f538a56..57b9685d9347 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > > @@ -1264,6 +1264,12 @@ static void tgl_whitelist_build(struct > > intel_engine_cs *engine) > > whitelist_reg_ext(w, PS_INVOCATION_COUNT, > > RING_FORCE_TO_NONPRIV_ACCESS_RD | > > RING_FORCE_TO_NONPRIV_RANGE_4); > > + > > + /* Wa_1808121037:tgl > > +* > > +* Allow userpace to implement this workaround. > > +*/ > > + whitelist_reg(w, GEN7_COMMON_SLICE_CHICKEN1); > > break; > > default: > > break; > > -- > > 2.25.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Matt Roper > Graphics Software Engineer > VTT-OSGC Platform Enablement > Intel Corporation > (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Wa_1607090982"
On Wed, Feb 12, 2020 at 09:06:11AM +, Chris Wilson wrote: > BIT(14) is not sticking in 0xe4f4 so we have no idea if the w/a is still > in effect when it needs to be. Until that is resolved, remove the > failing bit. The headline for the patch you're reverting was somewhat confusing since it doesn't match the name used in the code comment below or the bspec workaround page (Wa_1606931601). But it looks like both numbers refer to the same workaround in the underlying database, so it's the correct revert. Maybe also add a reference to the preferred Wa_1606931601 name in your commit message so that it's easier to find when searching git history? That might help prevent someone from accidentally re-implementing this workaround the next time we scrub the WA database. Matt > > Closes: https://gitlab.freedesktop.org/drm/intel/issues/1169 > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 62b43f538a56..4bbea781c142 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -598,9 +598,6 @@ static void tgl_ctx_workarounds_init(struct > intel_engine_cs *engine, > wa_add(wal, FF_MODE2, FF_MODE2_TDS_TIMER_MASK, val, > IS_TGL_REVID(engine->i915, TGL_REVID_A0, TGL_REVID_A0) ? 0 : > FF_MODE2_TDS_TIMER_MASK); > - > - /* Wa_1606931601:tgl */ > - WA_SET_BIT_MASKED(GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ); > } > > static void > -- > 2.25.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Add Wa_1808121037 to tgl.
On Wed, Feb 12, 2020 at 11:17:28AM -0800, Rafael Antognolli wrote: > It's not clear whether this workaround is final yet, but the BSpec > indicates that userspace needs to set bit 9 of this register on demand: > >"To avoid sporadic corruptions “Set 0x7010[9] when Depth Buffer >Surface Format is D16_UNORM , surface type is not NULL & 1X_MSAA" > > BugLink: https://gitlab.freedesktop.org/mesa/mesa/issues/2501 > Signed-off-by: Rafael Antognolli Seems like the right register to whitelist to allow userspace to apply the workaround. Reviewed-by: Matt Roper I think we can drop the "Allow userpace to implement this workaround" part of the comment; that part is self-explanatory given that it's a whitelist entry. Do you mind if we just tweak the comment while applying? It looks like the CI shards queue is massive right now so it's already going to take a long time to get the full results back for this patch; no need to make it even longer by resubmitting for a trivial comment shortening. Matt > --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 62b43f538a56..57b9685d9347 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -1264,6 +1264,12 @@ static void tgl_whitelist_build(struct intel_engine_cs > *engine) > whitelist_reg_ext(w, PS_INVOCATION_COUNT, > RING_FORCE_TO_NONPRIV_ACCESS_RD | > RING_FORCE_TO_NONPRIV_RANGE_4); > + > + /* Wa_1808121037:tgl > + * > + * Allow userpace to implement this workaround. > + */ > + whitelist_reg(w, GEN7_COMMON_SLICE_CHICKEN1); > break; > default: > break; > -- > 2.25.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/i915: Implement Wa_1607090982"
== Series Details == Series: Revert "drm/i915: Implement Wa_1607090982" URL : https://patchwork.freedesktop.org/series/73324/ State : success == Summary == CI Bug Log - changes from CI_DRM_7922_full -> Patchwork_16529_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_16529_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-shared-gtt-bsd1: - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#616]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl6/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-kbl2/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html * igt@gem_exec_parallel@vcs1-fds: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +16 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb4/igt@gem_exec_paral...@vcs1-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-iclb3/igt@gem_exec_paral...@vcs1-fds.html * igt@gem_exec_schedule@pi-shared-iova-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb7/igt@gem_exec_sched...@pi-shared-iova-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-iclb4/igt@gem_exec_sched...@pi-shared-iova-bsd.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb5/igt@gem_exec_sched...@reorder-wide-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_render_copy_redux@normal: - shard-hsw: [PASS][9] -> [FAIL][10] ([i915#694]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw7/igt@gem_render_copy_re...@normal.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-hsw5/igt@gem_render_copy_re...@normal.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl2/igt@i915_susp...@sysfs-reader.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#300]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-128x42-onscreen: - shard-apl: [PASS][15] -> [FAIL][16] ([i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-128x42-onscreen.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-128x42-onscreen.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#34]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk1/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-glk8/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#79]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl6/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16529/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][25] -> [SKIP][26]
[Intel-gfx] ✓ Fi.CI.BAT: success for Adding definitions for VRR registers and bitfields (rev2)
== Series Details == Series: Adding definitions for VRR registers and bitfields (rev2) URL : https://patchwork.freedesktop.org/series/73398/ State : success == Summary == CI Bug Log - changes from CI_DRM_7939 -> Patchwork_16572 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16572/index.html Known issues Here are the changes found in Patchwork_16572 that come from known issues: ### IGT changes ### Issues hit * igt@gem_close_race@basic-threads: - fi-byt-n2820: [PASS][1] -> [INCOMPLETE][2] ([i915#45]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-n2820/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16572/fi-byt-n2820/igt@gem_close_r...@basic-threads.html Possible fixes * igt@i915_selftest@live_execlists: - fi-icl-y: [DMESG-FAIL][3] ([fdo#108569]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-icl-y/igt@i915_selftest@live_execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16572/fi-icl-y/igt@i915_selftest@live_execlists.html Warnings * igt@gem_close_race@basic-threads: - fi-byt-j1900: [INCOMPLETE][5] ([i915#45]) -> [TIMEOUT][6] ([fdo#112271] / [i915#1084] / [i915#816]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-j1900/igt@gem_close_r...@basic-threads.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16572/fi-byt-j1900/igt@gem_close_r...@basic-threads.html * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [FAIL][7] ([i915#579]) -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16572/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271 [i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084 [i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816 Participating hosts (44 -> 45) -- Additional (7): fi-hsw-peppy fi-glk-dsi fi-ivb-3770 fi-icl-u3 fi-bsw-kefka fi-skl-6600u fi-kbl-r Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7939 -> Patchwork_16572 CI-20190529: 20190529 CI_DRM_7939: cceb0c30a34af6ca96e35211ecdc5ca198d44e7e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5441: 534ca091fe4ffed916752165bc5becd7ff56cd84 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16572: b9a4767fb86a5f2e7c8d0f773961a3cfb3d0ce67 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b9a4767fb86a drm/i915/tgl: Add definitions for VRR registers and bits == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16572/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12.
On Thu, 2020-02-13 at 14:37 -0800, Matt Roper wrote:
> On Tue, Feb 11, 2020 at 10:11:42AM -0800, Caz Yokoyama wrote:
> > From: "Yokoyama, Caz"
> >
> > MAD_INTER_CHANNEL_0_0_0_MCHBAR:
> > code nameoffset DRAM_DDR_TYPE
> > SKL 0x5000 1:0 DDR4/DDR3/LPDDR3
> > TGL 0x6048/0x6248/0xd800 2:0
> > DDR4/DDR3/LPDDR3/LPDDR4
> > ICL 0x5000/0x6048/0x48 2:0
> > DDR4/DDR3/LPDDR3/LPDDR4
> > EHL 0x5000/0x60482:0
> > DDR4/DDR3/LPDDR3/LPDDR4
> > CNL 0x5000 2:0
> > DDR4/DDR3/LPDDR3/LPDDR4
> >
> > MAD_DIMM_CH0/1_0_0_0_MCHBAR:
> > code name offset CH0/1
> > SKL0x500c/0x5010
> > TGL0x6054/0x6058
> > EHL0x500c/0x5010
> > ICL0x500c/0x5010
ICL0x500c/0x5010/0x6054/0x6058
as I editted in jira.
> > The bit definition of MAD_DIMM_CH0/1_0_0_0_MCHBAR is same between
> > CNL and TGL.
>
> Have you actually sanity checked the register addresses here on real
> hardware? I see the same offsets in the doc as what you've put here,
I expect CI does, i.e. CI builds the driver with my patch and run tests
for all platform. I only run the test on adls simics.
Are you asking me to run tests on several platform? I have i5-8600K as
a test machine.
> but since this is a different register database than we get most of
> our
> gfx-specific register details from, it would still be good to double
> check that you do indeed get sensible values back when reading from
> these addresses before we merge the patch. Especially since the
> database indicates that some of these registers are present at
> multiple
> offsets.
So you are asking me to read value of the following registers on ICL
for example and find whether they have the same value, correct?
0x5000 and 0x6048
0x500c and 0x6054
0x5010 and 0x6058
>
> >
> > P_CR_MC_BIOS_REQ_0_0_0 is same on BXT and GLK in terms of its
> > address and
> > bit definition.
> > BXT_D_CR_DRP0_DUNIT accesses offset 0x1000, 0x1200, 0x1400, 0x1600.
> > Its register name is RAM_ACCESS_DATA1. There is no difference
> > between
> > BXT and GLK in terms of its address and bit definition.
> >
> > Cc: Ville Syrjälä
> > Cc: Matt Roper
> > Signed-off-by: Yokoyama, Caz
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 15 ---
> > drivers/gpu/drm/i915/i915_reg.h | 6 ++
> > 2 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 516536234e97..b9418583e503 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -806,12 +806,18 @@ skl_dram_get_channels_info(struct
> > drm_i915_private *dev_priv)
> > u32 val;
> > int ret;
> >
> > - val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + val = I915_READ(TGL_MAD_DIMM_CH0_0_0_0_MCHBAR);
> > + else
> > + val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
> > ret = skl_dram_get_channel_info(dev_priv, , 0, val);
> > if (ret == 0)
> > dram_info->num_channels++;
> >
> > - val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + val = I915_READ(TGL_MAD_DIMM_CH1_0_0_0_MCHBAR);
> > + else
> > + val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
> > ret = skl_dram_get_channel_info(dev_priv, , 1, val);
> > if (ret == 0)
> > dram_info->num_channels++;
> > @@ -852,7 +858,10 @@ skl_get_dram_type(struct drm_i915_private
> > *dev_priv)
> > {
> > u32 val;
> >
> > - val = I915_READ(SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN);
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + val = I915_READ(TGL_MAD_INTER_CHANNEL_0_0_0_MCHBAR);
> > + else
> > + val =
> > I915_READ(SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN);
> >
> > switch (val & SKL_DRAM_DDR_TYPE_MASK) {
> > case SKL_DRAM_DDR_TYPE_DDR3:
>
> I'm not sure if it might be cleaner to create regs structures for
> each
> platform to centralize the platform-selection logic and avoid all the
> if/else in the code. E.g.,
>
> struct i915_mchbar_regs {
> i915_reg_t mad_inter_channel;
> i915_reg_t mad_dimm_ch0;
> i915_reg_t mad_dimm_ch1;
> };
>
> static const struct i915_mchbar_regs skl_mchbar_regs = {
> .mad_inter_channel =
> SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN,
> .mad_dimm_ch0 = SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN,
> .mad_dimm_ch1 = SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN,
> };
>
> and then use the appropriate regs structure in each of these
> functions
> so that you can just do
>
> val = I915_READ(regs->mad_inter_channel);
>
> and not have to update a
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Check for the error interrupt before we wait!
== Series Details == Series: drm/i915/selftests: Check for the error interrupt before we wait! URL : https://patchwork.freedesktop.org/series/73461/ State : success == Summary == CI Bug Log - changes from CI_DRM_7939 -> Patchwork_16571 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16571/index.html Known issues Here are the changes found in Patchwork_16571 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_parallel@contexts: - fi-byt-n2820: [PASS][1] -> [FAIL][2] ([i915#694]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-n2820/igt@gem_exec_paral...@contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16571/fi-byt-n2820/igt@gem_exec_paral...@contexts.html Possible fixes * igt@i915_selftest@live_execlists: - fi-icl-y: [DMESG-FAIL][3] ([fdo#108569]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-icl-y/igt@i915_selftest@live_execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16571/fi-icl-y/igt@i915_selftest@live_execlists.html Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [FAIL][5] ([i915#579]) -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16571/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694 Participating hosts (44 -> 40) -- Additional (5): fi-hsw-peppy fi-glk-dsi fi-ivb-3770 fi-bsw-kefka fi-kbl-r Missing(9): fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-byt-squawks fi-kbl-7500u fi-ctg-p8600 fi-byt-clapper fi-bdw-samus fi-snb-2600 Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_7939 -> Patchwork_16571 CI-20190529: 20190529 CI_DRM_7939: cceb0c30a34af6ca96e35211ecdc5ca198d44e7e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5441: 534ca091fe4ffed916752165bc5becd7ff56cd84 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_16571: 6dc22822beec6cf337e7c3968089dd4ec69cc980 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6dc22822beec drm/i915/selftests: Check for the error interrupt before we wait! == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16571/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
On 2020-02-14 12:49 p.m., Jani Nikula wrote: > On Fri, 14 Feb 2020, Chris Wilson wrote: >> Quoting Jani Nikula (2020-02-14 06:36:15) >>> On Thu, 13 Feb 2020, Nathan Chancellor wrote: A recent commit in clang added -Wtautological-compare to -Wall, which is enabled for i915 after -Wtautological-compare is disabled for the rest of the kernel so we see the following warning on x86_64: ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning: result of comparison of constant 576460752303423487 with expression of type 'unsigned int' is always false [-Wtautological-constant-out-of-range-compare] if (unlikely(remain > N_RELOC(ULONG_MAX))) ^ ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely' # define unlikely(x)__builtin_expect(!!(x), 0) ^ 1 warning generated. It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not account for the case where this file is built for 32-bit x86, where ULONG_MAX == UINT_MAX and this check is still relevant. Cast remain to unsigned long, which keeps the generated code the same (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and the warning is silenced so we can catch more potential issues in the future. Link: https://github.com/ClangBuiltLinux/linux/issues/778 Suggested-by: Michel Dänzer Signed-off-by: Nathan Chancellor >>> >>> Works for me as a workaround, >> >> But the whole point was that the compiler could see that it was >> impossible and not emit the code. Doesn't this break that? > > It seems that goal and the warning are fundamentally incompatible. Not really: if (sizeof(remain) >= sizeof(unsigned long) && unlikely(remain > N_RELOC(ULONG_MAX))) return -EINVAL; In contrast to the cast, this doesn't generate any machine code on 64-bit: https://godbolt.org/z/GmUE4S but still generates the same code on 32-bit: https://godbolt.org/z/hAoz8L -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,v3,1/3] drm/i915: Introduce encoder->compute_config_late()
== Series Details ==
Series: series starting with [CI,v3,1/3] drm/i915: Introduce
encoder->compute_config_late()
URL : https://patchwork.freedesktop.org/series/73460/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7939 -> Patchwork_16570
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/index.html
Known issues
Here are the changes found in Patchwork_16570 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_parallel@contexts:
- fi-byt-n2820: [PASS][1] -> [FAIL][2] ([i915#694]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/fi-byt-n2820/igt@gem_exec_paral...@contexts.html
* igt@i915_selftest@live_gem_contexts:
- fi-byt-n2820: [PASS][3] -> [DMESG-FAIL][4] ([i915#1052])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_exec_parallel@contexts:
- {fi-ehl-1}: [INCOMPLETE][5] ([i915#937]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-ehl-1/igt@gem_exec_paral...@contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/fi-ehl-1/igt@gem_exec_paral...@contexts.html
* igt@gem_exec_parallel@fds:
- fi-byt-n2820: [FAIL][7] ([i915#694]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-n2820/igt@gem_exec_paral...@fds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/fi-byt-n2820/igt@gem_exec_paral...@fds.html
* igt@i915_selftest@live_execlists:
- fi-icl-y: [DMESG-FAIL][9] ([fdo#108569]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-icl-y/igt@i915_selftest@live_execlists.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/fi-icl-y/igt@i915_selftest@live_execlists.html
Warnings
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][11] ([i915#579]) -> [SKIP][12] ([fdo#109271])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1052]: https://gitlab.freedesktop.org/drm/intel/issues/1052
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (44 -> 39)
--
Additional (7): fi-hsw-peppy fi-glk-dsi fi-ivb-3770 fi-icl-u3 fi-bsw-kefka
fi-skl-6600u fi-kbl-r
Missing(12): fi-ilk-m540 fi-bdw-5557u fi-bsw-n3050 fi-hsw-4200u
fi-byt-squawks fi-snb-2520m fi-ctg-p8600 fi-skl-lmem fi-blb-e6850
fi-byt-clapper fi-bsw-nick fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7939 -> Patchwork_16570
CI-20190529: 20190529
CI_DRM_7939: cceb0c30a34af6ca96e35211ecdc5ca198d44e7e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5441: 534ca091fe4ffed916752165bc5becd7ff56cd84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16570: 37b9800907360eadba87ee6617b6aa29e9a38195 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
37b980090736 drm/i915/dp: Add all tiled and port sync conns to modeset
03c1e93c1b88 drm/i915/dp: Compute port sync crtc states post compute_config()
8a37e7c4b9de drm/i915: Introduce encoder->compute_config_late()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16570/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020
> -Original Message- > From: Ville Syrjälä > Sent: Friday, February 14, 2020 8:03 PM > To: Shankar, Uma > Cc: Kadiyala, Kishore ; > intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020 > > On Fri, Feb 14, 2020 at 02:27:35PM +, Shankar, Uma wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Friday, February 14, 2020 6:40 PM > > > To: Kadiyala, Kishore > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > > > Subject: Re: [Intel-gfx] [PATCH] Add support for Color encoding > > > YCBCR_BT2020 > > > > > > On Fri, Feb 14, 2020 at 04:23:16PM +0530, Kishore Kadiyala wrote: > > > > Currently the plane property doesn't have support for > > > > YCBCR_BT2020, which enables the corresponding color conversion mode on > plane CSC. > > > > > > > > Signed-off-by: Kishore Kadiyala > > > > Cc: Uma Shankar > > > > --- > > > > drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++-- > > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c > > > > b/drivers/gpu/drm/i915/display/intel_sprite.c > > > > index 7abeefe8dce5..5169a7260d7c 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > > > > @@ -3011,6 +3011,7 @@ skl_universal_plane_create(struct > > > > drm_i915_private > > > *dev_priv, > > > > struct intel_plane *plane; > > > > enum drm_plane_type plane_type; > > > > unsigned int supported_rotations; > > > > + unsigned int supported_csc; > > > > unsigned int possible_crtcs; > > > > const u64 *modifiers; > > > > const u32 *formats; > > > > @@ -3088,9 +3089,13 @@ skl_universal_plane_create(struct > > > > drm_i915_private > > > *dev_priv, > > > >DRM_MODE_ROTATE_0, > > > >supported_rotations); > > > > > > > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | > > > > +BIT(DRM_COLOR_YCBCR_BT709); > > > > + > > > > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > > > > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020); > > > > > > Missing the actual code to enable it on glk and icl+ sdr planes, so this > > > will not > work. > > > > Yeah this need to be handled for Non HDR planes. > > > > > IIRC there was also some kind of hw fail related to some BT.something > conversions. > > > But I can't remember if that was in the RGB->RGB or > > > YUV->RGB logic. > > > > Will try to check this out. What kind of fails Ville, was it not all > > working or artifacts > ? > > IIRC a wrong coefficient was used in one of the hardcoded hw matrices. Should > be > listed on the bspec w/a page. Able to retrieve that, looks like it's for RGB709 to RGB2020 conversion on SDR planes. So recommendation is not to enable this conversion for SDR planes. Thanks Ville. Regards, Uma Shankar > -- > 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.CHECKPATCH: warning for series starting with [CI,v3,1/3] drm/i915: Introduce encoder->compute_config_late()
== Series Details == Series: series starting with [CI,v3,1/3] drm/i915: Introduce encoder->compute_config_late() URL : https://patchwork.freedesktop.org/series/73460/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8a37e7c4b9de drm/i915: Introduce encoder->compute_config_late() -:84: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct intel_encoder *' should also have an identifier name #84: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:144: + int (*compute_config_late)(struct intel_encoder *, -:84: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct intel_crtc_state *' should also have an identifier name #84: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:144: + int (*compute_config_late)(struct intel_encoder *, -:84: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct drm_connector_state *' should also have an identifier name #84: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:144: + int (*compute_config_late)(struct intel_encoder *, total: 0 errors, 3 warnings, 0 checks, 60 lines checked 03c1e93c1b88 drm/i915/dp: Compute port sync crtc states post compute_config() 37b980090736 drm/i915/dp: Add all tiled and port sync conns to modeset -:23: WARNING:BAD_SIGN_OFF: Use a single space after Reviewed-by: #23: Reviewed-by: Ville Syrjälä total: 0 errors, 1 warnings, 0 checks, 245 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020
On Fri, Feb 14, 2020 at 02:27:35PM +, Shankar, Uma wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Friday, February 14, 2020 6:40 PM > > To: Kadiyala, Kishore > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > Subject: Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020 > > > > On Fri, Feb 14, 2020 at 04:23:16PM +0530, Kishore Kadiyala wrote: > > > Currently the plane property doesn't have support for YCBCR_BT2020, > > > which enables the corresponding color conversion mode on plane CSC. > > > > > > Signed-off-by: Kishore Kadiyala > > > Cc: Uma Shankar > > > --- > > > drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++-- > > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c > > > b/drivers/gpu/drm/i915/display/intel_sprite.c > > > index 7abeefe8dce5..5169a7260d7c 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > > > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > > > @@ -3011,6 +3011,7 @@ skl_universal_plane_create(struct drm_i915_private > > *dev_priv, > > > struct intel_plane *plane; > > > enum drm_plane_type plane_type; > > > unsigned int supported_rotations; > > > + unsigned int supported_csc; > > > unsigned int possible_crtcs; > > > const u64 *modifiers; > > > const u32 *formats; > > > @@ -3088,9 +3089,13 @@ skl_universal_plane_create(struct drm_i915_private > > *dev_priv, > > > DRM_MODE_ROTATE_0, > > > supported_rotations); > > > > > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | > > > +BIT(DRM_COLOR_YCBCR_BT709); > > > + > > > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > > > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020); > > > > Missing the actual code to enable it on glk and icl+ sdr planes, so this > > will not work. > > Yeah this need to be handled for Non HDR planes. > > > IIRC there was also some kind of hw fail related to some BT.something > > conversions. > > But I can't remember if that was in the RGB->RGB or > > YUV->RGB logic. > > Will try to check this out. What kind of fails Ville, was it not all working > or artifacts ? IIRC a wrong coefficient was used in one of the hardcoded hw matrices. Should be listed on the bspec w/a page. -- 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 2/2] drm/i915/display: use intel_de_*() functions for register access
On Fri, 14 Feb 2020, Ville Syrjälä wrote:
> On Fri, Feb 14, 2020 at 04:09:10PM +0200, Jani Nikula wrote:
>> The implicit "dev_priv" local variable use has been a long-standing pain
>> point in the register access macros I915_READ(), I915_WRITE(),
>> POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
>>
>> Replace them with the corresponding new display engine register
>> accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
>> intel_de_read_fw(), and intel_de_write_fw().
>>
>> No functional changes.
>>
>> Generated using the following semantic patch:
>>
>> @@
>> expression REG, OFFSET;
>> @@
>> - I915_READ(REG)
>> + intel_de_read(dev_priv, REG)
>>
>> @@
>> expression REG, OFFSET;
>> @@
>> - POSTING_READ(REG)
>> + intel_de_posting_read(dev_priv, REG)
>>
>> @@
>> expression REG, OFFSET;
>> @@
>> - I915_WRITE(REG, OFFSET)
>> + intel_de_write(dev_priv, REG, OFFSET)
>>
>> @@
>> expression REG;
>> @@
>> - I915_READ_FW(REG)
>> + intel_de_read_fw(dev_priv, REG)
>>
>> @@
>> expression REG, OFFSET;
>> @@
>> - I915_WRITE_FW(REG, OFFSET)
>> + intel_de_write_fw(dev_priv, REG, OFFSET)
>>
>> Signed-off-by: Jani Nikula
>> ---
>> .../drm/i915/display/intel_display_debugfs.c | 65 +++
>> 1 file changed, 37 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> index 50baac726e70..287442bbcb46 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> @@ -57,15 +57,15 @@ static int i915_fbc_status(struct seq_file *m, void
>> *unused)
>> u32 mask;
>>
>> if (INTEL_GEN(dev_priv) >= 8)
>> -mask = I915_READ(IVB_FBC_STATUS2) &
>> BDW_FBC_COMP_SEG_MASK;
>> +mask = intel_de_read(dev_priv, IVB_FBC_STATUS2) &
>> BDW_FBC_COMP_SEG_MASK;
>> else if (INTEL_GEN(dev_priv) >= 7)
>> -mask = I915_READ(IVB_FBC_STATUS2) &
>> IVB_FBC_COMP_SEG_MASK;
>> +mask = intel_de_read(dev_priv, IVB_FBC_STATUS2) &
>> IVB_FBC_COMP_SEG_MASK;
>> else if (INTEL_GEN(dev_priv) >= 5)
>> -mask = I915_READ(ILK_DPFC_STATUS) &
>> ILK_DPFC_COMP_SEG_MASK;
>> +mask = intel_de_read(dev_priv, ILK_DPFC_STATUS) &
>> ILK_DPFC_COMP_SEG_MASK;
>> else if (IS_G4X(dev_priv))
>> -mask = I915_READ(DPFC_STATUS) & DPFC_COMP_SEG_MASK;
>> +mask = intel_de_read(dev_priv, DPFC_STATUS) &
>> DPFC_COMP_SEG_MASK;
>> else
>> -mask = I915_READ(FBC_STATUS) & (FBC_STAT_COMPRESSING |
>> +mask = intel_de_read(dev_priv, FBC_STATUS) &
>> (FBC_STAT_COMPRESSING |
>> FBC_STAT_COMPRESSED);
>
> Seesm to want some manual work to fix the alignment afterwards.
> Probably should wrap after & actually.
Hmmh, was too hasty glancing over the cocci generated patch.
>
>>
>> seq_printf(m, "Compressing: %s\n", yesno(mask));
>> @@ -99,12 +99,11 @@ static int i915_fbc_false_color_set(void *data, u64 val)
>>
>> mutex_lock(_priv->fbc.lock);
>>
>> -reg = I915_READ(ILK_DPFC_CONTROL);
>> +reg = intel_de_read(dev_priv, ILK_DPFC_CONTROL);
>> dev_priv->fbc.false_color = val;
>>
>> -I915_WRITE(ILK_DPFC_CONTROL, val ?
>> - (reg | FBC_CTL_FALSE_COLOR) :
>> - (reg & ~FBC_CTL_FALSE_COLOR));
>> +intel_de_write(dev_priv, ILK_DPFC_CONTROL,
>> + val ? (reg | FBC_CTL_FALSE_COLOR) : (reg &
>> ~FBC_CTL_FALSE_COLOR));
>
> Did we introduce some kind of rmw() variant? Could use it here to get
> rid of this rather ugly construct.
I wonder if it would be possible to come up with a magic cocci spell
to convert those.
>
> For the series
> Reviewed-by: Ville Syrjälä
Thanks.
BR,
Jani.
>
>>
>> mutex_unlock(_priv->fbc.lock);
>> return 0;
>> @@ -130,7 +129,7 @@ static int i915_ips_status(struct seq_file *m, void
>> *unused)
>> if (INTEL_GEN(dev_priv) >= 8) {
>> seq_puts(m, "Currently: unknown\n");
>> } else {
>> -if (I915_READ(IPS_CTL) & IPS_ENABLE)
>> +if (intel_de_read(dev_priv, IPS_CTL) & IPS_ENABLE)
>> seq_puts(m, "Currently: enabled\n");
>> else
>> seq_puts(m, "Currently: disabled\n");
>> @@ -152,16 +151,16 @@ static int i915_sr_status(struct seq_file *m, void
>> *unused)
>> if (INTEL_GEN(dev_priv) >= 9)
>> /* no global SR status; inspect per-plane WM */;
>> else if (HAS_PCH_SPLIT(dev_priv))
>> -sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
>> +sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM1_LP_SR_EN;
>> else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) ||
>> IS_I945G(dev_priv) ||
Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, February 14, 2020 6:40 PM
> To: Kadiyala, Kishore
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> Subject: Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020
>
> On Fri, Feb 14, 2020 at 04:23:16PM +0530, Kishore Kadiyala wrote:
> > Currently the plane property doesn't have support for YCBCR_BT2020,
> > which enables the corresponding color conversion mode on plane CSC.
> >
> > Signed-off-by: Kishore Kadiyala
> > Cc: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> > b/drivers/gpu/drm/i915/display/intel_sprite.c
> > index 7abeefe8dce5..5169a7260d7c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> > @@ -3011,6 +3011,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> > struct intel_plane *plane;
> > enum drm_plane_type plane_type;
> > unsigned int supported_rotations;
> > + unsigned int supported_csc;
> > unsigned int possible_crtcs;
> > const u64 *modifiers;
> > const u32 *formats;
> > @@ -3088,9 +3089,13 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> >DRM_MODE_ROTATE_0,
> >supported_rotations);
> >
> > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) |
> > +BIT(DRM_COLOR_YCBCR_BT709);
> > +
> > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
>
> Missing the actual code to enable it on glk and icl+ sdr planes, so this will
> not work.
Yeah this need to be handled for Non HDR planes.
> IIRC there was also some kind of hw fail related to some BT.something
> conversions.
> But I can't remember if that was in the RGB->RGB or
> YUV->RGB logic.
Will try to check this out. What kind of fails Ville, was it not all working or
artifacts ?
> Also clearly commit 27ee72477c9b ("drm/i915/icl: Handle YCbCr to RGB
> conversion
> for BT2020 case") was never actually tested :(
Yeah, this seem to miss the BT2020 export from driver. IGT has the stuff to
test this.
Will work with Kishore to fix this.
Regards,
Uma Shankar
>
> > +
> > drm_plane_create_color_properties(>base,
> > - BIT(DRM_COLOR_YCBCR_BT601) |
> > - BIT(DRM_COLOR_YCBCR_BT709),
> > + supported_csc,
> >
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> > BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> > DRM_COLOR_YCBCR_BT709,
> > --
> > 2.17.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
Re: [Intel-gfx] [PATCH] drm/i915/mst: fix pipe and vblank enable
On Fri, 14 Feb 2020, "Sarvela, Tomi P" wrote: >> From: Jani Nikula >> >> On Mon, 10 Feb 2020, Arkadiusz Hiler wrote: >> > As of the 3 days worth of queued shards: >> > >> > I agree that this is unacceptable, but we can do only so much from the >> > CI/infra side. The time has been creeping up steadily over the last year >> > or so and the machines are not getting any faster. >> >> I am *not* trying to say that it's all your fault and you need to >> provide all results faster for the ever-increasing firehose of incoming >> patches. >> >> I'd like to pose the question, what would all this look like if we made >> it a hard requirement that we need a go/no-go decision on every patch >> series within 24 hours? I emphasize that I don't mean full results in 24 >> hours. Given all the other constraints, how could we provide as much >> useful information as possible within 24 hours to make a decision? >> >> In another thread I said, we've shifted a bit from review being the >> bottle neck to shard runs being the bottle neck. It's still much more >> likely that a patch will change due to review feedback instead of shard >> run results. Half a dozen rounds of review ping pong directly leads to >> half a dozen rounds of mostly unnecessary testing. I would not outright >> dismiss only running full igt on reviewed/acked patches. > > This is actually a good idea. In practice, the shards are swamped by the > amount of builds today, and the throughput has been close to 1/h a long > time, even with work ongoing to prune or tighten stupidest IGT tests. > > We could make the shard run requirements stricter: in addition to passing > BAT it would need some amount of Acks. Patchwork already collects them. Of course, patchwork isn't accurate in picking acks/reviews, but I don't think it has to be. Err on the side of testing, and provide a way to start shard runs manually, also because sometimes you do want the results ASAP on v1. (On that note, would be nice if people could *remove* their patch series from the shard queueu too.) > Another idea has been moving the serialized shard run queue to something > that can handle reordering: trybots can be moved after everything else. This > doesn't affect to the shard queue length though, if we still want to test > everything. Next we'll be figuring out a fair scheduler that does not starve the trybot queue. ;) >> Additionally, there are smaller optimizations to be made (obviously all >> depending on developer bandwidth to implement this stuff), such as >> identifying patches that don't change the resulting binary >> (comment/documentation/whitespace changes), and only running build >> testing on them. > > This idea has been floating around, and would help in 5% changes or so > (which is still noticeable: 1-2 more builds / day tested instead of queued). > > Just need a good diff checker that says "text changes only, skip it". It's probably not as trivial as it initially sounds, but gut feeling says that it's also not a problem that nobody has tried to solve before. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: use intel_de_*() functions for register access
On Fri, Feb 14, 2020 at 04:09:10PM +0200, Jani Nikula wrote:
> The implicit "dev_priv" local variable use has been a long-standing pain
> point in the register access macros I915_READ(), I915_WRITE(),
> POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
>
> Replace them with the corresponding new display engine register
> accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
> intel_de_read_fw(), and intel_de_write_fw().
>
> No functional changes.
>
> Generated using the following semantic patch:
>
> @@
> expression REG, OFFSET;
> @@
> - I915_READ(REG)
> + intel_de_read(dev_priv, REG)
>
> @@
> expression REG, OFFSET;
> @@
> - POSTING_READ(REG)
> + intel_de_posting_read(dev_priv, REG)
>
> @@
> expression REG, OFFSET;
> @@
> - I915_WRITE(REG, OFFSET)
> + intel_de_write(dev_priv, REG, OFFSET)
>
> @@
> expression REG;
> @@
> - I915_READ_FW(REG)
> + intel_de_read_fw(dev_priv, REG)
>
> @@
> expression REG, OFFSET;
> @@
> - I915_WRITE_FW(REG, OFFSET)
> + intel_de_write_fw(dev_priv, REG, OFFSET)
>
> Signed-off-by: Jani Nikula
> ---
> .../drm/i915/display/intel_display_debugfs.c | 65 +++
> 1 file changed, 37 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 50baac726e70..287442bbcb46 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -57,15 +57,15 @@ static int i915_fbc_status(struct seq_file *m, void
> *unused)
> u32 mask;
>
> if (INTEL_GEN(dev_priv) >= 8)
> - mask = I915_READ(IVB_FBC_STATUS2) &
> BDW_FBC_COMP_SEG_MASK;
> + mask = intel_de_read(dev_priv, IVB_FBC_STATUS2) &
> BDW_FBC_COMP_SEG_MASK;
> else if (INTEL_GEN(dev_priv) >= 7)
> - mask = I915_READ(IVB_FBC_STATUS2) &
> IVB_FBC_COMP_SEG_MASK;
> + mask = intel_de_read(dev_priv, IVB_FBC_STATUS2) &
> IVB_FBC_COMP_SEG_MASK;
> else if (INTEL_GEN(dev_priv) >= 5)
> - mask = I915_READ(ILK_DPFC_STATUS) &
> ILK_DPFC_COMP_SEG_MASK;
> + mask = intel_de_read(dev_priv, ILK_DPFC_STATUS) &
> ILK_DPFC_COMP_SEG_MASK;
> else if (IS_G4X(dev_priv))
> - mask = I915_READ(DPFC_STATUS) & DPFC_COMP_SEG_MASK;
> + mask = intel_de_read(dev_priv, DPFC_STATUS) &
> DPFC_COMP_SEG_MASK;
> else
> - mask = I915_READ(FBC_STATUS) & (FBC_STAT_COMPRESSING |
> + mask = intel_de_read(dev_priv, FBC_STATUS) &
> (FBC_STAT_COMPRESSING |
> FBC_STAT_COMPRESSED);
Seesm to want some manual work to fix the alignment afterwards.
Probably should wrap after & actually.
>
> seq_printf(m, "Compressing: %s\n", yesno(mask));
> @@ -99,12 +99,11 @@ static int i915_fbc_false_color_set(void *data, u64 val)
>
> mutex_lock(_priv->fbc.lock);
>
> - reg = I915_READ(ILK_DPFC_CONTROL);
> + reg = intel_de_read(dev_priv, ILK_DPFC_CONTROL);
> dev_priv->fbc.false_color = val;
>
> - I915_WRITE(ILK_DPFC_CONTROL, val ?
> -(reg | FBC_CTL_FALSE_COLOR) :
> -(reg & ~FBC_CTL_FALSE_COLOR));
> + intel_de_write(dev_priv, ILK_DPFC_CONTROL,
> +val ? (reg | FBC_CTL_FALSE_COLOR) : (reg &
> ~FBC_CTL_FALSE_COLOR));
Did we introduce some kind of rmw() variant? Could use it here to get
rid of this rather ugly construct.
For the series
Reviewed-by: Ville Syrjälä
>
> mutex_unlock(_priv->fbc.lock);
> return 0;
> @@ -130,7 +129,7 @@ static int i915_ips_status(struct seq_file *m, void
> *unused)
> if (INTEL_GEN(dev_priv) >= 8) {
> seq_puts(m, "Currently: unknown\n");
> } else {
> - if (I915_READ(IPS_CTL) & IPS_ENABLE)
> + if (intel_de_read(dev_priv, IPS_CTL) & IPS_ENABLE)
> seq_puts(m, "Currently: enabled\n");
> else
> seq_puts(m, "Currently: disabled\n");
> @@ -152,16 +151,16 @@ static int i915_sr_status(struct seq_file *m, void
> *unused)
> if (INTEL_GEN(dev_priv) >= 9)
> /* no global SR status; inspect per-plane WM */;
> else if (HAS_PCH_SPLIT(dev_priv))
> - sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
> + sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM1_LP_SR_EN;
> else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) ||
>IS_I945G(dev_priv) || IS_I945GM(dev_priv))
> - sr_enabled = I915_READ(FW_BLC_SELF) & FW_BLC_SELF_EN;
> + sr_enabled = intel_de_read(dev_priv, FW_BLC_SELF) &
> FW_BLC_SELF_EN;
> else if (IS_I915GM(dev_priv))
> - sr_enabled = I915_READ(INSTPM) & INSTPM_SELF_EN;
> + sr_enabled =
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Adding YUV444 packed format support for skl+ (rev3)
> -Original Message- > From: Intel-gfx On Behalf Of > Patchwork > Sent: Wednesday, January 29, 2020 5:55 AM > To: Paauwe, Bob J > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Adding YUV444 packed > format > support for skl+ (rev3) > > == Series Details == > > Series: drm/i915: Adding YUV444 packed format support for skl+ (rev3) > URL : https://patchwork.freedesktop.org/series/66770/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_7827_full -> Patchwork_16284_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_16284_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_16284_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_16284_full: > > ### IGT changes ### > > Possible regressions Hi Martin/Tomi, I tried to check these failures locally and they seem to work. Looks like there was some regression on these tests intermediately (not sure). They all seem to work on drm-tip with/without the changes. Can we trigger a re-run just to be sure. Wanted to take permission before pressing the button Regards, Uma Shankar > > * igt@kms_plane@pixel-format-pipe-a-planes: > - shard-iclb: [PASS][1] -> [FAIL][2] +14 similar issues >[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > iclb3/igt@kms_pl...@pixel-format-pipe-a-planes.html >[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > iclb2/igt@kms_pl...@pixel-format-pipe-a-planes.html > > * igt@kms_plane@pixel-format-pipe-b-planes: > - shard-skl: [PASS][3] -> [FAIL][4] +11 similar issues >[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > skl4/igt@kms_pl...@pixel-format-pipe-b-planes.html >[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > skl3/igt@kms_pl...@pixel-format-pipe-b-planes.html > - shard-kbl: [PASS][5] -> [FAIL][6] +13 similar issues >[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > kbl2/igt@kms_pl...@pixel-format-pipe-b-planes.html >[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > kbl2/igt@kms_pl...@pixel-format-pipe-b-planes.html > > * igt@kms_plane_scaling@pipe-a-scaler-with-clipping-clamping: > - shard-glk: [PASS][7] -> [FAIL][8] +13 similar issues >[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > glk6/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html >[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > glk8/igt@kms_plane_scal...@pipe-a-scaler-with-clipping-clamping.html > > * igt@kms_plane_scaling@pipe-b-scaler-with-pixel-format: > - shard-apl: [PASS][9] -> [FAIL][10] +13 similar issues >[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > apl1/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html >[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > apl7/igt@kms_plane_scal...@pipe-b-scaler-with-pixel-format.html > > * igt@kms_plane_scaling@pipe-c-scaler-with-rotation: > - shard-skl: NOTRUN -> [FAIL][11] +1 similar issue >[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > skl2/igt@kms_plane_scal...@pipe-c-scaler-with-rotation.html > > * igt@kms_plane_scaling@pipe-d-scaler-with-clipping-clamping: > - shard-tglb: [PASS][12] -> [FAIL][13] +3 similar issues >[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > tglb2/igt@kms_plane_scal...@pipe-d-scaler-with-clipping-clamping.html >[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > tglb4/igt@kms_plane_scal...@pipe-d-scaler-with-clipping-clamping.html > > > Known issues > > > Here are the changes found in Patchwork_16284_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_busy@busy-vcs1: > - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112080]) +14 similar > issues >[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > iclb1/igt@gem_b...@busy-vcs1.html >[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16284/shard- > iclb8/igt@gem_b...@busy-vcs1.html > > * igt@gem_ctx_persistence@vcs1-mixed-process: > - shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109276] / > [fdo#112080]) +4 similar > issues >[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7827/shard- > iclb2/igt@gem_ctx_persiste...@vcs1-mixed-process.html >[17]:
[Intel-gfx] [PATCH 1/2] drm/i915/csr: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_csr.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_csr.c
b/drivers/gpu/drm/i915/display/intel_csr.c
index 6a408e11a3de..57320c12839f 100644
--- a/drivers/gpu/drm/i915/display/intel_csr.c
+++ b/drivers/gpu/drm/i915/display/intel_csr.c
@@ -27,6 +27,7 @@
#include "i915_drv.h"
#include "i915_reg.h"
#include "intel_csr.h"
+#include "intel_de.h"
/**
* DOC: csr support for dmc
@@ -276,11 +277,11 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
mask |= DC_STATE_DEBUG_MASK_CORES;
/* The below bit doesn't need to be cleared ever afterwards */
- val = I915_READ(DC_STATE_DEBUG);
+ val = intel_de_read(dev_priv, DC_STATE_DEBUG);
if ((val & mask) != mask) {
val |= mask;
- I915_WRITE(DC_STATE_DEBUG, val);
- POSTING_READ(DC_STATE_DEBUG);
+ intel_de_write(dev_priv, DC_STATE_DEBUG, val);
+ intel_de_posting_read(dev_priv, DC_STATE_DEBUG);
}
}
@@ -321,8 +322,8 @@ void intel_csr_load_program(struct drm_i915_private
*dev_priv)
preempt_enable();
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
- I915_WRITE(dev_priv->csr.mmioaddr[i],
- dev_priv->csr.mmiodata[i]);
+ intel_de_write(dev_priv, dev_priv->csr.mmioaddr[i],
+ dev_priv->csr.mmiodata[i]);
}
dev_priv->csr.dc_state = 0;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/display: use intel_de_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().
No functional changes.
Generated using the following semantic patch:
@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)
@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)
@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 65 +++
1 file changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 50baac726e70..287442bbcb46 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -57,15 +57,15 @@ static int i915_fbc_status(struct seq_file *m, void *unused)
u32 mask;
if (INTEL_GEN(dev_priv) >= 8)
- mask = I915_READ(IVB_FBC_STATUS2) &
BDW_FBC_COMP_SEG_MASK;
+ mask = intel_de_read(dev_priv, IVB_FBC_STATUS2) &
BDW_FBC_COMP_SEG_MASK;
else if (INTEL_GEN(dev_priv) >= 7)
- mask = I915_READ(IVB_FBC_STATUS2) &
IVB_FBC_COMP_SEG_MASK;
+ mask = intel_de_read(dev_priv, IVB_FBC_STATUS2) &
IVB_FBC_COMP_SEG_MASK;
else if (INTEL_GEN(dev_priv) >= 5)
- mask = I915_READ(ILK_DPFC_STATUS) &
ILK_DPFC_COMP_SEG_MASK;
+ mask = intel_de_read(dev_priv, ILK_DPFC_STATUS) &
ILK_DPFC_COMP_SEG_MASK;
else if (IS_G4X(dev_priv))
- mask = I915_READ(DPFC_STATUS) & DPFC_COMP_SEG_MASK;
+ mask = intel_de_read(dev_priv, DPFC_STATUS) &
DPFC_COMP_SEG_MASK;
else
- mask = I915_READ(FBC_STATUS) & (FBC_STAT_COMPRESSING |
+ mask = intel_de_read(dev_priv, FBC_STATUS) &
(FBC_STAT_COMPRESSING |
FBC_STAT_COMPRESSED);
seq_printf(m, "Compressing: %s\n", yesno(mask));
@@ -99,12 +99,11 @@ static int i915_fbc_false_color_set(void *data, u64 val)
mutex_lock(_priv->fbc.lock);
- reg = I915_READ(ILK_DPFC_CONTROL);
+ reg = intel_de_read(dev_priv, ILK_DPFC_CONTROL);
dev_priv->fbc.false_color = val;
- I915_WRITE(ILK_DPFC_CONTROL, val ?
- (reg | FBC_CTL_FALSE_COLOR) :
- (reg & ~FBC_CTL_FALSE_COLOR));
+ intel_de_write(dev_priv, ILK_DPFC_CONTROL,
+ val ? (reg | FBC_CTL_FALSE_COLOR) : (reg &
~FBC_CTL_FALSE_COLOR));
mutex_unlock(_priv->fbc.lock);
return 0;
@@ -130,7 +129,7 @@ static int i915_ips_status(struct seq_file *m, void *unused)
if (INTEL_GEN(dev_priv) >= 8) {
seq_puts(m, "Currently: unknown\n");
} else {
- if (I915_READ(IPS_CTL) & IPS_ENABLE)
+ if (intel_de_read(dev_priv, IPS_CTL) & IPS_ENABLE)
seq_puts(m, "Currently: enabled\n");
else
seq_puts(m, "Currently: disabled\n");
@@ -152,16 +151,16 @@ static int i915_sr_status(struct seq_file *m, void
*unused)
if (INTEL_GEN(dev_priv) >= 9)
/* no global SR status; inspect per-plane WM */;
else if (HAS_PCH_SPLIT(dev_priv))
- sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
+ sr_enabled = intel_de_read(dev_priv, WM1_LP_ILK) & WM1_LP_SR_EN;
else if (IS_I965GM(dev_priv) || IS_G4X(dev_priv) ||
IS_I945G(dev_priv) || IS_I945GM(dev_priv))
- sr_enabled = I915_READ(FW_BLC_SELF) & FW_BLC_SELF_EN;
+ sr_enabled = intel_de_read(dev_priv, FW_BLC_SELF) &
FW_BLC_SELF_EN;
else if (IS_I915GM(dev_priv))
- sr_enabled = I915_READ(INSTPM) & INSTPM_SELF_EN;
+ sr_enabled = intel_de_read(dev_priv, INSTPM) & INSTPM_SELF_EN;
else if (IS_PINEVIEW(dev_priv))
- sr_enabled = I915_READ(DSPFW3) & PINEVIEW_SELF_REFRESH_EN;
+ sr_enabled = intel_de_read(dev_priv, DSPFW3) &
PINEVIEW_SELF_REFRESH_EN;
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
- sr_enabled = I915_READ(FW_BLC_SELF_VLV) & FW_CSPWRDWNEN;
+ sr_enabled = intel_de_read(dev_priv, FW_BLC_SELF_VLV) &
Re: [Intel-gfx] [PATCH] drm/i915/mst: fix pipe and vblank enable
> From: Jani Nikula > > On Mon, 10 Feb 2020, Arkadiusz Hiler wrote: > > As of the 3 days worth of queued shards: > > > > I agree that this is unacceptable, but we can do only so much from the > > CI/infra side. The time has been creeping up steadily over the last year > > or so and the machines are not getting any faster. > > I am *not* trying to say that it's all your fault and you need to > provide all results faster for the ever-increasing firehose of incoming > patches. > > I'd like to pose the question, what would all this look like if we made > it a hard requirement that we need a go/no-go decision on every patch > series within 24 hours? I emphasize that I don't mean full results in 24 > hours. Given all the other constraints, how could we provide as much > useful information as possible within 24 hours to make a decision? > > In another thread I said, we've shifted a bit from review being the > bottle neck to shard runs being the bottle neck. It's still much more > likely that a patch will change due to review feedback instead of shard > run results. Half a dozen rounds of review ping pong directly leads to > half a dozen rounds of mostly unnecessary testing. I would not outright > dismiss only running full igt on reviewed/acked patches. This is actually a good idea. In practice, the shards are swamped by the amount of builds today, and the throughput has been close to 1/h a long time, even with work ongoing to prune or tighten stupidest IGT tests. We could make the shard run requirements stricter: in addition to passing BAT it would need some amount of Acks. Patchwork already collects them. Another idea has been moving the serialized shard run queue to something that can handle reordering: trybots can be moved after everything else. This doesn't affect to the shard queue length though, if we still want to test everything. > Additionally, there are smaller optimizations to be made (obviously all > depending on developer bandwidth to implement this stuff), such as > identifying patches that don't change the resulting binary > (comment/documentation/whitespace changes), and only running build > testing on them. This idea has been floating around, and would help in 5% changes or so (which is still noticeable: 1-2 more builds / day tested instead of queued). Just need a good diff checker that says "text changes only, skip it". Tomi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
Hi Tvrtko,
> > > > + }
> > > > +
> > > > + intel_gt_sysfs_pm_remove(gt, root);
> > > > + kobject_put(root);
> > >
> > > Maybe stick to the same terminology regarding root and parent.
> >
> > yes.
> >
> > > Get/put on the parent looks unbalanced. Both register and unregister take
> > > a
> > > reference and only unregister releases it. But do you even need a
> > > reference?
> >
> > why? I take it here:
> >
> > static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt)
> > {
> > return kobject_get(>i915->drm.primary->kdev->kobj);
> > }
> >
> > at the beginning (when the driver is loaded) and I release it at
> > the end (when the driver is unloaded). Am I not seeing something?
>
> Gt_to_parent_obj at the top of intel_gt_sysfs_register balances out with the
> put at the end of the same function. What balances out gt_to_parent_obj from
> intel_gt_sysfs_register?
And... you are right!
either nothing or too many :)
> > > I am also tempted by the _once alternative, but then it makes less sense
> > > to
> > > include name & pid.
> >
> > It's true, it can be an unrelenting message, and I thought of it,
> > but if the user is resilient at reading out from the wrong
> > directory, why shouldn't I :)
>
> Because we always try to avoid emitting spammy logs when they can be easily
> triggered by userspace. Can we do rate limit? I think that could work well
> with logging the process name & pid.
yes, if two people suggested the same thing, most probably that's
the right thing to do.
> Also, we need an entry in Documentation/ABI/obsolete/.
I was waiting this patch to get in shape before adding the
interface to obsolete.
I will include it in the next patch.
Thanks a lot for the review,
Andi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall. Move
irq_unintall() closer to the layer it belongs.
The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +---
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/i915_drv.c | 5 +
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e09d3c93c52b..d9c1c952a27d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -18898,6 +18898,7 @@ static void intel_hpd_poll_fini(struct drm_i915_private
*i915)
drm_connector_list_iter_end(_iter);
}
+/* part #1: call before irq uninstall */
void intel_modeset_driver_remove(struct drm_i915_private *i915)
{
flush_workqueue(i915->flip_wq);
@@ -18905,14 +18906,11 @@ void intel_modeset_driver_remove(struct
drm_i915_private *i915)
flush_work(>atomic_helper.free_work);
WARN_ON(!llist_empty(>atomic_helper.free_list));
+}
- /*
-* Interrupts and polling as the first thing to avoid creating havoc.
-* Too much stuff here (turning of connectors, ...) would
-* experience fancy races otherwise.
-*/
- intel_irq_uninstall(i915);
-
+/* part #2: call after irq uninstall */
+void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915)
+{
/*
* Due to the hpd irq storm handling the hotplug work can re-arm the
* poll handlers. Hence disable polling after hpd handling is shut down.
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 75438a136d58..f92efbbec838 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -616,6 +616,7 @@ intel_format_info_is_yuv_semiplanar(const struct
drm_format_info *info,
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init(struct drm_i915_private *i915);
void intel_modeset_driver_remove(struct drm_i915_private *i915);
+void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915);
void intel_display_resume(struct drm_device *dev);
void intel_init_pch_refclk(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 955f52bcd6a2..4636d723d531 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -333,6 +333,9 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
i915_gem_driver_release(i915);
cleanup_modeset:
intel_modeset_driver_remove(i915);
+ intel_irq_uninstall(i915);
+ intel_modeset_driver_remove_noirq(i915);
+ goto cleanup_csr;
cleanup_irq:
intel_irq_uninstall(i915);
cleanup_csr:
@@ -349,6 +352,8 @@ static void i915_driver_modeset_remove(struct
drm_i915_private *i915)
intel_irq_uninstall(i915);
+ intel_modeset_driver_remove_noirq(i915);
+
intel_bios_driver_remove(i915);
intel_vga_unregister(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/2] drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstall
Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4636d723d531..2e567bda79bd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -346,12 +346,15 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
return ret;
}
+/* part #1: call before irq uninstall */
static void i915_driver_modeset_remove(struct drm_i915_private *i915)
{
intel_modeset_driver_remove(i915);
+}
- intel_irq_uninstall(i915);
-
+/* part #2: call after irq uninstall */
+static void i915_driver_modeset_remove_noirq(struct drm_i915_private *i915)
+{
intel_modeset_driver_remove_noirq(i915);
intel_bios_driver_remove(i915);
@@ -1593,6 +1596,10 @@ void i915_driver_remove(struct drm_i915_private *i915)
i915_driver_modeset_remove(i915);
+ intel_irq_uninstall(i915);
+
+ i915_driver_modeset_remove_noirq(i915);
+
i915_reset_error_state(i915);
i915_gem_driver_remove(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
On Fri, Feb 14, 2020 at 08:32:19AM +, Chris Wilson wrote: > Quoting Jani Nikula (2020-02-14 06:36:15) > > On Thu, 13 Feb 2020, Nathan Chancellor wrote: > > > A recent commit in clang added -Wtautological-compare to -Wall, which is > > > enabled for i915 after -Wtautological-compare is disabled for the rest > > > of the kernel so we see the following warning on x86_64: > > > > > > ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning: > > > result of comparison of constant 576460752303423487 with expression of > > > type 'unsigned int' is always false > > > [-Wtautological-constant-out-of-range-compare] > > > if (unlikely(remain > N_RELOC(ULONG_MAX))) > > > ^ > > > ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely' > > > # define unlikely(x)__builtin_expect(!!(x), 0) > > > ^ > > > 1 warning generated. > > > > > > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not > > > account for the case where this file is built for 32-bit x86, where > > > ULONG_MAX == UINT_MAX and this check is still relevant. > > > > > > Cast remain to unsigned long, which keeps the generated code the same > > > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and > > > the warning is silenced so we can catch more potential issues in the > > > future. > > > > > > Link: https://github.com/ClangBuiltLinux/linux/issues/778 > > > Suggested-by: Michel Dänzer > > > Signed-off-by: Nathan Chancellor > > > > Works for me as a workaround, > > But the whole point was that the compiler could see that it was > impossible and not emit the code. Doesn't this break that? > -Chris As noted in the commit message, I ran diff <(objdump -Dr) <(objdump -Dr) on objects files compiled with and without the patch with clang and gcc for x86_64 and gcc for i386 (i386 does not build with clang) and there was zero difference aside from the file names. At the end of the day, I do not really care how the warning get fixed, just that it does since it is the only one on x86_64 defconfig. Cheers, Nathan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
On 14/02/2020 13:18, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-14 12:54:35)
On 14/02/2020 11:03, Andi Shyti wrote:
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev)
+{
+ struct kobject *kobj = >kobj;
+ /*
+ * We are interested at knowing from where the interface
+ * has been called, whether it's called from gt/ or from
+ * the parent directory.
+ * From the interface position it depends also the value of
+ * the private data.
+ * If the interface is called from gt/ then private data is
+ * of the "struct intel_gt *" type, otherwise it's * a
+ * "struct drm_i915_private *" type.
+ */
+ if (strcmp(dev->kobj.name, "gt")) {
+ struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+ drm_warn(>drm, "the interface is obsolete, use gt/\n");
Can you log current->name & pid?
I am also thinking is a level down from warn would be better. Notice
sounds intuitively correct to me.
git grep -e 'pr.*obsolete' | grep warn | wc -l
21
git grep -e 'pr.*obsolete' | grep notice | wc -l
1
git grep -e 'pr.*obsolete' | grep info | wc -l
4
Looks like warn's back on the menu, boys.
Majority is just wrong. :P
I am also tempted by the _once alternative, but then it makes less sense
to include name & pid.
I'm more afraid that there are users out there that frequently poke
these files.
Agreed, I think best option is to go with ratelimited and name & pid
logged. And more verbosity about what has been access and what should be
accessed instead.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
On 14/02/2020 13:16, Andi Shyti wrote:
Hi Tvrtko,
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Can you paste the new and legacy paths in the commit message?
sure!
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 96890dd12b5f..552a27cc0622 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -32,6 +32,7 @@ struct intel_gt {
struct drm_i915_private *i915;
struct intel_uncore *uncore;
struct i915_ggtt *ggtt;
+ struct kobject kobj;
sysfs_root or something like would perhaps be more descriptive?
it's a kobj, but yes, I can call it that.
+static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt)
+{
+ return kobject_get(>i915->drm.primary->kdev->kobj);
It's a bit surprising X_to_Y helper get a reference as well, no?
gt_get_parent_obj perhaps? But where is this released?
sure!
the kobject put is handled down, for all the cases, have I missed
any?
+}
+
+static ssize_t gt_info_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ return snprintf(buff, PAGE_SIZE, "0\n");
+}
+
+static DEVICE_ATTR_RO(gt_info);
+
+static void sysfs_gt_kobj_release(struct kobject *kobj)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj);
+
+ drm_info(>i915->drm, "releasing interface\n");
Debugging remnants.
I wanted to fill this function with a goodbye message :)
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+ struct kobject *kparent = gt_to_parent_obj(gt);
+ int ret;
+
+ ret = kobject_init_and_add(>kobj, _gt_ktype, kparent, "gt");
+ if (ret) {
+ drm_err(>i915->drm, "failed to initialize sysfs file\n");
+ kobject_put(>kobj);
So you want gt->kobj to be embedded struct and you want to then override the
release vfunc so it is not freed, but what is the specific reason you want
it embedded?
it looked to me like the cleanest way.
There is no real "struct device" that is containing the object I
am creating, sot that the set_drvdata() was producing some
unwanted effects. Embedding it in the gt, I can always get
easily to the gt structure containign the kobject.
Got it.
+void intel_gt_sysfs_unregister(struct intel_gt *gt)
+{
+ struct kobject *root = gt_to_parent_obj(gt);
+
+ if (>kobj) {
This is always true.
remannt from a vim replace command :)
+ sysfs_remove_file(>kobj, _attr_gt_info.attr);
+ intel_gt_sysfs_pm_remove(gt, >kobj);
+ kobject_put(>kobj);
I think kobject_put is enough to tear down the whole hierarchy so you could
simplify this.
Uh! forgot that kobject was cleaning up everythign. Thanks!
+ }
+
+ intel_gt_sysfs_pm_remove(gt, root);
+ kobject_put(root);
Maybe stick to the same terminology regarding root and parent.
yes.
Get/put on the parent looks unbalanced. Both register and unregister take a
reference and only unregister releases it. But do you even need a reference?
why? I take it here:
static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt)
{
return kobject_get(>i915->drm.primary->kdev->kobj);
}
at the beginning (when the driver is loaded) and I release it at
the end (when the driver is unloaded). Am I not seeing something?
Gt_to_parent_obj at the top of intel_gt_sysfs_register balances out with
the put at the end of the same function. What balances out
gt_to_parent_obj from intel_gt_sysfs_register?
+struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev)
+{
+ struct kobject *kobj = >kobj;
+ /*
+* We are interested at knowing from where the interface
+* has been called, whether it's called from gt/ or from
+* the parent directory.
+* From the interface position it depends also the value of
+* the private data.
+* If the interface is called from gt/ then private data is
+* of the "struct intel_gt *" type, otherwise it's * a
+* "struct drm_i915_private *" type.
+*/
+ if (strcmp(dev->kobj.name, "gt")) {
+ struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
+
+ drm_warn(>drm, "the interface is obsolete, use gt/\n");
Can you log current->name & pid?
I am also thinking is a level down from warn would be better. Notice sounds
intuitively correct to me.
I swear, I thought hard to come up with a meaningful message, but
that's the best I came up with.
At least we need to mention it is about sysfs, it needs to be helpful
for the userspace developer/user to know what is being access and from
where.
I suggested to google for this. This is what I came up with as an example:
[ 775.385966] batman_adv: [Deprecated]:
Re: [Intel-gfx] [PATCH] tests/i915/gem_exec_store: remove hard coded engine limit
Quoting Matthew Auld (2020-02-14 13:08:26) > Prep for having an arbitrary context engine[], since that can be > whatever we like. > > Signed-off-by: Matthew Auld > Cc: Antonio Argenziano > Cc: Tvrtko Ursulin > Cc: Chris Wilson Arrays allocated, cleared and freed for nengine. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/i915/gem_exec_store: remove hard coded engine limit
On 14/02/2020 13:08, Matthew Auld wrote:
Prep for having an arbitrary context engine[], since that can be
whatever we like.
Signed-off-by: Matthew Auld
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
tests/i915/gem_exec_store.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/tests/i915/gem_exec_store.c b/tests/i915/gem_exec_store.c
index b74c3d84..eb511696 100644
--- a/tests/i915/gem_exec_store.c
+++ b/tests/i915/gem_exec_store.c
@@ -180,25 +180,40 @@ static void store_all(int fd)
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[2];
struct intel_execution_engine2 *engine;
- struct drm_i915_gem_relocation_entry reloc[32];
+ struct drm_i915_gem_relocation_entry *reloc;
struct drm_i915_gem_execbuffer2 execbuf;
- unsigned engines[16], permuted[16];
+ unsigned *engines, *permuted;
uint32_t batch[16];
uint64_t offset;
unsigned nengine;
int value;
int i, j;
+ nengine = 0;
+ __for_each_physical_engine(fd, engine) {
+ if (!gem_class_can_store_dword(fd, engine->class))
+ continue;
+ nengine++;
+ }
+
+ reloc = calloc(2*nengine, sizeof(*reloc));
+ igt_assert(reloc);
+
+ engines = calloc(nengine, sizeof(*engines));
+ igt_assert(engines);
+
+ permuted = calloc(nengine, sizeof(*permuted));
+ igt_assert(permuted);
+
memset(, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer(obj);
execbuf.buffer_count = 2;
if (gen < 6)
execbuf.flags |= I915_EXEC_SECURE;
- memset(reloc, 0, sizeof(reloc));
memset(obj, 0, sizeof(obj));
- obj[0].handle = gem_create(fd, 4096);
- obj[1].handle = gem_create(fd, 4096);
+ obj[0].handle = gem_create(fd, nengine*sizeof(uint32_t));
+ obj[1].handle = gem_create(fd, 2*nengine*sizeof(batch));
obj[1].relocation_count = 1;
offset = sizeof(uint32_t);
@@ -224,8 +239,6 @@ static void store_all(int fd)
if (!gem_class_can_store_dword(fd, engine->class))
continue;
- igt_assert(2*(nengine+1)*sizeof(batch) <= 4096);
-
execbuf.flags &= ~ENGINE_MASK;
execbuf.flags |= engine->flags;
@@ -281,12 +294,16 @@ static void store_all(int fd)
}
gem_close(fd, obj[1].handle);
- gem_read(fd, obj[0].handle, 0, engines, sizeof(engines));
+ gem_read(fd, obj[0].handle, 0, engines, nengine*sizeof(engines[0]));
gem_close(fd, obj[0].handle);
for (i = 0; i < nengine; i++)
igt_assert_eq_u32(engines[i], i);
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+
+ free(permuted);
+ free(engines);
+ free(reloc);
}
static int print_welcome(int fd)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: make a gt sysfs group and move power management files (rev3)
Quoting Patchwork (2020-02-14 13:13:51) > == Series Details == > > Series: drm/i915/gt: make a gt sysfs group and move power management files > (rev3) > URL : https://patchwork.freedesktop.org/series/73190/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_7939 -> Patchwork_16569 > > > Summary > --- > > **SUCCESS** > > No regressions found. > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/index.html Hmm, do we not have the sysfs walker in BAT? Apparently not. This *should* produce a warning :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: make a gt sysfs group and move power management files
Hi Andi,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next v5.6-rc1 next-20200214]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Andi-Shyti/drm-i915-gt-make-a-gt-sysfs-group-and-move-power-management-files/20200214-142110
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-randconfig-h003-20200213 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c: In function
'intel_gt_sysfs_get_drvdata':
>> drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:26:49: error: "/*" within comment
>> [-Werror=comment]
* has been called, whether it's called from gt/* or from
cc1: all warnings being treated as errors
vim +26 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
18
19 struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev)
20 {
21 struct kobject *kobj = >kobj;
22 struct drm_i915_private *i915;
23
24 /*
25 * We are interested at knowing from where the interface
> 26 * has been called, whether it's called from gt/* or from
27 * the parent directory.
28 * From the interface position it depends also the value of
29 * the private data.
30 * If the interface is called from gt/ then private data is
31 * of the "struct intel_gt *" type, otherwise it's * a
32 * "struct drm_i915_private *" type.
33 */
34 if (strcmp(kobj->name, "gt")) {
35 pr_warn("the interface is obsolete, use gt/\n");
36 i915 = kdev_minor_to_i915(dev);
37 return >gt;
38 }
39
40 return dev_get_drvdata(dev);
41 }
42
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Check for the error interrupt before we wait!
On Fri, 14 Feb 2020 at 12:07, Chris Wilson wrote: > > Sometimes the error interrupt can fire even before we have seen the > request go active -- in which case, we end up waiting until the timeout > as the request is already completed. Double check for this case! > > Signed-off-by: Chris Wilson 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] drm/i915/gt: make a gt sysfs group and move power management files
Quoting Tvrtko Ursulin (2020-02-14 12:54:35)
>
> On 14/02/2020 11:03, Andi Shyti wrote:
> > +struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev)
> > +{
> > + struct kobject *kobj = >kobj;
> > + /*
> > + * We are interested at knowing from where the interface
> > + * has been called, whether it's called from gt/ or from
> > + * the parent directory.
> > + * From the interface position it depends also the value of
> > + * the private data.
> > + * If the interface is called from gt/ then private data is
> > + * of the "struct intel_gt *" type, otherwise it's * a
> > + * "struct drm_i915_private *" type.
> > + */
> > + if (strcmp(dev->kobj.name, "gt")) {
> > + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > +
> > + drm_warn(>drm, "the interface is obsolete, use gt/\n");
>
> Can you log current->name & pid?
>
> I am also thinking is a level down from warn would be better. Notice
> sounds intuitively correct to me.
git grep -e 'pr.*obsolete' | grep warn | wc -l
21
git grep -e 'pr.*obsolete' | grep notice | wc -l
1
git grep -e 'pr.*obsolete' | grep info | wc -l
4
Looks like warn's back on the menu, boys.
> I am also tempted by the _once alternative, but then it makes less sense
> to include name & pid.
I'm more afraid that there are users out there that frequently poke
these files.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
Hi Tvrtko,
> > The GT has its own properties and in sysfs they should be grouped
> > in the 'gt/' directory.
> >
> > Create the 'gt/' directory in sysfs and move the power management
> > related files.
>
> Can you paste the new and legacy paths in the commit message?
sure!
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > index 96890dd12b5f..552a27cc0622 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > @@ -32,6 +32,7 @@ struct intel_gt {
> > struct drm_i915_private *i915;
> > struct intel_uncore *uncore;
> > struct i915_ggtt *ggtt;
> > + struct kobject kobj;
>
> sysfs_root or something like would perhaps be more descriptive?
it's a kobj, but yes, I can call it that.
> > +static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt)
> > +{
> > + return kobject_get(>i915->drm.primary->kdev->kobj);
>
> It's a bit surprising X_to_Y helper get a reference as well, no?
> gt_get_parent_obj perhaps? But where is this released?
sure!
the kobject put is handled down, for all the cases, have I missed
any?
> > +}
> > +
> > +static ssize_t gt_info_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buff)
> > +{
> > + return snprintf(buff, PAGE_SIZE, "0\n");
> > +}
> > +
> > +static DEVICE_ATTR_RO(gt_info);
> > +
> > +static void sysfs_gt_kobj_release(struct kobject *kobj)
> > +{
> > + struct intel_gt *gt = kobj_to_gt(kobj);
> > +
> > + drm_info(>i915->drm, "releasing interface\n");
>
> Debugging remnants.
I wanted to fill this function with a goodbye message :)
> > +void intel_gt_sysfs_register(struct intel_gt *gt)
> > +{
> > + struct kobject *kparent = gt_to_parent_obj(gt);
> > + int ret;
> > +
> > + ret = kobject_init_and_add(>kobj, _gt_ktype, kparent, "gt");
> > + if (ret) {
> > + drm_err(>i915->drm, "failed to initialize sysfs file\n");
> > + kobject_put(>kobj);
>
> So you want gt->kobj to be embedded struct and you want to then override the
> release vfunc so it is not freed, but what is the specific reason you want
> it embedded?
it looked to me like the cleanest way.
There is no real "struct device" that is containing the object I
am creating, sot that the set_drvdata() was producing some
unwanted effects. Embedding it in the gt, I can always get
easily to the gt structure containign the kobject.
> > +void intel_gt_sysfs_unregister(struct intel_gt *gt)
> > +{
> > + struct kobject *root = gt_to_parent_obj(gt);
> > +
> > + if (>kobj) {
>
> This is always true.
remannt from a vim replace command :)
> > + sysfs_remove_file(>kobj, _attr_gt_info.attr);
> > + intel_gt_sysfs_pm_remove(gt, >kobj);
> > + kobject_put(>kobj);
>
> I think kobject_put is enough to tear down the whole hierarchy so you could
> simplify this.
Uh! forgot that kobject was cleaning up everythign. Thanks!
> > + }
> > +
> > + intel_gt_sysfs_pm_remove(gt, root);
> > + kobject_put(root);
>
> Maybe stick to the same terminology regarding root and parent.
yes.
> Get/put on the parent looks unbalanced. Both register and unregister take a
> reference and only unregister releases it. But do you even need a reference?
why? I take it here:
static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt)
{
return kobject_get(>i915->drm.primary->kdev->kobj);
}
at the beginning (when the driver is loaded) and I release it at
the end (when the driver is unloaded). Am I not seeing something?
> > +struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev)
> > +{
> > + struct kobject *kobj = >kobj;
> > + /*
> > +* We are interested at knowing from where the interface
> > +* has been called, whether it's called from gt/ or from
> > +* the parent directory.
> > +* From the interface position it depends also the value of
> > +* the private data.
> > +* If the interface is called from gt/ then private data is
> > +* of the "struct intel_gt *" type, otherwise it's * a
> > +* "struct drm_i915_private *" type.
> > +*/
> > + if (strcmp(dev->kobj.name, "gt")) {
> > + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > +
> > + drm_warn(>drm, "the interface is obsolete, use gt/\n");
>
> Can you log current->name & pid?
>
> I am also thinking is a level down from warn would be better. Notice sounds
> intuitively correct to me.
I swear, I thought hard to come up with a meaningful message, but
that's the best I came up with.
> I am also tempted by the _once alternative, but then it makes less sense to
> include name & pid.
It's true, it can be an unrelenting message, and I thought of it,
but if the user is resilient at reading out from the wrong
directory, why shouldn't I :)
Andi
Re: [Intel-gfx] [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
Quoting Andi Shyti (2020-02-14 11:03:08)
> +struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev)
> +{
> + struct kobject *kobj = >kobj;
> + /*
> +* We are interested at knowing from where the interface
> +* has been called, whether it's called from gt/ or from
> +* the parent directory.
> +* From the interface position it depends also the value of
> +* the private data.
> +* If the interface is called from gt/ then private data is
> +* of the "struct intel_gt *" type, otherwise it's * a
> +* "struct drm_i915_private *" type.
> +*/
> + if (strcmp(dev->kobj.name, "gt")) {
> + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> +
> + drm_warn(>drm, "the interface is obsolete, use gt/\n");
> + return >gt;
I guess it's not possible to flesh this out with path? And we do need it
to be warn_once else the user will be flooded.
One final request, can we also put the old entries under
CONFIG_DRM_I915_SYSFS_OBSOLETE_GT (or somesuch)
As far as the naming goes, the compromise isn't horrendous.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: make a gt sysfs group and move power management files (rev3)
== Series Details ==
Series: drm/i915/gt: make a gt sysfs group and move power management files
(rev3)
URL : https://patchwork.freedesktop.org/series/73190/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7939 -> Patchwork_16569
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/index.html
Known issues
Here are the changes found in Patchwork_16569 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][1] -> [DMESG-FAIL][2] ([i915#877])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@gem_exec_parallel@contexts:
- {fi-ehl-1}: [INCOMPLETE][3] ([i915#937]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-ehl-1/igt@gem_exec_paral...@contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/fi-ehl-1/igt@gem_exec_paral...@contexts.html
* igt@i915_selftest@live_execlists:
- fi-icl-y: [DMESG-FAIL][5] ([fdo#108569]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-icl-y/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/fi-icl-y/igt@i915_selftest@live_execlists.html
Warnings
* igt@gem_close_race@basic-threads:
- fi-byt-j1900: [INCOMPLETE][7] ([i915#45]) -> [TIMEOUT][8]
([fdo#112271] / [i915#1084] / [i915#816])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/fi-byt-j1900/igt@gem_close_r...@basic-threads.html
* igt@i915_pm_rpm@basic-rte:
- fi-kbl-guc: [FAIL][9] ([i915#579]) -> [SKIP][10] ([fdo#109271])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7939/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/fi-kbl-guc/igt@i915_pm_...@basic-rte.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1084]: https://gitlab.freedesktop.org/drm/intel/issues/1084
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (44 -> 43)
--
Additional (7): fi-hsw-peppy fi-glk-dsi fi-ivb-3770 fi-icl-u3 fi-bsw-kefka
fi-skl-6600u fi-kbl-r
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-ctg-p8600
fi-byt-n2820 fi-byt-clapper fi-bdw-samus fi-snb-2600
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7939 -> Patchwork_16569
CI-20190529: 20190529
CI_DRM_7939: cceb0c30a34af6ca96e35211ecdc5ca198d44e7e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5441: 534ca091fe4ffed916752165bc5becd7ff56cd84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16569: 2bb6ef6acc00a99d609b52064cf9baa76bb79004 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2bb6ef6acc00 drm/i915/gt: make a gt sysfs group and move power management files
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16569/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020
On Fri, Feb 14, 2020 at 04:23:16PM +0530, Kishore Kadiyala wrote:
> Currently the plane property doesn't have support for YCBCR_BT2020,
> which enables the corresponding color conversion mode on plane CSC.
>
> Signed-off-by: Kishore Kadiyala
> Cc: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
> b/drivers/gpu/drm/i915/display/intel_sprite.c
> index 7abeefe8dce5..5169a7260d7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/display/intel_sprite.c
> @@ -3011,6 +3011,7 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> struct intel_plane *plane;
> enum drm_plane_type plane_type;
> unsigned int supported_rotations;
> + unsigned int supported_csc;
> unsigned int possible_crtcs;
> const u64 *modifiers;
> const u32 *formats;
> @@ -3088,9 +3089,13 @@ skl_universal_plane_create(struct drm_i915_private
> *dev_priv,
> DRM_MODE_ROTATE_0,
> supported_rotations);
>
> + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709);
> +
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020);
Missing the actual code to enable it on glk and icl+ sdr planes, so
this will not work.
IIRC there was also some kind of hw fail related to some BT.something
conversions. But I can't remember if that was in the RGB->RGB or
YUV->RGB logic.
Also clearly commit 27ee72477c9b ("drm/i915/icl: Handle YCbCr to RGB
conversion for BT2020 case") was never actually tested :(
> +
> drm_plane_create_color_properties(>base,
> - BIT(DRM_COLOR_YCBCR_BT601) |
> - BIT(DRM_COLOR_YCBCR_BT709),
> + supported_csc,
> BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) |
> BIT(DRM_COLOR_YCBCR_FULL_RANGE),
> DRM_COLOR_YCBCR_BT709,
> --
> 2.17.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] [PATCH] tests/i915/gem_exec_store: remove hard coded engine limit
Prep for having an arbitrary context engine[], since that can be
whatever we like.
Signed-off-by: Matthew Auld
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
tests/i915/gem_exec_store.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/tests/i915/gem_exec_store.c b/tests/i915/gem_exec_store.c
index b74c3d84..eb511696 100644
--- a/tests/i915/gem_exec_store.c
+++ b/tests/i915/gem_exec_store.c
@@ -180,25 +180,40 @@ static void store_all(int fd)
const int gen = intel_gen(intel_get_drm_devid(fd));
struct drm_i915_gem_exec_object2 obj[2];
struct intel_execution_engine2 *engine;
- struct drm_i915_gem_relocation_entry reloc[32];
+ struct drm_i915_gem_relocation_entry *reloc;
struct drm_i915_gem_execbuffer2 execbuf;
- unsigned engines[16], permuted[16];
+ unsigned *engines, *permuted;
uint32_t batch[16];
uint64_t offset;
unsigned nengine;
int value;
int i, j;
+ nengine = 0;
+ __for_each_physical_engine(fd, engine) {
+ if (!gem_class_can_store_dword(fd, engine->class))
+ continue;
+ nengine++;
+ }
+
+ reloc = calloc(2*nengine, sizeof(*reloc));
+ igt_assert(reloc);
+
+ engines = calloc(nengine, sizeof(*engines));
+ igt_assert(engines);
+
+ permuted = calloc(nengine, sizeof(*permuted));
+ igt_assert(permuted);
+
memset(, 0, sizeof(execbuf));
execbuf.buffers_ptr = to_user_pointer(obj);
execbuf.buffer_count = 2;
if (gen < 6)
execbuf.flags |= I915_EXEC_SECURE;
- memset(reloc, 0, sizeof(reloc));
memset(obj, 0, sizeof(obj));
- obj[0].handle = gem_create(fd, 4096);
- obj[1].handle = gem_create(fd, 4096);
+ obj[0].handle = gem_create(fd, nengine*sizeof(uint32_t));
+ obj[1].handle = gem_create(fd, 2*nengine*sizeof(batch));
obj[1].relocation_count = 1;
offset = sizeof(uint32_t);
@@ -224,8 +239,6 @@ static void store_all(int fd)
if (!gem_class_can_store_dword(fd, engine->class))
continue;
- igt_assert(2*(nengine+1)*sizeof(batch) <= 4096);
-
execbuf.flags &= ~ENGINE_MASK;
execbuf.flags |= engine->flags;
@@ -281,12 +294,16 @@ static void store_all(int fd)
}
gem_close(fd, obj[1].handle);
- gem_read(fd, obj[0].handle, 0, engines, sizeof(engines));
+ gem_read(fd, obj[0].handle, 0, engines, nengine*sizeof(engines[0]));
gem_close(fd, obj[0].handle);
for (i = 0; i < nengine; i++)
igt_assert_eq_u32(engines[i], i);
igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+
+ free(permuted);
+ free(engines);
+ free(reloc);
}
static int print_welcome(int fd)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: make a gt sysfs group and move power management files
On 14/02/2020 11:03, Andi Shyti wrote:
The GT has its own properties and in sysfs they should be grouped
in the 'gt/' directory.
Create the 'gt/' directory in sysfs and move the power management
related files.
Can you paste the new and legacy paths in the commit message?
Signed-off-by: Andi Shyti
---
Hi,
this version has some more substantial differences, nothing that
changes the wanted behavior, though.
Thanks Chris, Jani and Tvrtko for the reviews,
Andi
Changelog:
==
v2 -> v3:
- fix some cleanups that I forgot in the previous patch
- fix reference pointers to the gt structure
- and many other small changes here and there.
v1 -> v2:
- keep the existing files as they are
- use "intel_gt_*" as prefix instead of "sysfs_*"
drivers/gpu/drm/i915/Makefile| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 3 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 +
drivers/gpu/drm/i915/gt/sysfs_gt.c | 85 +
drivers/gpu/drm/i915/gt/sysfs_gt.h | 22 ++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.c| 446 +++
drivers/gpu/drm/i915/gt/sysfs_gt_pm.h| 17 +
drivers/gpu/drm/i915/i915_sysfs.c| 375 +--
drivers/gpu/drm/i915/i915_sysfs.h| 3 +
9 files changed, 581 insertions(+), 375 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt.h
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.c
create mode 100644 drivers/gpu/drm/i915/gt/sysfs_gt_pm.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 49eed50ef0a4..3b81c8a96c06 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -106,7 +106,9 @@ gt-y += \
gt/intel_rps.o \
gt/intel_sseu.o \
gt/intel_timeline.o \
- gt/intel_workarounds.o
+ gt/intel_workarounds.o \
+ gt/sysfs_gt.o \
+ gt/sysfs_gt_pm.o
# autogenerated null render state
gt-y += \
gt/gen6_renderstate.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f1f1b306e0af..e794d05d69a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -15,6 +15,7 @@
#include "intel_rps.h"
#include "intel_uncore.h"
#include "intel_pm.h"
+#include "sysfs_gt.h"
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
{
@@ -321,6 +322,7 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_rps_driver_register(>rps);
debugfs_gt_register(gt);
+ intel_gt_sysfs_register(gt);
}
static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
@@ -641,6 +643,7 @@ void intel_gt_driver_remove(struct intel_gt *gt)
void intel_gt_driver_unregister(struct intel_gt *gt)
{
+ intel_gt_sysfs_unregister(gt);
intel_rps_driver_unregister(>rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 96890dd12b5f..552a27cc0622 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -32,6 +32,7 @@ struct intel_gt {
struct drm_i915_private *i915;
struct intel_uncore *uncore;
struct i915_ggtt *ggtt;
+ struct kobject kobj;
sysfs_root or something like would perhaps be more descriptive?
struct intel_uc uc;
diff --git a/drivers/gpu/drm/i915/gt/sysfs_gt.c b/drivers/gpu/drm/i915/gt/sysfs_gt.c
new file mode 100644
index ..4ca140fc215f
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/sysfs_gt.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: MIT
+
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "../i915_drv.h"
+#include "intel_gt.h"
+#include "intel_gt_types.h"
+#include "intel_rc6.h"
+
+#include "sysfs_gt.h"
+#include "sysfs_gt_pm.h"
+
+static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt)
+{
+ return kobject_get(>i915->drm.primary->kdev->kobj);
It's a bit surprising X_to_Y helper get a reference as well, no?
gt_get_parent_obj perhaps? But where is this released?
+}
+
+static ssize_t gt_info_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ return snprintf(buff, PAGE_SIZE, "0\n");
+}
+
+static DEVICE_ATTR_RO(gt_info);
+
+static void sysfs_gt_kobj_release(struct kobject *kobj)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj);
+
+ drm_info(>i915->drm, "releasing interface\n");
Debugging remnants.
+}
+
+static struct kobj_type sysfs_gt_ktype = {
+ .release = sysfs_gt_kobj_release,
+ .sysfs_ops = _sysfs_ops,
+};
+
+void intel_gt_sysfs_register(struct intel_gt *gt)
+{
+ struct kobject *kparent = gt_to_parent_obj(gt);
+ int ret;
+
+ ret = kobject_init_and_add(>kobj, _gt_ktype, kparent, "gt");
+ if (ret) {
+
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: make a gt sysfs group and move power management files (rev3)
== Series Details == Series: drm/i915/gt: make a gt sysfs group and move power management files (rev3) URL : https://patchwork.freedesktop.org/series/73190/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/gt: make a gt sysfs group and move power management files +drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:19:17: warning: symbol 'intel_gt_sysfs_get_drvdata' 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.CHECKPATCH: warning for drm/i915/gt: make a gt sysfs group and move power management files (rev3)
== Series Details == Series: drm/i915/gt: make a gt sysfs group and move power management files (rev3) URL : https://patchwork.freedesktop.org/series/73190/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2bb6ef6acc00 drm/i915/gt: make a gt sysfs group and move power management files -:71: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #71: new file mode 100644 -:553: WARNING:DEVICE_ATTR_FUNCTIONS: Consider renaming function(s) 'gt_rp_mhz_show' to 'gt_RP0_freq_mhz_show' #553: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:359: +static DEVICE_ATTR(gt_RP0_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:554: WARNING:DEVICE_ATTR_FUNCTIONS: Consider renaming function(s) 'gt_rp_mhz_show' to 'gt_RP1_freq_mhz_show' #554: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:360: +static DEVICE_ATTR(gt_RP1_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:555: CHECK:CAMELCASE: Avoid CamelCase: #555: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:361: +static DEVICE_ATTR(gt_RPn_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:555: WARNING:DEVICE_ATTR_FUNCTIONS: Consider renaming function(s) 'gt_rp_mhz_show' to 'gt_RPn_freq_mhz_show' #555: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:361: +static DEVICE_ATTR(gt_RPn_freq_mhz, 0444, gt_rp_mhz_show, NULL); -:570: CHECK:CAMELCASE: Avoid CamelCase: #570: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:376: + else if (attr == _attr_gt_RPn_freq_mhz) -:573: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #573: FILE: drivers/gpu/drm/i915/gt/sysfs_gt_pm.c:379: + BUG(); total: 0 errors, 5 warnings, 2 checks, 1029 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] lib: Add a YAML emitter
Quoting Jani Nikula (2020-02-14 07:57:09) > On Thu, 13 Feb 2020, Chris Wilson wrote: > > Provide a library to generate correct YAML for use in structured debugfs > > or similar information dumps. This will be useful to pull our large > > information dumps into a forwards compatible, parse-able file-format by > > forcing some structure upon ourselves! > > Acked-by: Jani Nikula > > I like the idea. I like the prospect of converting *all* of our bigger > debugfs files to have some structure. Why not smaller ones too, to be > uniform. Not entirely sold on using it in sysfs, like the example code > did, but even that might be justified for capturing a state. Fair enough, I shall not mention sysfs in the first pass :) And I'll do a couple more large and small debugfs to help flesh out the API and demonstrate its usecases. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/1] drm/i915/tgl: Add definitions for VRR registers and bits
Add definitions for registers grouped under Transcoder VRR function
with necessary bitfields.
Bspec: 49268
v2: Use REG_GENMASK, correct tabs/space indentation and move the
definitions near the transcoder section.(Jani)
Cc: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Matt Roper
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 90 +
1 file changed, 90 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b09c1d6dc0aa..ee169af7dda2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4319,6 +4319,96 @@ enum {
#define EXITLINE_MASKREG_GENMASK(12, 0)
#define EXITLINE_SHIFT 0
+/* VRR registers */
+#define _TRANS_VRR_CTL_A 0x60420
+#define _TRANS_VRR_CTL_B 0x61420
+#define _TRANS_VRR_CTL_C 0x62420
+#define _TRANS_VRR_CTL_D 0x63420
+#define TRANS_VRR_CTL(tran)_MMIO_TRANS2(tran, _TRANS_VRR_CTL_A)
+#define VRR_CTL_VRR_ENABLE REG_BIT(31)
+#define VRR_CTL_IGN_MAX_SHIFTREG_BIT(30)
+#define VRR_CTL_FLIP_LINE_EN REG_BIT(29)
+#define VRR_CTL_LINE_COUNT_MASK REG_GENMASK(10, 3)
+#define VRR_CTL_SW_FULLLINE_COUNTREG_BIT(0)
+
+#define _TRANS_VRR_VMAX_A 0x60424
+#define _TRANS_VRR_VMAX_B 0x61424
+#define _TRANS_VRR_VMAX_C 0x62424
+#define _TRANS_VRR_VMAX_D 0x63424
+#define TRANS_VRR_VMAX(tran) _MMIO_TRANS2(tran, _TRANS_VRR_VMAX_A)
+#define VRR_VMAX_MASKREG_GENMASK(19, 0)
+
+#define _TRANS_VRR_VMIN_A 0x60434
+#define _TRANS_VRR_VMIN_B 0x61434
+#define _TRANS_VRR_VMIN_C 0x62434
+#define _TRANS_VRR_VMIN_D 0x63434
+#define TRANS_VRR_VMIN(tran) _MMIO_TRANS2(tran, _TRANS_VRR_VMIN_A)
+#define TRANS_VRR_VMIN_MASK REG_GENMASK(15, 0)
+
+#define _TRANS_VRR_VMAXSHIFT_A 0x60428
+#define _TRANS_VRR_VMAXSHIFT_B 0x61428
+#define _TRANS_VRR_VMAXSHIFT_C 0x62428
+#define _TRANS_VRR_VMAXSHIFT_D 0x63428
+#define TRANS_VRR_VMAXSHIFT(tran) _MMIO_TRANS2(tran, \
+ _TRANS_VRR_VMAXSHIFT_A)
+#define VRR_VMAXSHIFT_DEC_MASK REG_GENMASK(29, 16)
+#define VRR_VMAXSHIFT_DECREG_BIT(16)
+#define TRANS_VRR_VMAXSHIFT_INC_MASK REG_GENMASK(12, 0)
+
+#define _TRANS_VRR_STATUS_A0x6042C
+#define _TRANS_VRR_STATUS_B0x6142C
+#define _TRANS_VRR_STATUS_C0x6242C
+#define _TRANS_VRR_STATUS_D0x6342C
+#define TRANS_VRR_STATUS(tran) _MMIO_TRANS2(tran, _TRANS_VRR_STATUS_A)
+#define VRR_STATUS_VMAX_REACHED REG_BIT(31)
+#define VRR_STATUS_NOFLIP_TILL_BNDR REG_BIT(30)
+#define VRR_STATUS_FLIP_BEF_BNDR REG_BIT(29)
+#define VRR_STATUS_NO_FLIP_FRAME REG_BIT(28)
+#define VRR_STATUS_VRR_EN_LIVE REG_BIT(27)
+#define VRR_STATUS_FLIPS_SERVICEDREG_BIT(26)
+#define VRR_STATUS_VBLANK_MASK REG_GENMASK(22, 20)
+#define STATUS_FSM_IDLE REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
0)
+#define STATUS_FSM_WAIT_TILL_FDB REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
1)
+#define STATUS_FSM_WAIT_TILL_FS REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
2)
+#define STATUS_FSM_WAIT_TILL_FLIPREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
3)
+#define STATUS_FSM_PIPELINE_FILL REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
4)
+#define STATUS_FSM_ACTIVEREG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
5)
+#define STATUS_FSM_LEGACY_VBLANK REG_FIELD_PREP(VRR_STATUS_VBLANK_MASK,
6)
+
+#define _TRANS_VRR_VTOTAL_PREV_A 0x60480
+#define _TRANS_VRR_VTOTAL_PREV_B 0x61480
+#define _TRANS_VRR_VTOTAL_PREV_C 0x62480
+#define _TRANS_VRR_VTOTAL_PREV_D 0x63480
+#define TRANS_VRR_VTOTAL_PREV(tran)_MMIO_TRANS2(tran, \
+ _TRANS_VRR_VTOTAL_PREV_A)
+#define VRR_VTOTAL_FLIP_BEFR_BNDRREG_BIT(31)
+#define VRR_VTOTAL_FLIP_AFTER_BNDR REG_BIT(30)
+#define VRR_VTOTAL_FLIP_AFTER_DBLBUF REG_BIT(29)
+#define VRR_VTOTAL_PREV_FRAME_MASK REG_GENMASK(19, 0)
+
+#define _TRANS_VRR_FLIPLINE_A 0x60438
+#define _TRANS_VRR_FLIPLINE_B 0x61438
+#define _TRANS_VRR_FLIPLINE_C 0x62438
+#define _TRANS_VRR_FLIPLINE_D 0x63438
+#define TRANS_VRR_FLIPLINE(tran) _MMIO_TRANS2(tran, \
+ _TRANS_VRR_FLIPLINE_A)
+#define VRR_FLIPLINE_MASKREG_GENMASK(19, 0)
+
+#define _TRANS_VRR_STATUS2_A 0x6043C
+#define _TRANS_VRR_STATUS2_B 0x6143C
+#define _TRANS_VRR_STATUS2_C 0x6243C
+#define _TRANS_VRR_STATUS2_D 0x6343C
+#define TRANS_VRR_STATUS2(tran)_MMIO_TRANS2(tran,
_TRANS_VRR_STATUS2_A)
+#define VRR_STATUS2_VERT_LN_CNT_MASK REG_GENMASK(19, 0)
+
+#define _TRANS_PUSH_A
[Intel-gfx] [PATCH v2 0/1] Adding definitions for VRR registers and bitfields
Add definitions for configuring VRR registers for TGL. Aditya Swarup (1): drm/i915/tgl: Add definitions for VRR registers and bits drivers/gpu/drm/i915/i915_reg.h | 90 + 1 file changed, 90 insertions(+) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for Color encoding YCBCR_BT2020
== Series Details ==
Series: Add support for Color encoding YCBCR_BT2020
URL : https://patchwork.freedesktop.org/series/73457/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7938 -> Patchwork_16568
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/index.html
Known issues
Here are the changes found in Patchwork_16568 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gtt:
- fi-skl-6600u: [PASS][1] -> [TIMEOUT][2] ([fdo#111732] /
[fdo#112271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-6600u/igt@i915_selftest@live_gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/fi-skl-6600u/igt@i915_selftest@live_gtt.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [INCOMPLETE][3] ([i915#45]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_parallel@contexts:
- {fi-ehl-1}: [INCOMPLETE][5] ([i915#937]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-ehl-1/igt@gem_exec_paral...@contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/fi-ehl-1/igt@gem_exec_paral...@contexts.html
* igt@i915_selftest@live_execlists:
- fi-icl-y: [DMESG-FAIL][7] ([fdo#108569]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-icl-y/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/fi-icl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gtt:
- fi-bxt-dsi: [TIMEOUT][9] ([fdo#112271]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#111732]: https://bugs.freedesktop.org/show_bug.cgi?id=111732
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
Participating hosts (52 -> 44)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-cfl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7938 -> Patchwork_16568
CI-20190529: 20190529
CI_DRM_7938: 9fda6807b50ceb40ef01b055f6428db8965e3d06 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5441: 534ca091fe4ffed916752165bc5becd7ff56cd84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16568: b4fc9ab087da4ae3bcedf2a5beab580e74273b64 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b4fc9ab087da Add support for Color encoding YCBCR_BT2020
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16568/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Check for the error interrupt before we wait!
Sometimes the error interrupt can fire even before we have seen the
request go active -- in which case, we end up waiting until the timeout
as the request is already completed. Double check for this case!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 3a74a54739a8..64761e619876 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -76,11 +76,15 @@ static int wait_for_submit(struct intel_engine_cs *engine,
do {
cond_resched();
intel_engine_flush_submission(engine);
+
if (i915_request_is_active(rq) &&
!READ_ONCE(engine->execlists.pending[0])) {
tasklet_unlock_wait(>execlists.tasklet);
return 0;
}
+
+ if (i915_request_completed(rq)) /* that was quick! */
+ return 0;
} while (time_before(jiffies, timeout));
return -ETIME;
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Cast remain to unsigned long in eb_relocate_vma
On Fri, 14 Feb 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-02-14 06:36:15) >> On Thu, 13 Feb 2020, Nathan Chancellor wrote: >> > A recent commit in clang added -Wtautological-compare to -Wall, which is >> > enabled for i915 after -Wtautological-compare is disabled for the rest >> > of the kernel so we see the following warning on x86_64: >> > >> > ../drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1433:22: warning: >> > result of comparison of constant 576460752303423487 with expression of >> > type 'unsigned int' is always false >> > [-Wtautological-constant-out-of-range-compare] >> > if (unlikely(remain > N_RELOC(ULONG_MAX))) >> > ^ >> > ../include/linux/compiler.h:78:42: note: expanded from macro 'unlikely' >> > # define unlikely(x)__builtin_expect(!!(x), 0) >> > ^ >> > 1 warning generated. >> > >> > It is not wrong in the case where ULONG_MAX > UINT_MAX but it does not >> > account for the case where this file is built for 32-bit x86, where >> > ULONG_MAX == UINT_MAX and this check is still relevant. >> > >> > Cast remain to unsigned long, which keeps the generated code the same >> > (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and >> > the warning is silenced so we can catch more potential issues in the >> > future. >> > >> > Link: https://github.com/ClangBuiltLinux/linux/issues/778 >> > Suggested-by: Michel Dänzer >> > Signed-off-by: Nathan Chancellor >> >> Works for me as a workaround, > > But the whole point was that the compiler could see that it was > impossible and not emit the code. Doesn't this break that? It seems that goal and the warning are fundamentally incompatible. Back to the original patch? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Implement parallel execbuf submission.
== Series Details == Series: drm/i915/gem: Implement parallel execbuf submission. URL : https://patchwork.freedesktop.org/series/73456/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7938 -> Patchwork_16567 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_16567 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_16567, 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_16567/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_16567: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-threads: - fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-icl-guc/igt@gem_close_r...@basic-threads.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-icl-guc/igt@gem_close_r...@basic-threads.html - fi-bdw-5557u: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-bdw-5557u/igt@gem_close_r...@basic-threads.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-bdw-5557u/igt@gem_close_r...@basic-threads.html - fi-kbl-x1275: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-kbl-x1275/igt@gem_close_r...@basic-threads.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-kbl-x1275/igt@gem_close_r...@basic-threads.html * igt@gem_exec_parallel@fds: - fi-cfl-8109u: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-cfl-8109u/igt@gem_exec_paral...@fds.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-cfl-8109u/igt@gem_exec_paral...@fds.html * igt@gem_sync@basic-each: - fi-kbl-7500u: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-kbl-7500u/igt@gem_s...@basic-each.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-kbl-7500u/igt@gem_s...@basic-each.html * igt@i915_selftest@live_gt_engines: - fi-snb-2520m: [PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-snb-2520m/igt@i915_selftest@live_gt_engines.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-snb-2520m/igt@i915_selftest@live_gt_engines.html * igt@i915_selftest@live_requests: - fi-hsw-peppy: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-hsw-peppy/igt@i915_selftest@live_requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-hsw-peppy/igt@i915_selftest@live_requests.html - fi-skl-6700k2: [PASS][15] -> [DMESG-WARN][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-6700k2/igt@i915_selftest@live_requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-skl-6700k2/igt@i915_selftest@live_requests.html - fi-hsw-4770r: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-hsw-4770r/igt@i915_selftest@live_requests.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-hsw-4770r/igt@i915_selftest@live_requests.html - fi-skl-lmem:[PASS][19] -> [DMESG-WARN][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-lmem/igt@i915_selftest@live_requests.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-skl-lmem/igt@i915_selftest@live_requests.html - fi-ivb-3770:[PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-ivb-3770/igt@i915_selftest@live_requests.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-ivb-3770/igt@i915_selftest@live_requests.html - fi-skl-6600u: [PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-6600u/igt@i915_selftest@live_requests.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-skl-6600u/igt@i915_selftest@live_requests.html - fi-cml-s: [PASS][25] -> [DMESG-WARN][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-cml-s/igt@i915_selftest@live_requests.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16567/fi-cml-s/igt@i915_selftest@live_requests.html - fi-hsw-4770:[PASS][27] -> [DMESG-WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-hsw-4770/igt@i915_selftest@live_requests.html [28]:
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: split out display debugfs to a separate file
On Fri, 14 Feb 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-02-11 16:14:51) >> The i915_debugfs.c has grown more than a little unwieldy. Split out the >> display related debugfs code to a file of its own under display/, >> initialized with a separate call. No functional changes. >> >> v2: >> - Also moved i915_frontbuffer_tracking, i915_gem_framebuffer, >> i915_power_domain_info, i915_dmc_info, i915_ipc_status (Ville) >> >> Cc: Ville Syrjälä >> Signed-off-by: Jani Nikula > The diff unnerved me, but I couldn't spot anything other than code motion. > Reviewed-by: Chris Wilson Many thanks, pushed to dinq. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI v3 2/3] drm/i915/dp: Compute port sync crtc states post compute_config()
This patch pushes out the computation of master and slave
transcoders in crtc states after encoder's compute_config hook.
This ensures that the assigned master slave crtcs have exact same
mode and timings which is a requirement for Port sync mode
to be enabled.
v3:
* Make crtc_state const, remove crtc state NULL init (Ville)
v2:
* Correct indentation
* Rename to intel_ddi_port_sync_transcoders (Ville)
* remove unwanted debug (Ville)
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 107 +
drivers/gpu/drm/i915/display/intel_display.c | 159 +--
2 files changed, 108 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 544e15603ef9..f2fd9f097591 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4455,6 +4455,112 @@ static int intel_ddi_compute_config(struct
intel_encoder *encoder,
return 0;
}
+static bool mode_equal(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+ return drm_mode_match(mode1, mode2,
+ DRM_MODE_MATCH_TIMINGS |
+ DRM_MODE_MATCH_FLAGS |
+ DRM_MODE_MATCH_3D_FLAGS) &&
+ mode1->clock == mode2->clock; /* we want an exact match */
+}
+
+static bool m_n_equal(const struct intel_link_m_n *m_n_1,
+ const struct intel_link_m_n *m_n_2)
+{
+ return m_n_1->tu == m_n_2->tu &&
+ m_n_1->gmch_m == m_n_2->gmch_m &&
+ m_n_1->gmch_n == m_n_2->gmch_n &&
+ m_n_1->link_m == m_n_2->link_m &&
+ m_n_1->link_n == m_n_2->link_n;
+}
+
+static bool crtcs_port_sync_compatible(const struct intel_crtc_state
*crtc_state1,
+ const struct intel_crtc_state
*crtc_state2)
+{
+ return crtc_state1->hw.active && crtc_state2->hw.active &&
+ crtc_state1->output_types == crtc_state2->output_types &&
+ crtc_state1->output_format == crtc_state2->output_format &&
+ crtc_state1->lane_count == crtc_state2->lane_count &&
+ crtc_state1->port_clock == crtc_state2->port_clock &&
+ mode_equal(_state1->hw.adjusted_mode,
+ _state2->hw.adjusted_mode) &&
+ m_n_equal(_state1->dp_m_n, _state2->dp_m_n);
+}
+
+static u8
+intel_ddi_port_sync_transcoders(const struct intel_crtc_state *ref_crtc_state,
+ int tile_group_id)
+{
+ struct drm_connector *connector;
+ const struct drm_connector_state *conn_state;
+ struct drm_i915_private *dev_priv =
to_i915(ref_crtc_state->uapi.crtc->dev);
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(ref_crtc_state->uapi.state);
+ u8 transcoders = 0;
+ int i;
+
+ if (INTEL_GEN(dev_priv) < 11)
+ return 0;
+
+ if (!intel_crtc_has_type(ref_crtc_state, INTEL_OUTPUT_DP))
+ return 0;
+
+ for_each_new_connector_in_state(>base, connector, conn_state, i)
{
+ struct intel_crtc *crtc = to_intel_crtc(conn_state->crtc);
+ const struct intel_crtc_state *crtc_state;
+
+ if (!crtc)
+ continue;
+
+ if (!connector->has_tile ||
+ connector->tile_group->id !=
+ tile_group_id)
+ continue;
+ crtc_state = intel_atomic_get_new_crtc_state(state,
+crtc);
+ if (!crtcs_port_sync_compatible(ref_crtc_state,
+ crtc_state))
+ continue;
+ transcoders |= BIT(crtc_state->cpu_transcoder);
+ }
+
+ return transcoders;
+}
+
+static int intel_ddi_compute_config_late(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct drm_connector *connector = conn_state->connector;
+ u8 port_sync_transcoders = 0;
+
+ DRM_DEBUG_KMS("[ENCODER:%d:%s] [CRTC:%d:%s]",
+ encoder->base.base.id, encoder->base.name,
+ crtc_state->uapi.crtc->base.id,
crtc_state->uapi.crtc->name);
+
+ if (connector->has_tile)
+ port_sync_transcoders =
intel_ddi_port_sync_transcoders(crtc_state,
+
connector->tile_group->id);
+
+ /*
+* EDP Transcoders cannot be ensalved
+* make them a master always when present
+*/
+ if (port_sync_transcoders &
[Intel-gfx] [CI v3 1/3] drm/i915: Introduce encoder->compute_config_late()
From: Ville Syrjälä
Add an optional secondary encoder state compute hook. This gets
called after the normak .compute_config() has been called for
all the encoders in the state. Thus in the new hook we can rely
on all derived state populated by .compute_config() to be already
set up. Should be useful for MST and port sync master/slave
transcoder selection.
Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 39 +++
.../drm/i915/display/intel_display_types.h| 3 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e09d3c93c52b..ce72551ba16a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -13549,6 +13549,35 @@ intel_modeset_pipe_config(struct intel_crtc_state
*pipe_config)
return 0;
}
+static int
+intel_modeset_pipe_config_late(struct intel_crtc_state *crtc_state)
+{
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(crtc_state->uapi.state);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_connector_state *conn_state;
+ struct drm_connector *connector;
+ int i;
+
+ for_each_new_connector_in_state(>base, connector,
+ conn_state, i) {
+ struct intel_encoder *encoder =
+ to_intel_encoder(conn_state->best_encoder);
+ int ret;
+
+ if (conn_state->crtc != >base ||
+ !encoder->compute_config_late)
+ continue;
+
+ ret = encoder->compute_config_late(encoder, crtc_state,
+ conn_state);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
bool intel_fuzzy_clock_check(int clock1, int clock2)
{
int diff;
@@ -14954,6 +14983,16 @@ static int intel_atomic_check(struct drm_device *dev,
ret = intel_modeset_pipe_config(new_crtc_state);
if (ret)
goto fail;
+ }
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (!needs_modeset(new_crtc_state))
+ continue;
+
+ ret = intel_modeset_pipe_config_late(new_crtc_state);
+ if (ret)
+ goto fail;
intel_crtc_check_fastset(old_crtc_state, new_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 283c622f8ba1..0d8a64305464 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -141,6 +141,9 @@ struct intel_encoder {
int (*compute_config)(struct intel_encoder *,
struct intel_crtc_state *,
struct drm_connector_state *);
+ int (*compute_config_late)(struct intel_encoder *,
+ struct intel_crtc_state *,
+ struct drm_connector_state *);
void (*update_prepare)(struct intel_atomic_state *,
struct intel_encoder *,
struct intel_crtc *);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync conns to modeset
If one of the synced crtcs needs a full modeset, we need
to make sure all the synced crtcs are forced a full
modeset.
v3:
* Remove ~BIT(cpu_trans) which is a nop (Ville)
* use get_new_crtc_state and remove error check (Ville)
v2:
* Add tiles based on cpu_trans check (Ville)
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 85
drivers/gpu/drm/i915/display/intel_dp.c | 136 ++-
2 files changed, 135 insertions(+), 86 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c8615f212e8f..8693585d8d88 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14694,76 +14694,6 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
-static int
-intel_modeset_all_tiles(struct intel_atomic_state *state, int tile_grp_id)
-{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- struct drm_connector *connector;
- struct drm_connector_list_iter conn_iter;
- int ret = 0;
-
- drm_connector_list_iter_begin(_priv->drm, _iter);
- drm_for_each_connector_iter(connector, _iter) {
- struct drm_connector_state *conn_state;
- struct drm_crtc_state *crtc_state;
-
- if (!connector->has_tile ||
- connector->tile_group->id != tile_grp_id)
- continue;
- conn_state = drm_atomic_get_connector_state(>base,
- connector);
- if (IS_ERR(conn_state)) {
- ret = PTR_ERR(conn_state);
- break;
- }
-
- if (!conn_state->crtc)
- continue;
-
- crtc_state = drm_atomic_get_crtc_state(>base,
- conn_state->crtc);
- if (IS_ERR(crtc_state)) {
- ret = PTR_ERR(crtc_state);
- break;
- }
- crtc_state->mode_changed = true;
- ret = drm_atomic_add_affected_connectors(>base,
-conn_state->crtc);
- if (ret)
- break;
- }
- drm_connector_list_iter_end(_iter);
-
- return ret;
-}
-
-static int
-intel_atomic_check_tiled_conns(struct intel_atomic_state *state)
-{
- struct drm_i915_private *dev_priv = to_i915(state->base.dev);
- struct drm_connector *connector;
- struct drm_connector_state *old_conn_state, *new_conn_state;
- int i, ret;
-
- if (INTEL_GEN(dev_priv) < 11)
- return 0;
-
- /* Is tiled, mark all other tiled CRTCs as needing a modeset */
- for_each_oldnew_connector_in_state(>base, connector,
- old_conn_state, new_conn_state, i) {
- if (!connector->has_tile)
- continue;
- if (!intel_connector_needs_modeset(state, connector))
- continue;
-
- ret = intel_modeset_all_tiles(state, connector->tile_group->id);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-
/**
* intel_atomic_check - validate state object
* @dev: drm device
@@ -14792,21 +14722,6 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
- /**
-* This check adds all the connectors in current state that belong to
-* the same tile group to a full modeset.
-* This function directly sets the mode_changed to true and we also call
-* drm_atomic_add_affected_connectors(). Hence we are not explicitly
-* calling drm_atomic_helper_check_modeset() after this.
-*
-* Fixme: Handle some corner cases where one of the
-* tiled connectors gets disconnected and tile info is lost but since it
-* was previously synced to other conn, we need to add that to the
modeset.
-*/
- ret = intel_atomic_check_tiled_conns(state);
- if (ret)
- goto fail;
-
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!needs_modeset(new_crtc_state)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f4dede6253f8..27ffbaab8296 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6582,6 +6582,140 @@ void intel_dp_encoder_reset(struct drm_encoder *encoder)
}
}
+static int intel_modeset_tile_group(struct intel_atomic_state *state,
+
Re: [Intel-gfx] [PATCH] Add support for Color encoding YCBCR_BT2020
On Fri, 14 Feb 2020, Kishore Kadiyala wrote: > Currently the plane property doesn't have support for YCBCR_BT2020, > which enables the corresponding color conversion mode on plane CSC. Please prefix your patch subjects properly. "drm/i915: " at a minimum for stuff touching i915. No need to resend for this, but for future reference. BR, Jani. > > Signed-off-by: Kishore Kadiyala > Cc: Uma Shankar > --- > drivers/gpu/drm/i915/display/intel_sprite.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c > b/drivers/gpu/drm/i915/display/intel_sprite.c > index 7abeefe8dce5..5169a7260d7c 100644 > --- a/drivers/gpu/drm/i915/display/intel_sprite.c > +++ b/drivers/gpu/drm/i915/display/intel_sprite.c > @@ -3011,6 +3011,7 @@ skl_universal_plane_create(struct drm_i915_private > *dev_priv, > struct intel_plane *plane; > enum drm_plane_type plane_type; > unsigned int supported_rotations; > + unsigned int supported_csc; > unsigned int possible_crtcs; > const u64 *modifiers; > const u32 *formats; > @@ -3088,9 +3089,13 @@ skl_universal_plane_create(struct drm_i915_private > *dev_priv, > DRM_MODE_ROTATE_0, > supported_rotations); > > + supported_csc = BIT(DRM_COLOR_YCBCR_BT601) | BIT(DRM_COLOR_YCBCR_BT709); > + > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > + supported_csc |= BIT(DRM_COLOR_YCBCR_BT2020); > + > drm_plane_create_color_properties(>base, > - BIT(DRM_COLOR_YCBCR_BT601) | > - BIT(DRM_COLOR_YCBCR_BT709), > + supported_csc, > BIT(DRM_COLOR_YCBCR_LIMITED_RANGE) | > BIT(DRM_COLOR_YCBCR_FULL_RANGE), > DRM_COLOR_YCBCR_BT709, -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Introduce encoder->compute_config_late()
On Sun, Feb 02, 2020 at 11:47:54PM -0800, Manasi Navare wrote:
> From: Ville Syrjälä
>
> Add an optional secondary encoder state compute hook. This gets
> called after the normak .compute_config() has been called for
> all the encoders in the state. Thus in the new hook we can rely
> on all derived state populated by .compute_config() to be already
> set up. Should be useful for MST and port sync master/slave
> transcoder selection.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 39 +++
> .../drm/i915/display/intel_display_types.h| 3 ++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b0af37fb6d4a..2a2c9dd563e5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13522,6 +13522,35 @@ intel_modeset_pipe_config(struct intel_crtc_state
> *pipe_config)
> return 0;
> }
>
> +static int
> +intel_modeset_pipe_config_late(struct intel_crtc_state *crtc_state)
> +{
> + struct intel_atomic_state *state =
> + to_intel_atomic_state(crtc_state->uapi.state);
> + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> + struct drm_connector_state *conn_state;
> + struct drm_connector *connector;
> + int i;
> +
> + for_each_new_connector_in_state(>base, connector,
> + conn_state, i) {
> + struct intel_encoder *encoder =
> + to_intel_encoder(conn_state->best_encoder);
> + int ret;
> +
> + if (conn_state->crtc != >base ||
> + !encoder->compute_config_late)
> + continue;
> +
> + ret = encoder->compute_config_late(encoder, crtc_state,
> +conn_state);
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> bool intel_fuzzy_clock_check(int clock1, int clock2)
> {
> int diff;
> @@ -14929,6 +14958,16 @@ static int intel_atomic_check(struct drm_device *dev,
> ret = intel_modeset_pipe_config(new_crtc_state);
> if (ret)
> goto fail;
> + }
> +
> + for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> + new_crtc_state, i) {
> + if (!needs_modeset(new_crtc_state))
> + continue;
> +
> + ret = intel_modeset_pipe_config_late(new_crtc_state);
> + if (ret)
> + goto fail;
>
> intel_crtc_check_fastset(old_crtc_state, new_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 7c6133a9c51b..96d84d027556 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -141,6 +141,9 @@ struct intel_encoder {
> int (*compute_config)(struct intel_encoder *,
> struct intel_crtc_state *,
> struct drm_connector_state *);
> + int (*compute_config_late)(struct intel_encoder *,
> +struct intel_crtc_state *,
> +struct drm_connector_state *);
> void (*update_prepare)(struct intel_atomic_state *,
> struct intel_encoder *,
> struct intel_crtc *);
> --
> 2.19.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Implement parallel execbuf submission.
== Series Details ==
Series: drm/i915/gem: Implement parallel execbuf submission.
URL : https://patchwork.freedesktop.org/series/73456/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
45e26eb55b49 drm/i915: Drop inspection of execbuf flags during evict
77137cc44da0 drm/i915/gem: Extract transient execbuf flags from i915_vma
1c9c54ea3f9f drm/i915: Separate lookup and pinning in execbuf.
-:153: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#153: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:857:
+ }
total: 0 errors, 0 warnings, 1 checks, 190 lines checked
74411de36fec drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:506: WARNING:LONG_LINE: line over 100 characters
#506: FILE: drivers/gpu/drm/i915/i915_gem.c:1340:
+ while ((obj = list_first_entry_or_null(>obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 481 lines checked
4fb224307417 drm/i915: Remove locking from i915_gem_object_prepare_read/write
6d289dfa8e94 drm/i915: Parse command buffer earlier in eb_relocate(slow)
94e03631a69b drm/i915: Use per object locking in execbuf on top of
struct_mutex, v3.
-:224: CHECK:BRACES: braces {} should be used on all arms of this statement
#224: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1831:
+ if (err == -EDEADLK) {
[...]
+ else if (err)
[...]
-:232: ERROR:ELSE_AFTER_BRACE: else should follow close brace '}'
#232: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1839:
+ }
+ else if (err)
total: 1 errors, 0 warnings, 1 checks, 326 lines checked
15b80a481667 drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 202 lines checked
656138053d87 drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:978:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
75b5a2f7f6c3 drm/i915: Nuke arguments to eb_pin_engine
39baf3b54346 drm/i915: Pin engine before pinning all objects, v2.
b3a660cd040f drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:171:
+
+
-:330: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#330: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:2942:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 436 lines checked
4782909f0467 drm/i915: Make sure execbuffer always passes ww state to
i915_vma_pin.
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:581:
+ err = i915_vma_pin_ww(vma, >ww,
entry->pad_to_size, entry->alignment,
-:185: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#185: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2166:
+* hsw should have this fixed, but bdw mucks it up again. */
total: 0 errors, 1 warnings, 1 checks, 811 lines checked
5819fba41820 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking
as well
4f5b737716e8 drm/i915: Kill last user of intel_context_create_request outside
of selftests
e1a5ab78d885 drm/i915: Convert i915_perf to ww locking as well
80cc1c0dea35 drm/i915: Dirty hack to fix selftests locking inversion
e091c73e4158 drm/i915/selftests: Fix locking inversion in lrc selftest.
6e5d190d8121 drm/i915: Use ww pinning for intel_context_create_request()
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v2 5/5] i915/gem_ctx_isolation.c - If initialization fails, exit
On Thu, Feb 13, 2020 at 11:29:48AM -0800, Dale B Stimson wrote:
> On 2020-02-13 10:29:55, Petri Latvala wrote:
> > On Wed, Feb 12, 2020 at 05:28:40PM -0800, Dale B Stimson wrote:
> > > At the start of igt_main, failure of the initial tests for successful
> > > initialization transfer control to the end of an igt_fixture block.
> > > From there, execution of the main per-engine loop is attempted.
> > > Instead, the test should be caused to exit.
> > >
> > > If initialization fails, exit.
> > >
> > > Signed-off-by: Dale B Stimson
> > > ---
> > > tests/i915/gem_ctx_isolation.c | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/tests/i915/gem_ctx_isolation.c
> > > b/tests/i915/gem_ctx_isolation.c
> > > index 07ffbb84a..b11158dab 100644
> > > --- a/tests/i915/gem_ctx_isolation.c
> > > +++ b/tests/i915/gem_ctx_isolation.c
> > > @@ -898,10 +898,13 @@ igt_main
> > > int fd = -1;
> > > struct eng_mmio_base_table_s *mbp = NULL;
> > > uint32_t mmio_base = 0;
> > > + /* igt_fixture block is skipped if --list-subtests, so start with true.
> > > */
> > > + bool init_successful = true;
> > >
> > > igt_fixture {
> > > int gen;
> > >
> > > + init_successful = false;
> > > fd = drm_open_driver(DRIVER_INTEL);
> > > igt_require_gem(fd);
> > > igt_require(gem_has_contexts(fd));
> > > @@ -916,8 +919,20 @@ igt_main
> > > igt_skip_on(gen > LAST_KNOWN_GEN);
> > >
> > > mbp = gem_engine_mmio_base_info_get(fd);
> > > + init_successful = true;
> > > }
> > >
> > > + if (!init_successful) {
> > > + igt_exit_early();
> > > + }
> > > +
> >
> > NAK. All this dancing around the infrastructure just makes changing
> > the infrastructure later be awkward and produce weird errors.
> >
> > If something in the fixture failed, with this code you never enter the
> > subtest, making the test result 'notrun' instead of the correct 'skip'
> > or 'fail'.
> >
> > What is the problem this is trying to solve? Incorrect engine list
> > used? If you have a subtest per static engine, all CI does is execute
> > per static engine. Converting this test to use dynamic subtests for
> > engines is the way forward.
> >
> >
> > --
> > Petri Latvala
>
> NAK understood and accepted.
>
> I will address this in a different way, targeting the underlying issues
> instead of the symptom. Please see my patch (just sent to ML):
> lib/i915/gem_engine_topology.c - intel_get_current_engine invalid result
>
> To answer to your question about what this was trying to solve:
>
> Briefly, and specifically addressing gem_ctx_isolation:
>
> As-is observed behavior when open (or debugfs open) fails: per-engine loop
> executes forever:
> Subtest vecs0-nonpriv: FAIL
> Subtest vecs0-nonpriv-switch: FAIL
> Subtest vecs0-clean: FAIL
> Subtest vecs0-dirty-create: FAIL
> Subtest vecs0-dirty-switch: FAIL
> Subtest vecs0-none: FAIL
> Subtest vecs0-S3: FAIL
> Subtest vecs0-S4: FAIL
> Subtest vecs0-reset: FAIL
> And repeat, ad infinitum for vecs0
>
Ah, the good old non-progressing engine loop. We already have fixes
for two of the occurrences, you have found a third one. =(
--
Petri Latvala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gt: Yield the timeslice if caught waiting on a user semaphore
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Yield the timeslice if caught
waiting on a user semaphore
URL : https://patchwork.freedesktop.org/series/73455/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7938 -> Patchwork_16566
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/index.html
Known issues
Here are the changes found in Patchwork_16566 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-hsw-peppy/igt@gem_close_r...@basic-threads.html
* igt@i915_module_load@reload:
- fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([i915#92]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-6770hq/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-skl-6770hq/igt@i915_module_l...@reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [PASS][5] -> [DMESG-FAIL][6] ([i915#877])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@i915_selftest@live_requests:
- fi-apl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-apl-guc/igt@i915_selftest@live_requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-apl-guc/igt@i915_selftest@live_requests.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-skl-6770hq: [PASS][9] -> [SKIP][10] ([fdo#109271]) +5 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-skl-6770hq: [PASS][11] -> [DMESG-WARN][12] ([i915#106])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-byt-n2820: [INCOMPLETE][13] ([i915#45]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-byt-n2820/igt@gem_close_r...@basic-threads.html
* igt@gem_exec_parallel@contexts:
- {fi-ehl-1}: [INCOMPLETE][15] ([i915#937]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-ehl-1/igt@gem_exec_paral...@contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-ehl-1/igt@gem_exec_paral...@contexts.html
* igt@i915_selftest@live_execlists:
- fi-icl-y: [DMESG-FAIL][17] ([fdo#108569]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-icl-y/igt@i915_selftest@live_execlists.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-icl-y/igt@i915_selftest@live_execlists.html
* igt@i915_selftest@live_gtt:
- fi-bxt-dsi: [TIMEOUT][19] ([fdo#112271]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7938/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16566/fi-bxt-dsi/igt@i915_selftest@live_gtt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#937]: https://gitlab.freedesktop.org/drm/intel/issues/937
