[Intel-gfx] [PATCH v8 5/5] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Acked-by: Jordan Justen
Reviewed-by: Ramalingam C
Reviewed-by: Thomas Hellström
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE (which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
[Intel-gfx] [PATCH v8 3/5] drm/i915: support 64K GTT pages for discrete cards
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
atomic_read(&pt->used));
GEM_BUG_ON(!count || count >= atomic_read(&pt->used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
-count);
+num_ptes);
[Intel-gfx] [PATCH v8 1/5] drm/i915: add needs_compact_pt flag
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
v6:
* minor doc formatting
Suggested-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_drv.h | 11 ---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00e7594b59c9..4afdfa5fd3b3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,17 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
*/
#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+/*
+ * Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 2df2db0a5d70..ce6ae6a3cbdf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1046,6 +1047,7 @@ static const struct intel_device_info dg2_info = {
PLATFORM(INTEL_DG2),
.has_guc_deprivilege = 1,
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index abf1e103c558..d8da40d01dca 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+ func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
--
2.25.1
[Intel-gfx] [PATCH v8 2/5] drm/i915: enforce min GTT alignment for discrete cards
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
v3:
* use needs_compact_pt flag to discriminate between
64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
if compact-pt instead of hard coding
v5:
* fix i915_vm_obj_min_alignment for internal objects which
have no memory region
v6:
* tiled_blits_create correctly pick largest required alignment
v8:
* i915_vm_min_alignment protect against array overflow for mock region
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../i915/gem/selftests/i915_gem_client_blt.c | 21 ++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 22 +
drivers/gpu/drm/i915/i915_vma.c | 9 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
5 files changed, 119 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..3675d12a7d9a 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,19 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL);
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(&t->ce->vm->mutex);
memset(&hole, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(&t->ce->vm->mm, &hole,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +434,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +461,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +492,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +505,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct
rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
-&t->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+&t->buffers[2], t->hole + t->align,
&t->buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
GEM_BUG_ON(!vm->total);
[Intel-gfx] [PATCH v8 0/5] discrete card 64K page support
This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lmem buffers - enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert - expand vma reservation to round up to 2MB on DG2 in i915_vma_insert - add alignment test v2: rebase and fix for async vma that landed v3: * fix uapi doc typos * add needs_compact_pt flag patch * cleanup vma expansion to use vm->min_alignment instead of hard coding v4: * fix err return in igt_ppgtt_compact test * placate ci robot with explicit enum conversion in misaligned_pin * remove some blank lines v5: * fix obj alignment requirements querying for internal buffers that have no memory region associated. (fixes v3 bug) v6: * use NEEDS_COMPACT_PT inead of hard coding in misalignment test * tiled_blits_create correctly pick largest required alignment * minor doc formatting v7: * use i915_vma_unbind_unlocked in misalignment test v8: * fix misalignment test corner case for uninitialized stolen smem * fix misalignment test corner case for single page gtt hole * fix array overflow in i915_vm_min_alignment for mock region Reviewed-by: Thomas Hellström Matthew Auld (3): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/uapi: document behaviour for DG2 64K support Ramalingam C (1): drm/i915: add needs_compact_pt flag Robert Beckett (1): drm/i915: add gtt misalignment test .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 + .../i915/gem/selftests/i915_gem_client_blt.c | 21 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 - drivers/gpu/drm/i915/gt/intel_gtt.c | 12 + drivers/gpu/drm/i915/gt/intel_gtt.h | 25 ++ drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 11 +- drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_vma.c | 9 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 222 +++--- include/uapi/drm/i915_drm.h | 44 +++- 12 files changed, 464 insertions(+), 52 deletions(-) -- 2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
== Series Details == Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2) URL : https://patchwork.freedesktop.org/series/99671/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11203_full -> Patchwork_22210_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22210_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22210_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22210_full: ### IGT changes ### Possible regressions * igt@syncobj_timeline@transfer-timeline-point: - shard-apl: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-apl4/igt@syncobj_timel...@transfer-timeline-point.html Known issues Here are the changes found in Patchwork_22210_full that come from known issues: ### IGT changes ### Issues hit * igt@core_getclient: - shard-skl: [PASS][2] -> [DMESG-WARN][3] ([i915#1982]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-skl6/igt@core_getclient.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-skl9/igt@core_getclient.html * igt@feature_discovery@psr2: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#658]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-iclb2/igt@feature_discov...@psr2.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-iclb6/igt@feature_discov...@psr2.html * igt@gem_exec_balancer@parallel: - shard-kbl: NOTRUN -> [DMESG-WARN][6] ([i915#5076]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-kbl3/igt@gem_exec_balan...@parallel.html * igt@gem_exec_capture@pi@vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][7] ([i915#4547]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-skl6/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_capture@pi@vecs0: - shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([i915#3371]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/shard-tglb5/igt@gem_exec_capture@p...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-tglb1/igt@gem_exec_capture@p...@vecs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) +5 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_params@no-vebox: - shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109283]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-iclb8/igt@gem_exec_par...@no-vebox.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-skl4/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-skl7/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@random-engines: - shard-iclb: NOTRUN -> [SKIP][15] ([i915#4613]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-iclb8/igt@gem_lmem_swapp...@random-engines.html - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-apl6/igt@gem_lmem_swapp...@random-engines.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-apl6/igt@gem_pwr...@basic-exhaustion.html * igt@gem_pxp@verify-pxp-stale-ctx-execution: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-iclb8/igt@gem_...@verify-pxp-stale-ctx-execution.html * igt@gem_render_copy@yf-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#768]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/shard-iclb8/igt@gem_render_c...@yf-tiled-to-vebox-linear.html * igt@gem_userptr_blits@readonly-pwrite-unsync: - shard-iclb:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp, drm/i915: 128b/132b updates (rev6)
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev6)
URL : https://patchwork.freedesktop.org/series/99324/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22212
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/index.html
Participating hosts (45 -> 43)
--
Missing(2): fi-icl-u2 shard-tglu
Known issues
Here are the changes found in Patchwork_22212 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][1] -> [INCOMPLETE][2] ([i915#4547])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
- fi-bdw-5557u: [PASS][3] -> [INCOMPLETE][4] ([i915#146])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-guc: [DMESG-FAIL][5] ([i915#2291] / [i915#541]) ->
[PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][7] ([i915#4269]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11203 -> Patchwork_22212
CI-20190529: 20190529
CI_DRM_11203: e0f14f95759ad65e896868e1f9efd3247d93d28e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22212: fd1b3bb062a3878000ef868c04d92de4c141c79a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
fd1b3bb062a3 HACK: drm/i915/dp: give more time for CDS
bc5810b9bc72 drm/i915/mst: update slot information for 128b/132b
1500a79f114f drm/i915/dp: add 128b/132b support to link status checks
7b1a2c456190 drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
6e1a572e0fee drm/i915/dp: move intel_dp_prepare_link_train() call
fbe9d00f0423 drm/dp: add some new DPCD macros from DP 2.0 E11
2b74cd3aa4a7 drm/dp: add 128b/132b link status helpers from DP 2.0 E11
b1c38d738be2 drm/dp: add drm_dp_128b132b_read_aux_rd_interval()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22212/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: 128b/132b updates (rev6)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev6) URL : https://patchwork.freedesktop.org/series/99324/ 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 11/21] fbcon: Extract fbcon_open/release helpers
On Tue, Feb 08, 2022 at 07:24:03PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > > Hi Daniel,
> > >
> > > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > > There's two minor behaviour changes in here:
> > > > - in error paths we now consistently call fb_ops->fb_release
> > > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > > reasonable cleanup we can do anyway.
> > > >
> > > > Signed-off-by: Daniel Vetter
> > > > Cc: Daniel Vetter
> > > > Cc: Claudio Suarez
> > > > Cc: Greg Kroah-Hartman
> > > > Cc: Tetsuo Handa
> > > > Cc: Du Cheng
> > > > ---
> > > > drivers/video/fbdev/core/fbcon.c | 107 +++
> > > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > > >
> > > > diff --git a/drivers/video/fbdev/core/fbcon.c
> > > > b/drivers/video/fbdev/core/fbcon.c
> > > > index fa30e1909164..eea2ee14b64c 100644
> > > > --- a/drivers/video/fbdev/core/fbcon.c
> > > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info
> > > > *info, unsigned charcount)
> > > >
> > > > #endif /* CONFIG_MISC_TILEBLITTING */
> > > >
> > > > +static int fbcon_open(struct fb_info *info)
> > > > +{
> > > > + if (!try_module_get(info->fbops->owner))
> > > > + return -ENODEV;
> > > > +
> > > > + if (info->fbops->fb_open &&
> > > > + info->fbops->fb_open(info, 0)) {
> > > > + module_put(info->fbops->owner);
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void fbcon_release(struct fb_info *info)
> > > > +{
> > > > + if (info->fbops->fb_release)
> > > > + info->fbops->fb_release(info, 0);
> > > > +
> > > > + module_put(info->fbops->owner);
> > > > +}
> > > >
> > > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info
> > > > *info,
> > > > int unit, int oldidx)
> > > > {
> > > > struct fbcon_ops *ops = NULL;
> > > > - int err = 0;
> > > > -
> > > > - if (!try_module_get(info->fbops->owner))
> > > > - err = -ENODEV;
> > > > + int err;
> > > >
> > > > - if (!err && info->fbops->fb_open &&
> > > > - info->fbops->fb_open(info, 0))
> > > > - err = -ENODEV;
> > > > + err = fbcon_open(info);
> > > > + if (err)
> > > > + return err;
> > > >
> > > > if (!err) {
> > > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data
> > > > *vc, struct fb_info *info,
> > > >
> > > > if (err) {
> > > > con2fb_map[unit] = oldidx;
> > > > - module_put(info->fbops->owner);
> > > > + fbcon_release(info);
> > > > }
> > > >
> > > > return err;
> > > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data
> > > > *vc, struct fb_info *oldinfo,
> > > > int oldidx, int found)
> > > > {
> > > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > > - int err = 0, ret;
> > > > + int ret;
> > > >
> > > > - if (oldinfo->fbops->fb_release &&
> > > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > > - con2fb_map[unit] = oldidx;
> > > The old code assigns con2fb_map[unit] before is calls
> > > newinfo->fbops->fb_release).
> > > I wonder if there can be any callback to fbcon where the value
> > > of con2fb_map[unit] matters?
> >
> > It's all protected by console_lock, so other threads cannot see the
> > inconsistent state.
> >
> > Essentially everything in fbcon.c is protected by console_lock().
> >
> > Do you want me to hammer this in somewhere (maybe in the commit message),
> > or good enough for your ack?
>
> No need to spell it out more.
I think this was a very good question, since I had to spend a few minutes
figuring out what exactly and why I've done it too.
So I'll add this explainer, it really should have been in the commit
message!
> Add my a-b and apply it.
Well I need to resend, since there was a minor change due to rebasing on
top of Helge's fbcon scrolling patches instead of mine.
Thanks for your review
-Daniel
>
> Sam
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/dp, drm/i915: 128b/132b updates (rev6)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev6) URL : https://patchwork.freedesktop.org/series/99324/ State : warning == Summary == $ dim checkpatch origin/drm-tip b1c38d738be2 drm/dp: add drm_dp_128b132b_read_aux_rd_interval() 2b74cd3aa4a7 drm/dp: add 128b/132b link status helpers from DP 2.0 E11 fbe9d00f0423 drm/dp: add some new DPCD macros from DP 2.0 E11 6e1a572e0fee drm/i915/dp: move intel_dp_prepare_link_train() call 7b1a2c456190 drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata -:108: CHECK:LINE_SPACING: Please don't use multiple blank lines #108: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1132: + -:333: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #333: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1357: + + } total: 0 errors, 0 warnings, 2 checks, 337 lines checked 1500a79f114f drm/i915/dp: add 128b/132b support to link status checks bc5810b9bc72 drm/i915/mst: update slot information for 128b/132b fd1b3bb062a3 HACK: drm/i915/dp: give more time for CDS
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
== Series Details ==
Series: drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/99853/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22211
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22211 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22211, 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_22211/index.html
Participating hosts (45 -> 43)
--
Missing(2): shard-tglu fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22211:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22211 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][2] -> [DMESG-FAIL][3] ([i915#4528] /
[i915#5026])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-cfl-8109u: [PASS][5] -> [DMESG-WARN][6] ([i915#295]) +12 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-cfl-8109u/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271]) +13 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
* igt@runner@aborted:
- fi-blb-e6850: NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#2403] /
[i915#2426] / [i915#4312])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-blb-e6850/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-guc: [DMESG-FAIL][9] ([i915#2291] / [i915#541]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#295]: https://gitlab.freedesktop.org/drm/intel/issues/295
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#5026]: https://gitlab.freedesktop.org/drm/intel/issues/5026
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11203 -> Patchwork_22211
CI-20190529: 20190529
CI_DRM_11203: e0f14f95759ad65e896868e1f9efd3247d93d28e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22211: 8ed7bbe053b56b8ca9dc69705b7c8a719f5fd692 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8ed7bbe053b5 drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22211/index.html
[Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef
With upcoming lock tracepoints config, it'd define some of lockdep functions without enabling CONFIG_LOCKDEP actually. The existing code assumes those functions will be removed by the preprocessor but it's not the case anymore. Let's protect the code with #ifdef's explicitly. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim --- drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c index dfd87d082218..6e4b8d036283 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.c +++ b/drivers/gpu/drm/i915/intel_wakeref.c @@ -106,8 +106,11 @@ void __intel_wakeref_init(struct intel_wakeref *wf, wf->wakeref = 0; INIT_DELAYED_WORK(&wf->work, __intel_wakeref_put_work); + +#ifdef CONFIG_LOCKDEP lockdep_init_map(&wf->work.work.lockdep_map, "wakeref.work", &key->work, 0); +#endif } int intel_wakeref_wait_for_idle(struct intel_wakeref *wf) -- 2.35.0.263.gb82422642f-goog
[Intel-gfx] [RFC RESEND 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1.1)
Hello,
(Resending with Paul's correct email address, sorry!)
There have been some requests for low-overhead kernel lock contention
monitoring. The kernel has CONFIG_LOCK_STAT to provide such an infra
either via /proc/lock_stat or tracepoints directly.
However it's not light-weight and hard to be used in production. So
I'm trying to separate out the tracepoints and using them as a base to
build a new monitoring system.
* Changes in v1.1
- add some Acked-by's
- add comments on cgroup rstat cpu lock
As the lockdep and lock_stat provide good hooks in the lock functions,
it'd be natural to reuse them. Actually I tried to use lockdep as is
but disables the functionality at runtime (initialize debug_locks = 0,
lock_stat = 0). But it still has unacceptable overhead and the
lockdep data structures also increase memory footprint unnecessarily.
So I'm proposing a separate tracepoint-only configuration and keeping
lockdep_map only with minimal information needed for tracepoints (for
now, it's just name). And then the existing lockdep hooks can be used
for the tracepoints.
The patch 01-06 are preparation for the work. In a few places in the
kernel, they calls lockdep annotation explicitly to deal with
limitations in the lockdep implementation. In my understanding, they
are not needed to analyze lock contention.
To make matters worse, they rely on the compiler optimization (or
macro magic) so that it can get rid of the annotations and their
arguments when lockdep is not configured.
But it's not true any more when lock tracepoints are added and it'd
cause build errors. So I added #ifdef guards for LOCKDEP in the code
to prevent such errors.
In the patch 07 I mechanically changed most of code that depend on
CONFIG_LOCKDEP or CONFIG_DEBUG_LOCK_ALLOC to CONFIG_LOCK_INFO. It
paves the way for the codes to be shared for lockdep and tracepoints.
Mostly, it makes sure that locks are initialized with a proper name,
like in the patch 08 and 09.
I didn't change some places intentionally - for example, timer and
workqueue depend on LOCKDEP explicitly since they use some lockdep
annotations to work around the "held lock freed" warnings. The ocfs2
directly accesses lockdep_map.key so I didn't touch the code for now.
And RCU was because it generates too much overhead thanks to the
rcu_read_lock(). Maybe I need to revisit some of them later.
I added CONFIG_LOCK_TRACEPOINTS in the patch 10 to make it optional.
I found that it adds 2~3% of overhead when I ran `perf bench sched
messaging` even when the tracepoints are disabled. The benchmark
creates a lot of processes and make them communicate by socket pairs
(or pipes). I measured that around 15% of lock acquisition creates
contentions and it's mostly for spin locks (alc->lock and u->lock).
I ran perf record + report with the workload and it showed 50% of the
cpu cycles are in the spin lock slow path. So it's highly affected by
the spin lock slow path. Actually LOCK_CONTENDED() macro transforms
the spin lock code (and others) to use trylock first and then fall
back to real lock function if failed. Thus it'd add more (atomic)
operations and cache line bouncing for the contended cases:
#define LOCK_CONTENDED(_lock, try, lock) \
do { \
if (!try(_lock)) {\
lock_contended(&(_lock)->dep_map, _RET_IP_); \
lock(_lock); \
} \
lock_acquired(&(_lock)->dep_map, _RET_IP_); \
} while (0)
If I modify the macro not to use trylock and to call the real lock
function directly (so the lock_contended tracepoint would be called
always, if enabled), the overhead goes down to 0.x% when the
tracepoints are disabled.
I don't have a good solution as long as we use LOCK_CONTENDED() macro
to separate the contended locking path. Maybe we can make it call
some (generic) slow path lock function directly after failing trylock.
Or move the lockdep annotations into the each lock function bodies and
get rid of the LOCK_CONTENDED() macro entirely. Ideas?
Actually the patch 11 handles the same issue on the mutex code. The
fast version of mutex trylock was attempted only if LOCKDEP is not
enabled and it affects the mutex lock performance in the uncontended
cases too. So I partially reverted the change in the patch 07 to use
the fast functions with lock tracepoints too. Maybe we can use it
with LOCKDEP as well?
The last patch 12 might be controversial and I'd like to move the
lock_acquired annotation into the if(!try) block in the LOCK_CONTEDED
macro so that it can only be called when there's a contention.
Eventually I'm mostly interested in the contended locks only and I
want to reduce the overhead in the fast path. By moving that, it'd be
easy to track contended locks with timing by using two tracepoints.
It'd change lock hold time calculation in lock_stat fo
Re: [Intel-gfx] [PATCH v5 06/10] drm/i915/guc: Update GuC's log-buffer-state access for error capture.
Hi Matt, thank you for taking the time to review the codes.
Answering your question inline below.
On Fri, 2022-02-04 at 10:19 -0800, Matthew Brost wrote:
> On Wed, Jan 26, 2022 at 02:48:18AM -0800, Alan Previn wrote:
> > GuC log buffer regions for debug-log-events, crash-dumps and
> > error-state-capture are all a single bo allocation that includes
> > the guc_log_buffer_state structures.
> >
> > Since the error-capture region is accessed with high priority at non-
> > deterministic times (as part of gpu coredump) while the debug-log-event
> > region is populated and accessed with different priorities, timings and
> > consumers, let's split out separate locks for buffer-state accesses
> > of each region.
> >
> > Also, ensure a global mapping is made up front for the entire bo
> > throughout GuC operation so that dynamic mapping and unmapping isn't
> > required for error capture log access if relay-logging isn't running.
> >
> > Additionally, while here, make some readibility improvements:
> > 1. change previous function names with "capture_logs" to
> >"copy_debug_logs" to help make the distinction clearer.
> > 2. Update the guc log region mapping comments to order them
> >according to the enum definition as per the GuC interface.
> >
> > Signed-off-by: Alan Previn
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
> > .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 47 ++
> > .../gpu/drm/i915/gt/uc/intel_guc_capture.h| 1 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 135 +++---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_log.h| 16 ++-
> > 5 files changed, 141 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 4e819853ec2e..be1ad7fa2bf8 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -34,6 +34,8 @@ struct intel_guc {
> > struct intel_uc_fw fw;
> > /** @log: sub-structure containing GuC log related data and objects */
> > struct intel_guc_log log;
> > + /** @log_state: states and locks for each subregion of GuC's log buffer
> > */
> > + struct intel_guc_log_stats log_state[GUC_MAX_LOG_BUFFER];
>
> Why move this? This still probably should be sub-structure of
> intel_guc_log. Most of the access is from functions that pass in
> intel_guc_log, then retrieve the GuC object, only to access this new
> intel_guc_log_stats object. That layering seems wrong, if the argument
> to a function is intel_guc_log it should really try to access members
> within that object or below. Obv some exceptions exist but here it seems
> clear to me this is in the wrong place.
>
So the reasoning i had was because because intel_guc_log module only managed
guc-relay-logging and guc-log-dumping for log-events but allocates the buffer
for 3 separate subregion/usages (i.e. log-events, crash-dump and error-capture).
That said, I did not want intel_guc_capture and relay-logging (or log-dumping)
to have to contend with the same lock because these two subregions are
completely
independant of each other in terms of when they are being accessed and why.
However, after the redesign of rev5 (this rev), I now believe the
intel_guc_capture
module does not require a lock because its only ever accessing its log
subregion in response to the ctb handler functions that run out of the same
queue.
As we know intel_guc_capture reacts to G2H-error-capture-notification and
G2H-context-reset
(that trickles into i915_gpu_coredump). At the point of i915_error_state dump,
intel_guc_capture module does not access the buffer - it merely dumps the
already-parsed
and engine-dump-node (that was detached from error-capture's internal
linked-list
and attached to the gpu_coredump structure in the second G2H above).
And of course, intel_guc_log only ever accesses the log-events subregion
and never the error-capture regions.
That said, i could revert the lock structure to the original and not have
intel_guc_capture using locks. What do you think?
...alan
> Another nit, I'd personally break this out into multiple patches.
>
> e.g. 1 to rename relay log functions, 1 introducing intel_guc_log_stats
> + lock, and 1 adding intel_guc_capture_output_min_size_est. Maybe I'm
> missing another patch or two in there.
>
> Not a blocker but it does make reviews easier.
>
Will do.
> Matt
>
> > /** @ct: the command transport communication channel */
> > struct intel_guc_ct ct;
> > /** @slpc: sub-structure containing SLPC related data and objects */
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > index 70d2ee841289..e7f99d051636 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> > @@ -651,6 +651,53 @@ int intel_guc_capture_prep_lists(struct intel_guc
> > *guc, struct guc_ads
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef
Hello, On Tue, Feb 8, 2022 at 10:51 AM Jani Nikula wrote: > > On Tue, 08 Feb 2022, Namhyung Kim wrote: > > With upcoming lock tracepoints config, it'd define some of lockdep > > functions without enabling CONFIG_LOCKDEP actually. The existing code > > assumes those functions will be removed by the preprocessor but it's > > not the case anymore. Let's protect the code with #ifdef's explicitly. > > I don't understand why you can't keep the no-op stubs for > CONFIG_LOCKDEP=n. Because I want to use the lockdep annotation for other purposes. But the workqueue lockdep_map was defined under LOCKDEP only. Please see the description in the cover letter. https://lore.kernel.org/all/20220208184208.79303-1-namhy...@kernel.org/ Thanks, Namhyung
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
== Series Details == Series: drm/i915: move intel_hws_csb_write_index() out of i915_drv.h URL : https://patchwork.freedesktop.org/series/99853/ 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/i915: move intel_hws_csb_write_index() out of i915_drv.h
== Series Details == Series: drm/i915: move intel_hws_csb_write_index() out of i915_drv.h URL : https://patchwork.freedesktop.org/series/99853/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8ed7bbe053b5 drm/i915: move intel_hws_csb_write_index() out of i915_drv.h -:51: WARNING:LONG_LINE: line length of 112 exceeds 100 columns #51: FILE: drivers/gpu/drm/i915/gvt/execlist.c:166: + hwsp_gpa + INTEL_HWS_CSB_WRITE_INDEX(execlist->engine->i915) * 4, total: 0 errors, 1 warnings, 0 checks, 42 lines checked
Re: [Intel-gfx] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)
Oops, I used the wrong email address of Paul. Sorry about that!
I'll resend with a new address soon.
Thanks,
Namhyung
On Tue, Feb 8, 2022 at 10:42 AM Namhyung Kim wrote:
>
> Hello,
>
> There have been some requests for low-overhead kernel lock contention
> monitoring. The kernel has CONFIG_LOCK_STAT to provide such an infra
> either via /proc/lock_stat or tracepoints directly.
>
> However it's not light-weight and hard to be used in production. So
> I'm trying to separate out the tracepoints and using them as a base to
> build a new monitoring system.
>
> As the lockdep and lock_stat provide good hooks in the lock functions,
> it'd be natural to reuse them. Actually I tried to use lockdep as is
> but disables the functionality at runtime (initialize debug_locks = 0,
> lock_stat = 0). But it still has unacceptable overhead and the
> lockdep data structures also increase memory footprint unnecessarily.
>
> So I'm proposing a separate tracepoint-only configuration and keeping
> lockdep_map only with minimal information needed for tracepoints (for
> now, it's just name). And then the existing lockdep hooks can be used
> for the tracepoints.
>
> The patch 01-06 are preparation for the work. In a few places in the
> kernel, they calls lockdep annotation explicitly to deal with
> limitations in the lockdep implementation. In my understanding, they
> are not needed to analyze lock contention.
>
> To make matters worse, they rely on the compiler optimization (or
> macro magic) so that it can get rid of the annotations and their
> arguments when lockdep is not configured.
>
> But it's not true any more when lock tracepoints are added and it'd
> cause build errors. So I added #ifdef guards for LOCKDEP in the code
> to prevent such errors.
>
> In the patch 07 I mechanically changed most of code that depend on
> CONFIG_LOCKDEP or CONFIG_DEBUG_LOCK_ALLOC to CONFIG_LOCK_INFO. It
> paves the way for the codes to be shared for lockdep and tracepoints.
> Mostly, it makes sure that locks are initialized with a proper name,
> like in the patch 08 and 09.
>
> I didn't change some places intentionally - for example, timer and
> workqueue depend on LOCKDEP explicitly since they use some lockdep
> annotations to work around the "held lock freed" warnings. The ocfs2
> directly accesses lockdep_map.key so I didn't touch the code for now.
> And RCU was because it generates too much overhead thanks to the
> rcu_read_lock(). Maybe I need to revisit some of them later.
>
> I added CONFIG_LOCK_TRACEPOINTS in the patch 10 to make it optional.
> I found that it adds 2~3% of overhead when I ran `perf bench sched
> messaging` even when the tracepoints are disabled. The benchmark
> creates a lot of processes and make them communicate by socket pairs
> (or pipes). I measured that around 15% of lock acquisition creates
> contentions and it's mostly for spin locks (alc->lock and u->lock).
>
> I ran perf record + report with the workload and it showed 50% of the
> cpu cycles are in the spin lock slow path. So it's highly affected by
> the spin lock slow path. Actually LOCK_CONTENDED() macro transforms
> the spin lock code (and others) to use trylock first and then fall
> back to real lock function if failed. Thus it'd add more (atomic)
> operations and cache line bouncing for the contended cases:
>
> #define LOCK_CONTENDED(_lock, try, lock) \
> do { \
> if (!try(_lock)) {\
> lock_contended(&(_lock)->dep_map, _RET_IP_); \
> lock(_lock); \
> } \
> lock_acquired(&(_lock)->dep_map, _RET_IP_); \
> } while (0)
>
> If I modify the macro not to use trylock and to call the real lock
> function directly (so the lock_contended tracepoint would be called
> always, if enabled), the overhead goes down to 0.x% when the
> tracepoints are disabled.
>
> I don't have a good solution as long as we use LOCK_CONTENDED() macro
> to separate the contended locking path. Maybe we can make it call
> some (generic) slow path lock function directly after failing trylock.
> Or move the lockdep annotations into the each lock function bodies and
> get rid of the LOCK_CONTENDED() macro entirely. Ideas?
>
> Actually the patch 11 handles the same issue on the mutex code. The
> fast version of mutex trylock was attempted only if LOCKDEP is not
> enabled and it affects the mutex lock performance in the uncontended
> cases too. So I partially reverted the change in the patch 07 to use
> the fast functions with lock tracepoints too. Maybe we can use it
> with LOCKDEP as well?
>
> The last patch 12 might be controversial and I'd like to move the
> lock_acquired annotation into the if(!try) block in the LOCK_CONTEDED
> macro so that it can only be called when there's a contention.
>
> Eventually I'm mostly interested in the contended lock
Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Add fallback inside memcpy_from_wc functions
On Mon, Feb 07, 2022 at 09:43:08PM +0530, Balasubramani Vivekanandan wrote:
memcpy_from_wc functions can fail if SSE4.1 is not supported or the
supplied addresses are not 16-byte aligned. It was then upto to the
caller to use memcpy as fallback.
Now fallback to memcpy is implemented inside memcpy_from_wc functions
relieving the user from checking the return value of i915_memcpy_from_wc
and doing fallback.
When doing copying from io memory address memcpy_fromio should be used
as fallback. So a new function is added to the family of memcpy_to_wc
functions which should be used while copying from io memory.
This change is implemented also with an intention to perpare for porting
memcpy_from_wc code to ARM64. Since SSE4.1 is not valid for ARM,
accelerated reads will not be supported and the driver should rely on
fallback always.
So there would be few more places in the code where fallback should be
introduced. For e.g. GuC log relay is currently not using fallback since
a GPU supporting GuC submission will mostly have SSE4.1 enabled CPU.
This is no more valid with Discrete GPU and with enabling support for
ARM64.
With fallback moved inside memcpy_from_wc function, call sites would
look neat and fallback can be implemented in a uniform way.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 8 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 9 ++-
drivers/gpu/drm/i915/i915_memcpy.c | 78 --
drivers/gpu/drm/i915/i915_memcpy.h | 18 ++---
5 files changed, 78 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index e03e362d320b..e187c4bfb7e4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -444,7 +444,7 @@ 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;
+ const void __iomem *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,
@@ -452,8 +452,7 @@ i915_gem_object_read_from_page_iomap(struct
drm_i915_gem_object *obj, u64 offset
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);
+ i915_io_memcpy_from_wc(dst, src_ptr, size);
nitpick, but maybe to align with the memcpy_fromio() API this would
better be named i915_memcpy_fromio_wc()?
io_mapping_unmap(src_map);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..64b8521a8b28 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -99,8 +99,10 @@ __igt_reset_stolen(struct intel_gt *gt,
memset_io(s, STACK_MAGIC, PAGE_SIZE);
in = (void __force *)s;
- if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
+ if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
in = tmp;
+ }
crc[page] = crc32_le(0, in, PAGE_SIZE);
io_mapping_unmap(s);
@@ -135,8 +137,10 @@ __igt_reset_stolen(struct intel_gt *gt,
PAGE_SIZE);
in = (void __force *)s;
- if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE))
+ if (i915_can_memcpy_from_wc(tmp, in, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(tmp, in, PAGE_SIZE);
but you removed __iomem above
in = tmp;
+ }
x = crc32_le(0, in, PAGE_SIZE);
if (x != crc[page] &&
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 127ff56c8ce6..2c14a28c 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -297,8 +297,10 @@ static int compress_page(struct i915_vma_compress *c,
struct z_stream_s *zstream = &c->zstream;
zstream->next_in = src;
- if (wc && c->tmp && i915_memcpy_from_wc(c->tmp, src, PAGE_SIZE))
+ if (wc && c->tmp && i915_can_memcpy_from_wc(c->tmp, src, PAGE_SIZE)) {
+ i915_io_memcpy_from_wc(c->tmp, (const void __iomem *)src,
PAGE_SIZE);
zstream->next_in = c->tmp;
+ }
zstream->avail_in = PAGE_SIZE;
do {
@@ -397,8 +399,11 @@ static int compress_page(struct i915_vma_compress *c,
if (!ptr)
return -ENOMEM;
- if (!(wc && i915_memcpy_from_wc(ptr, src, PAGE_SIZE)))
+ if (wc)
+ i915_io_
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
== Series Details ==
Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
URL : https://patchwork.freedesktop.org/series/99671/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22210
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/index.html
Participating hosts (45 -> 43)
--
Missing(2): fi-icl-u2 shard-tglu
Known issues
Here are the changes found in Patchwork_22210 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#3303])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: [PASS][3] -> [FAIL][4] ([i915#4547])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#1436] /
[i915#4312])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/fi-hsw-4770/igt@run...@aborted.html
- fi-skl-6600u: NOTRUN -> [FAIL][6] ([i915#4312])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/fi-skl-6600u/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-guc: [DMESG-FAIL][7] ([i915#2291] / [i915#541]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][9] ([i915#4269]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/fi-cml-u2/igt@kms_frontbuffer_track...@basic.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#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11203 -> Patchwork_22210
CI-20190529: 20190529
CI_DRM_11203: e0f14f95759ad65e896868e1f9efd3247d93d28e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22210: 2d61486947f426f7bd84ad50e96bcf75c248568b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2d61486947f4 drm/i915: move the DRIVER_* macros to i915_driver.[ch]
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22210/index.html
Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
>
> Cc oldc_dcon maintainers as fyi.
>
> Cc: Jens Frederich
> Cc: Jon Nettleton
> Cc: Greg Kroah-Hartman
> Cc: linux-stag...@lists.linux.dev
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Helge Deller
> Cc: Matthew Wilcox
> Cc: Sam Ravnborg
> Cc: Tetsuo Handa
> Cc: Zhen Lei
> Cc: Alex Deucher
> Cc: Xiyu Yang
> Cc: linux-fb...@vger.kernel.org
> Cc: Zheyu Ma
> Cc: Guenter Roeck
with the build thingy fixed:
Acked-by: Sam Ravnborg
I do wonder if there is a more clean way to trigger a blank
in the main fbdev driver from the olpc driver.
The current hack is not nice and it would be good to see it gone.
Sam
> ---
> drivers/video/fbdev/core/fbmem.c | 8 ++--
> include/linux/fb.h | 7 +++
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 904ef1250677..dad6572942fa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> +EXPORT_SYMBOL(registered_fb);
> EXPORT_SYMBOL(num_registered_fb);
> +#endif
> +#define for_each_registered_fb(i)\
> + for (i = 0; i < FB_MAX; i++)\
> + if (!registered_fb[i]) {} else
>
> bool fb_center_logo __read_mostly;
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a8a00d2ba1f3..e236817502c2 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo
> *var,
> extern int fb_get_options(const char *name, char **option);
> extern int fb_new_modelist(struct fb_info *info);
>
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> extern struct fb_info *registered_fb[FB_MAX];
> +
> extern int num_registered_fb;
> +#endif
> extern bool fb_center_logo;
> extern int fb_logo_count;
> extern struct class *fb_class;
>
> -#define for_each_registered_fb(i)\
> - for (i = 0; i < FB_MAX; i++)\
> - if (!registered_fb[i]) {} else
> -
> static inline void lock_fb_info(struct fb_info *info)
> {
> mutex_lock(&info->lock);
> --
> 2.33.0
Re: [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info
Hi Daniel, On Tue, Feb 08, 2022 at 03:03:28PM +0100, Daniel Vetter wrote: > On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote: > > Hi Daniel, > > > > On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote: > > > Accessing the one in fbmem.c without taking the right locks is a bad > > > idea. Instead maintain our own private copy, which is fully protected > > > by console_lock() (like everything else in fbcon.c). That copy is > > > serialized through fbcon_fb_registered/unregistered() calls. > > > > I fail to see why we can make a private copy of registered_fb > > just like that - are they not somehow shared between fbcon and fbmem. > > So when fbmem updates it, then fbcon will use the entry or such? > > > > I guess I am just ignorant of how registered_fb is used - but please > > explain. > > The private copy is protected under console_lock, and hence safe to access > from fbcon.c code. > > The main registered_fb array is protected by a different mutex, so we > could indeed end up with hilarious corruption because the value is > inconsistent while we try to access it (e.g. we check for !NULL, but later > on gcc decides to reload the value and now it's suddenly become NULL and > we blow up). > > The two are synchronized by fbmem.c calling fbcon_register/unregister, so > aside from the different locks if there's no race going on, they will > always be identical. IT was this part that I missed, and it is already spelled out in the commit message. > > Other option would be to roll out get_fb_info() to fbcon.c, but since > fbcon.c is fully protected by console_lock that would add complexity in > the code flow that we don't really need. And we'd have to wire fb_info > through all call chains, since the right way to use get_fb_info is to look > it up once and then only drop it when your callback has finished. > > Since the current code just assume it's all protected by console_lock and > we never drop that during a callback this would mean major surgery and > essentially refactoring all of fbcon.c to only access the fbcon stuff > through fb_info, i.e. to get rid of _all_ the global arrays we have more > or less. I'm not volunteering for that (despite that really this would be > the right thing to do if we'd have infinite engineering time). > > Ack with that explainer added to the commit message? I consider the current commit message fine - it helps when you actually read it. Acked-by: Sam Ravnborg
Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query to not modify state
On 2/8/2022 01:39, Tvrtko Ursulin wrote:
On 08/02/2022 02:07, 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.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking")
Signed-off-by: John Harrison
---
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));
}
Looks important - what are the consequences?
Supposedly nothing.
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.
Needs Cc: stable for 5.16?
Meaning "Cc: "? Or is there anything required to
specify 5.16?
John.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef
On Tue, 08 Feb 2022, Namhyung Kim wrote: > With upcoming lock tracepoints config, it'd define some of lockdep > functions without enabling CONFIG_LOCKDEP actually. The existing code > assumes those functions will be removed by the preprocessor but it's > not the case anymore. Let's protect the code with #ifdef's explicitly. I don't understand why you can't keep the no-op stubs for CONFIG_LOCKDEP=n. BR, Jani. > > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: Tvrtko Ursulin > Cc: intel-gfx@lists.freedesktop.org > Signed-off-by: Namhyung Kim > --- > drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_wakeref.c > b/drivers/gpu/drm/i915/intel_wakeref.c > index dfd87d082218..6e4b8d036283 100644 > --- a/drivers/gpu/drm/i915/intel_wakeref.c > +++ b/drivers/gpu/drm/i915/intel_wakeref.c > @@ -106,8 +106,11 @@ void __intel_wakeref_init(struct intel_wakeref *wf, > wf->wakeref = 0; > > INIT_DELAYED_WORK(&wf->work, __intel_wakeref_put_work); > + > +#ifdef CONFIG_LOCKDEP > lockdep_init_map(&wf->work.work.lockdep_map, >"wakeref.work", &key->work, 0); > +#endif > } > > int intel_wakeref_wait_for_idle(struct intel_wakeref *wf) -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 05/12] drm/i915: Protect lockdep functions with #ifdef
With upcoming lock tracepoints config, it'd define some of lockdep functions without enabling CONFIG_LOCKDEP actually. The existing code assumes those functions will be removed by the preprocessor but it's not the case anymore. Let's protect the code with #ifdef's explicitly. Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Namhyung Kim --- drivers/gpu/drm/i915/intel_wakeref.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c index dfd87d082218..6e4b8d036283 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.c +++ b/drivers/gpu/drm/i915/intel_wakeref.c @@ -106,8 +106,11 @@ void __intel_wakeref_init(struct intel_wakeref *wf, wf->wakeref = 0; INIT_DELAYED_WORK(&wf->work, __intel_wakeref_put_work); + +#ifdef CONFIG_LOCKDEP lockdep_init_map(&wf->work.work.lockdep_map, "wakeref.work", &key->work, 0); +#endif } int intel_wakeref_wait_for_idle(struct intel_wakeref *wf) -- 2.35.0.263.gb82422642f-goog
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2)
== Series Details == Series: drm/i915: move the DRIVER_* macros to i915_driver.[ch] (rev2) URL : https://patchwork.freedesktop.org/series/99671/ 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] [RFC 00/12] locking: Separate lock tracepoints from lockdep/lock_stat (v1)
Hello,
There have been some requests for low-overhead kernel lock contention
monitoring. The kernel has CONFIG_LOCK_STAT to provide such an infra
either via /proc/lock_stat or tracepoints directly.
However it's not light-weight and hard to be used in production. So
I'm trying to separate out the tracepoints and using them as a base to
build a new monitoring system.
As the lockdep and lock_stat provide good hooks in the lock functions,
it'd be natural to reuse them. Actually I tried to use lockdep as is
but disables the functionality at runtime (initialize debug_locks = 0,
lock_stat = 0). But it still has unacceptable overhead and the
lockdep data structures also increase memory footprint unnecessarily.
So I'm proposing a separate tracepoint-only configuration and keeping
lockdep_map only with minimal information needed for tracepoints (for
now, it's just name). And then the existing lockdep hooks can be used
for the tracepoints.
The patch 01-06 are preparation for the work. In a few places in the
kernel, they calls lockdep annotation explicitly to deal with
limitations in the lockdep implementation. In my understanding, they
are not needed to analyze lock contention.
To make matters worse, they rely on the compiler optimization (or
macro magic) so that it can get rid of the annotations and their
arguments when lockdep is not configured.
But it's not true any more when lock tracepoints are added and it'd
cause build errors. So I added #ifdef guards for LOCKDEP in the code
to prevent such errors.
In the patch 07 I mechanically changed most of code that depend on
CONFIG_LOCKDEP or CONFIG_DEBUG_LOCK_ALLOC to CONFIG_LOCK_INFO. It
paves the way for the codes to be shared for lockdep and tracepoints.
Mostly, it makes sure that locks are initialized with a proper name,
like in the patch 08 and 09.
I didn't change some places intentionally - for example, timer and
workqueue depend on LOCKDEP explicitly since they use some lockdep
annotations to work around the "held lock freed" warnings. The ocfs2
directly accesses lockdep_map.key so I didn't touch the code for now.
And RCU was because it generates too much overhead thanks to the
rcu_read_lock(). Maybe I need to revisit some of them later.
I added CONFIG_LOCK_TRACEPOINTS in the patch 10 to make it optional.
I found that it adds 2~3% of overhead when I ran `perf bench sched
messaging` even when the tracepoints are disabled. The benchmark
creates a lot of processes and make them communicate by socket pairs
(or pipes). I measured that around 15% of lock acquisition creates
contentions and it's mostly for spin locks (alc->lock and u->lock).
I ran perf record + report with the workload and it showed 50% of the
cpu cycles are in the spin lock slow path. So it's highly affected by
the spin lock slow path. Actually LOCK_CONTENDED() macro transforms
the spin lock code (and others) to use trylock first and then fall
back to real lock function if failed. Thus it'd add more (atomic)
operations and cache line bouncing for the contended cases:
#define LOCK_CONTENDED(_lock, try, lock) \
do { \
if (!try(_lock)) {\
lock_contended(&(_lock)->dep_map, _RET_IP_); \
lock(_lock); \
} \
lock_acquired(&(_lock)->dep_map, _RET_IP_); \
} while (0)
If I modify the macro not to use trylock and to call the real lock
function directly (so the lock_contended tracepoint would be called
always, if enabled), the overhead goes down to 0.x% when the
tracepoints are disabled.
I don't have a good solution as long as we use LOCK_CONTENDED() macro
to separate the contended locking path. Maybe we can make it call
some (generic) slow path lock function directly after failing trylock.
Or move the lockdep annotations into the each lock function bodies and
get rid of the LOCK_CONTENDED() macro entirely. Ideas?
Actually the patch 11 handles the same issue on the mutex code. The
fast version of mutex trylock was attempted only if LOCKDEP is not
enabled and it affects the mutex lock performance in the uncontended
cases too. So I partially reverted the change in the patch 07 to use
the fast functions with lock tracepoints too. Maybe we can use it
with LOCKDEP as well?
The last patch 12 might be controversial and I'd like to move the
lock_acquired annotation into the if(!try) block in the LOCK_CONTEDED
macro so that it can only be called when there's a contention.
Eventually I'm mostly interested in the contended locks only and I
want to reduce the overhead in the fast path. By moving that, it'd be
easy to track contended locks with timing by using two tracepoints.
It'd change lock hold time calculation in lock_stat for the fast path,
but I assume time difference between lock_acquire and lock_acquired
would be small when the lock is not contended. So I t
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: split out intel_vtd.[ch] from i915_drv.h
== Series Details ==
Series: drm/i915: split out intel_vtd.[ch] from i915_drv.h
URL : https://patchwork.freedesktop.org/series/99852/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11203 -> Patchwork_22209
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22209 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22209, 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_22209/index.html
Participating hosts (45 -> 43)
--
Missing(2): shard-tglu fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22209:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22209 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271]) +13 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-guc: [DMESG-FAIL][6] ([i915#2291] / [i915#541]) ->
[PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/fi-skl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][8] ([i915#4269]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11203/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/fi-cml-u2/igt@kms_frontbuffer_track...@basic.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541
Build changes
-
* Linux: CI_DRM_11203 -> Patchwork_22209
CI-20190529: 20190529
CI_DRM_11203: e0f14f95759ad65e896868e1f9efd3247d93d28e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22209: f6d09243630e3679c1fb7f6780748517fc0cbb19 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f6d09243630e drm/i915/vtd: rename functions to have the usual prefix
019a148267a5 drm/i915: split out intel_vtd.[ch] from i915_drv.h
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22209/index.html
Re: [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit
On Tue, Feb 08, 2022 at 02:58:21PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > > There's a bunch of confusions going on here:
> > > - The deferred fbcon setup notifier should only be cleaned up from
> > > fb_console_exit(), to be symmetric with fb_console_init()
> > > - We also need to make sure we don't race with the work, which means
> > > temporarily dropping the console lock (or we can deadlock)
> > > - That also means no point in clearing deferred_takeover, we are
> > > unloading everything anyway.
> > > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > > that's what's it doing when being called from consw->con_deinit
> > > through fbcon_deinit.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Daniel Vetter
> > > Cc: Greg Kroah-Hartman
> > > Cc: Claudio Suarez
> > > Cc: Du Cheng
> > > Cc: Tetsuo Handa
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 63
> > > 1 file changed, 32 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c
> > > b/drivers/video/fbdev/core/fbcon.c
> > > index 5c14e24d14a1..22581952b4fd 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info,
> > > struct fb_var_screeninfo *var,
> > > int unit);
> > > static void fbcon_modechanged(struct fb_info *info);
> > > static void fbcon_set_all_vcs(struct fb_info *info);
> > > -static void fbcon_exit(void);
> > >
> > > static struct device *fbcon_device;
> > >
> > > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display
> > > *p, bool freefont)
> > >
> > > static void set_vc_hi_font(struct vc_data *vc, bool set);
> > >
> > > +static void fbcon_release_all(void)
> > > +{
> > > + struct fb_info *info;
> > > + int i, j, mapped;
> > > +
> > > + for_each_registered_fb(i) {
> > > + mapped = 0;
> > > + info = registered_fb[i];
> > > +
> > > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > > + if (con2fb_map[j] == i) {
> > > + mapped = 1;
> > > + con2fb_map[j] = -1;
> > > + }
> > > + }
> > > +
> > > + if (mapped)
> > > + fbcon_release(info);
> > > + }
> > > +}
> > > +
> > > static void fbcon_deinit(struct vc_data *vc)
> > > {
> > > struct fbcon_display *p = &fb_display[vc->vc_num];
> > > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > > set_vc_hi_font(vc, false);
> > >
> > > if (!con_is_bound(&fb_con))
> > > - fbcon_exit();
> > > + fbcon_release_all();
> > >
> > > if (vc->vc_num == logo_shown)
> > > logo_shown = FBCON_LOGO_CANSHOW;
> > > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > > #endif
> > > }
> > >
> > > -static void fbcon_exit(void)
> > > -{
> > > - struct fb_info *info;
> > > - int i, j, mapped;
> > > -
> > > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > > - if (deferred_takeover) {
> > > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > > - deferred_takeover = false;
> > > - }
> > > -#endif
> > > -
> > > - for_each_registered_fb(i) {
> > > - mapped = 0;
> > > - info = registered_fb[i];
> > > -
> > > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > > - if (con2fb_map[j] == i) {
> > > - mapped = 1;
> > > - con2fb_map[j] = -1;
> > > - }
> > > - }
> > > -
> > > - if (mapped)
> > > - fbcon_release(info);
> > > - }
> > > -}
> > > -
> > > void __init fb_console_init(void)
> > > {
> > > int i;
> > > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> > >
> > > void __exit fb_console_exit(void)
> > > {
> > > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > > + console_lock();
> > > + if (deferred_takeover)
> > > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > > + console_unlock();
> > > +
> > > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > > +#endif
> > > +
> > > console_lock();
> > > fbcon_deinit_device();
> > > device_destroy(fb_class, MKDEV(0, 0));
> > > - fbcon_exit();
> > > +
> > We loose the call to fbcon_release_all() here.
> > We have part of the old fbcon_exit() above, but miss the release parts.
> >
> > Maybe I missed something obvious?
>
> Ah yes that's the entire point of this change. The release_all in the
> fbcon exit path was only needed when fbcon was a separate module
> indepedent from core fb.ko. Which means it was possible to unload fbcon
> while having fbdev drivers registered.
>
> But since we've merged them that has become impossible, so by the
Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
On Tue, Feb 08, 2022 at 02:53:59PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > > No idea why con2fb_acquire_newinfo() initializes much less than
> > > fbcon_startup(), but so be it. From a quick look most of the
> > > un-initialized stuff should be fairly harmless, but who knows.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Daniel Vetter
> > > Cc: Greg Kroah-Hartman
> > > Cc: Tetsuo Handa
> > > Cc: Thomas Zimmermann
> > > Cc: Claudio Suarez
> > > Cc: Du Cheng
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 74 +---
> > > 1 file changed, 31 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c
> > > b/drivers/video/fbdev/core/fbcon.c
> > > index b83a5a77d8a8..5a3391ff038d 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info
> > > *info, unsigned charcount)
> > >
> > > #endif /* CONFIG_MISC_TILEBLITTING */
> > >
> > > +static void fbcon_release(struct fb_info *info)
> > > +{
> > > + if (info->fbops->fb_release)
> > > + info->fbops->fb_release(info, 0);
> > > +
> > > + module_put(info->fbops->owner);
> > > +}
> > > +
> > > static int fbcon_open(struct fb_info *info)
> > > {
> > > + struct fbcon_ops *ops;
> > > +
> > > if (!try_module_get(info->fbops->owner))
> > > return -ENODEV;
> > >
> > > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > > return -ENODEV;
> > > }
> > >
> > > - return 0;
> > > -}
> > > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > + if (!ops) {
> > > + fbcon_release(info);
> > > + return -ENOMEM;
> > > + }
> > >
> > > -static void fbcon_release(struct fb_info *info)
> > > -{
> > > - if (info->fbops->fb_release)
> > > - info->fbops->fb_release(info, 0);
> > > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > > + ops->info = info;
> > > + info->fbcon_par = ops;
> > > + ops->cur_blink_jiffies = HZ / 5;
> > >
> > > - module_put(info->fbops->owner);
> > > + return 0;
> > > }
> > >
> > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info
> > > *info,
> > > - int unit, int oldidx)
> > > + int unit)
> > > {
> > > struct fbcon_ops *ops = NULL;
> > > int err;
> > > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data
> > > *vc, struct fb_info *info,
> > > if (err)
> > > return err;
> > >
> > > - if (!err) {
> > > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > - if (!ops)
> > > - err = -ENOMEM;
> > > -
> > > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > > - }
> > > -
> > > - if (!err) {
> > > - ops->cur_blink_jiffies = HZ / 5;
> > > - ops->info = info;
> > > - info->fbcon_par = ops;
> > > -
> > > - if (vc)
> > > - set_blitting_type(vc, info);
> > > - }
> > > + ops = info->fbcon_par;
> > >
> > > - if (err) {
> > > - con2fb_map[unit] = oldidx;
> > > - fbcon_release(info);
> > > - }
> > > + if (vc)
> > > + set_blitting_type(vc, info);
> > >
> > > return err;
> > > }
> > > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int
> > > user)
> > >
> > > found = search_fb_in_map(newidx);
> > >
> > > - con2fb_map[unit] = newidx;
> > > - if (!err && !found)
> > > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > > + if (!err && !found) {
> > > + err = con2fb_acquire_newinfo(vc, info, unit);
> > > + if (!err)
> > > + con2fb_map[unit] = newidx;
> > > + }
> > This looks like an unintentional change of functionality as
> > con2fb_map[unit] is
> > only assigned when we do a con2fb_acquire_newinfo().
> >
> > Staring at the code I could not say it is wrong, but not nice to hide
> > the change in this patch.
>
> Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
> reset con2fb_map to oldidx upon failure, which I've found to be a most
> bizarre calling convention. So this sorts this out.
>
> The reason I smashed this into the same patch is that I had to remove the
> fbcon_release call, and so the error handling in there looked even more
> funny. But I indeed failed to explain this all in the commit message.
>
> Ack with that explainer, or do you want me to split this out properly?
Please update the commit message, then this patch has my:
Acked-by: Sam Ravnborg
Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
Hi Daniel,
On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > There's two minor behaviour changes in here:
> > > - in error paths we now consistently call fb_ops->fb_release
> > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > reasonable cleanup we can do anyway.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Daniel Vetter
> > > Cc: Claudio Suarez
> > > Cc: Greg Kroah-Hartman
> > > Cc: Tetsuo Handa
> > > Cc: Du Cheng
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 107 +++
> > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c
> > > b/drivers/video/fbdev/core/fbcon.c
> > > index fa30e1909164..eea2ee14b64c 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info
> > > *info, unsigned charcount)
> > >
> > > #endif /* CONFIG_MISC_TILEBLITTING */
> > >
> > > +static int fbcon_open(struct fb_info *info)
> > > +{
> > > + if (!try_module_get(info->fbops->owner))
> > > + return -ENODEV;
> > > +
> > > + if (info->fbops->fb_open &&
> > > + info->fbops->fb_open(info, 0)) {
> > > + module_put(info->fbops->owner);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void fbcon_release(struct fb_info *info)
> > > +{
> > > + if (info->fbops->fb_release)
> > > + info->fbops->fb_release(info, 0);
> > > +
> > > + module_put(info->fbops->owner);
> > > +}
> > >
> > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info
> > > *info,
> > > int unit, int oldidx)
> > > {
> > > struct fbcon_ops *ops = NULL;
> > > - int err = 0;
> > > -
> > > - if (!try_module_get(info->fbops->owner))
> > > - err = -ENODEV;
> > > + int err;
> > >
> > > - if (!err && info->fbops->fb_open &&
> > > - info->fbops->fb_open(info, 0))
> > > - err = -ENODEV;
> > > + err = fbcon_open(info);
> > > + if (err)
> > > + return err;
> > >
> > > if (!err) {
> > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> > > struct fb_info *info,
> > >
> > > if (err) {
> > > con2fb_map[unit] = oldidx;
> > > - module_put(info->fbops->owner);
> > > + fbcon_release(info);
> > > }
> > >
> > > return err;
> > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data
> > > *vc, struct fb_info *oldinfo,
> > > int oldidx, int found)
> > > {
> > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > - int err = 0, ret;
> > > + int ret;
> > >
> > > - if (oldinfo->fbops->fb_release &&
> > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > - con2fb_map[unit] = oldidx;
> > The old code assigns con2fb_map[unit] before is calls
> > newinfo->fbops->fb_release).
> > I wonder if there can be any callback to fbcon where the value
> > of con2fb_map[unit] matters?
>
> It's all protected by console_lock, so other threads cannot see the
> inconsistent state.
>
> Essentially everything in fbcon.c is protected by console_lock().
>
> Do you want me to hammer this in somewhere (maybe in the commit message),
> or good enough for your ack?
No need to spell it out more.
Add my a-b and apply it.
Sam
Re: [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
Hi Daniel, On Tue, Feb 08, 2022 at 02:46:33PM +0100, Daniel Vetter wrote: > On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote: > > On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote: > > > It was only used by fbcon, and that now switched to its own, > > > private work. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Helge Deller > > > Cc: linux-fb...@vger.kernel.org > > I would merge this with the patch that drops the usage > > Yeah, but I like to split these out so that if this does break something, > it's much easier to revert. In case I overlooked something somewhere. > > It's imo different if the cleanup is directly related to the preceeding > prep work, but this is a generic workqueue, and the cursor logic is rather > unrelated. And if I remember my history digging right, there were actually > other uses of this. So you basically say that because in the past there may have been other users, this deserves a dedicated removal commit. That works for me too. Acked-by: Sam Ravnborg Sam
Re: [Intel-gfx] [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps
On Tue, 2022-02-08 at 13:06 +, Souza, Jose wrote:
> On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> > As we've unfortunately started to come to expect from PSR on Intel
> > platforms, PSR2 selective fetch is not at all ready to be enabled on
> > Tigerlake as it results in severe flickering issues - at least on this
> > ThinkPad X1 Carbon 9th generation. The easiest way I've found of
> > reproducing these issues is to just move the cursor around the left border
> > of the screen (suspicious…).
>
> Where is the bug for that? Where is the logs?
I'm happy to open up a bug and include some logs, will do it in just a moment
> We can't go from enabled to disabled without any debug and because of a
> single device.
> In the mean time you have the option to set the i915 parameter to disable
> it.
I mean - I totally understand the hesistance with the lack of debug info, I'll
go open up an issue with said info in a bit. FWIW is a machine currently being
sold with Linux pre-installs which is expected to work out of the box, so it's
not exactly an uncommon laptop to be running Linux. Also I don't have any
problem with us trying to fix the issue before flat out disabling things - I
sent the revert hoping that would happen, and also because I needed to write
the revert anyway since I had to disable this in Fedora's kernel.
>
> >
> > So, fix people's displays again and turn PSR2 selective fetch off for all
> > steppings of Tigerlake. This can be re-enabled again if someone from Intel
> > finds the time to fix this functionality on OEM machines.
> >
> > Signed-off-by: Lyude Paul
> > Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> > default")
> > Cc: Gwan-gyeong Mun
> > Cc: Ville Syrjälä
> > Cc: José Roberto de Souza
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: # v5.16+
> > ---
> > drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > b/drivers/gpu/drm/i915/display/intel_psr.c
> > index a1a663f362e7..25c16abcd9cd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > @@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> > intel_dp *intel_dp,
> > return false;
> > }
> >
> > - /* Wa_14010254185 Wa_14010103792 */
> > - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> > + /*
> > + * There's two things stopping this from being enabled on TGL:
> > + * For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are
> > missing
> > + * For all steps: PSR2 selective fetch causes screen flickering
> > + */
> > + if (IS_TIGERLAKE(dev_priv)) {
> > drm_dbg_kms(&dev_priv->drm,
> > - "PSR2 sel fetch not enabled, missing the
> > implementation of WAs\n");
> > + "PSR2 sel fetch not enabled, currently broken
> > on TGL\n");
> > return false;
> > }
> >
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
Hi Daniel, On Tue, Feb 08, 2022 at 02:42:25PM +0100, Daniel Vetter wrote: > On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote: > > Hi Daniel, > > > > On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote: > > > Before > > > > > > commit 6104c37094e729f3d4ce65797002112735d49cd1 > > > Author: Daniel Vetter > > > Date: Tue Aug 1 17:32:07 2017 +0200 > > > > > > fbcon: Make fbcon a built-time depency for fbdev > > > > > > it was possible to load fbcon and fbdev drivers in any order, which > > > means that fbcon init had to handle the case where fbdev drivers where > > > already registered. > > > > > > This is no longer possible, hence delete that code. > > > > > > Note that the exit case is a bit more complex and will be done in a > > > separate patch. > > > > > > Signed-off-by: Daniel Vetter > > > Cc: Helge Deller > > > Cc: Daniel Vetter > > > Cc: Claudio Suarez > > > Cc: Greg Kroah-Hartman > > > Cc: Tetsuo Handa > > > Cc: Du Cheng > > > --- > > > drivers/video/fbdev/core/fbcon.c | 13 + > > > 1 file changed, 1 insertion(+), 12 deletions(-) > > > > > > diff --git a/drivers/video/fbdev/core/fbcon.c > > > b/drivers/video/fbdev/core/fbcon.c > > > index 8f971de35885..814b648e8f09 100644 > > > --- a/drivers/video/fbdev/core/fbcon.c > > > +++ b/drivers/video/fbdev/core/fbcon.c > > > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void) > > > return display_desc; > > > /* > > >* Instead of blindly using registered_fb[0], we use info_idx, set by > > > - * fb_console_init(); > > > + * fbcon_fb_registered(); > > >*/ > > This comment change looks like it does not belong in this patch. > > Also, the comment is wrong as info_idx is set in several places. > > Like set_con2fb_map(), fbcon_remap_all(), and more. > > Yeah I can split this out into a separate patch, but I spotted this wrong > comment as part of reviewing this code change here - essentially you have > to check how fb_info for fbcon are registered and fbcon init happens to > validate that deleting the below code is correct. > > Ok if I put this explainer into the commit message, or do you want me to > split this out fully? Keep it and add my a-b Sam
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: split out intel_vtd.[ch] from i915_drv.h
== Series Details == Series: drm/i915: split out intel_vtd.[ch] from i915_drv.h URL : https://patchwork.freedesktop.org/series/99852/ 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/i915: split out intel_vtd.[ch] from i915_drv.h
== Series Details == Series: drm/i915: split out intel_vtd.[ch] from i915_drv.h URL : https://patchwork.freedesktop.org/series/99852/ State : warning == Summary == $ dim checkpatch origin/drm-tip 019a148267a5 drm/i915: split out intel_vtd.[ch] from i915_drv.h -:321: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #321: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 274 lines checked f6d09243630e drm/i915/vtd: rename functions to have the usual prefix
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Disable tracing points on PREEMPT_RT
On 2021-12-14 11:58:37 [-0500], Steven Rostedt wrote: > On Tue, 14 Dec 2021 18:34:50 +0200 > Ville Syrjälä wrote: > > > Looks lightly tedious. Can't we have "slow" (or whatever) versions of > > the trace macros so we could just declare these the same was as before > > without having to manually write that wrapper for every event? > > That would be quite tedious as well ;-) … > It may be possible to do, but it will be far from trivial, and I'm not sure > I want this to be an easy option. Locks should not be taken from trace > events in general, as they are not tested with lockdep when the trace > points are not enabled, and could hide deadlocks that may not appear until > running on production. So we disable the tracing points or try what Steven suggested? > -- Steve Sebastian
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp, drm/i915: 128b/132b updates (rev5)
== Series Details ==
Series: drm/dp, drm/i915: 128b/132b updates (rev5)
URL : https://patchwork.freedesktop.org/series/99324/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11202 -> Patchwork_22208
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_22208 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22208, 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_22208/index.html
Participating hosts (46 -> 42)
--
Missing(4): fi-bsw-cyan fi-icl-u2 shard-tglu fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22208:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11202/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_22208 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [PASS][4] -> [INCOMPLETE][5] ([i915#4547])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11202/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-skl-6600u/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_chamelium@vga-edid-read:
- fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][7] ([fdo#109271]) +13 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][8] ([i915#1436] / [i915#2426] /
[i915#4312])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-kbl-soraka/igt@run...@aborted.html
- fi-skl-6600u: NOTRUN -> [FAIL][9] ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/fi-skl-6600u/igt@run...@aborted.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][10] ([i915#4494] / [i915#4957]) ->
[DMESG-FAIL][11] ([i915#4957])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11202/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-5: [DMESG-FAIL][12] ([i915#4957]) -> [DMESG-FAIL][13]
([i915#4494] / [i915#4957])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11202/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22208/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4898]: https://gitlab.freedesktop.org/drm/intel/issues/4898
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
Build changes
-
* Linux: CI_DRM_11202 -> Patchwork_22208
CI-20190529: 20190529
CI_DRM_11202: 1a579dc97fd43456576efb2c3c1ba20bc6822f6e @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6341: a96674e747ea2f2431bbf8813156adc44ec3162a @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22208: 18f489ee5d200a6404118f4d6732e02575494daa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
18f489ee5
[Intel-gfx] [PATCH] drm/i915: move intel_hws_csb_write_index() out of i915_drv.h
Underscore prefix the index macros, and place
INTEL_HWS_CSB_WRITE_INDEX() as a macro next to them, to declutter
i915_drv.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_engine.h | 6 --
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
drivers/gpu/drm/i915/gvt/execlist.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 8
4 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 0e353d8c2bc8..faf26ed37d01 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -180,8 +180,10 @@ intel_write_status_page(struct intel_engine_cs *engine,
int reg, u32 value)
#define I915_GEM_HWS_SCRATCH 0x80
#define I915_HWS_CSB_BUF0_INDEX0x10
-#define I915_HWS_CSB_WRITE_INDEX 0x1f
-#define ICL_HWS_CSB_WRITE_INDEX0x2f
+#define _I915_HWS_CSB_WRITE_INDEX 0x1f
+#define _ICL_HWS_CSB_WRITE_INDEX 0x2f
+#define INTEL_HWS_CSB_WRITE_INDEX(__i915) \
+ (GRAPHICS_VER(__i915) >= 11 ? _ICL_HWS_CSB_WRITE_INDEX :
_I915_HWS_CSB_WRITE_INDEX)
void intel_engine_stop(struct intel_engine_cs *engine);
void intel_engine_cleanup(struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 9bb7c863172f..961d795220a3 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3503,7 +3503,7 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
(u64 *)&engine->status_page.addr[I915_HWS_CSB_BUF0_INDEX];
execlists->csb_write =
- &engine->status_page.addr[intel_hws_csb_write_index(i915)];
+ &engine->status_page.addr[INTEL_HWS_CSB_WRITE_INDEX(i915)];
if (GRAPHICS_VER(i915) < 11)
execlists->csb_size = GEN8_CSB_ENTRIES;
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
b/drivers/gpu/drm/i915/gvt/execlist.c
index c8dcda6d4f0d..66d354c4195b 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -163,7 +163,7 @@ static void emulate_csb_update(struct intel_vgpu_execlist
*execlist,
hwsp_gpa +
I915_HWS_CSB_BUF0_INDEX * 4 + write_pointer * 8,
status, 8);
intel_gvt_hypervisor_write_gpa(vgpu,
- hwsp_gpa +
intel_hws_csb_write_index(execlist->engine->i915) * 4,
+ hwsp_gpa +
INTEL_HWS_CSB_WRITE_INDEX(execlist->engine->i915) * 4,
&write_pointer, 4);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c1706fd81f9..05656cc738d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1739,14 +1739,6 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)INTEL_INFO(dev_priv);
}
-static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
-{
- if (GRAPHICS_VER(i915) >= 11)
- return ICL_HWS_CSB_WRITE_INDEX;
- else
- return I915_HWS_CSB_WRITE_INDEX;
-}
-
static inline enum i915_map_type
i915_coherent_map_type(struct drm_i915_private *i915,
struct drm_i915_gem_object *obj, bool always_coherent)
--
2.30.2
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: 128b/132b updates (rev5)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev5) URL : https://patchwork.freedesktop.org/series/99324/ 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/dp, drm/i915: 128b/132b updates (rev5)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev5) URL : https://patchwork.freedesktop.org/series/99324/ State : warning == Summary == $ dim checkpatch origin/drm-tip 20e6f540b666 drm/dp: add drm_dp_128b132b_read_aux_rd_interval() 33af01e431af drm/dp: add 128b/132b link status helpers from DP 2.0 E11 9362394c0701 drm/dp: add some new DPCD macros from DP 2.0 E11 965064d5f41d drm/i915/dp: move intel_dp_prepare_link_train() call 530327803cfd drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata -:108: CHECK:LINE_SPACING: Please don't use multiple blank lines #108: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1132: + -:333: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #333: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1357: + + } total: 0 errors, 0 warnings, 2 checks, 337 lines checked ce2c19e796be drm/i915/dp: add 128b/132b support to link status checks f5777bc7387e drm/i915/mst: update slot information for 128b/132b 18f489ee5d20 HACK: drm/i915/dp: give more time for CDS
[Intel-gfx] [PATCH v4 2/2] drm/i915/vtd: rename functions to have the usual prefix
The prefix should tell where the function is to be found and where it
belongs.
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_driver.c | 2 +-
drivers/gpu/drm/i915/intel_pch.c | 2 +-
drivers/gpu/drm/i915/intel_vtd.c | 2 +-
drivers/gpu/drm/i915/intel_vtd.h | 14 +++---
9 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index 05339b3bc39b..39cff135c2ae 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -108,7 +108,7 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
* we should always have valid PTE following the scanout preventing
* the VT-d warning.
*/
- if (intel_scanout_needs_vtd_wa(dev_priv) && alignment < 256 * 1024)
+ if (intel_vtd_scanout_needs_wa(dev_priv) && alignment < 256 * 1024)
alignment = 256 * 1024;
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 0fb0921c81ab..3ae9d1ae7ba6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -123,7 +123,7 @@ i915_gem_shrink(struct i915_gem_ww_ctx *ww,
int err = 0;
/* CHV + VTD workaround use stop_machine(); need to trylock vm->mutex */
- bool trylock_vm = !ww && intel_vm_no_concurrent_access_wa(i915);
+ bool trylock_vm = !ww && intel_vtd_vm_no_concurrent_access_wa(i915);
trace_i915_gem_shrink(i915, target, shrink);
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index e49d8d17095a..f3ca1f93192a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -974,7 +974,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.cleanup = gen6_gmch_remove;
ggtt->vm.insert_page = gen8_ggtt_insert_page;
ggtt->vm.clear_range = nop_clear_range;
- if (intel_scanout_needs_vtd_wa(i915))
+ if (intel_vtd_scanout_needs_wa(i915))
ggtt->vm.clear_range = gen8_ggtt_clear_range;
ggtt->vm.insert_entries = gen8_ggtt_insert_entries;
@@ -983,7 +983,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
* Serialize GTT updates with aperture access on BXT if VT-d is on,
* and always on CHV.
*/
- if (intel_vm_no_concurrent_access_wa(i915)) {
+ if (intel_vtd_vm_no_concurrent_access_wa(i915)) {
ggtt->vm.insert_entries = bxt_vtd_ggtt_insert_entries__BKL;
ggtt->vm.insert_page= bxt_vtd_ggtt_insert_page__BKL;
ggtt->vm.bind_async_flags =
@@ -1122,7 +1122,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
ggtt->vm.alloc_scratch_dma = alloc_pt_dma;
ggtt->vm.clear_range = nop_clear_range;
- if (!HAS_FULL_PPGTT(i915) || intel_scanout_needs_vtd_wa(i915))
+ if (!HAS_FULL_PPGTT(i915) || intel_vtd_scanout_needs_wa(i915))
ggtt->vm.clear_range = gen6_ggtt_clear_range;
ggtt->vm.insert_page = gen6_ggtt_insert_page;
ggtt->vm.insert_entries = gen6_ggtt_insert_entries;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 524f3c3eb027..5331ad7decfe 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -206,7 +206,7 @@ void i915_address_space_init(struct i915_address_space *vm,
int subclass)
mutex_init(&vm->mutex);
lockdep_set_subclass(&vm->mutex, subclass);
- if (!intel_vm_no_concurrent_access_wa(vm->i915)) {
+ if (!intel_vtd_vm_no_concurrent_access_wa(vm->i915)) {
i915_gem_shrinker_taints_mutex(vm->i915, &vm->mutex);
} else {
/*
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 001958238cfe..2aeee6130fe1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -66,7 +66,7 @@ static int i915_capabilities(struct seq_file *m, void *data)
intel_device_info_print_static(INTEL_INFO(i915), &p);
intel_device_info_print_runtime(RUNTIME_INFO(i915), &p);
- i915_print_iommu_status(i915, &p);
+ intel_vtd_print_iommu_status(i915, &p);
intel_gt_info_print(&to_gt(i915)->info, &p);
intel_driver_caps_print(&i915->caps, &p);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 32a3265a177a..ff1f74891b8c 100644
--- a/drive
[Intel-gfx] [PATCH v4 1/2] drm/i915: split out intel_vtd.[ch] from i915_drv.h
Perhaps a bit contrived, but we need to reduce the size of i915_drv.h
from all the accumulated cruft.
v4: Rebase
v3: Rebase
v2: Turns out asm/hypervisor.h is not self-contained
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/display/intel_bw.c | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 5 +-
drivers/gpu/drm/i915/display/intel_fb_pin.c | 1 +
drivers/gpu/drm/i915/display/intel_fbc.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 1 +
drivers/gpu/drm/i915/gem/i915_gemfs.c| 1 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 8 +--
drivers/gpu/drm/i915/gt/intel_gtt.c | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_driver.c | 7 +--
drivers/gpu/drm/i915/i915_drv.h | 37 --
drivers/gpu/drm/i915/i915_gpu_error.c| 1 +
drivers/gpu/drm/i915/intel_device_info.c | 3 +-
drivers/gpu/drm/i915/intel_pch.c | 1 +
drivers/gpu/drm/i915/intel_pm.c | 1 +
drivers/gpu/drm/i915/intel_vtd.c | 14 ++
drivers/gpu/drm/i915/intel_vtd.h | 51
19 files changed, 87 insertions(+), 50 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_vtd.c
create mode 100644 drivers/gpu/drm/i915/intel_vtd.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26e6736bebb..d79c06b362f1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += i915_driver.o \
intel_sbi.o \
intel_step.o \
intel_uncore.o \
+ intel_vtd.o \
intel_wakeref.o \
vlv_sideband.o \
vlv_suspend.o
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index 5dce3cf0ed12..edcf77d3694d 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -12,6 +12,7 @@
#include "intel_display_types.h"
#include "intel_pcode.h"
#include "intel_pm.h"
+#include "intel_vtd.h"
/* Parameters for Qclk Geyserville (QGV) */
struct intel_qgv_point {
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7f512f9e9e5c..2af5eca2fe12 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -75,6 +75,7 @@
#include "g4x_dp.h"
#include "g4x_hdmi.h"
#include "i915_drv.h"
+#include "i9xx_plane.h"
#include "icl_dsi.h"
#include "intel_acpi.h"
#include "intel_atomic.h"
@@ -109,12 +110,12 @@
#include "intel_sprite.h"
#include "intel_tc.h"
#include "intel_vga.h"
-#include "i9xx_plane.h"
+#include "intel_vtd.h"
#include "skl_scaler.h"
#include "skl_universal_plane.h"
+#include "vlv_dsi.h"
#include "vlv_dsi_pll.h"
#include "vlv_sideband.h"
-#include "vlv_dsi.h"
static void intel_set_transcoder_timings(const struct intel_crtc_state
*crtc_state);
static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index c4b3d76341f3..05339b3bc39b 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -14,6 +14,7 @@
#include "intel_dpt.h"
#include "intel_fb.h"
#include "intel_fb_pin.h"
+#include "intel_vtd.h"
static struct i915_vma *
intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index bcdffe62f3cb..4c5a5aed7ca7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -48,6 +48,7 @@
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
+#include "intel_vtd.h"
#define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS;
(__fbc_id)++) \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
index 6a6ff98a8746..0fb0921c81ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
@@ -16,6 +16,7 @@
#include "gt/intel_gt_requests.h"
#include "i915_trace.h"
+#include "intel_vtd.h"
static bool swap_available(void)
{
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 1de73a644965..361378846127 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -16,6 +16,7 @@
#include "i915_gem_stolen.h"
#include "i915_reg.h"
#include "i915_vgpu.h"
+#include "intel_vtd.h"
/*
* The BIOS typically reserves some of the system's memory for the exclusive
diff --g
[Intel-gfx] [PATCH v4 0/2] drm/i915: split out intel_vtd.[ch] from i915_drv.h
Another rebase & resend of [1]. [1] https://patchwork.freedesktop.org/series/98789/ Jani Nikula (2): drm/i915: split out intel_vtd.[ch] from i915_drv.h drm/i915/vtd: rename functions to have the usual prefix drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/display/intel_bw.c | 1 + drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/display/intel_fb_pin.c | 3 +- drivers/gpu/drm/i915/display/intel_fbc.c | 1 + drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 3 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 1 + drivers/gpu/drm/i915/gem/i915_gemfs.c| 1 + drivers/gpu/drm/i915/gt/intel_ggtt.c | 14 +++--- drivers/gpu/drm/i915/gt/intel_gtt.c | 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/i915/i915_driver.c | 9 +--- drivers/gpu/drm/i915/i915_drv.h | 37 -- drivers/gpu/drm/i915/i915_gpu_error.c| 1 + drivers/gpu/drm/i915/intel_device_info.c | 3 +- drivers/gpu/drm/i915/intel_pch.c | 3 +- drivers/gpu/drm/i915/intel_pm.c | 1 + drivers/gpu/drm/i915/intel_vtd.c | 14 ++ drivers/gpu/drm/i915/intel_vtd.h | 51 19 files changed, 96 insertions(+), 59 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_vtd.c create mode 100644 drivers/gpu/drm/i915/intel_vtd.h -- 2.30.2
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/doc: pull in drm_buddy.c
== Series Details == Series: drm/doc: pull in drm_buddy.c URL : https://patchwork.freedesktop.org/series/99849/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11201 -> Patchwork_22207 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22207 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22207, 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_22207/index.html Participating hosts (45 -> 43) -- Missing(2): fi-bsw-cyan shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22207: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22207 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#4785]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - fi-blb-e6850: [PASS][6] -> [DMESG-FAIL][7] ([i915#4528]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/fi-blb-e6850/igt@i915_selftest@l...@requests.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-blb-e6850/igt@i915_selftest@l...@requests.html * igt@kms_chamelium@vga-edid-read: - fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html - fi-bdw-5557u: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-bdw-5557u/igt@kms_chamel...@vga-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-skl-6600u: NOTRUN -> [SKIP][10] ([fdo#109271]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-skl-6600u/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-a: - bat-dg1-5: [PASS][11] -> [SKIP][12] ([i915#4078]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/bat-dg1-5/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/bat-dg1-5/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-a.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-skl-6600u: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@cursor_plane_move: - fi-bdw-5557u: NOTRUN -> [SKIP][14] ([fdo#109271]) +13 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][15] ([i915#4838]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#1436] / [i915#4312]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-hsw-4770/igt@run...@aborted.html - fi-blb-e6850: NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#2403] / [i915#2426] / [i915#4312]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22207/fi-blb-e6850/igt@run...@aborted.html Warnings * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [DMESG-FAIL][18] ([i915#4957]) -> [DMESG-FAIL][19] ([i915#4494] / [i915#4957]) [18]: https://intel-gfx-ci.01.org/tree/drm-
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/buddy: fixup potential uaf
== Series Details == Series: drm/buddy: fixup potential uaf URL : https://patchwork.freedesktop.org/series/99842/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11201_full -> Patchwork_22205_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22205_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22205_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22205_full: ### IGT changes ### Possible regressions * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-iclb: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-iclb3/igt@syncobj_timel...@invalid-transfer-non-existent-point.html Known issues Here are the changes found in Patchwork_22205_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][2] ([fdo#109314]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-iclb3/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_eio@kms: - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#232]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/shard-tglb6/igt@gem_...@kms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-tglb3/igt@gem_...@kms.html * igt@gem_exec_capture@pi@vcs0: - shard-skl: NOTRUN -> [INCOMPLETE][5] ([i915#4547]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-skl4/igt@gem_exec_capture@p...@vcs0.html * igt@gem_exec_fair@basic-deadline: - shard-kbl: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-kbl6/igt@gem_exec_f...@basic-deadline.html - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/shard-glk3/igt@gem_exec_f...@basic-deadline.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-glk3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-skl: NOTRUN -> [SKIP][9] ([fdo#109271]) +376 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-skl9/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-kbl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_lmem_swapping@heavy-multi: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#4613]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-iclb3/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@heavy-random: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-skl7/igt@gem_lmem_swapp...@heavy-random.html * igt@gem_pwrite@basic-exhaustion: - shard-skl: NOTRUN -> [WARN][15] ([i915#2658]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-skl8/igt@gem_pwr...@basic-exhaustion.html - shard-kbl: NOTRUN -> [WARN][16] ([i915#2658]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-kbl7/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@unsync-unmap-after-close: - shard-iclb: NOTRUN -> [SKIP][17] ([i915#3297]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-iclb3/igt@gem_userptr_bl...@unsync-unmap-after-close.html * igt@gen7_exec_parse@batch-without-end: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#109289]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/shard-iclb3/igt@gen7_exec_pa...@batch-without-end.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1436] / [i915#716]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/shard-skl9/igt@gen9_exec_pa...@allowed-single.html [20]: https://intel-gfx-ci.
Re: [Intel-gfx] [PATCH v6 6/6] drm: Add arch arm64 for drm_clflush_virt_range
Ah, thanks for asking this question. It seems like I was not thinking
correctly. We are trying to flush dcache lines within this function and
not the tlb.
On 2022-02-08 2:20 a.m., Tvrtko Ursulin wrote:
On 07/02/2022 20:11, Michael Cheng wrote:
Use flush_tlb_kernel_range when invoking drm_clflush_virt_range on
arm64 platforms. Using flush_tlb_kernel_range will:
1. Make sure prior page-table updates have been completed
2. Invalidate the TLB
3. Check if the TLB invalidation has been completed
Arm does not have a clflush equivalent but invalidating TLBs there
includes flushing caches?
Regards,
Tvrtko
Signed-off-by: Michael Cheng
---
drivers/gpu/drm/drm_cache.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index f19d9acbe959..d2506060a7c8 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -176,6 +176,10 @@ drm_clflush_virt_range(void *addr, unsigned long
length)
if (wbinvd_on_all_cpus())
pr_err("Timed out waiting for cache flush\n");
+
+#elif defined(CONFIG_ARM64)
+ void *end = addr + length;
+ flush_tlb_kernel_range(*addr, *end);
#else
pr_err("Architecture has no drm_cache.c support\n");
WARN_ON_ONCE(1);
[Intel-gfx] [PATCH v3] drm/i915/mst: update slot information for 128b/132b
128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
slot 0 for metadata.
Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
on Encoding Format") added support for updating the topology state
accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP 2.0 MST
DM Support") started using it in the amd driver.
This feels more than a little cumbersome, especially updating the
information in atomic check. For i915, add the update to MST connector
.compute_config hook rather than iterating over all MST managers and
connectors in global mode config .atomic_check. Fingers crossed.
v3:
- Propagate errors from intel_dp_mst_update_slots() (Ville)
v2:
- Update in .compute_config() not .atomic_check (Ville)
Cc: Bhawanpreet Lakha
Cc: Lyude Paul
Cc: Uma Shankar
Cc: Ville Syrjälä
Acked-by: Lyude Paul
Reviewed-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 6b6eab507d30..e30e698aa684 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -99,6 +99,29 @@ static int intel_dp_mst_compute_link_config(struct
intel_encoder *encoder,
return 0;
}
+static int intel_dp_mst_update_slots(struct intel_encoder *encoder,
+struct intel_crtc_state *crtc_state,
+struct drm_connector_state *conn_state)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
+ struct intel_dp *intel_dp = &intel_mst->primary->dp;
+ struct drm_dp_mst_topology_mgr *mgr = &intel_dp->mst_mgr;
+ struct drm_dp_mst_topology_state *topology_state;
+ u8 link_coding_cap = intel_dp_is_uhbr(crtc_state) ?
+ DP_CAP_ANSI_128B132B : DP_CAP_ANSI_8B10B;
+
+ topology_state = drm_atomic_get_mst_topology_state(conn_state->state,
mgr);
+ if (IS_ERR(topology_state)) {
+ drm_dbg_kms(&i915->drm, "slot update failed\n");
+ return PTR_ERR(topology_state);
+ }
+
+ drm_dp_mst_update_slots(topology_state, link_coding_cap);
+
+ return 0;
+}
+
static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
@@ -155,6 +178,10 @@ static int intel_dp_mst_compute_config(struct
intel_encoder *encoder,
if (ret)
return ret;
+ ret = intel_dp_mst_update_slots(encoder, pipe_config, conn_state);
+ if (ret)
+ return ret;
+
pipe_config->limited_color_range =
intel_dp_limited_color_range(pipe_config, conn_state);
@@ -357,6 +384,7 @@ static void intel_mst_disable_dp(struct intel_atomic_state
*state,
struct intel_connector *connector =
to_intel_connector(old_conn_state->connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ int start_slot = intel_dp_is_uhbr(old_crtc_state) ? 0 : 1;
int ret;
drm_dbg_kms(&i915->drm, "active links %d\n",
@@ -366,7 +394,7 @@ static void intel_mst_disable_dp(struct intel_atomic_state
*state,
drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, connector->port);
- ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, 1);
+ ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, start_slot);
if (ret) {
drm_dbg_kms(&i915->drm, "failed to update payload %d\n", ret);
}
@@ -475,6 +503,7 @@ static void intel_mst_pre_enable_dp(struct
intel_atomic_state *state,
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
+ int start_slot = intel_dp_is_uhbr(pipe_config) ? 0 : 1;
int ret;
bool first_mst_stream;
@@ -509,7 +538,7 @@ static void intel_mst_pre_enable_dp(struct
intel_atomic_state *state,
intel_dp->active_mst_links++;
- ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, 1);
+ ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, start_slot);
/*
* Before Gen 12 this is not done as part of
--
2.30.2
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp, drm/i915: 128b/132b updates (rev4)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev4) URL : https://patchwork.freedesktop.org/series/99324/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11201 -> Patchwork_22206 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22206 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22206, 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_22206/index.html Participating hosts (45 -> 40) -- Missing(5): shard-tglu fi-bsw-cyan fi-icl-u2 fi-kbl-8809g bat-rpls-2 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22206: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22206 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@i915_selftest@live@hangcheck: - fi-hsw-4770:[PASS][4] -> [INCOMPLETE][5] ([i915#3303]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.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_22206/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_22206/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_22206/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@cursor_plane_move: - fi-bdw-5557u: NOTRUN -> [SKIP][10] ([fdo#109271]) +13 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html * igt@kms_psr@primary_page_flip: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][11] ([i915#4838]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-skl-6600u/igt@kms_psr@primary_page_flip.html * igt@runner@aborted: - fi-hsw-4770:NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#1436] / [i915#4312]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-hsw-4770/igt@run...@aborted.html Possible fixes * igt@kms_frontbuffer_tracking@basic: - fi-cml-u2: [DMESG-WARN][13] ([i915#4269]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html Warnings * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [DMESG-FAIL][15] ([i915#4957]) -> [DMESG-FAIL][16] ([i915#4494] / [i915#4957]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22206/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3303]: https://gitlab.fre
Re: [Intel-gfx] [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
On Tue, 08 Feb 2022, Zhi Wang wrote:
> From: Zhi Wang
>
> To support the new mdev interfaces and the re-factor patches from
> Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
> initialization path has to be separated into two phases:
>
> a) Early initialization.
>
> The early initialization of GVT requires to be done when loading i915.
> Mostly it's because the initial clean HW state needs to be saved before
> i915 touches the HW.
>
> b) Late initalization.
>
> This phases of initalization will setup the rest components of GVT-g,
> which can be done later when the dedicated module is being loaded.
What's the baseline for this series?
>
> v6:
>
> - Move the mmio_table.c into i915. (Christoph)
> - Keep init_device_info and related structures in GVT-g. (Christoph)
> - Refine the callbacks of the iterator. (Christoph)
> - Move the flags of MMIO register defination to GVT-g. (Chrsitoph)
> - Move the mmio block handling to GVT-g.
>
> v5:
>
> - Re-design the mmio table framework. (Christoph)
>
> v4:
>
> - Fix the errors of patch checking scripts.
>
> v3:
>
> - Fix the errors when CONFIG_DRM_I915_WERROR is turned on. (Jani)
>
> v2:
>
> - Implement a mmio table instead of generating it by marco in i915. (Jani)
>
> Cc: Christoph Hellwig
> Cc: Jason Gunthorpe
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Vivi Rodrigo
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> Tested-by: Terrence Xu
> Signed-off-by: Zhi Wang
> ---
> drivers/gpu/drm/i915/Makefile |2 +-
> drivers/gpu/drm/i915/gvt/cmd_parser.c |2 +-
> drivers/gpu/drm/i915/gvt/gvt.h |3 +-
> drivers/gpu/drm/i915/gvt/handlers.c | 1062 ++-
> drivers/gpu/drm/i915/gvt/mmio.h | 17 -
> drivers/gpu/drm/i915/gvt/reg.h |9 +-
> drivers/gpu/drm/i915/intel_gvt.c| 20 +-
> drivers/gpu/drm/i915/intel_gvt.h| 37 +
> drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 1308 +++
> 9 files changed, 1501 insertions(+), 959 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_gvt_mmio_table.c
>
> diff --git a/drivers/gpu/drm/i915/intel_gvt.h
> b/drivers/gpu/drm/i915/intel_gvt.h
> index d7d3fb6186fd..6d3031f3ac25 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.h
> +++ b/drivers/gpu/drm/i915/intel_gvt.h
> @@ -26,7 +26,32 @@
>
> struct drm_i915_private;
>
> +#include
Please use minimal includes. Looks like linux/types.h is enough. Please
also put the includes before the forward declarations.
> +
> #ifdef CONFIG_DRM_I915_GVT
> +
> +#define D_BDW (1 << 0)
> +#define D_SKL(1 << 1)
> +#define D_KBL(1 << 2)
> +#define D_BXT(1 << 3)
> +#define D_CFL(1 << 4)
> +
> +#define D_GEN9PLUS (D_SKL | D_KBL | D_BXT | D_CFL)
> +#define D_GEN8PLUS (D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
> +
> +#define D_SKL_PLUS (D_SKL | D_KBL | D_BXT | D_CFL)
> +#define D_BDW_PLUS (D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
> +
> +#define D_PRE_SKL(D_BDW)
> +#define D_ALL(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
If these really need to be in a header in i915/, I think they need to be
longer with some namespacing or something. I do wish these could be
hidden though.
> +
> +struct intel_gvt_mmio_table_iter {
> + struct drm_i915_private *i915;
> + void *data;
> + int (*handle_mmio_cb)(struct intel_gvt_mmio_table_iter *iter,
> + u32 offset, u32 device, u32 size);
> +};
We're heavily transitioning towards having a corresponding .h for each
.c instead of catch all headers. It's still a work in progress, but I'd
prefer having the declarations for stuff in intel_gvt_mmio_table.c
placed in intel_gvt_mmio_table.h, and named accordingly. Like I
suggested in my previous mails.
> +
> int intel_gvt_init(struct drm_i915_private *dev_priv);
> void intel_gvt_driver_remove(struct drm_i915_private *dev_priv);
> int intel_gvt_init_device(struct drm_i915_private *dev_priv);
> @@ -34,6 +59,8 @@ void intel_gvt_clean_device(struct drm_i915_private
> *dev_priv);
> int intel_gvt_init_host(void);
> void intel_gvt_sanitize_options(struct drm_i915_private *dev_priv);
> void intel_gvt_resume(struct drm_i915_private *dev_priv);
> +unsigned long intel_gvt_get_device_type(struct drm_i915_private *i915);
> +int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter);
> #else
> static inline int intel_gvt_init(struct drm_i915_private *dev_priv)
> {
> @@ -51,6 +78,16 @@ static inline void intel_gvt_sanitize_options(struct
> drm_i915_private *dev_priv)
> static inline void intel_gvt_resume(struct drm_i915_private *dev_priv)
> {
> }
> +
> +unsigned long intel_gvt_get_device_type(struct drm_i915_private *i915)
> +{
> + return 0;
> +}
> +
> +int intel_gvt_iterate_mmio_table(struct intel_gvt_mmio_table_iter *iter)
> +{
> + return 0;
> +}
Stubs need to be static inlines.
> #endif
>
> #endif /* _INTEL_GVT_H_ */
> diff --git a/drivers/gpu/drm/i915/int
[Intel-gfx] [PATCH] drm/doc: pull in drm_buddy.c
Make sure we pull in the kernel-doc for this. Reported-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Arunpravin Cc: Christian König --- Documentation/gpu/drm-mm.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 198bcc1affa1..f32ccce5722d 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -466,6 +466,15 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: +DRM Buddy Allocator +=== + +DRM Buddy Function References +- + +.. kernel-doc:: drivers/gpu/drm/drm_buddy.c + :export: + DRM Cache Handling and Fast WC memcpy() === -- 2.34.1
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915/dp: add 128b/132b support to link status checks
On Thu, Feb 03, 2022 at 11:03:55AM +0200, Jani Nikula wrote:
> Abstract link status check to a function that takes 128b/132b and 8b/10b
> into account, and use it. Also dump link status on failures.
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 39 ++-
> .../drm/i915/display/intel_dp_link_training.c | 2 +-
> .../drm/i915/display/intel_dp_link_training.h | 4 ++
> 3 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 146b83916005..8c5590f0409a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3628,6 +3628,32 @@ static void intel_dp_handle_test_request(struct
> intel_dp *intel_dp)
> "Could not write test response to sink\n");
> }
>
> +static bool intel_dp_link_ok(struct intel_dp *intel_dp,
> + u8 link_status[DP_LINK_STATUS_SIZE])
> +{
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + bool uhbr = intel_dp->link_rate >= 100;
> + bool ok;
> +
> + if (uhbr)
> + ok = drm_dp_128b132b_lane_channel_eq_done(link_status,
> + intel_dp->lane_count);
I was pondering whether we need to check more of the bits here. I guess
time will tell.
Remainder of the series is
Reviewed-by: Ville Syrjälä
> + else
> + ok = drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> +
> + if (ok)
> + return true;
> +
> + intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX, link_status);
> + drm_dbg_kms(&i915->drm,
> + "[ENCODER:%d:%s] %s link not ok, retraining\n",
> + encoder->base.base.id, encoder->base.name,
> + uhbr ? "128b/132b" : "8b/10b");
> +
> + return false;
> +}
> +
> static void
> intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, u8 *ack)
> {
> @@ -3658,14 +3684,7 @@ static bool intel_dp_mst_link_status(struct intel_dp
> *intel_dp)
> return false;
> }
>
> - if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> - drm_dbg_kms(&i915->drm,
> - "[ENCODER:%d:%s] channel EQ not ok, retraining\n",
> - encoder->base.base.id, encoder->base.name);
> - return false;
> - }
> -
> - return true;
> + return intel_dp_link_ok(intel_dp, link_status);
> }
>
> /**
> @@ -3779,8 +3798,8 @@ intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> intel_dp->lane_count))
> return false;
>
> - /* Retrain if Channel EQ or CR not ok */
> - return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> + /* Retrain if link not ok */
> + return !intel_dp_link_ok(intel_dp, link_status);
> }
>
> static bool intel_dp_has_connector(struct intel_dp *intel_dp,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index cc2b82d9114c..0686da36c428 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -712,7 +712,7 @@ static bool intel_dp_adjust_request_changed(const struct
> intel_crtc_state *crtc_
> return false;
> }
>
> -static void
> +void
> intel_dp_dump_link_status(struct intel_dp *intel_dp, enum drm_dp_phy dp_phy,
> const u8 link_status[DP_LINK_STATUS_SIZE])
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> index dbfb15705aaa..dc1556b46b85 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
> @@ -29,6 +29,10 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
> void intel_dp_stop_link_train(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state);
>
> +void
> +intel_dp_dump_link_status(struct intel_dp *intel_dp, enum drm_dp_phy dp_phy,
> + const u8 link_status[DP_LINK_STATUS_SIZE]);
> +
> /* Get the TPSx symbol type of the value programmed to
> DP_TRAINING_PATTERN_SET */
> static inline u8 intel_dp_training_pattern_symbol(u8 pattern)
> {
> --
> 2.30.2
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/mst: update slot information for 128b/132b
On Thu, Feb 03, 2022 at 11:03:56AM +0200, Jani Nikula wrote:
> 128b/132b supports using 64 slots starting from 0, while 8b/10b reserves
> slot 0 for metadata.
>
> Commit d6c6a76f80a1 ("drm: Update MST First Link Slot Information Based
> on Encoding Format") added support for updating the topology state
> accordingly, and commit 41724ea273cd ("drm/amd/display: Add DP 2.0 MST
> DM Support") started using it in the amd driver.
>
> This feels more than a little cumbersome, especially updating the
> information in atomic check. For i915, add the update to MST connector
> .compute_config hook rather than iterating over all MST managers and
> connectors in global mode config .atomic_check. Fingers crossed.
>
> v2:
> - Update in .compute_config() not .atomic_check (Ville)
>
> Cc: Bhawanpreet Lakha
> Cc: Lyude Paul
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 29 +++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 6b6eab507d30..2959e2c3930b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -99,6 +99,27 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
> return 0;
> }
>
> +static void intel_dp_mst_update_slots(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp_mst_encoder *intel_mst = enc_to_mst(encoder);
> + struct intel_dp *intel_dp = &intel_mst->primary->dp;
> + struct drm_dp_mst_topology_mgr *mgr = &intel_dp->mst_mgr;
> + struct drm_dp_mst_topology_state *topology_state;
> + u8 link_coding_cap = intel_dp_is_uhbr(crtc_state) ?
> + DP_CAP_ANSI_128B132B : DP_CAP_ANSI_8B10B;
> +
> + topology_state = drm_atomic_get_mst_topology_state(conn_state->state,
> mgr);
> + if (IS_ERR(topology_state)) {
> + drm_dbg_kms(&i915->drm, "slot update failed\n");
> + return;
We need to propagate the error upwards. Other than that seems about
as as reasonable as it can be given the current state of things.
So with that fixed
Reviewed-by: Ville Syrjälä
> + }
> +
> + drm_dp_mst_update_slots(topology_state, link_coding_cap);
> +}
> +
> static int intel_dp_mst_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state)
> @@ -155,6 +176,8 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> if (ret)
> return ret;
>
> + intel_dp_mst_update_slots(encoder, pipe_config, conn_state);
> +
> pipe_config->limited_color_range =
> intel_dp_limited_color_range(pipe_config, conn_state);
>
> @@ -357,6 +380,7 @@ static void intel_mst_disable_dp(struct
> intel_atomic_state *state,
> struct intel_connector *connector =
> to_intel_connector(old_conn_state->connector);
> struct drm_i915_private *i915 = to_i915(connector->base.dev);
> + int start_slot = intel_dp_is_uhbr(old_crtc_state) ? 0 : 1;
> int ret;
>
> drm_dbg_kms(&i915->drm, "active links %d\n",
> @@ -366,7 +390,7 @@ static void intel_mst_disable_dp(struct
> intel_atomic_state *state,
>
> drm_dp_mst_reset_vcpi_slots(&intel_dp->mst_mgr, connector->port);
>
> - ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, 1);
> + ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, start_slot);
> if (ret) {
> drm_dbg_kms(&i915->drm, "failed to update payload %d\n", ret);
> }
> @@ -475,6 +499,7 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> + int start_slot = intel_dp_is_uhbr(pipe_config) ? 0 : 1;
> int ret;
> bool first_mst_stream;
>
> @@ -509,7 +534,7 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
>
> intel_dp->active_mst_links++;
>
> - ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, 1);
> + ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr, start_slot);
>
> /*
>* Before Gen 12 this is not done as part of
> --
> 2.30.2
--
Ville Syrjälä
Intel
[Intel-gfx] [PULL] drm-intel-next
Hi Dave and Daniel, Here goes the first and probably biggest request towards 5.18. Another request will come in about 2 weeks. drm-intel-next-2022-02-08: Cross-subsystem Changes: dma-buf: - dma-buf-map: Rename to iosys-map (Lucas) Core Changes: - drm: - Always include the debugfs_entry in drm_crtc (Ville) - Add orientation quirk for GPD Win Max (Anisse) Driver Changes: --- gvt: - Constify some pointers. (Rikard Falkeborn) - Use list_entry to access list members. (Guenter Roeck) - Fix cmd parser error for Passmark9. (Zhenyu Wang) i915: - Various clean-ups including headers and removing unused and unnecessary stuff\ (Jani, Hans, Andy, Ville) - Cleaning up on our registers definitions i915_reg.h (Matt) - More multi-FBC refactoring (Ville) - Baytrail backlight fix (Hans) - DG1 OPROM read through SPI controller (Clint) - ADL-N platform enabling (Tejas) - Fix slab-out-of-bounds access (Jani) - Add opregion mailbox #5 support for possible EDID override (Anisse) - Fix possible NULL dereferences (Harish) - Updates and fixes around display voltage swing values (Clint, Jose) - Fix RPM wekeref on PXP code (Juston) - Many register definitions clean-up, including planes registers (Ville) - More conversion towards display version over the old gen (Madhumitha, Ville) - DP MST ESI handling improvements (Jani) - drm device based logging conversions (Jani) - Prevent divide by zero (Dan) - Introduce ilk_pch_pre_enable for complete modeset abstraction (Ville) - Async flip optimization for DG2 (Stanislav) - Multiple DSC and bigjoiner fixes and improvements (Ville) - Fix ADL-P TypeC Phy ready status readout (Imre) - Fix up DP DFP 4:2:0 handling more display related fixes (Ville) - Display M/N cleanup (Ville) - Switch to use VGA definitions from video/vga.h (Jani) - Fixes and improvements to abstract CPU architecture (Lucas) - Disable unsused power wells left enabled by BIOS (Imre) - Allow !join_mbus cases for adlp+ dbuf configuration (Ville) - Populate pipe dbuf slices more accurately during readout (Ville) - Workaround broken BIOS DBUF configuration on TGL/RKL (Ville) - Fix trailing semicolon (Lucas) Thanks, Rodrigo. The following changes since commit 26291c54e111ff6ba87a164d85d4a4e134b7315c: Linux 5.17-rc2 (2022-01-30 15:37:07 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-02-08 for you to fetch changes up to 7938f4218168ae9fc4bdddb15976f9ebbae41999: dma-buf-map: Rename to iosys-map (2022-02-07 16:35:35 -0800) Cross-subsystem Changes: dma-buf: - dma-buf-map: Rename to iosys-map (Lucas) Core Changes: - drm: - Always include the debugfs_entry in drm_crtc (Ville) - Add orientation quirk for GPD Win Max (Anisse) Driver Changes: --- gvt: - Constify some pointers. (Rikard Falkeborn) - Use list_entry to access list members. (Guenter Roeck) - Fix cmd parser error for Passmark9. (Zhenyu Wang) i915: - Various clean-ups including headers and removing unused and unnecessary stuff\ (Jani, Hans, Andy, Ville) - Cleaning up on our registers definitions i915_reg.h (Matt) - More multi-FBC refactoring (Ville) - Baytrail backlight fix (Hans) - DG1 OPROM read through SPI controller (Clint) - ADL-N platform enabling (Tejas) - Fix slab-out-of-bounds access (Jani) - Add opregion mailbox #5 support for possible EDID override (Anisse) - Fix possible NULL dereferences (Harish) - Updates and fixes around display voltage swing values (Clint, Jose) - Fix RPM wekeref on PXP code (Juston) - Many register definitions clean-up, including planes registers (Ville) - More conversion towards display version over the old gen (Madhumitha, Ville) - DP MST ESI handling improvements (Jani) - drm device based logging conversions (Jani) - Prevent divide by zero (Dan) - Introduce ilk_pch_pre_enable for complete modeset abstraction (Ville) - Async flip optimization for DG2 (Stanislav) - Multiple DSC and bigjoiner fixes and improvements (Ville) - Fix ADL-P TypeC Phy ready status readout (Imre) - Fix up DP DFP 4:2:0 handling more display related fixes (Ville) - Display M/N cleanup (Ville) - Switch to use VGA definitions from video/vga.h (Jani) - Fixes and improvements to abstract CPU architecture (Lucas) - Disable unsused power wells left enabled by BIOS (Imre) - Allow !join_mbus cases for adlp+ dbuf configuration (Ville) - Populate pipe dbuf slices more accurately during readout (Ville) - Workaround broken BIOS DBUF configuration on TGL/RKL (Ville) - Fix trailing semicolon (Lucas) Andy Shevchenko (1): drm/i915/dsi: Drop double check ACPI companion device for NULL Anisse Astier (2): drm/i915/opregion: add support for mailbox #5 EDID drm: Add orientation quirk for GPD Win Max Clint Taylor (2): drm/i915/dg1: Read OPROM via SPI
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/dp, drm/i915: 128b/132b updates (rev4)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev4) URL : https://patchwork.freedesktop.org/series/99324/ 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/dp, drm/i915: 128b/132b updates (rev4)
== Series Details == Series: drm/dp, drm/i915: 128b/132b updates (rev4) URL : https://patchwork.freedesktop.org/series/99324/ State : warning == Summary == $ dim checkpatch origin/drm-tip dda5c759f6bc drm/dp: add drm_dp_128b132b_read_aux_rd_interval() 0053fa9bdcc3 drm/dp: add 128b/132b link status helpers from DP 2.0 E11 1675a22fa2b7 drm/dp: add some new DPCD macros from DP 2.0 E11 0285f99c3bdf drm/i915/dp: move intel_dp_prepare_link_train() call 21d4a0d647e0 drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata -:107: CHECK:LINE_SPACING: Please don't use multiple blank lines #107: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1132: + -:332: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #332: FILE: drivers/gpu/drm/i915/display/intel_dp_link_training.c:1357: + + } total: 0 errors, 0 warnings, 2 checks, 337 lines checked e64b9a99d55e drm/i915/dp: add 128b/132b support to link status checks 682ceb281361 drm/i915/mst: update slot information for 128b/132b 14b6d1595f4e HACK: drm/i915/dp: give more time for CDS
Re: [Intel-gfx] [PATCH 1/3] i915/gvt: Introduce the mmio_table.c to support VFIO new mdev API
Hi Zhi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20220208]
[cannot apply to drm-intel/for-linux-next v5.17-rc3]
[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/Zhi-Wang/i915-gvt-Introduce-the-mmio_table-c-to-support-VFIO-new-mdev-API/20220127-200727
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-rhel-8.3-kselftests
(https://download.01.org/0day-ci/archive/20220208/202202082210.bpzsju31-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
#
https://github.com/0day-ci/linux/commit/533f92651a7a56481a053f1e04dc5a5ec024ffb9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Zhi-Wang/i915-gvt-Introduce-the-mmio_table-c-to-support-VFIO-new-mdev-API/20220127-200727
git checkout 533f92651a7a56481a053f1e04dc5a5ec024ffb9
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir
ARCH=x86_64 SHELL=/bin/bash drivers/gpu/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/gvt/handlers.c:45:6: sparse: sparse: symbol
>> 'intel_gvt_match_device' was not declared. Should it be static?
vim +/intel_gvt_match_device +45 drivers/gpu/drm/i915/gvt/handlers.c
12d14cc43b3470 Zhi Wang 2016-08-30 44
12d14cc43b3470 Zhi Wang 2016-08-30 @45 bool intel_gvt_match_device(struct
intel_gvt *gvt,
12d14cc43b3470 Zhi Wang 2016-08-30 46 unsigned long device)
12d14cc43b3470 Zhi Wang 2016-08-30 47 {
533f92651a7a56 Zhi Wang 2022-01-27 48 return
intel_gvt_get_device_type(gvt->gt->i915) & device;
12d14cc43b3470 Zhi Wang 2016-08-30 49 }
12d14cc43b3470 Zhi Wang 2016-08-30 50
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [Intel-gfx] [PATCH v4] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
On Tue, Feb 08, 2022 at 04:32:09PM +0200, Jani Nikula wrote:
> The DP 2.0 errata completely overhauls the 128b/132b link training, with
> no provisions for backward compatibility with the original DP 2.0
> specification.
>
> The changes are too intrusive to consider reusing the same code for both
> 8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
> done concurrently instead of serialized.
>
> NOTES:
>
> * It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and
> per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the
> LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or*
> 0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204)
> i.e. without the above bits set. Text elsewhere seems contradictory or
> incomplete.
>
> * We read entire link status (6 bytes) everywhere instead of individual
> DPCD addresses.
>
> * There are some subtle ambiguities or contradictions in the order of
> some DPCD access and TPS signal enables/disables. It's also not clear
> whether these are significant.
>
> v4:
> - Wait for intra-hop clear after link training end (Ville)
> - Wait instead of single check for intra-hop clear before link train
>
> v3:
> - Use msecs_to_jiffies_timeout() (Ville)
> - Read status at the beginning of interlane align done loop (Ville)
> - Try to simplify timeout flag use where possible (Ville)
>
> v2:
> - Always try one last time after timeouts to avoid races (Ville)
> - Extend timeout to cover the entire LANEx_EQ_DONE sequence (Ville)
> - Also check for eq interlane align done in LANEx_CDS_DONE Sequence (Ville)
> - Check for Intra-hop status before link training
>
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Looks good to me.
Reviewed-by: Ville Syrjälä
> ---
> .../drm/i915/display/intel_dp_link_training.c | 303 +-
> 1 file changed, 302 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 4e507aa75a03..d7f6d92ac5b5 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -996,6 +996,23 @@ static bool
> intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp,
> return drm_dp_dpcd_write(&intel_dp->aux, reg, &val, 1) == 1;
> }
>
> +static int
> +intel_dp_128b132b_intra_hop(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 sink_status;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_STATUS, &sink_status);
> + if (ret != 1) {
> + drm_dbg_kms(&i915->drm, "Failed to read sink status\n");
> + return ret < 0 ? ret : -EIO;
> + }
> +
> + return sink_status & DP_INTRA_HOP_AUX_REPLY_INDICATION ? 1 : 0;
> +}
> +
> /**
> * intel_dp_stop_link_train - stop link training
> * @intel_dp: DP struct
> @@ -1015,11 +1032,21 @@ static bool
> intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp,
> void intel_dp_stop_link_train(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state)
> {
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> +
> intel_dp->link_trained = true;
>
> intel_dp_disable_dpcd_training_pattern(intel_dp, DP_PHY_DPRX);
> intel_dp_program_link_training_pattern(intel_dp, crtc_state,
> DP_PHY_DPRX,
> DP_TRAINING_PATTERN_DISABLE);
> +
> + if (intel_dp_is_uhbr(crtc_state) &&
> + wait_for(intel_dp_128b132b_intra_hop(intel_dp, crtc_state) == 0,
> 500)) {
> + drm_dbg_kms(&i915->drm,
> + "[ENCODER:%d:%s] 128b/132b intra-hop not
> clearing\n",
> + encoder->base.base.id, encoder->base.name);
> + }
> }
>
> static bool
> @@ -1102,6 +1129,274 @@ intel_dp_link_train_all_phys(struct intel_dp
> *intel_dp,
> return ret;
> }
>
> +
> +/*
> + * 128b/132b DP LANEx_EQ_DONE Sequence (DP 2.0 E11 3.5.2.16.1)
> + */
> +static bool
> +intel_dp_128b132b_lane_eq(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + u8 link_status[DP_LINK_STATUS_SIZE];
> + int delay_us;
> + int try, max_tries = 20;
> + unsigned long deadline;
> + bool timeout = false;
> +
> + /*
> + * Reset signal levels. Start transmitting 128b/132b TPS1.
> + *
> + * Put DPRX and LTTPRs (if any) into intra-hop AUX mode by writing TPS1
> + * in DP_TRAINING_PATTERN_SET.
> + */
> + if (!intel_dp_reset_li
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/buddy: fixup potential uaf
== Series Details ==
Series: drm/buddy: fixup potential uaf
URL : https://patchwork.freedesktop.org/series/99842/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11201 -> Patchwork_22205
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/index.html
Participating hosts (44 -> 43)
--
Additional (1): fi-pnv-d510
Missing(2): fi-bsw-cyan fi-icl-u2
Known issues
Here are the changes found in Patchwork_22205 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-skl-6600u: NOTRUN -> [SKIP][1] ([fdo#109271]) +21 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-skl-6600u/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-skl-6600u/igt@kms_chamel...@vga-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-skl-6600u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +57 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-pnv-d510/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][7] ([i915#4957]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [DMESG-WARN][9] ([i915#4269]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/fi-cml-u2/igt@kms_frontbuffer_track...@basic.html
Warnings
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) ->
[DMESG-FAIL][12] ([i915#4957])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11201/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22205/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-
[Intel-gfx] [PATCH v4] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
The DP 2.0 errata completely overhauls the 128b/132b link training, with
no provisions for backward compatibility with the original DP 2.0
specification.
The changes are too intrusive to consider reusing the same code for both
8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
done concurrently instead of serialized.
NOTES:
* It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and
per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the
LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or*
0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204)
i.e. without the above bits set. Text elsewhere seems contradictory or
incomplete.
* We read entire link status (6 bytes) everywhere instead of individual
DPCD addresses.
* There are some subtle ambiguities or contradictions in the order of
some DPCD access and TPS signal enables/disables. It's also not clear
whether these are significant.
v4:
- Wait for intra-hop clear after link training end (Ville)
- Wait instead of single check for intra-hop clear before link train
v3:
- Use msecs_to_jiffies_timeout() (Ville)
- Read status at the beginning of interlane align done loop (Ville)
- Try to simplify timeout flag use where possible (Ville)
v2:
- Always try one last time after timeouts to avoid races (Ville)
- Extend timeout to cover the entire LANEx_EQ_DONE sequence (Ville)
- Also check for eq interlane align done in LANEx_CDS_DONE Sequence (Ville)
- Check for Intra-hop status before link training
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_dp_link_training.c | 303 +-
1 file changed, 302 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 4e507aa75a03..d7f6d92ac5b5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -996,6 +996,23 @@ static bool intel_dp_disable_dpcd_training_pattern(struct
intel_dp *intel_dp,
return drm_dp_dpcd_write(&intel_dp->aux, reg, &val, 1) == 1;
}
+static int
+intel_dp_128b132b_intra_hop(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ u8 sink_status;
+ int ret;
+
+ ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_STATUS, &sink_status);
+ if (ret != 1) {
+ drm_dbg_kms(&i915->drm, "Failed to read sink status\n");
+ return ret < 0 ? ret : -EIO;
+ }
+
+ return sink_status & DP_INTRA_HOP_AUX_REPLY_INDICATION ? 1 : 0;
+}
+
/**
* intel_dp_stop_link_train - stop link training
* @intel_dp: DP struct
@@ -1015,11 +1032,21 @@ static bool
intel_dp_disable_dpcd_training_pattern(struct intel_dp *intel_dp,
void intel_dp_stop_link_train(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+
intel_dp->link_trained = true;
intel_dp_disable_dpcd_training_pattern(intel_dp, DP_PHY_DPRX);
intel_dp_program_link_training_pattern(intel_dp, crtc_state,
DP_PHY_DPRX,
DP_TRAINING_PATTERN_DISABLE);
+
+ if (intel_dp_is_uhbr(crtc_state) &&
+ wait_for(intel_dp_128b132b_intra_hop(intel_dp, crtc_state) == 0,
500)) {
+ drm_dbg_kms(&i915->drm,
+ "[ENCODER:%d:%s] 128b/132b intra-hop not
clearing\n",
+ encoder->base.base.id, encoder->base.name);
+ }
}
static bool
@@ -1102,6 +1129,274 @@ intel_dp_link_train_all_phys(struct intel_dp *intel_dp,
return ret;
}
+
+/*
+ * 128b/132b DP LANEx_EQ_DONE Sequence (DP 2.0 E11 3.5.2.16.1)
+ */
+static bool
+intel_dp_128b132b_lane_eq(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ u8 link_status[DP_LINK_STATUS_SIZE];
+ int delay_us;
+ int try, max_tries = 20;
+ unsigned long deadline;
+ bool timeout = false;
+
+ /*
+* Reset signal levels. Start transmitting 128b/132b TPS1.
+*
+* Put DPRX and LTTPRs (if any) into intra-hop AUX mode by writing TPS1
+* in DP_TRAINING_PATTERN_SET.
+*/
+ if (!intel_dp_reset_link_train(intel_dp, crtc_state, DP_PHY_DPRX,
+ DP_TRAINING_PATTERN_1)) {
+ drm_err(&i915->drm,
+ "[ENCODER:%d:%s] Failed to start 128b/132b TPS1\n",
+ encoder->base.base.id, encoder->base.name);
+
Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote: > Ever since Tomi extracted the core code in 2014 it's been defacto me > maintaining this, with help from others from dri-devel and sometimes > Linus (but those are mostly merge conflicts): > > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5 > 35 Daniel Vetter > 23 Linus Torvalds > 10 Hans de Goede > 9 Dave Airlie > 6 Peter Rosin > > I think ideally we'd also record that the various firmware fb drivers > (efifb, vesafb, ...) are also maintained in drm-misc because for the > past few years the patches have either been to fix handover issues > with drm drivers, or caused handover issues with drm drivers. So any > other tree just doesn't make sense. But also, there's plenty of > outdated MAINTAINER entries for these with people and git trees that > haven't been active in years, so maybe let's just leave them alone. > And furthermore distros are now adopting simpledrm as the firmware fb > driver, so hopefully the need to care about the fbdev firmware drivers > will go down going forward. > > Note that drm-misc is group maintained, I expect that to continue like > we've done before, so no new expectations that patches all go through > my hands. That would be silly. This also means I'm happy to put any > other volunteer's name in the M: line, but otherwise git log says I'm > the one who's stuck with this. > > Cc: Dave Airlie > Cc: Jani Nikula > Cc: Linus Torvalds > Cc: Linux Fbdev development list > Cc: Pavel Machek > Cc: Sam Ravnborg > Cc: Greg Kroah-Hartman > Cc: Javier Martinez Canillas > Cc: DRI Development > Cc: Linux Kernel Mailing List > Cc: Claudio Suarez > Cc: Tomi Valkeinen > Cc: Geert Uytterhoeven > Cc: Thomas Zimmermann > Cc: Daniel Vetter > Cc: Sven Schnelle > Cc: Gerd Hoffmann > Signed-off-by: Daniel Vetter Merged to drm-misc-fixes with all the acks added. -Daniel > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ea3e6c914384..49809eaa3096 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7573,6 +7573,12 @@ S: Maintained > W: http://floatingpoint.sourceforge.net/emulator/index.html > F: arch/x86/math-emu/ > > +FRAMEBUFFER CORE > +M: Daniel Vetter > +F: drivers/video/fbdev/core/ > +S: Odd Fixes > +T: git git://anongit.freedesktop.org/drm/drm-misc > + > FRAMEBUFFER LAYER > M: Helge Deller > L: linux-fb...@vger.kernel.org > -- > 2.33.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix mbus join config lookup
On Mon, 07 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The bogus loop from compute_dbuf_slices() was copied into
> check_mbus_joined() as well. So this lookup is wrong as well.
> Fix it.
>
> Cc: sta...@vger.kernel.org
> Fixes: f4dc00863226 ("drm/i915/adl_p: MBUS programming")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index da721aea70ff..23d4bb011fc8 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4831,7 +4831,7 @@ static bool check_mbus_joined(u8 active_pipes,
> {
> int i;
>
> - for (i = 0; i < dbuf_slices[i].active_pipes; i++) {
> + for (i = 0; dbuf_slices[i].active_pipes != 0; i++) {
> if (dbuf_slices[i].active_pipes == active_pipes)
> return dbuf_slices[i].join_mbus;
> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] drm/i195: Fix dbuf slice config lookup
On Mon, 07 Feb 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently I totally fumbled the loop condition when I
> removed the ARRAY_SIZE() stuff from the dbuf slice config
> lookup. Comparing the loop index with the active_pipes bitmask
> is utter nonsense, what we want to do is check to see if the
> mask is zero or not.
>
> Cc: sta...@vger.kernel.org
> Fixes: 05e8155afe35 ("drm/i915: Use a sentinel to terminate the dbuf slice
> arrays")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 02084652fe3d..da721aea70ff 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4848,7 +4848,7 @@ static u8 compute_dbuf_slices(enum pipe pipe, u8
> active_pipes, bool join_mbus,
> {
> int i;
>
> - for (i = 0; i < dbuf_slices[i].active_pipes; i++) {
> + for (i = 0; dbuf_slices[i].active_pipes != 0; i++) {
> if (dbuf_slices[i].active_pipes == active_pipes &&
> dbuf_slices[i].join_mbus == join_mbus)
> return dbuf_slices[i].dbuf_mask[pipe];
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> Thanks for your patch!
>
> On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
>
> Can't the actual frame buffer driver (which one?) used on olpc export
> a pointer to its fb_info?
Yeah that might be the right thing to do, I'll add that as a stagin TODO
in the next iteration.
>
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
>
> CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> by the robot.
Yeah realized that too and fixed it locally.
Cheers, Daniel
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] ✗ Fi.CI.IGT: failure for GuC HWCONFIG with documentation (rev2)
== Series Details == Series: GuC HWCONFIG with documentation (rev2) URL : https://patchwork.freedesktop.org/series/99787/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11200_full -> Patchwork_22202_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22202_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22202_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22202_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@smoketest: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb3/igt@gem_ctx_persiste...@smoketest.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/shard-iclb7/igt@gem_ctx_persiste...@smoketest.html * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-apl: NOTRUN -> [DMESG-WARN][3] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/shard-apl2/igt@syncobj_timel...@invalid-transfer-non-existent-point.html - shard-iclb: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/shard-iclb5/igt@syncobj_timel...@invalid-transfer-non-existent-point.html * igt@syncobj_timeline@transfer-timeline-point: - shard-kbl: NOTRUN -> [DMESG-WARN][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/shard-kbl7/igt@syncobj_timel...@transfer-timeline-point.html - shard-skl: NOTRUN -> [DMESG-WARN][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/shard-skl1/igt@syncobj_timel...@transfer-timeline-point.html Known issues Here are the changes found in Patchwork_22202_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-snb: ([PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31]) -> ([PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [FAIL][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55], [PASS][56]) ([i915#4338]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb5/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb5/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb5/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb7/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb7/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb4/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb4/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb4/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb4/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb4/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-snb5/boot.html [31]: https://int
Re: [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info
On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > Accessing the one in fbmem.c without taking the right locks is a bad
> > idea. Instead maintain our own private copy, which is fully protected
> > by console_lock() (like everything else in fbcon.c). That copy is
> > serialized through fbcon_fb_registered/unregistered() calls.
>
> I fail to see why we can make a private copy of registered_fb
> just like that - are they not somehow shared between fbcon and fbmem.
> So when fbmem updates it, then fbcon will use the entry or such?
>
> I guess I am just ignorant of how registered_fb is used - but please
> explain.
The private copy is protected under console_lock, and hence safe to access
from fbcon.c code.
The main registered_fb array is protected by a different mutex, so we
could indeed end up with hilarious corruption because the value is
inconsistent while we try to access it (e.g. we check for !NULL, but later
on gcc decides to reload the value and now it's suddenly become NULL and
we blow up).
The two are synchronized by fbmem.c calling fbcon_register/unregister, so
aside from the different locks if there's no race going on, they will
always be identical.
Other option would be to roll out get_fb_info() to fbcon.c, but since
fbcon.c is fully protected by console_lock that would add complexity in
the code flow that we don't really need. And we'd have to wire fb_info
through all call chains, since the right way to use get_fb_info is to look
it up once and then only drop it when your callback has finished.
Since the current code just assume it's all protected by console_lock and
we never drop that during a callback this would mean major surgery and
essentially refactoring all of fbcon.c to only access the fbcon stuff
through fb_info, i.e. to get rid of _all_ the global arrays we have more
or less. I'm not volunteering for that (despite that really this would be
the right thing to do if we'd have infinite engineering time).
Ack with that explainer added to the commit message?
-Daniel
>
> Sam
>
> >
> > Also this means we do not need to hold a full fb_info reference, which
> > is nice because doing so would mean a refcount loop between the
> > console and the fb_info. But it's also not nice since it means
> > console_lock() must be held absolutely everywhere. Well strictly
> > speaking we could still try to do some refcounting games again by
> > calling get_fb_info before we drop the console_lock. But things will
> > get tricky.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Tetsuo Handa
> > Cc: Claudio Suarez
> > Cc: Du Cheng
> > Cc: Greg Kroah-Hartman
> > ---
> > drivers/video/fbdev/core/fbcon.c | 82 +---
> > 1 file changed, 43 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 22581952b4fd..a0ca34b29615 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -86,10 +86,6 @@
> > * - fbcon state itself is protected by the console_lock, and the code
> > does a
> > * pretty good job at making sure that lock is held everywhere it's
> > needed.
> > *
> > - * - access to the registered_fb array is entirely unprotected. This
> > should use
> > - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> > - * switching from indices to proper pointers for fb_info everywhere.
> > - *
> > * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since
> > it
> > * means concurrent access to the same fbdev from both fbcon and
> > userspace
> > * will blow up. To fix this all fbcon calls from fbmem.c need to be
> > moved out
> > @@ -107,6 +103,13 @@ enum {
> >
> > static struct fbcon_display fb_display[MAX_NR_CONSOLES];
> >
> > +struct fb_info *fbcon_registered_fb[FB_MAX];
> > +int fbcon_num_registered_fb;
> > +
> > +#define fbcon_for_each_registered_fb(i)\
> > + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> > + if (!fbcon_registered_fb[i]) {} else
> > +
> > static signed char con2fb_map[MAX_NR_CONSOLES];
> > static signed char con2fb_map_boot[MAX_NR_CONSOLES];
> >
> > @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int
> > console)
> > {
> > WARN_CONSOLE_UNLOCKED();
> >
> > - /*
> > -* Note that only con2fb_map is protected by the console lock,
> > -* registered_fb is protected by a separate mutex. This lookup can
> > -* therefore race.
> > -*/
> > - return registered_fb[con2fb_map[console]];
> > + return fbcon_registered_fb[con2fb_map[console]];
> > }
> >
> > static int logo_lines;
> > @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> > {
> > int err, i;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> >
Re: [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit
On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > There's a bunch of confusions going on here:
> > - The deferred fbcon setup notifier should only be cleaned up from
> > fb_console_exit(), to be symmetric with fb_console_init()
> > - We also need to make sure we don't race with the work, which means
> > temporarily dropping the console lock (or we can deadlock)
> > - That also means no point in clearing deferred_takeover, we are
> > unloading everything anyway.
> > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > that's what's it doing when being called from consw->con_deinit
> > through fbcon_deinit.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Greg Kroah-Hartman
> > Cc: Claudio Suarez
> > Cc: Du Cheng
> > Cc: Tetsuo Handa
> > ---
> > drivers/video/fbdev/core/fbcon.c | 63
> > 1 file changed, 32 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 5c14e24d14a1..22581952b4fd 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct
> > fb_var_screeninfo *var,
> >int unit);
> > static void fbcon_modechanged(struct fb_info *info);
> > static void fbcon_set_all_vcs(struct fb_info *info);
> > -static void fbcon_exit(void);
> >
> > static struct device *fbcon_device;
> >
> > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p,
> > bool freefont)
> >
> > static void set_vc_hi_font(struct vc_data *vc, bool set);
> >
> > +static void fbcon_release_all(void)
> > +{
> > + struct fb_info *info;
> > + int i, j, mapped;
> > +
> > + for_each_registered_fb(i) {
> > + mapped = 0;
> > + info = registered_fb[i];
> > +
> > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > + if (con2fb_map[j] == i) {
> > + mapped = 1;
> > + con2fb_map[j] = -1;
> > + }
> > + }
> > +
> > + if (mapped)
> > + fbcon_release(info);
> > + }
> > +}
> > +
> > static void fbcon_deinit(struct vc_data *vc)
> > {
> > struct fbcon_display *p = &fb_display[vc->vc_num];
> > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > set_vc_hi_font(vc, false);
> >
> > if (!con_is_bound(&fb_con))
> > - fbcon_exit();
> > + fbcon_release_all();
> >
> > if (vc->vc_num == logo_shown)
> > logo_shown = FBCON_LOGO_CANSHOW;
> > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > #endif
> > }
> >
> > -static void fbcon_exit(void)
> > -{
> > - struct fb_info *info;
> > - int i, j, mapped;
> > -
> > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > - if (deferred_takeover) {
> > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > - deferred_takeover = false;
> > - }
> > -#endif
> > -
> > - for_each_registered_fb(i) {
> > - mapped = 0;
> > - info = registered_fb[i];
> > -
> > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > - if (con2fb_map[j] == i) {
> > - mapped = 1;
> > - con2fb_map[j] = -1;
> > - }
> > - }
> > -
> > - if (mapped)
> > - fbcon_release(info);
> > - }
> > -}
> > -
> > void __init fb_console_init(void)
> > {
> > int i;
> > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> >
> > void __exit fb_console_exit(void)
> > {
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > + console_lock();
> > + if (deferred_takeover)
> > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > + console_unlock();
> > +
> > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > +#endif
> > +
> > console_lock();
> > fbcon_deinit_device();
> > device_destroy(fb_class, MKDEV(0, 0));
> > - fbcon_exit();
> > +
> We loose the call to fbcon_release_all() here.
> We have part of the old fbcon_exit() above, but miss the release parts.
>
> Maybe I missed something obvious?
Ah yes that's the entire point of this change. The release_all in the
fbcon exit path was only needed when fbcon was a separate module
indepedent from core fb.ko. Which means it was possible to unload fbcon
while having fbdev drivers registered.
But since we've merged them that has become impossible, so by the time the
fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
left. And hence removing them is pointless.
Ack with that explainer added to the commit message?
-Daniel
>
> The rest looks fine.
>
> Sam
>
> > do_un
Re: [Intel-gfx] [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
On Fri, Feb 04, 2022 at 08:54:24PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> > Ideally console_lock becomes an implementation detail of fbcon.c and
> > doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> > but at least the register/unregister code is there now.
> >
> > With this the do_fb_ioctl() handler is the only code in fbmem.c still
> > calling console_lock().
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Thomas Zimmermann
> > Cc: Du Cheng
> > Cc: Claudio Suarez
> > Cc: Greg Kroah-Hartman
> > Cc: Tetsuo Handa
> > Cc: Matthew Wilcox
> > Cc: Sam Ravnborg
> > Cc: Zheyu Ma
> > Cc: Guenter Roeck
> > Cc: Alex Deucher
> > Cc: Zhen Lei
> > Cc: Xiyu Yang
>
> Like how lock_console is now almost local to fbcon.
> Except the usage outside fbmem + fbcon taht is.
Yeah that's the goal. The problem is that moving console_lock for the
remaining fb_pan and fb_set_var calls will mean we need to put
lock_fbinfo() calls into fbcon.c, and right now that's just not
impossible. The FIXME update at the end of the series tries to explain
this a bit more.
-Daniel
>
> Acked-by: Sam Ravnborg
>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 33 ++--
> > drivers/video/fbdev/core/fbmem.c | 23 ++
> > 2 files changed, 29 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 11b9f962af6f..e5e8aaf6f60d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> > int i, new_idx = -1;
> > int idx = info->node;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (!fbcon_has_console_bind)
> > + if (!fbcon_has_console_bind) {
> > + console_unlock();
> > return;
> > + }
> >
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > if (con2fb_map[i] != idx &&
> > @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> > }
> > fbcon_unbind();
> > }
> > +
> > + console_unlock();
> > }
> >
> > /* called with console_lock held */
> > @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > {
> > int i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (deferred_takeover)
> > + if (deferred_takeover) {
> > + console_unlock();
> > return;
> > + }
> >
> > idx = info->node;
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > if (!num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > + console_unlock();
> > }
> >
> > void fbcon_remap_all(struct fb_info *info)
> > @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct
> > fb_info *info)
> > }
> > #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
> >
> > +static bool lockless_register_fb;
> > +module_param_named_unsafe(lockless_register_fb, lockless_register_fb,
> > bool, 0400);
> > +MODULE_PARM_DESC(lockless_register_fb,
> > + "Lockless framebuffer registration for debugging [default=off]");
> > +
> > /* called with console_lock held */
> > int fbcon_fb_registered(struct fb_info *info)
> > {
> > int ret = 0, i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + if (!lockless_register_fb)
> > + console_lock();
> > + else
> > + atomic_inc(&ignore_console_lock_warning);
> >
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > if (deferred_takeover) {
> > pr_info("fbcon: Deferring console take-over\n");
> > - return 0;
> > + goto out;
> > }
> >
> > if (info_idx == -1) {
> > @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> > }
> > }
> >
> > +out:
> > + if (!lockless_register_fb)
> > + console_unlock();
> > + else
> > + atomic_dec(&ignore_console_lock_warning);
> > +
> > return ret;
> > }
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c
> > b/drivers/video/fbdev/core/fbmem.c
> > index fd51d12f2702..904ef1250677 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1573,14 +1573,9 @@ static void
> > do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > }
> > }
> >
> > -static bool lockless_register_fb;
> > -module_param_named_unsafe(lockless_register_fb, lockless_register_fb,
> > bool, 0400);
> > -MODULE_PARM_DESC(lockless_register_fb,
> > - "Lockless framebuffer registration for debugging [default=off]");
> > -
> > static int do_register_framebuffer(struct fb_info *fb_info)
> > {
> > - int i, ret;
> > + int i;
> > struct fb_videomode mode;
> >
> >
Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > No idea why con2fb_acquire_newinfo() initializes much less than
> > fbcon_startup(), but so be it. From a quick look most of the
> > un-initialized stuff should be fairly harmless, but who knows.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Greg Kroah-Hartman
> > Cc: Tetsuo Handa
> > Cc: Thomas Zimmermann
> > Cc: Claudio Suarez
> > Cc: Du Cheng
> > ---
> > drivers/video/fbdev/core/fbcon.c | 74 +---
> > 1 file changed, 31 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index b83a5a77d8a8..5a3391ff038d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info
> > *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> > +
> > static int fbcon_open(struct fb_info *info)
> > {
> > + struct fbcon_ops *ops;
> > +
> > if (!try_module_get(info->fbops->owner))
> > return -ENODEV;
> >
> > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > return -ENODEV;
> > }
> >
> > - return 0;
> > -}
> > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > + if (!ops) {
> > + fbcon_release(info);
> > + return -ENOMEM;
> > + }
> >
> > -static void fbcon_release(struct fb_info *info)
> > -{
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > + ops->info = info;
> > + info->fbcon_par = ops;
> > + ops->cur_blink_jiffies = HZ / 5;
> >
> > - module_put(info->fbops->owner);
> > + return 0;
> > }
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > - int unit, int oldidx)
> > + int unit)
> > {
> > struct fbcon_ops *ops = NULL;
> > int err;
> > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> > struct fb_info *info,
> > if (err)
> > return err;
> >
> > - if (!err) {
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops)
> > - err = -ENOMEM;
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > - }
> > -
> > - if (!err) {
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> > -
> > - if (vc)
> > - set_blitting_type(vc, info);
> > - }
> > + ops = info->fbcon_par;
> >
> > - if (err) {
> > - con2fb_map[unit] = oldidx;
> > - fbcon_release(info);
> > - }
> > + if (vc)
> > + set_blitting_type(vc, info);
> >
> > return err;
> > }
> > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int
> > user)
> >
> > found = search_fb_in_map(newidx);
> >
> > - con2fb_map[unit] = newidx;
> > - if (!err && !found)
> > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > + if (!err && !found) {
> > + err = con2fb_acquire_newinfo(vc, info, unit);
> > + if (!err)
> > + con2fb_map[unit] = newidx;
> > + }
> This looks like an unintentional change of functionality as con2fb_map[unit]
> is
> only assigned when we do a con2fb_acquire_newinfo().
>
> Staring at the code I could not say it is wrong, but not nice to hide
> the change in this patch.
Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
reset con2fb_map to oldidx upon failure, which I've found to be a most
bizarre calling convention. So this sorts this out.
The reason I smashed this into the same patch is that I had to remove the
fbcon_release call, and so the error handling in there looked even more
funny. But I indeed failed to explain this all in the commit message.
Ack with that explainer, or do you want me to split this out properly?
-Daniel
>
> Sam
>
>
> >
> > /*
> > * If old fb is not mapped to any of the consoles,
> > @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> > if (fbcon_open(info))
> > return NULL;
> >
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops) {
> > - fbcon_release(info);
> > - return NULL;
> > - }
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > -
> > + ops = info->fbcon_par;
> > ops->currcon = -1;
> > ops->graphics = 1;
> > ops->cur_rotate = -
Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > There's two minor behaviour changes in here:
> > - in error paths we now consistently call fb_ops->fb_release
> > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > reasonable cleanup we can do anyway.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Daniel Vetter
> > Cc: Claudio Suarez
> > Cc: Greg Kroah-Hartman
> > Cc: Tetsuo Handa
> > Cc: Du Cheng
> > ---
> > drivers/video/fbdev/core/fbcon.c | 107 +++
> > 1 file changed, 53 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index fa30e1909164..eea2ee14b64c 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info
> > *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static int fbcon_open(struct fb_info *info)
> > +{
> > + if (!try_module_get(info->fbops->owner))
> > + return -ENODEV;
> > +
> > + if (info->fbops->fb_open &&
> > + info->fbops->fb_open(info, 0)) {
> > + module_put(info->fbops->owner);
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > int unit, int oldidx)
> > {
> > struct fbcon_ops *ops = NULL;
> > - int err = 0;
> > -
> > - if (!try_module_get(info->fbops->owner))
> > - err = -ENODEV;
> > + int err;
> >
> > - if (!err && info->fbops->fb_open &&
> > - info->fbops->fb_open(info, 0))
> > - err = -ENODEV;
> > + err = fbcon_open(info);
> > + if (err)
> > + return err;
> >
> > if (!err) {
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc,
> > struct fb_info *info,
> >
> > if (err) {
> > con2fb_map[unit] = oldidx;
> > - module_put(info->fbops->owner);
> > + fbcon_release(info);
> > }
> >
> > return err;
> > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc,
> > struct fb_info *oldinfo,
> > int oldidx, int found)
> > {
> > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > - int err = 0, ret;
> > + int ret;
> >
> > - if (oldinfo->fbops->fb_release &&
> > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > - con2fb_map[unit] = oldidx;
> The old code assigns con2fb_map[unit] before is calls
> newinfo->fbops->fb_release).
> I wonder if there can be any callback to fbcon where the value
> of con2fb_map[unit] matters?
It's all protected by console_lock, so other threads cannot see the
inconsistent state.
Essentially everything in fbcon.c is protected by console_lock().
Do you want me to hammer this in somewhere (maybe in the commit message),
or good enough for your ack?
-Daniel
>
>
> > - if (!found && newinfo->fbops->fb_release)
> > - newinfo->fbops->fb_release(newinfo, 0);
> > - if (!found)
> > - module_put(newinfo->fbops->owner);
> > - err = -ENODEV;
> > - }
> > + fbcon_release(oldinfo);
> >
> > - if (!err) {
> > - fbcon_del_cursor_work(oldinfo);
> > - kfree(ops->cursor_state.mask);
> > - kfree(ops->cursor_data);
> > - kfree(ops->cursor_src);
> > - kfree(ops->fontbuffer);
> > - kfree(oldinfo->fbcon_par);
> > - oldinfo->fbcon_par = NULL;
> > - module_put(oldinfo->fbops->owner);
> > - /*
> > - If oldinfo and newinfo are driving the same hardware,
> > - the fb_release() method of oldinfo may attempt to
> > - restore the hardware state. This will leave the
> > - newinfo in an undefined state. Thus, a call to
> > - fb_set_par() may be needed for the newinfo.
> > - */
> > - if (newinfo && newinfo->fbops->fb_set_par) {
> > - ret = newinfo->fbops->fb_set_par(newinfo);
> > + fbcon_del_cursor_work(oldinfo);
>
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would drop the nice symmetry but make it more consistent.
>
> I think we miss freeing ops->cursor_data in fbcon_exit(),
> but I did no
Re: [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > It was only used by fbcon, and that now switched to its own,
> > private work.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Helge Deller
> > Cc: linux-fb...@vger.kernel.org
> I would merge this with the patch that drops the usage
Yeah, but I like to split these out so that if this does break something,
it's much easier to revert. In case I overlooked something somewhere.
It's imo different if the cleanup is directly related to the preceeding
prep work, but this is a generic workqueue, and the cursor logic is rather
unrelated. And if I remember my history digging right, there were actually
other uses of this.
-Daniel
>
> > ---
> > include/linux/fb.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 02f362c661c8..a8a00d2ba1f3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -449,7 +449,6 @@ struct fb_info {
> > struct fb_var_screeninfo var; /* Current var */
> > struct fb_fix_screeninfo fix; /* Current fix */
> > struct fb_monspecs monspecs;/* Current Monitor specs */
> > - struct work_struct queue; /* Framebuffer event queue */
> > struct fb_pixmap pixmap;/* Image hardware mapper */
> > struct fb_pixmap sprite;/* Cursor hardware mapper */
> > struct fb_cmap cmap;/* Current cmap */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > Before
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> > fbcon: Make fbcon a built-time depency for fbdev
> >
> > it was possible to load fbcon and fbdev drivers in any order, which
> > means that fbcon init had to handle the case where fbdev drivers where
> > already registered.
> >
> > This is no longer possible, hence delete that code.
> >
> > Note that the exit case is a bit more complex and will be done in a
> > separate patch.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Helge Deller
> > Cc: Daniel Vetter
> > Cc: Claudio Suarez
> > Cc: Greg Kroah-Hartman
> > Cc: Tetsuo Handa
> > Cc: Du Cheng
> > ---
> > drivers/video/fbdev/core/fbcon.c | 13 +
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c
> > b/drivers/video/fbdev/core/fbcon.c
> > index 8f971de35885..814b648e8f09 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > -* fb_console_init();
> > +* fbcon_fb_registered();
> > */
> This comment change looks like it does not belong in this patch.
> Also, the comment is wrong as info_idx is set in several places.
> Like set_con2fb_map(), fbcon_remap_all(), and more.
Yeah I can split this out into a separate patch, but I spotted this wrong
comment as part of reviewing this code change here - essentially you have
to check how fb_info for fbcon are registered and fbcon init happens to
validate that deleting the below code is correct.
Ok if I put this explainer into the commit message, or do you want me to
split this out fully?
-Daniel
>
> Though it is not set by fb_console_init - so partly OK.
>
> With the comment adjustment dropped.
> Acked-by: Sam Ravnborg
>
> at least the code deletion looked OK, I failed to follow all the logic.
> So would be good if someone else could ack it too.
>
> Sam
>
>
>
> > info = registered_fb[info_idx];
> > if (!info)
> > @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> > return;
> > }
> > #endif
> > -
> > - if (num_registered_fb) {
> > - int i;
> > -
> > - for_each_registered_fb(i) {
> > - info_idx = i;
> > - break;
> > - }
> > -
> > - do_fbcon_takeover(0);
> > - }
> > }
> >
> > static void fbcon_exit(void)
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v2 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> On Tue, Feb 08, 2022 at 02:12:33PM +0200, Jani Nikula wrote:
>> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
>> > On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
>> >> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
>> >> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
>> >> >> +
>> >> >> + if (timeout) {
>> >> >> + intel_dp_dump_link_status(intel_dp,
>> >> >> DP_PHY_DPRX, link_status);
>> >> >> + drm_err(&i915->drm,
>> >> >> + "[ENCODER:%d:%s] Lane channel eq
>> >> >> timeout\n",
>> >> >> + encoder->base.base.id,
>> >> >> encoder->base.name);
>> >> >> + return false;
>> >> >> + }
>> >> >> +
>> >> >> + if (time_after(jiffies, deadline))
>> >> >> + timeout = true; /* try one last time after
>> >> >> deadline */
>> >> >
>> >> > Is there a reason we can't do this just before
>> >> > drm_dp_dpcd_read_link_status()
>> >> > so we don't have to pass the timeout status from one loop iteration to
>> >> > the next?
>> >>
>> >> The point is to check one last time after timeout has passed, like you
>> >> suggested in previous review, and I agreed.
>> >
>> > Sure but why can't it be something more like?
>> >
>> > timeout = time_after();
>> > read_status();
>> > if (bad)
>> >bail;
>> > if (timeout)
>> >bail;
>> >
>> > I think we have it more like that in wait_for()/etc.
>>
>> I was going to fix this, but then realized the "one more time" really
>> only makes sense if it includes updating the signal levels and training
>> set and then checking the status. I don't think there's point in "one
>> more time" only covering the status read.
>
> Hmm. Yeah, I suppose that is true. We can't really know when the sink
> updated the status so checking for the timeout just before that might
> have the same issue as checking entirely after the status check.
>
>>
>> I've got the loop set up such that the flow is natural when entering the
>> loop i.e. I'd rather not have the adjust in the beginning with some if
>> (try != 0) check.
>>
>> Or am I missing something?
>
> Nah. I guess it's best leave it the way you have it now.
Thanks. Sent v3, but realized I'm still missing the intra-hop stuff.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v3] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
The DP 2.0 errata completely overhauls the 128b/132b link training, with
no provisions for backward compatibility with the original DP 2.0
specification.
The changes are too intrusive to consider reusing the same code for both
8b/10b and 128b/132b, mainly because the LTTPR channel equalisation is
done concurrently instead of serialized.
NOTES:
* It's a bit unclear when to wait for DP_INTERLANE_ALIGN_DONE and
per-lane DP_LANE_SYMBOL_LOCKED. Figure xx4 in the SCR implies the
LANEx_CHANNEL_EQ_DONE sequence may end with either 0x77,0x77,0x85 *or*
0x33,0x33,0x84 (for four lane configuration in DPCD 0x202..0x204)
i.e. without the above bits set. Text elsewhere seems contradictory or
incomplete.
* We read entire link status (6 bytes) everywhere instead of individual
DPCD addresses.
* There are some subtle ambiguities or contradictions in the order of
some DPCD access and TPS signal enables/disables. It's also not clear
whether these are significant.
v3:
- Use msecs_to_jiffies_timeout() (Ville)
- Read status at the beginning of interlane align done loop (Ville)
- Try to simplify timeout flag use where possible (Ville)
v2:
- Always try one last time after timeouts to avoid races (Ville)
- Extend timeout to cover the entire LANEx_EQ_DONE sequence (Ville)
- Also check for eq interlane align done in LANEx_CDS_DONE Sequence (Ville)
- Check for Intra-hop status before link training
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_dp_link_training.c | 281 +-
1 file changed, 280 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 4e507aa75a03..17aa5d712389 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -1102,6 +1102,279 @@ intel_dp_link_train_all_phys(struct intel_dp *intel_dp,
return ret;
}
+
+/*
+ * 128b/132b DP LANEx_EQ_DONE Sequence (DP 2.0 E11 3.5.2.16.1)
+ */
+static bool
+intel_dp_128b132b_lane_eq(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ u8 link_status[DP_LINK_STATUS_SIZE];
+ int delay_us;
+ int try, max_tries = 20;
+ unsigned long deadline;
+ bool timeout = false;
+
+ /*
+* Reset signal levels. Start transmitting 128b/132b TPS1.
+*
+* Put DPRX and LTTPRs (if any) into intra-hop AUX mode by writing TPS1
+* in DP_TRAINING_PATTERN_SET.
+*/
+ if (!intel_dp_reset_link_train(intel_dp, crtc_state, DP_PHY_DPRX,
+ DP_TRAINING_PATTERN_1)) {
+ drm_err(&i915->drm,
+ "[ENCODER:%d:%s] Failed to start 128b/132b TPS1\n",
+ encoder->base.base.id, encoder->base.name);
+ return false;
+ }
+
+ delay_us = drm_dp_128b132b_read_aux_rd_interval(&intel_dp->aux);
+
+ /* Read the initial TX FFE settings. */
+ if (drm_dp_dpcd_read_link_status(&intel_dp->aux, link_status) < 0) {
+ drm_err(&i915->drm,
+ "[ENCODER:%d:%s] Failed to read TX FFE presets\n",
+ encoder->base.base.id, encoder->base.name);
+ return false;
+ }
+
+ /* Update signal levels and training set as requested. */
+ intel_dp_get_adjust_train(intel_dp, crtc_state, DP_PHY_DPRX,
link_status);
+ if (!intel_dp_update_link_train(intel_dp, crtc_state, DP_PHY_DPRX)) {
+ drm_err(&i915->drm,
+ "[ENCODER:%d:%s] Failed to set initial TX FFE
settings\n",
+ encoder->base.base.id, encoder->base.name);
+ return false;
+ }
+
+ /* Start transmitting 128b/132b TPS2. */
+ if (!intel_dp_set_link_train(intel_dp, crtc_state, DP_PHY_DPRX,
+DP_TRAINING_PATTERN_2)) {
+ drm_err(&i915->drm,
+ "[ENCODER:%d:%s] Failed to start 128b/132b TPS2\n",
+ encoder->base.base.id, encoder->base.name);
+ return false;
+ }
+
+ /* Time budget for the LANEx_EQ_DONE Sequence */
+ deadline = jiffies + msecs_to_jiffies_timeout(400);
+
+ for (try = 0; try < max_tries; try++) {
+ usleep_range(delay_us, 2 * delay_us);
+
+ /*
+* The delay may get updated. The transmitter shall read the
+* delay before link status during link training.
+*/
+ delay_us = drm_dp_128b132b_read_aux_rd_interval(&intel_dp->aux);
+
+ if (drm_dp_dpcd_read_link_status(&intel_dp->aux, link_status) <
0) {
+ drm_err(&i915->drm,
+
Re: [Intel-gfx] [PATCH v4] dma-buf-map: Rename to iosys-map
On 2/4/22 18:05, Lucas De Marchi wrote: > Rename struct dma_buf_map to struct iosys_map and corresponding APIs. > Over time dma-buf-map grew up to more functionality than the one used by > dma-buf: in fact it's just a shim layer to abstract system memory, that > can be accessed via regular load and store, from IO memory that needs to > be acessed via arch helpers. > > The idea is to extend this API so it can fulfill other needs, internal > to a single driver. Example: in the i915 driver it's desired to share > the implementation for integrated graphics, which uses mostly system > memory, with discrete graphics, which may need to access IO memory. > > The conversion was mostly done with the following semantic patch: > > @r1@ > @@ > - struct dma_buf_map > + struct iosys_map > > @r2@ > @@ > ( > - DMA_BUF_MAP_INIT_VADDR > + IOSYS_MAP_INIT_VADDR > | > - dma_buf_map_set_vaddr > + iosys_map_set_vaddr > | > - dma_buf_map_set_vaddr_iomem > + iosys_map_set_vaddr_iomem > | > - dma_buf_map_is_equal > + iosys_map_is_equal > | > - dma_buf_map_is_null > + iosys_map_is_null > | > - dma_buf_map_is_set > + iosys_map_is_set > | > - dma_buf_map_clear > + iosys_map_clear > | > - dma_buf_map_memcpy_to > + iosys_map_memcpy_to > | > - dma_buf_map_incr > + iosys_map_incr > ) > > @@ > @@ > - #include > + #include > > Then some files had their includes adjusted and some comments were > update to remove mentions to dma-buf-map. > > Since this is not specific to dma-buf anymore, move the documentation to > the "Bus-Independent Device Accesses" section. > > v2: > - Squash patches > > v3: > - Fix wrong removal of dma-buf.h from MAINTAINERS > - Move documentation from dma-buf.rst to device-io.rst > > v4: > - Change documentation tile and level > > Signed-off-by: Lucas De Marchi > Acked-by: Christian König > Acked-by: Sumit Semwal > Acked-by: Thomas Zimmermann > --- > Documentation/driver-api/device-io.rst| 9 + > Documentation/driver-api/dma-buf.rst | 9 - > Documentation/gpu/todo.rst| 20 +- > MAINTAINERS | 9 +- > drivers/dma-buf/dma-buf.c | 22 +- > drivers/dma-buf/heaps/cma_heap.c | 10 +- > drivers/dma-buf/heaps/system_heap.c | 10 +- > drivers/gpu/drm/ast/ast_drv.h | 2 +- > drivers/gpu/drm/ast/ast_mode.c| 8 +- > drivers/gpu/drm/drm_cache.c | 18 +- > drivers/gpu/drm/drm_client.c | 9 +- > drivers/gpu/drm/drm_fb_helper.c | 12 +- > drivers/gpu/drm/drm_gem.c | 12 +- > drivers/gpu/drm/drm_gem_cma_helper.c | 9 +- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +- > drivers/gpu/drm/drm_gem_shmem_helper.c| 15 +- > drivers/gpu/drm/drm_gem_ttm_helper.c | 4 +- > drivers/gpu/drm/drm_gem_vram_helper.c | 25 +- > drivers/gpu/drm/drm_internal.h| 6 +- > drivers/gpu/drm/drm_mipi_dbi.c| 8 +- > drivers/gpu/drm/drm_prime.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +- > drivers/gpu/drm/gud/gud_pipe.c| 4 +- > drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 8 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +- > .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 6 +- > drivers/gpu/drm/lima/lima_gem.c | 3 +- > drivers/gpu/drm/lima/lima_sched.c | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.c| 7 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.h| 5 +- > drivers/gpu/drm/mgag200/mgag200_mode.c| 4 +- > drivers/gpu/drm/msm/msm_drv.h | 4 +- > drivers/gpu/drm/msm/msm_gem_prime.c | 6 +- > drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 13 +- > drivers/gpu/drm/qxl/qxl_display.c | 8 +- > drivers/gpu/drm/qxl/qxl_draw.c| 6 +- > drivers/gpu/drm/qxl/qxl_drv.h | 10 +- > drivers/gpu/drm/qxl/qxl_object.c | 8 +- > drivers/gpu/drm/qxl/qxl_object.h | 4 +- > drivers/gpu/drm/qxl/qxl_prime.c | 4 +- > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +- > drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 5 +- > drivers/gpu/drm/tegra/gem.c | 10 +- > drivers/gpu/drm/tiny/cirrus.c | 8 +- > drivers/gpu/drm/tiny/gm12u320.c | 7 +- > drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +- > drivers/gpu/drm/ttm/ttm_resource.c
Re: [Intel-gfx] [PATCH] drm/buddy: fixup potential uaf
On Tue, Feb 08, 2022 at 11:38:15AM +, Matthew Auld wrote:
> If we are unlucky and somehow can't allocate enough memory when
> splitting blocks, where we temporarily end up with the given block and
> its buddy on the respective free list, then we need to ensure we delete
> both blocks, and not just the buddy, before potentially freeing them.
>
> v2: rebase on i915_buddy removal
>
> Fixes: 14d1b9a6247c ("drm/i915: buddy allocator")
> Signed-off-by: Matthew Auld
> Cc: Arunpravin
> Cc: Christian König
btw wrt fixups, can you pls include the drm_buddy.c kerneldoc into
Documentation/gpu/drm-mm.rst? That seems to be missing. Also probably some
kerneldoc to polish to make it warning free and complete.
-Daniel
> ---
> drivers/gpu/drm/drm_buddy.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
> index d60878bc9c20..2bf75e8abfaa 100644
> --- a/drivers/gpu/drm/drm_buddy.c
> +++ b/drivers/gpu/drm/drm_buddy.c
> @@ -333,8 +333,10 @@ drm_buddy_alloc_blocks(struct drm_buddy *mm, unsigned
> int order)
> return block;
>
> out_free:
> - if (i != order)
> + if (i != order) {
> + list_del(&block->link);
> __drm_buddy_free(mm, block);
> + }
> return ERR_PTR(err);
> }
> EXPORT_SYMBOL(drm_buddy_alloc_blocks);
> @@ -452,8 +454,10 @@ int drm_buddy_alloc_range(struct drm_buddy *mm,
> buddy = get_buddy(block);
> if (buddy &&
> (drm_buddy_block_is_free(block) &&
> - drm_buddy_block_is_free(buddy)))
> + drm_buddy_block_is_free(buddy))) {
> + list_del(&block->link);
> __drm_buddy_free(mm, block);
> + }
>
> err_free:
> drm_buddy_free_list(mm, &allocated);
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH v3] dma-buf-map: Rename to iosys-map
On Thu, Feb 03, 2022 at 12:56:14AM -0800, Lucas De Marchi wrote: > Rename struct dma_buf_map to struct iosys_map and corresponding APIs. > Over time dma-buf-map grew up to more functionality than the one used by > dma-buf: in fact it's just a shim layer to abstract system memory, that > can be accessed via regular load and store, from IO memory that needs to > be acessed via arch helpers. > > The idea is to extend this API so it can fulfill other needs, internal > to a single driver. Example: in the i915 driver it's desired to share > the implementation for integrated graphics, which uses mostly system > memory, with discrete graphics, which may need to access IO memory. > > The conversion was mostly done with the following semantic patch: > > @r1@ > @@ > - struct dma_buf_map > + struct iosys_map > > @r2@ > @@ > ( > - DMA_BUF_MAP_INIT_VADDR > + IOSYS_MAP_INIT_VADDR > | > - dma_buf_map_set_vaddr > + iosys_map_set_vaddr > | > - dma_buf_map_set_vaddr_iomem > + iosys_map_set_vaddr_iomem > | > - dma_buf_map_is_equal > + iosys_map_is_equal > | > - dma_buf_map_is_null > + iosys_map_is_null > | > - dma_buf_map_is_set > + iosys_map_is_set > | > - dma_buf_map_clear > + iosys_map_clear > | > - dma_buf_map_memcpy_to > + iosys_map_memcpy_to > | > - dma_buf_map_incr > + iosys_map_incr > ) > > @@ > @@ > - #include > + #include > > Then some files had their includes adjusted and some comments were update to > remove mentions to dma-buf-map. > > Since this is not specific to dma-buf anymore, move the documentation to > the "Bus-Independent Device Accesses" section. > > v2: > - Squash patches > > v3: > - Fix wrong removal of dma-buf.h from MAINTAINERS > - Move documentation from dma-buf.rst to device-io.rst > > Signed-off-by: Lucas De Marchi > Acked-by: Christian König > Acked-by: Sumit Semwal Acked-by: Daniel Vetter > --- > Documentation/driver-api/device-io.rst| 9 + > Documentation/driver-api/dma-buf.rst | 9 - > Documentation/gpu/todo.rst| 20 +- > MAINTAINERS | 9 +- > drivers/dma-buf/dma-buf.c | 22 +- > drivers/dma-buf/heaps/cma_heap.c | 10 +- > drivers/dma-buf/heaps/system_heap.c | 10 +- > drivers/gpu/drm/ast/ast_drv.h | 2 +- > drivers/gpu/drm/ast/ast_mode.c| 8 +- > drivers/gpu/drm/drm_cache.c | 18 +- > drivers/gpu/drm/drm_client.c | 9 +- > drivers/gpu/drm/drm_fb_helper.c | 12 +- > drivers/gpu/drm/drm_gem.c | 12 +- > drivers/gpu/drm/drm_gem_cma_helper.c | 9 +- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 16 +- > drivers/gpu/drm/drm_gem_shmem_helper.c| 15 +- > drivers/gpu/drm/drm_gem_ttm_helper.c | 4 +- > drivers/gpu/drm/drm_gem_vram_helper.c | 25 +- > drivers/gpu/drm/drm_internal.h| 6 +- > drivers/gpu/drm/drm_mipi_dbi.c| 8 +- > drivers/gpu/drm/drm_prime.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 +- > drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 8 +- > drivers/gpu/drm/gud/gud_pipe.c| 4 +- > drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 5 +- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 8 +- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 6 +- > .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 6 +- > drivers/gpu/drm/lima/lima_gem.c | 3 +- > drivers/gpu/drm/lima/lima_sched.c | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.c| 7 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.h| 5 +- > drivers/gpu/drm/mgag200/mgag200_mode.c| 4 +- > drivers/gpu/drm/msm/msm_drv.h | 4 +- > drivers/gpu/drm/msm/msm_gem_prime.c | 6 +- > drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 13 +- > drivers/gpu/drm/qxl/qxl_display.c | 8 +- > drivers/gpu/drm/qxl/qxl_draw.c| 6 +- > drivers/gpu/drm/qxl/qxl_drv.h | 10 +- > drivers/gpu/drm/qxl/qxl_object.c | 8 +- > drivers/gpu/drm/qxl/qxl_object.h | 4 +- > drivers/gpu/drm/qxl/qxl_prime.c | 4 +- > drivers/gpu/drm/radeon/radeon_gem.c | 1 + > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 9 +- > drivers/gpu/drm/rockchip/rockchip_drm_gem.h | 5 +- > drivers/gpu/drm/tegra/gem.c | 10 +- > drivers/gpu/drm/tiny/cirrus.c | 8 +- > drivers/gpu/drm/tiny/gm12u320.c | 7 +- > drivers/gpu/drm/ttm/ttm_bo_util.c | 16 +- > drivers/gpu/drm/ttm/ttm_resource.c| 26 +- > drivers/gp
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
== Series Details == Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2) URL : https://patchwork.freedesktop.org/series/99711/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11200_full -> Patchwork_22201_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22201_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22201_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22201_full: ### IGT changes ### Possible regressions * igt@perf@non-zero-reason: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl4/igt@p...@non-zero-reason.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-skl4/igt@p...@non-zero-reason.html * igt@syncobj_timeline@invalid-transfer-non-existent-point: - shard-apl: NOTRUN -> [DMESG-WARN][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-apl8/igt@syncobj_timel...@invalid-transfer-non-existent-point.html - shard-iclb: NOTRUN -> [DMESG-WARN][4] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-iclb8/igt@syncobj_timel...@invalid-transfer-non-existent-point.html * igt@syncobj_timeline@transfer-timeline-point: - shard-skl: NOTRUN -> [DMESG-WARN][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-skl10/igt@syncobj_timel...@transfer-timeline-point.html Warnings * igt@gem_exec_balancer@parallel-keep-submit-fence: - shard-iclb: [SKIP][6] ([i915#4525]) -> [DMESG-WARN][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-iclb5/igt@gem_exec_balan...@parallel-keep-submit-fence.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-iclb2/igt@gem_exec_balan...@parallel-keep-submit-fence.html Known issues Here are the changes found in Patchwork_22201_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-skl: NOTRUN -> [DMESG-WARN][8] ([i915#4991]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-skl9/igt@gem_cre...@create-massive.html * igt@gem_ctx_param@set-priority-not-supported: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109314]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-iclb8/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_exec_capture@pi@rcs0: - shard-skl: [PASS][10] -> [INCOMPLETE][11] ([i915#4547]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-skl10/igt@gem_exec_capture@p...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-skl6/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][12] ([i915#2846]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-apl4/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: NOTRUN -> [FAIL][13] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-kbl4/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-tglb2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][16] -> [FAIL][17] ([i915#2842]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_lmem_swapping@heavy-multi: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-apl8/igt@gem_lmem_swapp...@heavy-multi.html - shard-iclb: NOTRUN -> [SKIP][19] ([i915#4613]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/shard-iclb8/igt@gem_lmem_swapp...@heavy-multi.html * igt@gem_lmem_swapping@random: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#4613]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/
Re: [Intel-gfx] [PATCH] drm/i915/psr: Disable PSR2 selective fetch for all TGL steps
On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> As we've unfortunately started to come to expect from PSR on Intel
> platforms, PSR2 selective fetch is not at all ready to be enabled on
> Tigerlake as it results in severe flickering issues - at least on this
> ThinkPad X1 Carbon 9th generation. The easiest way I've found of
> reproducing these issues is to just move the cursor around the left border
> of the screen (suspicious…).
Where is the bug for that? Where is the logs?
We can't go from enabled to disabled without any debug and because of a single
device.
In the mean time you have the option to set the i915 parameter to disable it.
>
> So, fix people's displays again and turn PSR2 selective fetch off for all
> steppings of Tigerlake. This can be re-enabled again if someone from Intel
> finds the time to fix this functionality on OEM machines.
>
> Signed-off-by: Lyude Paul
> Fixes: 7f6002e58025 ("drm/i915/display: Enable PSR2 selective fetch by
> default")
> Cc: Gwan-gyeong Mun
> Cc: Ville Syrjälä
> Cc: José Roberto de Souza
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v5.16+
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a1a663f362e7..25c16abcd9cd 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -737,10 +737,14 @@ static bool intel_psr2_sel_fetch_config_valid(struct
> intel_dp *intel_dp,
> return false;
> }
>
> - /* Wa_14010254185 Wa_14010103792 */
> - if (IS_TGL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_C0)) {
> + /*
> + * There's two things stopping this from being enabled on TGL:
> + * For steps A0-C0: workarounds Wa_14010254185 Wa_14010103792 are
> missing
> + * For all steps: PSR2 selective fetch causes screen flickering
> + */
> + if (IS_TIGERLAKE(dev_priv)) {
> drm_dbg_kms(&dev_priv->drm,
> - "PSR2 sel fetch not enabled, missing the
> implementation of WAs\n");
> + "PSR2 sel fetch not enabled, currently broken on
> TGL\n");
> return false;
> }
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Refactor the display power domain mappings (rev2)
== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev2) URL : https://patchwork.freedesktop.org/series/99476/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22204 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_22204 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_22204, 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_22204/index.html Participating hosts (42 -> 43) -- Additional (4): fi-kbl-soraka bat-jsl-2 fi-pnv-d510 bat-dg1-5 Missing(3): shard-rkl shard-tglu fi-adl-ddr4 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_22204: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-bdw-5557u/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_22204 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_gttfill@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4086]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@gem_exec_gttf...@basic.html * igt@gem_huc_copy@huc-copy: - fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html - fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +57 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-kbl-soraka/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-skl-6600u: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4077]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4079]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#1155]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][13] ([i915#1886] / [i915#2291]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4215]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4212]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22204/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium@dp-edid-read: - fi-kbl-soraka: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_222
Re: [Intel-gfx] [PATCH v2 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
On Tue, Feb 08, 2022 at 02:12:33PM +0200, Jani Nikula wrote:
> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> > On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
> >> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
> >> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
> >> >> +
> >> >> + if (timeout) {
> >> >> + intel_dp_dump_link_status(intel_dp,
> >> >> DP_PHY_DPRX, link_status);
> >> >> + drm_err(&i915->drm,
> >> >> + "[ENCODER:%d:%s] Lane channel eq
> >> >> timeout\n",
> >> >> + encoder->base.base.id,
> >> >> encoder->base.name);
> >> >> + return false;
> >> >> + }
> >> >> +
> >> >> + if (time_after(jiffies, deadline))
> >> >> + timeout = true; /* try one last time after
> >> >> deadline */
> >> >
> >> > Is there a reason we can't do this just before
> >> > drm_dp_dpcd_read_link_status()
> >> > so we don't have to pass the timeout status from one loop iteration to
> >> > the next?
> >>
> >> The point is to check one last time after timeout has passed, like you
> >> suggested in previous review, and I agreed.
> >
> > Sure but why can't it be something more like?
> >
> > timeout = time_after();
> > read_status();
> > if (bad)
> > bail;
> > if (timeout)
> > bail;
> >
> > I think we have it more like that in wait_for()/etc.
>
> I was going to fix this, but then realized the "one more time" really
> only makes sense if it includes updating the signal levels and training
> set and then checking the status. I don't think there's point in "one
> more time" only covering the status read.
Hmm. Yeah, I suppose that is true. We can't really know when the sink
updated the status so checking for the timeout just before that might
have the same issue as checking entirely after the status check.
>
> I've got the loop set up such that the flow is natural when entering the
> loop i.e. I'd rather not have the adjust in the beginning with some if
> (try != 0) check.
>
> Or am I missing something?
Nah. I guess it's best leave it the way you have it now.
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Refactor the display power domain mappings (rev2)
== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev2) URL : https://patchwork.freedesktop.org/series/99476/ 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/i915: Refactor the display power domain mappings (rev2)
== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev2) URL : https://patchwork.freedesktop.org/series/99476/ State : warning == Summary == $ dim checkpatch origin/drm-tip fa34bdc13d82 drm/i915: Fix the VDSC_PW2 power domain enum value 69200c39d539 drm/i915: Sanitize open-coded power well enable()/disable() calls 2436f611541b drm/i915: Remove redundant state verification during TypeC AUX power well disabling 6b279b657486 drm/i915: Move i915_power_well_regs struct into i915_power_well_ops cfc03d647e82 drm/i915: Move power well get/put/enable/disable functions to a new file -:184: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #184: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 308 lines checked ebd42ad72529 drm/i915: Add function to call a power well's sync_hw() hook a952543f918d drm/i915: Add functions to get a power well's state/name/domains/mask/refcount 3d2d49f7eabf drm/i915: Move intel_display_power_well_is_enabled() to intel_display_power_well.c 142e7545b265 drm/i915: Move per-platform power well hooks to intel_display_power_well.c -:2127: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #2127: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:265: + + } -:2337: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.rst #2337: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:475: + msleep(1); -:2342: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.rst #2342: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:480: + msleep(1); -:2663: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #2663: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:801: + DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)), -:2703: WARNING:LONG_LINE: line length of 108 exceeds 100 columns #2703: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:841: + intel_de_read(dev_priv, GEN8_CHICKEN_DCPR_1) | SKL_SELECT_ALTERNATE_DC_EXIT); -:2730: WARNING:LONG_LINE: line length of 108 exceeds 100 columns #2730: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:868: + intel_de_read(dev_priv, GEN8_CHICKEN_DCPR_1) | SKL_SELECT_ALTERNATE_DC_EXIT); -:2832: WARNING:REPEATED_WORD: Possible repeated word: 'power' #2832: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:970: +"Unexpected DBuf power power state (0x%08x, expected 0x%08x)\n", -:2907: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #2907: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:1045: +static bool i9xx_always_on_power_well_enabled(struct drm_i915_private *dev_priv, +struct i915_power_well *power_well) -:3179: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'bits' - possible side-effects? #3179: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:1317: +#define BITS_SET(val, bits) (((val) & (bits)) == (bits)) -:3634: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.rst #3634: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:1772: + msleep(1); -:3680: CHECK:LINE_SPACING: Please don't use multiple blank lines #3680: FILE: drivers/gpu/drm/i915/display/intel_display_power_well.c:1818: + + total: 0 errors, 7 warnings, 4 checks, 3827 lines checked c54451a78f9e drm/i915: Unexport the for_each_power_well() macros -:19: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #19: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:21: +#define for_each_power_domain_well(__dev_priv, __power_well, __domain_mask) \ + for_each_power_well(__dev_priv, __power_well) \ + for_each_if((__power_well)->desc->domains & (__domain_mask)) -:19: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__power_well' - possible side-effects? #19: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:21: +#define for_each_power_domain_well(__dev_priv, __power_well, __domain_mask) \ + for_each_power_well(__dev_priv, __power_well) \ + for_each_if((__power_well)->desc->domains & (__domain_mask)) -:23: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #23: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:25: +#define for_each_power_domain_well_reverse(__dev_priv, __power_well, __domain_mask) \ + for_each_power_well_reverse(__dev_priv, __power_well) \ + for_each_if((__power_well)->desc->domains & (__domain_mask)) -:23: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__power_well' - pos
[Intel-gfx] ✓ Fi.CI.BAT: success for GuC HWCONFIG with documentation (rev2)
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22202
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/index.html
Participating hosts (42 -> 45)
--
Additional (5): fi-kbl-soraka bat-dg1-5 fi-icl-u2 fi-pnv-d510 bat-jsl-2
Missing(2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_22202:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_hangman@error-state-basic:
- {bat-adlp-6}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/bat-adlp-6/igt@i915_hang...@error-state-basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/bat-adlp-6/igt@i915_hang...@error-state-basic.html
Known issues
Here are the changes found in Patchwork_22202 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_22202/fi-blb-e6850/igt@amdgpu/amd_cs_...@fork-compute0.html
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][4] ([fdo#109315]) +17 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271]) +8 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_exec_gttfill@basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4086])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/bat-dg1-5/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html
- fi-pnv-d510:NOTRUN -> [SKIP][8] ([fdo#109271]) +39 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-pnv-d510/igt@gem_huc_c...@huc-copy.html
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][10] ([i915#2190])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][11] ([i915#4613]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-kbl-soraka/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-skl-6600u/igt@gem_lmem_swapp...@verify-random.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4083])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_mmap_gtt@basic:
- bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#4077]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/bat-dg1-5/igt@gem_mmap_...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#4079]) +1 similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#1155])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][18] ([i915#1886] / [i915#2291])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22202/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: NOTRUN -> [DMESG-FAIL][19] ([i915#4494] / [i915#4957])
[19]:
https://intel-gfx-ci.01.
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v6,1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API
== Series Details == Series: series starting with [v6,1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API URL : https://patchwork.freedesktop.org/series/99838/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_gvt_mmio_table.o drivers/gpu/drm/i915/intel_gvt_mmio_table.c: In function ‘iterate_generic_mmio’: drivers/gpu/drm/i915/intel_gvt_mmio_table.c:65:16: error: ‘RENDER_RING_BASE’ undeclared (first use in this function); did you mean ‘IDR_INIT_BASE’? MMIO_F(prefix(RENDER_RING_BASE), s, d); \ ^~~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:54:57: note: in definition of macro ‘MMIO_F’ ret = iter->handle_mmio_cb(iter, i915_mmio_reg_offset(reg), \ ^~~ ./drivers/gpu/drm/i915/gt/intel_engine_regs.h:73:27: note: in expansion of macro ‘_MMIO’ #define RING_IMR(base)_MMIO((base) + 0xa8) ^ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:65:9: note: in expansion of macro ‘RING_IMR’ MMIO_F(prefix(RENDER_RING_BASE), s, d); \ ^~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:74:2: note: in expansion of macro ‘MMIO_RING_F’ MMIO_RING_F(prefix, 4, d) ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:81:2: note: in expansion of macro ‘MMIO_RING_D’ MMIO_RING_D(RING_IMR, D_ALL); ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:65:16: note: each undeclared identifier is reported only once for each function it appears in MMIO_F(prefix(RENDER_RING_BASE), s, d); \ ^~~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:54:57: note: in definition of macro ‘MMIO_F’ ret = iter->handle_mmio_cb(iter, i915_mmio_reg_offset(reg), \ ^~~ ./drivers/gpu/drm/i915/gt/intel_engine_regs.h:73:27: note: in expansion of macro ‘_MMIO’ #define RING_IMR(base)_MMIO((base) + 0xa8) ^ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:65:9: note: in expansion of macro ‘RING_IMR’ MMIO_F(prefix(RENDER_RING_BASE), s, d); \ ^~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:74:2: note: in expansion of macro ‘MMIO_RING_F’ MMIO_RING_F(prefix, 4, d) ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:81:2: note: in expansion of macro ‘MMIO_RING_D’ MMIO_RING_D(RING_IMR, D_ALL); ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:66:16: error: ‘BLT_RING_BASE’ undeclared (first use in this function); did you mean ‘CTX_RING_TAIL’? MMIO_F(prefix(BLT_RING_BASE), s, d); \ ^ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:54:57: note: in definition of macro ‘MMIO_F’ ret = iter->handle_mmio_cb(iter, i915_mmio_reg_offset(reg), \ ^~~ ./drivers/gpu/drm/i915/gt/intel_engine_regs.h:73:27: note: in expansion of macro ‘_MMIO’ #define RING_IMR(base)_MMIO((base) + 0xa8) ^ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:66:9: note: in expansion of macro ‘RING_IMR’ MMIO_F(prefix(BLT_RING_BASE), s, d); \ ^~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:74:2: note: in expansion of macro ‘MMIO_RING_F’ MMIO_RING_F(prefix, 4, d) ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:81:2: note: in expansion of macro ‘MMIO_RING_D’ MMIO_RING_D(RING_IMR, D_ALL); ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:67:16: error: ‘GEN6_BSD_RING_BASE’ undeclared (first use in this function); did you mean ‘GEN8_CSB_PTR_MASK’? MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d); \ ^~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:54:57: note: in definition of macro ‘MMIO_F’ ret = iter->handle_mmio_cb(iter, i915_mmio_reg_offset(reg), \ ^~~ ./drivers/gpu/drm/i915/gt/intel_engine_regs.h:73:27: note: in expansion of macro ‘_MMIO’ #define RING_IMR(base)_MMIO((base) + 0xa8) ^ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:67:9: note: in expansion of macro ‘RING_IMR’ MMIO_F(prefix(GEN6_BSD_RING_BASE), s, d); \ ^~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:74:2: note: in expansion of macro ‘MMIO_RING_F’ MMIO_RING_F(prefix, 4, d) ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:81:2: note: in expansion of macro ‘MMIO_RING_D’ MMIO_RING_D(RING_IMR, D_ALL); ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:68:16: error: ‘VEBOX_RING_BASE’ undeclared (first use in this function); did you mean ‘CTX_RING_TAIL’? MMIO_F(prefix(VEBOX_RING_BASE), s, d); \ ^~~ drivers/gpu/drm/i915/intel_gvt_mmio_table.c:54:57: note: in definition of macro ‘MMIO_F’ ret = iter->handle_mmio_cb(iter, i915_mmio_reg_offset(reg), \
Re: [Intel-gfx] [PATCH v2 5/8] drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata
On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
>> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
>> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
>> >> +
>> >> + if (timeout) {
>> >> + intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX,
>> >> link_status);
>> >> + drm_err(&i915->drm,
>> >> + "[ENCODER:%d:%s] Lane channel eq timeout\n",
>> >> + encoder->base.base.id, encoder->base.name);
>> >> + return false;
>> >> + }
>> >> +
>> >> + if (time_after(jiffies, deadline))
>> >> + timeout = true; /* try one last time after deadline */
>> >
>> > Is there a reason we can't do this just before
>> > drm_dp_dpcd_read_link_status()
>> > so we don't have to pass the timeout status from one loop iteration to
>> > the next?
>>
>> The point is to check one last time after timeout has passed, like you
>> suggested in previous review, and I agreed.
>
> Sure but why can't it be something more like?
>
> timeout = time_after();
> read_status();
> if (bad)
> bail;
> if (timeout)
> bail;
>
> I think we have it more like that in wait_for()/etc.
I was going to fix this, but then realized the "one more time" really
only makes sense if it includes updating the signal levels and training
set and then checking the status. I don't think there's point in "one
more time" only covering the status read.
I've got the loop set up such that the flow is natural when entering the
loop i.e. I'd rather not have the adjust in the beginning with some if
(try != 0) check.
Or am I missing something?
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GuC HWCONFIG with documentation (rev2)
== Series Details == Series: GuC HWCONFIG with documentation (rev2) URL : https://patchwork.freedesktop.org/series/99787/ 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 GuC HWCONFIG with documentation (rev2)
== Series Details == Series: GuC HWCONFIG with documentation (rev2) URL : https://patchwork.freedesktop.org/series/99787/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0d55eb6c8da5 drm/i915/guc: Add fetch of hwconfig table -:78: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #78: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 227 lines checked a35c6a38af41 drm/i915/uapi: Add query for hwconfig blob 74d623c301f6 drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item 106e8c86e1d3 drm/i915/guc: Verify hwconfig blob matches supported format -:30: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!hwconfig->ptr" #30: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:79: + if (hwconfig->size % 4 != 0 || hwconfig->ptr == NULL) total: 0 errors, 0 warnings, 1 checks, 41 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
== Series Details == Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2) URL : https://patchwork.freedesktop.org/series/99711/ State : success == Summary == CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22201 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/index.html Participating hosts (42 -> 43) -- Additional (3): fi-kbl-soraka bat-jsl-2 bat-dg1-5 Missing(2): shard-rkl shard-tglu Known issues Here are the changes found in Patchwork_22201 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_22201/fi-blb-e6850/igt@amdgpu/amd_cs_...@fork-compute0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +8 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_gttfill@basic: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#4086]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [PASS][4] -> [INCOMPLETE][5] ([i915#146]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_flink_basic@bad-flink: - fi-skl-6600u: NOTRUN -> [INCOMPLETE][6] ([i915#4547]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-skl-6600u/igt@gem_flink_ba...@bad-flink.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-kbl-soraka/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4083]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4077]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@gem_mmap_...@basic.html * igt@gem_tiled_pread_basic: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4079]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#1155]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][13] ([i915#1886] / [i915#2291]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: NOTRUN -> [DMESG-FAIL][14] ([i915#4494] / [i915#4957]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html - fi-hsw-4770:[PASS][15] -> [INCOMPLETE][16] ([i915#4785]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11200/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#4215]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#4212]) +7 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium@dp-edid-read: - fi-kbl-soraka: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +8 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/fi-kbl-soraka/igt@kms_chamel...@dp-edid-read.html * igt@kms_chamelium@dp-hpd-fast: - bat-dg1-5: NOTRUN -> [SKIP][20] ([fdo#111827]) +8 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22201/bat-
[Intel-gfx] [PATCH] drm/buddy: fixup potential uaf
If we are unlucky and somehow can't allocate enough memory when
splitting blocks, where we temporarily end up with the given block and
its buddy on the respective free list, then we need to ensure we delete
both blocks, and not just the buddy, before potentially freeing them.
v2: rebase on i915_buddy removal
Fixes: 14d1b9a6247c ("drm/i915: buddy allocator")
Signed-off-by: Matthew Auld
Cc: Arunpravin
Cc: Christian König
---
drivers/gpu/drm/drm_buddy.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index d60878bc9c20..2bf75e8abfaa 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -333,8 +333,10 @@ drm_buddy_alloc_blocks(struct drm_buddy *mm, unsigned int
order)
return block;
out_free:
- if (i != order)
+ if (i != order) {
+ list_del(&block->link);
__drm_buddy_free(mm, block);
+ }
return ERR_PTR(err);
}
EXPORT_SYMBOL(drm_buddy_alloc_blocks);
@@ -452,8 +454,10 @@ int drm_buddy_alloc_range(struct drm_buddy *mm,
buddy = get_buddy(block);
if (buddy &&
(drm_buddy_block_is_free(block) &&
-drm_buddy_block_is_free(buddy)))
+drm_buddy_block_is_free(buddy))) {
+ list_del(&block->link);
__drm_buddy_free(mm, block);
+ }
err_free:
drm_buddy_free_list(mm, &allocated);
--
2.34.1
[Intel-gfx] [PATCH v2 21/26] drm/i915: Sanitize the ADL-S power well definition
Instead of the skip_mask special casing of the ADL-S power well
descriptors, add a power well descriptor list for ADL-S as well reusing
the TGL descriptors, w/o the TC-cold power well. ADL-S doesn't have
TypeC PHYs, so a better way would be having ADL-S specific AUX
descriptors, but I left changing this for a follow-up.
This changes the ordering of the AUX and TC-cold vs. PW_4/5 power wells
on TGL and ADL-S, but this shouldn't make a difference (PW_4/5 don't
depend on the AUX/TC-cold power wells).
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 69 +++
1 file changed, 39 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 42fbea02770fe..c4f7ff3bcc3dc 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -902,12 +902,36 @@ static const struct i915_power_well_desc
tgl_power_wells_main[] = {
),
.ops = &icl_ddi_power_well_ops,
}, {
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("PW_4", &tgl_pwdoms_pw_4,
+ .hsw.idx = ICL_PW_CTL_IDX_PW_4),
+ ),
+ .ops = &hsw_power_well_ops,
+ .has_fuses = true,
+ .irq_pipe_mask = BIT(PIPE_C),
+ }, {
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("PW_5", &tgl_pwdoms_pw_5,
+ .hsw.idx = TGL_PW_CTL_IDX_PW_5),
+ ),
+ .ops = &hsw_power_well_ops,
+ .has_fuses = true,
+ .irq_pipe_mask = BIT(PIPE_D),
+ },
+};
+
+static const struct i915_power_well_desc tgl_power_wells_tc_cold_off[] = {
+ {
.instances = &I915_PW_INSTANCES(
I915_PW("TC_cold_off", &tgl_pwdoms_tc_cold_off,
.id = TGL_DISP_PW_TC_COLD_OFF),
),
.ops = &tgl_tc_cold_off_ops,
- }, {
+ },
+};
+
+static const struct i915_power_well_desc tgl_power_wells_aux[] = {
+ {
.instances = &I915_PW_INSTANCES(
I915_PW("AUX_A", &tgl_pwdoms_aux_a, .hsw.idx =
ICL_PW_CTL_IDX_AUX_A),
I915_PW("AUX_B", &tgl_pwdoms_aux_b, .hsw.idx =
ICL_PW_CTL_IDX_AUX_B),
@@ -931,22 +955,6 @@ static const struct i915_power_well_desc
tgl_power_wells_main[] = {
),
.ops = &icl_aux_power_well_ops,
.is_tc_tbt = true,
- }, {
- .instances = &I915_PW_INSTANCES(
- I915_PW("PW_4", &tgl_pwdoms_pw_4,
- .hsw.idx = ICL_PW_CTL_IDX_PW_4),
- ),
- .ops = &hsw_power_well_ops,
- .has_fuses = true,
- .irq_pipe_mask = BIT(PIPE_C),
- }, {
- .instances = &I915_PW_INSTANCES(
- I915_PW("PW_5", &tgl_pwdoms_pw_5,
- .hsw.idx = TGL_PW_CTL_IDX_PW_5),
- ),
- .ops = &hsw_power_well_ops,
- .has_fuses = true,
- .irq_pipe_mask = BIT(PIPE_D),
},
};
@@ -954,6 +962,15 @@ static const struct i915_power_well_desc_list
tgl_power_wells[] = {
I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
I915_PW_DESCRIPTORS(tgl_power_wells_main),
+ I915_PW_DESCRIPTORS(tgl_power_wells_tc_cold_off),
+ I915_PW_DESCRIPTORS(tgl_power_wells_aux),
+};
+
+static const struct i915_power_well_desc_list adls_power_wells[] = {
+ I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
+ I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
+ I915_PW_DESCRIPTORS(tgl_power_wells_main),
+ I915_PW_DESCRIPTORS(tgl_power_wells_aux),
};
#define RKL_PW_4_POWER_DOMAINS \
@@ -1400,7 +1417,7 @@ static void init_power_well_domains(const struct
i915_power_well_instance *inst,
static int
__set_power_wells(struct i915_power_domains *power_domains,
const struct i915_power_well_desc_list *power_well_descs,
- int power_well_descs_sz, u64 skip_mask)
+ int power_well_descs_sz)
{
struct drm_i915_private *i915 = container_of(power_domains,
struct drm_i915_private,
@@ -1413,8 +1430,7 @@ __set_power_wells(struct i915_power_domains
*power_domains,
int plt_idx = 0;
for_each_power_well_instance(power_well_descs, power_well_descs_sz,
desc_list, desc, inst)
- if (!(BIT_ULL(inst->id) & skip_mask))
- power_well_count++;
+ power_well_count++;
power_domains->power_well_count = power_well_count;
power_domains->power_wells =
@@ -1428,9 +1444,6 @@ __set_power_wells(
[Intel-gfx] [PATCH v2 26/26] drm/i915: Remove the XELPD specific AUX and DDI power domains
The spec calls the XELPD_D/E ports just D/E, the platform prefix in the
domain names was only needed by the port->domain mapping relying on
matching enum values for the whole port/domain range (and the
corresponding aliasing between the platform specific domain enums).
Since a previous patch we can define the port->domain mapping explicitly
so do this by reusing the already existing D/E power domain names.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_power.c| 18 +++
.../drm/i915/display/intel_display_power.h| 9
.../i915/display/intel_display_power_map.c| 22 +++
3 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0cadcf98a0f9e..65e22a717cd8d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -89,10 +89,6 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "PORT_DDI_LANES_TC5";
case POWER_DOMAIN_PORT_DDI_LANES_TC6:
return "PORT_DDI_LANES_TC6";
- case POWER_DOMAIN_PORT_DDI_LANES_D_XELPD:
- return "PORT_DDI_LANES_D_XELPD";
- case POWER_DOMAIN_PORT_DDI_LANES_E_XELPD:
- return "PORT_DDI_LANES_E_XELPD";
case POWER_DOMAIN_PORT_DDI_IO_A:
return "PORT_DDI_IO_A";
case POWER_DOMAIN_PORT_DDI_IO_B:
@@ -117,10 +113,6 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "PORT_DDI_IO_TC5";
case POWER_DOMAIN_PORT_DDI_IO_TC6:
return "PORT_DDI_IO_TC6";
- case POWER_DOMAIN_PORT_DDI_IO_D_XELPD:
- return "PORT_DDI_IO_D_XELPD";
- case POWER_DOMAIN_PORT_DDI_IO_E_XELPD:
- return "PORT_DDI_IO_E_XELPD";
case POWER_DOMAIN_PORT_DSI:
return "PORT_DSI";
case POWER_DOMAIN_PORT_CRT:
@@ -157,10 +149,6 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "AUX_USBC5";
case POWER_DOMAIN_AUX_USBC6:
return "AUX_USBC6";
- case POWER_DOMAIN_AUX_D_XELPD:
- return "AUX_D_XELPD";
- case POWER_DOMAIN_AUX_E_XELPD:
- return "AUX_E_XELPD";
case POWER_DOMAIN_AUX_IO_A:
return "AUX_IO_A";
case POWER_DOMAIN_AUX_TBT1:
@@ -2387,9 +2375,9 @@ d13_port_domains[] = {
.aux_ch_start = AUX_CH_D_XELPD,
.aux_ch_end = AUX_CH_E_XELPD,
- .ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_D_XELPD,
- .ddi_io = POWER_DOMAIN_PORT_DDI_IO_D_XELPD,
- .aux_legacy_usbc = POWER_DOMAIN_AUX_D_XELPD,
+ .ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_D,
+ .ddi_io = POWER_DOMAIN_PORT_DDI_IO_D,
+ .aux_legacy_usbc = POWER_DOMAIN_AUX_D,
.aux_tbt = POWER_DOMAIN_INVALID,
},
};
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 3347eaeb22e15..f2d488d5ba4b7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -56,9 +56,6 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_LANES_TC5,
POWER_DOMAIN_PORT_DDI_LANES_TC6,
- POWER_DOMAIN_PORT_DDI_LANES_D_XELPD,
- POWER_DOMAIN_PORT_DDI_LANES_E_XELPD,
-
POWER_DOMAIN_PORT_DDI_IO_A,
POWER_DOMAIN_PORT_DDI_IO_B,
POWER_DOMAIN_PORT_DDI_IO_C,
@@ -73,9 +70,6 @@ enum intel_display_power_domain {
POWER_DOMAIN_PORT_DDI_IO_TC5,
POWER_DOMAIN_PORT_DDI_IO_TC6,
- POWER_DOMAIN_PORT_DDI_IO_D_XELPD,
- POWER_DOMAIN_PORT_DDI_IO_E_XELPD,
-
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_PORT_CRT,
POWER_DOMAIN_PORT_OTHER,
@@ -96,9 +90,6 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_USBC5,
POWER_DOMAIN_AUX_USBC6,
- POWER_DOMAIN_AUX_D_XELPD,
- POWER_DOMAIN_AUX_E_XELPD,
-
POWER_DOMAIN_AUX_IO_A,
POWER_DOMAIN_AUX_TBT1,
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index dce34a5b49f32..f2f899ad5c4a5 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1207,8 +1207,8 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_a,
XELPD_PW_C_POWER_DOMAINS, \
XELPD_PW_D_POWER_DOMAINS, \
POWER_DOMAIN_PORT_DDI_LANES_C, \
- POWER_DOMAIN_PORT_DDI_LANES_D_XELPD, \
- POWER_DOMAIN_PORT_DDI_LANES_E_XELPD, \
+ POWER_DOMAIN_PORT_DDI_LANES_D, \
+ POWER_DOMAIN_PORT_DDI_LANES_E, \
POWER_DOMAIN_PORT_DDI_LANES_TC1, \
POWER_DOMAIN_PORT_DDI_LANES_TC2, \
POWER_DOMAIN_PORT_DDI_LANES_TC3, \
@@
[Intel-gfx] [PATCH v2 23/26] drm/i915: Remove the aliasing of power domain enum values
Aliasing the intel_display_power_domain enum values was required because of the u64 power domain mask size limit. This makes the dmesg/debugfs printouts of the domain names somewhat unclear, for instance domain names for port D are shown on D12+ platforms where the corresponding port is called TC1. Make this clearer by removing the aliasing which is possible after a previous patch converting the mask to a bitmap. Signed-off-by: Imre Deak --- .../drm/i915/display/intel_display_power.c| 84 +-- .../drm/i915/display/intel_display_power.h| 26 ++ 2 files changed, 67 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 2816c3b1faef0..f6a6e15eca9b1 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -77,12 +77,22 @@ intel_display_power_domain_str(enum intel_display_power_domain domain) return "PORT_DDI_LANES_E"; case POWER_DOMAIN_PORT_DDI_LANES_F: return "PORT_DDI_LANES_F"; - case POWER_DOMAIN_PORT_DDI_LANES_G: - return "PORT_DDI_LANES_G"; - case POWER_DOMAIN_PORT_DDI_LANES_H: - return "PORT_DDI_LANES_H"; - case POWER_DOMAIN_PORT_DDI_LANES_I: - return "PORT_DDI_LANES_I"; + case POWER_DOMAIN_PORT_DDI_LANES_TC1: + return "PORT_DDI_LANES_TC1"; + case POWER_DOMAIN_PORT_DDI_LANES_TC2: + return "PORT_DDI_LANES_TC2"; + case POWER_DOMAIN_PORT_DDI_LANES_TC3: + return "PORT_DDI_LANES_TC3"; + case POWER_DOMAIN_PORT_DDI_LANES_TC4: + return "PORT_DDI_LANES_TC4"; + case POWER_DOMAIN_PORT_DDI_LANES_TC5: + return "PORT_DDI_LANES_TC5"; + case POWER_DOMAIN_PORT_DDI_LANES_TC6: + return "PORT_DDI_LANES_TC6"; + case POWER_DOMAIN_PORT_DDI_LANES_D_XELPD: + return "PORT_DDI_LANES_D_XELPD"; + case POWER_DOMAIN_PORT_DDI_LANES_E_XELPD: + return "PORT_DDI_LANES_E_XELPD"; case POWER_DOMAIN_PORT_DDI_IO_A: return "PORT_DDI_IO_A"; case POWER_DOMAIN_PORT_DDI_IO_B: @@ -95,12 +105,22 @@ intel_display_power_domain_str(enum intel_display_power_domain domain) return "PORT_DDI_IO_E"; case POWER_DOMAIN_PORT_DDI_IO_F: return "PORT_DDI_IO_F"; - case POWER_DOMAIN_PORT_DDI_IO_G: - return "PORT_DDI_IO_G"; - case POWER_DOMAIN_PORT_DDI_IO_H: - return "PORT_DDI_IO_H"; - case POWER_DOMAIN_PORT_DDI_IO_I: - return "PORT_DDI_IO_I"; + case POWER_DOMAIN_PORT_DDI_IO_TC1: + return "PORT_DDI_IO_TC1"; + case POWER_DOMAIN_PORT_DDI_IO_TC2: + return "PORT_DDI_IO_TC2"; + case POWER_DOMAIN_PORT_DDI_IO_TC3: + return "PORT_DDI_IO_TC3"; + case POWER_DOMAIN_PORT_DDI_IO_TC4: + return "PORT_DDI_IO_TC4"; + case POWER_DOMAIN_PORT_DDI_IO_TC5: + return "PORT_DDI_IO_TC5"; + case POWER_DOMAIN_PORT_DDI_IO_TC6: + return "PORT_DDI_IO_TC6"; + case POWER_DOMAIN_PORT_DDI_IO_D_XELPD: + return "PORT_DDI_IO_D_XELPD"; + case POWER_DOMAIN_PORT_DDI_IO_E_XELPD: + return "PORT_DDI_IO_E_XELPD"; case POWER_DOMAIN_PORT_DSI: return "PORT_DSI"; case POWER_DOMAIN_PORT_CRT: @@ -125,12 +145,22 @@ intel_display_power_domain_str(enum intel_display_power_domain domain) return "AUX_E"; case POWER_DOMAIN_AUX_F: return "AUX_F"; - case POWER_DOMAIN_AUX_G: - return "AUX_G"; - case POWER_DOMAIN_AUX_H: - return "AUX_H"; - case POWER_DOMAIN_AUX_I: - return "AUX_I"; + case POWER_DOMAIN_AUX_USBC1: + return "AUX_USBC1"; + case POWER_DOMAIN_AUX_USBC2: + return "AUX_USBC2"; + case POWER_DOMAIN_AUX_USBC3: + return "AUX_USBC3"; + case POWER_DOMAIN_AUX_USBC4: + return "AUX_USBC4"; + case POWER_DOMAIN_AUX_USBC5: + return "AUX_USBC5"; + case POWER_DOMAIN_AUX_USBC6: + return "AUX_USBC6"; + case POWER_DOMAIN_AUX_D_XELPD: + return "AUX_D_XELPD"; + case POWER_DOMAIN_AUX_E_XELPD: + return "AUX_E_XELPD"; case POWER_DOMAIN_AUX_IO_A: return "AUX_IO_A"; case POWER_DOMAIN_AUX_TBT_C: @@ -141,12 +171,18 @@ intel_display_power_domain_str(enum intel_display_power_domain domain) return "AUX_TBT_E"; case POWER_DOMAIN_AUX_TBT_F: return "AUX_TBT_F"; - case POWER_DOMAIN_AUX_TBT_G: - return "AUX_TBT_G"; - case POWER_DOMAIN_AUX_TBT_H: - return "AUX_TBT_H"; - case POWER_DOMAIN_AUX_TBT_I: -
[Intel-gfx] [PATCH v2 24/26] drm/i915: Remove the ICL specific TBT power domains
The spec calls the ICL TBT AUX power well instances TBT1-4 (similarly to
all later platforms), align the power domain names with the spec.
Signed-off-by: Imre Deak
---
.../gpu/drm/i915/display/intel_display_power.c | 10 +-
.../gpu/drm/i915/display/intel_display_power.h | 4
.../drm/i915/display/intel_display_power_map.c | 16
3 files changed, 9 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index f6a6e15eca9b1..0cadcf98a0f9e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -163,14 +163,6 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "AUX_E_XELPD";
case POWER_DOMAIN_AUX_IO_A:
return "AUX_IO_A";
- case POWER_DOMAIN_AUX_TBT_C:
- return "AUX_TBT_C";
- case POWER_DOMAIN_AUX_TBT_D:
- return "AUX_TBT_D";
- case POWER_DOMAIN_AUX_TBT_E:
- return "AUX_TBT_E";
- case POWER_DOMAIN_AUX_TBT_F:
- return "AUX_TBT_F";
case POWER_DOMAIN_AUX_TBT1:
return "AUX_TBT1";
case POWER_DOMAIN_AUX_TBT2:
@@ -2338,7 +2330,7 @@ d11_port_domains[] = {
.ddi_lanes = POWER_DOMAIN_PORT_DDI_LANES_C,
.ddi_io = POWER_DOMAIN_PORT_DDI_IO_C,
.aux_legacy_usbc = POWER_DOMAIN_AUX_C,
- .aux_tbt = POWER_DOMAIN_AUX_TBT_C,
+ .aux_tbt = POWER_DOMAIN_AUX_TBT1,
},
};
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 3c555cb05c9c6..3347eaeb22e15 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -100,10 +100,6 @@ enum intel_display_power_domain {
POWER_DOMAIN_AUX_E_XELPD,
POWER_DOMAIN_AUX_IO_A,
- POWER_DOMAIN_AUX_TBT_C,
- POWER_DOMAIN_AUX_TBT_D,
- POWER_DOMAIN_AUX_TBT_E,
- POWER_DOMAIN_AUX_TBT_F,
POWER_DOMAIN_AUX_TBT1,
POWER_DOMAIN_AUX_TBT2,
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index c4f7ff3bcc3dc..4c7def498dd6f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -622,10 +622,10 @@ I915_DECL_PW_DOMAINS(icl_pwdoms_pw_4,
POWER_DOMAIN_AUX_D, \
POWER_DOMAIN_AUX_E, \
POWER_DOMAIN_AUX_F, \
- POWER_DOMAIN_AUX_TBT_C, \
- POWER_DOMAIN_AUX_TBT_D, \
- POWER_DOMAIN_AUX_TBT_E, \
- POWER_DOMAIN_AUX_TBT_F
+ POWER_DOMAIN_AUX_TBT1, \
+ POWER_DOMAIN_AUX_TBT2, \
+ POWER_DOMAIN_AUX_TBT3, \
+ POWER_DOMAIN_AUX_TBT4
I915_DECL_PW_DOMAINS(icl_pwdoms_pw_3,
ICL_PW_3_POWER_DOMAINS,
@@ -668,10 +668,10 @@ I915_DECL_PW_DOMAINS(icl_pwdoms_aux_c,
POWER_DOMAIN_AUX_C);
I915_DECL_PW_DOMAINS(icl_pwdoms_aux_d, POWER_DOMAIN_AUX_D);
I915_DECL_PW_DOMAINS(icl_pwdoms_aux_e, POWER_DOMAIN_AUX_E);
I915_DECL_PW_DOMAINS(icl_pwdoms_aux_f, POWER_DOMAIN_AUX_F);
-I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt1, POWER_DOMAIN_AUX_TBT_C);
-I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt2, POWER_DOMAIN_AUX_TBT_D);
-I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt3, POWER_DOMAIN_AUX_TBT_E);
-I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt4, POWER_DOMAIN_AUX_TBT_F);
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt1, POWER_DOMAIN_AUX_TBT1);
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt2, POWER_DOMAIN_AUX_TBT2);
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt3, POWER_DOMAIN_AUX_TBT3);
+I915_DECL_PW_DOMAINS(icl_pwdoms_aux_tbt4, POWER_DOMAIN_AUX_TBT4);
static const struct i915_power_well_desc icl_power_wells_pw_1[] = {
{
--
2.27.0
[Intel-gfx] [PATCH v2 22/26] drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platform
Atm the port -> DDI and AUX power domain mapping is specified by relying
on the aliasing of the platform specific intel_display_power_domain enum
values. For instance D12+ platforms refer to the 'D' port and power
domain instances, which doesn't match the bspec terminology, on these
platforms the corresponding port is TC1. To make it clear what
port/domain the code refers to add a mapping between them which matches
the bspec terms on different display versions.
This also allows for removing the aliasing in enum values in a follow-up
patch.
v2: Add the functions to intel_display_power.c, use
intel_display_power_ prefix.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/g4x_dp.c | 3 +-
drivers/gpu/drm/i915/display/g4x_hdmi.c | 3 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.c | 85 +---
drivers/gpu/drm/i915/display/intel_display.h | 4 +-
.../drm/i915/display/intel_display_power.c| 206 ++
.../drm/i915/display/intel_display_power.h| 12 +
drivers/gpu/drm/i915/display/intel_tc.c | 5 +-
8 files changed, 235 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index f67bbaaad8e07..b92a0ade9c394 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -11,6 +11,7 @@
#include "intel_connector.h"
#include "intel_crtc.h"
#include "intel_de.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_dp_link_training.h"
@@ -1402,7 +1403,7 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
dig_port->max_lanes = 4;
intel_encoder->type = INTEL_OUTPUT_DP;
- intel_encoder->power_domain = intel_port_to_power_domain(port);
+ intel_encoder->power_domain =
intel_display_power_ddi_lanes_domain(dev_priv, port);
if (IS_CHERRYVIEW(dev_priv)) {
if (port == PORT_D)
intel_encoder->pipe_mask = BIT(PIPE_C);
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 06e00b1eaa7ce..56fa6dfba020c 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -10,6 +10,7 @@
#include "intel_connector.h"
#include "intel_crtc.h"
#include "intel_de.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dpio_phy.h"
#include "intel_fifo_underrun.h"
@@ -588,7 +589,7 @@ void g4x_hdmi_init(struct drm_i915_private *dev_priv,
intel_encoder->shutdown = intel_hdmi_encoder_shutdown;
intel_encoder->type = INTEL_OUTPUT_HDMI;
- intel_encoder->power_domain = intel_port_to_power_domain(port);
+ intel_encoder->power_domain =
intel_display_power_ddi_lanes_domain(dev_priv, port);
intel_encoder->port = port;
if (IS_CHERRYVIEW(dev_priv)) {
if (port == PORT_D)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a4784f98d7d37..f8cc0f49eddc7 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -38,6 +38,7 @@
#include "intel_ddi.h"
#include "intel_ddi_buf_trans.h"
#include "intel_de.h"
+#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_dp_link_training.h"
@@ -4349,7 +4350,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder->get_power_domains = intel_ddi_get_power_domains;
encoder->type = INTEL_OUTPUT_DDI;
- encoder->power_domain = intel_port_to_power_domain(port);
+ encoder->power_domain = intel_display_power_ddi_lanes_domain(dev_priv,
port);
encoder->port = port;
encoder->cloneable = 0;
encoder->pipe_mask = ~0;
@@ -4477,8 +4478,7 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
}
drm_WARN_ON(&dev_priv->drm, port > PORT_I);
- dig_port->ddi_io_power_domain = POWER_DOMAIN_PORT_DDI_IO_A +
- port - PORT_A;
+ dig_port->ddi_io_power_domain =
intel_display_power_ddi_io_domain(dev_priv, port);
if (init_dp) {
if (!intel_ddi_init_dp_connector(dig_port))
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 16e496579e0aa..490698519eeb6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -50,6 +50,7 @@
#include "display/intel_crt.h"
#include "display/intel_ddi.h"
#include "display/intel_display_debugfs.h"
+#include "display/intel_display_power.h"
#include "display/intel_dp.h"
#include "display/intel_dp_mst.h"
#include "display/intel_dpll.h"
@@ -2300,91 +2301,15 @@ enum tc_port intel_port_to_tc(struct drm_i915_private
*dev_priv,
[Intel-gfx] [PATCH v2 19/26] drm/i915: Allow platforms to share power well descriptors
Some power wells - like always-on and skl+/icl+ PW_1 - with the same
name, domain list, flags, ops are used by multiple platforms, so allow
platforms to reuse the descriptors of such power wells.
This change also lets the follow up patches to simplify the DG1/RKL
power well definitions, and remove the ADL-S skip_mask special casing.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 281 --
1 file changed, 122 insertions(+), 159 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 08b6fff924946..1d5d60ec00135 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -38,9 +38,17 @@
{ .name = _name, .domain_list = _domain_list, ## __VA_ARGS__ }
+struct i915_power_well_desc_list {
+ const struct i915_power_well_desc *list;
+ u8 count;
+};
+
+#define I915_PW_DESCRIPTORS(x) __LIST(x)
+
+
I915_DECL_PW_DOMAINS(i9xx_pwdoms_always_on, I915_PW_DOMAINS_ALL);
-static const struct i915_power_well_desc i9xx_always_on_power_well[] = {
+static const struct i915_power_well_desc i9xx_power_wells_always_on[] = {
{
.instances = &I915_PW_INSTANCES(
I915_PW("always-on", &i9xx_pwdoms_always_on),
@@ -50,6 +58,10 @@ static const struct i915_power_well_desc
i9xx_always_on_power_well[] = {
},
};
+static const struct i915_power_well_desc_list i9xx_power_wells[] = {
+ I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
+};
+
I915_DECL_PW_DOMAINS(i830_pwdoms_pipes,
POWER_DOMAIN_PIPE_A,
POWER_DOMAIN_PIPE_B,
@@ -59,14 +71,8 @@ I915_DECL_PW_DOMAINS(i830_pwdoms_pipes,
POWER_DOMAIN_TRANSCODER_B,
POWER_DOMAIN_INIT);
-static const struct i915_power_well_desc i830_power_wells[] = {
+static const struct i915_power_well_desc i830_power_wells_main[] = {
{
- .instances = &I915_PW_INSTANCES(
- I915_PW("always-on", &i9xx_pwdoms_always_on),
- ),
- .ops = &i9xx_always_on_power_well_ops,
- .always_on = true,
- }, {
.instances = &I915_PW_INSTANCES(
I915_PW("pipes", &i830_pwdoms_pipes),
),
@@ -74,6 +80,11 @@ static const struct i915_power_well_desc i830_power_wells[]
= {
},
};
+static const struct i915_power_well_desc_list i830_power_wells[] = {
+ I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
+ I915_PW_DESCRIPTORS(i830_power_wells_main),
+};
+
I915_DECL_PW_DOMAINS(hsw_pwdoms_display,
POWER_DOMAIN_PIPE_B,
POWER_DOMAIN_PIPE_C,
@@ -92,14 +103,8 @@ I915_DECL_PW_DOMAINS(hsw_pwdoms_display,
POWER_DOMAIN_AUDIO_PLAYBACK,
POWER_DOMAIN_INIT);
-static const struct i915_power_well_desc hsw_power_wells[] = {
+static const struct i915_power_well_desc hsw_power_wells_main[] = {
{
- .instances = &I915_PW_INSTANCES(
- I915_PW("always-on", &i9xx_pwdoms_always_on),
- ),
- .ops = &i9xx_always_on_power_well_ops,
- .always_on = true,
- }, {
.instances = &I915_PW_INSTANCES(
I915_PW("display", &hsw_pwdoms_display,
.hsw.idx = HSW_PW_CTL_IDX_GLOBAL,
@@ -110,6 +115,11 @@ static const struct i915_power_well_desc hsw_power_wells[]
= {
},
};
+static const struct i915_power_well_desc_list hsw_power_wells[] = {
+ I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
+ I915_PW_DESCRIPTORS(hsw_power_wells_main),
+};
+
I915_DECL_PW_DOMAINS(bdw_pwdoms_display,
POWER_DOMAIN_PIPE_B,
POWER_DOMAIN_PIPE_C,
@@ -127,14 +137,8 @@ I915_DECL_PW_DOMAINS(bdw_pwdoms_display,
POWER_DOMAIN_AUDIO_PLAYBACK,
POWER_DOMAIN_INIT);
-static const struct i915_power_well_desc bdw_power_wells[] = {
+static const struct i915_power_well_desc bdw_power_wells_main[] = {
{
- .instances = &I915_PW_INSTANCES(
- I915_PW("always-on", &i9xx_pwdoms_always_on),
- ),
- .ops = &i9xx_always_on_power_well_ops,
- .always_on = true,
- }, {
.instances = &I915_PW_INSTANCES(
I915_PW("display", &bdw_pwdoms_display,
.hsw.idx = HSW_PW_CTL_IDX_GLOBAL,
@@ -146,6 +150,11 @@ static const struct i915_power_well_desc bdw_power_wells[]
= {
},
};
+static const struct i915_power_well_desc_list bdw_power_wells[] = {
+ I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
+ I915_PW_DESCRIPTORS(bdw_power_wells_main),
+};
+
I915_DECL_PW_DOMAINS(vlv_pwdoms_display,
POWER_DOMAIN_DISPLAY_CORE,
POWER_DOMAIN_PIPE_A,
@@ -181,14 +190,8 @@ I915_DECL_PW_DOMAINS(vlv_pwdoms_dpio_tx_bc_lanes,
POWER_DOMAIN_A
[Intel-gfx] [PATCH v2 20/26] drm/i915: Simplify the DG1 power well descriptors
Simplify the definition of DG1 power wells by reusing the identical
RKL DDI/AUX descriptors.
This reorders the DG1 DDI/AUX vs. PW4/5 power wells, but this shouldn't
make a difference (it is the order on RKL and the DDI/AUX power wells
don't have a dependency on PW4/5).
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 24 ++-
1 file changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 1d5d60ec00135..42fbea02770fe 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1035,7 +1035,11 @@ static const struct i915_power_well_desc
rkl_power_wells_main[] = {
.ops = &hsw_power_well_ops,
.has_fuses = true,
.irq_pipe_mask = BIT(PIPE_C),
- }, {
+ },
+};
+
+static const struct i915_power_well_desc rkl_power_wells_ddi_aux[] = {
+ {
.instances = &I915_PW_INSTANCES(
I915_PW("DDI_IO_A", &icl_pwdoms_ddi_io_a, .hsw.idx =
ICL_PW_CTL_IDX_DDI_A),
I915_PW("DDI_IO_B", &icl_pwdoms_ddi_io_b, .hsw.idx =
ICL_PW_CTL_IDX_DDI_B),
@@ -1058,6 +1062,7 @@ static const struct i915_power_well_desc_list
rkl_power_wells[] = {
I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
I915_PW_DESCRIPTORS(rkl_power_wells_main),
+ I915_PW_DESCRIPTORS(rkl_power_wells_ddi_aux),
};
/*
@@ -1117,22 +1122,6 @@ static const struct i915_power_well_desc
dg1_power_wells_main[] = {
.irq_pipe_mask = BIT(PIPE_B),
.has_vga = true,
.has_fuses = true,
- }, {
- .instances = &I915_PW_INSTANCES(
- I915_PW("DDI_IO_A", &icl_pwdoms_ddi_io_a, .hsw.idx =
ICL_PW_CTL_IDX_DDI_A),
- I915_PW("DDI_IO_B", &icl_pwdoms_ddi_io_b, .hsw.idx =
ICL_PW_CTL_IDX_DDI_B),
- I915_PW("DDI_IO_TC1", &tgl_pwdoms_ddi_io_tc1, .hsw.idx
= TGL_PW_CTL_IDX_DDI_TC1),
- I915_PW("DDI_IO_TC2", &tgl_pwdoms_ddi_io_tc2, .hsw.idx
= TGL_PW_CTL_IDX_DDI_TC2),
- ),
- .ops = &icl_ddi_power_well_ops,
- }, {
- .instances = &I915_PW_INSTANCES(
- I915_PW("AUX_A", &tgl_pwdoms_aux_a, .hsw.idx =
ICL_PW_CTL_IDX_AUX_A),
- I915_PW("AUX_B", &tgl_pwdoms_aux_b, .hsw.idx =
ICL_PW_CTL_IDX_AUX_B),
- I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
- I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
- ),
- .ops = &icl_aux_power_well_ops,
}, {
.instances = &I915_PW_INSTANCES(
I915_PW("PW_4", &tgl_pwdoms_pw_4,
@@ -1156,6 +1145,7 @@ static const struct i915_power_well_desc_list
dg1_power_wells[] = {
I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
I915_PW_DESCRIPTORS(dg1_power_wells_main),
+ I915_PW_DESCRIPTORS(rkl_power_wells_ddi_aux),
};
/*
--
2.27.0
[Intel-gfx] [PATCH v2 25/26] drm/i915: Remove duplicate DDI/AUX power domain mappings
The DDI and AUX domain -> power well mappings are identical for a few
platforms/power well instances, reuse the mappings of earlier platforms
for these removing the duplicate mapping of new platforms.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 89 +++
1 file changed, 31 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 4c7def498dd6f..dce34a5b49f32 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -653,9 +653,6 @@ I915_DECL_PW_DOMAINS(icl_pwdoms_dc_off,
POWER_DOMAIN_DC_OFF,
POWER_DOMAIN_INIT);
-I915_DECL_PW_DOMAINS(icl_pwdoms_ddi_io_a, POWER_DOMAIN_PORT_DDI_IO_A);
-I915_DECL_PW_DOMAINS(icl_pwdoms_ddi_io_b, POWER_DOMAIN_PORT_DDI_IO_B);
-I915_DECL_PW_DOMAINS(icl_pwdoms_ddi_io_c, POWER_DOMAIN_PORT_DDI_IO_C);
I915_DECL_PW_DOMAINS(icl_pwdoms_ddi_io_d, POWER_DOMAIN_PORT_DDI_IO_D);
I915_DECL_PW_DOMAINS(icl_pwdoms_ddi_io_e, POWER_DOMAIN_PORT_DDI_IO_E);
I915_DECL_PW_DOMAINS(icl_pwdoms_ddi_io_f, POWER_DOMAIN_PORT_DDI_IO_F);
@@ -714,9 +711,9 @@ static const struct i915_power_well_desc
icl_power_wells_main[] = {
.has_fuses = true,
}, {
.instances = &I915_PW_INSTANCES(
- I915_PW("DDI_IO_A", &icl_pwdoms_ddi_io_a, .hsw.idx =
ICL_PW_CTL_IDX_DDI_A),
- I915_PW("DDI_IO_B", &icl_pwdoms_ddi_io_b, .hsw.idx =
ICL_PW_CTL_IDX_DDI_B),
- I915_PW("DDI_IO_C", &icl_pwdoms_ddi_io_c, .hsw.idx =
ICL_PW_CTL_IDX_DDI_C),
+ I915_PW("DDI_IO_A", &glk_pwdoms_ddi_io_a, .hsw.idx =
ICL_PW_CTL_IDX_DDI_A),
+ I915_PW("DDI_IO_B", &glk_pwdoms_ddi_io_b, .hsw.idx =
ICL_PW_CTL_IDX_DDI_B),
+ I915_PW("DDI_IO_C", &glk_pwdoms_ddi_io_c, .hsw.idx =
ICL_PW_CTL_IDX_DDI_C),
I915_PW("DDI_IO_D", &icl_pwdoms_ddi_io_d, .hsw.idx =
ICL_PW_CTL_IDX_DDI_D),
I915_PW("DDI_IO_E", &icl_pwdoms_ddi_io_e, .hsw.idx =
ICL_PW_CTL_IDX_DDI_E),
I915_PW("DDI_IO_F", &icl_pwdoms_ddi_io_f, .hsw.idx =
ICL_PW_CTL_IDX_DDI_F),
@@ -828,12 +825,6 @@ I915_DECL_PW_DOMAINS(tgl_pwdoms_ddi_io_tc4,
POWER_DOMAIN_PORT_DDI_IO_TC4);
I915_DECL_PW_DOMAINS(tgl_pwdoms_ddi_io_tc5,POWER_DOMAIN_PORT_DDI_IO_TC5);
I915_DECL_PW_DOMAINS(tgl_pwdoms_ddi_io_tc6,POWER_DOMAIN_PORT_DDI_IO_TC6);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_a,
- POWER_DOMAIN_AUX_A,
- POWER_DOMAIN_AUX_IO_A);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_b, POWER_DOMAIN_AUX_B);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_c, POWER_DOMAIN_AUX_C);
-
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_usbc1, POWER_DOMAIN_AUX_USBC1);
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_usbc2, POWER_DOMAIN_AUX_USBC2);
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_usbc3, POWER_DOMAIN_AUX_USBC3);
@@ -841,10 +832,6 @@ I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_usbc4,
POWER_DOMAIN_AUX_USBC4);
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_usbc5, POWER_DOMAIN_AUX_USBC5);
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_usbc6, POWER_DOMAIN_AUX_USBC6);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_tbt1, POWER_DOMAIN_AUX_TBT1);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_tbt2, POWER_DOMAIN_AUX_TBT2);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_tbt3, POWER_DOMAIN_AUX_TBT3);
-I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_tbt4, POWER_DOMAIN_AUX_TBT4);
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_tbt5, POWER_DOMAIN_AUX_TBT5);
I915_DECL_PW_DOMAINS(tgl_pwdoms_aux_tbt6, POWER_DOMAIN_AUX_TBT6);
@@ -890,9 +877,9 @@ static const struct i915_power_well_desc
tgl_power_wells_main[] = {
.has_fuses = true,
}, {
.instances = &I915_PW_INSTANCES(
- I915_PW("DDI_IO_A", &icl_pwdoms_ddi_io_a, .hsw.idx =
ICL_PW_CTL_IDX_DDI_A),
- I915_PW("DDI_IO_B", &icl_pwdoms_ddi_io_b, .hsw.idx =
ICL_PW_CTL_IDX_DDI_B),
- I915_PW("DDI_IO_C", &icl_pwdoms_ddi_io_c, .hsw.idx =
ICL_PW_CTL_IDX_DDI_C),
+ I915_PW("DDI_IO_A", &glk_pwdoms_ddi_io_a, .hsw.idx =
ICL_PW_CTL_IDX_DDI_A),
+ I915_PW("DDI_IO_B", &glk_pwdoms_ddi_io_b, .hsw.idx =
ICL_PW_CTL_IDX_DDI_B),
+ I915_PW("DDI_IO_C", &glk_pwdoms_ddi_io_c, .hsw.idx =
ICL_PW_CTL_IDX_DDI_C),
I915_PW("DDI_IO_TC1", &tgl_pwdoms_ddi_io_tc1, .hsw.idx
= TGL_PW_CTL_IDX_DDI_TC1),
I915_PW("DDI_IO_TC2", &tgl_pwdoms_ddi_io_tc2, .hsw.idx
= TGL_PW_CTL_IDX_DDI_TC2),
I915_PW("DDI_IO_TC3", &tgl_pwdoms_ddi_io_tc3, .hsw.idx
= TGL_PW_CTL_IDX_DDI_TC3),
@@ -933,9 +920,9 @@ static const struct i915_power_well_desc
tgl_power_wells_tc_cold_off[] = {
static const struct i915_power_well_desc tgl_power_wells_aux[] = {
[Intel-gfx] [PATCH v2 18/26] drm/i915: Simplify power well definitions by adding power well instances
All the port specific AUX/DDI_IO power wells share the same power well
ops struct and flags, so we can save some space and simplify the
definition of these by listing for all such power wells only the params
specific to them (name, domains, power well register index, id). Move
these params to a new i915_power_well_instance struct and convert the
per-platform power well definitions accordingly.
For all power well instance the name and power domain list params must
be specified, while the register index and id are optional, add the
I915_PW() macro that both simplifies the definitions and ensures that
the required params are set.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 1515 +
.../i915/display/intel_display_power_well.c | 72 +-
.../i915/display/intel_display_power_well.h | 48 +-
3 files changed, 505 insertions(+), 1130 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 4dad861f252f7..08b6fff924946 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -30,16 +30,23 @@
#define I915_PW_DOMAINS_NONE NULL
#define I915_PW_DOMAINS_ALL/* zero-length list */
+#define I915_PW_INSTANCES(...) \
+ (const struct i915_power_well_instance_list) \
+ __LIST(__LIST_INLINE_ELEMS(struct i915_power_well_instance,
__VA_ARGS__))
+
+#define I915_PW(_name, _domain_list, ...) \
+ { .name = _name, .domain_list = _domain_list, ## __VA_ARGS__ }
+
I915_DECL_PW_DOMAINS(i9xx_pwdoms_always_on, I915_PW_DOMAINS_ALL);
static const struct i915_power_well_desc i9xx_always_on_power_well[] = {
{
- .name = "always-on",
- .domain_list = &i9xx_pwdoms_always_on,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("always-on", &i9xx_pwdoms_always_on),
+ ),
.ops = &i9xx_always_on_power_well_ops,
.always_on = true,
- .id = DISP_PW_ID_NONE,
},
};
@@ -54,16 +61,16 @@ I915_DECL_PW_DOMAINS(i830_pwdoms_pipes,
static const struct i915_power_well_desc i830_power_wells[] = {
{
- .name = "always-on",
- .domain_list = &i9xx_pwdoms_always_on,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("always-on", &i9xx_pwdoms_always_on),
+ ),
.ops = &i9xx_always_on_power_well_ops,
.always_on = true,
- .id = DISP_PW_ID_NONE,
}, {
- .name = "pipes",
- .domain_list = &i830_pwdoms_pipes,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("pipes", &i830_pwdoms_pipes),
+ ),
.ops = &i830_pipes_power_well_ops,
- .id = DISP_PW_ID_NONE,
},
};
@@ -87,20 +94,19 @@ I915_DECL_PW_DOMAINS(hsw_pwdoms_display,
static const struct i915_power_well_desc hsw_power_wells[] = {
{
- .name = "always-on",
- .domain_list = &i9xx_pwdoms_always_on,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("always-on", &i9xx_pwdoms_always_on),
+ ),
.ops = &i9xx_always_on_power_well_ops,
.always_on = true,
- .id = DISP_PW_ID_NONE,
}, {
- .name = "display",
- .domain_list = &hsw_pwdoms_display,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("display", &hsw_pwdoms_display,
+ .hsw.idx = HSW_PW_CTL_IDX_GLOBAL,
+ .id = HSW_DISP_PW_GLOBAL),
+ ),
.ops = &hsw_power_well_ops,
.has_vga = true,
- .id = HSW_DISP_PW_GLOBAL,
- {
- .hsw.idx = HSW_PW_CTL_IDX_GLOBAL,
- },
},
};
@@ -123,21 +129,20 @@ I915_DECL_PW_DOMAINS(bdw_pwdoms_display,
static const struct i915_power_well_desc bdw_power_wells[] = {
{
- .name = "always-on",
- .domain_list = &i9xx_pwdoms_always_on,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("always-on", &i9xx_pwdoms_always_on),
+ ),
.ops = &i9xx_always_on_power_well_ops,
.always_on = true,
- .id = DISP_PW_ID_NONE,
}, {
- .name = "display",
- .domain_list = &bdw_pwdoms_display,
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("display", &bdw_pwdoms_display,
+ .hsw.idx = HSW_PW_CTL_IDX_GLOBAL,
+ .id = HSW_DISP_PW_GLOBAL),
+ ),
.ops = &hsw_power_well_ops,
.has_vga = true,
[Intel-gfx] [PATCH v2 17/26] drm/i915: Convert the u64 power well domains mask to a bitmap
To remove the aliasing of the power domain enum values in a follow-up
patch in this patchset (requiring a bigger mask) and allow for defining
additional power domains in the future (at least some upcoming TypeC
changes requires this) convert the u64 i915_power_well_desc::domains
mask to a bitmap.
For simplicity I changed the for_each_power_domain_well() macros to
accept one domain only instead of a mask, as there isn't any current
user passing multiple domains.
v2: Don't add a typedef for the bitmap struct. (Jani)
Cc: Jani Nikula
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 65 ++-
.../drm/i915/display/intel_display_power.c| 108 +++---
.../drm/i915/display/intel_display_power.h| 18 +--
.../i915/display/intel_display_power_map.c| 4 +-
.../i915/display/intel_display_power_well.c | 4 +-
.../i915/display/intel_display_power_well.h | 5 +-
6 files changed, 116 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e2f1e9415415e..16e496579e0aa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2387,66 +2387,71 @@ intel_legacy_aux_to_power_domain(enum aux_ch aux_ch)
}
}
-static u64 get_crtc_power_domains(struct intel_crtc_state *crtc_state)
+static void get_crtc_power_domains(struct intel_crtc_state *crtc_state,
+ struct intel_power_domain_mask *mask)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
struct drm_encoder *encoder;
enum pipe pipe = crtc->pipe;
- u64 mask;
+
+ bitmap_zero(mask->bits, POWER_DOMAIN_NUM);
if (!crtc_state->hw.active)
- return 0;
+ return;
- mask = BIT_ULL(POWER_DOMAIN_PIPE(pipe));
- mask |= BIT_ULL(POWER_DOMAIN_TRANSCODER(cpu_transcoder));
+ set_bit(POWER_DOMAIN_PIPE(pipe), mask->bits);
+ set_bit(POWER_DOMAIN_TRANSCODER(cpu_transcoder), mask->bits);
if (crtc_state->pch_pfit.enabled ||
crtc_state->pch_pfit.force_thru)
- mask |= BIT_ULL(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
+ set_bit(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe), mask->bits);
drm_for_each_encoder_mask(encoder, &dev_priv->drm,
crtc_state->uapi.encoder_mask) {
struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
- mask |= BIT_ULL(intel_encoder->power_domain);
+ set_bit(intel_encoder->power_domain, mask->bits);
}
if (HAS_DDI(dev_priv) && crtc_state->has_audio)
- mask |= BIT_ULL(POWER_DOMAIN_AUDIO_MMIO);
+ set_bit(POWER_DOMAIN_AUDIO_MMIO, mask->bits);
if (crtc_state->shared_dpll)
- mask |= BIT_ULL(POWER_DOMAIN_DISPLAY_CORE);
+ set_bit(POWER_DOMAIN_DISPLAY_CORE, mask->bits);
if (crtc_state->dsc.compression_enable)
- mask |= BIT_ULL(intel_dsc_power_domain(crtc, cpu_transcoder));
-
- return mask;
+ set_bit(intel_dsc_power_domain(crtc, cpu_transcoder),
mask->bits);
}
-static u64
-modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state)
+static void
+modeset_get_crtc_power_domains(struct intel_crtc_state *crtc_state,
+ struct intel_power_domain_mask *old_domains)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum intel_display_power_domain domain;
- u64 domains, new_domains, old_domains;
+ struct intel_power_domain_mask domains, new_domains;
- domains = get_crtc_power_domains(crtc_state);
+ get_crtc_power_domains(crtc_state, &domains);
- new_domains = domains & ~crtc->enabled_power_domains.mask;
- old_domains = crtc->enabled_power_domains.mask & ~domains;
+ bitmap_andnot(new_domains.bits,
+ domains.bits,
+ crtc->enabled_power_domains.mask.bits,
+ POWER_DOMAIN_NUM);
+ bitmap_andnot(old_domains->bits,
+ crtc->enabled_power_domains.mask.bits,
+ domains.bits,
+ POWER_DOMAIN_NUM);
- for_each_power_domain(domain, new_domains)
+ for_each_power_domain(domain, &new_domains)
intel_display_power_get_in_set(dev_priv,
&crtc->enabled_power_domains,
domain);
-
- return old_domains;
}
static void modeset_put_crtc_power_domains(struct intel_crtc *crtc,
- u64 domains)
+
