Re: [Intel-gfx] [PATCH 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address
On Mon, Feb 28, 2022 at 11:48:58PM -0800, Lucas De Marchi wrote: On Tue, Feb 22, 2022 at 08:22:01PM +0530, Balasubramani Vivekanandan wrote: Fast copy using non-temporal instructions for x86 currently exists at two locations. One is implemented in i915 driver at i915/i915_memcpy.c and another copy at drm_cache.c. The plan is to remove the duplicate implementation in i915 driver and use the functions from drm_cache.c. A variant of drm_memcpy_from_wc() is added in drm_cache.c which accepts address as argument instead of iosys_map for destination. It is a very common scenario in i915 to copy from a WC memory type, which may be an io memory or a system memory to a destination address pointing to system memory. To avoid the overhead of creating iosys_map type for the destination, new variant is created to accept the address directly. Also a new function is exported in drm_cache.c to find if the fast copy is supported by the platform or not. It is required for i915. Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Thomas Hellstr_m Signed-off-by: Balasubramani Vivekanandan --- drivers/gpu/drm/drm_cache.c | 54 + include/drm/drm_cache.h | 3 +++ 2 files changed, 57 insertions(+) diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c index a21c1350eb09..eb0bcd33665e 100644 --- a/drivers/gpu/drm/drm_cache.c +++ b/drivers/gpu/drm/drm_cache.c @@ -358,6 +358,54 @@ void drm_memcpy_from_wc(struct iosys_map *dst, } EXPORT_SYMBOL(drm_memcpy_from_wc); +/** + * drm_memcpy_from_wc_vaddr - Perform the fastest available memcpy from a source + * that may be WC. to a destination in system memory. + * @dst: The destination pointer + * @src: The source pointer + * @len: The size of the area to transfer in bytes + * + * Same as drm_memcpy_from_wc except destination is accepted as system memory + * address. Useful in situations where passing destination address as iosys_map + * is simply an overhead and can be avoided. although one could do drm_memcpy_from_wc(IOSYS_MAP_INIT_VADDR(addr), ... ... Just making you don't take that as a suggestion, I was just thinking out loud. And as is, it doesn't work as the function expects a iosys_map * Lucas De Marhci
Re: [Intel-gfx] [PATCH 3/7] drm/i915: use the memcpy_from_wc call from the drm
On Tue, Feb 22, 2022 at 08:22:02PM +0530, Balasubramani Vivekanandan wrote:
memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 2d593d573ef1..49ff8e3e71d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -449,16 +449,16 @@ static void
i915_gem_object_read_from_page_iomap(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
void __iomem *src_map;
- void __iomem *src_ptr;
+ struct iosys_map src_ptr;
+
dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >>
PAGE_SHIFT);
src_map = io_mapping_map_wc(&obj->mm.region->iomap,
dma - obj->mm.region->region.start,
PAGE_SIZE);
- src_ptr = src_map + offset_in_page(offset);
- if (!i915_memcpy_from_wc(dst, (void __force *)src_ptr, size))
- memcpy_fromio(dst, src_ptr, size);
+ iosys_map_set_vaddr_iomem(&src_ptr, (src_map + offset_in_page(offset)));
Too many parenthesis ---^
other than that.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ drm_memcpy_from_wc_vaddr(dst, &src_ptr, size);
io_mapping_unmap(src_map);
}
--
2.25.1
Re: [Intel-gfx] [PATCH 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address
On Tue, Feb 22, 2022 at 08:22:01PM +0530, Balasubramani Vivekanandan wrote:
Fast copy using non-temporal instructions for x86 currently exists at two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c. The plan is to remove the duplicate
implementation in i915 driver and use the functions from drm_cache.c.
A variant of drm_memcpy_from_wc() is added in drm_cache.c which accepts
address as argument instead of iosys_map for destination. It is a very
common scenario in i915 to copy from a WC memory type, which may be an
io memory or a system memory to a destination address pointing to system
memory. To avoid the overhead of creating iosys_map type for the
destination, new variant is created to accept the address directly.
Also a new function is exported in drm_cache.c to find if the fast copy
is supported by the platform or not. It is required for i915.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Thomas Hellstr_m
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/drm_cache.c | 54 +
include/drm/drm_cache.h | 3 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a21c1350eb09..eb0bcd33665e 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -358,6 +358,54 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
}
EXPORT_SYMBOL(drm_memcpy_from_wc);
+/**
+ * drm_memcpy_from_wc_vaddr - Perform the fastest available memcpy from a
source
+ * that may be WC.
to a destination in system memory.
+ * @dst: The destination pointer
+ * @src: The source pointer
+ * @len: The size of the area to transfer in bytes
+ *
+ * Same as drm_memcpy_from_wc except destination is accepted as system memory
+ * address. Useful in situations where passing destination address as iosys_map
+ * is simply an overhead and can be avoided.
although one could do drm_memcpy_from_wc(IOSYS_MAP_INIT_VADDR(addr), ...
(if IOSYS_MAP_INIT_VADDR provided a cast to the struct).
+ */
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
name here is confusing as we are copying *to* system memory. Maybe
drm_memcpy_vaddr_from_wc()? Not sure it's better. Maybe someone in Cc
has a better suggestion
( To be honest, this whole _from_wc() suffix sound weird when are checking I/O
vs system memory it may have been the motivation, but maybe it
shouldn't be the name of the memcpy() variant )
The implementation looks ok and follows drm_memcpy_from_wc()
Lucas De Marchi
+ unsigned long len)
+{
+ if (WARN_ON(in_interrupt())) {
+ iosys_map_memcpy_from(dst, src, 0, len);
+ return;
+ }
+
+ if (static_branch_likely(&has_movntdqa)) {
+ __drm_memcpy_from_wc(dst,
+src->is_iomem ?
+(void const __force *)src->vaddr_iomem :
+src->vaddr,
+len);
+ return;
+ }
+
+ iosys_map_memcpy_from(dst, src, 0, len);
+}
+EXPORT_SYMBOL(drm_memcpy_from_wc_vaddr);
+
+/*
+ * drm_memcpy_fastcopy_supported - Returns if fast copy using non-temporal
+ * instructions is supported
+ *
+ * Returns true if platform has support for fast copying from wc memory type
+ * using non-temporal instructions. Else false.
+ */
+bool drm_memcpy_fastcopy_supported(void)
+{
+ if (static_branch_likely(&has_movntdqa))
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
/*
* drm_memcpy_init_early - One time initialization of the WC memcpy code
*/
@@ -382,6 +430,12 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
}
EXPORT_SYMBOL(drm_memcpy_from_wc);
+bool drm_memcpy_fastcopy_supported(void)
+{
+ return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
void drm_memcpy_init_early(void)
{
}
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 22deb216b59c..8f48e4dcd7dc 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -77,4 +77,7 @@ void drm_memcpy_init_early(void);
void drm_memcpy_from_wc(struct iosys_map *dst,
const struct iosys_map *src,
unsigned long len);
+bool drm_memcpy_fastcopy_supported(void);
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ unsigned long len);
#endif
--
2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for Kbuild: move to -std=gnu11
== Series Details ==
Series: Kbuild: move to -std=gnu11
URL : https://patchwork.freedesktop.org/series/100824/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11300_full -> Patchwork_22435_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22435_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22435_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_22435_full:
### IGT changes ###
Possible regressions
* igt@gem_mmap_offset@clear:
- shard-tglb: [PASS][1] -> [TIMEOUT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-tglb3/igt@gem_mmap_off...@clear.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-tglb2/igt@gem_mmap_off...@clear.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-25}:
- {shard-rkl}:NOTRUN -> [SKIP][3] +7 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-rkl-1/igt@kms_plane_scal...@planes-unity-scaling-downscale-factor-0-25.html
*
{igt@kms_plane_scaling@upscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1-upscale-with-rotation}:
- {shard-dg1}:NOTRUN -> [SKIP][4] +7 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-dg1-13/igt@kms_plane_scaling@upscale-with-rotation-factor-0...@pipe-b-hdmi-a-1-upscale-with-rotation.html
New tests
-
New tests have been introduced between CI_DRM_11300_full and
Patchwork_22435_full:
### New IGT tests (1) ###
*
igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:
- Statuses : 1 pass(s)
- Exec time: [1.28] s
Known issues
Here are the changes found in Patchwork_22435_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_read@short-buffer-block:
- shard-snb: [PASS][5] -> [SKIP][6] ([fdo#109271]) +3 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-snb2/igt@drm_r...@short-buffer-block.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-snb2/igt@drm_r...@short-buffer-block.html
* igt@gem_eio@reset-stress:
- shard-snb: [PASS][7] -> [CRASH][8] ([i915#5165])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-snb4/igt@gem_...@reset-stress.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-snb2/igt@gem_...@reset-stress.html
* igt@gem_exec_balancer@parallel-bb-first:
- shard-tglb: NOTRUN -> [DMESG-WARN][9] ([i915#5076])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-tglb1/igt@gem_exec_balan...@parallel-bb-first.html
* igt@gem_exec_capture@pi@vcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][10] ([i915#4547])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-skl7/igt@gem_exec_capture@p...@vcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-glk9/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_suspend@basic-s3@smem:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +4
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-apl2/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-apl2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-glk1/igt@gem_exec_whis...@basic-contexts-forked-all.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/shard-glk3/igt@gem_exec_whis
Re: [Intel-gfx] [PATCH 1/7] drm: Relax alignment constraint for destination address
On Tue, Feb 22, 2022 at 08:22:00PM +0530, Balasubramani Vivekanandan wrote:
There is no need for the destination address to be aligned to 16 byte
boundary to be able to use the non-temporal instructions while copying.
Non-temporal instructions are used only for loading from the source
address which has alignment constraints.
We only need to take care of using the right instructions, based on
whether destination address is aligned or not, while storing the data to
the destination address.
__memcpy_ntdqu is copied from i915/i915_memcpy.c
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Chris Wilson
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/drm_cache.c | 44 -
1 file changed, 38 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index c3e6e615bf09..a21c1350eb09 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -278,18 +278,50 @@ static void __memcpy_ntdqa(void *dst, const void *src,
unsigned long len)
kernel_fpu_end();
}
+static void __memcpy_ntdqu(void *dst, const void *src, unsigned long len)
+{
+ kernel_fpu_begin();
+
+ while (len >= 4) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movntdqa 16(%0), %%xmm1\n"
+ "movntdqa 32(%0), %%xmm2\n"
+ "movntdqa 48(%0), %%xmm3\n"
+ "movups %%xmm0, (%1)\n"
+ "movups %%xmm1, 16(%1)\n"
+ "movups %%xmm2, 32(%1)\n"
+ "movups %%xmm3, 48(%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 64;
+ dst += 64;
+ len -= 4;
+ }
+ while (len--) {
+ asm("movntdqa (%0), %%xmm0\n"
+ "movups %%xmm0, (%1)\n"
+ :: "r" (src), "r" (dst) : "memory");
+ src += 16;
+ dst += 16;
ok, this takes care of the tail
+ }
+
+ kernel_fpu_end();
+}
+
/*
* __drm_memcpy_from_wc copies @len bytes from @src to @dst using
- * non-temporal instructions where available. Note that all arguments
- * (@src, @dst) must be aligned to 16 bytes and @len must be a multiple
- * of 16.
+ * non-temporal instructions where available. Note that @src must be aligned to
+ * 16 bytes and @len must be a multiple of 16.
*/
static void __drm_memcpy_from_wc(void *dst, const void *src, unsigned long len)
{
- if (unlikely(((unsigned long)dst | (unsigned long)src | len) & 15))
+ if (unlikely(((unsigned long)src | len) & 15)) {
memcpy(dst, src, len);
- else if (likely(len))
- __memcpy_ntdqa(dst, src, len >> 4);
+ } else if (likely(len)) {
+ if (IS_ALIGNED((unsigned long)dst, 16))
we may want to just extend this function to deal with dst not being
aligned. But this may be done on top
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ __memcpy_ntdqa(dst, src, len >> 4);
+ else
+ __memcpy_ntdqu(dst, src, len >> 4);
+ }
}
/**
--
2.25.1
Re: [Intel-gfx] [PATCH v2 06/13] drm/i915: Move context descriptor fields to intel_lrc.h
On Mon, Feb 28, 2022 at 09:42:38AM -0800, Matt Roper wrote:
This is a more appropriate header for these definitions.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 34 ---
drivers/gpu/drm/i915/gt/intel_lrc.h | 34 +++
3 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index edba18c942cf..b0982a9e4476 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -21,6 +21,7 @@
#include "intel_gt.h"
#include "intel_gt_requests.h"
#include "intel_gt_pm.h"
+#include "intel_lrc.h"
#include "intel_lrc_reg.h"
#include "intel_reset.h"
#include "intel_ring.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 69b826a3c381..84f189738a68 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1499,38 +1499,4 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
-enum {
- INTEL_ADVANCED_CONTEXT = 0,
- INTEL_LEGACY_32B_CONTEXT,
- INTEL_ADVANCED_AD_CONTEXT,
- INTEL_LEGACY_64B_CONTEXT
-};
-
-enum {
- FAULT_AND_HANG = 0,
- FAULT_AND_HALT, /* Debug only */
- FAULT_AND_STREAM,
- FAULT_AND_CONTINUE /* Unsupported */
-};
-
-#define CTX_GTT_ADDRESS_MASK GENMASK(31, 12)
-#define GEN8_CTX_VALID (1 << 0)
-#define GEN8_CTX_FORCE_PD_RESTORE(1 << 1)
-#define GEN8_CTX_FORCE_RESTORE (1 << 2)
-#define GEN8_CTX_L3LLC_COHERENT (1 << 5)
-#define GEN8_CTX_PRIVILEGE (1 << 8)
-#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
-#define GEN8_CTX_ID_SHIFT32
-#define GEN8_CTX_ID_WIDTH21
-#define GEN11_SW_CTX_ID_SHIFT37
-#define GEN11_SW_CTX_ID_WIDTH11
-#define GEN11_ENGINE_CLASS_SHIFT 61
-#define GEN11_ENGINE_CLASS_WIDTH 3
-#define GEN11_ENGINE_INSTANCE_SHIFT 48
-#define GEN11_ENGINE_INSTANCE_WIDTH 6
-#define XEHP_SW_CTX_ID_SHIFT 39
-#define XEHP_SW_CTX_ID_WIDTH 16
-#define XEHP_SW_COUNTER_SHIFT58
-#define XEHP_SW_COUNTER_WIDTH6
-
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index 0b76f096b559..820f8f41fc1f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -69,4 +69,38 @@ void lrc_check_regs(const struct intel_context *ce,
void lrc_update_runtime(struct intel_context *ce);
+enum {
+ INTEL_ADVANCED_CONTEXT = 0,
+ INTEL_LEGACY_32B_CONTEXT,
+ INTEL_ADVANCED_AD_CONTEXT,
+ INTEL_LEGACY_64B_CONTEXT
+};
+
+enum {
+ FAULT_AND_HANG = 0,
+ FAULT_AND_HALT, /* Debug only */
+ FAULT_AND_STREAM,
+ FAULT_AND_CONTINUE /* Unsupported */
+};
+
+#define CTX_GTT_ADDRESS_MASK GENMASK(31, 12)
I don't like changing code while moving, but I'd open an exception here
just to fix these 2 spaces in this block. Anyway, up to you:
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+#define GEN8_CTX_VALID (1 << 0)
+#define GEN8_CTX_FORCE_PD_RESTORE(1 << 1)
+#define GEN8_CTX_FORCE_RESTORE (1 << 2)
+#define GEN8_CTX_L3LLC_COHERENT (1 << 5)
+#define GEN8_CTX_PRIVILEGE (1 << 8)
+#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
+#define GEN8_CTX_ID_SHIFT32
+#define GEN8_CTX_ID_WIDTH21
+#define GEN11_SW_CTX_ID_SHIFT37
+#define GEN11_SW_CTX_ID_WIDTH11
+#define GEN11_ENGINE_CLASS_SHIFT 61
+#define GEN11_ENGINE_CLASS_WIDTH 3
+#define GEN11_ENGINE_INSTANCE_SHIFT 48
+#define GEN11_ENGINE_INSTANCE_WIDTH 6
+#define XEHP_SW_CTX_ID_SHIFT 39
+#define XEHP_SW_CTX_ID_WIDTH 16
+#define XEHP_SW_COUNTER_SHIFT58
+#define XEHP_SW_COUNTER_WIDTH6
+
#endif /* __INTEL_LRC_H__ */
--
2.34.1
Re: [Intel-gfx] [PATCH v2 04/13] drm/i915/xehp: compute engine pipe_control
On Mon, Feb 28, 2022 at 09:42:36AM -0800, Matt Roper wrote:
From: Daniele Ceraolo Spurio
CCS will reuse the RCS functions for breadcrumb and flush emission.
However, CCS pipe_control has additional programming restrictions:
- Command Streamer Stall Enable must be always set
- Post Sync Operations must not be set to Write PS Depth Count
- 3D-related bits must not be set
Bspec: 47112
Cc: Vinay Belgaumkar
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 35 +++-
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 +
2 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1f8cf4f790b2..0a29eaf8b0df 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -201,6 +201,8 @@ static u32 *gen12_emit_aux_table_inv(const i915_reg_t
inv_reg, u32 *cs)
int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
{
+ struct intel_engine_cs *engine = rq->engine;
+
if (mode & EMIT_FLUSH) {
u32 flags = 0;
u32 *cs;
@@ -219,6 +221,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
+ if (engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_FLAGS;
+
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -246,6 +251,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
+ if (engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_FLAGS;
+
cs = intel_ring_begin(rq, 8 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -618,19 +626,28 @@ u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request
*rq, u32 *cs)
u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
{
+ struct drm_i915_private *i915 = rq->engine->i915;
+
extra blank line here
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ u32 flags = (PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_TILE_CACHE_FLUSH |
+PIPE_CONTROL_FLUSH_L3 |
+PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+PIPE_CONTROL_DC_FLUSH_ENABLE |
+PIPE_CONTROL_FLUSH_ENABLE);
+
+ if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12,
50))
+ /* Wa_1409600907 */
+ flags |= PIPE_CONTROL_DEPTH_STALL;
+
+ if (rq->engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_FLAGS;
+
cs = gen12_emit_ggtt_write_rcs(cs,
rq->fence.seqno,
hwsp_offset(rq),
PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
- PIPE_CONTROL_CS_STALL |
- PIPE_CONTROL_TILE_CACHE_FLUSH |
- PIPE_CONTROL_FLUSH_L3 |
- PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
- PIPE_CONTROL_DEPTH_CACHE_FLUSH |
- /* Wa_1409600907:tgl */
- PIPE_CONTROL_DEPTH_STALL |
- PIPE_CONTROL_DC_FLUSH_ENABLE |
- PIPE_CONTROL_FLUSH_ENABLE);
+ flags);
return gen12_emit_fini_breadcrumb_tail(rq, cs);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f8253012d166..d112ffd56418 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -228,11 +228,14 @@
#define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE (1<<29) /* gen11+ */
#define PIPE_CONTROL_TILE_CACHE_FLUSH (1<<28) /* gen11+ */
#define PIPE_CONTROL_FLUSH_L3 (1<<27)
+#define PIPE_CONTROL_AMFS_FLUSH (1<<25) /* gen12+ */
#define PIPE_CONTROL_GLOBAL_GTT_IVB (1<<24) /* gen7+ */
#define PIPE_CONTROL_MMIO_WRITE (1<<23)
#define PIPE_CONTROL_STORE_DATA_INDEX (1<<21)
#define PIPE_CONTROL_CS_STALL (1<<20)
+#define PIPE_CONTROL_GLOBAL_SNAPSHOT_RESET (1<<19)
#define PIPE_CONTROL_TLB_INVALIDATE (1<<18)
+#define PIPE_CONTROL_PSD_SYNC(1<<17) /*
gen11+ */
#define PIPE_CONTROL_MEDIA_STATE_CLEAR(1<<16)
#define PIPE_CONTROL_WRITE_TIMESTAMP
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms
== Series Details ==
Series: drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms
URL : https://patchwork.freedesktop.org/series/100867/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22445
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/index.html
Participating hosts (46 -> 40)
--
Additional (1): bat-jsl-2
Missing(7): fi-kbl-soraka shard-tglu fi-bsw-cyan fi-pnv-d510 shard-rkl
shard-dg1 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22445 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][1] -> [FAIL][2] ([i915#4032])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_pm:
- fi-tgl-1115g4: [PASS][3] -> [DMESG-FAIL][4] ([i915#3987])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/fi-tgl-1115g4/igt@i915_selftest@live@gt_pm.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][5] ([i915#541]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_busy@basic@flip:
- bat-adlp-4: [DMESG-WARN][7] ([i915#3576]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/bat-adlp-4/igt@kms_busy@ba...@flip.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][9] ([i915#165]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][11] ([i915#165] / [i915#295]) ->
[PASS][12] +13 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][13] ([i915#4494] / [i915#4957]) ->
[DMESG-FAIL][14] ([i915#4957])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][15] ([i915#5026]) -> [DMESG-FAIL][16]
([i915#4528] / [i915#5026])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22445/fi-blb-e6850/igt@i915_selftest@l...@requests.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987
[i915#4032]: https://gitlab.freedesktop.org/drm/intel/issues/4032
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026
[i915#5127]: https
[Intel-gfx] ✓ Fi.CI.IGT: success for Kbuild: remove -std=gnu89 from compiler arguments
== Series Details ==
Series: Kbuild: remove -std=gnu89 from compiler arguments
URL : https://patchwork.freedesktop.org/series/100823/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300_full -> Patchwork_22434_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_22434_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22434_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_22434_full:
### IGT changes ###
Warnings
* igt@kms_chamelium@hdmi-hpd-storm-disable:
- shard-tglb: [SKIP][1] ([fdo#109284] / [fdo#111827]) ->
[INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-tglb2/igt@kms_chamel...@hdmi-hpd-storm-disable.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@kms_chamel...@hdmi-hpd-storm-disable.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-dpms:
- {shard-rkl}:[PASS][3] -> ([INCOMPLETE][4], [PASS][5])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-rkl-2/igt@i915_pm...@dc6-dpms.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-5/igt@i915_pm...@dc6-dpms.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-4/igt@i915_pm...@dc6-dpms.html
* igt@i915_selftest@live@slpc:
- {shard-rkl}:[PASS][6] -> [INCOMPLETE][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-rkl-5/igt@i915_selftest@l...@slpc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-5/igt@i915_selftest@l...@slpc.html
*
{igt@kms_plane_scaling@planes-downscale-factor-0-5@pipe-a-edp-1-planes-downscale}:
- shard-iclb: [PASS][8] -> [SKIP][9] +5 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb5/igt@kms_plane_scaling@planes-downscale-factor-...@pipe-a-edp-1-planes-downscale.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb2/igt@kms_plane_scaling@planes-downscale-factor-...@pipe-a-edp-1-planes-downscale.html
* {igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5}:
- {shard-rkl}:NOTRUN -> [SKIP][10] +10 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-rkl-1/igt@kms_plane_scal...@planes-upscale-factor-0-25-downscale-factor-0-5.html
*
{igt@kms_plane_scaling@scaler-with-clipping-clamping@pipe-b-edp-1-scaler-with-clipping-clamping}:
- shard-iclb: [PASS][11] -> [INCOMPLETE][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-iclb4/igt@kms_plane_scaling@scaler-with-clipping-clamp...@pipe-b-edp-1-scaler-with-clipping-clamping.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-iclb2/igt@kms_plane_scaling@scaler-with-clipping-clamp...@pipe-b-edp-1-scaler-with-clipping-clamping.html
*
{igt@kms_plane_scaling@upscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1-upscale-with-rotation}:
- {shard-dg1}:NOTRUN -> [SKIP][13] +12 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-dg1-17/igt@kms_plane_scaling@upscale-with-rotation-factor-0...@pipe-b-hdmi-a-1-upscale-with-rotation.html
New tests
-
New tests have been introduced between CI_DRM_11300_full and
Patchwork_22434_full:
### New IGT tests (1) ###
*
igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:
- Statuses : 1 pass(s)
- Exec time: [1.28] s
Known issues
Here are the changes found in Patchwork_22434_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +5
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/shard-kbl6/igt@gem_ctx_isolation@preservation...@vcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html
* igt@gem_exec_balancer@parallel-bb-first:
- shard-tglb: NOTRUN -> [DMESG-WARN][16] ([i915#5076])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/shard-tglb6/igt@gem_exec_balan...@parallel-bb-first.html
* igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][17] ([i91
Re: [Intel-gfx] [PATCH 1/6] drivers: usb: remove usage of list iterator past the loop body
On Mon, Feb 28, 2022 at 10:20:28AM -0800, Joe Perches wrote: > On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote: > > > a multi-line indent gets curly braces for readability even though > > it's not required by C. And then both sides would get curly braces. > > That's more your personal preference than a coding style guideline. > It's a USB patch. I thought Greg prefered it that way. Greg has some specific style things which he likes and I have adopted and some I pretend not to see. regards, dan carpenter
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add more TMDS clock rate supported by HDMI driver
== Series Details ==
Series: drm/i915: add more TMDS clock rate supported by HDMI driver
URL : https://patchwork.freedesktop.org/series/100866/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22444
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/index.html
Participating hosts (46 -> 32)
--
Missing(14): fi-kbl-soraka fi-bdw-samus shard-tglu bat-dg1-6 bat-dg1-5
shard-rkl bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-pnv-d510 bat-rpls-2
shard-dg1 bat-jsl-1
Known issues
Here are the changes found in Patchwork_22444 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-multi-fence:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-blb-e6850/igt@amdgpu/amd_ba...@cs-multi-fence.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@i915_selftest@live@workarounds:
- fi-rkl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#4983])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-rkl-guc/igt@i915_selftest@l...@workarounds.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][5] ([i915#541]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][7] ([i915#3921]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][9] ([i915#5026]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][11] ([i915#165]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][13] ([i915#165] / [i915#295]) ->
[PASS][14] +13 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026
[i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11300 -> Patchwork_22444
CI-20190529: 20190529
CI_DRM_11300: 10eb9bc8729d3da3fe8f53c8e5b70b8a9a52b6e0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6361: 2372a4beb6a33c5f0799a4a8ccbb93794f52dbca @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22444: e9b91b340e439b49a72b562c900b0b99eae24f2a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e9b91b340e43 drm/i915: add more TMDS clock rate supported by HDMI driver
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22444/index.html
[Intel-gfx] [PATCH] drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms
Platforms with FlatCCS do not use auxiliary planes for compression
control data and thus do not need traditional aux table invalidation
(and the registers no longer even exist).
Original-author: CQ Tang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 28
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1f8cf4f790b2..13bbbf5d9737 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -231,7 +231,7 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE) {
u32 flags = 0;
- u32 *cs;
+ u32 *cs, count;
flags |= PIPE_CONTROL_COMMAND_CACHE_INVALIDATE;
flags |= PIPE_CONTROL_TLB_INVALIDATE;
@@ -246,7 +246,12 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
- cs = intel_ring_begin(rq, 8 + 4);
+ if (!HAS_FLAT_CCS(rq->engine->i915))
+ count = 8 + 4;
+ else
+ count = 8;
+
+ cs = intel_ring_begin(rq, count);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -259,8 +264,10 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
- /* hsdes: 1809175790 */
- cs = gen12_emit_aux_table_inv(GEN12_GFX_CCS_AUX_NV, cs);
+ if (!HAS_FLAT_CCS(rq->engine->i915)) {
+ /* hsdes: 1809175790 */
+ cs = gen12_emit_aux_table_inv(GEN12_GFX_CCS_AUX_NV, cs);
+ }
*cs++ = preparser_disable(false);
intel_ring_advance(rq, cs);
@@ -275,12 +282,15 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
mode)
u32 cmd, *cs;
cmd = 4;
- if (mode & EMIT_INVALIDATE)
+ if (mode & EMIT_INVALIDATE) {
cmd += 2;
- if (mode & EMIT_INVALIDATE)
- aux_inv = rq->engine->mask & ~BIT(BCS0);
- if (aux_inv)
- cmd += 2 * hweight32(aux_inv) + 2;
+
+ if (!HAS_FLAT_CCS(rq->engine->i915)) {
+ aux_inv = rq->engine->mask & ~BIT(BCS0);
+ if (aux_inv)
+ cmd += 2 * hweight32(aux_inv) + 2;
+ }
+ }
cs = intel_ring_begin(rq, cmd);
if (IS_ERR(cs))
--
2.34.1
[Intel-gfx] [PATCH] drm/i915: add more TMDS clock rate supported by HDMI driver
VBT 249 update to support more TMDS clock rate 3.00G, 3.40G
and 5.94G. Refer to this new definition to configure max
TMDS clock rate for HDMI driver.
BSpec: 20124
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Ankit Nautiyal
Signed-off-by: Lee Shawn C
---
drivers/gpu/drm/i915/display/intel_bios.c | 6 ++
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 40b5e7ed12c2..a559a1914588 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1955,6 +1955,12 @@ static int _intel_bios_max_tmds_clock(const struct
intel_bios_encoder_data *devd
fallthrough;
case HDMI_MAX_DATA_RATE_PLATFORM:
return 0;
+ case HDMI_MAX_DATA_RATE_594:
+ return 594000;
+ case HDMI_MAX_DATA_RATE_340:
+ return 34;
+ case HDMI_MAX_DATA_RATE_300:
+ return 30;
case HDMI_MAX_DATA_RATE_297:
return 297000;
case HDMI_MAX_DATA_RATE_165:
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index b9397d9363c5..e0508990df48 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -289,6 +289,9 @@ struct bdb_general_features {
#define HDMI_MAX_DATA_RATE_PLATFORM0 /* 204 */
#define HDMI_MAX_DATA_RATE_297 1 /* 204 */
#define HDMI_MAX_DATA_RATE_165 2 /* 204 */
+#define HDMI_MAX_DATA_RATE_594 3 /* 249 */
+#define HDMI_MAX_DATA_RATE_340 4 /* 249 */
+#define HDMI_MAX_DATA_RATE_300 5 /* 249 */
#define LEGACY_CHILD_DEVICE_CONFIG_SIZE33
--
2.17.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware
URL : https://patchwork.freedesktop.org/series/100818/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11299_full -> Patchwork_22433_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22433_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22433_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_22433_full:
### IGT changes ###
Possible regressions
* igt@syncobj_timeline@wait-all-for-submit-snapshot:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/shard-skl1/igt@syncobj_timel...@wait-all-for-submit-snapshot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-skl4/igt@syncobj_timel...@wait-all-for-submit-snapshot.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
*
{igt@kms_plane_scaling@downscale-with-pixel-format-factor-0-25@pipe-a-edp-1-downscale-with-pixel-format}:
- shard-iclb: NOTRUN -> [SKIP][3] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-iclb8/igt@kms_plane_scaling@downscale-with-pixel-format-factor-0...@pipe-a-edp-1-downscale-with-pixel-format.html
*
{igt@kms_plane_scaling@downscale-with-rotation-factor-0-75@pipe-b-edp-1-downscale-with-rotation}:
- {shard-rkl}:NOTRUN -> [SKIP][4] +8 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-rkl-6/igt@kms_plane_scaling@downscale-with-rotation-factor-0...@pipe-b-edp-1-downscale-with-rotation.html
*
{igt@kms_plane_scaling@scaler-with-rotation-unity-scaling@pipe-d-hdmi-a-3-scaler-with-rotation}:
- {shard-dg1}:NOTRUN -> [SKIP][5] +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-dg1-18/igt@kms_plane_scaling@scaler-with-rotation-unity-scal...@pipe-d-hdmi-a-3-scaler-with-rotation.html
New tests
-
New tests have been introduced between CI_DRM_11299_full and
Patchwork_22433_full:
### New IGT tests (1) ###
*
igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-edp-1-planes-upscale-downscale:
- Statuses : 1 pass(s)
- Exec time: [1.28] s
Known issues
Here are the changes found in Patchwork_22433_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@set-priority-not-supported:
- shard-iclb: NOTRUN -> [SKIP][6] ([fdo#109314])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html
* igt@gem_eio@in-flight-contexts-10ms:
- shard-iclb: NOTRUN -> [TIMEOUT][7] ([i915#3070])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-iclb8/igt@gem_...@in-flight-contexts-10ms.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][8] ([i915#5076])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-kbl3/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_capture@pi@vcs0:
- shard-skl: NOTRUN -> [INCOMPLETE][9] ([i915#4547])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-skl1/igt@gem_exec_capture@p...@vcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-kbl7/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-skl: NOTRUN -> [SKIP][11] ([fdo#109271]) +7 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-skl6/igt@gem_exec_fair@basic-none-...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842]) +4 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_huc_copy@huc-copy:
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
From: Matthew Wilcox > Sent: 28 February 2022 20:16 > > On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_ 'pos' than > > outside. > > Then we can never use -Wshadow ;-( I'd love to be able to turn it on; > it catches real bugs. > > > +#define list_for_each_entry(pos, head, member) > > \ > > + for (typeof(pos) pos = list_first_entry(head, typeof(*pos), member); > > \ > > +!list_entry_is_head(pos, head, member);\ > > pos = list_next_entry(pos, member)) Actually can't you use 'pos' to temporarily hold the address of 'member'. Something like: for (pos = (void *)head; \ pos ? ((pos = (void *)pos - offsetof(member)), 1) : 0; \ pos = (void *)pos->next) So that 'pos' is NULL if the loop terminates. No pointers outside structures are generated. Probably need to kill list_entry_is_head() - or it just checks for NULL. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev3)
== Series Details == Series: Remove usage of list iterator past the loop body (rev3) URL : https://patchwork.freedesktop.org/series/100822/ State : failure == Summary == fatal: empty ident name (for <>) not allowed Applying: drivers: usb: remove usage of list iterator past the loop body Applying: treewide: remove using list iterator after loop body as a ptr
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
From: Linus Torvalds > Sent: 28 February 2022 19:56 > On Mon, Feb 28, 2022 at 4:19 AM Christian König > wrote: > > > > I don't think that using the extra variable makes the code in any way > > more reliable or easier to read. > > So I think the next step is to do the attached patch (which requires > that "-std=gnu11" that was discussed in the original thread). > > That will guarantee that the 'pos' parameter of list_for_each_entry() > is only updated INSIDE the for_each_list_entry() loop, and can never > point to the (wrongly typed) head entry. > > And I would actually hope that it should actually cause compiler > warnings about possibly uninitialized variables if people then use the > 'pos' pointer outside the loop. Except > > (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for > inexplicable reasons - possibly because it already expected this > behavior > > (b) when I remove that NULL initializer, I still don't get a warning, > because we've disabled -Wno-maybe-uninitialized since it results in so > many false positives. > > Oh well. > > Anyway, give this patch a look, and at least if it's expanded to do > "(pos) = NULL" in the entry statement for the for-loop, it will avoid > the HEAD type confusion that Jakob is working on. And I think in a > cleaner way than the horrid games he plays. > > (But it won't avoid possible CPU speculation of such type confusion. > That, in my opinion, is a completely different issue) > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. > > Anybody have any ideas? > > Linus diff --git a/include/linux/list.h b/include/linux/list.h index dd6c2041d09c..bab995596aaa 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -634,10 +634,10 @@ static inline void list_splice_tail_init(struct list_head *list, * @head: the head for your list. * @member:the name of the list_head within the struct. */ -#define list_for_each_entry(pos, head, member) \ - for (pos = list_first_entry(head, typeof(*pos), member);\ -!list_entry_is_head(pos, head, member);\ -pos = list_next_entry(pos, member)) +#define list_for_each_entry(pos, head, member) \ + for (typeof(pos) __iter = list_first_entry(head, typeof(*pos), member); \ +!list_entry_is_head(__iter, head, member) && (((pos)=__iter),1); \ +__iter = list_next_entry(__iter, member)) /** * list_for_each_entry_reverse - iterate backwards over list of given type. I think you actually want: !list_entry_is_head(__iter, head, member) ? (((pos)=__iter),1) : (((pos) = NULL),0); Which can be done in the original by: !list_entry_is_head(pos, head, member) ? 1 : (((pos) = NULL), 0); Although it would be safer to have (without looking up the actual name): for (item *__item = head; \ __item ? (((pos) = list_item(__item, member)), 1) : (((pos) = NULL), 0); __item = (pos)->member) The local does need 'fixing' to avoid shadowing for nested loops. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Clear compress metadata for Xe_HP platforms
== Series Details ==
Series: drm/i915/gt: Clear compress metadata for Xe_HP platforms
URL : https://patchwork.freedesktop.org/series/100856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22442
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/index.html
Participating hosts (46 -> 40)
--
Additional (1): bat-jsl-2
Missing(7): shard-tglu shard-rkl fi-bsw-cyan bat-dg2-9 bat-rpls-2
shard-dg1 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22442 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-blb-e6850/igt@amdgpu/amd_cs_...@fork-compute0.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][2] -> [FAIL][3] ([i915#4032])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@kms_force_connector_basic@force-connector-state:
- bat-adlp-4: [PASS][4] -> [DMESG-WARN][5] ([i915#3576])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_force_connector_ba...@force-connector-state.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/bat-adlp-4/igt@kms_force_connector_ba...@force-connector-state.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][6] ([i915#541]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][8] ([i915#5026]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][10] ([i915#3576]) -> [PASS][11] +1
similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][12] ([i915#165]) -> [PASS][13] +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-cfl-8109u: [DMESG-WARN][14] ([i915#165] / [i915#295]) ->
[PASS][15] +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-cfl-8109u/igt@kms_force_connector_ba...@prune-stale-modes.html
Warnings
* igt@kms_frontbuffer_tracking@basic:
- fi-cfl-8109u: [DMESG-WARN][16] ([i915#165] / [i915#295]) ->
[DMESG-FAIL][17] ([i915#295])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][18] ([i915#165] / [i915#295]) ->
[DMESG-WARN][19] ([i915#295]) +10 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22442/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#295]: https://gitlab.freedesktop.org/drm/intel/i
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
== Series Details ==
Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
URL : https://patchwork.freedesktop.org/series/100851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22441
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/index.html
Participating hosts (46 -> 33)
--
Missing(13): fi-bdw-samus shard-tglu bat-dg1-6 bat-dg1-5 shard-rkl
bat-dg2-9 fi-bsw-cyan bat-adlp-6 bat-adlp-4 fi-pnv-d510 bat-rpls-2 shard-dg1
bat-jsl-1
Known issues
Here are the changes found in Patchwork_22441 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-multi-fence:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-blb-e6850/igt@amdgpu/amd_ba...@cs-multi-fence.html
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [PASS][2] -> [INCOMPLETE][3] ([i915#4547])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html
* igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][4] -> [INCOMPLETE][5] ([i915#4983])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][6] ([i915#541]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][8] ([i915#5026]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][10] ([i915#165]) -> [PASS][11] +1
similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][12] ([i915#165] / [i915#295]) ->
[PASS][13] +13 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026
[i915#5127]: https://gitlab.freedesktop.org/drm/intel/issues/5127
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11300 -> Patchwork_22441
CI-20190529: 20190529
CI_DRM_11300: 10eb9bc8729d3da3fe8f53c8e5b70b8a9a52b6e0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6361: 2372a4beb6a33c5f0799a4a8ccbb93794f52dbca @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22441: 7ba5645d82fa47b563026775f555df287a6d59bb @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7ba5645d82fa drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22441/index.html
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 4:45 PM Linus Torvalds wrote: > > Yeah, except that's ugly beyond belief, plus it's literally not what > we do in the kernel. (Of course, I probably shouldn't have used 'min()' as an example, because that is actually one of the few places where we do exactly that, using our __UNIQUE_ID() macros. Exactly because people _have_ tried to do -Wshadow when doing W=2). Linus
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool wrote: > > In C its scope is the rest of the declaration and the entire loop, not > anything after it. This was the same in C++98 already, btw (but in > pre-standard versions of C++ things were like you remember, yes, and it > was painful). Yeah, the original C++ model was just unadulterated garbage, with no excuse for it, and the scope was not the loop, but the block the loop existed in. That would never have been acceptable for the kernel - it's basically just an even uglier version of "put variable declarations in the middle of code" (and we use "-Wdeclaration-after-statement" to disallow that for kernel code, although apparently some of our user space tooling code doesn't enforce or follow that rule). The actual C99 version is the sane one which actually makes it easier and clearer to have loop iterators that are clearly just in loop scope. That's a good idea in general, and I have wanted to start using that in the kernel even aside from some of the loop construct macros. Because putting variables in natural minimal scope is a GoodThing(tm). Of course, we shouldn't go crazy with it. Even after we do that -std=gnu11 thing, we'll have backports to worry about. And it's not clear that we necessarily want to backport that gnu11 thing - since people who run old stable kernels also may be still using those really old compilers... Linus
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 3:26 PM Matthew Wilcox wrote:
>
> #define ___PASTE(a, b) a##b
> #define __PASTE(a, b) ___PASTE(a, b)
> #define _min(a, b, u) ({ \
Yeah, except that's ugly beyond belief, plus it's literally not what
we do in the kernel.
Really. The "-Wshadow doesn't work on the kernel" is not some new
issue, because you have to do completely insane things to the source
code to enable it.
Just compare your uglier-than-sin version to my straightforward one.
One does the usual and obvious "use a private variable to avoid the
classic multi-use of a macro argument". And the other one is an
abomination.
Linus
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel wrote: > > The goal of this is to get compiler warnings right? This would indeed be > great. Yes, so I don't mind having a one-time patch that has been gathered using some automated checker tool, but I don't think that works from a long-term maintenance perspective. So if we have the basic rule being "don't use the loop iterator after the loop has finished, because it can cause all kinds of subtle issues", then in _addition_ to fixing the existing code paths that have this issue, I really would want to (a) get a compiler warning for future cases and (b) make it not actually _work_ for future cases. Because otherwise it will just happen again. > Changing the list_for_each_entry() macro first will break all of those cases > (e.g. the ones using 'list_entry_is_head()). So I have no problems with breaking cases that we basically already have a patch for due to your automated tool. There were certainly more than a handful, but it didn't look _too_ bad to just make the rule be "don't use the iterator after the loop". Of course, that's just based on that patch of yours. Maybe there are a ton of other cases that your patch didn't change, because they didn't match your trigger case, so I may just be overly optimistic here. But basically to _me_, the important part is that the end result is maintainable longer-term. I'm more than happy to have a one-time patch to fix a lot of dubious cases if we can then have clean rules going forward. > I assumed it is better to fix those cases first and then have a simple > coccinelle script changing the macro + moving the iterator into the scope > of the macro. So that had been another plan of mine, until I actually looked at changing the macro. In the one case I looked at, it was ugly beyond belief. It turns out that just syntactically, it's really nice to give the type of the iterator from outside the way we do now. Yeah, it may be a bit odd, and maybe it's partly because I'm so used to the "list_for_each_list_entry()" syntax, but moving the type into the loop construct really made it nasty - either one very complex line, or having to split it over two lines which was even worse. Maybe the place I looked at just happened to have a long typename, but it's basically always going to be a struct, so it's never a _simple_ type. And it just looked very odd adn unnatural to have the type as one of the "arguments" to that list_for_each_entry() macro. So yes, initially my idea had been to just move the iterator entirely inside the macro. But specifying the type got so ugly that I think that typeof (pos) pos trick inside the macro really ends up giving us the best of all worlds: (a) let's us keep the existing syntax and code for all the nice cases that did everything inside the loop anyway (b) gives us a nice warning for any normal use-after-loop case (unless you explicitly initialized it like that sgx_mmu_notifier_release() function did for no good reason (c) also guarantees that even if you don't get a warning, non-converted (or newly written) bad code won't actually _work_ so you end up getting the new rules without any ambiguity or mistaken > With this you are no longer able to set the 'outer' pos within the list > iterator loop body or am I missing something? Correct. Any assignment inside the loop will be entirely just to the local loop case. So any "break;" out of the loop will have to set another variable - like your updated patch did. > I fail to see how this will make most of the changes in this > patch obsolete (if that was the intention). I hope my explanation above clarifies my thinking: I do not dislike your patch, and in fact your patch is indeed required to make the new semantics work. What I disliked was always the maintainability of your patch - making the rules be something that isn't actually visible in the source code, and letting the old semantics still work as well as they ever did, and having to basically run some verification pass to find bad users. (I also disliked your original patch that mixed up the "CPU speculation type safety" with the actual non-speculative problems, but that was another issue). Linus
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query helper function to not modify state
On 2/17/2022 1:29 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A flag query helper was actually writing to the flags word rather than
just reading. Fix that. Also update the function's comment as it was
out of date.
NB: No need for a 'Fixes' tag. The test was only ever used inside a
BUG_ON during context registration. Rather than asserting that the
condition was true, it was making the condition true. So, in theory,
there was no consequence because we should never have hit a BUG_ON
anyway. Which means the write should always have been a no-op.
Signed-off-by: John Harrison
I seem to have confused patchwork by doing a cut & paste of my r-b from
a different review, so here it is again:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
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 b3a429a92c0d..d9f4218f5ef4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -174,11 +174,8 @@ static inline void init_sched_state(struct intel_context
*ce)
__maybe_unused
static bool sched_state_is_init(struct intel_context *ce)
{
- /*
-* XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED after
-* suspend.
-*/
- return !(ce->guc_state.sched_state &=
+ /* Kernel contexts can have SCHED_STATE_REGISTERED after suspend. */
+ return !(ce->guc_state.sched_state &
~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
}
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
== Series Details == Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities URL : https://patchwork.freedesktop.org/series/100851/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7ba5645d82fa drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities -:35: WARNING:TYPO_SPELLING: 'capabilites' may be misspelled - perhaps 'capabilities'? #35: The standard requires the DPCD capabilites to be read after the LTTPR ^^^ -:50: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #50: FILE: drivers/gpu/drm/dp/drm_dp.c:2393: +static int drm_dp_read_lttpr_regs(struct drm_dp_aux *aux, const u8 dpcd[DP_RECEIVER_CAP_SIZE], int address, -:165: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #165: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:81: +static bool intel_dp_read_lttpr_common_caps(struct intel_dp *intel_dp, const u8 dpcd[DP_RECEIVER_CAP_SIZE]) total: 0 errors, 3 warnings, 0 checks, 182 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/100847/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22439 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22439 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22439, 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_22439/index.html Participating hosts (46 -> 42) -- Additional (1): bat-jsl-2 Missing(5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22439: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@module-reload: - bat-adlp-4: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/bat-adlp-4/igt@i915_pm_...@module-reload.html Known issues Here are the changes found in Patchwork_22439 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@fork-compute0: - fi-blb-e6850: NOTRUN -> [SKIP][3] ([fdo#109271]) +17 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/fi-blb-e6850/igt@amdgpu/amd_cs_...@fork-compute0.html * igt@i915_pm_rps@basic-api: - bat-dg1-5: [PASS][4] -> [FAIL][5] ([i915#4032]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/bat-dg1-5/igt@i915_pm_...@basic-api.html * igt@kms_flip@basic-plain-flip@a-edp1: - bat-adlp-4: [PASS][6] -> [DMESG-WARN][7] ([i915#3576]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@prime_vgem@basic-userptr: - fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271]) +18 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/fi-skl-6600u/igt@prime_v...@basic-userptr.html * igt@runner@aborted: - bat-adlp-4: NOTRUN -> [FAIL][9] ([i915#4312]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/bat-adlp-4/igt@run...@aborted.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-glk-dsi: [DMESG-FAIL][10] ([i915#541]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@requests: - fi-blb-e6850: [DMESG-FAIL][12] ([i915#5026]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/fi-blb-e6850/igt@i915_selftest@l...@requests.html * igt@kms_flip@basic-flip-vs-modeset@a-edp1: - bat-adlp-4: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html * igt@kms_force_connector_basic@force-connector-state: - fi-cfl-8109u: [DMESG-WARN][16] ([i915#165]) -> [PASS][17] +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-cfl-8109u: [DMESG-WARN][18] ([i915#165] / [i915#295]) -> [PASS][19] +13 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22439/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: [FAIL][20] ([i915#4547]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-skl-6600u/igt@kms_psr@primary_page_flip.html [21]: https://intel
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev2)
== Series Details ==
Series: Remove usage of list iterator past the loop body (rev2)
URL : https://patchwork.freedesktop.org/series/100822/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_ids.o
In file included from ./include/linux/kernel.h:21,
from ./arch/x86/include/asm/percpu.h:27,
from ./arch/x86/include/asm/current.h:6,
from ./include/linux/mutex.h:14,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h:27,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:23:
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c: In function ‘amdgpu_vmid_grab_idle’:
./include/linux/container_of.h:17:41: error: initialization of ‘struct
amdgpu_vmid **’ from incompatible pointer type ‘struct amdgpu_vmid *’
[-Werror=incompatible-pointer-types]
#define container_of(ptr, type, member) ({\
^
./include/linux/list.h:520:2: note: in expansion of macro ‘container_of’
container_of(ptr, type, member)
^~~~
./include/linux/list.h:531:2: note: in expansion of macro ‘list_entry’
list_entry((ptr)->next, type, member)
^~
./include/linux/list.h:638:25: note: in expansion of macro ‘list_first_entry’
for (typeof(pos) pos = list_first_entry(head, typeof(*pos), member); \
^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c:216:2: note: in expansion of macro
‘list_for_each_entry’
list_for_each_entry((*idle), &id_mgr->ids_lru, list) {
^~~
cc1: some warnings being treated as errors
scripts/Makefile.build:288: recipe for target
'drivers/gpu/drm/amd/amdgpu/amdgpu_ids.o' failed
make[4]: *** [drivers/gpu/drm/amd/amdgpu/amdgpu_ids.o] Error 1
scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/amd/amdgpu'
failed
make[3]: *** [drivers/gpu/drm/amd/amdgpu] Error 2
scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1831: recipe for target 'drivers' failed
make: *** [drivers] Error 2
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/100847/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/100847/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0ae83c35ff14 drm/mm: Add an iterator to optimally walk over holes for an allocation (v5) -:157: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects? #157: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + mode & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = mode & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + mode & ~DRM_MM_INSERT_ONCE)) -:157: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mm' - possible side-effects? #157: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + mode & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = mode & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + mode & ~DRM_MM_INSERT_ONCE)) -:157: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'size' - possible side-effects? #157: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + mode & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = mode & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + mode & ~DRM_MM_INSERT_ONCE)) -:157: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mode' - possible side-effects? #157: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + mode & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = mode & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + mode & ~DRM_MM_INSERT_ONCE)) -:157: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'mode' may be better as '(mode)' to avoid precedence issues #157: FILE: include/drm/drm_mm.h:430: +#define drm_mm_for_each_suitable_hole(pos, mm, range_start, range_end, \ + size, mode) \ + for (pos = __drm_mm_first_hole(mm, range_start, range_end, size, \ + mode & ~DRM_MM_INSERT_ONCE); \ +pos; \ +pos = mode & DRM_MM_INSERT_ONCE ? \ +NULL : __drm_mm_next_hole(mm, pos, size, \ + mode & ~DRM_MM_INSERT_ONCE)) total: 0 errors, 0 warnings, 5 checks, 114 lines checked 81e2ccf8eadb drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)
== Series Details ==
Series: series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)
URL : https://patchwork.freedesktop.org/series/100771/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22438
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/index.html
Participating hosts (46 -> 41)
--
Additional (1): bat-jsl-2
Missing(6): shard-tglu fi-bsw-cyan fi-pnv-d510 shard-rkl shard-dg1
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22438 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-blb-e6850/igt@amdgpu/amd_cs_...@fork-compute0.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][2] -> [INCOMPLETE][3] ([i915#4547])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][4] -> [FAIL][5] ([i915#4032])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][6] -> [INCOMPLETE][7] ([i915#2940])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- bat-adlp-4: [PASS][8] -> [DMESG-WARN][9] ([i915#3576])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/bat-adlp-4/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#1436] /
[i915#3428] / [i915#4312])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-bsw-kefka/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][11] ([i915#541]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][13] ([i915#5026]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_busy@basic@modeset:
- bat-adlp-4: [DMESG-WARN][15] ([i915#3576]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@ba...@modeset.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/bat-adlp-4/igt@kms_busy@ba...@modeset.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][17] ([i915#165]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][19] ([i915#165] / [i915#295]) ->
[PASS][20] +13 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22438/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/i
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 12:37:15PM -0800, Linus Torvalds wrote:
> On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote:
> >
> > Then we can never use -Wshadow ;-( I'd love to be able to turn it on;
> > it catches real bugs.
>
> Oh, we already can never use -Wshadow regardless of things like this.
> That bridge hasn't just been burned, it never existed in the first
> place.
>
> The whole '-Wshadow' thing simply cannot work with local variables in
> macros - something that we've used since day 1.
>
> Try this (as a "p.c" file):
>
> #define min(a,b) ({ \
> typeof(a) __a = (a);\
> typeof(b) __b = (b);\
> __a < __b ? __a : __b; })
>
> int min3(int a, int b, int c)
> {
> return min(a,min(b,c));
> }
>
> and now do "gcc -O2 -S t.c".
>
> Then try it with -Wshadow.
#define ___PASTE(a, b) a##b
#define __PASTE(a, b) ___PASTE(a, b)
#define _min(a, b, u) ({ \
typeof(a) __PASTE(__a,u) = (a);\
typeof(b) __PASTE(__b,u) = (b);\
__PASTE(__a,u) < __PASTE(__b,u) ? __PASTE(__a,u) : __PASTE(__b,u); })
#define min(a, b) _min(a, b, __COUNTER__)
int min3(int a, int b, int c)
{
return min(a,min(b,c));
}
(probably there's a more elegant way to do this)
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)
== Series Details == Series: series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2) URL : https://patchwork.freedesktop.org/series/100771/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)
== Series Details == Series: series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2) URL : https://patchwork.freedesktop.org/series/100771/ State : warning == Summary == $ dim checkpatch origin/drm-tip e9d80367b6a2 drm/i915: Use str_yes_no() -:333: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #333: FILE: drivers/gpu/drm/i915/display/intel_display_trace.h:213: + str_yes_no(__entry->cxsr), __entry->sr_plane, __entry->sr_cursor, __entry->sr_fbc, -:334: WARNING:LONG_LINE: line length of 110 exceeds 100 columns #334: FILE: drivers/gpu/drm/i915/display/intel_display_trace.h:214: + str_yes_no(__entry->hpll), __entry->hpll_plane, __entry->hpll_cursor, __entry->hpll_fbc, -:553: WARNING:LONG_LINE: line length of 107 exceeds 100 columns #553: FILE: drivers/gpu/drm/i915/gt/intel_engine_cs.c:1645: + str_yes_no(test_bit(TASKLET_STATE_SCHED, &engine->sched_engine->tasklet.state)), -:730: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #730: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c:316: + str_yes_no((rpmodectl & GEN6_RP_MEDIA_MODE_MASK) == GEN6_RP_MEDIA_SW_MODE)); -:746: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #746: FILE: drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c:425: + str_yes_no((rpmodectl & GEN6_RP_MEDIA_MODE_MASK) == GEN6_RP_MEDIA_SW_MODE)); -:1185: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as '(name)' to avoid precedence issues #1185: FILE: drivers/gpu/drm/i915/intel_device_info.c:115: +#define PRINT_FLAG(name) drm_printf(p, "%s: %s\n", #name, str_yes_no(info->name)) total: 0 errors, 5 warnings, 1 checks, 1085 lines checked af443bb6aa4e drm/i915: Use str_enable_disable() ee78b0e8d699 drm/i915: Use str_enabled_disabled() d9a9387b3b12 drm/i915: Use str_on_off()
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Prepare for Xe_HP compute engines
== Series Details ==
Series: i915: Prepare for Xe_HP compute engines
URL : https://patchwork.freedesktop.org/series/100833/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22437
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/index.html
Participating hosts (46 -> 41)
--
Missing(5): shard-tglu fi-bsw-cyan shard-rkl shard-dg1 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22437 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/fi-blb-e6850/igt@amdgpu/amd_cs_...@fork-compute0.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][3] -> [FAIL][4] ([i915#4032])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][5] -> [INCOMPLETE][6] ([i915#4418])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- bat-adlp-4: [PASS][7] -> [DMESG-WARN][8] ([i915#3576])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-adlp-4/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
* igt@runner@aborted:
- bat-dg1-5: NOTRUN -> [FAIL][9] ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-dg1-5/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][10] ([i915#541]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][12] ([i915#4494] / [i915#4957]) ->
[PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][14] ([i915#3921]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][16] ([i915#5026]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [INCOMPLETE][18] -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-rpls-2/igt@i915_selftest@l...@reset.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][20] ([i915#3576]) -> [PASS][21] +1
similar issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][22] ([i915#165]) -> [PASS][23] +1
similar issue
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22437/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][24] ([i915#165] / [i915#295]) ->
[PASS][25
[Intel-gfx] ✓ Fi.CI.BAT: success for HAX: drm/i915: Disable GuC submission on DG1
== Series Details ==
Series: HAX: drm/i915: Disable GuC submission on DG1
URL : https://patchwork.freedesktop.org/series/100826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22436
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/index.html
Participating hosts (46 -> 40)
--
Missing(6): shard-tglu fi-bsw-cyan fi-pnv-d510 shard-rkl shard-dg1
fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22436 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][2] ([i915#4528] / [i915#5026])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@late_gt_pm:
- fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] ([i915#2927] /
[i915#3428])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-bsw-n3050/igt@i915_selftest@live@late_gt_pm.html
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#1436] /
[i915#3428] / [i915#4312])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-bsw-n3050/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][6] ([i915#541]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][8] ([i915#4494] / [i915#4957]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5: [DMESG-FAIL][10] ([i915#4494] / [i915#4957]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][12] ([i915#3921]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][14] ([i915#5026]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- bat-adlp-4: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17] +1
similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][18] ([i915#165]) -> [PASS][19] +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][20] ([i915#165] / [i915#295]) ->
[PASS][21] +13 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22436/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#165]: https://gitlab.freedesktop.org/drm/intel/iss
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Prepare for Xe_HP compute engines
== Series Details == Series: i915: Prepare for Xe_HP compute engines URL : https://patchwork.freedesktop.org/series/100833/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Prepare for Xe_HP compute engines
== Series Details ==
Series: i915: Prepare for Xe_HP compute engines
URL : https://patchwork.freedesktop.org/series/100833/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aeab2e429058 drm/i915/xehp: Define compute class and engine
794deed65cd5 drm/i915/xehp: CCS shares the render reset domain
83e3525cfb56 drm/i915/xehp: Add Compute CS IRQ handlers
c1e9139a6d18 drm/i915/xehp: compute engine pipe_control
-:97: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#97: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:231:
+#define PIPE_CONTROL_AMFS_FLUSH (1<<25) /* gen12+ */
^
-:102: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#102: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:236:
+#define PIPE_CONTROL_GLOBAL_SNAPSHOT_RESET (1<<19)
^
-:104: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#104: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:238:
+#define PIPE_CONTROL_PSD_SYNC(1<<17) /*
gen11+ */
^
total: 0 errors, 0 warnings, 3 checks, 95 lines checked
25857870fcd9 drm/i915/xehp: CCS should use RCS setup functions
4644209c10d6 drm/i915: Move context descriptor fields to intel_lrc.h
a384c36be225 drm/i915/xehp: Define context scheduling attributes in lrc
descriptor
4060c5ce8fe7 drm/i915/xehp/guc: enable compute engine inside GuC
8c2a3081039e drm/i915/xehp: Enable ccs/dual-ctx in RCU_MODE
dee0a41826f5 drm/i915/xehp: Don't support parallel submission on compute /
render
-:44: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional
statements (16, 23)
#44: FILE: drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c:158:
+ if (class == COMPUTE_CLASS || class == RENDER_CLASS)
+ continue;
-:45: WARNING:TABSTOP: Statements should start on a tabstop
#45: FILE: drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c:159:
+ continue;
total: 0 errors, 2 warnings, 0 checks, 26 lines checked
e2d994ffd124 drm/i915/xehp: handle fused off CCS engines
-:46: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#46: FILE: drivers/gpu/drm/i915/gt/intel_engine_cs.c:607:
+ const unsigned long ccs_mask = intel_slicemask_from_dssmask(
total: 0 errors, 0 warnings, 1 checks, 80 lines checked
2ea92310ad16 drm/i915/xehp: Add compute workarounds
-:51: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#51: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1224:
+ cs = gen8_emit_pipe_control(cs,
PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE, 0);
total: 0 errors, 1 warnings, 0 checks, 84 lines checked
1d7e9a4c4f20 drm/i915/xehpsdv: Move render/compute engine reset domains related
workarounds
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query helper function to not modify state
On 2/17/2022 1:29 PM, john.c.harri...@intel.com wrote:
From: John Harrison
A flag query helper was actually writing to the flags word rather than
just reading. Fix that. Also update the function's comment as it was
out of date.
NB: No need for a 'Fixes' tag. The test was only ever used inside a
BUG_ON during context registration. Rather than asserting that the
condition was true, it was making the condition true. So, in theory,
there was no consequence because we should never have hit a BUG_ON
anyway. Which means the write should always have been a no-op.
Signed-off-by: John Harrison
|Reviewed-by: Daniele Ceraolo Spurio
Daniele|
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
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 b3a429a92c0d..d9f4218f5ef4 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -174,11 +174,8 @@ static inline void init_sched_state(struct intel_context
*ce)
__maybe_unused
static bool sched_state_is_init(struct intel_context *ce)
{
- /*
-* XXX: Kernel contexts can have SCHED_STATE_NO_LOCK_REGISTERED after
-* suspend.
-*/
- return !(ce->guc_state.sched_state &=
+ /* Kernel contexts can have SCHED_STATE_REGISTERED after suspend. */
+ return !(ce->guc_state.sched_state &
~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
}
Re: [Intel-gfx] [PATCH v7 09/13] drm/i915/guc: Check sizing of guc_capture output
Hi Alan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc6
next-20220228]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Alan-Previn/Add-GuC-Error-Capture-Support/20220226-175600
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386-allyesconfig
(https://download.01.org/0day-ci/archive/20220301/202203010622.2jydeohx-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d271fc04d5b97b12e6b797c6067d3c96a8d7470e)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/4c41838b35d9a5c0bcb4380e0064cb2d5d33661f
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Alan-Previn/Add-GuC-Error-Capture-Support/20220226-175600
git checkout 4c41838b35d9a5c0bcb4380e0064cb2d5d33661f
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:555:1: error: no previous
prototype for function 'intel_guc_capture_getlistsize'
[-Werror,-Wmissing-prototypes]
intel_guc_capture_getlistsize(struct intel_guc *guc, u32 owner, u32 type,
u32 classid,
^
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:554:1: note: declare 'static'
if the function is not intended to be used outside of this translation unit
int
^
static
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:585:1: error: no previous
prototype for function 'intel_guc_capture_getlist'
[-Werror,-Wmissing-prototypes]
intel_guc_capture_getlist(struct intel_guc *guc, u32 owner, u32 type, u32
classid,
^
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:584:1: note: declare 'static'
if the function is not intended to be used outside of this translation unit
int
^
static
>> drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:648:5: error: no previous
>> prototype for function 'intel_guc_capture_output_min_size_est'
>> [-Werror,-Wmissing-prototypes]
int intel_guc_capture_output_min_size_est(struct intel_guc *guc)
^
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:648:1: note: declare 'static'
if the function is not intended to be used outside of this translation unit
int intel_guc_capture_output_min_size_est(struct intel_guc *guc)
^
static
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:711:6: error: no previous
prototype for function 'intel_guc_capture_destroy'
[-Werror,-Wmissing-prototypes]
void intel_guc_capture_destroy(struct intel_guc *guc)
^
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:711:1: note: declare 'static'
if the function is not intended to be used outside of this translation unit
void intel_guc_capture_destroy(struct intel_guc *guc)
^
static
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:727:5: error: no previous
prototype for function 'intel_guc_capture_init' [-Werror,-Wmissing-prototypes]
int intel_guc_capture_init(struct intel_guc *guc)
^
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:727:1: note: declare 'static'
if the function is not intended to be used outside of this translation unit
int intel_guc_capture_init(struct intel_guc *guc)
^
static
5 errors generated.
vim +/intel_guc_capture_output_min_size_est +648
drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
646
647 #define GUC_CAPTURE_OVERBUFFER_MULTIPLIER 3
> 648 int intel_guc_capture_output_min_size_est(struct intel_guc *guc)
649 {
650 struct intel_gt *gt = guc_to_gt(guc);
651 struct intel_engine_cs *engine;
652 enum intel_engine_id id;
653 int worst_min_size = 0, num_regs = 0;
654 size_t tmp = 0;
655
656 /*
657 * If every single engine-instance suffered a failure in quick
succession but
658 * were all unrelated, then a burst of multiple error-capture
events would dump
659 * registers for every one engine instance, one at a time. In
this case, GuC
660 * would even dump the global-registers repeatedly.
661 *
662 * For eac
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote:
>
> On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
[...]
> > > > I do wish we could actually poison the 'pos' value after the
> > > > loop somehow - but clearly the "might be uninitialized" I was
> > > > hoping for isn't the way to do it.
> > > >
> > > > Anybody have any ideas?
> > >
> > > I think we should look at the use cases why code is touching
> > > (pos) after the loop.
> > >
> > > Just from skimming over the patches to change this and experience
> > > with the drivers/subsystems I help to maintain I think the
> > > primary pattern looks something like this:
> > >
> > > list_for_each_entry(entry, head, member) {
> > > if (some_condition_checking(entry))
> > > break;
> > > }
> > > do_something_with(entry);
> >
> > Actually, we usually have a check to see if the loop found
> > anything, but in that case it should something like
> >
> > if (list_entry_is_head(entry, head, member)) {
> >return with error;
> > }
> > do_somethin_with(entry);
> >
> > Suffice? The list_entry_is_head() macro is designed to cope with
> > the bogus entry on head problem.
>
> Won't suffice because the end goal of this work is to limit scope of
> entry only to loop. Hence the need for additional variable.
Well, yes, but my objection is more to the size of churn than the
desire to do loop local. I'm not even sure loop local is possible,
because it's always annoyed me that for (int i = 0; ... in C++ defines
i in the outer scope not the loop scope, which is why I never use it.
However, if the desire is really to poison the loop variable then we
can do
#define list_for_each_entry(pos, head, member) \
for (pos = list_first_entry(head, typeof(*pos), member);\
!list_entry_is_head(pos, head, member) && ((pos = NULL) == NULL;
\
pos = list_next_entry(pos, member))
Which would at least set pos to NULL when the loop completes.
> Besides, there are no guarantees that people won't
> do_something_with(entry) without the check or won't compare entry to
> NULL to check if the loop finished with break or not.
I get the wider goal, but we have to patch the problem cases now and a
simple one-liner is better than a larger patch that may or may not work
if we ever achieve the local definition or value poisoning idea. I'm
also fairly certain coccinelle can come up with a use without checking
for loop completion semantic patch which we can add to 0day.
James
[Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: move to -std=gnu11
== Series Details ==
Series: Kbuild: move to -std=gnu11
URL : https://patchwork.freedesktop.org/series/100824/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22435
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/index.html
Participating hosts (44 -> 41)
--
Missing(3): fi-bsw-cyan shard-tglu fi-bdw-samus
Known issues
Here are the changes found in Patchwork_22435 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-multi-fence:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-blb-e6850/igt@amdgpu/amd_ba...@cs-multi-fence.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271]) +18 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][4] -> [FAIL][5] ([i915#4032])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050: [PASS][6] -> [DMESG-FAIL][7] ([i915#2373])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][8] ([i915#541]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][10] ([i915#3921]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][12] ([i915#5026]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_busy@basic@modeset:
- bat-adlp-4: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15] +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@ba...@modeset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/bat-adlp-4/igt@kms_busy@ba...@modeset.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][16] ([i915#165]) -> [PASS][17] +1
similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][18] ([i915#165] / [i915#295]) ->
[PASS][19] +13 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [FAIL][20] ([i915#4547]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22435/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#295]: https://gitlab
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Kbuild: move to -std=gnu11
== Series Details == Series: Kbuild: move to -std=gnu11 URL : https://patchwork.freedesktop.org/series/100824/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: remove -std=gnu89 from compiler arguments
== Series Details ==
Series: Kbuild: remove -std=gnu89 from compiler arguments
URL : https://patchwork.freedesktop.org/series/100823/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22434
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/index.html
Participating hosts (43 -> 41)
--
Additional (1): bat-jsl-2
Missing(3): fi-bsw-cyan fi-bdw-samus fi-pnv-d510
Known issues
Here are the changes found in Patchwork_22434 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-multi-fence:
- fi-blb-e6850: NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-blb-e6850/igt@amdgpu/amd_ba...@cs-multi-fence.html
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4] ([i915#4547])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][5] -> [FAIL][6] ([i915#4032])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-5/igt@i915_pm_...@basic-api.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][7] -> [INCOMPLETE][8] ([i915#4418])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@runner@aborted:
- bat-dg1-6: NOTRUN -> [FAIL][9] ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-dsi: [DMESG-FAIL][10] ([i915#541]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-glk-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][12] ([i915#3921]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][14] ([i915#5026]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_busy@basic@modeset:
- bat-adlp-4: [DMESG-WARN][16] ([i915#3576]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@ba...@modeset.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-adlp-4/igt@kms_busy@ba...@modeset.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-cfl-8109u: [DMESG-WARN][18] ([i915#165]) -> [PASS][19] +1
similar issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-cfl-8109u/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [DMESG-WARN][20] ([i915#165] / [i915#295]) ->
[PASS][21] +13 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
Warnings
* igt@kms_busy@basic@flip:
- bat-adlp-4: [DMESG-WARN][22] ([i915#3576]) -> [DMESG-WARN][23]
([i915#1982] / [i915#3576])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11300/bat-adlp-4/igt@kms_busy@ba...@flip.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22434/bat-adlp-4/igt@kms_busy@ba...@flip.html
{name
Re: [Intel-gfx] [PATCH] drm/i915/gt: Clear compress metadata for Xe_HP platforms
Matt,
This is the continuation of review happened at
https://patchwork.freedesktop.org/patch/475177/?series=100419&rev=1
On 2022-03-01 at 02:51:39 +0530, Ramalingam C wrote:
> From: Ayaz A Siddiqui
>
> Xe-HP and latest devices support Flat CCS which reserved a portion of
> the device memory to store compression metadata, during the clearing of
> device memory buffer object we also need to clear the associated
> CCS buffer.
>
> Flat CCS memory can not be directly accessed by S/W.
> Address of CCS buffer associated main BO is automatically calculated
> by device itself. KMD/UMD can only access this buffer indirectly using
> XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.
>
> v2: Fixed issues with platform naming [Lucas]
> v3: Rebased [Ram]
> Used the round_up funcs [Bob]
> v4: Fixed ccs blk calculation [Ram]
> Added Kdoc on flat-ccs.
> v5: GENMASK is used [Matt]
> mocs fix [Matt]
> Comments Fix [Matt]
> Flush address programming [Ram]
>
> Signed-off-by: Ayaz A Siddiqui
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 ++
> drivers/gpu/drm/i915/gt/intel_migrate.c | 146 ++-
> 2 files changed, 157 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> index f8253012d166..237c1baccc64 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> @@ -203,6 +203,21 @@
> #define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
> #define GFX_OP_DRAWRECT_INFO_I965 ((0x7900<<16)|0x2)
>
> +#define XY_CTRL_SURF_INSTR_SIZE 5
> +#define MI_FLUSH_DW_SIZE 3
> +#define XY_CTRL_SURF_COPY_BLT((2 << 29) | (0x48 << 22) | 3)
> +#define SRC_ACCESS_TYPE_SHIFT 21
> +#define DST_ACCESS_TYPE_SHIFT 20
> +#define CCS_SIZE_MASK GENMASK(17, 8)
> +#define XY_CTRL_SURF_MOCS_MASK GENMASK(31, 25)
> +#define NUM_CCS_BYTES_PER_BLOCK256
> +#define NUM_BYTES_PER_CCS_BYTE 256
> +#define NUM_CCS_BLKS_PER_XFER 1024
> +#define INDIRECT_ACCESS0
> +#define DIRECT_ACCESS 1
> +#define MI_FLUSH_LLCBIT(9)
> +#define MI_FLUSH_CCSBIT(16)
> +
> #define COLOR_BLT_CMD(2 << 29 | 0x40 << 22 | (5 - 2))
> #define XY_COLOR_BLT_CMD (2 << 29 | 0x50 << 22)
> #define SRC_COPY_BLT_CMD (2 << 29 | 0x43 << 22)
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 20444d6ceb3c..26ee6ae0e1bb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -16,6 +16,8 @@ struct insert_pte_data {
> };
>
> #define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
> +#define GET_CCS_BYTES(i915, size)(HAS_FLAT_CCS(i915) ? \
> + DIV_ROUND_UP(size,
> NUM_BYTES_PER_CCS_BYTE) : 0)
>
> static bool engine_supports_migration(struct intel_engine_cs *engine)
> {
> @@ -467,6 +469,113 @@ static bool wa_1209644611_applies(int ver, u32 size)
> return height % 4 == 3 && height <= 8;
> }
>
> +/**
> + * DOC: Flat-CCS - Memory compression for Local memory
> + *
> + * On Xe-HP and later devices, we use dedicated compression control state
> (CCS)
> + * stored in local memory for each surface, to support the 3D and media
> + * compression formats.
> + *
> + * The memory required for the CCS of the entire local memory is 1/256 of the
> + * local memory size. So before the kernel boot, the required memory is
> reserved
> + * for the CCS data and a secure register will be programmed with the CCS
> base
> + * address.
> + *
> + * Flat CCS data needs to be cleared when a lmem object is allocated.
> + * And CCS data can be copied in and out of CCS region through
> + * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
> + *
> + * When we exhaust the lmem, if the object's placements support smem, then
> we can
> + * directly decompress the compressed lmem object into smem and start using
> it
> + * from smem itself.
> + *
> + * But when we need to swapout the compressed lmem object into a smem region
> + * though objects' placement doesn't support smem, then we copy the lmem
> content
> + * as it is into smem region along with ccs data (using
> XY_CTRL_SURF_COPY_BLT).
> + * When the object is referred, lmem content will be swaped in along with
> + * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
> + * location.
> + */
> +
> +static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
> +{
> + /* Address needs to be QWORD aligned */
> + GEM_BUG_ON(!IS_ALIGNED(dst, 8));
> +
> + *cmd++ = MI_FLUSH_DW | flags;
> + *cmd++ = lower_32_bits(dst);
> + *cmd++ = upper_32_b
[Intel-gfx] [PATCH] drm/i915/gt: Clear compress metadata for Xe_HP platforms
From: Ayaz A Siddiqui
Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.
Flat CCS memory can not be directly accessed by S/W.
Address of CCS buffer associated main BO is automatically calculated
by device itself. KMD/UMD can only access this buffer indirectly using
XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.
v2: Fixed issues with platform naming [Lucas]
v3: Rebased [Ram]
Used the round_up funcs [Bob]
v4: Fixed ccs blk calculation [Ram]
Added Kdoc on flat-ccs.
v5: GENMASK is used [Matt]
mocs fix [Matt]
Comments Fix [Matt]
Flush address programming [Ram]
Signed-off-by: Ayaz A Siddiqui
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 ++
drivers/gpu/drm/i915/gt/intel_migrate.c | 146 ++-
2 files changed, 157 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f8253012d166..237c1baccc64 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -203,6 +203,21 @@
#define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
#define GFX_OP_DRAWRECT_INFO_I965 ((0x7900<<16)|0x2)
+#define XY_CTRL_SURF_INSTR_SIZE5
+#define MI_FLUSH_DW_SIZE 3
+#define XY_CTRL_SURF_COPY_BLT ((2 << 29) | (0x48 << 22) | 3)
+#define SRC_ACCESS_TYPE_SHIFT21
+#define DST_ACCESS_TYPE_SHIFT20
+#define CCS_SIZE_MASKGENMASK(17, 8)
+#define XY_CTRL_SURF_MOCS_MASK GENMASK(31, 25)
+#define NUM_CCS_BYTES_PER_BLOCK 256
+#define NUM_BYTES_PER_CCS_BYTE 256
+#define NUM_CCS_BLKS_PER_XFER1024
+#define INDIRECT_ACCESS 0
+#define DIRECT_ACCESS1
+#define MI_FLUSH_LLC BIT(9)
+#define MI_FLUSH_CCS BIT(16)
+
#define COLOR_BLT_CMD (2 << 29 | 0x40 << 22 | (5 - 2))
#define XY_COLOR_BLT_CMD (2 << 29 | 0x50 << 22)
#define SRC_COPY_BLT_CMD (2 << 29 | 0x43 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 20444d6ceb3c..26ee6ae0e1bb 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -16,6 +16,8 @@ struct insert_pte_data {
};
#define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
+#define GET_CCS_BYTES(i915, size) (HAS_FLAT_CCS(i915) ? \
+DIV_ROUND_UP(size,
NUM_BYTES_PER_CCS_BYTE) : 0)
static bool engine_supports_migration(struct intel_engine_cs *engine)
{
@@ -467,6 +469,113 @@ static bool wa_1209644611_applies(int ver, u32 size)
return height % 4 == 3 && height <= 8;
}
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exhaust the lmem, if the object's placements support smem, then we
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
+ * location.
+ */
+
+static inline u32 *i915_flush_dw(u32 *cmd, u64 dst, u32 flags)
+{
+ /* Address needs to be QWORD aligned */
+ GEM_BUG_ON(!IS_ALIGNED(dst, 8));
+
+ *cmd++ = MI_FLUSH_DW | flags;
+ *cmd++ = lower_32_bits(dst);
+ *cmd++ = upper_32_bits(dst);
+
+ return cmd;
+}
+
+static u32 calc_ctrl_surf_instr_size(struct drm_i915_private *i915, int size)
+{
+ u32 num_cmds, num_blks, total_size;
+
+ if (!GET_CCS_BYTES(i915, size))
+ return 0;
+
+ /*
+* XY_CTRL_SURF_COPY_BLT transfers CCS in 256 byte
+* blocks. one XY_CTRL_SURF_COPY_BLT command can
+* transfer upto 1024 blocks.
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote:
>
> Am 28.02.22 um 21:42 schrieb James Bottomley:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> > > Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > > > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > > > wrote:
> > > > [SNIP]
> > > > Anybody have any ideas?
> > > I think we should look at the use cases why code is touching
> > > (pos)
> > > after the loop.
> > >
> > > Just from skimming over the patches to change this and experience
> > > with the drivers/subsystems I help to maintain I think the
> > > primary pattern looks something like this:
> > >
> > > list_for_each_entry(entry, head, member) {
> > > if (some_condition_checking(entry))
> > > break;
> > > }
> > > do_something_with(entry);
> >
> > Actually, we usually have a check to see if the loop found
> > anything, but in that case it should something like
> >
> > if (list_entry_is_head(entry, head, member)) {
> > return with error;
> > }
> > do_somethin_with(entry);
> >
> > Suffice? The list_entry_is_head() macro is designed to cope with
> > the bogus entry on head problem.
>
> That will work and is also what people already do.
>
> The key problem is that we let people do the same thing over and
> over again with slightly different implementations.
>
> Out in the wild I've seen at least using a separate variable, using
> a bool to indicate that something was found and just assuming that
> the list has an entry.
>
> The last case is bogus and basically what can break badly.
Yes, I understand that. I'm saying we should replace that bogus checks
of entry->something against some_value loop termination condition with
the list_entry_is_head() macro. That should be a one line and fairly
mechanical change rather than the explosion of code changes we seem to
have in the patch series.
James
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Kbuild: remove -std=gnu89 from compiler arguments
== Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > wrote:
> > > I don't think that using the extra variable makes the code in any
> > > way
> > > more reliable or easier to read.
> > So I think the next step is to do the attached patch (which
> > requires
> > that "-std=gnu11" that was discussed in the original thread).
> >
> > That will guarantee that the 'pos' parameter of
> > list_for_each_entry()
> > is only updated INSIDE the for_each_list_entry() loop, and can
> > never
> > point to the (wrongly typed) head entry.
> >
> > And I would actually hope that it should actually cause compiler
> > warnings about possibly uninitialized variables if people then use
> > the
> > 'pos' pointer outside the loop. Except
> >
> > (a) that code in sgx/encl.c currently initializes 'tmp' to NULL
> > for
> > inexplicable reasons - possibly because it already expected this
> > behavior
> >
> > (b) when I remove that NULL initializer, I still don't get a
> > warning,
> > because we've disabled -Wno-maybe-uninitialized since it results in
> > so
> > many false positives.
> >
> > Oh well.
> >
> > Anyway, give this patch a look, and at least if it's expanded to do
> > "(pos) = NULL" in the entry statement for the for-loop, it will
> > avoid the HEAD type confusion that Jakob is working on. And I think
> > in a cleaner way than the horrid games he plays.
> >
> > (But it won't avoid possible CPU speculation of such type
> > confusion. That, in my opinion, is a completely different issue)
>
> Yes, completely agree.
>
> > I do wish we could actually poison the 'pos' value after the loop
> > somehow - but clearly the "might be uninitialized" I was hoping for
> > isn't the way to do it.
> >
> > Anybody have any ideas?
>
> I think we should look at the use cases why code is touching (pos)
> after the loop.
>
> Just from skimming over the patches to change this and experience
> with the drivers/subsystems I help to maintain I think the primary
> pattern looks something like this:
>
> list_for_each_entry(entry, head, member) {
> if (some_condition_checking(entry))
> break;
> }
> do_something_with(entry);
Actually, we usually have a check to see if the loop found anything,
but in that case it should something like
if (list_entry_is_head(entry, head, member)) {
return with error;
}
do_somethin_with(entry);
Suffice? The list_entry_is_head() macro is designed to cope with the
bogus entry on head problem.
James
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg wrote: > > If we're willing to change the API for the macro, we could do > > list_for_each_entry(type, pos, head, member) > > and then actually take advantage of -Wshadow? See my reply to Willy. There is no way -Wshadow will ever happen. I considered that (type, pos, head, member) kind of thing, to the point of trying it for one file, but it ends up as horrendous syntax. It turns out that declaring the type separately really helps, and avoids crazy long lines among other things. It would be unacceptable for another reason too - the amount of churn would just be immense. Every single use of that macro (and related macros) would change, even the ones that really don't need it or want it (ie the good kinds that already only use the variable inside the loop). So "typeof(pos) pos" may be ugly - but it's a very localized ugly. Linus
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote:
>
> Then we can never use -Wshadow ;-( I'd love to be able to turn it on;
> it catches real bugs.
Oh, we already can never use -Wshadow regardless of things like this.
That bridge hasn't just been burned, it never existed in the first
place.
The whole '-Wshadow' thing simply cannot work with local variables in
macros - something that we've used since day 1.
Try this (as a "p.c" file):
#define min(a,b) ({ \
typeof(a) __a = (a);\
typeof(b) __b = (b);\
__a < __b ? __a : __b; })
int min3(int a, int b, int c)
{
return min(a,min(b,c));
}
and now do "gcc -O2 -S t.c".
Then try it with -Wshadow.
In other words, -Wshadow is simply not acceptable. Never has been,
never will be, and that has nothing to do with the
typeof(pos) pos
kind of thing.
Your argument just isn't an argument.
Linus
Re: [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: Adding new sysfs frequency attributes
On 17.02.2022 15:41, Andi Shyti wrote:
> From: Sujaritha Sundaresan
>
> This patch adds the following new sysfs frequency attributes;
> - punit_req_freq_mhz
> - throttle_reason_status
> - throttle_reason_pl1
> - throttle_reason_pl2
> - throttle_reason_pl4
> - throttle_reason_thermal
> - throttle_reason_prochot
> - throttle_reason_ratl
> - throttle_reason_vr_thermalert
> - throttle_reason_vr_tdc
>
> Signed-off-by: Sujaritha Sundaresan
> Signed-off-by: Andi Shyti
> Cc: Dale B Stimson
> ---
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 142
> drivers/gpu/drm/i915/gt/intel_rps.c | 83
> drivers/gpu/drm/i915/gt/intel_rps.h | 10 ++
> drivers/gpu/drm/i915/i915_reg.h | 11 ++
> 4 files changed, 246 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 8e86b8f675f1..8be676cd1607 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -463,6 +463,141 @@ static ssize_t rps_rp_mhz_show(struct device *dev,
> static const struct attribute * const gen6_rps_attrs[] = GEN6_RPS_ATTR;
> static const struct attribute * const gen6_gt_attrs[] = GEN6_GT_ATTR;
>
> +static ssize_t punit_req_freq_mhz_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + u32 preq = intel_rps_read_punit_req_frequency(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%d\n", preq);
%u since preq is u32
and use sysfs_emit (also in below show functions)
> +}
> +
> +static ssize_t throttle_reason_status_show(struct device *dev,
> +struct device_attribute *attr,
> +char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool status = !!intel_rps_read_throttle_reason_status(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n", status);
> +}
> +
> +static ssize_t throttle_reason_pl1_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool pl1 = !!intel_rps_read_throttle_reason_pl1(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n", pl1);
> +}
> +
> +static ssize_t throttle_reason_pl2_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool pl2 = !!intel_rps_read_throttle_reason_pl2(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n", pl2);
> +}
> +
> +static ssize_t throttle_reason_pl4_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool pl4 = !!intel_rps_read_throttle_reason_pl4(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n", pl4);
> +}
> +
> +static ssize_t throttle_reason_thermal_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool thermal = !!intel_rps_read_throttle_reason_thermal(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n", thermal);
> +}
> +
> +static ssize_t throttle_reason_prochot_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool prochot = !!intel_rps_read_throttle_reason_prochot(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n", prochot);
> +}
> +
> +static ssize_t throttle_reason_ratl_show(struct device *dev,
> + struct device_attribute *attr,
> + char *buff)
> +{
> + struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
> + struct intel_rps *rps = >->rps;
> + bool ratl = !!intel_rps_read_throttle_reason_ratl(rps);
> +
> + return scnprintf(buff, PAGE_SIZE, "%u\n",
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, 2022-02-28 at 20:16 +, Matthew Wilcox wrote: > On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_ 'pos' than > > outside. > > Then we can never use -Wshadow ;-( I'd love to be able to turn it on; > it catches real bugs. > I was just going to say the same thing... If we're willing to change the API for the macro, we could do list_for_each_entry(type, pos, head, member) and then actually take advantage of -Wshadow? johannes
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > We can do > > typeof(pos) pos > > in the 'for ()' loop, and never use __iter at all. > > That means that inside the for-loop, we use a _different_ 'pos' than outside. Then we can never use -Wshadow ;-( I'd love to be able to turn it on; it catches real bugs. > +#define list_for_each_entry(pos, head, member) > \ > + for (typeof(pos) pos = list_first_entry(head, typeof(*pos), member); > \ > + !list_entry_is_head(pos, head, member);\ >pos = list_next_entry(pos, member))
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds wrote: > > We can do > > typeof(pos) pos > > in the 'for ()' loop, and never use __iter at all. > > That means that inside the for-loop, we use a _different_ 'pos' than outside. The thing that makes me throw up in my mouth a bit is that in that typeof(pos) pos the first 'pos' (that we use for just the typeof) is that outer-level 'pos', IOW it's a *different* 'pos' than the second 'pos' in that same declaration that declares the inner level shadowing new 'pos' variable. If I was a compiler person, I would say "Linus, that thing is too ugly to live", and I would hate it. I'm just hoping that even compiler people say "that's *so* ugly it's almost beautiful". Because it does seem to work. It's not pretty, but hey, it's not like our headers are really ever be winning any beauty contests... Linus
[Intel-gfx] [PATCH] drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities
At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted
DPCD register values when reading from the 0xF- LTTPR range with an
AUX transaction block size bigger than 1. The DP standard requires 0 to
be returned - as for any other reserved/invalid addresses - but these
monitors return the DPCD_REV register value repeated in each byte of the
read buffer. This will in turn corrupt the values returned by the LTTPRs
between the source and the monitor: LTTPRs must adjust the values they
read from the downstream DPRX, for instance left-shift/init the
downstream DP_PHY_REPEATER_CNT value. Since the value returned by the
monitor's DPRX is non-zero the adjusted values will be corrupt.
Reading the LTTPR registers one-by-one instead of reading all of them
with a single AUX transfer works around the issue.
According to the DP standard's 0xF register description:
"LTTPR-related registers at DPCD Addresses Fh through F02FFh are
valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4
refers to the DPCD_REV or to the
LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed
at the VESA site to clarify this haven't been addressed), one
possibility is that it's a restriction due to non-compliant monitors
described above. Disabling the non-transparent LTTPR mode for all such
monitors is not a viable solution: the transparent LTTPR mode has its
own issue causing link training failures and this would affect a lot of
monitors in use with DPCD_REV < 1.4. Instead this patch works around
the problem by reading the LTTPR common and PHY cap registers one-by-one
for any monitor with a DPCD_REV < 1.4.
The standard requires the DPCD capabilites to be read after the LTTPR
common capabilities are read, so re-read the DPCD capabilities after
the LTTPR common and PHY caps were read out.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531
Signed-off-by: Imre Deak
---
drivers/gpu/drm/dp/drm_dp.c | 58 ---
.../drm/i915/display/intel_dp_link_training.c | 30 +++---
include/drm/dp/drm_dp_helper.h| 2 +
3 files changed, 59 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/dp/drm_dp.c b/drivers/gpu/drm/dp/drm_dp.c
index 703972ae14c64..f3950d42980f9 100644
--- a/drivers/gpu/drm/dp/drm_dp.c
+++ b/drivers/gpu/drm/dp/drm_dp.c
@@ -2390,9 +2390,36 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+static int drm_dp_read_lttpr_regs(struct drm_dp_aux *aux, const u8
dpcd[DP_RECEIVER_CAP_SIZE], int address,
+ u8 *buf, int buf_size)
+{
+ /*
+* Some monitors with a DPCD_REV < 0x14 return corrupted values when
+* reading from the 0xF- range with a block size bigger than 1.
+*/
+ int block_size = dpcd[DP_DPCD_REV] < 0x14 ? 1 : buf_size;
+ int offset = 0;
+ int ret;
+
+ while (offset < buf_size) {
+ ret = drm_dp_dpcd_read(aux,
+ address + offset,
+ &buf[offset], block_size);
+ if (ret < 0)
+ return ret;
+
+ WARN_ON(ret != block_size);
+
+ offset += block_size;
+ }
+
+ return 0;
+}
+
/**
* drm_dp_read_lttpr_common_caps - read the LTTPR common capabilities
* @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
* @caps: buffer to return the capability info in
*
* Read capabilities common to all LTTPRs.
@@ -2400,25 +2427,19 @@ EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
* Returns 0 on success or a negative error code on failure.
*/
int drm_dp_read_lttpr_common_caps(struct drm_dp_aux *aux,
+ const u8 dpcd[DP_RECEIVER_CAP_SIZE],
u8 caps[DP_LTTPR_COMMON_CAP_SIZE])
{
- int ret;
-
- ret = drm_dp_dpcd_read(aux,
-
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
- caps, DP_LTTPR_COMMON_CAP_SIZE);
- if (ret < 0)
- return ret;
-
- WARN_ON(ret != DP_LTTPR_COMMON_CAP_SIZE);
-
- return 0;
+ return drm_dp_read_lttpr_regs(aux, dpcd,
+
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV,
+ caps, DP_LTTPR_COMMON_CAP_SIZE);
}
EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps);
/**
* drm_dp_read_lttpr_phy_caps - read the capabilities for a given LTTPR PHY
* @aux: DisplayPort AUX channel
+ * @dpcd: DisplayPort configuration data
* @dp_phy: LTTPR PHY to read the capabilities for
* @caps: buffer to return the capability info in
*
@@ -2427,20 +2448,13 @@ EXPORT_SYMBOL(drm_dp_read_lttpr_common_caps);
* Returns 0 on success or a negative error code on failure.
*/
int drm_dp_read_lttpr_phy_caps(struct drm_dp
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds
wrote:
>
> Side note: we do need *some* way to do it.
Ooh.
This patch is a work of art.
And I mean that in the worst possible way.
We can do
typeof(pos) pos
in the 'for ()' loop, and never use __iter at all.
That means that inside the for-loop, we use a _different_ 'pos' than outside.
And then the compiler will not see some "might be uninitialized", but
the outer 'pos' *will* be uninitialized.
Unless, of course, the outer 'pos' had that pointless explicit initializer.
Here - can somebody poke holes in this "work of art" patch?
Linus
Makefile | 2 +-
arch/x86/kernel/cpu/sgx/encl.c | 2 +-
include/linux/list.h | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index daeb5c88b50b..cc4b0a266af0 100644
--- a/Makefile
+++ b/Makefile
@@ -515,7 +515,7 @@ KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
-Werror=implicit-function-declaration -Werror=implicit-int \
-Werror=return-type -Wno-format-security \
- -std=gnu89
+ -std=gnu11
KBUILD_CPPFLAGS := -D__KERNEL__
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_KERNEL :=
diff --git a/arch/x86/kernel/cpu/sgx/encl.c b/arch/x86/kernel/cpu/sgx/encl.c
index 48afe96ae0f0..87db2f3936b0 100644
--- a/arch/x86/kernel/cpu/sgx/encl.c
+++ b/arch/x86/kernel/cpu/sgx/encl.c
@@ -450,7 +450,7 @@ static void sgx_mmu_notifier_release(struct mmu_notifier *mn,
struct mm_struct *mm)
{
struct sgx_encl_mm *encl_mm = container_of(mn, struct sgx_encl_mm, mmu_notifier);
- struct sgx_encl_mm *tmp = NULL;
+ struct sgx_encl_mm *tmp;
/*
* The enclave itself can remove encl_mm. Note, objects can't be moved
diff --git a/include/linux/list.h b/include/linux/list.h
index dd6c2041d09c..708078b2f24d 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -634,9 +634,9 @@ static inline void list_splice_tail_init(struct list_head *list,
* @head: the head for your list.
* @member: the name of the list_head within the struct.
*/
-#define list_for_each_entry(pos, head, member)\
- for (pos = list_first_entry(head, typeof(*pos), member); \
- !list_entry_is_head(pos, head, member); \
+#define list_for_each_entry(pos, head, member) \
+ for (typeof(pos) pos = list_first_entry(head, typeof(*pos), member); \
+ !list_entry_is_head(pos, head, member); \
pos = list_next_entry(pos, member))
/**
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds wrote: > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. Side note: we do need *some* way to do it. Because if we make that change, and only set it to another pointer when not the head, then we very much change the semantics of "list_for_each_head()". The "list was empty" case would now exit with 'pos' not set at all (or set to NULL if we add that). Or it would be set to the last entry. And regardless, that means that all the if (pos == head) kinds of checks after the loop would be fundamentally broken. Darn. I really hoped for (and naively expected) that we could actually have the compiler warn about the use-after-loop case. That whole "compiler will now complain about bad use" was integral to my clever plan to use the C99 feature of declaring the iterator inside the loop. But my "clever plan" was apparently some ACME-level Wile E. Coyote sh*t. Darn. Linus
Re: [Intel-gfx] [PATCH v5 3/7] drm/i915/gt: add gt_is_root() helper
On 17.02.2022 15:41, Andi Shyti wrote:
> The "gt_is_root(struct intel_gt *gt)" helper return true if the
> gt is the root gt, which means that its id is 0. Return false
> otherwise.
>
> Suggested-by: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_gt.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
> b/drivers/gpu/drm/i915/gt/intel_gt.h
> index 915d6192079b..f17f51e2d394 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.h
> @@ -19,6 +19,11 @@ struct drm_printer;
> ##__VA_ARGS__); \
> } while (0)
>
> +static inline bool gt_is_root(struct intel_gt *gt)
> +{
> + return !gt->info.id;
> +}
> +
we could squash this patch with prev one, where it can be used in:
intel_gt_tile_cleanup(struct intel_gt *gt)
{
intel_uncore_cleanup_mmio(gt->uncore);
- if (gt->info.id) {
+ if (!gt_is_root(gt)) {
kfree(gt->uncore);
kfree(gt);
}
}
or just use it this way in this patch, with that:
Reviewed-by: Michal Wajdeczko
> static inline struct intel_gt *uc_to_gt(struct intel_uc *uc)
> {
> return container_of(uc, struct intel_gt, uc);
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware
URL : https://patchwork.freedesktop.org/series/100818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11299 -> Patchwork_22433
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/index.html
Participating hosts (41 -> 41)
--
Additional (1): bat-jsl-2
Missing(1): fi-bsw-cyan
Known issues
Here are the changes found in Patchwork_22433 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][3] -> [INCOMPLETE][4] ([i915#2940])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@modeset:
- bat-adlp-4: [PASS][5] -> [DMESG-WARN][6] ([i915#3576])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/bat-adlp-4/igt@kms_busy@ba...@modeset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/bat-adlp-4/igt@kms_busy@ba...@modeset.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271]) +2 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [INCOMPLETE][10] ([i915#4838])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
Possible fixes
* igt@core_auth@basic-auth:
- fi-kbl-soraka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/fi-kbl-soraka/igt@core_a...@basic-auth.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-kbl-soraka/igt@core_a...@basic-auth.html
* igt@debugfs_test@read_all_entries:
- fi-cfl-8109u: [DMESG-WARN][13] ([i915#203] / [i915#262] /
[i915#295]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-cfl-8109u/igt@debugfs_test@read_all_entries.html
* igt@gem_exec_suspend@basic-s0@smem:
- fi-cfl-8109u: [DMESG-WARN][15] ([i915#203] / [i915#295]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-cfl-8109u/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@smem:
- {fi-rkl-11600}: [INCOMPLETE][17] ([i915#5127]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@workarounds:
- {bat-adlp-6}: [DMESG-WARN][19] ([i915#5068]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][21] ([i915#3576]) -> [PASS][22] +1
similar issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11299/bat-adlp-6/igt@kms_busy@ba...@flip.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22433/bat-adlp-6/igt@kms_busy@ba...@flip.html
{name}: This
Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
On Mon, Feb 28, 2022 at 4:19 AM Christian König wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=gnu11" that was discussed in the original thread). That will guarantee that the 'pos' parameter of list_for_each_entry() is only updated INSIDE the for_each_list_entry() loop, and can never point to the (wrongly typed) head entry. And I would actually hope that it should actually cause compiler warnings about possibly uninitialized variables if people then use the 'pos' pointer outside the loop. Except (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for inexplicable reasons - possibly because it already expected this behavior (b) when I remove that NULL initializer, I still don't get a warning, because we've disabled -Wno-maybe-uninitialized since it results in so many false positives. Oh well. Anyway, give this patch a look, and at least if it's expanded to do "(pos) = NULL" in the entry statement for the for-loop, it will avoid the HEAD type confusion that Jakob is working on. And I think in a cleaner way than the horrid games he plays. (But it won't avoid possible CPU speculation of such type confusion. That, in my opinion, is a completely different issue) I do wish we could actually poison the 'pos' value after the loop somehow - but clearly the "might be uninitialized" I was hoping for isn't the way to do it. Anybody have any ideas? Linus p Description: Binary data
Re: [Intel-gfx] [PATCH v5 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0
On 17.02.2022 15:41, Andi Shyti wrote:
> With the upcoming multitile support each tile will have its own
> local memory. Mark the current LMEM with the suffix '0' to
> emphasise that it belongs to the root tile.
>
> Suggested-by: Michal Wajdeczko
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
> drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 4 ++--
> drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +++---
> drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c | 8
> drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
> drivers/gpu/drm/i915/intel_memory_region.c| 2 +-
> drivers/gpu/drm/i915/intel_memory_region.h| 4 ++--
> 8 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c
> b/drivers/gpu/drm/i915/display/intel_fb.c
> index 23cfe2e5ce2a..421f7238da05 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -1981,7 +1981,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
>
> /* object is backed with LMEM for discrete */
> i915 = to_i915(obj->base.dev);
> - if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
> INTEL_REGION_LMEM)) {
> + if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
> INTEL_REGION_LMEM_0)) {
> /* object is "remote", not in local memory */
> i915_gem_object_put(obj);
> return ERR_PTR(-EREMOTE);
> diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> index a307b4993bcf..bd6e7c98e751 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
> @@ -140,7 +140,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
> if (!ret && phys_cursor)
> ret = i915_gem_object_attach_phys(obj, alignment);
> else if (!ret && HAS_LMEM(dev_priv))
> - ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM);
> + ret = i915_gem_object_migrate(obj, &ww, INTEL_REGION_LMEM_0);
> /* TODO: Do we need to sync when migration becomes async? */
> if (!ret)
> ret = i915_gem_object_pin_pages(obj);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> index 444f8268b9c5..47e43dc3a174 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
> @@ -100,7 +100,7 @@ __i915_gem_object_create_lmem_with_ps(struct
> drm_i915_private *i915,
> resource_size_t page_size,
> unsigned int flags)
> {
> - return
> i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
> + return
> i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
>size, page_size, flags);
> }
>
> @@ -135,6 +135,6 @@ i915_gem_object_create_lmem(struct drm_i915_private *i915,
> resource_size_t size,
> unsigned int flags)
> {
> - return
> i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM],
> + return
> i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_LMEM_0],
>size, 0, flags);
> }
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
> index b071a58dd6da..a342fd387d4e 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
> @@ -88,7 +88,7 @@ static int igt_dmabuf_import_self(void *arg)
> static int igt_dmabuf_import_same_driver_lmem(void *arg)
> {
> struct drm_i915_private *i915 = arg;
> - struct intel_memory_region *lmem = i915->mm.regions[INTEL_REGION_LMEM];
> + struct intel_memory_region *lmem =
> i915->mm.regions[INTEL_REGION_LMEM_0];
> struct drm_i915_gem_object *obj;
> struct drm_gem_object *import;
> struct dma_buf *dmabuf;
> @@ -252,10 +252,10 @@ static int igt_dmabuf_import_same_driver_lmem_smem(void
> *arg)
> struct drm_i915_private *i915 = arg;
> struct intel_memory_region *regions[2];
>
> - if (!i915->mm.regions[INTEL_REGION_LMEM])
> + if (!i915->mm.regions[INTEL_REGION_LMEM_0])
> return 0;
>
> - regions[0] = i915->mm.regions[INTEL_REGION_LMEM];
> + regions[0] = i915->mm.regions[INTEL_REGION_LMEM_0];
> regions[1] = i915->mm.regions[INTEL_REGION_SMEM];
> return igt_dmabuf_import_same_driver(i915, regions, 2);
> }
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
> index d534141b2cf7..2c63daf932de 100644
> ---
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Prep work for next GuC release (rev3)
On 2/24/2022 20:43, Patchwork wrote:
Project List - Patchwork *Patch Details*
*Series:* Prep work for next GuC release (rev3)
*URL:* https://patchwork.freedesktop.org/series/99805/
*State:*success
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22404/index.html
CI Bug Log - changes from CI_DRM_11285 -> Patchwork_22404
Summary
*SUCCESS*
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22404/index.html
Participating hosts (39 -> 41)
Additional (3): fi-kbl-soraka fi-cml-u2 fi-pnv-d510
Missing (1): fi-bdw-samus
Not a GuC platform.
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_22404:
IGT changes
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@workarounds:
o {bat-adlp-6}: PASS
-> DMESG-WARN
This issue is being seen in other CI runs and is not related to this
patch set (https://gitlab.freedesktop.org/drm/intel/-/issues/5068).
John.
*
Known issues
Here are the changes found in Patchwork_22404 that come from known issues:
IGT changes
Issues hit
*
igt@amdgpu/amd_basic@memory-alloc:
o fi-cml-u2: NOTRUN -> SKIP
(fdo#109315
) +17
similar issues
*
igt@gem_exec_fence@basic-busy@bcs0:
o
fi-kbl-soraka: NOTRUN -> SKIP
(fdo#109271
) +8
similar issues
o
fi-cml-u2: NOTRUN -> SKIP
(i915#1208
) +1
similar issue
*
igt@gem_huc_copy@huc-copy:
o
fi-skl-6600u: NOTRUN -> SKIP
(fdo#109271
/
i915#2190 )
o
fi-cml-u2: NOTRUN -> SKIP
(i915#2190 )
o
fi-kbl-soraka: NOTRUN -> SKIP
(fdo#109271
/
i915#2190 )
*
igt@gem_lmem_swapping@basic:
o fi-kbl-soraka: NOTRUN -> SKIP
(fdo#109271
/
i915#4613
) +3
similar issues
*
igt@gem_lmem_swapping@parallel-random-engines:
o fi-cml-u2: NOTRUN -> SKIP
(i915#4613
) +3
similar issues
*
igt@gem_lmem_swapping@verify-random:
o fi-skl-6600u: NOTRUN -> SKIP
(fdo#109271
/
i915#4613
) +3
similar issues
*
igt@i915_selftest@live:
o fi-skl-6600u: NOTRUN -> FAIL
(i915#4547 )
*
igt@i915_selftest@live@gt_heartbeat:
o fi-bsw-nick: PASS
-> DMESG-FAIL
[Intel-gfx] [CI 0/2] drm/mm: Add an iterator to optimally walk over holes suitable for an allocation
The first patch is a drm core patch that replaces the for loop in drm_mm_insert_node_in_range() with the iterator and would not cause any functional changes. The second patch is a i915 driver specific patch that also uses the iterator but solves a different problem. v2: - Added a new patch to this series to fix a potential NULL dereference. - Fixed a typo associated with the iterator introduced in the drm core patch. - Added locking around the snippet in the i915 patch that traverses the GGTT hole nodes. v3: (Tvrtko) - Replaced mutex_lock with mutex_lock_interruptible_nested() in the i915 patch. v4: (Tvrtko) - Dropped the patch added in v2 as it was deemed unnecessary. v5: (Tvrtko) - Fixed yet another typo in the drm core patch: should have passed caller_mode instead of mode to the iterator. Cc: Tvrtko Ursulin Cc: Nirmoy Das Cc: Christian König Vivek Kasireddy (2): drm/mm: Add an iterator to optimally walk over holes for an allocation (v5) drm/i915/gem: Don't try to map and fence large scanout buffers (v9) drivers/gpu/drm/drm_mm.c| 32 drivers/gpu/drm/i915/i915_gem.c | 128 +++- include/drm/drm_mm.h| 36 + 3 files changed, 145 insertions(+), 51 deletions(-) -- 2.34.1
[Intel-gfx] [CI 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
map into the aperture.
- Account for guard pages while calculating the total size required
for the object.
- Do not subject all objects to the heuristic check and instead
consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.
v6: (Tvrtko)
- Return 0 on success and the specific error code on failure to
preserve the existing behavior.
v7: (Ville)
- Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
size < ggtt->mappable_end / 4 checks.
- Drop the redundant check that is based on previous heuristic.
v8:
- Make sure that we are holding the mutex associated with ggtt vm
as we traverse the hole nodes.
v9: (Tvrtko)
- Use mutex_lock_interruptible_nested() instead of mutex_lock().
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 128 +++-
1 file changed, 94 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2e10187cd0a0..4bef9eaa8b2e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,6 +49,7 @@
#include "gem/i915_gem_pm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -879,6 +880,96 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(&obj->vma.lock);
}
+static int
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+ struct drm_mm_node *hole;
+ u64 hole_start, hole_end, start, end;
+ u64 fence_size, fence_alignment;
+ unsigned int count = 0;
+ int err = 0;
+
+ /*
+* If the
[Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v5)
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm drivers to quickly identify holes of a certain
size within a given range.
v2: (Tvrtko)
- Prepend a double underscore for the newly exported first/next_hole
- s/each_best_hole/each_suitable_hole/g
- Mask out DRM_MM_INSERT_ONCE from the mode before calling
first/next_hole and elsewhere.
v3: (Tvrtko)
- Reduce the number of hunks by retaining the "mode" variable name
v4:
- Typo: s/__drm_mm_next_hole(.., hole/__drm_mm_next_hole(.., pos
v5: (Tvrtko)
- Fixed another typo: should pass caller_mode instead of mode to
the iterator in drm_mm_insert_node_in_range().
Reviewed-by: Tvrtko Ursulin
Acked-by: Christian König
Suggested-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_mm.c | 32 +++-
include/drm/drm_mm.h | 36
2 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..6ff98a0e4df3 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
return node;
}
-static struct drm_mm_node *
-first_hole(struct drm_mm *mm,
- u64 start, u64 end, u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
hole_stack);
}
}
+EXPORT_SYMBOL(__drm_mm_first_hole);
/**
* DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
@@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node
*entry, u64 size) \
DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
-static struct drm_mm_node *
-next_hole(struct drm_mm *mm,
- struct drm_mm_node *node,
- u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_next_hole(struct drm_mm *mm,
+ struct drm_mm_node *node,
+ u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
return &node->hole_stack == &mm->hole_stack ? NULL : node;
}
}
+EXPORT_SYMBOL(__drm_mm_next_hole);
/**
* drm_mm_reserve_node - insert an pre-initialized node
@@ -516,11 +518,11 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
u64 size, u64 alignment,
unsigned long color,
u64 range_start, u64 range_end,
- enum drm_mm_insert_mode mode)
+ enum drm_mm_insert_mode caller_mode)
{
struct drm_mm_node *hole;
u64 remainder_mask;
- bool once;
+ enum drm_mm_insert_mode mode = caller_mode & ~DRM_MM_INSERT_ONCE;
DRM_MM_BUG_ON(range_start > range_end);
@@ -533,13 +535,9 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
- once = mode & DRM_MM_INSERT_ONCE;
- mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
- for (hole = first_hole(mm, range_start, range_end, size, mode);
-hole;
-hole = once ? NULL : next_hole(mm, hole, size, mode)) {
+ drm_mm_for_each_suitable_hole(hole, mm, range_start, range_end,
+ size, caller_mode) {
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index ac33ba1b18bc..dff6db627807 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -400,6 +400,42 @@ static inline u64 drm_mm_hole_node_end(const struct
drm_mm_node *hole_node)
1 : 0; \
pos = list_next_entry(pos, hole_stack))
+struct drm_mm_node *
+__drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode);
+
+struct drm_mm_node *
+__drm_mm_next_hole(struct drm_mm *mm,
+ struct drm_mm_node *node,
+ u64 size,
+ enum drm_mm_insert_mode mode);
+
+/**
+ * drm_mm_for_each_suitable_hole - iterator to optimally walk over al
Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads
On 2/28/2022 07:32, Tvrtko Ursulin wrote:
On 25/02/2022 19:03, John Harrison wrote:
On 2/25/2022 10:29, Tvrtko Ursulin wrote:
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible on
current hardware.
Thus the pre-emption timeout was disabled as a workaround
to prevent
unwanted resets. Instead, the hang detection was left to
the heartbeat
and its (longer) timeout. This is undesirable with GuC
submission as
the heartbeat is a full GT reset rather than a per engine
reset and so
is much more destructive. Instead, just bump the
pre-emption timeout
Can we have a feature request to allow asking GuC for an
engine reset?
For what purpose?
To allow "stopped heartbeat" to reset the engine, however..
GuC manages the scheduling of contexts across engines. With
virtual engines, the KMD has no knowledge of which engine a
context might be executing on. Even without virtual engines,
the KMD still has no knowledge of which context is currently
executing on any given engine at any given time.
There is a reason why hang detection should be left to the
entity that is doing the scheduling. Any other entity is
second guessing at best.
The reason for keeping the heartbeat around even when GuC
submission is enabled is for the case where the KMD/GuC have
got out of sync with either other somehow or GuC itself has
just crashed. I.e. when no submission at all is working and
we need to reset the GuC itself and start over.
.. I wasn't really up to speed to know/remember heartbeats are
nerfed already in GuC mode.
Not sure what you mean by that claim. Engine resets are handled
by GuC because GuC handles the scheduling. You can't do the
former if you aren't doing the latter. However, the heartbeat
is still present and is still the watchdog by which engine
resets are triggered. As per the rest of the submission
process, the hang detection and recovery is split between i915
and GuC.
I meant that "stopped heartbeat on engine XXX" can only do a
full GPU reset on GuC.
I mean that there is no 'stopped heartbeat on engine XXX' when
i915 is not handling the recovery part of the process.
H?
static void
reset_engine(struct intel_engine_cs *engine, struct i915_request *rq)
{
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
show_heartbeat(rq, engine);
if (intel_engine_uses_guc(engine))
/*
* GuC itself is toast or GuC's hang detection
* is disabled. Either way, need to find the
* hang culprit manually.
*/
intel_guc_find_hung_context(engine);
intel_gt_handle_error(engine->gt, engine->mask,
I915_ERROR_CAPTURE,
"stopped heartbeat on %s",
engine->name);
}
How there is no "stopped hearbeat" in guc mode? From this code it
certainly looks there is.
Only when the GuC is toast and it is no longer an engine reset but
a full GT reset that is required. So technically, it is not a
'stopped heartbeat on engine XXX' it is 'stopped heartbeat on GT#'.
You say below heartbeats are going in GuC mode. Now I totally
don't understand how they are going but there is allegedly no
"stopped hearbeat".
Because if GuC is handling the detection and recovery then i915
will not reach that point. GuC will do the engine reset and start
scheduling the next context before the heartbeat period expires. So
the notification will be a G2H about a specific context being reset
rather than the i915 notification about a stopped heartbeat.
intel_gt_handle_error(engine->gt, engine->mask,
I915_ERROR_CAPTURE,
"stopped heartbeat on %s",
engine->name);
intel_gt_handle_error:
/*
* Try engine reset when available. We fall back to full
reset if
* single reset fails.
*/
if (!intel_uc_uses_guc_submission(>->uc) &&
intel_has_reset_engine(gt) && !intel_gt_is_wedged(gt)) {
local_bh_disable();
for_each_engine_masked(engine, gt, engine_mask, tmp) {
You said "However, the heartbeat is still present and is still
the watchdog by which engine resets are triggered", now I don't
know what you meant by this. It actually triggers a single
engine reset in GuC mode? Where in code does that happen if this
block above shows it not taking the engine reset path?
i915 sends down the per engine pulse.
GuC schedules the pulse
GuC attempts to pre-empt the currently active context
GuC detects the pre-emption timeout
GuC resets the engine
The fundamental process is exactly the same as in execlist mode.
It's just th
Re: [Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v4)
Hi Tvrtko,
>
> Hi Vivek,
>
> On 27/02/2022 17:29, Vivek Kasireddy wrote:
> > This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
> > functions to identify suitable holes for an allocation of a given
> > size by efficiently traversing the rbtree associated with the given
> > allocator.
> >
> > It replaces the for loop in drm_mm_insert_node_in_range() and can
> > also be used by drm drivers to quickly identify holes of a certain
> > size within a given range.
> >
> > v2: (Tvrtko)
> > - Prepend a double underscore for the newly exported first/next_hole
> > - s/each_best_hole/each_suitable_hole/g
> > - Mask out DRM_MM_INSERT_ONCE from the mode before calling
> >first/next_hole and elsewhere.
> >
> > v3: (Tvrtko)
> > - Reduce the number of hunks by retaining the "mode" variable name
> >
> > v4:
> > - Typo: s/__drm_mm_next_hole(.., hole/__drm_mm_next_hole(.., pos
> >
> > Reviewed-by: Tvrtko Ursulin
> > Acked-by: Christian König
> > Suggested-by: Tvrtko Ursulin
> > Signed-off-by: Vivek Kasireddy
> > ---
> > drivers/gpu/drm/drm_mm.c | 32 +++-
> > include/drm/drm_mm.h | 36
> > 2 files changed, 51 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
> > index 8257f9d4f619..8efea548ae9f 100644
> > --- a/drivers/gpu/drm/drm_mm.c
> > +++ b/drivers/gpu/drm/drm_mm.c
> > @@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct
> > drm_mm
> *mm, u64 addr, u64 size)
> > return node;
> > }
> >
> > -static struct drm_mm_node *
> > -first_hole(struct drm_mm *mm,
> > - u64 start, u64 end, u64 size,
> > - enum drm_mm_insert_mode mode)
> > +struct drm_mm_node *
> > +__drm_mm_first_hole(struct drm_mm *mm,
> > + u64 start, u64 end, u64 size,
> > + enum drm_mm_insert_mode mode)
> > {
> > switch (mode) {
> > default:
> > @@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
> > hole_stack);
> > }
> > }
> > +EXPORT_SYMBOL(__drm_mm_first_hole);
> >
> > /**
> >* DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
> > @@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node
> *entry, u64 size) \
> > DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
> > DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
> >
> > -static struct drm_mm_node *
> > -next_hole(struct drm_mm *mm,
> > - struct drm_mm_node *node,
> > - u64 size,
> > - enum drm_mm_insert_mode mode)
> > +struct drm_mm_node *
> > +__drm_mm_next_hole(struct drm_mm *mm,
> > + struct drm_mm_node *node,
> > + u64 size,
> > + enum drm_mm_insert_mode mode)
> > {
> > switch (mode) {
> > default:
> > @@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
> > return &node->hole_stack == &mm->hole_stack ? NULL : node;
> > }
> > }
> > +EXPORT_SYMBOL(__drm_mm_next_hole);
> >
> > /**
> >* drm_mm_reserve_node - insert an pre-initialized node
> > @@ -516,11 +518,11 @@ int drm_mm_insert_node_in_range(struct drm_mm * const
> mm,
> > u64 size, u64 alignment,
> > unsigned long color,
> > u64 range_start, u64 range_end,
> > - enum drm_mm_insert_mode mode)
> > + enum drm_mm_insert_mode caller_mode)
> > {
> > struct drm_mm_node *hole;
> > u64 remainder_mask;
> > - bool once;
> > + enum drm_mm_insert_mode mode = caller_mode &
> ~DRM_MM_INSERT_ONCE;
> >
> > DRM_MM_BUG_ON(range_start > range_end);
> >
> > @@ -533,13 +535,9 @@ int drm_mm_insert_node_in_range(struct drm_mm * const
> mm,
> > if (alignment <= 1)
> > alignment = 0;
> >
> > - once = mode & DRM_MM_INSERT_ONCE;
> > - mode &= ~DRM_MM_INSERT_ONCE;
> > -
> > remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
> > - for (hole = first_hole(mm, range_start, range_end, size, mode);
> > -hole;
> > -hole = once ? NULL : next_hole(mm, hole, size, mode)) {
> > + drm_mm_for_each_suitable_hole(hole, mm, range_start, range_end,
> > + size, mode) {
>
> I was doing one last read of the patch before I ask the maintainers
> where to merge it and realized - don't you need to pass in the
> caller_mode just here (not mode which has been masked out from "once")?
> Otherwise "once" mode will not be respected by the iterator.
[Kasireddy, Vivek] Right, yet another typo; it should have been caller_mode
instead of mode. Let me fix it and run it through another CI cycle.
Thanks,
Vivek
>
> Regards,
>
> Tvrtko
>
> > u64 hole_start = __drm_mm_hole_node_start(hole);
> > u64 hole_end = hole_start + hole->hole_size;
> > u64 adj_start, adj_end;
> > diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts
On 2/28/2022 09:12, Tvrtko Ursulin wrote: On 25/02/2022 18:48, John Harrison wrote: On 2/25/2022 10:14, Tvrtko Ursulin wrote: I'll try to simplify the discussion here: On 24/02/2022 19:45, John Harrison wrote: On 2/24/2022 03:41, Tvrtko Ursulin wrote: On 23/02/2022 20:00, John Harrison wrote: On 2/23/2022 05:58, Tvrtko Ursulin wrote: On 23/02/2022 02:45, John Harrison wrote: On 2/22/2022 03:19, Tvrtko Ursulin wrote: On 18/02/2022 21:33, john.c.harri...@intel.com wrote: From: John Harrison Compute workloads are inherantly not pre-emptible for long periods on current hardware. As a workaround for this, the pre-emption timeout for compute capable engines was disabled. This is undesirable with GuC submission as it prevents per engine reset of hung contexts. Hence the next patch will re-enable the timeout but bumped up by an order of magnititude. (Some typos above.) I'm spotting 'inherently' but not anything else. Magnititude! O;) Doh! [snip] Whereas, bumping all heartbeat periods to be greater than the pre-emption timeout is wasteful and unnecessary. That leads to a total heartbeat time of about a minute. Which is a very long time to wait for a hang to be detected and recovered. Especially when the official limit on a context responding to an 'are you dead' query is only 7.5 seconds. Not sure how did you get one minute? 7.5 * 2 (to be safe) = 15. 15 * 5 (number of heartbeat periods) = 75 => 1 minute 15 seconds Even ignoring any safety factor and just going with 7.5 * 5 still gets you to 37.5 seconds which is over a half a minute and likely to race. Ah because my starting point is there should be no preempt timeout = heartbeat * 3, I just think that's too ugly. Then complain at the hardware designers to give us mid-thread pre-emption back. The heartbeat is only one source of pre-emption events. For example, a user can be running multiple contexts in parallel and expecting them to time slice on a single engine. Or maybe a user is just running one compute task in the background but is doing render work in the foreground. Etc. There was a reason the original hack was to disable pre-emption rather than increase the heartbeat. This is simply a slightly less ugly version of the same hack. And unfortunately, the basic idea of the hack is non-negotiable. As per other comments, 'tP(RCS) = tH *3' or 'tP(RCS) = tP(default) * 12' or 'tP(RCS) = 7500' are the available options. Given that the heartbeat is the ever present hard limit, it seems most plausible to base the hack on that. Any of the others works, though. Although I think a explicit hardcoded value is the most ugly. I guess the other option is to add CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE and default that to 7500. Take your pick. But 640ms is not allowed. Regardless, crux of argument was to avoid GuC engine reset and heartbeat reset racing with each other, and to do that by considering the preempt timeout with the heartbeat interval. I was thinking about this scenario in this series: [Please use fixed width font and no line wrap to view.] A) tP = preempt timeout tH = hearbeat interval tP = 3 * tH 1) Background load = I915_PRIORITY_DISPLAY <-- [tH] --> Pulse1 <-- [tH] --> Pulse2 <-- [tH] --> Pulse3 < [2 * tH] > FULL RESET | \- preemption triggered, tP = 3 * tH --\ \-> preempt timeout would hit here Here we have collateral damage due full reset, since we can't tell GuC to reset just one engine and we fudged tP just to "account" for heartbeats. You are missing the whole point of the patch series which is that the last heartbeat period is '2 * tP' not '2 * tH'. + longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2; By making the last period double the pre-emption timeout, it is guaranteed that the FULL RESET stage cannot be hit before the hardware has attempted and timed-out on at least one pre-emption. Oh well :) that probably means the overall scheme is too odd for me. tp = 3tH and last pulse after 2tP I mean. To be accurate, it is 'tP(RCS) = 3 * tH(default); tH(final) = tP(current) * 2;'. Seems fairly straight forward to me. It's not a recursive definition or anything like that. It gives us a total heartbeat timeout that is close to the original version but still allows at least one pre-emption event. [snip] <-- [tH] --> Pulse1 <-- [tH] --> Pulse2 <-- [tH] --> Pulse3 < [2 * tH] > full reset would be here | \- preemption triggered, tP = 3 * tH \ \-> Preempt timeout reset Here is is kind of least worse, but question is why we fudged tP when it gives us nothing good in this case. The point of fudging tP(RCS) is to give compute workloads longer to reach a pre-emptible point (given that EU walkers are basically not pre-emptible). The reason for doing the fudge is not connected to the heartbeat at all. The fact that it causes problems for the heartbeat is an undesired side effect.
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann wrote: > > I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it > make sense regardless of the -std=gnu11 change I do think they make sense, but I want to note again that people doing cross builds obviously use different tools for user builds than for the kernel. In fact, even not cross-building, we've had situations where the "kbuild" compiler is different from the host compiler, because people have upgraded one but not the other (upgrading the kernel build environment is actually much easier than upgrading the host build environment, because you don't need all the random libraries etc, and you can literally _just_ build your own gcc and binutils) And we have *not* necessarily required that the host tools match the kernel tools. So I could well imagine that there are people who build their kernels, but their host build environment might be old enough that -std=gnu11 is problematic for that part. And note how any change to KBUILD_USERCFLAGS is reflected in KBUILD_HOSTCFLAGS. So I would suggest that the KBUILD_USERCFLAGS part of the patch (and the modpost.c change that goes with it) be done as a separate commit. Because we might end up reverting that part. Hmm? Linus
Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow
On 2/28/2022 08:11, Tvrtko Ursulin wrote: On 25/02/2022 17:39, John Harrison wrote: On 2/25/2022 09:06, Tvrtko Ursulin wrote: On 24/02/2022 19:19, John Harrison wrote: [snip] ./gt/uc/intel_guc_fwif.h: u32 execution_quantum; ./gt/uc/intel_guc_submission.c: desc->execution_quantum = engine->props.timeslice_duration_ms * 1000; ./gt/intel_engine_types.h: unsigned long timeslice_duration_ms; timeslice_store/preempt_timeout_store: err = kstrtoull(buf, 0, &duration); So both kconfig and sysfs can already overflow GuC, not only because of tick conversion internally but because at backend level nothing was done for assigning 64-bit into 32-bit. Or I failed to find where it is handled. That's why I'm adding this range check to make sure we don't allow overflows. Yes and no, this fixes it, but the first bug was not only due GuC internal tick conversion. It was present ever since the u64 from i915 was shoved into u32 sent to GuC. So even if GuC used the value without additional multiplication, bug was be there. My point being when GuC backend was added timeout_ms values should have been limited/clamped to U32_MAX. The tick discovery is additional limit on top. I'm not disagreeing. I'm just saying that the truncation wasn't noticed until I actually tried using very long timeouts to debug a particular problem. Now that it is noticed, we need some method of range checking and this simple clamp solves all the truncation problems. Agreed in principle, just please mention in the commit message all aspects of the problem. I think we can get away without a Fixes: tag since it requires user fiddling to break things in unexpected ways. I would though put in a code a clamping which expresses both, something like min(u32, ..GUC LIMIT..). So the full story is documented forever. Or "if > u32 || > ..GUC LIMIT..) return -EINVAL". Just in case GuC limit one day changes but u32 stays. Perhaps internal ticks go away or anything and we are left with plain 1:1 millisecond relationship. Can certainly add a comment along the lines of "GuC API only takes a 32bit field but that is further reduced to GUC_LIMIT due to internal calculations which would otherwise overflow". But if the GuC limit is > u32 then, by definition, that means the GuC API has changed to take a u64 instead of a u32. So there will no u32 truncation any more. So I'm not seeing a need to explicitly test the integer size when the value check covers that. Hmm I was thinking if the internal conversion in the GuC fw changes so that GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS goes above u32, then to be extra safe by documenting in code there is the additional limit of the data structure field. Say the field was changed to take some unit larger than a millisecond. Then the check against the GuC MAX limit define would not be enough, unless that would account both for internal implementation and u32 in the protocol. Maybe that is overdefensive but I don't see that it harms. 50-50, but it's do it once and forget so I'd do it. Huh? How can the limit be greater than a u32 if the interface only takes a u32? By definition the limit would be clamped to u32 size. If you mean that the GuC policy is in different units and those units might not overflow but ms units do, then actually that is already the case. The GuC works in us not ms. That's part of why the wrap around is so low, we have to multiply by 1000 before sending to GuC. However, that is actually irrelevant because the comparison is being done on the i915 side in i915's units. We have to scale the GuC limit to match what i915 is using. And the i915 side is u64 so if the scaling to i915 numbers overflows a u32 then who cares because that comparison can be done at 64 bits wide. If the units change then that is a backwards breaking API change that will require a manual driver code update. You can't just recompile with a new header and magically get an ms to us or ms to s conversion in your a = b assignment. The code will need to be changed to do the new unit conversion (note we already convert from ms to us, the GuC API is all expressed in us). And that code change will mean having to revisit any and all scaling, type conversions, etc. I.e. any pre-existing checks will not necessarily be valid and will need to be re-visted anyway. But as above, any scaling to GuC units has to be incorporated into the limit already because otherwise the limit would not fit in the GuC's own API. Yes I get that, I was just worried that u32 field in the protocol and GUC_POLICY_MAX_EXEC_QUANTUM_MS defines are separate in the source code and then how to protect against forgetting to update both in sync. Like if the protocol was changed to take nanoseconds, and firmware implementation changed to support the full range, but define left/forgotten at 100s. That would then overflow u32. Huh? If the API was updated to 'support the full range' then how can you get ov
Re: [Intel-gfx] [PATCH 1/6] drivers: usb: remove usage of list iterator past the loop body
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote: > a multi-line indent gets curly braces for readability even though > it's not required by C. And then both sides would get curly braces. That's more your personal preference than a coding style guideline.
[Intel-gfx] ✗ Fi.CI.IGT: failure for Fix prime_mmap to work when using LMEM (rev2)
== Series Details ==
Series: Fix prime_mmap to work when using LMEM (rev2)
URL : https://patchwork.freedesktop.org/series/100737/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11297_full -> Patchwork_22432_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22432_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22432_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_22432_full:
### IGT changes ###
Possible regressions
* igt@kms_vblank@pipe-b-query-forked:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/shard-tglb6/igt@kms_vbl...@pipe-b-query-forked.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-tglb7/igt@kms_vbl...@pipe-b-query-forked.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@prime_mmap_coherency@ioctl-errors:
- {shard-dg1}:[FAIL][3] ([i915#4899]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/shard-dg1-15/igt@prime_mmap_cohere...@ioctl-errors.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-dg1-13/igt@prime_mmap_cohere...@ioctl-errors.html
Known issues
Here are the changes found in Patchwork_22432_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-3x:
- shard-iclb: NOTRUN -> [SKIP][5] ([i915#1839])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-iclb7/igt@feature_discov...@display-3x.html
* igt@gem_create@create-massive:
- shard-iclb: NOTRUN -> [DMESG-WARN][6] ([i915#4991])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-iclb7/igt@gem_cre...@create-massive.html
* igt@gem_eio@unwedge-stress:
- shard-tglb: [PASS][7] -> [FAIL][8] ([i915#232])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/shard-tglb7/igt@gem_...@unwedge-stress.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-tglb2/igt@gem_...@unwedge-stress.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#4547])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/shard-skl8/igt@gem_exec_capture@p...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-skl9/igt@gem_exec_capture@p...@rcs0.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: NOTRUN -> [FAIL][11] ([i915#2846])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-apl4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-iclb7/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2849])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-iclb: NOTRUN -> [SKIP][17] ([fdo#109283])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-iclb7/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-skl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-skl8/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@verify:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#4613])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-iclb3/igt@gem_lmem_swapp...@verify.html
* igt@gem_pwrite@basic-exhaustion:
- shard-tglb: NOTRUN -> [WARN][20] ([i915#2658])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/shard-tglb3/igt@ge
[Intel-gfx] [PATCH v2 08/13] drm/i915/xehp/guc: enable compute engine inside GuC
From: Daniele Ceraolo Spurio
Tell GuC that CCS is enabled by setting a bit in its ADS.
Cc: Vinay Belgaumkar
Original-author: Michel Thierry
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h| 3 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 84f189738a68..e629443e07ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1327,6 +1327,9 @@
#define ECOBITS_PPGTT_CACHE64B (3 << 8)
#define ECOBITS_PPGTT_CACHE4B(0 << 8)
+#define GEN12_RCU_MODE _MMIO(0x14800)
+#define GEN12_RCU_MODE_CCS_ENABLEREG_BIT(0)
+
#define CHV_FUSE_GT_MMIO(VLV_DISPLAY_BASE + 0x2168)
#define CHV_FGT_DISABLE_SS0 (1 << 10)
#define CHV_FGT_DISABLE_SS1 (1 << 11)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 847e00390b00..9bb551b83e7a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -335,6 +335,10 @@ static int guc_mmio_regset_init(struct temp_regset *regset,
ret |= GUC_MMIO_REG_ADD(regset, RING_HWS_PGA(base), false);
ret |= GUC_MMIO_REG_ADD(regset, RING_IMR(base), false);
+ if (engine->class == RENDER_CLASS &&
+ CCS_MASK(engine->gt))
+ ret |= GUC_MMIO_REG_ADD(regset, GEN12_RCU_MODE, true);
+
for (i = 0, wa = wal->list; i < wal->count; i++, wa++)
ret |= GUC_MMIO_REG_ADD(regset, wa->reg, wa->masked_reg);
@@ -430,6 +434,7 @@ static void fill_engine_enable_masks(struct intel_gt *gt,
struct iosys_map *info_map)
{
info_map_write(info_map, engine_enabled_masks[GUC_RENDER_CLASS], 1);
+ info_map_write(info_map, engine_enabled_masks[GUC_COMPUTE_CLASS],
CCS_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS], 1);
info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS],
VDBOX_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_VIDEOENHANCE_CLASS],
VEBOX_MASK(gt));
--
2.34.1
[Intel-gfx] [PATCH v2 11/13] drm/i915/xehp: handle fused off CCS engines
From: Daniele Ceraolo Spurio
HW resources are divided across the active CCS engines at the compute
slice level, with each CCS having priority on one of the cslices.
If a compute slice has no enabled DSS, its paired compute engine is not
usable in full parallel execution because the other ones already fully
saturate the HW, so consider it fused off.
v2(José):
- moved it to its own function
- fixed definition of ccs_mask
Cc: Stuart Summers
Cc: Vinay Belgaumkar
Cc: Ashutosh Dixit
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 25 +++
drivers/gpu/drm/i915/gt/intel_sseu.c | 17 ---
drivers/gpu/drm/i915/gt/intel_sseu.h | 4 +++-
3 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 92f4cf9833ee..4fa3adc15b08 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -592,6 +592,29 @@ bool gen11_vdbox_has_sfc(struct intel_gt *gt,
return false;
}
+static void engine_mask_apply_compute_fuses(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_gt_info *info = >->info;
+ unsigned int i;
+
+ /*
+* If all DSS in a quadrant are fused off, the corresponding CCS
+* engine is not available for use.
+*/
+ if (fls(CCS_MASK(gt)) > 1) {
+ int ss_per_ccs = info->sseu.max_subslices / I915_MAX_CCS;
+ const unsigned long ccs_mask = intel_slicemask_from_dssmask(
+ intel_sseu_get_compute_subslices(&info->sseu),
+ ss_per_ccs);
+
+ for_each_clear_bit(i, &ccs_mask, I915_MAX_CCS) {
+ info->engine_mask &= ~BIT(_CCS(i));
+ drm_dbg(&i915->drm, "ccs%u fused off\n", i);
+ }
+ }
+}
+
/*
* Determine which engines are fused off in our particular hardware.
* Note that we have a catch-22 situation where we need to be able to access
@@ -673,6 +696,8 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
vebox_mask, VEBOX_MASK(gt));
GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
+ engine_mask_apply_compute_fuses(gt);
+
return info->engine_mask;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 29118c652811..4ac0bbaf0c31 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -32,7 +32,9 @@ intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
return total;
}
-u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice)
+static u32
+_intel_sseu_get_subslices(const struct sseu_dev_info *sseu,
+ const u8 *subslice_mask, u8 slice)
{
int i, offset = slice * sseu->ss_stride;
u32 mask = 0;
@@ -40,12 +42,21 @@ u32 intel_sseu_get_subslices(const struct sseu_dev_info
*sseu, u8 slice)
GEM_BUG_ON(slice >= sseu->max_slices);
for (i = 0; i < sseu->ss_stride; i++)
- mask |= (u32)sseu->subslice_mask[offset + i] <<
- i * BITS_PER_BYTE;
+ mask |= (u32)subslice_mask[offset + i] << i * BITS_PER_BYTE;
return mask;
}
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice)
+{
+ return _intel_sseu_get_subslices(sseu, sseu->subslice_mask, slice);
+}
+
+u32 intel_sseu_get_compute_subslices(const struct sseu_dev_info *sseu)
+{
+ return _intel_sseu_get_subslices(sseu, sseu->compute_subslice_mask, 0);
+}
+
void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
u8 *subslice_mask, u32 ss_mask)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 60882a74741e..8a79cd8eaab4 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -103,7 +103,9 @@ intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
unsigned int
intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice);
-u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice);
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice);
+
+u32 intel_sseu_get_compute_subslices(const struct sseu_dev_info *sseu);
void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
u8 *subslice_mask, u32 ss_mask);
--
2.34.1
[Intel-gfx] [PATCH v2 09/13] drm/i915/xehp: Enable ccs/dual-ctx in RCU_MODE
We have to specify in the Render Control Unit Mode register
when CCS is enabled.
v2:
- Move RCU_MODE programming to a helper function. (Tvrtko)
- Clean up and clarify comments. (Tvrtko)
- Add RCU_MODE to the GuC save/restore list. (Daniele)
Bspec: 46034
Original-author: Michel Thierry
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Vinay Belgaumkar
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine.h | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 17 +
.../drm/i915/gt/intel_execlists_submission.c| 16
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 16
4 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index be4b1e65442f..1c0ab05c3c40 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -265,6 +265,8 @@ intel_engine_create_pinned_context(struct intel_engine_cs
*engine,
void intel_engine_destroy_pinned_context(struct intel_context *ce);
+void xehp_enable_ccs_engines(struct intel_engine_cs *engine);
+
#define ENGINE_PHYSICAL0
#define ENGINE_MOCK1
#define ENGINE_VIRTUAL 2
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2136c56d3abc..92f4cf9833ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -2070,6 +2070,23 @@ intel_engine_execlist_find_hung_request(struct
intel_engine_cs *engine)
return active;
}
+void xehp_enable_ccs_engines(struct intel_engine_cs *engine)
+{
+ /*
+* If there are any non-fused-off CCS engines, we need to enable CCS
+* support in the RCU_MODE register. This only needs to be done once,
+* so for simplicity we'll take care of this in the RCS engine's
+* resume handler; since the RCS and all CCS engines belong to the
+* same reset domain and are reset together, this will also take care
+* of re-applying the setting after i915-triggered resets.
+*/
+ if (!CCS_MASK(engine->gt))
+ return;
+
+ intel_uncore_write(engine->uncore, GEN12_RCU_MODE,
+ _MASKED_BIT_ENABLE(GEN12_RCU_MODE_CCS_ENABLE));
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "mock_engine.c"
#include "selftest_engine.c"
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index c8407cc96c42..574c0542c92f 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -2914,6 +2914,19 @@ static int execlists_resume(struct intel_engine_cs
*engine)
return 0;
}
+static int gen12_rcs_resume(struct intel_engine_cs *engine)
+{
+ int ret;
+
+ ret = execlists_resume(engine);
+ if (ret)
+ return ret;
+
+ xehp_enable_ccs_engines(engine);
+
+ return 0;
+}
+
static void execlists_reset_prepare(struct intel_engine_cs *engine)
{
ENGINE_TRACE(engine, "depth<-%d\n",
@@ -3468,6 +3481,9 @@ static void rcs_submission_override(struct
intel_engine_cs *engine)
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
break;
}
+
+ if (engine->class == RENDER_CLASS)
+ engine->resume = gen12_rcs_resume;
}
int intel_execlists_submission_setup(struct intel_engine_cs *engine)
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 6db8bb1982ca..7e42fecd6093 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3619,6 +3619,19 @@ static bool guc_sched_engine_disabled(struct
i915_sched_engine *sched_engine)
return !sched_engine->tasklet.callback;
}
+static int gen12_rcs_resume(struct intel_engine_cs *engine)
+{
+ int ret;
+
+ ret = guc_resume(engine);
+ if (ret)
+ return ret;
+
+ xehp_enable_ccs_engines(engine);
+
+ return 0;
+}
+
static void guc_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = guc_submit_request;
@@ -3739,6 +3752,9 @@ static void rcs_submission_override(struct
intel_engine_cs *engine)
engine->emit_fini_breadcrumb = gen8_emit_fini_breadcrumb_rcs;
break;
}
+
+ if (engine->class == RENDER_CLASS)
+ engine->resume = gen12_rcs_resume;
}
static inline void guc_default_irqs(struct intel_engine_cs *engine)
--
2.34.1
[Intel-gfx] [PATCH v2 13/13] drm/i915/xehpsdv: Move render/compute engine reset domains related workarounds
From: Srinivasan Shanmugam
Registers that exist in the shared render/compute reset domain need to
be placed on an engine workaround list to ensure that they are properly
re-applied whenever an RCS or CCS engine is reset. We have a number of
workarounds (updating registers MLTICTXCTL, L3SQCREG1_CCS0,
GEN12_MERT_MOD_CTRL, and GEN12_GAMCNTRL_CTRL) that are incorrectly
implemented on the 'gt' workaround list and need to be moved
accordingly.
Cc: Matt Roper
Signed-off-by: Srinivasan Shanmugam
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 26 ++---
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 0b9435d62808..c014b40d2e9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1343,12 +1343,6 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
/* Wa_1409757795:xehpsdv */
wa_write_or(wal, SCCGCTL94DC, CG3DDISURB);
- /* Wa_18011725039:xehpsdv */
- if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A1, STEP_B0)) {
- wa_masked_dis(wal, MLTICTXCTL, TDONRENDER);
- wa_write_or(wal, L3SQCREG1_CCS0, FLUSHALLNONCOH);
- }
-
/* Wa_16011155590:xehpsdv */
if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A0, STEP_B0))
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
@@ -1385,19 +1379,12 @@ xehpsdv_gt_workarounds_init(struct intel_gt *gt, struct
i915_wa_list *wal)
GAMTLBVEBOX0_CLKGATE_DIS);
}
- /* Wa_14012362059:xehpsdv */
- wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
-
/* Wa_16012725990:xehpsdv */
if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A1, STEP_FOREVER))
wa_write_or(wal, UNSLICE_UNIT_LEVEL_CLKGATE,
VFUNIT_CLKGATE_DIS);
/* Wa_14011060649:xehpsdv */
wa_14011060649(gt, wal);
-
- /* Wa_14014368820:xehpsdv */
- wa_write_or(wal, GEN12_GAMCNTRL_CTRL, INVALIDATION_BROADCAST_MODE_DIS |
- GLOBAL_INVALIDATION_MODE);
}
static void
@@ -2617,6 +2604,19 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
/* Wa_14010449647:xehpsdv */
wa_masked_en(wal, GEN7_HALF_SLICE_CHICKEN1,
GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
+
+ /* Wa_18011725039:xehpsdv */
+ if (IS_XEHPSDV_GRAPHICS_STEP(i915, STEP_A1, STEP_B0)) {
+ wa_masked_dis(wal, MLTICTXCTL, TDONRENDER);
+ wa_write_or(wal, L3SQCREG1_CCS0, FLUSHALLNONCOH);
+ }
+
+ /* Wa_14012362059:xehpsdv */
+ wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
+
+ /* Wa_14014368820:xehpsdv */
+ wa_write_or(wal, GEN12_GAMCNTRL_CTRL,
INVALIDATION_BROADCAST_MODE_DIS |
+ GLOBAL_INVALIDATION_MODE);
}
}
--
2.34.1
[Intel-gfx] [PATCH v2 10/13] drm/i915/xehp: Don't support parallel submission on compute / render
From: Matthew Brost
A different emit breadcrumbs ring programming is required for compute /
render and we don't have UMD user so just reject parallel submission for
these engine classes.
Signed-off-by: Matthew Brost
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 ++
drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c | 4
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index bc6d59df064d..9ae294eb7fb4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -670,6 +670,16 @@ set_proto_ctx_engines_parallel_submit(struct
i915_user_extension __user *base,
goto out_err;
}
+ /*
+* We don't support breadcrumb handshake on these
+* classes
+*/
+ if (siblings[n]->class == RENDER_CLASS ||
+ siblings[n]->class == COMPUTE_CLASS) {
+ err = -EINVAL;
+ goto out_err;
+ }
+
if (n) {
if (prev_engine.engine_class !=
ci.engine_class) {
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
index 1297ddbf7f88..f9218a37d170 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c
@@ -154,6 +154,10 @@ static int intel_guc_multi_lrc_basic(void *arg)
int ret;
for (class = 0; class < MAX_ENGINE_CLASS + 1; ++class) {
+ /* We don't support breadcrumb handshake on these classes */
+ if (class == COMPUTE_CLASS || class == RENDER_CLASS)
+ continue;
+
ret = __intel_guc_multi_lrc_basic(gt, class);
if (ret)
return ret;
--
2.34.1
[Intel-gfx] [PATCH v2 04/13] drm/i915/xehp: compute engine pipe_control
From: Daniele Ceraolo Spurio
CCS will reuse the RCS functions for breadcrumb and flush emission.
However, CCS pipe_control has additional programming restrictions:
- Command Streamer Stall Enable must be always set
- Post Sync Operations must not be set to Write PS Depth Count
- 3D-related bits must not be set
Bspec: 47112
Cc: Vinay Belgaumkar
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 35 +++-
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 +
2 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 1f8cf4f790b2..0a29eaf8b0df 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -201,6 +201,8 @@ static u32 *gen12_emit_aux_table_inv(const i915_reg_t
inv_reg, u32 *cs)
int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
{
+ struct intel_engine_cs *engine = rq->engine;
+
if (mode & EMIT_FLUSH) {
u32 flags = 0;
u32 *cs;
@@ -219,6 +221,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
+ if (engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_FLAGS;
+
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -246,6 +251,9 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
+ if (engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_FLAGS;
+
cs = intel_ring_begin(rq, 8 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -618,19 +626,28 @@ u32 *gen12_emit_fini_breadcrumb_xcs(struct i915_request
*rq, u32 *cs)
u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request *rq, u32 *cs)
{
+ struct drm_i915_private *i915 = rq->engine->i915;
+
+ u32 flags = (PIPE_CONTROL_CS_STALL |
+PIPE_CONTROL_TILE_CACHE_FLUSH |
+PIPE_CONTROL_FLUSH_L3 |
+PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
+PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+PIPE_CONTROL_DC_FLUSH_ENABLE |
+PIPE_CONTROL_FLUSH_ENABLE);
+
+ if (GRAPHICS_VER(i915) == 12 && GRAPHICS_VER_FULL(i915) < IP_VER(12,
50))
+ /* Wa_1409600907 */
+ flags |= PIPE_CONTROL_DEPTH_STALL;
+
+ if (rq->engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_FLAGS;
+
cs = gen12_emit_ggtt_write_rcs(cs,
rq->fence.seqno,
hwsp_offset(rq),
PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
- PIPE_CONTROL_CS_STALL |
- PIPE_CONTROL_TILE_CACHE_FLUSH |
- PIPE_CONTROL_FLUSH_L3 |
- PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
- PIPE_CONTROL_DEPTH_CACHE_FLUSH |
- /* Wa_1409600907:tgl */
- PIPE_CONTROL_DEPTH_STALL |
- PIPE_CONTROL_DC_FLUSH_ENABLE |
- PIPE_CONTROL_FLUSH_ENABLE);
+ flags);
return gen12_emit_fini_breadcrumb_tail(rq, cs);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f8253012d166..d112ffd56418 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -228,11 +228,14 @@
#define PIPE_CONTROL_COMMAND_CACHE_INVALIDATE(1<<29) /*
gen11+ */
#define PIPE_CONTROL_TILE_CACHE_FLUSH(1<<28) /*
gen11+ */
#define PIPE_CONTROL_FLUSH_L3(1<<27)
+#define PIPE_CONTROL_AMFS_FLUSH (1<<25) /* gen12+ */
#define PIPE_CONTROL_GLOBAL_GTT_IVB (1<<24) /* gen7+ */
#define PIPE_CONTROL_MMIO_WRITE (1<<23)
#define PIPE_CONTROL_STORE_DATA_INDEX(1<<21)
#define PIPE_CONTROL_CS_STALL(1<<20)
+#define PIPE_CONTROL_GLOBAL_SNAPSHOT_RESET (1<<19)
#define PIPE_CONTROL_TLB_INVALIDATE (1<<18)
+#define PIPE_CONTROL_PSD_SYNC(1<<17) /*
gen11+ */
#define PIPE_CONTROL_MEDIA_STATE_CLEAR (1<<16)
#define PIPE_CONTROL_WRITE_TIMESTAMP (3<<14)
#define PIPE_CONTROL_QW_WRITE
[Intel-gfx] [PATCH v2 12/13] drm/i915/xehp: Add compute workarounds
Additional workarounds are required once we start exposing CCS engines.
Note that we have a number of workarounds that update registers in the
shared render/compute reset domain. Historically we've just added such
registers to the RCS engine's workaround list. But going forward we
should be more careful to place such workarounds on a wa_list for an
engine that definitely exists and is not fused off (e.g., a platform
with no RCS would never apply the RCS wa_list). We'll keep
rcs_engine_wa_init() focused on RCS-specific workarounds that only need
to be applied if the RCS engine is present. A separate
general_render_compute_wa_init() function will be used to define
workarounds that touch registers in the shared render/compute reset
domain and that we need to apply regardless of what render and/or
compute engines actually exist. Any workarounds defined in this new
function will internally be added to the first present RCS or CCS
engine's workaround list to ensure they get applied (and only get
applied once rather than being needlessly re-applied several times).
Co-author: Srinivasan Shanmugam
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 6 +++
drivers/gpu/drm/i915/gt/intel_workarounds.c | 47 +
3 files changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index e629443e07ae..19cd34f24263 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1060,6 +1060,7 @@
#define FLOW_CONTROL_ENABLE REG_BIT(15)
#define UGM_BACKUP_MODE REG_BIT(13)
#define MDQ_ARBITRATION_MODE REG_BIT(12)
+#define SYSTOLIC_DOP_CLOCK_GATING_DISREG_BIT(10)
#define PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLEREG_BIT(8)
#define STALL_DOP_GATING_DISABLE REG_BIT(5)
#define THROTTLE_12_5REG_GENMASK(4, 2)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index d333400d29fe..e9ea576b96a4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1217,6 +1217,12 @@ gen12_emit_indirect_ctx_xcs(const struct intel_context
*ce, u32 *cs)
cs = gen12_emit_timestamp_wa(ce, cs);
cs = gen12_emit_restore_scratch(ce, cs);
+ /* Wa_16013000631:dg2 */
+ if (IS_DG2_GRAPHICS_STEP(ce->engine->i915, G10, STEP_B0, STEP_C0) ||
+ IS_DG2_G11(ce->engine->i915))
+ if (ce->engine->class == COMPUTE_CLASS)
+ cs = gen8_emit_pipe_control(cs,
PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE, 0);
+
return cs;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 0471d475e680..0b9435d62808 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1921,6 +1921,11 @@ static void dg2_whitelist_build(struct intel_engine_cs
*engine)
RING_FORCE_TO_NONPRIV_RANGE_4);
break;
+ case COMPUTE_CLASS:
+ /* Wa_16011157294:dg2_g10 */
+ if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_A0, STEP_B0))
+ whitelist_reg(w, GEN9_CTX_PREEMPT_REG);
+ break;
default:
break;
}
@@ -2581,6 +2586,40 @@ xcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
}
}
+/*
+ * The workarounds in this function apply to shared registers in
+ * the general render reset domain that aren't tied to a
+ * specific engine. Since all render+compute engines get reset
+ * together, and the contents of these registers are lost during
+ * the shared render domain reset, we'll define such workarounds
+ * here and then add them to just a single RCS or CCS engine's
+ * workaround list (whichever engine has the flag).
+ */
+static void
+general_render_compute_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ if (IS_XEHPSDV(i915)) {
+ /* Wa_1409954639 */
+ wa_masked_en(wal,
+GEN8_ROW_CHICKEN,
+SYSTOLIC_DOP_CLOCK_GATING_DIS);
+
+ /* Wa_1607196519 */
+ wa_masked_en(wal,
+GEN9_ROW_CHICKEN4,
+GEN12_DISABLE_GRF_CLEAR);
+
+ /* Wa_14010670810:xehpsdv */
+ wa_write_or(wal, XEHP_L3NODEARBCFG, XEHP_LNESPARE);
+
+ /* Wa_14010449647:xehpsdv */
+ wa_masked_en(wal, GEN7_HALF_SLICE_CHICKEN1,
+GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
+ }
+}
+
static void
engine_init_workarounds(struct intel_engine_cs *
[Intel-gfx] [PATCH v2 06/13] drm/i915: Move context descriptor fields to intel_lrc.h
This is a more appropriate header for these definitions.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 34 ---
drivers/gpu/drm/i915/gt/intel_lrc.h | 34 +++
3 files changed, 35 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index edba18c942cf..b0982a9e4476 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -21,6 +21,7 @@
#include "intel_gt.h"
#include "intel_gt_requests.h"
#include "intel_gt_pm.h"
+#include "intel_lrc.h"
#include "intel_lrc_reg.h"
#include "intel_reset.h"
#include "intel_ring.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 69b826a3c381..84f189738a68 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1499,38 +1499,4 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
-enum {
- INTEL_ADVANCED_CONTEXT = 0,
- INTEL_LEGACY_32B_CONTEXT,
- INTEL_ADVANCED_AD_CONTEXT,
- INTEL_LEGACY_64B_CONTEXT
-};
-
-enum {
- FAULT_AND_HANG = 0,
- FAULT_AND_HALT, /* Debug only */
- FAULT_AND_STREAM,
- FAULT_AND_CONTINUE /* Unsupported */
-};
-
-#define CTX_GTT_ADDRESS_MASK GENMASK(31, 12)
-#define GEN8_CTX_VALID (1 << 0)
-#define GEN8_CTX_FORCE_PD_RESTORE(1 << 1)
-#define GEN8_CTX_FORCE_RESTORE (1 << 2)
-#define GEN8_CTX_L3LLC_COHERENT (1 << 5)
-#define GEN8_CTX_PRIVILEGE (1 << 8)
-#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
-#define GEN8_CTX_ID_SHIFT32
-#define GEN8_CTX_ID_WIDTH21
-#define GEN11_SW_CTX_ID_SHIFT37
-#define GEN11_SW_CTX_ID_WIDTH11
-#define GEN11_ENGINE_CLASS_SHIFT 61
-#define GEN11_ENGINE_CLASS_WIDTH 3
-#define GEN11_ENGINE_INSTANCE_SHIFT 48
-#define GEN11_ENGINE_INSTANCE_WIDTH 6
-#define XEHP_SW_CTX_ID_SHIFT 39
-#define XEHP_SW_CTX_ID_WIDTH 16
-#define XEHP_SW_COUNTER_SHIFT58
-#define XEHP_SW_COUNTER_WIDTH6
-
#endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index 0b76f096b559..820f8f41fc1f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -69,4 +69,38 @@ void lrc_check_regs(const struct intel_context *ce,
void lrc_update_runtime(struct intel_context *ce);
+enum {
+ INTEL_ADVANCED_CONTEXT = 0,
+ INTEL_LEGACY_32B_CONTEXT,
+ INTEL_ADVANCED_AD_CONTEXT,
+ INTEL_LEGACY_64B_CONTEXT
+};
+
+enum {
+ FAULT_AND_HANG = 0,
+ FAULT_AND_HALT, /* Debug only */
+ FAULT_AND_STREAM,
+ FAULT_AND_CONTINUE /* Unsupported */
+};
+
+#define CTX_GTT_ADDRESS_MASK GENMASK(31, 12)
+#define GEN8_CTX_VALID (1 << 0)
+#define GEN8_CTX_FORCE_PD_RESTORE(1 << 1)
+#define GEN8_CTX_FORCE_RESTORE (1 << 2)
+#define GEN8_CTX_L3LLC_COHERENT (1 << 5)
+#define GEN8_CTX_PRIVILEGE (1 << 8)
+#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
+#define GEN8_CTX_ID_SHIFT32
+#define GEN8_CTX_ID_WIDTH21
+#define GEN11_SW_CTX_ID_SHIFT37
+#define GEN11_SW_CTX_ID_WIDTH11
+#define GEN11_ENGINE_CLASS_SHIFT 61
+#define GEN11_ENGINE_CLASS_WIDTH 3
+#define GEN11_ENGINE_INSTANCE_SHIFT 48
+#define GEN11_ENGINE_INSTANCE_WIDTH 6
+#define XEHP_SW_CTX_ID_SHIFT 39
+#define XEHP_SW_CTX_ID_WIDTH 16
+#define XEHP_SW_COUNTER_SHIFT58
+#define XEHP_SW_COUNTER_WIDTH6
+
#endif /* __INTEL_LRC_H__ */
--
2.34.1
[Intel-gfx] [PATCH v2 07/13] drm/i915/xehp: Define context scheduling attributes in lrc descriptor
In Dual Context mode the EUs are shared between render and compute
command streamers. The hardware provides a field in the lrc descriptor
to indicate the prioritization of the thread dispatch associated to the
corresponding context.
The context priority is set to 'low' at creation time and relies on the
existing context priority to set it to low/normal/high.
Bspec: 46145, 46260
Original-author: Michel Thierry
Cc: Tvrtko Ursulin
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Prasad Nallani
Signed-off-by: Matt Roper
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +++-
drivers/gpu/drm/i915/gt/intel_engine_types.h| 1 +
.../drm/i915/gt/intel_execlists_submission.c| 6 +-
drivers/gpu/drm/i915/gt/intel_lrc.h | 17 +
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index b0982a9e4476..2136c56d3abc 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -435,8 +435,10 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id,
engine->props.preempt_timeout_ms = 0;
/* features common between engines sharing EUs */
- if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS)
+ if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS) {
engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
+ engine->flags |= I915_ENGINE_HAS_EU_PRIORITY;
+ }
engine->defaults = engine->props; /* never to change again */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5fa5f21bbf2d..19ff8758e34d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -525,6 +525,7 @@ struct intel_engine_cs {
#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7)
#define I915_ENGINE_WANT_FORCED_PREEMPTION BIT(8)
#define I915_ENGINE_HAS_RCS_REG_STATE BIT(9)
+#define I915_ENGINE_HAS_EU_PRIORITYBIT(10)
unsigned int flags;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 47fca5ebfa76..c8407cc96c42 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -665,9 +665,13 @@ static inline void execlists_schedule_out(struct
i915_request *rq)
static u64 execlists_update_context(struct i915_request *rq)
{
struct intel_context *ce = rq->context;
- u64 desc = ce->lrc.desc;
+ u64 desc;
u32 tail, prev;
+ desc = ce->lrc.desc;
+ if (rq->engine->flags & I915_ENGINE_HAS_EU_PRIORITY)
+ desc |= lrc_desc_priority(rq_prio(rq));
+
/*
* WaIdleLiteRestore:bdw,skl
*
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.h
b/drivers/gpu/drm/i915/gt/intel_lrc.h
index 820f8f41fc1f..4f2ac9c6ba1d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.h
@@ -6,6 +6,9 @@
#ifndef __INTEL_LRC_H__
#define __INTEL_LRC_H__
+#include "i915_priolist_types.h"
+
+#include
#include
struct drm_i915_gem_object;
@@ -90,6 +93,10 @@ enum {
#define GEN8_CTX_L3LLC_COHERENT (1 << 5)
#define GEN8_CTX_PRIVILEGE (1 << 8)
#define GEN8_CTX_ADDRESSING_MODE_SHIFT 3
+#define GEN12_CTX_PRIORITY_MASK GENMASK(10, 9)
+#define GEN12_CTX_PRIORITY_HIGH
FIELD_PREP(GEN12_CTX_PRIORITY_MASK, 2)
+#define GEN12_CTX_PRIORITY_NORMAL
FIELD_PREP(GEN12_CTX_PRIORITY_MASK, 1)
+#define GEN12_CTX_PRIORITY_LOW
FIELD_PREP(GEN12_CTX_PRIORITY_MASK, 0)
#define GEN8_CTX_ID_SHIFT32
#define GEN8_CTX_ID_WIDTH21
#define GEN11_SW_CTX_ID_SHIFT37
@@ -103,4 +110,14 @@ enum {
#define XEHP_SW_COUNTER_SHIFT58
#define XEHP_SW_COUNTER_WIDTH6
+static inline u32 lrc_desc_priority(int prio)
+{
+ if (prio > I915_PRIORITY_NORMAL)
+ return GEN12_CTX_PRIORITY_HIGH;
+ else if (prio < I915_PRIORITY_NORMAL)
+ return GEN12_CTX_PRIORITY_LOW;
+ else
+ return GEN12_CTX_PRIORITY_NORMAL;
+}
+
#endif /* __INTEL_LRC_H__ */
--
2.34.1
[Intel-gfx] [PATCH v2 02/13] drm/i915/xehp: CCS shares the render reset domain
The reset domain is shared between render and all compute engines, so resetting one will affect the others. Note: Before performing a reset on an RCS or CCS engine, the GuC will attempt to preempt-to-idle the other non-hung RCS/CCS engines to avoid impacting other clients (since some shared modules will be reset). If other engines are executing non-preemptable workloads, the impact is unavoidable and some work may be lost. Bspec: 52549 Original-author: Michel Thierry Cc: Tvrtko Ursulin Cc: Vinay Belgaumkar Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Aravind Iddamsetty Signed-off-by: Matt Roper Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 3190b7b462a9..3150c0847f65 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -341,6 +341,10 @@ static u32 get_reset_domain(u8 ver, enum intel_engine_id id) [VECS1] = GEN11_GRDOM_VECS2, [VECS2] = GEN11_GRDOM_VECS3, [VECS3] = GEN11_GRDOM_VECS4, + [CCS0] = GEN11_GRDOM_RENDER, + [CCS1] = GEN11_GRDOM_RENDER, + [CCS2] = GEN11_GRDOM_RENDER, + [CCS3] = GEN11_GRDOM_RENDER, }; GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) || !engine_reset_domains[id]); -- 2.34.1
[Intel-gfx] [PATCH v2 01/13] drm/i915/xehp: Define compute class and engine
Introduce a Compute Command Streamer (CCS), which has access to
the media and GPGPU pipelines (but not the 3D pipeline).
To begin with, define the compute class/engine common functions, based
on the existing render ones.
v2:
- Add kerneldoc for drm_i915_gem_engine_class since we're adding a new
element to it. (Daniel)
- Make engine class <-> guc class converters use lookup tables to make
it more clear/explicit how the IDs map. (Tvrtko)
v3:
- Don't update uapi for now; we'll just include the driver-internal
changes for the time being.
Bspec: 46167, 45544
Original-author: Michel Thierry
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Vinay Belgaumkar
Signed-off-by: Rodrigo Vivi
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Matt Roper
Reviewed-by: Tvrtko Ursulin #v1
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 28 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 9 +-
drivers/gpu/drm/i915/gt/intel_engine_user.c | 5 ++-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 32 ++--
drivers/gpu/drm/i915/i915_reg.h | 4 +++
6 files changed, 71 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e855c801ba28..3190b7b462a9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -156,6 +156,34 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 12, .base = XEHP_VEBOX4_RING_BASE }
},
},
+ [CCS0] = {
+ .class = COMPUTE_CLASS,
+ .instance = 0,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = GEN12_COMPUTE0_RING_BASE }
+ }
+ },
+ [CCS1] = {
+ .class = COMPUTE_CLASS,
+ .instance = 1,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = GEN12_COMPUTE1_RING_BASE }
+ }
+ },
+ [CCS2] = {
+ .class = COMPUTE_CLASS,
+ .instance = 2,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = GEN12_COMPUTE2_RING_BASE }
+ }
+ },
+ [CCS3] = {
+ .class = COMPUTE_CLASS,
+ .instance = 3,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = GEN12_COMPUTE3_RING_BASE }
+ }
+ },
};
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 36365bdbe1ee..f4533ccafbaf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -33,7 +33,8 @@
#define VIDEO_ENHANCEMENT_CLASS2
#define COPY_ENGINE_CLASS 3
#define OTHER_CLASS4
-#define MAX_ENGINE_CLASS 4
+#define COMPUTE_CLASS 5
+#define MAX_ENGINE_CLASS 5
#define MAX_ENGINE_INSTANCE7
#define I915_MAX_SLICES3
@@ -95,6 +96,7 @@ struct i915_ctx_workarounds {
#define I915_MAX_VCS 8
#define I915_MAX_VECS 4
+#define I915_MAX_CCS 4
/*
* Engine IDs definitions.
@@ -117,6 +119,11 @@ enum intel_engine_id {
VECS2,
VECS3,
#define _VECS(n) (VECS0 + (n))
+ CCS0,
+ CCS1,
+ CCS2,
+ CCS3,
+#define _CCS(n) (CCS0 + (n))
I915_NUM_ENGINES
#define INVALID_ENGINE ((enum intel_engine_id)-1)
};
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 9ce85a845105..b8c9b6b89003 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,6 +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 */
};
static int engine_cmp(void *priv, const struct list_head *A,
@@ -139,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
[COPY_ENGINE_CLASS] = "bcs",
[VIDEO_DECODE_CLASS] = "vcs",
[VIDEO_ENHANCEMENT_CLASS] = "vecs",
+ [COMPUTE_CLASS] = "ccs",
};
if (class >= ARRAY_SIZE(uabi_names) || !uabi_names[class])
@@ -162,6 +164,7 @@ static int legacy_ring_idx(const struct legacy_ring *ring)
[COPY_ENGINE_CLASS] = { BCS0, 1 },
[VIDEO_DECODE_CLASS] = { VCS0, I915_MAX_VCS },
[VIDEO_ENHANCEMENT_CLASS] = { VECS0, I915_MAX_VECS },
+ [COMPUTE_CLASS] = { CCS0, I915_MAX_CCS },
};
if (GEM_DEBUG_WARN_ON(ring->class >= ARRAY_SIZE(map)))
@@ -190,7 +193,7 @@ static void add_legacy_ring(struct leg
[Intel-gfx] [PATCH v2 05/13] drm/i915/xehp: CCS should use RCS setup functions
The compute engine handles the same commands the render engine can
(except 3D pipeline), so it makes sense that CCS is more similar to RCS
than non-render engines.
The CCS context state (lrc) is also similar to the render one, so reuse
it. Note that the compute engine has its own CTX_R_PWR_CLK_STATE
register.
In order to avoid having multiple RCS && CCS checks, add the following
engine flag:
- I915_ENGINE_HAS_RCS_REG_STATE - use the render (larger) reg state ctx.
BSpec: 46260
Original-author: Michel Thierry
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Matt Roper
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 8 +---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 ++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
6 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index bd60d42238fb..7609db87df05 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -885,7 +885,9 @@ static int igt_shared_ctx_exec(void *arg)
return err;
}
-static int rpcs_query_batch(struct drm_i915_gem_object *rpcs, struct i915_vma
*vma)
+static int rpcs_query_batch(struct drm_i915_gem_object *rpcs,
+ struct i915_vma *vma,
+ struct intel_engine_cs *engine)
{
u32 *cmd;
@@ -896,7 +898,7 @@ static int rpcs_query_batch(struct drm_i915_gem_object
*rpcs, struct i915_vma *v
return PTR_ERR(cmd);
*cmd++ = MI_STORE_REGISTER_MEM_GEN8;
- *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE(RENDER_RING_BASE));
+ *cmd++ = i915_mmio_reg_offset(GEN8_R_PWR_CLK_STATE(engine->mmio_base));
*cmd++ = lower_32_bits(vma->node.start);
*cmd++ = upper_32_bits(vma->node.start);
*cmd = MI_BATCH_BUFFER_END;
@@ -957,7 +959,7 @@ emit_rpcs_query(struct drm_i915_gem_object *obj,
if (err)
goto err_vma;
- err = rpcs_query_batch(rpcs, vma);
+ err = rpcs_query_batch(rpcs, vma, ce->engine);
if (err)
goto err_batch;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3150c0847f65..edba18c942cf 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -208,6 +208,8 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 class)
BUILD_BUG_ON(I915_GTT_PAGE_SIZE != PAGE_SIZE);
switch (class) {
+ case COMPUTE_CLASS:
+ fallthrough;
case RENDER_CLASS:
switch (GRAPHICS_VER(gt->i915)) {
default:
@@ -431,6 +433,10 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id,
if (GRAPHICS_VER(i915) == 12 && engine->class == RENDER_CLASS)
engine->props.preempt_timeout_ms = 0;
+ /* features common between engines sharing EUs */
+ if (engine->class == RENDER_CLASS || engine->class == COMPUTE_CLASS)
+ engine->flags |= I915_ENGINE_HAS_RCS_REG_STATE;
+
engine->defaults = engine->props; /* never to change again */
engine->context_size = intel_engine_context_size(gt, engine->class);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index f4533ccafbaf..5fa5f21bbf2d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -524,6 +524,7 @@ struct intel_engine_cs {
#define I915_ENGINE_HAS_RELATIVE_MMIO BIT(6)
#define I915_ENGINE_REQUIRES_CMD_PARSER BIT(7)
#define I915_ENGINE_WANT_FORCED_PREEMPTION BIT(8)
+#define I915_ENGINE_HAS_RCS_REG_STATE BIT(9)
unsigned int flags;
/*
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 961d795220a3..47fca5ebfa76 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3480,7 +3480,7 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
logical_ring_default_vfuncs(engine);
logical_ring_default_irqs(engine);
- if (engine->class == RENDER_CLASS)
+ if (engine->flags & I915_ENGINE_HAS_RCS_REG_STATE)
rcs_submission_override(engine);
lrc_init_wa_ctx(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 004e1216e654..d333400d29fe 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/g
[Intel-gfx] [PATCH v2 03/13] drm/i915/xehp: Add Compute CS IRQ handlers
Add execlists and GuC interrupts for compute CS into existing IRQ handlers. All compute command streamers belong to the same compute class, so the only change needed to enable their interrupts is to program their GT engine interrupt mask registers. CCS0 shares the register with CCS1, while CCS2 and CCS3 are in a new one. BSpec: 50844, 54029, 54030, 53223, 53224. Original-author: Michel Thierry Cc: Tvrtko Ursulin Cc: Vinay Belgaumkar Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Aravind Iddamsetty Signed-off-by: Matt Roper Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_gt_irq.c | 15 ++- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ drivers/gpu/drm/i915/i915_drv.h | 2 ++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c b/drivers/gpu/drm/i915/gt/intel_gt_irq.c index 983264e10e0a..e443ac4c8059 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c @@ -100,7 +100,7 @@ gen11_gt_identity_handler(struct intel_gt *gt, const u32 identity) if (unlikely(!intr)) return; - if (class <= COPY_ENGINE_CLASS) + if (class <= COPY_ENGINE_CLASS || class == COMPUTE_CLASS) return gen11_engine_irq_handler(gt, class, instance, intr); if (class == OTHER_CLASS) @@ -182,6 +182,8 @@ void gen11_gt_irq_reset(struct intel_gt *gt) /* Disable RCS, BCS, VCS and VECS class engines. */ intel_uncore_write(uncore, GEN11_RENDER_COPY_INTR_ENABLE, 0); intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE,0); + if (CCS_MASK(gt)) + intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, 0); /* Restore masks irqs on RCS, BCS, VCS and VECS engines. */ intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~0); @@ -195,6 +197,10 @@ void gen11_gt_irq_reset(struct intel_gt *gt) intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK, ~0); if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3)) intel_uncore_write(uncore, GEN12_VECS2_VECS3_INTR_MASK, ~0); + if (HAS_ENGINE(gt, CCS0) || HAS_ENGINE(gt, CCS1)) + intel_uncore_write(uncore, GEN12_CCS0_CCS1_INTR_MASK, ~0); + if (HAS_ENGINE(gt, CCS2) || HAS_ENGINE(gt, CCS3)) + intel_uncore_write(uncore, GEN12_CCS2_CCS3_INTR_MASK, ~0); intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0); intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0); @@ -225,6 +231,8 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt) /* Enable RCS, BCS, VCS and VECS class interrupts. */ intel_uncore_write(uncore, GEN11_RENDER_COPY_INTR_ENABLE, dmask); intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE, dmask); + if (CCS_MASK(gt)) + intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, smask); /* Unmask irqs on RCS, BCS, VCS and VECS engines. */ intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask); @@ -238,6 +246,11 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt) intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK, ~dmask); if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3)) intel_uncore_write(uncore, GEN12_VECS2_VECS3_INTR_MASK, ~dmask); + if (HAS_ENGINE(gt, CCS0) || HAS_ENGINE(gt, CCS1)) + intel_uncore_write(uncore, GEN12_CCS0_CCS1_INTR_MASK, ~dmask); + if (HAS_ENGINE(gt, CCS2) || HAS_ENGINE(gt, CCS3)) + intel_uncore_write(uncore, GEN12_CCS2_CCS3_INTR_MASK, ~dmask); + /* * RPS interrupts will get enabled/disabled on demand when RPS itself * is enabled/disabled. diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 530807bfe9a0..69b826a3c381 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1468,6 +1468,7 @@ #define GEN11_GPM_WGBOXPERF_INTR_ENABLE_MMIO(0x19003c) #define GEN11_CRYPTO_RSVD_INTR_ENABLE _MMIO(0x190040) #define GEN11_GUNIT_CSME_INTR_ENABLE _MMIO(0x190044) +#define GEN12_CCS_RSVD_INTR_ENABLE _MMIO(0x190048) #define GEN11_INTR_IDENTITY_REG(x) _MMIO(0x190060 + ((x) * 4)) #define GEN11_INTR_DATA_VALID(1 << 31) @@ -1493,6 +1494,8 @@ #define GEN11_GPM_WGBOXPERF_INTR_MASK _MMIO(0x1900ec) #define GEN11_CRYPTO_RSVD_INTR_MASK_MMIO(0x1900f0) #define GEN11_GUNIT_CSME_INTR_MASK _MMIO(0x1900f4) +#define GEN12_CCS0_CCS1_INTR_MASK _MMIO(0x190100) +#define GEN12_CCS2_CCS3_INTR_MASK _MMIO(0x190104) #define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index d26a3eaee270..457bc1993d19 100644 --- a/drivers/gpu/drm/i915/i915_drv
[Intel-gfx] [PATCH v2 00/13] i915: Prepare for Xe_HP compute engines
The Xe_HP architecture introduces compute engines as a new engine class. These compute command streamers (CCS) are similar to the render engine, except that they're intended for GPGPU usage and lack support for the 3D pipeline. For now we're just sending some initial "under the hood" preparation for CCS engines without actually exposing them to userspace or adding them to any platform's engine list yet. There may be a bit more GuC-related updates necessary before it's safe to expose them, so the actual uabi bits will come later once that's all worked out. Daniele Ceraolo Spurio (3): drm/i915/xehp: compute engine pipe_control drm/i915/xehp/guc: enable compute engine inside GuC drm/i915/xehp: handle fused off CCS engines Matt Roper (8): drm/i915/xehp: Define compute class and engine drm/i915/xehp: CCS shares the render reset domain drm/i915/xehp: Add Compute CS IRQ handlers drm/i915/xehp: CCS should use RCS setup functions drm/i915: Move context descriptor fields to intel_lrc.h drm/i915/xehp: Define context scheduling attributes in lrc descriptor drm/i915/xehp: Enable ccs/dual-ctx in RCU_MODE drm/i915/xehp: Add compute workarounds Matthew Brost (1): drm/i915/xehp: Don't support parallel submission on compute / render Srinivasan Shanmugam (1): drm/i915/xehpsdv: Move render/compute engine reset domains related workarounds drivers/gpu/drm/i915/gem/i915_gem_context.c | 10 +++ .../drm/i915/gem/selftests/i915_gem_context.c | 8 +- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 35 ++-- drivers/gpu/drm/i915/gt/intel_engine.h| 2 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 83 +++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 11 ++- drivers/gpu/drm/i915/gt/intel_engine_user.c | 5 +- .../drm/i915/gt/intel_execlists_submission.c | 24 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 drivers/gpu/drm/i915/gt/intel_gt_irq.c| 15 +++- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 45 +++--- drivers/gpu/drm/i915/gt/intel_lrc.c | 10 ++- drivers/gpu/drm/i915/gt/intel_lrc.h | 51 drivers/gpu/drm/i915/gt/intel_sseu.c | 17 +++- drivers/gpu/drm/i915/gt/intel_sseu.h | 4 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 73 +--- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 5 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 32 +-- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 18 +++- .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 4 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_reg.h | 4 + 22 files changed, 393 insertions(+), 80 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v8 00/13] Add GuC Error Capture Support
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global, engine class and engine instance registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Updates usage and buffer-state data for the regions of the shared GuC log-buffer to accomdate both the existing relay logging of general debug logs along with the new error state capture usage. 5. Using a pool of preallocated memory, provide ability to extract and format the GuC reported register-capture data into chunks consistent with existing i915 error- state collection flows and structures. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 8th rev of this series with the first 3 revs labelled as RFC. Prior receipts of rvb's: - Patch #5, #12 have received R-v-b's from Umesh Nerlige Ramappa - Patch #6 has received an R-v-b from Matthew Brost Changes from prior revs: v8: - Fix a bug found by CI in rev7: Create a cached ADS capture list for null-header like the other lists. v7: - Rebased on lastest drm_tip that has the ADS now using shmem based ads_blob_write utilities. Stress test was performed with this patch included to fix a legacy bug: https://patchwork.freedesktop.org/series/100768/ v6: - In patch #1, ADS reg-list population, we now alloc regular memory to create the lists and cache them for simpler and faster use by GuC ADS module at init, suspend-resume and reset cycles. This was in response to review comments from Lucas De Marchi that also wanted to ensure the GuC ADS module owns the final copying into the ADS phyical memory. - Thanks to Jani Nikula for pointing out that patch #2 and #3 should ensure static tables as constant and dynamic lists should be allocated and cached but attached to the GT level for the case of multiple cards with different fusings for steered registers. These are addressed now along with multiple code style fixups (thanks to review comment from Umesh) and splitting the steered register list generation as a seperate patch. - The extraction functionality, Patch #10 and #11 (was patch #7), has fixed all of Umesh's review comments related to the code styling. Additionally, it was discovered during stress tests that the extraction function could be called by the ct processing thread at the same time as the start of a GT reset event. Thus, a redesign was done whereby the linked list of processed capture-output-nodes are allocated up front and reused throughout the driver's life to ensure no memory locks are taken during extraction. - For patch #6 (now 7, 8 and 9), updates to intel_guc_log was split into smaller chunks and the log_state structure was returned back to inside of the intel_guc_log struct as opposed to the intel_guc struct in prior rev. This is in response to review comments by Matt Brost. - #Patch 13 (previously #10) is mostly identical but addresses all of the code styling comments reviews from Umesh. v5: - Added Gen9->Gen11 register list for CI coverage that included Gen9 with GuC submission. - Redesigned the extraction of the GuC error-capture dumps by grouping them into complete per-engine-reset nodes. Complete here means each node includes the global, engine-class and engine-instance register lists in a single structure. - Extraction is decoupled from the print-out. We now do the extraction immediately when receiving the G2H for error-capture notification. A link list of nodes is maintained with a FIFO based threshold while awaiting retrieval from i915_gpu_coredump's capture_engine function. - Added new plumbing through the i915_gpu_coredump allocation and capture functions to include a flag that is used indicate that GuC had triggered the reset. This new plumbing guarantees an exact match from i915_gpu_coredump's per-engine vma recording and node-retrieval from the guc-error-capture. - Broke the coredump gt_global capture and recording functions into smaller subsets so we can reuse as much of the existing legacy register reading + printing functions and only rely on GuC error-capture for the smaller subset of registers that are tied to
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts
On 25/02/2022 18:48, John Harrison wrote: On 2/25/2022 10:14, Tvrtko Ursulin wrote: I'll try to simplify the discussion here: On 24/02/2022 19:45, John Harrison wrote: On 2/24/2022 03:41, Tvrtko Ursulin wrote: On 23/02/2022 20:00, John Harrison wrote: On 2/23/2022 05:58, Tvrtko Ursulin wrote: On 23/02/2022 02:45, John Harrison wrote: On 2/22/2022 03:19, Tvrtko Ursulin wrote: On 18/02/2022 21:33, john.c.harri...@intel.com wrote: From: John Harrison Compute workloads are inherantly not pre-emptible for long periods on current hardware. As a workaround for this, the pre-emption timeout for compute capable engines was disabled. This is undesirable with GuC submission as it prevents per engine reset of hung contexts. Hence the next patch will re-enable the timeout but bumped up by an order of magnititude. (Some typos above.) I'm spotting 'inherently' but not anything else. Magnititude! O;) Doh! [snip] Whereas, bumping all heartbeat periods to be greater than the pre-emption timeout is wasteful and unnecessary. That leads to a total heartbeat time of about a minute. Which is a very long time to wait for a hang to be detected and recovered. Especially when the official limit on a context responding to an 'are you dead' query is only 7.5 seconds. Not sure how did you get one minute? 7.5 * 2 (to be safe) = 15. 15 * 5 (number of heartbeat periods) = 75 => 1 minute 15 seconds Even ignoring any safety factor and just going with 7.5 * 5 still gets you to 37.5 seconds which is over a half a minute and likely to race. Ah because my starting point is there should be no preempt timeout = heartbeat * 3, I just think that's too ugly. Then complain at the hardware designers to give us mid-thread pre-emption back. The heartbeat is only one source of pre-emption events. For example, a user can be running multiple contexts in parallel and expecting them to time slice on a single engine. Or maybe a user is just running one compute task in the background but is doing render work in the foreground. Etc. There was a reason the original hack was to disable pre-emption rather than increase the heartbeat. This is simply a slightly less ugly version of the same hack. And unfortunately, the basic idea of the hack is non-negotiable. As per other comments, 'tP(RCS) = tH *3' or 'tP(RCS) = tP(default) * 12' or 'tP(RCS) = 7500' are the available options. Given that the heartbeat is the ever present hard limit, it seems most plausible to base the hack on that. Any of the others works, though. Although I think a explicit hardcoded value is the most ugly. I guess the other option is to add CONFIG_DRM_I915_PREEMPT_TIMEOUT_COMPUTE and default that to 7500. Take your pick. But 640ms is not allowed. Regardless, crux of argument was to avoid GuC engine reset and heartbeat reset racing with each other, and to do that by considering the preempt timeout with the heartbeat interval. I was thinking about this scenario in this series: [Please use fixed width font and no line wrap to view.] A) tP = preempt timeout tH = hearbeat interval tP = 3 * tH 1) Background load = I915_PRIORITY_DISPLAY <-- [tH] --> Pulse1 <-- [tH] --> Pulse2 <-- [tH] --> Pulse3 < [2 * tH] > FULL RESET | \- preemption triggered, tP = 3 * tH --\ \-> preempt timeout would hit here Here we have collateral damage due full reset, since we can't tell GuC to reset just one engine and we fudged tP just to "account" for heartbeats. You are missing the whole point of the patch series which is that the last heartbeat period is '2 * tP' not '2 * tH'. + longer = READ_ONCE(engine->props.preempt_timeout_ms) * 2; By making the last period double the pre-emption timeout, it is guaranteed that the FULL RESET stage cannot be hit before the hardware has attempted and timed-out on at least one pre-emption. Oh well :) that probably means the overall scheme is too odd for me. tp = 3tH and last pulse after 2tP I mean. To be accurate, it is 'tP(RCS) = 3 * tH(default); tH(final) = tP(current) * 2;'. Seems fairly straight forward to me. It's not a recursive definition or anything like that. It gives us a total heartbeat timeout that is close to the original version but still allows at least one pre-emption event. [snip] <-- [tH] --> Pulse1 <-- [tH] --> Pulse2 <-- [tH] --> Pulse3 < [2 * tH] > full reset would be here | \- preemption triggered, tP = 3 * tH \ \-> Preempt timeout reset Here is is kind of least worse, but question is why we fudged tP when it gives us nothing good in this case. The point of fudging tP(RCS) is to give compute workloads longer to reach a pre-emptible point (given that EU walkers are basically not pre-emptible). The reason for doing the fudge is not connected to the heartbeat at all. The fact that
[Intel-gfx] [PATCH v8 00/13] Add GuC Error Capture Support
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global, engine class and engine instance registers with GuC. 3. Defines tables of register lists that are global or engine class or engine instance in scope. 4. Updates usage and buffer-state data for the regions of the shared GuC log-buffer to accomdate both the existing relay logging of general debug logs along with the new error state capture usage. 5. Using a pool of preallocated memory, provide ability to extract and format the GuC reported register-capture data into chunks consistent with existing i915 error- state collection flows and structures. 6. Connects the i915_gpu_coredump reporting function to the GuC error capture module to print all GuC error state capture dumps that is reported. This is the 8th rev of this series with the first 3 revs labelled as RFC. Prior receipts of rvb's: - Patch #5, #12 have received R-v-b's from Umesh Nerlige Ramappa - Patch #6 has received an R-v-b from Matthew Brost Changes from prior revs: v8: - Fix a bug found by CI in rev7: Create a cached ADS capture list for null-header like the other lists. v7: - Rebased on lastest drm_tip that has the ADS now using shmem based ads_blob_write utilities. Stress test was performed with this patch included to fix a legacy bug: https://patchwork.freedesktop.org/series/100768/ v6: - In patch #1, ADS reg-list population, we now alloc regular memory to create the lists and cache them for simpler and faster use by GuC ADS module at init, suspend-resume and reset cycles. This was in response to review comments from Lucas De Marchi that also wanted to ensure the GuC ADS module owns the final copying into the ADS phyical memory. - Thanks to Jani Nikula for pointing out that patch #2 and #3 should ensure static tables as constant and dynamic lists should be allocated and cached but attached to the GT level for the case of multiple cards with different fusings for steered registers. These are addressed now along with multiple code style fixups (thanks to review comment from Umesh) and splitting the steered register list generation as a seperate patch. - The extraction functionality, Patch #10 and #11 (was patch #7), has fixed all of Umesh's review comments related to the code styling. Additionally, it was discovered during stress tests that the extraction function could be called by the ct processing thread at the same time as the start of a GT reset event. Thus, a redesign was done whereby the linked list of processed capture-output-nodes are allocated up front and reused throughout the driver's life to ensure no memory locks are taken during extraction. - For patch #6 (now 7, 8 and 9), updates to intel_guc_log was split into smaller chunks and the log_state structure was returned back to inside of the intel_guc_log struct as opposed to the intel_guc struct in prior rev. This is in response to review comments by Matt Brost. - #Patch 13 (previously #10) is mostly identical but addresses all of the code styling comments reviews from Umesh. v5: - Added Gen9->Gen11 register list for CI coverage that included Gen9 with GuC submission. - Redesigned the extraction of the GuC error-capture dumps by grouping them into complete per-engine-reset nodes. Complete here means each node includes the global, engine-class and engine-instance register lists in a single structure. - Extraction is decoupled from the print-out. We now do the extraction immediately when receiving the G2H for error-capture notification. A link list of nodes is maintained with a FIFO based threshold while awaiting retrieval from i915_gpu_coredump's capture_engine function. - Added new plumbing through the i915_gpu_coredump allocation and capture functions to include a flag that is used indicate that GuC had triggered the reset. This new plumbing guarantees an exact match from i915_gpu_coredump's per-engine vma recording and node-retrieval from the guc-error-capture. - Broke the coredump gt_global capture and recording functions into smaller subsets so we can reuse as much of the existing legacy register reading + printing functions and only rely on GuC error-capture for the smaller subset of registers that are tied to
Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow
On 25/02/2022 17:39, John Harrison wrote: On 2/25/2022 09:06, Tvrtko Ursulin wrote: On 24/02/2022 19:19, John Harrison wrote: [snip] ./gt/uc/intel_guc_fwif.h: u32 execution_quantum; ./gt/uc/intel_guc_submission.c: desc->execution_quantum = engine->props.timeslice_duration_ms * 1000; ./gt/intel_engine_types.h: unsigned long timeslice_duration_ms; timeslice_store/preempt_timeout_store: err = kstrtoull(buf, 0, &duration); So both kconfig and sysfs can already overflow GuC, not only because of tick conversion internally but because at backend level nothing was done for assigning 64-bit into 32-bit. Or I failed to find where it is handled. That's why I'm adding this range check to make sure we don't allow overflows. Yes and no, this fixes it, but the first bug was not only due GuC internal tick conversion. It was present ever since the u64 from i915 was shoved into u32 sent to GuC. So even if GuC used the value without additional multiplication, bug was be there. My point being when GuC backend was added timeout_ms values should have been limited/clamped to U32_MAX. The tick discovery is additional limit on top. I'm not disagreeing. I'm just saying that the truncation wasn't noticed until I actually tried using very long timeouts to debug a particular problem. Now that it is noticed, we need some method of range checking and this simple clamp solves all the truncation problems. Agreed in principle, just please mention in the commit message all aspects of the problem. I think we can get away without a Fixes: tag since it requires user fiddling to break things in unexpected ways. I would though put in a code a clamping which expresses both, something like min(u32, ..GUC LIMIT..). So the full story is documented forever. Or "if > u32 || > ..GUC LIMIT..) return -EINVAL". Just in case GuC limit one day changes but u32 stays. Perhaps internal ticks go away or anything and we are left with plain 1:1 millisecond relationship. Can certainly add a comment along the lines of "GuC API only takes a 32bit field but that is further reduced to GUC_LIMIT due to internal calculations which would otherwise overflow". But if the GuC limit is > u32 then, by definition, that means the GuC API has changed to take a u64 instead of a u32. So there will no u32 truncation any more. So I'm not seeing a need to explicitly test the integer size when the value check covers that. Hmm I was thinking if the internal conversion in the GuC fw changes so that GUC_POLICY_MAX_PREEMPT_TIMEOUT_MS goes above u32, then to be extra safe by documenting in code there is the additional limit of the data structure field. Say the field was changed to take some unit larger than a millisecond. Then the check against the GuC MAX limit define would not be enough, unless that would account both for internal implementation and u32 in the protocol. Maybe that is overdefensive but I don't see that it harms. 50-50, but it's do it once and forget so I'd do it. Huh? How can the limit be greater than a u32 if the interface only takes a u32? By definition the limit would be clamped to u32 size. If you mean that the GuC policy is in different units and those units might not overflow but ms units do, then actually that is already the case. The GuC works in us not ms. That's part of why the wrap around is so low, we have to multiply by 1000 before sending to GuC. However, that is actually irrelevant because the comparison is being done on the i915 side in i915's units. We have to scale the GuC limit to match what i915 is using. And the i915 side is u64 so if the scaling to i915 numbers overflows a u32 then who cares because that comparison can be done at 64 bits wide. If the units change then that is a backwards breaking API change that will require a manual driver code update. You can't just recompile with a new header and magically get an ms to us or ms to s conversion in your a = b assignment. The code will need to be changed to do the new unit conversion (note we already convert from ms to us, the GuC API is all expressed in us). And that code change will mean having to revisit any and all scaling, type conversions, etc. I.e. any pre-existing checks will not necessarily be valid and will need to be re-visted anyway. But as above, any scaling to GuC units has to be incorporated into the limit already because otherwise the limit would not fit in the GuC's own API. Yes I get that, I was just worried that u32 field in the protocol and GUC_POLICY_MAX_EXEC_QUANTUM_MS defines are separate in the source code and then how to protect against forgetting to update both in sync. Like if the protocol was changed to take nanoseconds, and firmware implementation changed to support the full range, but define left/forgotten at 100s. That would then overflow u32. Regards, Tvrtko John. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 15 ++
[Intel-gfx] [PATCH] HAX: drm/i915: Disable GuC submission on DG1
This is just to try to repro the execlist selftest failure I'm seeing on
my local DG1 with GuC submission disabled.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index da199aa6989f..563913fad35b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -41,6 +41,11 @@ static void uc_expand_default_options(struct intel_uc *uc)
return;
}
+ if (IS_DG1(i915)) {
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ return;
+ }
+
/* Default: enable HuC authentication and GuC submission */
i915->params.enable_guc = ENABLE_GUC_LOAD_HUC | ENABLE_GUC_SUBMISSION;
}
--
2.34.1
Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads
On 25/02/2022 19:03, John Harrison wrote:
On 2/25/2022 10:29, Tvrtko Ursulin wrote:
On 25/02/2022 18:01, John Harrison wrote:
On 2/25/2022 09:39, Tvrtko Ursulin wrote:
On 25/02/2022 17:11, John Harrison wrote:
On 2/25/2022 08:36, Tvrtko Ursulin wrote:
On 24/02/2022 20:02, John Harrison wrote:
On 2/23/2022 04:00, Tvrtko Ursulin wrote:
On 23/02/2022 02:22, John Harrison wrote:
On 2/22/2022 01:53, Tvrtko Ursulin wrote:
On 18/02/2022 21:33, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible on current
hardware.
Thus the pre-emption timeout was disabled as a workaround to
prevent
unwanted resets. Instead, the hang detection was left to the
heartbeat
and its (longer) timeout. This is undesirable with GuC
submission as
the heartbeat is a full GT reset rather than a per engine
reset and so
is much more destructive. Instead, just bump the pre-emption
timeout
Can we have a feature request to allow asking GuC for an
engine reset?
For what purpose?
To allow "stopped heartbeat" to reset the engine, however..
GuC manages the scheduling of contexts across engines. With
virtual engines, the KMD has no knowledge of which engine a
context might be executing on. Even without virtual engines,
the KMD still has no knowledge of which context is currently
executing on any given engine at any given time.
There is a reason why hang detection should be left to the
entity that is doing the scheduling. Any other entity is second
guessing at best.
The reason for keeping the heartbeat around even when GuC
submission is enabled is for the case where the KMD/GuC have
got out of sync with either other somehow or GuC itself has
just crashed. I.e. when no submission at all is working and we
need to reset the GuC itself and start over.
.. I wasn't really up to speed to know/remember heartbeats are
nerfed already in GuC mode.
Not sure what you mean by that claim. Engine resets are handled
by GuC because GuC handles the scheduling. You can't do the
former if you aren't doing the latter. However, the heartbeat is
still present and is still the watchdog by which engine resets
are triggered. As per the rest of the submission process, the
hang detection and recovery is split between i915 and GuC.
I meant that "stopped heartbeat on engine XXX" can only do a full
GPU reset on GuC.
I mean that there is no 'stopped heartbeat on engine XXX' when i915
is not handling the recovery part of the process.
H?
static void
reset_engine(struct intel_engine_cs *engine, struct i915_request *rq)
{
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
show_heartbeat(rq, engine);
if (intel_engine_uses_guc(engine))
/*
* GuC itself is toast or GuC's hang detection
* is disabled. Either way, need to find the
* hang culprit manually.
*/
intel_guc_find_hung_context(engine);
intel_gt_handle_error(engine->gt, engine->mask,
I915_ERROR_CAPTURE,
"stopped heartbeat on %s",
engine->name);
}
How there is no "stopped hearbeat" in guc mode? From this code it
certainly looks there is.
Only when the GuC is toast and it is no longer an engine reset but a
full GT reset that is required. So technically, it is not a 'stopped
heartbeat on engine XXX' it is 'stopped heartbeat on GT#'.
You say below heartbeats are going in GuC mode. Now I totally don't
understand how they are going but there is allegedly no "stopped
hearbeat".
Because if GuC is handling the detection and recovery then i915 will
not reach that point. GuC will do the engine reset and start
scheduling the next context before the heartbeat period expires. So
the notification will be a G2H about a specific context being reset
rather than the i915 notification about a stopped heartbeat.
intel_gt_handle_error(engine->gt, engine->mask,
I915_ERROR_CAPTURE,
"stopped heartbeat on %s",
engine->name);
intel_gt_handle_error:
/*
* Try engine reset when available. We fall back to full reset if
* single reset fails.
*/
if (!intel_uc_uses_guc_submission(>->uc) &&
intel_has_reset_engine(gt) && !intel_gt_is_wedged(gt)) {
local_bh_disable();
for_each_engine_masked(engine, gt, engine_mask, tmp) {
You said "However, the heartbeat is still present and is still the
watchdog by which engine resets are triggered", now I don't know
what you meant by this. It actually triggers a single engine reset
in GuC mode? Where in code does that happen if this block above
shows it not taking the engine reset path?
i915 sends down the per engine pulse.
GuC schedules the pulse
GuC attempts to pre-empt the currently active context
GuC detects the pre-emption timeout
GuC resets the engine
The fundamental process is exactly the same as in execlist mode.
It's just that the above blocks of code (calls to
intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: Update dma_buf_ops.unmap_dma_buf callback to use drm_gem_unmap_dma_buf()
Reviewed-by: Nirmoy Das
On 25/02/2022 14:13, Gwan-gyeong Mun wrote:
The dma_buf_ops.unmap_dma_buf callback used in i915,
i915_gem_unmap_dma_buf(), has the same code as drm_gem_unmap_dma_buf().
In order to eliminate defining and using duplicate function, it updates
the dma_buf_ops.unmap_dma_buf callback to use drm_gem_unmap_dma_buf().
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 13917231ae81..af899ae1f3c7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -66,15 +66,6 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
return ERR_PTR(ret);
}
-static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
- struct sg_table *sg,
- enum dma_data_direction dir)
-{
- dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
- sg_free_table(sg);
- kfree(sg);
-}
-
static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf,
struct iosys_map *map)
{
@@ -209,7 +200,7 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
.attach = i915_gem_dmabuf_attach,
.detach = i915_gem_dmabuf_detach,
.map_dma_buf = i915_gem_map_dma_buf,
- .unmap_dma_buf = i915_gem_unmap_dma_buf,
+ .unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
.mmap = i915_gem_dmabuf_mmap,
.vmap = i915_gem_dmabuf_vmap,
[Intel-gfx] ✓ Fi.CI.BAT: success for Fix prime_mmap to work when using LMEM (rev2)
== Series Details ==
Series: Fix prime_mmap to work when using LMEM (rev2)
URL : https://patchwork.freedesktop.org/series/100737/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11297 -> Patchwork_22432
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/index.html
Participating hosts (46 -> 41)
--
Additional (1): fi-pnv-d510
Missing(6): fi-kbl-soraka shard-tglu fi-bsw-cyan shard-rkl shard-dg1
fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22432:
### IGT changes ###
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:
- {bat-dg2-9}:NOTRUN -> [DMESG-WARN][1] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_lmem_swapping@parallel-random-engines@lmem0:
- {bat-dg2-9}:NOTRUN -> [FAIL][2] +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-dg2-9/igt@gem_lmem_swapping@parallel-random-engi...@lmem0.html
* igt@gem_lmem_swapping@verify-random@lmem0:
- {bat-dg2-9}:NOTRUN -> [INCOMPLETE][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-dg2-9/igt@gem_lmem_swapping@verify-ran...@lmem0.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- {bat-dg2-9}:NOTRUN -> [SKIP][4] +6 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-dg2-9/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html
Known issues
Here are the changes found in Patchwork_22432 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-ivb-3770:NOTRUN -> [SKIP][5] ([fdo#109271]) +17 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/fi-ivb-3770/igt@amdgpu/amd_pr...@amd-to-i915.html
* igt@gem_huc_copy@huc-copy:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +39 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [PASS][7] -> [DMESG-WARN][8] ([i915#3576]) +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/bat-adlp-4/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-adlp-4/igt@i915_pm_...@module-reload.html
* igt@i915_pm_rps@basic-api:
- bat-dg1-5: [PASS][9] -> [FAIL][10] ([i915#4032])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/bat-dg1-5/igt@i915_pm_...@basic-api.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-dg1-5/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][11] -> [INCOMPLETE][12] ([i915#3921])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][13] ([i915#2927])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#2403] /
[i915#4312])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/fi-pnv-d510/igt@run...@aborted.html
Possible fixes
* {igt@gem_exec_basic@basic@vecs1-lmem0}:
- {bat-dg2-9}:[DMESG-WARN][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/bat-dg2-9/igt@gem_exec_basic@ba...@vecs1-lmem0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-dg2-9/igt@gem_exec_basic@ba...@vecs1-lmem0.html
* igt@i915_selftest@live@hangcheck:
- fi-ivb-3770:[INCOMPLETE][17] ([i915#3303]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/fi-ivb-3770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][19] ([i915#3576]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11297/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22432/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
Warnings
* i
Re: [Intel-gfx] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later standards > introduce many other features, most of these are already available in > gnu89 as GNU extensions as well. > > An earlier attempt to do this when gcc-5 started defaulting to > -std=gnu11 failed because at the time that caused warnings about > designated initializers with older compilers. Now that gcc-5.1 is the > minimum compiler version used for building kernels, that is no longer a > concern. Similarly, the behavior of 'inline' functions changes between > gnu89 and gnu89, but this was taken care of by defining 'inline' to Typo here? Second one should be gnu99 right? > include __attribute__((gnu_inline)) in order to allow building with > clang a while ago. > > One minor issue that remains is an added gcc warning for shifts of > negative integers when building with -Werror, which happens with the > 'make W=1' option, as well as for three drivers in the kernel that always > enable -Werror, but it was only observed with the i915 driver so far. > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > warning that appears in a system header on arm, this still needs a > workaround. > > Since the differences between gnu99, gnu11 and gnu17 are fairly minimal > and mainly impact warnings at the -Wpedantic level that the kernel > never enables, the easiest way is to just leave out the -std=gnu89 > argument entirely, and rely on the compiler default language setting, > which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported > versions of gcc or clang. > > Link: > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > Suggested-by: Linus Torvalds > Cc: Masahiro Yamada > Cc: linux-kbu...@vger.kernel.org > Cc: l...@lists.linux.dev > Signed-off-by: Arnd Bergmann > --- > I put the suggestion into patch form, based on what we discussed > in the thread. I only gave it minimal testing, but it would > be good to have it in linux-next if we want to do this in the > merge window. > --- > Documentation/process/programming-language.rst | 4 ++-- > .../translations/it_IT/process/programming-language.rst| 4 ++-- > .../translations/zh_CN/process/programming-language.rst| 4 ++-- > .../translations/zh_TW/process/programming-language.rst| 4 ++-- > Makefile | 7 +++ > arch/arm64/kernel/vdso32/Makefile | 3 +-- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/staging/greybus/tools/Makefile | 3 ++- > fs/btrfs/Makefile | 1 + > scripts/Makefile.extrawarn | 1 + > 10 files changed, 17 insertions(+), 15 deletions(-) > > diff --git a/Documentation/process/programming-language.rst > b/Documentation/process/programming-language.rst > index ec474a70a02f..894f2a6eb9db 100644 > --- a/Documentation/process/programming-language.rst > +++ b/Documentation/process/programming-language.rst > @@ -5,8 +5,8 @@ Programming Language > > The kernel is written in the C programming language [c-language]_. > More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ > -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 > -(including some C99 features). ``clang`` [clang]_ is also supported, see > +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 > +(including some C17 features). ``clang`` [clang]_ is also supported, see > docs on :ref:`Building Linux with Clang/LLVM `. > > This dialect contains many extensions to the language [gnu-extensions]_, > diff --git > a/Documentation/translations/it_IT/process/programming-language.rst > b/Documentation/translations/it_IT/process/programming-language.rst > index 41db2598ce11..aa21097737ae 100644 > --- a/Documentation/translations/it_IT/process/programming-language.rst > +++ b/Documentation/translations/it_IT/process/programming-language.rst > @@ -10,8 +10,8 @@ Linguaggio di programmazione > > Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_. > Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando > -l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU > -dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99). > +l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU > +dello standard ISO C11 (con l'aggiunta di alcune funzionalità da C17). > Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione > :ref:`Building Linux with Clang/LLVM `. > > diff --git > a/Documenta
Re: [Intel-gfx] [greybus-dev] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
On 2/27/22 5:11 PM, Linus Torvalds wrote: On Sun, Feb 27, 2022 at 3:04 PM Alex Elder wrote: Glancing at the Greybus code, I don't believe there's any reason it needs to shift a negative value. Such warnings could be fixed by making certain variables unsigned, for example. As mentioned in the original thread, making things unsigned actually is likely to introduce bugs and make things worse. Understood. What I meant is that the shifts were producing single-bit masks from plain int values that range from 0 to 10 or something (in a for loop). Looking again though, that it's not so simple. Regardless, your point about the warning is good and I won't plan to "fix" this. Thanks. -Alex The warning is simply bogus, and the fact that it was enabled by -Wextra in gcc for std=gnu99 and up was a mistake that looks likely to be fixed in gcc. So don't try to "fix" the code to make any possible warnings go away. You may just make things worse. (That is often true in general for the more esoteric warnings, but in this case it's just painfully more obvious). Linus
[Intel-gfx] [PATCH 0/6] Remove usage of list iterator past the loop body
This is the first patch removing several categories of use cases of
the list iterator variable past the loop.
This is follow up to the discussion in:
https://lore.kernel.org/all/20220217184829.1991035-1-jakobkosc...@gmail.com/
As concluded in:
https://lore.kernel.org/all/yhdfeiwi4edth...@kroah.com/
the correct use should be using a separate variable after the loop
and using a 'tmp' variable as the list iterator.
The list iterator will not point to a valid structure after the loop
if no break/goto was hit. Invalid uses of the list iterator variable
can be avoided altogether by simply using a separate pointer to
iterate the list.
Linus and Greg agreed on the following pattern:
- struct gr_request *req;
+ struct gr_request *req = NULL;
+ struct gr_request *tmp;
struct gr_ep *ep;
int ret = 0;
- list_for_each_entry(req, &ep->queue, queue) {
- if (&req->req == _req)
+ list_for_each_entry(tmp, &ep->queue, queue) {
+ if (&tmp->req == _req) {
+ req = tmp;
break;
+ }
}
- if (&req->req != _req) {
+ if (!req) {
ret = -EINVAL;
goto out;
}
With gnu89 the list iterator variable cannot yet be declared
within the for loop of the list iterator.
Moving to a more modern version of C would allow defining
the list iterator variable within the macro, limiting
the scope to the loop.
This avoids any incorrect usage past the loop altogether.
This are around 30% of the cases where the iterator
variable is used past the loop (identified with a slightly
modified version of use_after_iter.cocci).
I've decided to split it into at a few patches separated
by similar use cases.
Because the output of get_maintainer.pl was too big,
I included all the found lists and everyone from the
previous discussion.
Jakob Koschel (6):
drivers: usb: remove usage of list iterator past the loop body
treewide: remove using list iterator after loop body as a ptr
treewide: fix incorrect use to determine if list is empty
drivers: remove unnecessary use of list iterator variable
treewide: remove dereference of list iterator after loop body
treewide: remove check of list iterator against head past the loop
body
arch/arm/mach-mmp/sram.c | 9 ++--
arch/arm/plat-pxa/ssp.c | 28 +---
arch/powerpc/sysdev/fsl_gtm.c | 4 +-
arch/x86/kernel/cpu/sgx/encl.c| 6 ++-
drivers/block/drbd/drbd_req.c | 45 ---
drivers/counter/counter-chrdev.c | 26 ++-
drivers/crypto/cavium/nitrox/nitrox_main.c| 11 +++--
drivers/dma/dw-edma/dw-edma-core.c| 4 +-
drivers/dma/ppc4xx/adma.c | 11 +++--
drivers/firewire/core-transaction.c | 32 +++--
drivers/firewire/sbp2.c | 14 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 19 +---
drivers/gpu/drm/drm_memory.c | 15 ---
drivers/gpu/drm/drm_mm.c | 17 ---
drivers/gpu/drm/drm_vm.c | 13 +++---
drivers/gpu/drm/gma500/oaktrail_lvds.c| 9 ++--
drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 15 ---
drivers/gpu/drm/i915/gt/intel_ring.c | 15 ---
.../gpu/drm/nouveau/nvkm/subdev/clk/base.c| 11 +++--
.../gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 13 +++---
drivers/gpu/drm/scheduler/sched_main.c| 14 +++---
drivers/gpu/drm/ttm/ttm_bo.c | 19
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 +
drivers/infiniband/hw/hfi1/tid_rdma.c | 16 ---
drivers/infiniband/hw/mlx4/main.c | 12 ++---
drivers/media/dvb-frontends/mxl5xx.c | 11 +++--
drivers/media/pci/saa7134/saa7134-alsa.c | 4 +-
drivers/media/v4l2-core/v4l2-ctrls-api.c | 31 +++--
drivers/misc/mei/interrupt.c | 12 ++---
.../net/ethernet/intel/i40e/i40e_ethtool.c| 3 +-
.../net/ethernet/qlogic/qede/qede_filter.c| 11 +++--
drivers/net/wireless/ath/ath6kl/htc_mbox.c| 2 +-
.../net/wireless/intel/ipw2x00/libipw_rx.c| 15 ---
drivers/perf/xgene_pmu.c | 13 +++---
drivers/power/supply/cpcap-battery.c | 11 +++--
drivers/scsi/lpfc/lpfc_bsg.c | 16 ---
drivers/scsi/scsi_transport_sas.c | 17 ---
drivers/scsi/wd719x.c | 12 +++--
drivers/staging/rtl8192e/rtl819x_TSProc.c | 17 +++
drivers/staging/rtl8192e/rtllib_rx.c | 17 ---
.../staging/rtl8192u/ieee80211/ieee80211_rx.c | 15 ---
.../rtl8192u/ieee80211/rtl819x_TSProc.c | 19
drivers/thermal/thermal_core.c| 38 ++--
drivers/usb/gadget/composite.c| 9 ++--
d
Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > warning that appears in a system header on arm, this still needs a > > workaround. > > On the topic of Wdeclaration-after-statement, Clang only respects this > warning with C99 and later starting with Clang 14: > https://github.com/llvm/llvm-project/commit/c65186c89f35#diff-ec770381d76c859f5f572db789175fe44410a72608f58ad5dbb14335ba56eb97R61 > > Until Clang 14, -Wdeclaration-after-statement is ignored by Clang in > newer standards. If this is a big problem, we can probably convince > the Clang stable folks to backport the fixes. However, the build won't > fail, folks might just miss the warning if they don't also test with > GCC. I don't expect this is to be a big issue, as long as the latest clang behaves as expected. There are many warnings that are only produced by one of the two compilers, so this is something we already deal with. I think it's more important to address the extra warning that Nathan reported, where clang now complains about the intermingled declaration in a system header when previously neither gcc nor clang noticed this. > > The differences between gnu99, gnu11, gnu1x and gnu17 are fairly > > minimal and mainly impact warnings at the -Wpedantic level that the > > kernel never enables. Between these, gnu11 is the newest version > > that is supported by all supported compiler versions, though it is > > only the default on gcc-5, while all other supported versions of > > gcc or clang default to gnu1x/gnu17. > > > > Link: > > https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ > > Link: https://github.com/ClangBuiltLinux/linux/issues/1603 > > Suggested-by: Linus Torvalds > > Cc: Masahiro Yamada > > Cc: linux-kbu...@vger.kernel.org > > Cc: l...@lists.linux.dev > > Signed-off-by: Arnd Bergmann > > Acked-by: Marco Elver Thanks, Arnd
Re: [Intel-gfx] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
On Mon, Feb 28, 2022 at 1:14 AM John Stoffel wrote: > > On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > During a patch discussion, Linus brought up the option of changing > > the C standard version from gnu89 to gnu99, which allows using variable > > declaration inside of a for() loop. While the C99, C11 and later standards > > introduce many other features, most of these are already available in > > gnu89 as GNU extensions as well. > > > > An earlier attempt to do this when gcc-5 started defaulting to > > -std=gnu11 failed because at the time that caused warnings about > > designated initializers with older compilers. Now that gcc-5.1 is the > > minimum compiler version used for building kernels, that is no longer a > > concern. Similarly, the behavior of 'inline' functions changes between > > gnu89 and gnu89, but this was taken care of by defining 'inline' to > > Typo here? Second one should be gnu99 right? Fixed, thanks! Arnd
[Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11
From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 and gnu11, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago. One minor issue that remains is an added gcc warning for shifts of negative integers when building with -Werror, which happens with the 'make W=1' option, as well as for three drivers in the kernel that always enable -Werror, but it was only observed with the i915 driver so far. To be on the safe side, add -Wno-shift-negative-value to any -Wextra in a Makefile. Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround. The differences between gnu99, gnu11, gnu1x and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables. Between these, gnu11 is the newest version that is supported by all supported compiler versions, though it is only the default on gcc-5, while all other supported versions of gcc or clang default to gnu1x/gnu17. Link: https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds Cc: Masahiro Yamada Cc: linux-kbu...@vger.kernel.org Cc: l...@lists.linux.dev Signed-off-by: Arnd Bergmann --- [v2] - added -std=gnu11 back, rather than just relying on the default - minor changes to changelog text --- Documentation/process/programming-language.rst | 4 ++-- .../translations/it_IT/process/programming-language.rst | 4 ++-- .../translations/zh_CN/process/programming-language.rst | 4 ++-- .../translations/zh_TW/process/programming-language.rst | 4 ++-- Makefile| 6 +++--- arch/arm64/kernel/vdso32/Makefile | 2 +- drivers/gpu/drm/i915/Makefile | 1 + drivers/staging/greybus/tools/Makefile | 3 ++- fs/btrfs/Makefile | 1 + scripts/Makefile.extrawarn | 1 + 10 files changed, 17 insertions(+), 13 deletions(-) diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index ec474a70a02f..894f2a6eb9db 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -5,8 +5,8 @@ Programming Language The kernel is written in the C programming language [c-language]_. More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 -(including some C99 features). ``clang`` [clang]_ is also supported, see +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 +(including some C17 features). ``clang`` [clang]_ is also supported, see docs on :ref:`Building Linux with Clang/LLVM `. This dialect contains many extensions to the language [gnu-extensions]_, diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index 41db2598ce11..aa21097737ae 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -10,8 +10,8 @@ Linguaggio di programmazione Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_. Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando -l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU -dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99). +l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU +dello standard ISO C11 (con l'aggiunta di alcune funzionalità da C17). Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione :ref:`Building Linux with Clang/LLVM `. diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst index 2a47a1d2ec20..58d2b3bd2d85 100644 --- a/Documentation/translations/zh_CN/process/programming-language.rst +++ b/Documentation/translations/zh_CN/process/programming-language.rst @
