[Intel-gfx] [PATCH v2 5/9] drm/i915/bios: Assume panel_type==0 if the VBT has bogus data
From: Ville Syrjälä
Just assume panel_type==0 always if the VBT gives us bogus data.
We actually already do this everywhere else except in
parse_panel_options() since we just leave i915->vbt.panel_type
zeroed. This also seems to be what Windows does.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index ecfce9adfbbb..53a7a16df231 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -619,13 +619,14 @@ parse_panel_options(struct drm_i915_private *i915)
} else {
if (lvds_options->panel_type > 0xf) {
drm_dbg_kms(>drm,
- "Invalid VBT panel type 0x%x\n",
+ "Invalid VBT panel type 0x%x, assuming 0\n",
lvds_options->panel_type);
- return;
+ panel_type = 0;
+ } else {
+ panel_type = lvds_options->panel_type;
+ drm_dbg_kms(>drm, "Panel type: %d (VBT)\n",
+ panel_type);
}
- panel_type = lvds_options->panel_type;
- drm_dbg_kms(>drm, "Panel type: %d (VBT)\n",
- panel_type);
}
i915->vbt.panel_type = panel_type;
--
2.35.1
[Intel-gfx] [PATCH v2 4/9] drm/i915/bios: Document the mess around the LFP data tables
From: Ville Syrjälä
Document the fact that struct lvds_lfp_data_entry can't be used
directly and instead must be accessed via the data table pointers.
Also remove the bogus comment implying that there might be a
variable number of panel entries in the table. There are always
exactly 16.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index 2554f4b9b4da..4b98bab3b890 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -735,7 +735,7 @@ struct lvds_lfp_data_ptr {
} __packed;
struct bdb_lvds_lfp_data_ptrs {
- u8 lvds_entries; /* followed by one or more lvds_data_ptr structs */
+ u8 lvds_entries;
struct lvds_lfp_data_ptr ptr[16];
struct lvds_lfp_data_ptr_table panel_name; /* 156-163? */
} __packed;
@@ -769,6 +769,11 @@ struct lvds_pnp_id {
u8 mfg_year;
} __packed;
+/*
+ * For reference only. fp_timing has variable size so
+ * the data must be accessed using the data table pointers.
+ * Do not use this directly!
+ */
struct lvds_lfp_data_entry {
struct lvds_fp_timing fp_timing;
struct lvds_dvo_timing dvo_timing;
--
2.35.1
[Intel-gfx] [PATCH v2 3/9] drm/i915/bios: Get access to the tail end of the LFP data block
From: Ville Syrjälä
We need to start parsing stuff from the tail end of the LFP data block.
This is made awkward by the fact that the fp_timing table has variable
size. So we must use a bit more finesse to get the tail end, and to
make sure we allocate enough memory for it to make sure our struct
representation fits.
v2: Rebase due to the preallocation of BDB blocks
v3: Rebase due to min_size WARN relocation
v4: Document BDB_LVDS_LFP_DATA vs. BDB_LVDS_LFP_DATA_PTRS order (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 43 ++-
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 17
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7bc3d55b6bb0..ecfce9adfbbb 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -186,10 +186,14 @@ static const struct {
.min_size = sizeof(struct bdb_edp), },
{ .section_id = BDB_LVDS_OPTIONS,
.min_size = sizeof(struct bdb_lvds_options), },
+ /*
+* BDB_LVDS_LFP_DATA depends on BDB_LVDS_LFP_DATA_PTRS,
+* so keep the two ordered.
+*/
{ .section_id = BDB_LVDS_LFP_DATA_PTRS,
.min_size = sizeof(struct bdb_lvds_lfp_data_ptrs), },
{ .section_id = BDB_LVDS_LFP_DATA,
- .min_size = sizeof(struct bdb_lvds_lfp_data), },
+ .min_size = 0, /* special case */ },
{ .section_id = BDB_LVDS_BACKLIGHT,
.min_size = sizeof(struct bdb_lfp_backlight_data), },
{ .section_id = BDB_LFP_POWER,
@@ -204,6 +208,23 @@ static const struct {
.min_size = sizeof(struct bdb_generic_dtd), },
};
+static size_t lfp_data_min_size(struct drm_i915_private *i915)
+{
+ const struct bdb_lvds_lfp_data_ptrs *ptrs;
+ size_t size;
+
+ ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
+ if (!ptrs)
+ return 0;
+
+ size = sizeof(struct bdb_lvds_lfp_data);
+ if (ptrs->panel_name.table_size)
+ size = max(size, ptrs->panel_name.offset +
+ sizeof(struct bdb_lvds_lfp_data_tail));
+
+ return size;
+}
+
static bool validate_lfp_data_ptrs(const void *bdb,
const struct bdb_lvds_lfp_data_ptrs *ptrs)
{
@@ -491,6 +512,9 @@ static void init_bdb_blocks(struct drm_i915_private *i915,
enum bdb_block_id section_id = bdb_blocks[i].section_id;
size_t min_size = bdb_blocks[i].min_size;
+ if (section_id == BDB_LVDS_LFP_DATA)
+ min_size = lfp_data_min_size(i915);
+
init_bdb_block(i915, bdb, section_id, min_size);
}
}
@@ -561,6 +585,16 @@ get_lvds_fp_timing(const struct bdb_lvds_lfp_data *data,
return (const void *)data + ptrs->ptr[index].fp_timing.offset;
}
+static const struct bdb_lvds_lfp_data_tail *
+get_lfp_data_tail(const struct bdb_lvds_lfp_data *data,
+ const struct bdb_lvds_lfp_data_ptrs *ptrs)
+{
+ if (ptrs->panel_name.table_size)
+ return (const void *)data + ptrs->panel_name.offset;
+ else
+ return NULL;
+}
+
/* Parse general panel options */
static void
parse_panel_options(struct drm_i915_private *i915)
@@ -665,6 +699,7 @@ static void
parse_lfp_data(struct drm_i915_private *i915)
{
const struct bdb_lvds_lfp_data *data;
+ const struct bdb_lvds_lfp_data_tail *tail;
const struct bdb_lvds_lfp_data_ptrs *ptrs;
ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
@@ -677,6 +712,12 @@ parse_lfp_data(struct drm_i915_private *i915)
if (!i915->vbt.lfp_lvds_vbt_mode)
parse_lfp_panel_dtd(i915, data, ptrs);
+
+ tail = get_lfp_data_tail(data, ptrs);
+ if (!tail)
+ return;
+
+ (void)tail;
}
static void
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index e4a11c3e3f3e..2554f4b9b4da 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -783,6 +783,23 @@ struct lvds_lfp_panel_name {
u8 name[13];
} __packed;
+struct lvds_lfp_black_border {
+ u8 top; /* 227 */
+ u8 bottom; /* 227 */
+ u8 left; /* 238 */
+ u8 right; /* 238 */
+} __packed;
+
+struct bdb_lvds_lfp_data_tail {
+ struct lvds_lfp_panel_name panel_name[16]; /* 156-163? */
+ u16 scaling_enable; /* 187 */
+ u8 seamless_drrs_min_refresh_rate[16]; /* 188 */
+ u8 pixel_overlap_count[16]; /* 208 */
+ struct lvds_lfp_black_border black_border[16]; /* 227 */
+ u16 dual_lfp_port_sync_enable; /* 231 */
+ u16 gpu_dithering_for_banding_artifacts; /* 245 */
+} __packed;
+
/*
* Block 43 - LFP Backlight Control Data Block
*/
--
2.35.1
[Intel-gfx] [PATCH v2 2/9] drm/i915/bios: Generate LFP data table pointers if the VBT lacks them
From: Ville Syrjälä
Modern VBTs no longer contain the LFP data table pointers
block (41). We are expecting to have one in order to be able
to parse the LFP data block (42), so let's make one up.
Since the fp_timing table has variable size we must somehow
determine its size. Rather than just hardcode it we look for
the terminator bytes (0x) to figure out where each table
entry starts. dvo_timing, panel_pnp_id, and panel_name are
expected to have fixed size.
This has been observed on various machines, eg. TGL with BDB
version 240, CML with BDB version 231, etc. The most recent
VBT I've observed that still had block 41 had BDB version
228. So presumably the cutoff (if an exact cutoff even exists)
is somewhere around BDB version 229-231.
v2: kfree the thing we allocated, not the thing+3 bytes
v3: Do the debugprint only if we found the LFP data block
v4: Fix t0 null check (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 134 +-
1 file changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 8a1086721525..7bc3d55b6bb0 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -311,16 +311,144 @@ static bool fixup_lfp_data_ptrs(const void *bdb, void
*ptrs_block)
return validate_lfp_data_ptrs(bdb, ptrs);
}
+static const void *find_fp_timing_terminator(const u8 *data, int size)
+{
+ int i;
+
+ for (i = 0; i < size - 1; i++) {
+ if (data[i] == 0xff && data[i+1] == 0xff)
+ return [i];
+ }
+
+ return NULL;
+}
+
+static int make_lfp_data_ptr(struct lvds_lfp_data_ptr_table *table,
+int table_size, int total_size)
+{
+ if (total_size < table_size)
+ return total_size;
+
+ table->table_size = table_size;
+ table->offset = total_size - table_size;
+
+ return total_size - table_size;
+}
+
+static void next_lfp_data_ptr(struct lvds_lfp_data_ptr_table *next,
+ const struct lvds_lfp_data_ptr_table *prev,
+ int size)
+{
+ next->table_size = prev->table_size;
+ next->offset = prev->offset + size;
+}
+
+static void *generate_lfp_data_ptrs(struct drm_i915_private *i915,
+ const void *bdb)
+{
+ int i, size, table_size, block_size, offset;
+ const void *t0, *t1, *block;
+ struct bdb_lvds_lfp_data_ptrs *ptrs;
+ void *ptrs_block;
+
+ block = find_raw_section(bdb, BDB_LVDS_LFP_DATA);
+ if (!block)
+ return NULL;
+
+ drm_dbg_kms(>drm, "Generating LFP data table pointers\n");
+
+ block_size = get_blocksize(block);
+
+ size = block_size;
+ t0 = find_fp_timing_terminator(block, size);
+ if (!t0)
+ return NULL;
+
+ size -= t0 - block - 2;
+ t1 = find_fp_timing_terminator(t0 + 2, size);
+ if (!t1)
+ return NULL;
+
+ size = t1 - t0;
+ if (size * 16 > block_size)
+ return NULL;
+
+ ptrs_block = kzalloc(sizeof(*ptrs) + 3, GFP_KERNEL);
+ if (!ptrs_block)
+ return NULL;
+
+ *(u8 *)(ptrs_block + 0) = BDB_LVDS_LFP_DATA_PTRS;
+ *(u16 *)(ptrs_block + 1) = sizeof(*ptrs);
+ ptrs = ptrs_block + 3;
+
+ table_size = sizeof(struct lvds_pnp_id);
+ size = make_lfp_data_ptr(>ptr[0].panel_pnp_id, table_size, size);
+
+ table_size = sizeof(struct lvds_dvo_timing);
+ size = make_lfp_data_ptr(>ptr[0].dvo_timing, table_size, size);
+
+ table_size = t0 - block + 2;
+ size = make_lfp_data_ptr(>ptr[0].fp_timing, table_size, size);
+
+ if (ptrs->ptr[0].fp_timing.table_size)
+ ptrs->lvds_entries++;
+ if (ptrs->ptr[0].dvo_timing.table_size)
+ ptrs->lvds_entries++;
+ if (ptrs->ptr[0].panel_pnp_id.table_size)
+ ptrs->lvds_entries++;
+
+ if (size != 0 || ptrs->lvds_entries != 3) {
+ kfree(ptrs);
+ return NULL;
+ }
+
+ size = t1 - t0;
+ for (i = 1; i < 16; i++) {
+ next_lfp_data_ptr(>ptr[i].fp_timing,
>ptr[i-1].fp_timing, size);
+ next_lfp_data_ptr(>ptr[i].dvo_timing,
>ptr[i-1].dvo_timing, size);
+ next_lfp_data_ptr(>ptr[i].panel_pnp_id,
>ptr[i-1].panel_pnp_id, size);
+ }
+
+ size = t1 - t0;
+ table_size = sizeof(struct lvds_lfp_panel_name);
+
+ if (16 * (size + table_size) <= block_size) {
+ ptrs->panel_name.table_size = table_size;
+ ptrs->panel_name.offset = size * 16;
+ }
+
+ offset = block - bdb;
+
+ for (i = 0; i < 16; i++) {
+ ptrs->ptr[i].fp_timing.offset += offset;
+ ptrs->ptr[i].dvo_timing.offset += offset;
+
[Intel-gfx] [PATCH v2 1/9] drm/i915/bios: Reorder panel DTD parsing
From: Ville Syrjälä
Reorder things so that we can parse the entier LFP data block
in one go. For now we just stick to parsing the DTD from it.
Also fix the misleading comment about block 42 being deprecated.
Only the DTD part is deprecated, the rest is still very much needed.
v2: Move the version check+comment into parse_generic_dtd() (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 64 ---
1 file changed, 34 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 81949c36ab96..8a1086721525 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -489,25 +489,16 @@ parse_panel_options(struct drm_i915_private *i915)
}
}
-/* Try to find integrated panel timing data */
static void
-parse_lfp_panel_dtd(struct drm_i915_private *i915)
+parse_lfp_panel_dtd(struct drm_i915_private *i915,
+ const struct bdb_lvds_lfp_data *lvds_lfp_data,
+ const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs)
{
- const struct bdb_lvds_lfp_data *lvds_lfp_data;
- const struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
const struct lvds_dvo_timing *panel_dvo_timing;
const struct lvds_fp_timing *fp_timing;
struct drm_display_mode *panel_fixed_mode;
int panel_type = i915->vbt.panel_type;
- lvds_lfp_data = find_section(i915, BDB_LVDS_LFP_DATA);
- if (!lvds_lfp_data)
- return;
-
- lvds_lfp_data_ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
- if (!lvds_lfp_data_ptrs)
- return;
-
panel_dvo_timing = get_lvds_dvo_timing(lvds_lfp_data,
lvds_lfp_data_ptrs,
panel_type);
@@ -538,6 +529,24 @@ parse_lfp_panel_dtd(struct drm_i915_private *i915)
}
}
+static void
+parse_lfp_data(struct drm_i915_private *i915)
+{
+ const struct bdb_lvds_lfp_data *data;
+ const struct bdb_lvds_lfp_data_ptrs *ptrs;
+
+ ptrs = find_section(i915, BDB_LVDS_LFP_DATA_PTRS);
+ if (!ptrs)
+ return;
+
+ data = find_section(i915, BDB_LVDS_LFP_DATA);
+ if (!data)
+ return;
+
+ if (!i915->vbt.lfp_lvds_vbt_mode)
+ parse_lfp_panel_dtd(i915, data, ptrs);
+}
+
static void
parse_generic_dtd(struct drm_i915_private *i915)
{
@@ -546,6 +555,17 @@ parse_generic_dtd(struct drm_i915_private *i915)
struct drm_display_mode *panel_fixed_mode;
int num_dtd;
+ /*
+* Older VBTs provided DTD information for internal displays through
+* the "LFP panel tables" block (42). As of VBT revision 229 the
+* DTD information should be provided via a newer "generic DTD"
+* block (58). Just to be safe, we'll try the new generic DTD block
+* first on VBT >= 229, but still fall back to trying the old LFP
+* block if that fails.
+*/
+ if (i915->vbt.version < 229)
+ return;
+
generic_dtd = find_section(i915, BDB_GENERIC_DTD);
if (!generic_dtd)
return;
@@ -616,23 +636,6 @@ parse_generic_dtd(struct drm_i915_private *i915)
i915->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
}
-static void
-parse_panel_dtd(struct drm_i915_private *i915)
-{
- /*
-* Older VBTs provided provided DTD information for internal displays
-* through the "LFP panel DTD" block (42). As of VBT revision 229,
-* that block is now deprecated and DTD information should be provided
-* via a newer "generic DTD" block (58). Just to be safe, we'll
-* try the new generic DTD block first on VBT >= 229, but still fall
-* back to trying the old LFP block if that fails.
-*/
- if (i915->vbt.version >= 229)
- parse_generic_dtd(i915);
- if (!i915->vbt.lfp_lvds_vbt_mode)
- parse_lfp_panel_dtd(i915);
-}
-
static void
parse_lfp_backlight(struct drm_i915_private *i915)
{
@@ -2709,7 +2712,8 @@ void intel_bios_init(struct drm_i915_private *i915)
parse_general_features(i915);
parse_general_definitions(i915);
parse_panel_options(i915);
- parse_panel_dtd(i915);
+ parse_generic_dtd(i915);
+ parse_lfp_data(i915);
parse_lfp_backlight(i915);
parse_sdvo_panel_data(i915);
parse_driver_features(i915);
--
2.35.1
[Intel-gfx] [PATCH v2 0/9] drm/i915/bios: Rework BDB block handling
From: Ville Syrjälä Here are the easy parts of the previous BDB series, without the PNPID->panel_type bits (the PPS stuff still needs some more thinking). Everything here has been reviewed so should be good to go in if CI is happy. Ville Syrjälä (9): drm/i915/bios: Reorder panel DTD parsing drm/i915/bios: Generate LFP data table pointers if the VBT lacks them drm/i915/bios: Get access to the tail end of the LFP data block drm/i915/bios: Document the mess around the LFP data tables drm/i915/bios: Assume panel_type==0 if the VBT has bogus data drm/i915/bios: Extract get_panel_type() drm/i915/bios: Refactor panel_type code drm/i915/bios: Parse the seamless DRRS min refresh rate drm/i915: Respect VBT seamless DRRS min refresh rate drivers/gpu/drm/i915/display/intel_bios.c | 345 +++--- drivers/gpu/drm/i915/display/intel_panel.c| 10 +- drivers/gpu/drm/i915/display/intel_vbt_defs.h | 24 +- drivers/gpu/drm/i915/i915_drv.h | 1 + 4 files changed, 326 insertions(+), 54 deletions(-) -- 2.35.1
Re: [Intel-gfx] [PATCH] drm/i915: Change semantics of context isolation reporting to UM
On Wed, May 04, 2022 at 02:24:07PM +0200, Daniel Vetter wrote:
> On Fri, 29 Apr 2022 at 17:11, Adrian Larumbe
> wrote:
> > I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
> > both Iris and Vulkan , and stood for the guarantee that, when creating a
> > new context, all state set by it will not leak to any other context.
> >
> > However the actual return value was a bitmask where every bit stood for an
> > initialised engine, and IGT test gem_ctx_isolation makes use of this mask
> > for deciding on the actual context engine isolation status.
> >
> > However, we do not provide UAPI for IGT tests, so the value returned by the
> > PARAM ioctl has to reflect Mesa usage as a boolean.
> >
> > This change only made sense after compute engine support was added to the
> > driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
> > and engine") because no context isolation can be assumed on any device with
> > both RCS annd CCS engines.
> >
> > Signed-off-by: Adrian Larumbe
>
> Top level post and adding Matt Roper and dri-devel.
>
> This was meant as a simple cleanup after CCS enabling in upstream, but
> that CCS enabling seems to have gone wrong.
>
> What I thought we should be done for CCS enabling is the following:
> - actually have some igt-side hardcoded assumption about how much
> engines are isolated from each another, which is a hw property. I
> think some of that landed, but it's very incomplete
>
> - convert all igt tests over to that. At least gem_ctx_isolation.c is
> not converted over, as Adrian pointed out.
I pointed that out last week in one of our offline syncs and that's what
got the ball rolling on that test again. But you specifically told us
that the uapi cleanup for context isolation shouldn't block the CCS
patches from landing since that was still happening in parallel:
"...I do see the uapi cleanup as part of this multi engine/CCS
enabling, but it's not a blocker to land the patches..."
Did we misunderstand what you were trying to say in that email or was
there a change of direction here?
Matt
>
> - once igt stopped using this context isolation getparam (we do not,
> ever, create uapi just for testcases), fix up the uapi to what iris
> actually needs, which is _only_ a boolean which indicates whether the
> kernel's context setup code leaks register state from existing
> contexts to newly created ones. Which is the bug iris works around
> here, where using iris caused gpu hangs in libva. Iow, the kernel
> should always and unconditionally return true here. Check out iris
> history for details please, actual iris usage has nothing to do with
> any other cross-context or cross-engine isolation guarantee we're
> making, it's purely about whether our hw ctx code is buggy or not and
> leaks state between clients, because we accidentally used the
> currently running ctx as template instead of a fixed one created once
> at driver load.
>
> Matt, since the CCS enabling on the igt validation side looks very
> incomplete I'm leaning very much towards "pls revert, try again".
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_user.c | 13 -
> > drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 +
> > drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> > drivers/gpu/drm/i915/i915_getparam.c| 2 +-
> > include/uapi/drm/i915_drm.h | 14 +++---
> > 5 files changed, 18 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 0f6cd96b459f..2d6bd36d6150 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
> > [COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
> > [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
> > [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
> > - /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
> > + [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
> > };
> >
> > static int engine_cmp(void *priv, const struct list_head *A,
> > @@ -306,3 +306,14 @@ unsigned int
> > intel_engines_has_context_isolation(struct drm_i915_private *i915)
> >
> > return which;
> > }
> > +
> > +bool intel_cross_engine_isolated(struct drm_i915_private *i915)
> > +{
> > + unsigned int which = intel_engines_has_context_isolation(i915);
> > +
> > + if ((which & BIT(I915_ENGINE_CLASS_RENDER)) &&
> > + (which & BIT(I915_ENGINE_CLASS_COMPUTE)))
> > + return false;
> > +
> > + return !!which;
> > +}
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.h
> > index 3dc7e8ab9fbc..ff21349db4d4 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.h
> > @@ -15,6
Re: [Intel-gfx] [PATCH 1/1] drm/i915/dmc: Load DMC on DG2
On Tue, May 03, 2022 at 04:57:29PM -0700, Anusha Srivatsa wrote:
> Add Support for DC states on Dg2.
>
> v2: Add dc9 as the max supported DC states and disable DC5.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha Srivatsa
> Reviewed-by: Rodrigo Vivi (v1)
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 1d9bd5808849..022d63cf68dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -907,7 +907,9 @@ static u32 get_allowed_dc_mask(const struct
> drm_i915_private *dev_priv,
> if (!HAS_DISPLAY(dev_priv))
> return 0;
>
> - if (IS_DG1(dev_priv))
> + if (IS_DG2(dev_priv))
> + max_dc = DC_STATE_EN_DC9;
This needs to stay at 0 to disable DC5, while DC9 will be enabled later
in the function.
> + else if (IS_DG1(dev_priv))
> max_dc = 3;
> else if (DISPLAY_VER(dev_priv) >= 12)
> max_dc = 4;
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 257cf662f9f4..2f01aca4d981 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -52,6 +52,10 @@
>
> #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>
> +#define DG2_DMC_PATH DMC_PATH(dg2, 2, 06)
> +#define DG2_DMC_VERSION_REQUIRED DMC_VERSION(2, 06)
> +MODULE_FIRMWARE(DG2_DMC_PATH);
> +
> #define ADLP_DMC_PATHDMC_PATH(adlp, 2, 16)
> #define ADLP_DMC_VERSION_REQUIREDDMC_VERSION(2, 16)
> MODULE_FIRMWARE(ADLP_DMC_PATH);
> @@ -688,7 +692,11 @@ void intel_dmc_ucode_init(struct drm_i915_private
> *dev_priv)
>*/
> intel_dmc_runtime_pm_get(dev_priv);
>
> - if (IS_ALDERLAKE_P(dev_priv)) {
> + if (IS_DG2(dev_priv)) {
> + dmc->fw_path = DG2_DMC_PATH;
> + dmc->required_version = DG2_DMC_VERSION_REQUIRED;
> + dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> + } else if (IS_ALDERLAKE_P(dev_priv)) {
> dmc->fw_path = ADLP_DMC_PATH;
> dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
> dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring
On 25/04/2022 16:23, Ramalingam C wrote:
From: Chris Wilson
Userspace may leave predication enabled upon return from the batch
buffer, which has the consequent of preventing all operation from the
ring from being executed, including all the synchronisation, coherency
control, arbitration and user signaling. This is more than just a local
gpu hang in one client, as the user has the ability to prevent the
kernel from applying critical workarounds and can cause a full GT reset.
We could simply execute MI_SET_PREDICATE upon return from the user
batch, but this has the repercussion of modifying the user's context
state. Instead, we opt to execute a fixup batch which by mixing
predicated operations can determine the state of the
SET_PREDICATE_RESULT register and restore it prior to the next userspace
batch. This allows us to protect the kernel's ring without changing the
uABI.
Suggested-by: Zbigniew Kempczynski
Signed-off-by: Chris Wilson
Cc: Zbigniew Kempczynski
Cc: Thomas Hellstrom
Signed-off-by: Ramalingam C
Applies to Gen12+ so Cc: stable?
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 54 +
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 7 ++
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
.../drm/i915/gt/intel_execlists_submission.c | 15 +++-
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 75 ++-
drivers/gpu/drm/i915/gt/intel_lrc.h | 5 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +
8 files changed, 137 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 9529c5455bc3..3e13960615bd 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -5,6 +5,7 @@
#include "gen8_engine_cs.h"
#include "i915_drv.h"
+#include "intel_engine_regs.h"
#include "intel_gpu_commands.h"
#include "intel_lrc.h"
#include "intel_ring.h"
@@ -385,6 +386,59 @@ int gen8_emit_init_breadcrumb(struct i915_request *rq)
return 0;
}
+static int __gen125_emit_bb_start(struct i915_request *rq,
+ u64 offset, u32 len,
+ const unsigned int flags,
+ u32 arb)
+{
+ struct intel_context *ce = rq->context;
+ u32 wa_offset = lrc_indirect_bb(ce);
+ u32 *cs;
+
+ cs = intel_ring_begin(rq, 12);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ *cs++ = MI_ARB_ON_OFF | arb;
+
+ *cs++ = MI_LOAD_REGISTER_MEM_GEN8 |
+ MI_SRM_LRM_GLOBAL_GTT |
+ MI_LRI_LRM_CS_MMIO;
+ *cs++ = i915_mmio_reg_offset(RING_PREDICATE_RESULT(0));
+ *cs++ = wa_offset + DG2_PREDICATE_RESULT_WA;
+ *cs++ = 0;
+
+ *cs++ = MI_BATCH_BUFFER_START_GEN8 |
+ (flags & I915_DISPATCH_SECURE ? 0 : BIT(8));
+ *cs++ = lower_32_bits(offset);
+ *cs++ = upper_32_bits(offset);
+
+ /* Fixup stray MI_SET_PREDICATE as it prevents us executing the ring */
+ *cs++ = MI_BATCH_BUFFER_START_GEN8;
+ *cs++ = wa_offset + DG2_PREDICATE_RESULT_BB;
+ *cs++ = 0;
+
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
+ intel_ring_advance(rq, cs);
+
+ return 0;
+}
+
+int gen125_emit_bb_start_noarb(struct i915_request *rq,
+ u64 offset, u32 len,
+ const unsigned int flags)
+{
+ return __gen125_emit_bb_start(rq, offset, len, flags, MI_ARB_DISABLE);
+}
+
+int gen125_emit_bb_start(struct i915_request *rq,
+u64 offset, u32 len,
+const unsigned int flags)
+{
+ return __gen125_emit_bb_start(rq, offset, len, flags, MI_ARB_ENABLE);
+}
+
int gen8_emit_bb_start_noarb(struct i915_request *rq,
u64 offset, u32 len,
const unsigned int flags)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
index 107ab42539ab..32e3d2b831bb 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.h
@@ -31,6 +31,13 @@ int gen8_emit_bb_start(struct i915_request *rq,
u64 offset, u32 len,
const unsigned int flags);
+int gen125_emit_bb_start_noarb(struct i915_request *rq,
+ u64 offset, u32 len,
+ const unsigned int flags);
+int gen125_emit_bb_start(struct i915_request *rq,
+u64 offset, u32 len,
+const unsigned int flags);
+
u32 *gen8_emit_fini_breadcrumb_xcs(struct i915_request *rq, u32 *cs);
u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request *rq, u32 *cs);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config
== Series Details ==
Series: series starting with [1/2] drm/i915: Don't use DRM_DEBUG_WARN_ON for
unexpected l3bank/mslice config
URL : https://patchwork.freedesktop.org/series/103536/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11602 -> Patchwork_103536v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/index.html
Participating hosts (33 -> 43)
--
Additional (11): fi-rkl-11600 bat-dg1-6 bat-dg2-8 bat-adlm-1 fi-icl-u2
bat-adlp-6 bat-adln-1 bat-rpls-1 bat-rpls-2 bat-jsl-2 bat-jsl-1
Missing(1): fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103536v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_contexts:
- {bat-adlm-1}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-adlm-1/igt@i915_selftest@live@gt_contexts.html
Known issues
Here are the changes found in Patchwork_103536v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_mmap@basic:
- bat-dg1-6: NOTRUN -> [SKIP][6] ([i915#4083])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4077]) +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#4079]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@gem_tiled_pread_basic.html
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#3282])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#3012])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
- bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#1155])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][12] ([i915#4418])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#4212]) +7 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@kms_addfb_ba...@addfb25-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#4215])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#111827]) +8 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-edid-read:
- bat-dg1-6: NOTRUN -> [SKIP][17] ([fdo#111827]) +7 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103536v1/bat-dg1-6/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: NOTRUN -> [SKIP][18] ([fdo#111827]) +8 similar issues
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix race in __i915_vma_remove_closed (rev4)
== Series Details ==
Series: drm/i915: Fix race in __i915_vma_remove_closed (rev4)
URL : https://patchwork.freedesktop.org/series/102845/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11597_full -> Patchwork_102845v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102845v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102845v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102845v4_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_persistence@engines-hostile@vecs0:
- shard-apl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-apl8/igt@gem_ctx_persistence@engines-host...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-apl4/igt@gem_ctx_persistence@engines-host...@vecs0.html
* {igt@kms_concurrent@pipe-a@hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [CRASH][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-dg1-18/igt@kms_concurrent@pip...@hdmi-a-3.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@cursor-dpms:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-rkl-5/igt@i915_pm_...@cursor-dpms.html
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-dg1-18/igt@i915_pm_...@system-suspend-devices.html
* igt@i915_selftest@live@hangcheck:
- {shard-rkl}:NOTRUN -> [DMESG-FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-rkl-5/igt@i915_selftest@l...@hangcheck.html
New tests
-
New tests have been introduced between CI_DRM_11597_full and
Patchwork_102845v4_full:
### New IGT tests (1) ###
* igt@kms_concurrent@pipe-a@hdmi-a-3:
- Statuses : 1 crash(s)
- Exec time: [0.03] s
Known issues
Here are the changes found in Patchwork_102845v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@unwedge-stress:
- shard-skl: [PASS][7] -> [TIMEOUT][8] ([i915#3063])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-skl6/igt@gem_...@unwedge-stress.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-skl1/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-kbl3/igt@gem_exec_fair@basic-none-...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-kbl1/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-tglb6/igt@gem_exec_fair@basic-p...@bcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-tglb5/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_flink_race@flink_close:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#5687])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-iclb2/igt@gem_flink_race@flink_close.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-iclb5/igt@gem_flink_race@flink_close.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][18] -> [SKIP][19] ([i915#2190])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-tglb2/igt@gem_huc_c...@huc-copy.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102845v4/shard-tglb7/igt@gem_huc_c...@huc-copy.html
*
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: use IOMEM_ERR_PTR() directly
== Series Details ==
Series: drm/i915: use IOMEM_ERR_PTR() directly
URL : https://patchwork.freedesktop.org/series/103485/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11597_full -> Patchwork_103485v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103485v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-dg1-15/igt@i915_pm_...@system-suspend-devices.html
Known issues
Here are the changes found in Patchwork_103485v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-glk2/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglb: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-tglb6/igt@gem_exec_fair@basic-p...@bcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-tglb1/igt@gem_exec_fair@basic-p...@bcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-kbl4/igt@gem_exec_fair@basic-p...@vecs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-kbl1/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-uc-set-default:
- shard-snb: [PASS][11] -> [SKIP][12] ([fdo#109271]) +2 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11597/shard-snb4/igt@gem_exec_fl...@basic-uc-set-default.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-snb6/igt@gem_exec_fl...@basic-uc-set-default.html
* igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-iclb6/igt@gem_exec_par...@secure-non-root.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-kbl6/igt@gem_lmem_swapp...@heavy-multi.html
* igt@gem_lmem_swapping@heavy-random:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-apl7/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#4613])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-iclb5/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_pwrite@basic-exhaustion:
- shard-apl: NOTRUN -> [WARN][17] ([i915#2658])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-apl7/igt@gem_pwr...@basic-exhaustion.html
* igt@gem_pxp@create-regular-context-1:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-iclb5/igt@gem_...@create-regular-context-1.html
* igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#768])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103485v1/shard-iclb5/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html
* igt@gen9_exec_parse@basic-rejected:
- shard-iclb: NOTRUN -> [SKIP][20] ([i915#2856]) +1 similar issue
[20]:
[Intel-gfx] [PATCH v2 10/26] drm/i915: Extract intel_crtc_dotclock()
From: Ville Syrjälä
Extract intel_crtc_dotclock() from ddi_dotclock_get(). We'll reuse
this during state computation in order to determine the actual final
dotclcok after the DPLL computation has been done (which may not give
us the exact same port_clock that we fed in).
v2: Add the prototype
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 --
drivers/gpu/drm/i915/display/intel_display.h | 1 +
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9e6fa59eabba..0cf2d4fba6a8 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -322,14 +322,10 @@ static int icl_calc_tbt_pll_link(struct drm_i915_private
*dev_priv,
}
}
-static void ddi_dotclock_get(struct intel_crtc_state *pipe_config)
+int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config)
{
int dotclock;
- /* CRT dotclock is determined via other means */
- if (pipe_config->has_pch_encoder)
- return;
-
if (intel_crtc_has_dp_encoder(pipe_config))
dotclock = intel_dotclock_calculate(pipe_config->port_clock,
_config->dp_m_n);
@@ -345,7 +341,17 @@ static void ddi_dotclock_get(struct intel_crtc_state
*pipe_config)
if (pipe_config->pixel_multiplier)
dotclock /= pipe_config->pixel_multiplier;
- pipe_config->hw.adjusted_mode.crtc_clock = dotclock;
+ return dotclock;
+}
+
+static void ddi_dotclock_get(struct intel_crtc_state *pipe_config)
+{
+ /* CRT dotclock is determined via other means */
+ if (pipe_config->has_pch_encoder)
+ return;
+
+ pipe_config->hw.adjusted_mode.crtc_clock =
+ intel_crtc_dotclock(pipe_config);
}
void intel_ddi_set_dp_msa(const struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 187910d94ec6..7af6b5a413dc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -635,6 +635,7 @@ void intel_cpu_transcoder_get_m2_n2(struct intel_crtc *crtc,
void i9xx_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
+int intel_crtc_dotclock(const struct intel_crtc_state *pipe_config);
enum intel_display_power_domain intel_port_to_power_domain(struct
intel_digital_port *dig_port);
enum intel_display_power_domain
intel_aux_power_domain(struct intel_digital_port *dig_port);
--
2.35.1
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/fbdev: print error in case drm_fb_helper_initial_config fails
== Series Details ==
Series: series starting with [1/2] drm/i915/fbdev: print error in case
drm_fb_helper_initial_config fails
URL : https://patchwork.freedesktop.org/series/103533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11601 -> Patchwork_103533v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/index.html
Participating hosts (44 -> 42)
--
Additional (2): bat-adlm-1 bat-dg1-5
Missing(4): bat-jsl-2 fi-bsw-cyan fi-rkl-11600 fi-icl-u2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103533v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: NOTRUN -> [WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-rpls-2/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_103533v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@fb...@write.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4083])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#1155])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: NOTRUN -> [INCOMPLETE][7] ([i915#4418])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][8] ([i915#3921])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4215])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4212]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4303])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- bat-dg1-5: NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-dpms:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4078]) +23 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [PASS][15] -> [DMESG-WARN][16] ([i915#3576])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11601/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([fdo#109285])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103533v1/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#1072] / [i915#4078]) +3
similar issues
Re: [Intel-gfx] [PATCH] drm/i915: Change semantics of context isolation reporting to UM
On Fri, 29 Apr 2022 at 17:11, Adrian Larumbe
wrote:
> I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
> both Iris and Vulkan , and stood for the guarantee that, when creating a
> new context, all state set by it will not leak to any other context.
>
> However the actual return value was a bitmask where every bit stood for an
> initialised engine, and IGT test gem_ctx_isolation makes use of this mask
> for deciding on the actual context engine isolation status.
>
> However, we do not provide UAPI for IGT tests, so the value returned by the
> PARAM ioctl has to reflect Mesa usage as a boolean.
>
> This change only made sense after compute engine support was added to the
> driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
> and engine") because no context isolation can be assumed on any device with
> both RCS annd CCS engines.
>
> Signed-off-by: Adrian Larumbe
Top level post and adding Matt Roper and dri-devel.
This was meant as a simple cleanup after CCS enabling in upstream, but
that CCS enabling seems to have gone wrong.
What I thought we should be done for CCS enabling is the following:
- actually have some igt-side hardcoded assumption about how much
engines are isolated from each another, which is a hw property. I
think some of that landed, but it's very incomplete
- convert all igt tests over to that. At least gem_ctx_isolation.c is
not converted over, as Adrian pointed out.
- once igt stopped using this context isolation getparam (we do not,
ever, create uapi just for testcases), fix up the uapi to what iris
actually needs, which is _only_ a boolean which indicates whether the
kernel's context setup code leaks register state from existing
contexts to newly created ones. Which is the bug iris works around
here, where using iris caused gpu hangs in libva. Iow, the kernel
should always and unconditionally return true here. Check out iris
history for details please, actual iris usage has nothing to do with
any other cross-context or cross-engine isolation guarantee we're
making, it's purely about whether our hw ctx code is buggy or not and
leaks state between clients, because we accidentally used the
currently running ctx as template instead of a fixed one created once
at driver load.
Matt, since the CCS enabling on the igt validation side looks very
incomplete I'm leaning very much towards "pls revert, try again".
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 13 -
> drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 +
> drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> drivers/gpu/drm/i915/i915_getparam.c| 2 +-
> include/uapi/drm/i915_drm.h | 14 +++---
> 5 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 0f6cd96b459f..2d6bd36d6150 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
> [COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
> [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
> [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
> - /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
> + [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
> };
>
> static int engine_cmp(void *priv, const struct list_head *A,
> @@ -306,3 +306,14 @@ unsigned int intel_engines_has_context_isolation(struct
> drm_i915_private *i915)
>
> return which;
> }
> +
> +bool intel_cross_engine_isolated(struct drm_i915_private *i915)
> +{
> + unsigned int which = intel_engines_has_context_isolation(i915);
> +
> + if ((which & BIT(I915_ENGINE_CLASS_RENDER)) &&
> + (which & BIT(I915_ENGINE_CLASS_COMPUTE)))
> + return false;
> +
> + return !!which;
> +}
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.h
> b/drivers/gpu/drm/i915/gt/intel_engine_user.h
> index 3dc7e8ab9fbc..ff21349db4d4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.h
> @@ -15,6 +15,7 @@ struct intel_engine_cs *
> intel_engine_lookup_user(struct drm_i915_private *i915, u8 class, u8
> instance);
>
> unsigned int intel_engines_has_context_isolation(struct drm_i915_private
> *i915);
> +bool intel_cross_engine_isolated(struct drm_i915_private *i915);
>
> void intel_engine_add_user(struct intel_engine_cs *engine);
> void intel_engines_driver_register(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> b/drivers/gpu/drm/i915/i915_drm_client.h
> index 5f5b02b01ba0..f796c5e8e060 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.h
> +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> @@ -13,7 +13,7 @@
>
> #include "gt/intel_engine_types.h"
>
> -#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE
Re: [Intel-gfx] [PATCH] drm/i915: use IOMEM_ERR_PTR() directly
On 02/05/2022 09:30, Jani Nikula wrote:
On Mon, 02 May 2022, Kefeng Wang wrote:
Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR().
Signed-off-by: Kefeng Wang
Reviewed-by: Jani Nikula
Pushed to drm-intel-gt-next, thanks for the patch and review!
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_vma.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.h | 1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 94fcdb7bd21d..639605c89b7b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -541,7 +541,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
int err;
if (WARN_ON_ONCE(vma->obj->flags & I915_BO_ALLOC_GPU_ONLY))
- return IO_ERR_PTR(-EINVAL);
+ return IOMEM_ERR_PTR(-EINVAL);
if (!i915_gem_object_is_lmem(vma->obj)) {
if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
@@ -594,7 +594,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
err_unpin:
__i915_vma_unpin(vma);
err:
- return IO_ERR_PTR(err);
+ return IOMEM_ERR_PTR(err);
}
void i915_vma_flush_writes(struct i915_vma *vma)
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 67ae7341c7e0..8e74972fdca3 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -331,7 +331,6 @@ static inline bool i915_node_color_differs(const struct
drm_mm_node *node,
* Returns a valid iomapped pointer or ERR_PTR.
*/
void __iomem *i915_vma_pin_iomap(struct i915_vma *vma);
-#define IO_ERR_PTR(x) ((void __iomem *)ERR_PTR(x))
/**
* i915_vma_unpin_iomap - unpins the mapping returned from i915_vma_iomap
[Intel-gfx] [PATCH 2/2] drm/i915: Don't use DRM_DEBUG_WARN_ON for ring unexpectedly not idle
From: Tvrtko Ursulin DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed to exercise a certain code path, so in case of values coming from MMIO reads we cannot be sure CI will have all the possible SKUs and parts, or that it will catch all possible error conditions. Use drm_warn instead. Signed-off-by: Tvrtko Ursulin Cc: Mika Kuoppala Cc: Jani Nikula --- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c b/drivers/gpu/drm/i915/gt/intel_ring_submission.c index 5423bfd301ad..f8f279a195c0 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c @@ -117,7 +117,9 @@ static void flush_cs_tlb(struct intel_engine_cs *engine) return; /* ring should be idle before issuing a sync flush*/ - GEM_DEBUG_WARN_ON((ENGINE_READ(engine, RING_MI_MODE) & MODE_IDLE) == 0); + if ((ENGINE_READ(engine, RING_MI_MODE) & MODE_IDLE) == 0) + drm_warn(>i915->drm, "%s not idle before sync flush!\n", +engine->name); ENGINE_WRITE_FW(engine, RING_INSTPM, _MASKED_BIT_ENABLE(INSTPM_TLB_INVALIDATE | -- 2.32.0
[Intel-gfx] [PATCH 1/2] drm/i915: Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config
From: Tvrtko Ursulin
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed
to exercise a certain code path, so in case of values coming from MMIO
reads we cannot be sure CI will have all the possible SKUs and parts.
Use drm_warn instead and move logging to init phase while at it.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
Cc: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_gt.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 53307ca0eed0..c474e5c3ea5e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -153,11 +153,14 @@ int intel_gt_init_mmio(struct intel_gt *gt)
* An mslice is unavailable only if both the meml3 for the slice is
* disabled *and* all of the DSS in the slice (quadrant) are disabled.
*/
- if (HAS_MSLICES(i915))
+ if (HAS_MSLICES(i915)) {
gt->info.mslice_mask =
slicemask(gt, GEN_DSS_PER_MSLICE) |
(intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) &
GEN12_MEML3_EN_MASK);
+ if (!gt->info.mslice_mask) /* should be impossible! */
+ drm_warn(>drm, "mslice mask all zero!\n");
+ }
if (IS_DG2(i915)) {
gt->steering_table[MSLICE] = xehpsdv_mslice_steering_table;
@@ -171,6 +174,8 @@ int intel_gt_init_mmio(struct intel_gt *gt)
gt->info.l3bank_mask =
~intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) &
GEN10_L3BANK_MASK;
+ if (!gt->info.l3bank_mask) /* should be impossible! */
+ drm_warn(>drm, "L3 bank mask is all zero!\n");
} else if (HAS_MSLICES(i915)) {
MISSING_CASE(INTEL_INFO(i915)->platform);
}
@@ -882,20 +887,14 @@ static void intel_gt_get_valid_steering(struct intel_gt
*gt,
{
switch (type) {
case L3BANK:
- GEM_DEBUG_WARN_ON(!gt->info.l3bank_mask); /* should be
impossible! */
-
*sliceid = 0; /* unused */
*subsliceid = __ffs(gt->info.l3bank_mask);
break;
case MSLICE:
- GEM_DEBUG_WARN_ON(!gt->info.mslice_mask); /* should be
impossible! */
-
*sliceid = __ffs(gt->info.mslice_mask);
*subsliceid = 0;/* unused */
break;
case LNCF:
- GEM_DEBUG_WARN_ON(!gt->info.mslice_mask); /* should be
impossible! */
-
/*
* An LNCF is always present if its mslice is present, so we
* can safely just steer to LNCF 0 in all cases.
--
2.32.0
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/fbdev: print error in case drm_fb_helper_initial_config fails
== Series Details ==
Series: series starting with [1/2] drm/i915/fbdev: print error in case
drm_fb_helper_initial_config fails
URL : https://patchwork.freedesktop.org/series/103533/
State : warning
== Summary ==
Error: dim checkpatch failed
049b4153799b drm/i915/fbdev: print error in case drm_fb_helper_initial_config
fails
1f84c1806ac0 tty/vt: add some logging to vt error path
-:19: WARNING:LONG_LINE: line length of 119 exceeds 100 columns
#19: FILE: drivers/tty/vt/vt.c:3630:
+#define ERR(__err) ({ void *err = ERR_PTR(__err); pr_err("%s:%d: err=%pe\n",
__func__, __LINE__, err); PTR_ERR(err); })
total: 0 errors, 1 warnings, 0 checks, 56 lines checked
Re: [Intel-gfx] [PATCH] drm/i915: Change semantics of context isolation reporting to UM
Hi, Tvrtko
On 03.05.2022 15:44, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 29/04/2022 16:11, Adrian Larumbe wrote:
> > I915_PARAM_HAS_CONTEXT_ISOLATION was already being used as a boolean by
> > both Iris and Vulkan , and stood for the guarantee that, when creating a
> > new context, all state set by it will not leak to any other context.
> >
> > However the actual return value was a bitmask where every bit stood for an
> > initialised engine, and IGT test gem_ctx_isolation makes use of this mask
> > for deciding on the actual context engine isolation status.
> >
> > However, we do not provide UAPI for IGT tests, so the value returned by the
> > PARAM ioctl has to reflect Mesa usage as a boolean.
>
> a)
> I suggest splitting into two patches. One changes the semantics to boolean,
> second one changes it for RCS+CCS.
>
> b)
> What about test coverage - both for platforms with RCS+CSS (media and blitter
> stop being tested - all coverage is gone basically) and also for pre Gen8
> platforms, are there failures expected there? (Test will try to run on some
> engines which do not support isolation now, no?)
Do you mean IGT tests? I think gem_ctx_isolation.c has to be rewritten so that
the engine isolation status of the different devices is somehow hard-coded
into the test, perhaps something like the intel_device_info struct in the
kernel.
> This change only made sense after compute engine support was added to the
> driver in commit 944823c9463916dd53f3 ("drm/i915/xehp: Define compute class
> and engine") because no context isolation can be assumed on any device with
> both RCS annd CCS engines.
>Isn't it an arbitrary decision when thinking about other engine classes
>(media, blitter) on those platforms? Commit message should be clear in that
>respect.
I think the change was required because the addition of a CCS engine broke
pre-existing assumptions about engine context isolation, but only when
coexisting with an RCS engine in the same device. I wouldn't know about other
engines, but I'll ask around.
> Also, looking at iris:
>
>if (iris_getparam_integer(fd, I915_PARAM_HAS_CONTEXT_ISOLATION) <= 0) {
> debug_error("Kernel is too old for Iris. Consider upgrading to kernel
> v4.16.\n");
> return NULL;
>}
>
> Won't this make Iris fail on RCS+CCS platforms - or I need to look at a newer
> branch/pull request? What is the plan there?
Yes, I think I misread this code and didn't realise, when there isn't context
isolation, this snippet will fail. However, given the semantics of it, which I
glean from the error message between the brackets, I'd say context isolation not
being present shouldn't cause it to fail. So I guess it could be rewritten as
if (iris_getparam_integer(fd, I915_PARAM_HAS_CONTEXT_ISOLATION) < 0) {
> Signed-off-by: Adrian Larumbe
> ---
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 13 -
> drivers/gpu/drm/i915/gt/intel_engine_user.h | 1 +
> drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> drivers/gpu/drm/i915/i915_getparam.c| 2 +-
> include/uapi/drm/i915_drm.h | 14 +++---
> 5 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 0f6cd96b459f..2d6bd36d6150 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
> [COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
> [VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
> [VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
> - /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
> + [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
> > I think this landed so you will need to rebase.
>
> > };
> > static int engine_cmp(void *priv, const struct list_head *A,
> > @@ -306,3 +306,14 @@ unsigned int
> > intel_engines_has_context_isolation(struct drm_i915_private *i915)
> > return which;
> > }
> > +
> > +bool intel_cross_engine_isolated(struct drm_i915_private *i915)
>
> Naming feels lackluster (Intel what?). Do you expect other callers or could
> just implement the check in i915_getparam.c, inside the switch statement?
No other callers, so I guess I should do like you suggested below, handle the
logic straightaway from i915_getparam_ioctl.
> +{
> + unsigned int which = intel_engines_has_context_isolation(i915);
> +
> + if ((which & BIT(I915_ENGINE_CLASS_RENDER)) &&
> + (which & BIT(I915_ENGINE_CLASS_COMPUTE)))
> + return false;
> +
> + return !!which;
> You could first just check if there are any RCS and CCS engines (for instance
> i915->engine_uabi_class_count[], or RCS/CCS_MASK()).
>
> /* Comment here to explain the decision. */
> if (RCS_MASK(>gt) | CCS_MASK(>gt))
> value = 0;
> else
> value = !!intel_engines_has_context_isolation(i915);
[Intel-gfx] [PATCH 1/2] drm/i915/fbdev: print error in case drm_fb_helper_initial_config fails
On some configurations drm_fb_helper_initial_config sometimes fails.
Logging error value should help debugging such issues.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..557c7f15ac22a9 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -539,11 +539,16 @@ int intel_fbdev_init(struct drm_device *dev)
static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)
{
struct intel_fbdev *ifbdev = data;
+ int ret;
/* Due to peculiar init order wrt to hpd handling this is separate. */
- if (drm_fb_helper_initial_config(>helper,
-ifbdev->preferred_bpp))
- intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
+ ret = drm_fb_helper_initial_config(>helper,
+ ifbdev->preferred_bpp);
+ if (!ret)
+ return;
+ drm_err(ifbdev->helper.dev, "failed to set initial configuration:
%pe\n",
+ ERR_PTR(ret));
+ intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
}
void intel_fbdev_initial_config_async(struct drm_device *dev)
--
2.25.1
[Intel-gfx] [PATCH 2/2] [DO NOT MERGE] tty/vt: add some logging to vt error path
Intel CI contains machine which permanently fails with
fb initialization with crashes. Add extra logs to debug the issue.
Signed-off-by: Andrzej Hajda
---
drivers/tty/vt/vt.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f8c87c4d739955..430d9639d9fd20 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3627,6 +3627,8 @@ int __init vty_init(const struct file_operations
*console_fops)
static struct class *vtconsole_class;
+#define ERR(__err) ({ void *err = ERR_PTR(__err); pr_err("%s:%d: err=%pe\n",
__func__, __LINE__, err); PTR_ERR(err); })
+
static int do_bind_con_driver(const struct consw *csw, int first, int last,
int deflt)
{
@@ -3636,7 +3638,7 @@ static int do_bind_con_driver(const struct consw *csw,
int first, int last,
int i, j = -1, k = -1, retval = -ENODEV;
if (!try_module_get(owner))
- return -ENODEV;
+ return ERR(-ENODEV);
WARN_CONSOLE_UNLOCKED();
@@ -3651,7 +3653,7 @@ static int do_bind_con_driver(const struct consw *csw,
int first, int last,
}
}
- if (retval)
+ if (retval && ERR(retval))
goto err;
if (!(con_driver->flag & CON_DRIVER_FLAG_INIT)) {
@@ -4111,21 +4113,21 @@ static int do_register_con_driver(const struct consw
*csw, int first, int last)
WARN_CONSOLE_UNLOCKED();
if (!try_module_get(owner))
- return -ENODEV;
+ return ERR(-ENODEV);
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
con_driver = _con_driver[i];
/* already registered */
if (con_driver->con == csw) {
- retval = -EBUSY;
+ retval = ERR(-EBUSY);
goto err;
}
}
desc = csw->con_startup();
if (!desc) {
- retval = -ENODEV;
+ retval = ERR(-ENODEV);
goto err;
}
@@ -4148,7 +4150,7 @@ static int do_register_con_driver(const struct consw
*csw, int first, int last)
}
}
- if (retval)
+ if (retval && ERR(retval))
goto err;
con_driver->dev =
--
2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/bios: add helper for reading SPI
== Series Details ==
Series: drm/i915/bios: add helper for reading SPI
URL : https://patchwork.freedesktop.org/series/103480/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11595_full -> Patchwork_103480v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103480v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103480v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103480v1_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-snb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-snb5/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_flink_race@flink_close:
- {shard-tglu}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-tglu-3/igt@gem_flink_race@flink_close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-tglu-2/igt@gem_flink_race@flink_close.html
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-dg1-15/igt@i915_pm_...@system-suspend-devices.html
* igt@kms_cursor_legacy@all-pipes-torture-move:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-rkl-5/igt@kms_cursor_leg...@all-pipes-torture-move.html
Known issues
Here are the changes found in Patchwork_103480v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][7] -> [SKIP][8] ([i915#658])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-iclb2/igt@feature_discov...@psr2.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-iclb4/igt@feature_discov...@psr2.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-kbl3/igt@gem_exec_fair@basic-n...@vcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-glk4/igt@gem_exec_fair@basic-n...@vcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-glk8/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-tglb5/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-uc-set-default:
- shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-snb4/igt@gem_exec_fl...@basic-uc-set-default.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-snb6/igt@gem_exec_fl...@basic-uc-set-default.html
* igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#112283])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-iclb8/igt@gem_exec_par...@secure-non-root.html
* igt@gem_lmem_swapping@basic:
- shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103480v1/shard-skl9/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@heavy-random:
- shard-iclb: NOTRUN -> [SKIP][21]
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: CEA data block iterators, and more (rev3)
== Series Details ==
Series: drm/edid: CEA data block iterators, and more (rev3)
URL : https://patchwork.freedesktop.org/series/102703/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11595_full -> Patchwork_102703v3_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102703v3_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102703v3_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102703v3_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_heartbeat:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-skl7/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-skl1/igt@i915_selftest@live@gt_heartbeat.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_flink_race@flink_close:
- {shard-tglu}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-tglu-3/igt@gem_flink_race@flink_close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-tglu-3/igt@gem_flink_race@flink_close.html
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-dg1-17/igt@i915_pm_...@system-suspend-devices.html
Known issues
Here are the changes found in Patchwork_102703v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][6] -> [SKIP][7] ([i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-iclb2/igt@feature_discov...@psr2.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-iclb3/igt@feature_discov...@psr2.html
* igt@gem_eio@in-flight-contexts-1us:
- shard-tglb: [PASS][8] -> [TIMEOUT][9] ([i915#3063])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-tglb8/igt@gem_...@in-flight-contexts-1us.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-tglb7/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-iclb6/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-glk4/igt@gem_exec_fair@basic-n...@vcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-glk9/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][14] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-kbl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-tglb7/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_flush@basic-wb-rw-before-default:
- shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271]) +1 similar
issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-snb2/igt@gem_exec_fl...@basic-wb-rw-before-default.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-snb6/igt@gem_exec_fl...@basic-wb-rw-before-default.html
* igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][19] ([fdo#112283])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-iclb5/igt@gem_exec_par...@secure-non-root.html
* igt@gem_lmem_swapping@basic:
- shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102703v3/shard-skl4/igt@gem_lmem_swapp...@basic.html
*
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: warn about missing ->get_buf_trans initialization
== Series Details ==
Series: drm/i915: warn about missing ->get_buf_trans initialization
URL : https://patchwork.freedesktop.org/series/103473/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11595_full -> Patchwork_103473v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103473v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103473v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103473v1_full:
### IGT changes ###
Possible regressions
* {igt@kms_concurrent@pipe-a@hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [CRASH][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-dg1-18/igt@kms_concurrent@pip...@hdmi-a-3.html
* igt@perf@stress-open-close:
- shard-skl: [PASS][2] -> [INCOMPLETE][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-skl9/igt@p...@stress-open-close.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-skl10/igt@p...@stress-open-close.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s0@smem:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-dg1-12/igt@gem_exec_suspend@basic...@smem.html
New tests
-
New tests have been introduced between CI_DRM_11595_full and
Patchwork_103473v1_full:
### New IGT tests (1) ###
* igt@kms_concurrent@pipe-a@hdmi-a-3:
- Statuses : 1 crash(s)
- Exec time: [0.03] s
Known issues
Here are the changes found in Patchwork_103473v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#658])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-iclb2/igt@feature_discov...@psr2.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-iclb5/igt@feature_discov...@psr2.html
* igt@gem_eio@unwedge-stress:
- shard-iclb: [PASS][7] -> [TIMEOUT][8] ([i915#3070])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-iclb1/igt@gem_...@unwedge-stress.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-iclb1/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-kbl1/igt@gem_exec_fair@basic-p...@vcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11595/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-tglb8/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_exec_params@secure-non-root:
- shard-iclb: NOTRUN -> [SKIP][13] ([fdo#112283])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-iclb5/igt@gem_exec_par...@secure-non-root.html
* igt@gem_lmem_swapping@basic:
- shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-skl9/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-verify:
- shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +2
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-kbl4/igt@gem_lmem_swapp...@parallel-random-verify.html
* igt@gem_lmem_swapping@smem-oom:
- shard-iclb: NOTRUN -> [SKIP][16] ([i915#4613])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-iclb7/igt@gem_lmem_swapp...@smem-oom.html
* igt@gem_render_copy@x-tiled-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][17] ([i915#768])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103473v1/shard-iclb7/igt@gem_render_c...@x-tiled-to-vebox-y-tiled.html
* igt@gen7_exec_parse@bitmasks:
- shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109289]) +1 similar issue
[18]:
Re: [Intel-gfx] [PATCH 0/3] i915 private writeback framework
On Wed, May 04, 2022 at 09:52:34AM +, Kandpal, Suraj wrote: > Hi Daniel, > > > > A patch series was floated in the drm mailing list which aimed to > > > change the drm_connector and drm_encoder fields to pointer in the > > > drm_connector_writeback structure, this received a huge pushback from > > > the community but since i915 expects each connector present in the > > > drm_device list to be a intel_connector but drm_writeback framework. > > > [1] > > > https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22 > > > 119-1-suraj.kand...@intel.com/ [2] > > > https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22 > > > 261-6-suraj.kand...@intel.com/ This forces us to use a drm_connector > > > which is not embedded in intel_connector the current drm_writeback > > > framework becomes very unfeasible to us as it would mean a lot of > > > checks at a lot of places to take into account the above issue.Since > > > no one had an issue with encoder field being changed into a pointer it > > > was decided to break the connector and encoder pointer changes into > > > two different series.The encoder field changes is currently being > > > worked upon by Abhinav Kumar > > > [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 > > > In the meantime for i915 to start using the writeback functionality we > > > came up with a interim solution to own writeback pipeline bypassing > > > one provided by drm which is what these patches do. > > > Note: these are temp patches till we figure out how we can either > > > change drm core writeback to work with our intel_connector structure > > > or find a different solution which allows us to work with the current > > > > I'm assuming this is just fyi to keep development moving and not being > > planned for merging? > Yes we do plan to get it merged as a proper implementation that uses drm-core > will require significant time and to unblock the writeback functionality > these interim > series of patches have been floated. No, I really don't think merging some interim hack is the way to go. It's not display, but on the gem side there was this huge exception about "hey we need to merge guc scheduler and it's totally ready but it's not done properly like it should have been for upstream". And surprise it wasn't ready and took a year just to get the hack job complete, and now no one seems to be working on doing things properly. So I'm not eager at all to ack more hack jobs for i915. Do it right before merging to upstream please. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 0/3] i915 private writeback framework
Hi Daniel, > > A patch series was floated in the drm mailing list which aimed to > > change the drm_connector and drm_encoder fields to pointer in the > > drm_connector_writeback structure, this received a huge pushback from > > the community but since i915 expects each connector present in the > > drm_device list to be a intel_connector but drm_writeback framework. > > [1] > > https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22 > > 119-1-suraj.kand...@intel.com/ [2] > > https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22 > > 261-6-suraj.kand...@intel.com/ This forces us to use a drm_connector > > which is not embedded in intel_connector the current drm_writeback > > framework becomes very unfeasible to us as it would mean a lot of > > checks at a lot of places to take into account the above issue.Since > > no one had an issue with encoder field being changed into a pointer it > > was decided to break the connector and encoder pointer changes into > > two different series.The encoder field changes is currently being > > worked upon by Abhinav Kumar > > [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 > > In the meantime for i915 to start using the writeback functionality we > > came up with a interim solution to own writeback pipeline bypassing > > one provided by drm which is what these patches do. > > Note: these are temp patches till we figure out how we can either > > change drm core writeback to work with our intel_connector structure > > or find a different solution which allows us to work with the current > > I'm assuming this is just fyi to keep development moving and not being > planned for merging? Yes we do plan to get it merged as a proper implementation that uses drm-core will require significant time and to unblock the writeback functionality these interim series of patches have been floated. Regards Suraj Kandpal
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Enable THP on Icelake and beyond (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915: Enable THP on Icelake and beyond
(rev2)
URL : https://patchwork.freedesktop.org/series/103330/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11594_full -> Patchwork_103330v2_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_103330v2_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103330v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103330v2_full:
### CI changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* boot:
- {shard-rkl}:([PASS][1], [PASS][2], [PASS][3], [PASS][4],
[PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11],
[PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17],
[PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22]) -> ([PASS][23],
[PASS][24], [PASS][25], [PASS][26], [PASS][27], [FAIL][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
[PASS][42])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-6/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-6/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-6/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-6/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-5/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-5/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-5/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-5/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-5/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-4/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-4/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-4/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-4/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-2/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-2/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-2/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-2/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-2/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-1/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-1/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-1/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11594/shard-rkl-1/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-6/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-6/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-6/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-5/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-5/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-5/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-5/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-4/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-4/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-4/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-4/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-2/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-2/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-1/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-1/boot.html
[38]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/shard-rkl-1/boot.html
[39]:
Re: [Intel-gfx] [PATCH 0/3] i915 private writeback framework
On Mon, May 02, 2022 at 11:12:16AM +0530, Suraj Kandpal wrote: > A patch series was floated in the drm mailing list which aimed to change > the drm_connector and drm_encoder fields to pointer in the > drm_connector_writeback structure, this received a huge pushback from > the community but since i915 expects each connector present in the > drm_device list to be a intel_connector but drm_writeback framework. > [1] > https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ > [2] > https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ > This forces us to use a drm_connector which is not embedded in > intel_connector the current drm_writeback framework becomes very > unfeasible to us as it would mean a lot of checks at a lot of places > to take into account the above issue.Since no one had an issue with > encoder field being changed into a pointer it was decided to break the > connector and encoder pointer changes into two different series.The > encoder field changes is currently being worked upon by Abhinav Kumar > [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 > In the meantime for i915 to start using the writeback functionality we > came up with a interim solution to own writeback pipeline bypassing one > provided by drm which is what these patches do. > Note: these are temp patches till we figure out how we can either change > drm core writeback to work with our intel_connector structure or find a > different solution which allows us to work with the current I'm assuming this is just fyi to keep development moving and not being planned for merging? -Daniel > > Suraj Kandpal (3): > drm/i915: Creating writeback pipeline to bypass drm_writeback > framework > drm/i915: Define WD trancoder for i915 > drm/i915: Enabling WD Transcoder > > drivers/gpu/drm/i915/Makefile | 2 + > drivers/gpu/drm/i915/display/intel_acpi.c | 1 + > drivers/gpu/drm/i915/display/intel_display.c | 89 +- > drivers/gpu/drm/i915/display/intel_display.h | 15 + > .../drm/i915/display/intel_display_types.h| 18 + > drivers/gpu/drm/i915/display/intel_dpll.c | 3 + > drivers/gpu/drm/i915/display/intel_opregion.c | 3 + > .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++ > .../gpu/drm/i915/display/intel_wb_connector.h | 99 ++ > drivers/gpu/drm/i915/display/intel_wd.c | 978 ++ > drivers/gpu/drm/i915/display/intel_wd.h | 82 ++ > drivers/gpu/drm/i915/i915_drv.h | 5 + > drivers/gpu/drm/i915/i915_irq.c | 8 +- > drivers/gpu/drm/i915/i915_pci.c | 7 +- > drivers/gpu/drm/i915/i915_reg.h | 139 +++ > 15 files changed, 1742 insertions(+), 3 deletions(-) > create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c > create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h > > -- > 2.35.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Enable THP on Icelake and beyond (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Enable THP on Icelake and beyond (rev2) URL : https://patchwork.freedesktop.org/series/103330/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11594_full -> Patchwork_103330v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103330v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103330v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 3) -- ERROR: It appears as if the changes made in Patchwork_103330v2_full prevented too many machines from booting. Missing(10): shard-skl shard-tglu shard-tglb shard-iclb shard-apl shard-glk shard-kbl shard-snb shard-rkl shard-dg1 Changes --- No changes found Build changes - * CI: CI-20190529 -> None * IGT: IGT_6464 -> None * Linux: CI_DRM_11594 -> Patchwork_103330v2 CI-20190529: 20190529 CI_DRM_11594: 66be687e9dfa7723518e1b1e7081cd8c5a863eb7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6464: eddc67c5c85b8ee6eb4d13752ca43da5073dc985 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_103330v2: 66be687e9dfa7723518e1b1e7081cd8c5a863eb7 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103330v2/index.html
Re: [Intel-gfx] [PATCH 1/2] module: add a function to add module references
On Fri, Apr 29, 2022 at 12:36:01PM +0200, Greg KH wrote: > On Fri, Apr 29, 2022 at 11:23:51AM +0100, Mauro Carvalho Chehab wrote: > > Em Fri, 29 Apr 2022 12:10:07 +0200 > > Greg KH escreveu: > > > > > On Fri, Apr 29, 2022 at 10:15:03AM +0100, Mauro Carvalho Chehab wrote: > > > > HI Greg, > > > > > > > > Em Fri, 29 Apr 2022 10:30:33 +0200 > > > > Greg KH escreveu: > > > > > > > > > On Fri, Apr 29, 2022 at 09:07:57AM +0100, Mauro Carvalho Chehab > > > > > wrote: > > > > > > Hi Daniel, > > > > > > > > > > > > Em Fri, 29 Apr 2022 09:54:10 +0200 > > > > > > Daniel Vetter escreveu: > > > > > > > > > > > > > On Fri, Apr 29, 2022 at 07:31:15AM +0100, Mauro Carvalho Chehab > > > > > > > wrote: > > > > > > > > Sometimes, device drivers are bound using indirect references, > > > > > > > > which is not visible when looking at /proc/modules or lsmod. > > > > > > > > > > > > > > > > Add a function to allow setting up module references for such > > > > > > > > cases. > > > > > > > > > > > > > > > > Reviewed-by: Dan Williams > > > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > > > > > > > This sounds like duct tape at the wrong level. We should have a > > > > > > > device_link connecting these devices, and maybe device_link > > > > > > > internally > > > > > > > needs to make sure the respective driver modules stay around for > > > > > > > long > > > > > > > enough too. But open-coding this all over the place into every > > > > > > > driver that > > > > > > > has some kind of cross-driver dependency sounds terrible. > > > > > > > > > > > > > > Or maybe the bug is that the snd driver keeps accessing the > > > > > > > hw/component > > > > > > > side when that is just plain gone. Iirc there's still fundamental > > > > > > > issues > > > > > > > there on the sound side of things, which have been attempted to > > > > > > > paper over > > > > > > > by timeouts and stuff like that in the past instead of enforcing > > > > > > > a hard > > > > > > > link between the snd and i915 side. > > > > > > > > > > > > I agree with you that the device link between snd-hda and the DRM > > > > > > driver > > > > > > should properly handle unbinding on both directions. This is > > > > > > something > > > > > > that require further discussions with ALSA and DRM people, and we > > > > > > should > > > > > > keep working on it. > > > > > > > > > > > > Yet, the binding between those drivers do exist, but, despite other > > > > > > similar inter-driver bindings being properly reported by lsmod, > > > > > > this one > > > > > > is invisible for userspace. > > > > > > > > > > > > What this series does is to make such binding visible. As simple as > > > > > > that. > > > > > > > > > > It also increases the reference count, and creates a user/kernel api > > > > > with the symlinks, right? Will the reference count increase prevent > > > > > the > > > > > modules from now being unloadable? > > > > > > > > > > This feels like a very "weak" link between modules that should not be > > > > > needed if reference counting is implemented properly (so that things > > > > > are > > > > > cleaned up in the correct order.) > > > > > > > > The refcount increment exists even without this patch, as > > > > hda_component_master_bind() at sound/hda/hdac_component.c uses > > > > try_module_get() when it creates the device link. > > > > > > Ok, then why shouldn't try_module_get() be creating this link instead of > > > having to manually do it this way again? You don't want to have to go > > > around and add this call to all users of that function, right? > > > > Works for me, but this is not a too trivial change, as the new > > try_module_get() function will require two parameters, instead of one: > > > > - the module to be referenced; > > - the module which will reference it. > > > > On trivial cases, one will be THIS_MODULE, but, in the specific case > > of snd_hda, the binding is done via an ancillary routine under > > snd_hda_core, but the actual binding happens at snd_hda_intel. > > For calls that want to increment a module reference on behalf of a > different code segment than is calling it, create a new function so we > can audit-the-heck out of those code paths as odds are, they are unsafe. > > For the normal code path, just turn try_module_get() into a macro that > includes THIS_MODULE as part of it like we do for the driver register > functions (see usb_register_driver() in include/linux/usb.h as an > example of how to do that.) > > > Ok, we could add a __try_module_get() (or whatever other name that > > would properly express what it does) with two parameters, and then > > define try_module_get() as: > > > > #define try_module_get(mod) __try_module_get(mod, THIS_MODULE) > > Yes, that's the way forward. This might result in some complaints because it can create module refcount loops. Well, seemingly module refcount loops, you can break them by first
Re: [Intel-gfx] [PATCH] drm/i915: warn about missing ->get_buf_trans initialization
> -Original Message- > From: Intel-gfx On Behalf Of Jani > Nikula > Sent: Tuesday, May 3, 2022 1:52 PM > To: intel-gfx@lists.freedesktop.org > Cc: Nikula, Jani > Subject: [Intel-gfx] [PATCH] drm/i915: warn about missing ->get_buf_trans > initialization > > Make sure each DDI platform has sane ->get_buf_trans initialized. > > Suggested-by: Matt Roper > Cc: Matt Roper > Signed-off-by: Jani Nikula > --- Reviewed-by: Arun R Murthy Thanks and Regards, Arun R Murthy
Re: [Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
On 03/05/2022 20:49, Umesh Nerlige Ramappa wrote:
On Tue, May 03, 2022 at 09:42:52AM +0100, Tvrtko Ursulin wrote:
On 02/05/2022 23:18, Umesh Nerlige Ramappa wrote:
Current implementation of Wa_22011802037 is limited to the GuC backend
and gen12. Add support for execlist backend and gen11 as well.
Is the implication f6aa0d713c88 ("drm/i915: Add Wa_22011802037 force
cs halt") does not work on Tigerlake? Fixes: tag probably required in
that case since I have sold that fix as a, well, fix.
After the fix was made, the WA has evolved and added some more steps for
handling pending MI_FORCE_WAKEs. This patch is the additional set of
steps needed for the WA. As you mentioned offline, I should correct the
commit message to indicate that the WA does exist for execlists, but
needs additional steps. Will add Fixes: tag.
Ok, that would be good then since it does sound they need to be tied
together (as in cherry picked for fixes).
Will it be followed up with preempt-to-idle implementation to avoid the,
as I understand it, potential for activity on one CCS engine defeating
the WA on another by timing out the wait for idle?
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine.h | 2 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++-
.../drm/i915/gt/intel_execlists_submission.c | 7 ++
.../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-
6 files changed, 103 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1431f1e9dbee..04e435bce79b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct
intel_engine_cs *engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs
*engine);
+
void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine,
u32 mask);
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 14c6ddbbfde8..0bda665a407c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
/*
- * Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
+ * Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure
CS is
* stopped, set ring stop bit and prefetch disable bit to halt CS
*/
- if (GRAPHICS_VER(engine->i915) == 12)
+ if (GRAPHICS_VER(engine->i915) == 11 ||
GRAPHICS_VER(engine->i915) == 12)
IS_GRAPHICS_VER(11, 12)
intel_uncore_write_fw(uncore,
RING_MODE_GEN7(engine->mmio_base),
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
@@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct
intel_engine_cs *engine)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
+ /*
+ * TODO: Occasionally trying to stop the cs times out, but does not
What is the TODO part? To figure out why is sometimes does not work?
+ * adversely affect functionality. The timeout is set as a config
+ * parameter that defaults to 100ms. Assuming that this timeout is
+ * sufficient for any pending MI_FORCEWAKEs to complete. Once root
+ * caused, the caller must check and handler the return from this
s/handler/handle/
TODO is to convert the function to return an error?
TODO: Find out why occasionally stopping the CS times out. Seen
especially with gem_eio tests.
I will update the comment to be clear.
This timeout is in general or with this patch only?
+ * function.
+ */
if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine,
"timed out on STOP_RING -> IDLE; HEAD:%04x,
TAIL:%04x\n",
@@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct
intel_engine_cs *engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE,
_MASKED_BIT_DISABLE(STOP_RING));
}
+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
+{
+ static const i915_reg_t _reg[I915_NUM_ENGINES] = {
+ [RCS0] = MSG_IDLE_CS,
+ [BCS0] = MSG_IDLE_BCS,
+ [VCS0] = MSG_IDLE_VCS0,
+ [VCS1] = MSG_IDLE_VCS1,
+ [VCS2] = MSG_IDLE_VCS2,
+ [VCS3] = MSG_IDLE_VCS3,
+ [VCS4] = MSG_IDLE_VCS4,
+ [VCS5] = MSG_IDLE_VCS5,
+ [VCS6] = MSG_IDLE_VCS6,
+ [VCS7] = MSG_IDLE_VCS7,
+ [VECS0] = MSG_IDLE_VECS0,
+ [VECS1] = MSG_IDLE_VECS1,
+ [VECS2] =
Re: [Intel-gfx] [PATCH v2 00/20] drm/edid: CEA data block iterators, and more
On Tue, 03 May 2022, Jani Nikula wrote: > I've kind of lost track of the version numbers on some of the iterator > patches, but this is the next version (or mostly a resend) of > [1]. There's an additional rename patch for SCDS. Argh, forgot to send this series to dri-devel. Instead of sending the series yet another time, I bounced each message to dri-devel, and at least the archive indicates it worked fine. Fingers crossed. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Implement Wa_14015648006
== Series Details == Series: drm/i915/display: Implement Wa_14015648006 URL : https://patchwork.freedesktop.org/series/103518/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11599 -> Patchwork_103518v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103518v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103518v1, 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_103518v1/index.html Participating hosts (39 -> 41) -- Additional (5): fi-kbl-soraka bat-dg1-6 bat-dg1-5 fi-hsw-4770 bat-rpls-1 Missing(3): fi-bsw-cyan bat-rpls-2 bat-dg2-9 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103518v1: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@module-reload: - bat-dg1-5: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-5/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_103518v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@write: - bat-dg1-5: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-5/igt@fb...@write.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) +9 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/fi-hsw-4770/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_mmap@basic: - bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4083]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-6/igt@gem_m...@basic.html - bat-dg1-5: NOTRUN -> [SKIP][8] ([i915#4083]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_tiled_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4077]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-6/igt@gem_tiled_bl...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4077]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4079]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-5/igt@gem_tiled_pread_basic.html - bat-dg1-6: NOTRUN -> [SKIP][12] ([i915#4079]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-6/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3012]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html - bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#1155]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html - bat-dg1-6: NOTRUN -> [SKIP][15] ([i915#1155]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_engines: - bat-dg1-6: NOTRUN -> [INCOMPLETE][16] ([i915#4418]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][17] ([i915#1886]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103518v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@gtt: - fi-bdw-5557u: [PASS][18] -> [DMESG-FAIL][19] ([i915#3674]) [18]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Implement Wa_14015648006
== Series Details == Series: drm/i915/display: Implement Wa_14015648006 URL : https://patchwork.freedesktop.org/series/103518/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH] drm/i915/guc: Support programming the EU priority in the GuC descriptor
On 04/05/2022 02:06, Ceraolo Spurio, Daniele wrote: On 5/3/2022 5:44 PM, Daniele Ceraolo Spurio wrote: From: Matthew Brost The EU priority register must be updated by the GuC rather than the driver as it is context specific and only the GuC knows which context is currently executing. Cc: John Harrison Cc: Matt Roper Signed-off-by: Matthew Brost Signed-off-by: Aravind Iddamsetty --- drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 75291e9846c50..8f3ed60ff07d9 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -2420,6 +2420,8 @@ static void prepare_context_registration_info(struct intel_context *ce, */ info->hwlrca_lo = lower_32_bits(ce->lrc.lrca); info->hwlrca_hi = upper_32_bits(ce->lrc.lrca); + if (engine->flags & I915_ENGINE_HAS_EU_PRIORITY) + info->hwlrca_lo |= lrc_desc_priority(ce->guc_state.prio); Just realized that I forgot to squash in a change when I moved branch (guc_state.prio is the GuC-side value while lrc_desc_priority expects the i915 one). Ignore this, will fix up and re-send later. Is there any Fixes: or stable needed to tie it together with something? Regards, Tvrtko Daniele info->flags = CONTEXT_REGISTRATION_FLAG_KMD; /*
[Intel-gfx] [PATCH] drm/i915/display: Implement Wa_14015648006
Add 4th pipe to extend TGL Wa_16013835468 to support DG2
platform.
BSpec: 54077
Cc: Jouni Högander
Cc: José Roberto de Souza
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/display/intel_psr.c | 7 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 06db407e2749..d3b47c612305 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1080,6 +1080,8 @@ static u32 wa_16013835468_bit_get(struct intel_dp
*intel_dp)
return LATENCY_REPORTING_REMOVED_PIPE_B;
case PIPE_C:
return LATENCY_REPORTING_REMOVED_PIPE_C;
+ case PIPE_D:
+ return LATENCY_REPORTING_REMOVED_PIPE_D;
default:
MISSING_CASE(intel_dp->psr.pipe);
return 0;
@@ -1159,8 +1161,9 @@ static void intel_psr_enable_source(struct intel_dp
*intel_dp,
CLKGATE_DIS_MISC_DMASC_GATING_DIS);
/* Wa_16013835468:tgl[b0+], dg1 */
- if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_B0, STEP_FOREVER) ||
- IS_DG1(dev_priv)) {
+ /* Wa_14015648006: dg2 */
+ if (DISPLAY_VER(dev_priv) >= 12 &&
+ !IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) {
u16 vtotal, vblank;
vtotal = crtc_state->uapi.adjusted_mode.crtc_vtotal -
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ccb67eec1bd..b01402647300 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5921,6 +5921,7 @@
#define RESET_PCH_HANDSHAKE_ENABLE(1 << 4)
#define GEN8_CHICKEN_DCPR_1_MMIO(0x46430)
+#define LATENCY_REPORTING_REMOVED_PIPE_D REG_BIT(31)
#define SKL_SELECT_ALTERNATE_DC_EXIT REG_BIT(30)
#define LATENCY_REPORTING_REMOVED_PIPE_C REG_BIT(25)
#define LATENCY_REPORTING_REMOVED_PIPE_B REG_BIT(24)
--
2.27.0
Re: [Intel-gfx] Xorg SEGV in Xen PV dom0 after updating from 5.16.18 to 5.17.5
On 04.05.22 08:48, Juergen Gross wrote:
> On 04.05.22 07:46, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker. Sending this just to
>> CC the developers of the culprit mentioned below (bdd8b6c98239cad
>> ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")) and the
>> maintainers for the subsystem.
>>
>> While at it a quick note: I wonder if this is problem a similar to one
>> that recently turned up with amdgpu and is fixed by this problem:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=78b12008f20
>>
>
> No, this is different.
>
> I have posted a patch yesterday which should fix the issue:
>
> https://lore.kernel.org/lkml/20220503132207.17234-3-jgr...@suse.com/T/#m75efc68c96d8f7160229b5f3147242221ce0c28c
Ahh, great, thx for letting us know.
#regzbot monitor:
https://lore.kernel.org/lkml/20220503132207.17234-1-jgr...@suse.com/
Ciao, Thorsten
>> Ciao, Thorsten
>>
>> On 04.05.22 02:37, Marek Marczykowski-Górecki wrote:
>>>
>>> After updating from 5.16.18 to 5.17.5 in Xen PV dom0, my Xorg started
>>> crashing when displaying any window mapped from a guest (domU) system.
>>> This is 100% reproducible.
>>> The system is Qubes OS, and it uses a trick that maps windows content
>>> from other guests using Xen grant tables, wrapped as "shared memory"
>>> from Xorg point of view (so, the memory that Xorg mmaps is not just from
>>> another process, but from another VM). That's the ShmPutImage you can
>>> see on the stack trace below.
>>>
>>> Stack trace of thread 12858:
>>> #0 0x7f80029e17d5 raise (libc.so.6 + 0x3c7d5)
>>> #1 0x7f80029ca895 abort (libc.so.6 + 0x25895)
>>> #2 0x5b3469ace0e0 OsAbort (Xorg + 0x1c60e0)
>>> #3 0x5b3469ad3959 AbortServer (Xorg + 0x1cb959)
>>> #4 0x5b3469ad46aa FatalError (Xorg + 0x1cc6aa)
>>> #5 0x5b3469acb450 OsSigHandler (Xorg + 0x1c3450)
>>> #6 0x7f8002b85a90 __restore_rt (libpthread.so.0 + 0x14a90)
>>> #7 0x7f8002b0a2a1 __memmove_avx_unaligned_erms (libc.so.6 +
>>> 0x1652a1)
>>> #8 0x7f80015dfcc9 linear_to_xtiled_faster (iris_dri.so + 0xc91cc9)
>>> #9 0x7f80015e3477 _isl_memcpy_linear_to_tiled (iris_dri.so +
>>> 0xc95477)
>>> #10 0x7f8001468440 iris_texture_subdata (iris_dri.so + 0xb1a440)
>>> #11 0x7f8000a76107 st_TexSubImage (iris_dri.so + 0x128107)
>>> #12 0x7f8000be9a47 texture_sub_image (iris_dri.so + 0x29ba47)
>>> #13 0x7f8000becd0c texsubimage_err (iris_dri.so + 0x29ed0c)
>>> #14 0x7f8000bf2939 _mesa_TexSubImage2D (iris_dri.so + 0x2a4939)
>>> #15 0x7f800213831f glamor_upload_boxes (libglamoregl.so + 0x1e31f)
>>> #16 0x7f800213856f glamor_upload_region (libglamoregl.so + 0x1e56f)
>>> #17 0x7f800212aea6 glamor_put_image (libglamoregl.so + 0x10ea6)
>>> #18 0x5b3469a4d79c damagePutImage (Xorg + 0x14579c)
>>> #19 0x5b3469a00a7e ProcShmPutImage (Xorg + 0xf8a7e)
>>> #20 0x5b3469965a2b Dispatch (Xorg + 0x5da2b)
>>> #21 0x5b3469969b04 dix_main (Xorg + 0x61b04)
>>> #22 0x7f80029cc082 __libc_start_main (libc.so.6 + 0x27082)
>>> #23 0x5b3469952e6e _start (Xorg + 0x4ae6e)
>>>
>>> Disassembly of the surrounding code:
>>>
>>> 0x7596ae8c82fb <+123>: ja 0x7596ae8c8338
>>> <__memmove_avx_unaligned_erms+184>
>>> 0x7596ae8c82fd <+125>: jb 0x7596ae8c8304
>>> <__memmove_avx_unaligned_erms+132>
>>> 0x7596ae8c82ff <+127>: movzbl (%rsi),%ecx
>>> 0x7596ae8c8302 <+130>: mov %cl,(%rdi)
>>> 0x7596ae8c8304 <+132>: retq
>>> 0x7596ae8c8305 <+133>: vmovdqu (%rsi),%xmm0
>>> 0x7596ae8c8309 <+137>: vmovdqu -0x10(%rsi,%rdx,1),%xmm1
>>> => 0x7596ae8c830f <+143>: vmovdqu %xmm0,(%rdi)
>>> 0x7596ae8c8313 <+147>: vmovdqu %xmm1,-0x10(%rdi,%rdx,1)
>>> 0x7596ae8c8319 <+153>: retq
>>>
>>>
>>> I don't see any related kernel or Xen messages at this time. Xorg's SEGV
>>> handler prints also:
>>>
>>> (EE) Segmentation fault at address 0x3c010
>>>
>>> Git bisect says it's bdd8b6c98239cad ("drm/i915: replace X86_FEATURE_PAT
>>> with pat_enabled()"), and indeed with this commit reverted on top of
>>> 5.17.5 everything works fine.
>>>
>>> I guess this part of dom0's boot dmesg may be relevant:
>>>
>>> [ 0.000949] x86/PAT: MTRRs disabled, skipping PAT initialization too.
>>> [ 0.000953] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP
>>> UC UC
>>>
>>> Originally reported at
>>> https://github.com/QubesOS/qubes-issues/issues/7479
>>>
>>> #regzbot introduced bdd8b6c98239cad
>>> #regzbot monitor: https://github.com/QubesOS/qubes-issues/issues/7479
>>>
>
