[Intel-gfx] [PATCH] drm/i915/gem: Add a check for object size for corner cases
Add check for object size to return appropriate error -E2BIG or -EINVAL
to avoid WARM_ON and sucessfull return for some testcase.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Anand Moon
---
VLK-17702: Since these object size is U64 these corner case will not come
into real test senario.
IGT testcase:
sudo ./gem_create --r create-massive
sudo ./gem_userptr_blits --r input-checking
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 366d23afbb1a..afc37546da20 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -33,6 +33,9 @@ static inline bool i915_gem_object_size_2big(u64 size)
{
struct drm_i915_gem_object *obj;
+ if (size == -1 || size == (-1ull << 32))
+ return true;
+
if (GEM_CHECK_SIZE_OVERFLOW(size))
return true;
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
Hi
Am 09.02.21 um 11:54 schrieb Daniel Vetter:
*: vmwgfx is the only non-gem driver, but there's plans to move at least
vmwgfx internals (maybe not the uapi, we'll see) over to gem. Once that's
done it's truly all gpu memory.
Do you have a URL to the discussion?
While I recent worked on GEM, I thought that vmwgfx could easily switch
to the GEM internals without adopting the interface.
Personally, I think we should consider renaming struct drm_gem_object et
al. It's not strictly GEM UAPI, but nowadays anything memory-related.
Maybe drm_mem_object would fit.
Best regards
Thomas
---
drivers/gpu/drm/drm_gem.c | 89 +++
include/drm/drm_gem.h | 17
2 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index c2ce78c4edc3..a12da41eaafe 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -112,6 +113,89 @@ drm_gem_init(struct drm_device *dev)
return drmm_add_action(dev, drm_gem_init_release, NULL);
}
+/**
+ * drm_gem_object_set_cgroup - associate GEM object with a cgroup
+ * @obj: GEM object which is being associated with a cgroup
+ * @task: task associated with process control group to use
+ *
+ * This will acquire a reference on cgroup and use for charging GEM
+ * memory allocations.
+ * This helper could be extended in future to migrate charges to another
+ * cgroup, print warning if this usage occurs.
+ */
+void drm_gem_object_set_cgroup(struct drm_gem_object *obj,
+ struct task_struct *task)
+{
+ /* if object has existing cgroup, we migrate the charge... */
+ if (obj->drmcg) {
+ pr_warn("DRM: need to migrate cgroup charge of %lld\n",
+ atomic64_read(>drmcg_bytes_charged));
+ }
+ obj->drmcg = drmcg_get(task);
+}
+EXPORT_SYMBOL(drm_gem_object_set_cgroup);
+
+/**
+ * drm_gem_object_unset_cgroup - clear GEM object's associated cgroup
+ * @obj: GEM object
+ *
+ * This will release a reference on cgroup.
+ */
+void drm_gem_object_unset_cgroup(struct drm_gem_object *obj)
+{
+ WARN_ON(atomic64_read(>drmcg_bytes_charged));
+ drmcg_put(obj->drmcg);
+}
+EXPORT_SYMBOL(drm_gem_object_unset_cgroup);
+
+/**
+ * drm_gem_object_charge_mem - try charging size bytes to DRM cgroup
+ * @obj: GEM object which is being charged
+ * @size: number of bytes to charge
+ *
+ * Try to charge @size bytes to GEM object's associated DRM cgroup. This
+ * will fail if a successful charge would cause the current device memory
+ * usage to go above the cgroup's GPU memory maximum limit.
+ *
+ * Returns 0 on success. Otherwise, an error code is returned.
+ */
+int drm_gem_object_charge_mem(struct drm_gem_object *obj, u64 size)
+{
+ int ret;
+
+ ret = drm_cgroup_try_charge(obj->drmcg, obj->dev,
+ DRMCG_TYPE_MEM_CURRENT, size);
+ if (!ret)
+ atomic64_add(size, >drmcg_bytes_charged);
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_object_charge_mem);
+
+/**
+ * drm_gem_object_uncharge_mem - uncharge size bytes from DRM cgroup
+ * @obj: GEM object which is being uncharged
+ * @size: number of bytes to uncharge
+ *
+ * Uncharge @size bytes from the DRM cgroup associated with specified
+ * GEM object.
+ *
+ * Returns 0 on success. Otherwise, an error code is returned.
+ */
+void drm_gem_object_uncharge_mem(struct drm_gem_object *obj, u64 size)
+{
+ u64 charged = atomic64_read(>drmcg_bytes_charged);
+
+ if (WARN_ON(!charged))
+ return;
+ if (WARN_ON(size > charged))
+ size = charged;
+
+ atomic64_sub(size, >drmcg_bytes_charged);
+ drm_cgroup_uncharge(obj->drmcg, obj->dev, DRMCG_TYPE_MEM_CURRENT,
+ size);
+}
+EXPORT_SYMBOL(drm_gem_object_uncharge_mem);
+
/**
* drm_gem_object_init - initialize an allocated shmem-backed GEM object
* @dev: drm_device the object should be initialized for
@@ -156,6 +240,8 @@ void drm_gem_private_object_init(struct drm_device *dev,
obj->dev = dev;
obj->filp = NULL;
+ drm_gem_object_set_cgroup(obj, current);
+
kref_init(>refcount);
obj->handle_count = 0;
obj->size = size;
@@ -950,6 +1036,9 @@ drm_gem_object_release(struct drm_gem_object *obj)
dma_resv_fini(>_resv);
drm_gem_free_mmap_offset(obj);
+
+ /* Release reference on cgroup used with GEM object charging */
+ drm_gem_object_unset_cgroup(obj);
}
EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 240049566592..06ea10fc17bc 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -37,6 +37,7 @@
#include
#include
+#include
#include
struct dma_buf_map;
@@ -222,6 +223,17 @@ struct drm_gem_object {
*/
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
== Series Details == Series: Revert "drm/atomic: document and enforce rules around "spurious" EBUSY" URL : https://patchwork.freedesktop.org/series/86927/ State : success == Summary == CI Bug Log - changes from CI_DRM_9754_full -> Patchwork_19647_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19647_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-kbl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl6/igt@gem_cre...@create-massive.html - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl4/igt@gem_cre...@create-massive.html * igt@gem_eio@in-flight-suspend: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#1037] / [i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl7/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#3063]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb6/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb3/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb7/igt@gem_exec_fair@basic-p...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb6/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-apl: NOTRUN -> [TIMEOUT][13] ([i915#1729]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl2/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2389]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1610]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-apl6/igt@gem_exec_schedule@u-fairsl...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-apl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb7/igt@gem_exec_schedule@u-fairsl...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb6/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_userptr_blits@input-checking: - shard-skl: NOTRUN -> [DMESG-WARN][19] ([i915#3002]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-skl6/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271]) +45 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-kbl3/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_vm_create@destroy-race: - shard-tglb: [PASS][21] -> [FAIL][22] ([i915#2822]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-tglb2/igt@gem_vm_cre...@destroy-race.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-tglb7/igt@gem_vm_cre...@destroy-race.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#454]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/shard-iclb7/igt@i915_pm...@dc6-psr.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@live@client: - shard-glk: [PASS][25] -> [DMESG-FAIL][26] ([i915#3047]) [25]:
Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during suspend/resume
> -Original Message- > From: Lyude Paul > Sent: Wednesday, February 10, 2021 1:34 AM > To: Deak, Imre ; Surendrakumar Upadhyay, TejaskumarX > ; Gupta, Anshuman > > Cc: intel-gfx@lists.freedesktop.org; Pandey, Hariom > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during > suspend/resume > > ..snip.. (comments down below) > > On Tue, 2021-02-02 at 18:14 +0200, Imre Deak wrote: > > > > BSpec says about this WA for both ICL and TGL: > > """ > > Display driver should set and clear register offset 0xC2000 bit #7 as > > last step in programming south display registers in preparation for > > entering S0ix state, or set 0xC2000 bit #7 on S0ix entry and clear it > > on S0ix exit. > > > > """ > > > > This means to me the WA is only relevant for S0ix and we can implement > > it by setting/clearing 0xC2000 bit #7 right before entering/right > > after exiting S0ix. This is done atm on PCH_ICP..PCH_MCC in > > intel_display_power_suspend_late()/intel_display_power_resume_early(), > > so I'd move the WA for all platforms there. > > > > I assume the current code in irq_reset() was the first alternative to > > implement the WA, but it wasn't enough. Not sure why, maybe there is a > > south display register access after irq_reset() during suspend. Adding > > Anshuman for an idea on that. > > > > Poking Anshuman here, is there any update on this? I'm looking to push these > patches forward as some of Red Hat's hardware partners are very eager for this > to get upstream asap as we're running out of time from our end. If you can > answer this, I can handle respinning this patch as needed. My sincere apology, I had missed this thread. We have decided to keep the alternative WA i.e setting/clearing 0xC2000 bit #7 before entering after exiting s0ix to fix the deeper s0ix power consumption issues on ICL_PCH families platforms. This alternative WA was added to B.Spec on our request. But on TGL_PCH first alternative WA logic i.e in irq_reset() was working to attain deeper s0ix residencies so we haven't changed that. Thanks, Anshuman Gupta > > > --Imre > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Sincerely, >Lyude Paul (she/her) >Software Engineer at Red Hat > > Note: I deal with a lot of emails and have a lot of bugs on my plate. If > you've > asked me a question, are waiting for a review/merge on a patch, etc. and I > haven't responded in a while, please feel free to send me another email to > check > on my status. I don't bite! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/v3d/v3d_sched.c:263:1: error: return type is an incomplete type
263 | v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job
*sched_job)
| ^
drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_gpu_reset_for_timeout':
drivers/gpu/drm/v3d/v3d_sched.c:289:9: error: 'return' with a value, in
function returning void [-Werror=return-type]
289 | return DRM_GPU_SCHED_STAT_NOMINAL;
| ^~
drivers/gpu/drm/v3d/v3d_sched.c:263:1: note: declared here
263 | v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct drm_sched_job
*sched_job)
| ^
drivers/gpu/drm/v3d/v3d_sched.c: At top level:
drivers/gpu/drm/v3d/v3d_sched.c:298:1: error: return type is an incomplete type
298 | v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
| ^~~
drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_cl_job_timedout':
drivers/gpu/drm/v3d/v3d_sched.c:309:10: error: 'return' with a value, in
function returning void [-Werror=return-type]
309 | return DRM_GPU_SCHED_STAT_NOMINAL;
| ^~
drivers/gpu/drm/v3d/v3d_sched.c:298:1: note: declared here
298 | v3d_cl_job_timedout(struct drm_sched_job *sched_job, enum v3d_queue q,
| ^~~
drivers/gpu/drm/v3d/v3d_sched.c: At top level:
drivers/gpu/drm/v3d/v3d_sched.c:316:1: error: return type is an incomplete type
316 | v3d_bin_job_timedout(struct drm_sched_job *sched_job)
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:325:1: error: return type is an incomplete type
325 | v3d_render_job_timedout(struct drm_sched_job *sched_job)
| ^~~
drivers/gpu/drm/v3d/v3d_sched.c:334:1: error: return type is an incomplete type
334 | v3d_generic_job_timedout(struct drm_sched_job *sched_job)
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:342:1: error: return type is an incomplete type
342 | v3d_csd_job_timedout(struct drm_sched_job *sched_job)
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c: In function 'v3d_csd_job_timedout':
drivers/gpu/drm/v3d/v3d_sched.c:353:10: error: 'return' with a value, in
function returning void [-Werror=return-type]
353 | return DRM_GPU_SCHED_STAT_NOMINAL;
| ^~
drivers/gpu/drm/v3d/v3d_sched.c:342:1: note: declared here
342 | v3d_csd_job_timedout(struct drm_sched_job *sched_job)
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c: At top level:
drivers/gpu/drm/v3d/v3d_sched.c:362:18: error: initialization of 'enum
drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer type
'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
362 | .timedout_job = v3d_bin_job_timedout,
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:362:18: note: (near initialization for
'v3d_bin_sched_ops.timedout_job')
drivers/gpu/drm/v3d/v3d_sched.c:369:18: error: initialization of 'enum
drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer type
'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
369 | .timedout_job = v3d_render_job_timedout,
| ^~~
drivers/gpu/drm/v3d/v3d_sched.c:369:18: note: (near initialization for
'v3d_render_sched_ops.timedout_job')
drivers/gpu/drm/v3d/v3d_sched.c:376:18: error: initialization of 'enum
drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer type
'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
376 | .timedout_job = v3d_generic_job_timedout,
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:376:18: note: (near initialization for
'v3d_tfu_sched_ops.timedout_job')
drivers/gpu/drm/v3d/v3d_sched.c:383:18: error: initialization of 'enum
drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer type
'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
383 | .timedout_job = v3d_csd_job_timedout,
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:383:18: note: (near initialization for
'v3d_csd_sched_ops.timedout_job')
drivers/gpu/drm/v3d/v3d_sched.c:390:18: error: initialization of 'enum
drm_gpu_sched_stat (*)(struct drm_sched_job *)' from incompatible pointer type
'void (*)(struct drm_sched_job *)' [-Werror=incompatible-pointer-types]
390 | .timedout_job = v3d_generic_job_timedout,
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:390:18: note: (near initialization for
'v3d_cache_clean_sched_ops.timedout_job')
Caused by commit
c10983e14e8f ("drm/scheduler: Job timeout handler returns status (v3)")
I have used the drm-misc tree from next-20210209 for today.
--
Cheer
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
== Series Details == Series: Revert "drm/atomic: document and enforce rules around "spurious" EBUSY" URL : https://patchwork.freedesktop.org/series/86927/ State : success == Summary == CI Bug Log - changes from CI_DRM_9754 -> Patchwork_19647 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/index.html Known issues Here are the changes found in Patchwork_19647 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-tgl-y/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-tgl-y/igt@debugfs_test@read_all_entries.html * igt@i915_selftest@live@sanitycheck: - fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2605]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-kbl-7500u/igt@i915_selftest@l...@sanitycheck.html Possible fixes * igt@gem_flink_basic@bad-flink: - fi-tgl-y: [DMESG-WARN][5] ([i915#402]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-tgl-y/igt@gem_flink_ba...@bad-flink.html * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][7] ([i915#2203] / [i915#579]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9754/fi-kbl-guc/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/fi-kbl-guc/igt@i915_pm_...@module-reload.html [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203 [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 Participating hosts (43 -> 38) -- Missing(5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9754 -> Patchwork_19647 CI-20190529: 20190529 CI_DRM_9754: 115d43f1936b9d5da493e4ab324fada8938be783 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19647: 064f0782a30808570873507b3086843c2b561329 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 064f0782a308 Revert "drm/atomic: document and enforce rules around "spurious" EBUSY" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19647/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen9_bc: Add TGP PCH support
== Series Details == Series: drm/i915/gen9_bc: Add TGP PCH support URL : https://patchwork.freedesktop.org/series/86918/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752_full -> Patchwork_19646_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19646_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-persistence: - shard-hsw: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-hsw4/igt@gem_ctx_persiste...@legacy-engines-persistence.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][2] -> [DMESG-WARN][3] ([i915#1037] / [i915#180]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-apl3/igt@gem_...@in-flight-suspend.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-apl6/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][4] -> [TIMEOUT][5] ([i915#1037] / [i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-tglb8/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-tglb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][6] -> [INCOMPLETE][7] ([i915#1895] / [i915#2295] / [i915#3031]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@gem_exec_balan...@hang.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-iclb4/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][12] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-kbl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-kbl3/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1610] / [i915#2803]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-skl4/igt@gem_exec_schedule@u-fairsl...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-skl10/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-apl7/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-kbl1/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@huge-split: - shard-kbl: [PASS][19] -> [INCOMPLETE][20] ([i915#2502]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl1/igt@gem_userptr_bl...@huge-split.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-kbl1/igt@gem_userptr_bl...@huge-split.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][21] ([fdo#109271]) +48 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-kbl6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#1699]) +3 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/shard-apl7/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180]) +4 similar issues [23]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time (rev2)
== Series Details == Series: drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time (rev2) URL : https://patchwork.freedesktop.org/series/86773/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9752_full -> Patchwork_19645_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_19645_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_19645_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_19645_full: ### IGT changes ### Possible regressions * igt@gem_exec_capture@capture@bcs0: - shard-skl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-skl5/igt@gem_exec_capture@capt...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-skl2/igt@gem_exec_capture@capt...@bcs0.html Known issues Here are the changes found in Patchwork_19645_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-tglb8/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-tglb6/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#2481]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb8/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-iclb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / [i915#2295]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@gem_exec_balan...@hang.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-iclb4/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-kbl3/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-glk6/igt@gem_exec_fair@basic-p...@vcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-glk7/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-sync@rcs0: - shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl1/igt@gem_exec_fair@basic-s...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-kbl4/igt@gem_exec_fair@basic-s...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-kbl: NOTRUN -> [FAIL][17] ([i915#2389]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-kbl7/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][18] ([i915#2389]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-iclb1/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@bcs0: - shard-iclb: [PASS][19] -> [DMESG-WARN][20] ([i915#2803]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@bcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-iclb7/igt@gem_exec_schedule@u-fairsl...@bcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-skl: [PASS][21] -> [DMESG-WARN][22] ([i915#1610] / [i915#2803]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-skl4/igt@gem_exec_schedule@u-fairsl...@rcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/shard-skl9/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-glk: [PASS][23] -> [DMESG-WARN][24]
[Intel-gfx] [PATCH] Revert "drm/atomic: document and enforce rules around "spurious" EBUSY"
This reverts commit fb6473a48b635c55d04eb94e579eede52ef39550.
These additional checks added to avoid EBUSY give unnecessary WARN_ON
in case of big joiner used in i915 in which case even if the modeset
is requested on a single pipe, internally another consecutive
pipe is stolen and used to drive half of the transcoder timings.
So in this case it is expected that requested crtc and affected crtcs
do not match. Hence the added WARN ON becomes irrelevant.
But there is no easy solution to get the bigjoiner information
here at drm level. So for now revert this until we work out
a better solution.
Cc: Ville Syrjala
Cc: Daniel Vetter
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_atomic.c | 29 -
1 file changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b1efa9322be2..48b2262d69f6 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -320,10 +320,6 @@ EXPORT_SYMBOL(__drm_atomic_state_free);
* needed. It will also grab the relevant CRTC lock to make sure that the state
* is consistent.
*
- * WARNING: Drivers may only add new CRTC states to a @state if
- * drm_atomic_state.allow_modeset is set, or if it's a driver-internal commit
- * not created by userspace through an IOCTL call.
- *
* Returns:
*
* Either the allocated state or the error code encoded into the pointer. When
@@ -1306,15 +1302,10 @@ int drm_atomic_check_only(struct drm_atomic_state
*state)
struct drm_crtc_state *new_crtc_state;
struct drm_connector *conn;
struct drm_connector_state *conn_state;
- unsigned requested_crtc = 0;
- unsigned affected_crtc = 0;
int i, ret = 0;
DRM_DEBUG_ATOMIC("checking %p\n", state);
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- requested_crtc |= drm_crtc_mask(crtc);
-
for_each_oldnew_plane_in_state(state, plane, old_plane_state,
new_plane_state, i) {
ret = drm_atomic_plane_check(old_plane_state, new_plane_state);
if (ret) {
@@ -1362,26 +1353,6 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
- affected_crtc |= drm_crtc_mask(crtc);
-
- /*
-* For commits that allow modesets drivers can add other CRTCs to the
-* atomic commit, e.g. when they need to reallocate global resources.
-* This can cause spurious EBUSY, which robs compositors of a very
-* effective sanity check for their drawing loop. Therefor only allow
-* drivers to add unrelated CRTC states for modeset commits.
-*
-* FIXME: Should add affected_crtc mask to the ATOMIC IOCTL as an output
-* so compositors know what's going on.
-*/
- if (affected_crtc != requested_crtc) {
- DRM_DEBUG_ATOMIC("driver added CRTC to commit: requested 0x%x,
affected 0x%0x\n",
-requested_crtc, affected_crtc);
- WARN(!state->allow_modeset, "adding CRTC not allowed without
modesets: requested 0x%x, affected 0x%0x\n",
-requested_crtc, affected_crtc);
- }
-
return 0;
}
EXPORT_SYMBOL(drm_atomic_check_only);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Quoting Hans de Goede (2021-02-09 11:46:46) > Hi, > > On 2/9/21 12:27 AM, Chris Wilson wrote: > > Quoting Hans de Goede (2021-02-08 20:38:58) > >> Hi All, > >> > >> We (Fedora) have been receiving reports from multiple users about gfx > >> issues / glitches > >> stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs > >> and all > >> reporters report that adding i915.mitigations=off to the cmdline fixes > >> things, see: > > > > I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit > > did not report any differences with and without mitigations. I have yet > > to test other platforms. So I don't yet have an alternative. > > Note the original / first reporter of: > > https://bugzilla.redhat.com/show_bug.cgi?id=1925346 > > Is using hsw-gt2, so it seems that the problem is not just the enabling of > the mitigations on ivy-bridge / bay-trail but that there actually is > a regression on devices where the WA worked fine before... There have been 3 crashes uploaded related to v5.10.9, and in all 3 cases the ACTHD has been in the first page. This strongly suggests that the w/a is scribbling over address 0. And there's then a very good chance that commit 29d35b73ead4e41aa0d1a954c9bfbdce659ec5d6 Author: Chris Wilson Date: Mon Jan 25 12:50:33 2021 + drm/i915/gt: Always try to reserve GGTT address 0x0 commit 489140b5ba2e7cc4b853c29e0591895ddb462a82 upstream. in v5.10.14 is sufficient to hide the issue. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr
== Series Details == Series: series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr URL : https://patchwork.freedesktop.org/series/86910/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752_full -> Patchwork_19644_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19644_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([i915#1895] / [i915#2295] / [i915#3031]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@gem_exec_balan...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-iclb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-kbl4/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-kbl: NOTRUN -> [FAIL][5] ([i915#2389]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-kbl4/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-apl2/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][7] ([i915#2658]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-kbl4/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][8] ([fdo#109271]) +56 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-kbl6/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1699]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-apl2/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][10] -> [DMESG-WARN][11] ([i915#1436] / [i915#716]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-skl9/igt@gen9_exec_pa...@allowed-single.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-skl5/igt@gen9_exec_pa...@allowed-single.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-kbl6/igt@i915_pm...@dc3co-vpb-simulation.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@i915_pm...@dc6-psr.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-iclb2/igt@i915_pm...@dc6-psr.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1937]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-apl2/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180]) +4 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-apl4/igt@i915_susp...@sysfs-reader.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-apl4/igt@i915_susp...@sysfs-reader.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-snb: [PASS][18] -> [FAIL][19] ([i915#2521]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-snb6/igt@kms_async_fl...@alternate-sync-async-flip.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-snb6/igt@kms_async_fl...@alternate-sync-async-flip.html * igt@kms_big_joiner@invalid-modeset: - shard-kbl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2705]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-kbl6/igt@kms_big_joi...@invalid-modeset.html * igt@kms_chamelium@hdmi-audio: - shard-skl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/shard-skl9/igt@kms_chamel...@hdmi-audio.html * igt@kms_chamelium@hdmi-hpd-storm-disable: - shard-kbl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +6 similar issues [22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries
== Series Details == Series: drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries URL : https://patchwork.freedesktop.org/series/86908/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752_full -> Patchwork_19643_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19643_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@bcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-kbl7/igt@gem_ctx_isolation@preservation...@bcs0.html * igt@gem_ctx_persistence@legacy-engines-persistence: - shard-hsw: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-hsw6/igt@gem_ctx_persiste...@legacy-engines-persistence.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([i915#1037] / [i915#180]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-apl3/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-apl3/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][6] -> [TIMEOUT][7] ([i915#1037] / [i915#3063]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-tglb8/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-tglb7/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-kbl6/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-sync@rcs0: - shard-kbl: [PASS][12] -> [SKIP][13] ([fdo#109271]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl1/igt@gem_exec_fair@basic-s...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-kbl6/igt@gem_exec_fair@basic-s...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@rcs0: - shard-kbl: NOTRUN -> [FAIL][14] ([i915#2389]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-kbl6/igt@gem_exec_reloc@basic-wide-act...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2389]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#1610]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-apl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-apl1/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][18] -> [DMESG-WARN][19] ([i915#1610] / [i915#2803]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-skl4/igt@gem_exec_schedule@u-fairsl...@vcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-skl4/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_whisper@basic-queues: - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#118] / [i915#95]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-glk6/igt@gem_exec_whis...@basic-queues.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-glk2/igt@gem_exec_whis...@basic-queues.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#2190]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-apl6/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][23] ([i915#2658]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/shard-kbl3/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1699]) +3
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9_bc: Add TGP PCH support
== Series Details == Series: drm/i915/gen9_bc: Add TGP PCH support URL : https://patchwork.freedesktop.org/series/86918/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752 -> Patchwork_19646 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/index.html Known issues Here are the changes found in Patchwork_19646 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +26 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#2283]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@gt_pm: - fi-icl-y: [PASS][3] -> [DMESG-FAIL][4] ([i915#2291]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-icl-y/igt@i915_selftest@live@gt_pm.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/fi-icl-y/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@prime_self_import@basic-with_one_bo: - fi-tgl-y: [PASS][6] -> [DMESG-WARN][7] ([i915#402]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/fi-tgl-y/igt@prime_self_import@basic-with_one_bo.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][8] ([i915#402]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2291]: https://gitlab.freedesktop.org/drm/intel/issues/2291 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9752 -> Patchwork_19646 CI-20190529: 20190529 CI_DRM_9752: a99b75af1722e15bade7f41dca4227bc907561aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19646: ce45e5062ad419c728947634615a931abd049890 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ce45e5062ad4 drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos 00411d8a417f drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combos 7812d10de3b7 drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings 3c2b1a4f667c drm/i915/gen9_bc: Recognize TGP PCH + CML combos == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19646/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time (rev2)
== Series Details == Series: drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time (rev2) URL : https://patchwork.freedesktop.org/series/86773/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752 -> Patchwork_19645 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/index.html Known issues Here are the changes found in Patchwork_19645 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +26 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#2283]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_module_load@reload: - fi-kbl-7500u: [PASS][3] -> [DMESG-WARN][4] ([i915#2605]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-kbl-7500u/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/fi-kbl-7500u/igt@i915_module_l...@reload.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@vgem_basic@setversion: - fi-tgl-y: [PASS][6] -> [DMESG-WARN][7] ([i915#402]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@vgem_ba...@setversion.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/fi-tgl-y/igt@vgem_ba...@setversion.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][8] ([i915#402]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9752 -> Patchwork_19645 CI-20190529: 20190529 CI_DRM_9752: a99b75af1722e15bade7f41dca4227bc907561aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19645: ebfffda464cba6b46df4bf88f979d0d71e05c971 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ebfffda464cb drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19645/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/4] drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combos
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc
platform in order to make hotplugging display connectors work. Since
gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD
mappings as ICL, we simply add a skl_hpd_pin function that is shared
between gen9 and gen9_bc which handles both the traditional gen9 HPD pin
mappings and the Icelake HPD pin mappings that gen9_bc uses.
Changes since v4:
* Split this into its own commit
* Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of
sticking our HPD pin mappings in TGP code
Cc: Matt Roper
Cc: Jani Nikula
Cc: Ville Syrjala
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 3c4003605f93..01b171f52694 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3954,6 +3954,14 @@ static enum hpd_pin cnl_hpd_pin(struct drm_i915_private
*dev_priv,
return HPD_PORT_A + port - PORT_A;
}
+static enum hpd_pin skl_hpd_pin(struct drm_i915_private *dev_priv, enum port
port)
+{
+ if (HAS_PCH_TGP(dev_priv))
+ return icl_hpd_pin(dev_priv, port);
+
+ return HPD_PORT_A + port - PORT_A;
+}
+
#define port_tc_name(port) ((port) - PORT_TC1 + '1')
#define tc_port_name(tc_port) ((tc_port) - TC_PORT_1 + '1')
@@ -4070,6 +4078,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
encoder->hpd_pin = icl_hpd_pin(dev_priv, port);
else if (IS_GEN(dev_priv, 10))
encoder->hpd_pin = cnl_hpd_pin(dev_priv, port);
+ else if (IS_GEN(dev_priv, 9))
+ encoder->hpd_pin = skl_hpd_pin(dev_priv, port);
else
encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos
Apparently the new gen9_bc platforms that Intel has introduced don't
provide us with a STRAP config register to read from for initializing DDI
B, C, and D detection. So, workaround this by hard-coding our strap config
in intel_setup_outputs().
Changes since v4:
* Split this into it's own commit
Cc: Matt Roper
Cc: Jani Nikula
Cc: Ville Syrjala
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_display.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index beed08c00b6c..4dee37f8659d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11943,7 +11943,14 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
/* DDI B, C, D, and F detection is indicated by the SFUSE_STRAP
* register */
- found = intel_de_read(dev_priv, SFUSE_STRAP);
+ if (HAS_PCH_TGP(dev_priv)) {
+ /* W/A due to lack of STRAP config on TGP PCH*/
+ found = (SFUSE_STRAP_DDIB_DETECTED |
+SFUSE_STRAP_DDIC_DETECTED |
+SFUSE_STRAP_DDID_DETECTED);
+ } else {
+ found = intel_de_read(dev_priv, SFUSE_STRAP);
+ }
if (found & SFUSE_STRAP_DDIB_DETECTED)
intel_ddi_init(dev_priv, PORT_B);
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/4] drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings
With the introduction of gen9_bc, where Intel combines Cometlake CPUs with
a Tigerpoint PCH, we'll need to introduce new DDC pin mappings for this
platform in order to make all of the display connectors work. So, let's do
that.
Changes since v4:
* Split this into it's own patch - vsyrjala
Cc: Matt Roper
Cc: Jani Nikula
Cc: Ville Syrjala
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_bios.c | 9 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 20
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 7118530a1c38..1289f9d437e4 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1638,6 +1638,12 @@ static const u8 adls_ddc_pin_map[] = {
[ADLS_DDC_BUS_PORT_TC4] = GMBUS_PIN_12_TC4_ICP,
};
+static const u8 gen9bc_tgp_ddc_pin_map[] = {
+ [DDC_BUS_DDI_B] = GMBUS_PIN_2_BXT,
+ [DDC_BUS_DDI_C] = GMBUS_PIN_9_TC1_ICP,
+ [DDC_BUS_DDI_D] = GMBUS_PIN_10_TC2_ICP,
+};
+
static u8 map_ddc_pin(struct drm_i915_private *dev_priv, u8 vbt_pin)
{
const u8 *ddc_pin_map;
@@ -1651,6 +1657,9 @@ static u8 map_ddc_pin(struct drm_i915_private *dev_priv,
u8 vbt_pin)
} else if (IS_ROCKETLAKE(dev_priv) && INTEL_PCH_TYPE(dev_priv) ==
PCH_TGP) {
ddc_pin_map = rkl_pch_tgp_ddc_pin_map;
n_entries = ARRAY_SIZE(rkl_pch_tgp_ddc_pin_map);
+ } else if (HAS_PCH_TGP(dev_priv) && IS_GEN9_BC(dev_priv)) {
+ ddc_pin_map = gen9bc_tgp_ddc_pin_map;
+ n_entries = ARRAY_SIZE(gen9bc_tgp_ddc_pin_map);
} else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP) {
ddc_pin_map = icp_ddc_pin_map;
n_entries = ARRAY_SIZE(icp_ddc_pin_map);
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index dad54e116bc4..49528d07c7f3 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3138,6 +3138,24 @@ static u8 rkl_port_to_ddc_pin(struct drm_i915_private
*dev_priv, enum port port)
return GMBUS_PIN_1_BXT + phy;
}
+static u8 gen9bc_port_to_ddc_pin(struct drm_i915_private *i915, enum port port)
+{
+ enum phy phy = intel_port_to_phy(i915, port);
+
+ drm_WARN_ON(>drm, port == PORT_A);
+
+ /*
+* Pin mapping for GEN9 BC depends on which PCH is present. With TGP,
+* final two outputs use type-c pins, even though they're actually
+* combo outputs. With CMP, the traditional DDI A-D pins are used for
+* all outputs.
+*/
+ if (INTEL_PCH_TYPE(i915) >= PCH_TGP && phy >= PHY_C)
+ return GMBUS_PIN_9_TC1_ICP + phy - PHY_C;
+
+ return GMBUS_PIN_1_BXT + phy;
+}
+
static u8 dg1_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port
port)
{
return intel_port_to_phy(dev_priv, port) + 1;
@@ -3202,6 +3220,8 @@ static u8 intel_hdmi_ddc_pin(struct intel_encoder
*encoder)
ddc_pin = dg1_port_to_ddc_pin(dev_priv, port);
else if (IS_ROCKETLAKE(dev_priv))
ddc_pin = rkl_port_to_ddc_pin(dev_priv, port);
+ else if (IS_GEN9_BC(dev_priv) && HAS_PCH_TGP(dev_priv))
+ ddc_pin = gen9bc_port_to_ddc_pin(dev_priv, port);
else if (HAS_PCH_MCC(dev_priv))
ddc_pin = mcc_port_to_ddc_pin(dev_priv, port);
else if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
--
2.29.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/4] drm/i915/gen9_bc: Recognize TGP PCH + CML combos
Since Intel has introduced the gen9_bc platform, a combination of Tigerpoint PCHs and CML CPUs, let's recognize such platforms as valid and avoid WARNing on them. Changes since v4: * Split this into it's own patch - vsyrjala Cc: Matt Roper Cc: Jani Nikula Cc: Ville Syrjala [originally from Tejas's work] Signed-off-by: Tejas Upadhyay Signed-off-by: Lyude Paul --- drivers/gpu/drm/i915/intel_pch.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c index 4813207fc053..7476f0e063c6 100644 --- a/drivers/gpu/drm/i915/intel_pch.c +++ b/drivers/gpu/drm/i915/intel_pch.c @@ -121,7 +121,8 @@ intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id) case INTEL_PCH_TGP2_DEVICE_ID_TYPE: drm_dbg_kms(_priv->drm, "Found Tiger Lake LP PCH\n"); drm_WARN_ON(_priv->drm, !IS_TIGERLAKE(dev_priv) && - !IS_ROCKETLAKE(dev_priv)); + !IS_ROCKETLAKE(dev_priv) && + !IS_GEN9_BC(dev_priv)); return PCH_TGP; case INTEL_PCH_JSP_DEVICE_ID_TYPE: case INTEL_PCH_JSP2_DEVICE_ID_TYPE: -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/4] drm/i915/gen9_bc: Add TGP PCH support
This is to add basic support for Intel's new gen9_bc platform, which consists of a combination of a TGP PCH along with a CML CPU. This is also a continuation of the work from Tejaskumar Surendrakumar Upadhyay with the various review comments addressed. Lyude Paul (4): drm/i915/gen9_bc: Recognize TGP PCH + CML combos drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combos drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos drivers/gpu/drm/i915/display/intel_bios.c| 9 + drivers/gpu/drm/i915/display/intel_ddi.c | 10 ++ drivers/gpu/drm/i915/display/intel_display.c | 9 - drivers/gpu/drm/i915/display/intel_hdmi.c| 20 drivers/gpu/drm/i915/intel_pch.c | 3 ++- 5 files changed, 49 insertions(+), 2 deletions(-) -- 2.29.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/debugfs : PM_REQ and PM_RES registers (rev4)
== Series Details == Series: drm/i915/debugfs : PM_REQ and PM_RES registers (rev4) URL : https://patchwork.freedesktop.org/series/85437/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752_full -> Patchwork_19642_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19642_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@close-replace-race: - shard-glk: [PASS][1] -> [TIMEOUT][2] ([i915#2918]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-glk6/igt@gem_ctx_persiste...@close-replace-race.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-glk2/igt@gem_ctx_persiste...@close-replace-race.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1037] / [i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-apl3/igt@gem_...@in-flight-suspend.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-apl8/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#3063]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-tglb8/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-tglb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_balancer@hang: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([i915#1895] / [i915#2295] / [i915#3031]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@gem_exec_balan...@hang.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-iclb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-kbl1/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-glk6/igt@gem_exec_fair@basic-p...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-glk2/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][14] ([i915#2389]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#1610]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-apl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-apl6/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-iclb: [PASS][17] -> [DMESG-WARN][18] ([i915#2803]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@vcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-iclb3/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_whisper@basic-queues-forked: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([i915#1895] / [i915#2405]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/shard-iclb1/igt@gem_exec_whis...@basic-queues-forked.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-iclb5/igt@gem_exec_whis...@basic-queues-forked.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][22] ([i915#2658]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-kbl4/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@mmap-offset-invalidate-active@wb: - shard-kbl: NOTRUN -> [SKIP][23] ([fdo#109271]) +52 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/shard-kbl1/igt@gem_userptr_blits@mmap-offset-invalidate-act...@wb.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1699]) +3 similar issues [24]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
== Series Details == Series: series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling URL : https://patchwork.freedesktop.org/series/86882/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19637_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19637_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][1] -> [TIMEOUT][2] ([i915#1037] / [i915#2771]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-skl3/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-apl8/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2389]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#1610]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-apl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-apl8/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_whisper@basic-contexts-forked: - shard-iclb: [PASS][12] -> [INCOMPLETE][13] ([i915#1895]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb3/igt@gem_exec_whis...@basic-contexts-forked.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-iclb7/igt@gem_exec_whis...@basic-contexts-forked.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1699]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-skl10/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1699]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-apl1/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1937]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-apl1/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_pm_rpm@modeset-lpsp-stress: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271]) +75 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-apl1/igt@i915_pm_...@modeset-lpsp-stress.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +6 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-apl6/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_chamelium@vga-hpd-enable-disable-mode: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-kbl7/igt@kms_chamel...@vga-hpd-enable-disable-mode.html * igt@kms_color_chamelium@pipe-d-ctm-0-5: - shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109284] / [fdo#111827]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/shard-tglb6/igt@kms_color_chamel...@pipe-d-ctm-0-5.html * igt@kms_cursor_crc@pipe-c-cursor-64x21-random: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#54]) +9 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-64x21-random.html [22]:
[Intel-gfx] [PATCH v2] drm/i915/display: Allow PSR2 selective fetch to be enabled at run-time
Right now CI is blacklisting module reload, so we need to be able to
enable PSR2 selective fetch in run time to test this feature before
enable it by default.
Changes in IGT will also be needed.
v2:
- Fixed handling of I915_PSR_DEBUG_ENABLE_SEL_FETCH in
intel_psr_debug_set()
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 8 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ebaa9d0ed376..577f47aa6b3e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1425,6 +1425,7 @@ struct intel_psr {
#define I915_PSR_DEBUG_DISABLE 0x01
#define I915_PSR_DEBUG_ENABLE 0x02
#define I915_PSR_DEBUG_FORCE_PSR1 0x03
+#define I915_PSR_DEBUG_ENABLE_SEL_FETCH0x4
#define I915_PSR_DEBUG_IRQ 0x10
u32 debug;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index bf214d0e2dec..43e9e362382b 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -684,7 +684,8 @@ static bool intel_psr2_sel_fetch_config_valid(struct
intel_dp *intel_dp,
struct intel_plane *plane;
int i;
- if (!dev_priv->params.enable_psr2_sel_fetch) {
+ if (!dev_priv->params.enable_psr2_sel_fetch &&
+ intel_dp->psr.debug != I915_PSR_DEBUG_ENABLE_SEL_FETCH) {
drm_dbg_kms(_priv->drm,
"PSR2 sel fetch not enabled, disabled by
parameter\n");
return false;
@@ -1448,7 +1449,8 @@ void intel_psr_update(struct intel_dp *intel_dp,
enable = crtc_state->has_psr;
psr2_enable = crtc_state->has_psr2;
- if (enable == psr->enabled && psr2_enable == psr->psr2_enabled) {
+ if (enable == psr->enabled && psr2_enable == psr->psr2_enabled &&
+ crtc_state->enable_psr2_sel_fetch == psr->psr2_sel_fetch_enabled) {
/* Force a PSR exit when enabling CRC to avoid CRC timeouts */
if (crtc_state->crc_enabled && psr->enabled)
psr_force_hw_tracking_exit(intel_dp);
@@ -1637,7 +1639,7 @@ int intel_psr_debug_set(struct intel_dp *intel_dp, u64
val)
int ret;
if (val & ~(I915_PSR_DEBUG_IRQ | I915_PSR_DEBUG_MODE_MASK) ||
- mode > I915_PSR_DEBUG_FORCE_PSR1) {
+ mode > I915_PSR_DEBUG_ENABLE_SEL_FETCH) {
drm_dbg_kms(_priv->drm, "Invalid debug mask %llx\n", val);
return -EINVAL;
}
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries
On Tue, Feb 09, 2021 at 09:42:38AM -0800, José Roberto de Souza wrote:
> Set the right BW buddy page mask for new memory types.
>
> BSpec: 49218
> Cc: Clint Taylor
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: José Roberto de Souza
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display_power.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index e17b1ca356c3..f00c1750febd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -5317,17 +5317,25 @@ struct buddy_page_mask {
>
> static const struct buddy_page_mask tgl_buddy_page_masks[] = {
> { .num_channels = 1, .type = INTEL_DRAM_DDR4, .page_mask = 0xF },
> + { .num_channels = 1, .type = INTEL_DRAM_DDR5, .page_mask = 0xF },
> { .num_channels = 2, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x1C },
> + { .num_channels = 2, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x1C },
> { .num_channels = 2, .type = INTEL_DRAM_DDR4, .page_mask = 0x1F },
> + { .num_channels = 2, .type = INTEL_DRAM_DDR5, .page_mask = 0x1E },
> { .num_channels = 4, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x38 },
> + { .num_channels = 4, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x38 },
> {}
> };
>
> static const struct buddy_page_mask wa_1409767108_buddy_page_masks[] = {
> { .num_channels = 1, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x1 },
> { .num_channels = 1, .type = INTEL_DRAM_DDR4, .page_mask = 0x1 },
> + { .num_channels = 1, .type = INTEL_DRAM_DDR5, .page_mask = 0x1 },
> + { .num_channels = 1, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x1 },
> { .num_channels = 2, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x3 },
> { .num_channels = 2, .type = INTEL_DRAM_DDR4, .page_mask = 0x3 },
> + { .num_channels = 2, .type = INTEL_DRAM_DDR5, .page_mask = 0x3 },
> + { .num_channels = 2, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x3 },
> {}
> };
>
> --
> 2.30.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gen9bc: Handle TGP PCH during suspend/resume
..snip.. (comments down below) On Tue, 2021-02-02 at 18:14 +0200, Imre Deak wrote: > > BSpec says about this WA for both ICL and TGL: > """ > Display driver should set and clear register offset 0xC2000 bit #7 as > last step in programming south display registers in preparation for > entering S0ix state, or set 0xC2000 bit #7 on S0ix entry and clear it on > S0ix exit. > > """ > > This means to me the WA is only relevant for S0ix and we can implement > it by setting/clearing 0xC2000 bit #7 right before entering/right after > exiting S0ix. This is done atm on PCH_ICP..PCH_MCC in > intel_display_power_suspend_late()/intel_display_power_resume_early(), > so I'd move the WA for all platforms there. > > I assume the current code in irq_reset() was the first alternative to > implement the WA, but it wasn't enough. Not sure why, maybe there is a > south display register access after irq_reset() during suspend. Adding > Anshuman for an idea on that. > Poking Anshuman here, is there any update on this? I'm looking to push these patches forward as some of Red Hat's hardware partners are very eager for this to get upstream asap as we're running out of time from our end. If you can answer this, I can handle respinning this patch as needed. > --Imre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr
== Series Details == Series: series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr URL : https://patchwork.freedesktop.org/series/86910/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752 -> Patchwork_19644 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/index.html Known issues Here are the changes found in Patchwork_19644 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +26 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-kbl-7500u: [PASS][2] -> [DMESG-WARN][3] ([i915#2605]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#2283]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#2411] / [i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@i915_pm_rpm@module-reload: - fi-byt-j1900: [PASS][7] -> [INCOMPLETE][8] ([i915#142] / [i915#2405]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-byt-j1900/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-byt-j1900/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][9] -> [INCOMPLETE][10] ([i915#2940]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@dp-crc-fast: - fi-bdw-5557u: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [PASS][12] -> [DMESG-WARN][13] ([i915#402]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-tgl-y/igt@prime_v...@basic-fence-flip.html * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][14] ([i915#1436]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-bsw-nick/igt@run...@aborted.html - fi-byt-j1900: NOTRUN -> [FAIL][15] ([i915#1814] / [i915#2505]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-byt-j1900/igt@run...@aborted.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][16] ([i915#402]) -> [PASS][17] +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19644/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#142]: https://gitlab.freedesktop.org/drm/intel/issues/142 [i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436 [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#2505]: https://gitlab.freedesktop.org/drm/intel/issues/2505 [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605 [i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9752 -> Patchwork_19644 CI-20190529: 20190529 CI_DRM_9752: a99b75af1722e15bade7f41dca4227bc907561aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr
== Series Details == Series: series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr URL : https://patchwork.freedesktop.org/series/86910/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr
== Series Details == Series: series starting with [1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr URL : https://patchwork.freedesktop.org/series/86910/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1edc3ad07376 drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr -:25: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #25: FILE: drivers/gpu/drm/i915/display/intel_display.h:421: +#define for_each_intel_encoder_mask_with_psr(dev, intel_encoder, encoder_mask) \ list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list, base.head) \ for_each_if(((encoder_mask) & drm_encoder_mask(&(intel_encoder)->base)) && \ intel_encoder_can_psr(intel_encoder)) -:25: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_encoder' - possible side-effects? #25: FILE: drivers/gpu/drm/i915/display/intel_display.h:421: +#define for_each_intel_encoder_mask_with_psr(dev, intel_encoder, encoder_mask) \ list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list, base.head) \ for_each_if(((encoder_mask) & drm_encoder_mask(&(intel_encoder)->base)) && \ intel_encoder_can_psr(intel_encoder)) -:34: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #34: FILE: drivers/gpu/drm/i915/display/intel_display.h:430: +#define for_each_intel_encoder_with_psr(dev, intel_encoder) \ for_each_intel_encoder((dev), (intel_encoder)) \ for_each_if(intel_encoder_can_psr(intel_encoder)) -:34: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_encoder' - possible side-effects? #34: FILE: drivers/gpu/drm/i915/display/intel_display.h:430: +#define for_each_intel_encoder_with_psr(dev, intel_encoder) \ for_each_intel_encoder((dev), (intel_encoder)) \ for_each_if(intel_encoder_can_psr(intel_encoder)) total: 2 errors, 0 warnings, 2 checks, 92 lines checked fe6bbcba6125 drm/i915/display: Only write to register in intel_psr2_program_trans_man_trk_ctl() 889eeb0a82dd drm/i915/display: Remove some redundancy around CAN_PSR() -:29: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'intel_dp' - possible side-effects? #29: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:1796: +#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \ + (intel_dp)->psr.source_support) total: 0 errors, 0 warnings, 1 checks, 35 lines checked 6c507f7a8c35 drm/i915/display: Set source_support even if panel do not support PSR ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries
== Series Details == Series: drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries URL : https://patchwork.freedesktop.org/series/86908/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752 -> Patchwork_19643 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/index.html Known issues Here are the changes found in Patchwork_19643 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@memory-alloc: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/fi-tgl-y/igt@amdgpu/amd_ba...@memory-alloc.html * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][2] ([fdo#109271]) +26 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][3] ([i915#2283]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_getparams_basic@basic-subslice-total: - fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/fi-tgl-y/igt@i915_getparams_ba...@basic-subslice-total.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_19643/fi-bdw-5557u/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 38) -- Missing(6): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-byt-j1900 fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9752 -> Patchwork_19643 CI-20190529: 20190529 CI_DRM_9752: a99b75af1722e15bade7f41dca4227bc907561aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19643: e4bad3c4ea5816aff10e8e1b76e9a0db3e232eee @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e4bad3c4ea58 drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19643/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/display: Set source_support even if panel do not support PSR
This will set the right value of source_support when the port encoder/port supports PSR but sink don't. This change will also be needed in future for panel replay as psr struct needs to be initialized even if disconnected or current sink don't support PSR. Cc: Gwan-gyeong Mun Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_psr.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index e0111b470570..6b3e2120161e 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -1837,9 +1837,6 @@ void intel_psr_init(struct intel_dp *intel_dp) if (!HAS_PSR(dev_priv)) return; - if (!intel_dp->psr.sink_support) - return; - /* * HSW spec explicitly says PSR is tied to port A. * BDW+ platforms have a instance of PSR registers per transcoder but -- 2.30.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/display: Only write to register in intel_psr2_program_trans_man_trk_ctl()
There is no support for two pipes one transcoder for PSR and if we had
that the current code should not use cpu_transcoder.
Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch is
set and PSR is not enabled and if by a bug it happens PSR HW will just
ignore any value in set in PSR2_MAN_TRK_CTL.
So dropping all the rest and keeping the same behavior that we have
with intel_psr2_program_plane_sel_fetch().
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 1d3903612fcb..8ad9fcff3a12 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1226,23 +1226,13 @@ void intel_psr2_program_plane_sel_fetch(struct
intel_plane *plane,
void intel_psr2_program_trans_man_trk_ctl(const struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
- struct intel_encoder *encoder;
if (!HAS_PSR2_SEL_FETCH(dev_priv) ||
!crtc_state->enable_psr2_sel_fetch)
return;
- for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
-crtc_state->uapi.encoder_mask) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- if (!intel_dp->psr.enabled)
- continue;
-
- intel_de_write(dev_priv,
- PSR2_MAN_TRK_CTL(crtc_state->cpu_transcoder),
- crtc_state->psr2_man_track_ctl);
- }
+ intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(crtc_state->cpu_transcoder),
+ crtc_state->psr2_man_track_ctl);
}
static void psr2_man_trk_ctl_calc(struct intel_crtc_state *crtc_state,
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/display: Remove some redundancy around CAN_PSR()
If source_support is set the platform supports PSR so no need to check
it again at every CAN_PSR().
Also removing the intel_dp_is_edp() calls, if sink_support is set
the sink connected is for sure a eDP panel.
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_types.h | 5 ++---
drivers/gpu/drm/i915/display/intel_dp.c| 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index ebaa9d0ed376..4a46c4e9b0ac 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1793,9 +1793,8 @@ dp_to_i915(struct intel_dp *intel_dp)
return to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
}
-#define CAN_PSR(intel_dp) (HAS_PSR(dp_to_i915(intel_dp)) && \
-(intel_dp)->psr.sink_support && \
-(intel_dp)->psr.source_support)
+#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
+ (intel_dp)->psr.source_support)
static inline bool intel_encoder_can_psr(struct intel_encoder *encoder)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4f89e0de5dde..0a0cc61344c4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2358,7 +2358,7 @@ bool intel_dp_initial_fastset_check(struct intel_encoder
*encoder,
return false;
}
- if (CAN_PSR(intel_dp) && intel_dp_is_edp(intel_dp)) {
+ if (CAN_PSR(intel_dp)) {
drm_dbg_kms(>drm, "Forcing full modeset to compute PSR
state\n");
crtc_state->uapi.mode_changed = true;
return false;
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 8ad9fcff3a12..e0111b470570 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1962,7 +1962,7 @@ void intel_psr_short_pulse(struct intel_dp *intel_dp)
DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
DP_PSR_LINK_CRC_ERROR;
- if (!CAN_PSR(intel_dp) || !intel_dp_is_edp(intel_dp))
+ if (!CAN_PSR(intel_dp))
return;
mutex_lock(>lock);
@@ -2012,7 +2012,7 @@ bool intel_psr_enabled(struct intel_dp *intel_dp)
{
bool ret;
- if (!CAN_PSR(intel_dp) || !intel_dp_is_edp(intel_dp))
+ if (!CAN_PSR(intel_dp))
return false;
mutex_lock(_dp->psr.lock);
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr
for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion
"with_psr" is better.
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.h | 4 ++--
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 +++---
drivers/gpu/drm/i915/display/intel_psr.c | 12 ++--
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e3757ecabbf7..c60a58ba60ee 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -418,7 +418,7 @@ enum phy_fia {
for_each_if((encoder_mask) &\
drm_encoder_mask(_encoder->base))
-#define for_each_intel_encoder_mask_can_psr(dev, intel_encoder, encoder_mask) \
+#define for_each_intel_encoder_mask_with_psr(dev, intel_encoder, encoder_mask)
\
list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list,
base.head) \
for_each_if(((encoder_mask) &
drm_encoder_mask(&(intel_encoder)->base)) && \
intel_encoder_can_psr(intel_encoder))
@@ -427,7 +427,7 @@ enum phy_fia {
for_each_intel_encoder(dev, intel_encoder) \
for_each_if(intel_encoder_is_dp(intel_encoder))
-#define for_each_intel_encoder_can_psr(dev, intel_encoder) \
+#define for_each_intel_encoder_with_psr(dev, intel_encoder) \
for_each_intel_encoder((dev), (intel_encoder)) \
for_each_if(intel_encoder_can_psr(intel_encoder))
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d6e4a9237bda..7ce11d851163 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -437,7 +437,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
return -ENODEV;
/* Find the first EDP which supports PSR */
- for_each_intel_encoder_can_psr(_priv->drm, encoder) {
+ for_each_intel_encoder_with_psr(_priv->drm, encoder) {
intel_dp = enc_to_intel_dp(encoder);
break;
}
@@ -459,7 +459,7 @@ i915_edp_psr_debug_set(void *data, u64 val)
if (!HAS_PSR(dev_priv))
return ret;
- for_each_intel_encoder_can_psr(_priv->drm, encoder) {
+ for_each_intel_encoder_with_psr(_priv->drm, encoder) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
drm_dbg_kms(_priv->drm, "Setting PSR debug to %llx\n", val);
@@ -484,7 +484,7 @@ i915_edp_psr_debug_get(void *data, u64 *val)
if (!HAS_PSR(dev_priv))
return -ENODEV;
- for_each_intel_encoder_can_psr(_priv->drm, encoder) {
+ for_each_intel_encoder_with_psr(_priv->drm, encoder) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
// TODO: split to each transcoder's PSR debug state
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index bf214d0e2dec..1d3903612fcb 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1232,8 +1232,8 @@ void intel_psr2_program_trans_man_trk_ctl(const struct
intel_crtc_state *crtc_st
!crtc_state->enable_psr2_sel_fetch)
return;
- for_each_intel_encoder_mask_can_psr(_priv->drm, encoder,
- crtc_state->uapi.encoder_mask) {
+ for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
+crtc_state->uapi.encoder_mask) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
if (!intel_dp->psr.enabled)
@@ -1515,8 +1515,8 @@ void intel_psr_wait_for_idle(const struct
intel_crtc_state *new_crtc_state)
if (!new_crtc_state->has_psr)
return;
- for_each_intel_encoder_mask_can_psr(_priv->drm, encoder,
- new_crtc_state->uapi.encoder_mask) {
+ for_each_intel_encoder_mask_with_psr(_priv->drm, encoder,
+new_crtc_state->uapi.encoder_mask)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
u32 psr_status;
@@ -1730,7 +1730,7 @@ void intel_psr_invalidate(struct drm_i915_private
*dev_priv,
if (origin == ORIGIN_FLIP)
return;
- for_each_intel_encoder_can_psr(_priv->drm, encoder) {
+ for_each_intel_encoder_with_psr(_priv->drm, encoder) {
unsigned int pipe_frontbuffer_bits = frontbuffer_bits;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -1802,7 +1802,7 @@ void
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86895/ State : success == Summary == CI Bug Log - changes from CI_DRM_9750_full -> Patchwork_19641_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19641_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@hang: - shard-hsw: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-hsw6/igt@gem_ctx_persiste...@hang.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][2] -> [FAIL][3] ([i915#2842]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-iclb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-tglb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-many-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2389]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-iclb2/igt@gem_exec_reloc@basic-many-act...@vcs1.html * igt@gem_exec_reloc@basic-parallel: - shard-kbl: NOTRUN -> [TIMEOUT][12] ([i915#1729]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-kbl1/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#2803]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-skl3/igt@gem_exec_schedule@u-fairsl...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-skl2/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_schedule@u-fairslice@vcs1: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#1610] / [i915#2803]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-kbl4/igt@gem_exec_schedule@u-fairsl...@vcs1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-kbl2/igt@gem_exec_schedule@u-fairsl...@vcs1.html * igt@gem_exec_whisper@basic-queues-priority: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([i915#1895]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-iclb3/igt@gem_exec_whis...@basic-queues-priority.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-iclb2/igt@gem_exec_whis...@basic-queues-priority.html * igt@gem_userptr_blits@input-checking: - shard-apl: NOTRUN -> [DMESG-WARN][19] ([i915#3002]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-apl4/igt@gem_userptr_bl...@input-checking.html * igt@gem_userptr_blits@vma-merge: - shard-iclb: NOTRUN -> [INCOMPLETE][20] ([i915#2502] / [i915#2667]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-iclb6/igt@gem_userptr_bl...@vma-merge.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][21] -> [INCOMPLETE][22] ([i915#1630]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-apl8/igt@gem_workarou...@suspend-resume.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/shard-apl7/igt@gem_workarou...@suspend-resume.html * igt@gen9_exec_parse@allowed-single: - shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#1436] / [i915#716]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/shard-kbl7/igt@gen9_exec_pa...@allowed-single.html [24]:
Re: [Intel-gfx] [PATCH 01/31] drm/i915/gt: Ratelimit heartbeat completion probing
Chris Wilson writes:
> The heartbeat runs through a few phases that we expect to complete
> within a certain number of heartbeat intervals. First we must submit the
> heartbeat to the queue, and if the queue is occupied it may take a
> couple of intervals before the heartbeat preempts the workload and is
> submitted to HW. Once running on HW, completion is not instantaneous as
> it may have to first reset the current workload before it itself runs
> through the empty request and signals completion. As such, we know that
> the heartbeat must take at least the preempt reset timeout and before we
> have had a chance to reset the engine, we do not want to issue a global
> reset ourselves (simply so that we only try to do one reset at a time
> and not confuse ourselves by resetting twice and hitting an innocent.)
>
> So by taking into consideration that once running the request must take
> a finite amount of time, we can delay the final completion check to
> accommodate that and avoid checking too early (before we've had a chance
> to handle any engine resets required).
>
> v2: Attach a callback to flush the work immediately upon the heartbeat
> completion and insert the delay before the next.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2853
> Suggested-by: CQ Tang
> Signed-off-by: Chris Wilson
> ---
> .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 95 ---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> .../drm/i915/gt/selftest_engine_heartbeat.c | 65 ++---
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 5 +-
> 4 files changed, 117 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 0b062fad1837..209a477af412 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -20,6 +20,18 @@
> * issue a reset -- in the hope that restores progress.
> */
>
> +#define HEARTBEAT_COMPLETION 50u /* milliseconds */
> +
> +static long completion_timeout(const struct intel_engine_cs *engine)
> +{
> + long timeout = HEARTBEAT_COMPLETION;
> +
> + if (intel_engine_has_preempt_reset(engine))
> + timeout += READ_ONCE(engine->props.preempt_timeout_ms);
Was pondering that we dont add slack but the slack is in
the initial value.
> +
> + return msecs_to_jiffies(timeout);
> +}
> +
> static bool next_heartbeat(struct intel_engine_cs *engine)
> {
> long delay;
> @@ -29,6 +41,26 @@ static bool next_heartbeat(struct intel_engine_cs *engine)
> return false;
>
> delay = msecs_to_jiffies_timeout(delay);
> +
> + /*
> + * Once we submit a heartbeat to the HW, we know that it will take
> + * at least a certain amount of time to complete. On a hanging system
> + * it will first have to wait for the preempt reset timeout, and
> + * then it will take some time for the reset to resume with the
> + * heartbeat and for it to complete. So once we have submitted the
> + * heartbeat to HW, we can wait a while longer before declaring the
> + * engine stuck and forcing a reset ourselves. If we do a reset
> + * and the engine is also doing a reset, it is possible that we
> + * reset the engine twice, harming an innocent.
> + *
> + * Before we have sumitted the heartbeat, we do not want to change
s/sumitted/submitted.
> + * the interval as we to promote the heartbeat and trigger preemption
s/we to/we want to/ ?
> + * in a deterministic time frame.
> + */
> + if (engine->heartbeat.systole &&
> + i915_request_is_active(engine->heartbeat.systole))
> + delay = max(delay, completion_timeout(engine));
I see no harm to just always switch to the max.
> +
> if (delay >= HZ)
> delay = round_jiffies_up_relative(delay);
> mod_delayed_work(system_highpri_wq, >heartbeat.work, delay + 1);
> @@ -48,12 +80,49 @@ heartbeat_create(struct intel_context *ce, gfp_t gfp)
> return rq;
> }
>
> +static void defibrillator(struct dma_fence *f, struct dma_fence_cb *cb)
> +{
> + struct intel_engine_cs *engine =
> + container_of(cb, typeof(*engine), heartbeat.cb);
> +
> + if (READ_ONCE(engine->heartbeat.systole))
This particular spot is not a problem but we do manipulate
the systole, without lock, in heartbeat().
So I see race in idle_pulse where we swap the systole.
-Mika
> + mod_delayed_work(system_highpri_wq, >heartbeat.work, 0);
> +}
> +
> +static void
> +untrack_heartbeat(struct intel_engine_cs *engine)
> +{
> + struct i915_request *rq;
> +
> + rq = fetch_and_zero(>heartbeat.systole);
> + if (!rq)
> + return;
> +
> + ENGINE_TRACE(engine, "heartbeat " RQ_FMT "completed\n", RQ_ARG(rq));
> +
> + dma_fence_remove_callback(>fence, >heartbeat.cb);
> + i915_request_put(rq);
> +}
> +
>
[Intel-gfx] [PATCH] drm/i915/display: Add DDR5 and LPDDR5 BW buddy page entries
Set the right BW buddy page mask for new memory types.
BSpec: 49218
Cc: Clint Taylor
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index e17b1ca356c3..f00c1750febd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -5317,17 +5317,25 @@ struct buddy_page_mask {
static const struct buddy_page_mask tgl_buddy_page_masks[] = {
{ .num_channels = 1, .type = INTEL_DRAM_DDR4, .page_mask = 0xF },
+ { .num_channels = 1, .type = INTEL_DRAM_DDR5, .page_mask = 0xF },
{ .num_channels = 2, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x1C },
+ { .num_channels = 2, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x1C },
{ .num_channels = 2, .type = INTEL_DRAM_DDR4, .page_mask = 0x1F },
+ { .num_channels = 2, .type = INTEL_DRAM_DDR5, .page_mask = 0x1E },
{ .num_channels = 4, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x38 },
+ { .num_channels = 4, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x38 },
{}
};
static const struct buddy_page_mask wa_1409767108_buddy_page_masks[] = {
{ .num_channels = 1, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x1 },
{ .num_channels = 1, .type = INTEL_DRAM_DDR4, .page_mask = 0x1 },
+ { .num_channels = 1, .type = INTEL_DRAM_DDR5, .page_mask = 0x1 },
+ { .num_channels = 1, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x1 },
{ .num_channels = 2, .type = INTEL_DRAM_LPDDR4, .page_mask = 0x3 },
{ .num_channels = 2, .type = INTEL_DRAM_DDR4, .page_mask = 0x3 },
+ { .num_channels = 2, .type = INTEL_DRAM_DDR5, .page_mask = 0x3 },
+ { .num_channels = 2, .type = INTEL_DRAM_LPDDR5, .page_mask = 0x3 },
{}
};
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
Re-reported. -Original Message- From: Imre Deak Sent: Tuesday, February 9, 2021 4:31 AM To: intel-gfx@lists.freedesktop.org; Souza, Jose ; Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it On Mon, Feb 08, 2021 at 10:43:14PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it > URL : https://patchwork.freedesktop.org/series/86858/ > State : failure Thanks for the review pushed to -din. The failure is unrelated, see below. > > == Summary == > > CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19631_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19631_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19631_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19631_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_universal_plane@cursor-fb-leak-pipe-a: > - shard-iclb: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb1/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-iclb4/i > gt@kms_universal_pl...@cursor-fb-leak-pipe-a.html This is on an unrelated platform and looks like https://gitlab.freedesktop.org/drm/intel/-/issues/2682 > Known issues > > > Here are the changes found in Patchwork_19631_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@unwedge-stress: > - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / > [i915#2771]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl4/ig > t@gem_...@unwedge-stress.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar > issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-kbl2/ig > t@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_exec_schedule@u-fairslice@rcs0: > - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1610] / > [i915#2803]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl7/ig > t@gem_exec_schedule@u-fairsl...@rcs0.html > > * igt@gem_exec_whisper@basic-contexts-forked-all: > - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / > [i915#95]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/ig > t@gem_exec_whis...@basic-contexts-forked-all.html > > * igt@gem_huc_copy@huc-copy: > - shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_huc_c...@huc-copy.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-tglb6/i > gt@gem_huc_c...@huc-copy.html > > * igt@gem_render_copy@linear-to-vebox-y-tiled: > - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +74 similar > issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-apl7/ig > t@gem_render_c...@linear-to-vebox-y-tiled.html > > * igt@gem_userptr_blits@huge-split: > - shard-glk: [PASS][14] -> [INCOMPLETE][15] ([i915#2502]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk4/igt@gem_userptr_bl...@huge-split.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/ig > t@gem_userptr_bl...@huge-split.html > > * igt@gem_userptr_blits@process-exit-mmap-busy@uc: > - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1699]) > +3 similar issues >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl6/ig > t@gem_userptr_blits@process-exit-mmap-b...@uc.html > > * igt@gen9_exec_parse@allowed-all: > - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1436] / > [i915#716]) >[17]: >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
== Series Details == Series: drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it URL : https://patchwork.freedesktop.org/series/86858/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19631_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19631_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][1] -> [TIMEOUT][2] ([i915#1037] / [i915#2771]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl4/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#2842]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_schedule@u-fairslice@rcs0: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1610] / [i915#2803]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html * igt@gem_exec_whisper@basic-contexts-forked-all: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][9] -> [SKIP][10] ([i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_huc_c...@huc-copy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271]) +74 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-apl7/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gem_userptr_blits@huge-split: - shard-glk: [PASS][12] -> [INCOMPLETE][13] ([i915#2502]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk4/igt@gem_userptr_bl...@huge-split.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/igt@gem_userptr_bl...@huge-split.html * igt@gem_userptr_blits@process-exit-mmap-busy@uc: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1699]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl6/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html * igt@gen9_exec_parse@allowed-all: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1436] / [i915#716]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl10/igt@gen9_exec_pa...@allowed-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl10/igt@gen9_exec_pa...@allowed-all.html * igt@i915_selftest@live@client: - shard-glk: [PASS][17] -> [DMESG-FAIL][18] ([i915#3047]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk1/igt@i915_selftest@l...@client.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk2/igt@i915_selftest@l...@client.html * igt@i915_suspend@forcewake: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([i915#636]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl6/igt@i915_susp...@forcewake.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl8/igt@i915_susp...@forcewake.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +6 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-apl7/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_color_chamelium@pipe-d-ctm-0-5: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#109284] / [fdo#111827]) +2 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-tglb2/igt@kms_color_chamel...@pipe-d-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#54]) +5 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [24]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs : PM_REQ and PM_RES registers (rev4)
== Series Details == Series: drm/i915/debugfs : PM_REQ and PM_RES registers (rev4) URL : https://patchwork.freedesktop.org/series/85437/ State : success == Summary == CI Bug Log - changes from CI_DRM_9752 -> Patchwork_19642 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/index.html Known issues Here are the changes found in Patchwork_19642 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@query-info: - fi-tgl-y: NOTRUN -> [SKIP][1] ([fdo#109315] / [i915#2575]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/fi-tgl-y/igt@amdgpu/amd_ba...@query-info.html * igt@gem_mmap_gtt@basic: - fi-tgl-y: [PASS][2] -> [DMESG-WARN][3] ([i915#402]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@gem_mmap_...@basic.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/fi-tgl-y/igt@gem_mmap_...@basic.html * igt@i915_pm_rpm@module-reload: - fi-kbl-7500u: [PASS][4] -> [INCOMPLETE][5] ([i915#151] / [i915#2405]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-kbl-7500u/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/fi-kbl-7500u/igt@i915_pm_...@module-reload.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][6] -> [FAIL][7] ([i915#1372]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@runner@aborted: - fi-kbl-7500u: NOTRUN -> [FAIL][8] ([fdo#109271] / [i915#1814] / [i915#2722]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/fi-kbl-7500u/igt@run...@aborted.html Possible fixes * igt@vgem_basic@dmabuf-fence-before: - fi-tgl-y: [DMESG-WARN][9] ([i915#402]) -> [PASS][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9752/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/fi-tgl-y/igt@vgem_ba...@dmabuf-fence-before.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#151]: https://gitlab.freedesktop.org/drm/intel/issues/151 [i915#1814]: https://gitlab.freedesktop.org/drm/intel/issues/1814 [i915#2405]: https://gitlab.freedesktop.org/drm/intel/issues/2405 [i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575 [i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9752 -> Patchwork_19642 CI-20190529: 20190529 CI_DRM_9752: a99b75af1722e15bade7f41dca4227bc907561aa @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19642: 45c0b040618535169c0722ed22b61db9062bd5eb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 45c0b0406185 drm/i915/debugfs : PCU PM_REQ and PM_RES registers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19642/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
== Series Details == Series: series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling URL : https://patchwork.freedesktop.org/series/86882/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19637 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/index.html Known issues Here are the changes found in Patchwork_19637 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-gfx0: - fi-cfl-8700k: NOTRUN -> [SKIP][1] ([fdo#109271]) +25 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +23 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][3] -> [FAIL][4] ([i915#1888]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html - fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([i915#2411] / [i915#402]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-y/igt@gem_exec_susp...@basic-s3.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_19637/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886] / [i915#2291]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@vga-edid-read: - fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-cfl-8700k: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#533]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@prime_vgem@basic-write: - fi-tgl-y: [PASS][14] -> [DMESG-WARN][15] ([i915#402]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_v...@basic-write.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-y/igt@prime_v...@basic-write.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][16] ([i915#1602] / [i915#2029] / [i915#2369]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-bdw-5557u/igt@run...@aborted.html * igt@vgem_basic@unload: - fi-kbl-soraka: NOTRUN -> [DMESG-WARN][17] ([i915#1982]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@vgem_ba...@unload.html Possible fixes * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [DMESG-WARN][18] ([i915#402]) -> [PASS][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Tue, Feb 9, 2021 at 4:41 PM Ville Syrjälä wrote: > On Tue, Feb 09, 2021 at 11:07:53AM +0100, Daniel Vetter wrote: > > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > drm_vblank_restore() exists because certain power saving states > > > can clobber the hardware frame counter. The way it does this is > > > by guesstimating how many frames were missed purely based on > > > the difference between the last stored timestamp vs. a newly > > > sampled timestamp. > > > > > > If we should call this function before a full frame has > > > elapsed since we sampled the last timestamp we would end up > > > with a possibly slightly different timestamp value for the > > > same frame. Currently we will happily overwrite the already > > > stored timestamp for the frame with the new value. This > > > could cause userspace to observe two different timestamps > > > for the same frame (and the timestamp could even go > > > backwards depending on how much error we introduce when > > > correcting the timestamp based on the scanout position). > > > > > > To avoid that let's not update the stored timestamp unless we're > > > also incrementing the sequence counter. We do still want to update > > > vblank->last with the freshly sampled hw frame counter value so > > > that subsequent vblank irqs/queries can actually use the hw frame > > > counter to determine how many frames have elapsed. > > > > > > Cc: Dhinakaran Pandiyan > > > Cc: Rodrigo Vivi > > > Cc: Daniel Vetter > > > Signed-off-by: Ville Syrjälä > > > > Ok, top-posting because lol I got confused. I mixed up the guesstimation > > work we do for when we don't have a vblank counter with the precise vblank > > timestamp stuff. > > > > I think it'd still be good to maybe lock down/document a bit better the > > requirements for drm_crtc_vblank_restore, but I convinced myself now that > > your patch looks correct. > > > > Reviewed-by: Daniel Vetter > > Ta. > > Though I wonder if we should just do something like this instead: > - store_vblank(dev, pipe, diff, t_vblank, cur_vblank); > + vblank->last = (cur_vblank - diff) & max_vblank_count; > > to make it entirely obvious that this exists only to fix up > the stored hw counter value? > > Would also avoid the problem the original patch tries to fix > because we'd simply never store a new timestamp here. Hm yeah, I think that would nicely limit the impact. But need to check overflow/underflow math is all correct. And I think that would neatly implement the trick I proposed to address the bug that wasn't there :-) The only thing that I've thought of as issue is that we might have more wrap-around of the hw vblank counter, but that shouldn't be worse than without this - anytime we have the vblank on for long enough we fix the entire thing, and I think our wrap handling is now consistent enough (there was some "let's just add a large bump" stuff for dri1 userspace iirc) that this shouldn't be any problem. Plus the comment about _restore being very special would be in the restore function, so this would also be rather tidy. If you go with this maybe extend the kerneldoc for ->last to mention that drm_vblank_restore() adjusts it? The more I ponder this, the more I like it ... which probably means I'm missing something, because this is drm_vblank.c? Cheers, Daniel > > > > > > --- > > > drivers/gpu/drm/drm_vblank.c | 11 +++ > > > 1 file changed, 11 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > > index 893165eeddf3..e127a7db2088 100644 > > > --- a/drivers/gpu/drm/drm_vblank.c > > > +++ b/drivers/gpu/drm/drm_vblank.c > > > @@ -176,6 +176,17 @@ static void store_vblank(struct drm_device *dev, > > > unsigned int pipe, > > > > > > vblank->last = last; > > > > > > + /* > > > +* drm_vblank_restore() wants to always update > > > +* vblank->last since we can't trust the frame counter > > > +* across power saving states. But we don't want to alter > > > +* the stored timestamp for the same frame number since > > > +* that would cause userspace to potentially observe two > > > +* different timestamps for the same frame. > > > +*/ > > > + if (vblank_count_inc == 0) > > > + return; > > > + > > > write_seqlock(>seqlock); > > > vblank->time = t_vblank; > > > atomic64_add(vblank_count_inc, >count); > > > -- > > > 2.26.2 > > > > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch > > -- > Ville Syrjälä > Intel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Hi,
On 2/9/21 12:27 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-08 20:38:58)
>> Hi All,
>>
>> We (Fedora) have been receiving reports from multiple users about gfx issues
>> / glitches
>> stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs
>> and all
>> reporters report that adding i915.mitigations=off to the cmdline fixes
>> things, see:
>
> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> did not report any differences with and without mitigations. I have yet
> to test other platforms. So I don't yet have an alternative. Though note
> that v5.11 and v5.12 will behave similarly, so we need to urgently find
> a fix for Linus's tree anyway.
Note I've gone ahead and prepared a test kernel for the Fedora bug reports
with the following 3 commits reverted from 5.10.y :
520d05a77b2866eb ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals")
ecca0c675bdecebd ("drm/i915/gt: Restore clear-residual mitigations for
Ivybridge, Baytrail")
48b8c6689efa7cd6 ("drm/i915/gt: Limit VFE threads based on GT")
(Note this are the 5.10.y hashes)
I know going this route is not ideal but it might be best for 5.10.y for now.
I will let you know if reverting these 3 actually helps once I hear back
from the reporters of the issue.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/31] drm/i915: Replace priolist rbtree with a skiplist
On 08/02/2021 16:19, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2021-02-08 15:23:17)
On 08/02/2021 10:52, Chris Wilson wrote:
static struct list_head *
lookup_priolist(struct i915_sched *se, int prio)
{
- struct i915_priolist *p;
- struct rb_node **parent, *rb;
- bool first = true;
+ struct i915_priolist *update[I915_PRIOLIST_HEIGHT];
+ struct i915_priolist_root *const root = >queue;
+ struct i915_priolist *pl, *tmp;
+ int lvl;
lockdep_assert_held(>lock);
- assert_priolists(se);
-
if (unlikely(se->no_priolist))
prio = I915_PRIORITY_NORMAL;
+ for_each_priolist(pl, root) { /* recycle any empty elements before us */
+ if (pl->priority <= prio || !list_empty(>requests))
+ break;
This less part of the less-or-equal condition keeps confusing me as a
break criteria. If premise is cleaning up, why break on first smaller
prio? Would the idea be to prune all empty lists up to, not including,
the lookup prio?
Just parcelling up the work. If we tidy up all the unused nodes before
us, we insert ourselves at the head of the tree, and all the cheap
checks to see if this is the first request, or to find the first
request are happy.
It's not expected to find anything unused with the tweaks to tidy up
empty elements as we move between i915_priolist.requests, but it seems
sensible to keep as then it should be just checking the first
i915_priolist and breaking out.
It's fine, for some reason I missed the order is descending. Probably
thinking about deadlines already. Need to see how that works there then.
But a comment indicating the order would be cool.
-void __i915_priolist_free(struct i915_priolist *p)
+static void __remove_priolist(struct i915_sched *se, struct list_head *plist)
{
- kmem_cache_free(global.slab_priorities, p);
+ struct i915_priolist_root *root = >queue;
+ struct i915_priolist *pl, *tmp;
+ struct i915_priolist *old =
+ container_of(plist, struct i915_priolist, requests);
+ int prio = old->priority;
+ int lvl;
+
+ lockdep_assert_held(>lock);
+ GEM_BUG_ON(!list_empty(plist));
+
+ pl = >sentinel;
+ lvl = pl->level;
+ GEM_BUG_ON(lvl < 0);
+
+ if (prio != I915_PRIORITY_NORMAL)
+ pl_push(old, >requests);
+
+ do {
+ while (tmp = pl->next[lvl], tmp->priority > prio)
+ pl = tmp;
Ah okay, this is needed because the list is singly linked. I suggest a
comment.
Doubly linked would not be interesting?
+ if (lvl <= old->level) {
+ pl->next[lvl] = old->next[lvl];
+ if (pl == >sentinel && old->next[lvl] == pl) {
+ GEM_BUG_ON(pl->level != lvl);
+ pl->level--;
+ }
+ }
+ } while (--lvl >= 0);
+ GEM_BUG_ON(tmp != old);
+}
+struct i915_priolist *__i915_sched_dequeue_next(struct i915_sched *se)
+{
+ struct i915_priolist * const s = >queue.sentinel;
+ struct i915_priolist *pl = s->next[0];
+ int lvl;
+
+ GEM_BUG_ON(!list_empty(>requests));
+ GEM_BUG_ON(pl == s);
+
+ /* Keep pl->next[0] valid for for_each_priolist iteration */
+ if (pl->priority != I915_PRIORITY_NORMAL)
+ pl_push(pl, >requests);
+
+ lvl = pl->level;
+ GEM_BUG_ON(lvl < 0);
+ do {
+ s->next[lvl] = pl->next[lvl];
+ if (pl->next[lvl] == s) {
+ GEM_BUG_ON(s->level != lvl);
+ s->level--;
+ }
+ } while (--lvl >= 0);
+
+ return pl->next[0];
}
If both __i915_sched_dequeue_next and __remove_priolist are removing an
empty list from the hieararchy, why can't they shared some code?
The __remove_priolist does the general search and remove, whereas
dequeue_next is trying to keep O(1) remove-from-head. dequeue_next is
meant to be called many, many more times than __remove_priolist.
Ok.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Tue, Feb 09, 2021 at 11:07:53AM +0100, Daniel Vetter wrote: > On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > drm_vblank_restore() exists because certain power saving states > > can clobber the hardware frame counter. The way it does this is > > by guesstimating how many frames were missed purely based on > > the difference between the last stored timestamp vs. a newly > > sampled timestamp. > > > > If we should call this function before a full frame has > > elapsed since we sampled the last timestamp we would end up > > with a possibly slightly different timestamp value for the > > same frame. Currently we will happily overwrite the already > > stored timestamp for the frame with the new value. This > > could cause userspace to observe two different timestamps > > for the same frame (and the timestamp could even go > > backwards depending on how much error we introduce when > > correcting the timestamp based on the scanout position). > > > > To avoid that let's not update the stored timestamp unless we're > > also incrementing the sequence counter. We do still want to update > > vblank->last with the freshly sampled hw frame counter value so > > that subsequent vblank irqs/queries can actually use the hw frame > > counter to determine how many frames have elapsed. > > > > Cc: Dhinakaran Pandiyan > > Cc: Rodrigo Vivi > > Cc: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > Ok, top-posting because lol I got confused. I mixed up the guesstimation > work we do for when we don't have a vblank counter with the precise vblank > timestamp stuff. > > I think it'd still be good to maybe lock down/document a bit better the > requirements for drm_crtc_vblank_restore, but I convinced myself now that > your patch looks correct. > > Reviewed-by: Daniel Vetter Ta. Though I wonder if we should just do something like this instead: - store_vblank(dev, pipe, diff, t_vblank, cur_vblank); + vblank->last = (cur_vblank - diff) & max_vblank_count; to make it entirely obvious that this exists only to fix up the stored hw counter value? Would also avoid the problem the original patch tries to fix because we'd simply never store a new timestamp here. > > > --- > > drivers/gpu/drm/drm_vblank.c | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > > index 893165eeddf3..e127a7db2088 100644 > > --- a/drivers/gpu/drm/drm_vblank.c > > +++ b/drivers/gpu/drm/drm_vblank.c > > @@ -176,6 +176,17 @@ static void store_vblank(struct drm_device *dev, > > unsigned int pipe, > > > > vblank->last = last; > > > > + /* > > +* drm_vblank_restore() wants to always update > > +* vblank->last since we can't trust the frame counter > > +* across power saving states. But we don't want to alter > > +* the stored timestamp for the same frame number since > > +* that would cause userspace to potentially observe two > > +* different timestamps for the same frame. > > +*/ > > + if (vblank_count_inc == 0) > > + return; > > + > > write_seqlock(>seqlock); > > vblank->time = t_vblank; > > atomic64_add(vblank_count_inc, >count); > > -- > > 2.26.2 > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Document drm_crtc_vblank_restore constraints
On Tue, Feb 09, 2021 at 11:15:23AM +0100, Daniel Vetter wrote:
> I got real badly confused when trying to review a fix from Ville for
> this. Let's try to document better what's required for this, and check
> the minimal settings at runtime - we can't check ofc that there's
> indeed no races in the driver callback.
>
> Also noticed that the drm_vblank_restore version is unused, so lets
> unexport that while at it.
>
> Cc: Ville Syrjala
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_vblank.c | 25 ++---
> include/drm/drm_vblank.h | 1 -
> 2 files changed, 10 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index c914b14cfb43..05f4d4c078fd 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1471,20 +1471,7 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_crtc_vblank_on);
>
> -/**
> - * drm_vblank_restore - estimate missed vblanks and update vblank count.
> - * @dev: DRM device
> - * @pipe: CRTC index
> - *
> - * Power manamement features can cause frame counter resets between vblank
> - * disable and enable. Drivers can use this function in their
> - * _crtc_funcs.enable_vblank implementation to estimate missed vblanks
> since
> - * the last _crtc_funcs.disable_vblank using timestamps and update the
> - * vblank counter.
> - *
> - * This function is the legacy version of drm_crtc_vblank_restore().
> - */
> -void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> +static void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> {
> ktime_t t_vblank;
> struct drm_vblank_crtc *vblank;
> @@ -1520,7 +1507,6 @@ void drm_vblank_restore(struct drm_device *dev,
> unsigned int pipe)
> diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
> store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> }
> -EXPORT_SYMBOL(drm_vblank_restore);
>
> /**
> * drm_crtc_vblank_restore - estimate missed vblanks and update vblank count.
> @@ -1531,9 +1517,18 @@ EXPORT_SYMBOL(drm_vblank_restore);
> * _crtc_funcs.enable_vblank implementation to estimate missed vblanks
> since
> * the last _crtc_funcs.disable_vblank using timestamps and update the
> * vblank counter.
> + *
> + * Note that drivers must have race-free high-precision timestamping support,
> + * i.e. _crtc_funcs.get_vblank_timestamp must be hooked up and
> + * _driver.vblank_disable_immediate must be set to indicate the
> + * time-stamping functions are race-free against vblank hardware counter
> + * increments.
Looks good. Might prevent someone from shooting themselves in
the foot.
Reviewed-by: Ville Syrjälä
> */
> void drm_crtc_vblank_restore(struct drm_crtc *crtc)
> {
> + WARN_ON_ONCE(!crtc->funcs->get_vblank_timestamp);
> + WARN_ON_ONCE(!crtc->dev->vblank_disable_immediate);
> +
> drm_vblank_restore(crtc->dev, drm_crtc_index(crtc));
> }
> EXPORT_SYMBOL(drm_crtc_vblank_restore);
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index dd125f8c766c..733a3e2d1d10 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -247,7 +247,6 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
> void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> void drm_crtc_vblank_on(struct drm_crtc *crtc);
> u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
> -void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
> void drm_crtc_vblank_restore(struct drm_crtc *crtc);
>
> void drm_calc_timestamping_constants(struct drm_crtc *crtc,
> --
> 2.30.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86895/ State : success == Summary == CI Bug Log - changes from CI_DRM_9750 -> Patchwork_19641 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/index.html Known issues Here are the changes found in Patchwork_19641 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +22 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-kbl-7500u: [PASS][2] -> [DMESG-WARN][3] ([i915#2605]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-kbl-7500u/igt@core_hotunp...@unbind-rebind.html - fi-bdw-5557u: NOTRUN -> [WARN][4] ([i915#2283]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([i915#1372]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html * igt@prime_self_import@basic-with_two_bos: - fi-tgl-y: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-tgl-y/igt@prime_self_import@basic-with_two_bos.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-tgl-y: [DMESG-WARN][9] ([i915#2411] / [i915#402]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-tgl-y/igt@gem_exec_susp...@basic-s3.html * igt@prime_vgem@basic-fence-flip: - fi-tgl-y: [DMESG-WARN][11] ([i915#402]) -> [PASS][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9750/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/fi-tgl-y/igt@prime_v...@basic-fence-flip.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411 [i915#2605]: https://gitlab.freedesktop.org/drm/intel/issues/2605 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 Participating hosts (44 -> 39) -- Missing(5): fi-jsl-1 fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_9750 -> Patchwork_19641 CI-20190529: 20190529 CI_DRM_9750: 8ab525b5fa9cbe46bde6340351e84a501c64fd47 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5999: 2982c998a9cb79095611fba018d5df3eec5eab88 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_19641: 0dffdf690010564b2273c27eaea2e7786d7f6bcb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0dffdf690010 drm/i915/stolen: pass the allocation flags f1fe786eeec6 drm/i915/stolen: enforce the min_page_size contract 30478535a4b4 drm/i915/stolen: treat stolen local as normal local memory e8b34b3c94ee drm/i915: Create stolen memory region from local memory == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19641/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
On Tue, Feb 09, 2021 at 09:22:09AM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2021-02-09 02:19:16)
> > From: Ville Syrjälä
> >
> > ilk+ planes get notably unhappy when the plane x+w exceeds
> > the stride. This wasn't a problem previously because we
> > always aligned SURF to the closest tile boundary so the
> > x offset never got particularly large. But now with async
> > flips we have to align to 256KiB instead and thus this
> > becomes a real issue.
> >
> > On ilk/snb/ivb it looks like the accesses just just wrap
> > early to the next tile row when scanout goes past the
> > SURF+n*stride boundary, hsw/bdw suffer more heavily and
> > start to underrun constantly. i965/g4x appear to be immune.
> > vlv/chv I've not yet checked.
> >
> > Let's borrow another trick from the skl+ code and search
> > backwards for a better SURF offset in the hopes of getting the
> > x offset below the limit. IIRC when I ran into a similar issue
> > on skl years ago it was causing the hardware to fall over
> > pretty hard as well.
> >
> > And let's be consistent and include i965/g4x in the check
> > as well, just in case I just got super lucky somehow when
> > I wasn't able to reproduce the issue. Not that it really
> > matters since we still use 4k SURF alignment for i965/g4x
> > anyway.
> >
> > Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv")
> > Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb")
> > Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw")
> > Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/i9xx_plane.c | 27 +++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
> > b/drivers/gpu/drm/i915/display/i9xx_plane.c
> > index 0523e2c79d16..8a52beaed2da 100644
> > --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
> > +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
> > @@ -255,6 +255,33 @@ int i9xx_check_plane_surface(struct intel_plane_state
> > *plane_state)
> > else
> > offset = 0;
> >
> > + /*
> > +* When using an X-tiled surface the plane starts to
> > +* misbehave if the x offset + width exceeds the stride.
> > +* hsw/bdw: underrun galore
> > +* ilk/snb/ivb: wrap to the next tile row mid scanout
> > +* i965/g4x: so far appear immune to this
> > +* vlv/chv: TODO check
> > +*
> > +* Linear surfaces seem to work just fine, even on hsw/bdw
> > +* despite them not using the linear offset anymore.
> > +*/
> > + if (INTEL_GEN(dev_priv) >= 4 && fb->modifier ==
> > I915_FORMAT_MOD_X_TILED) {
> > + u32 alignment = intel_surf_alignment(fb, 0);
> > + int cpp = fb->format->cpp[0];
> > +
> > + while ((src_x + src_w) * cpp >
> > plane_state->color_plane[0].stride) {
> > + if (offset == 0) {
> > + drm_dbg_kms(_priv->drm,
> > + "Unable to find suitable
> > display surface offset due to X-tiling\n");
> > + return -EINVAL;
> > + }
> > +
> > + offset = intel_plane_adjust_aligned_offset(_x,
> > _y, plane_state, 0,
> > + offset,
> > offset - alignment);
>
> As offset decreases, src_x goes up; but modulus the pitch. So long as
> the alignment is not a multiple of the pitch, src_x will change on each
> iteration. And after the adjustment, the offset is stored in
> plane_state.
>
> So this loop would fail for any power-of-two stride, but at the same
> time that would put the src_x + src_w out-of-bounds in the supplied
> coordinates. The only way src_x + src_w would exceed stride legally is
> if we have chosen an aligned offset that causes that, thus there should
> exist an offset where src_x + src_w does not exceed the stride.
>
> The reason for choosing a nearby tile offset was to reduce src_x/src_y
> to fit within the crtc limits. While remapping could be used to solve
> that, the aligned_offset computation allows reuse of a single view.
>
> Since offset, src_x are a function of the plane input parameters, this
> should be possible to exercise with carefully selected framebuffers and
> modesetting. Right? Is there a test case for this?
My idea was to extend kms_big_fb for these sort of things.
While I originally made it purely to test remapping it should
be possible to extend it for non-remapped fbs as well. IIRC
J-P did at least some work towards that goal, but I guess
it's only in the internal copy for whatever reason.
> Reviewed-by: Chris Wilson
Ta.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
On Tue, Feb 09, 2021 at 03:22:09AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: Disallow plane x+w>stride on > ilk+ with X-tiling > URL : https://patchwork.freedesktop.org/series/86882/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19637 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19637 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19637, 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_19637/index.html > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19637: > > ### IGT changes ### > > Possible regressions > > * igt@vgem_basic@unload: > - fi-kbl-soraka: NOTRUN -> [DMESG-WARN][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19637/fi-kbl-soraka/igt@vgem_ba...@unload.html <3> [558.016425] i915 :00:02.0: [drm] *ERROR* Potential atomic update failure on pipe A I guess we've been throwing that under these two: https://gitlab.freedesktop.org/drm/intel/-/issues/86 https://gitlab.freedesktop.org/drm/intel/-/issues/558 -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86895/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1323:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:295:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1442:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1496:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory
== Series Details == Series: series starting with [v2,1/4] drm/i915: Create stolen memory region from local memory URL : https://patchwork.freedesktop.org/series/86895/ State : warning == Summary == $ dim checkpatch origin/drm-tip e8b34b3c94ee drm/i915: Create stolen memory region from local memory -:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #13: as stolen-local or stolen-system based on this value won't work. Split total: 0 errors, 1 warnings, 0 checks, 202 lines checked 30478535a4b4 drm/i915/stolen: treat stolen local as normal local memory f1fe786eeec6 drm/i915/stolen: enforce the min_page_size contract 0dffdf690010 drm/i915/stolen: pass the allocation flags ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: fix spelling mistake "Couldnt" -> "Couldn't" (rev2)
== Series Details == Series: drm/i915/display: fix spelling mistake "Couldnt" -> "Couldn't" (rev2) URL : https://patchwork.freedesktop.org/series/86637/ State : failure == Summary == Applying: drm/i915/display: Fix spelling mistake "Couldnt" -> "Couldn't" Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_dp.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_dp.c No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
On Tue, Feb 09, 2021 at 04:44:12PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 09, 2021 at 09:50:28AM +, Chris Wilson wrote:
> > Quoting Chris Wilson (2021-02-09 09:22:09)
> > > Quoting Ville Syrjala (2021-02-09 02:19:16)
> > > > + while ((src_x + src_w) * cpp >
> > > > plane_state->color_plane[0].stride) {
> > > > + if (offset == 0) {
> > > > + drm_dbg_kms(_priv->drm,
> > > > + "Unable to find suitable
> > > > display surface offset due to X-tiling\n");
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + offset =
> > > > intel_plane_adjust_aligned_offset(_x, _y, plane_state, 0,
> > > > +
> > > > offset, offset - alignment);
> >
> > > The reason for choosing a nearby tile offset was to reduce src_x/src_y
> > > to fit within the crtc limits. While remapping could be used to solve
> > > that, the aligned_offset computation allows reuse of a single view.
> >
> > Should there not be a second constraint on the loop to make sure src_x +
> > src_w is less than 4095/8191/etc?
>
> Yeah, but we don't have that in the skl code either atm.
> Should add it to both.
Actually no. We already cap the max stride such that it never
exceeds that limit. So the single check already covers that.
What I think we should be checking is that src_y stays below the
appropriate limit. Although I'm not sure if we could realistically
hit a case where that fails but still find a suitably aligned
offset before hitting 0. Oh and I've not actually confirmed
whether src_y+src_h also has an upper limit or not.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
On Tue, Feb 09, 2021 at 09:50:28AM +, Chris Wilson wrote:
> Quoting Chris Wilson (2021-02-09 09:22:09)
> > Quoting Ville Syrjala (2021-02-09 02:19:16)
> > > + while ((src_x + src_w) * cpp >
> > > plane_state->color_plane[0].stride) {
> > > + if (offset == 0) {
> > > + drm_dbg_kms(_priv->drm,
> > > + "Unable to find suitable
> > > display surface offset due to X-tiling\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + offset =
> > > intel_plane_adjust_aligned_offset(_x, _y, plane_state, 0,
> > > +
> > > offset, offset - alignment);
>
> > The reason for choosing a nearby tile offset was to reduce src_x/src_y
> > to fit within the crtc limits. While remapping could be used to solve
> > that, the aligned_offset computation allows reuse of a single view.
>
> Should there not be a second constraint on the loop to make sure src_x +
> src_w is less than 4095/8191/etc?
Yeah, but we don't have that in the skl code either atm.
Should add it to both.
And if it can actually fail I guess we should just fall back
to remapping rather than telling the user they can't have a
working display. So far I never did the mental gymnastics to
come up with an actually failing scenario.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915/debugfs : PCU PM_REQ and PM_RES registers
> -Original Message-
> From: S, Saichandana
> Sent: Tuesday, February 9, 2021 7:02 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ch...@chris-wilson.co.uk; Gupta,
> Anshuman
> Subject: [PATCH v5] drm/i915/debugfs : PCU PM_REQ and PM_RES registers
I would have kept the patch name "Add PCU PM_REQ and PM_RES Debugfs"
>
> This debugfs provides the display PM debug information like Time to Next VBI
> and Time to Next Fill from Display Engine <-> PCU Mailbox.
>
> V2:
> Added a functional print to debugfs. [Jani Nikula]
>
> V3:
> Used separate variables to store the register values and also used
> REG_GENMASK and REG_BIT for mask preparation. [Anshuman Gupta]
>
> Removed reading of register contents. Replaced local variable with yesno().
> Placed register macros separately, distinguishing from other macros. [Jani
> Nikula]
>
> V4 : Used i915 as local variable. [Anshuman Gupta, Jani Nikula]
>
> V5 : Added wakeref to wakeup device. [Chris Wilson]
> Signed-off-by: Saichandana S
> ---
> .../drm/i915/display/intel_display_debugfs.c | 24 +++
> drivers/gpu/drm/i915/i915_reg.h | 9 +++
> 2 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index d6e4a9237bda..29aaa41fdeec 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -591,6 +591,29 @@ static int i915_dmc_info(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int i915_pcu_pm_req_res_info(struct seq_file *m, void *unused) {
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct intel_csr *csr = >csr;
> + intel_wakeref_t wakeref;
> +
> + if (!HAS_CSR(i915))
> + return -ENODEV;
> +
> + wakeref = intel_runtime_pm_get(>runtime_pm);
> + if (!csr->dmc_payload)
> + return 0;
> + seq_printf(m, "Time to Next Fill : 0x%08x\n",
> +intel_de_read(i915, PM_RSP_DBG_0) &
These values including TTNVBI are in microseconds, you can print the
decimal values in micro seconds to keep it human readable format.
Thanks,
Anshuman Gupta.
> PM_RESP_TTNF_MASK);
> + seq_printf(m, "Time to Next VBI : 0x%08x\n",
> +(intel_de_read(i915, PM_RSP_DBG_0) &
> PM_RESP_TTNVBI_MASK) >> 16);
> + seq_printf(m, "Selective Exit Latency : 0x%08x\n",
> +intel_de_read(i915, PM_RSP_DBG_1) &
> +PM_RESP_SEL_EXIT_LATENCY_MASK);
> +
> + intel_runtime_pm_put(>runtime_pm, wakeref);
> + return 0;
> +}
> +
> static void intel_seq_print_mode(struct seq_file *m, int tabs,
>const struct drm_display_mode *mode) { @@
> -2128,6 +2151,7 @@ static const struct drm_info_list
> intel_display_debugfs_list[] = {
> {"i915_edp_psr_status", i915_edp_psr_status, 0},
> {"i915_power_domain_info", i915_power_domain_info, 0},
> {"i915_dmc_info", i915_dmc_info, 0},
> + {"i915_pcu_pm_req_res_info", i915_pcu_pm_req_res_info, 0},
> {"i915_display_info", i915_display_info, 0},
> {"i915_shared_dplls_info", i915_shared_dplls_info, 0},
> {"i915_dp_mst_info", i915_dp_mst_info, 0}, diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index
> 224ad897af34..93d319bf80fd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -12525,4 +12525,13 @@ enum skl_power_gate {
> #define TGL_ROOT_DEVICE_SKU_ULX 0x2
> #define TGL_ROOT_DEVICE_SKU_ULT 0x4
>
> +/*These registers are of functional registers for PM debug request and
> response registers*/
> +#define PM_REQ_DBG_0 _MMIO(0x45284)
> +#define PM_REQ_DBG_1 _MMIO(0x45288)
> +#define PM_RSP_DBG_0 _MMIO(0x4528C)
> +#define PM_RESP_TTNF_MASK REG_GENMASK(15, 0)
> +#define PM_RESP_TTNVBI_MASKREG_GENMASK(31, 16)
> +#define PM_RSP_DBG_1 _MMIO(0x45290)
> +#define PM_RESP_SEL_EXIT_LATENCY_MASK REG_GENMASK(2, 0)
> +
> #endif /* _I915_REG_H_ */
> --
> 2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/debugfs : PCU PM_REQ and PM_RES registers
This debugfs provides the display PM debug information like Time
to Next VBI and Time to Next Fill from Display Engine <-> PCU Mailbox.
V2:
Added a functional print to debugfs. [Jani Nikula]
V3:
Used separate variables to store the register values and also
used REG_GENMASK and REG_BIT for mask preparation. [Anshuman Gupta]
Removed reading of register contents. Replaced local variable with yesno().
Placed register macros separately, distinguishing from other
macros. [Jani Nikula]
V4 : Used i915 as local variable. [Anshuman Gupta, Jani Nikula]
V5 : Added wakeref to wakeup device. [Chris Wilson]
Signed-off-by: Saichandana S
---
.../drm/i915/display/intel_display_debugfs.c | 24 +++
drivers/gpu/drm/i915/i915_reg.h | 9 +++
2 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index d6e4a9237bda..29aaa41fdeec 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -591,6 +591,29 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
return 0;
}
+static int i915_pcu_pm_req_res_info(struct seq_file *m, void *unused)
+{
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+ struct intel_csr *csr = >csr;
+ intel_wakeref_t wakeref;
+
+ if (!HAS_CSR(i915))
+ return -ENODEV;
+
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+ if (!csr->dmc_payload)
+ return 0;
+ seq_printf(m, "Time to Next Fill : 0x%08x\n",
+ intel_de_read(i915, PM_RSP_DBG_0) & PM_RESP_TTNF_MASK);
+ seq_printf(m, "Time to Next VBI : 0x%08x\n",
+ (intel_de_read(i915, PM_RSP_DBG_0) & PM_RESP_TTNVBI_MASK) >>
16);
+ seq_printf(m, "Selective Exit Latency : 0x%08x\n",
+ intel_de_read(i915, PM_RSP_DBG_1) &
PM_RESP_SEL_EXIT_LATENCY_MASK);
+
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+ return 0;
+}
+
static void intel_seq_print_mode(struct seq_file *m, int tabs,
const struct drm_display_mode *mode)
{
@@ -2128,6 +2151,7 @@ static const struct drm_info_list
intel_display_debugfs_list[] = {
{"i915_edp_psr_status", i915_edp_psr_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
{"i915_dmc_info", i915_dmc_info, 0},
+ {"i915_pcu_pm_req_res_info", i915_pcu_pm_req_res_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
{"i915_dp_mst_info", i915_dp_mst_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 224ad897af34..93d319bf80fd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -12525,4 +12525,13 @@ enum skl_power_gate {
#define TGL_ROOT_DEVICE_SKU_ULX0x2
#define TGL_ROOT_DEVICE_SKU_ULT0x4
+/*These registers are of functional registers for PM debug request and
response registers*/
+#define PM_REQ_DBG_0 _MMIO(0x45284)
+#define PM_REQ_DBG_1 _MMIO(0x45288)
+#define PM_RSP_DBG_0 _MMIO(0x4528C)
+#define PM_RESP_TTNF_MASKREG_GENMASK(15, 0)
+#define PM_RESP_TTNVBI_MASK REG_GENMASK(31, 16)
+#define PM_RSP_DBG_1 _MMIO(0x45290)
+#define PM_RESP_SEL_EXIT_LATENCY_MASKREG_GENMASK(2, 0)
+
#endif /* _I915_REG_H_ */
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it
On Mon, Feb 08, 2021 at 10:43:14PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it > URL : https://patchwork.freedesktop.org/series/86858/ > State : failure Thanks for the review pushed to -din. The failure is unrelated, see below. > > == Summary == > > CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19631_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_19631_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_19631_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_19631_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_universal_plane@cursor-fb-leak-pipe-a: > - shard-iclb: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb1/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-iclb4/igt@kms_universal_pl...@cursor-fb-leak-pipe-a.html This is on an unrelated platform and looks like https://gitlab.freedesktop.org/drm/intel/-/issues/2682 > Known issues > > > Here are the changes found in Patchwork_19631_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@unwedge-stress: > - shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / > [i915#2771]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@gem_...@unwedge-stress.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl4/igt@gem_...@unwedge-stress.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) +2 similar > issues >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_exec_schedule@u-fairslice@rcs0: > - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1610] / > [i915#2803]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl7/igt@gem_exec_schedule@u-fairsl...@rcs0.html > > * igt@gem_exec_whisper@basic-contexts-forked-all: > - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([i915#118] / > [i915#95]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/igt@gem_exec_whis...@basic-contexts-forked-all.html > > * igt@gem_huc_copy@huc-copy: > - shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_huc_c...@huc-copy.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-tglb6/igt@gem_huc_c...@huc-copy.html > > * igt@gem_render_copy@linear-to-vebox-y-tiled: > - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +74 similar > issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-apl7/igt@gem_render_c...@linear-to-vebox-y-tiled.html > > * igt@gem_userptr_blits@huge-split: > - shard-glk: [PASS][14] -> [INCOMPLETE][15] ([i915#2502]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk4/igt@gem_userptr_bl...@huge-split.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-glk3/igt@gem_userptr_bl...@huge-split.html > > * igt@gem_userptr_blits@process-exit-mmap-busy@uc: > - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#1699]) > +3 similar issues >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl6/igt@gem_userptr_blits@process-exit-mmap-b...@uc.html > > * igt@gen9_exec_parse@allowed-all: > - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1436] / > [i915#716]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl10/igt@gen9_exec_pa...@allowed-all.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19631/shard-skl10/igt@gen9_exec_pa...@allowed-all.html > > * igt@i915_selftest@live@client: > - shard-glk: [PASS][19] -> [DMESG-FAIL][20] ([i915#3047]) >[19]: >
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/vblank: Document drm_crtc_vblank_restore constraints
== Series Details == Series: drm/vblank: Document drm_crtc_vblank_restore constraints URL : https://patchwork.freedesktop.org/series/86888/ State : success == Summary == CI Bug Log - changes from CI_DRM_9747_full -> Patchwork_19639_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_19639_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_on: - shard-skl: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl5/igt@debugfs_test@read_all_entries_display_on.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-skl6/igt@debugfs_test@read_all_entries_display_on.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][3] -> [TIMEOUT][4] ([i915#1037] / [i915#3063]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-tglb7/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][5] -> [TIMEOUT][6] ([i915#1037] / [i915#2481]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb8/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-iclb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs0: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#2842]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-kbl6/igt@gem_exec_fair@basic-n...@vcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-kbl2/igt@gem_exec_fair@basic-n...@vcs0.html * igt@gem_exec_reloc@basic-parallel: - shard-apl: NOTRUN -> [TIMEOUT][9] ([i915#1729]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-apl7/igt@gem_exec_re...@basic-parallel.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2389]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-iclb2/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_exec_schedule@u-fairslice@vcs0: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1610] / [i915#2803]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-skl7/igt@gem_exec_schedule@u-fairsl...@vcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-skl1/igt@gem_exec_schedule@u-fairsl...@vcs0.html * igt@gem_exec_schedule@u-fairslice@vecs0: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#2803]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-tglb7/igt@gem_exec_schedule@u-fairsl...@vecs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-tglb8/igt@gem_exec_schedule@u-fairsl...@vecs0.html - shard-iclb: [PASS][15] -> [DMESG-WARN][16] ([i915#2803]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-iclb4/igt@gem_exec_schedule@u-fairsl...@vecs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-iclb1/igt@gem_exec_schedule@u-fairsl...@vecs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-glk: [PASS][17] -> [DMESG-WARN][18] ([i915#118] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk6/igt@gem_exec_whis...@basic-contexts-priority-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-glk2/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_userptr_blits@process-exit-mmap-busy@wc: - shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#1699]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-apl6/igt@gem_userptr_blits@process-exit-mmap-b...@wc.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#1436] / [i915#716]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/shard-glk6/igt@gen9_exec_pa...@allowed-all.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-glk6/igt@gen9_exec_pa...@allowed-all.html * igt@i915_hangman@engine-hang: - shard-hsw: NOTRUN -> [SKIP][22] ([fdo#109271]) +28 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-hsw6/igt@i915_hang...@engine-hang.html * igt@i915_pm_backlight@fade_with_dpms: - shard-hsw: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#3012]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/shard-hsw6/igt@i915_pm_backlight@fade_with_dpms.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-apl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1937]) [24]:
[Intel-gfx] [PATCH v2 4/4] drm/i915/stolen: pass the allocation flags
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 320270c35949..7e06636f7f24 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -632,7 +632,8 @@ static const struct drm_i915_gem_object_ops
i915_gem_object_stolen_ops = {
static int __i915_gem_object_create_stolen(struct intel_memory_region *mem,
struct drm_i915_gem_object *obj,
- struct drm_mm_node *stolen)
+ struct drm_mm_node *stolen,
+ unsigned int flags)
{
static struct lock_class_key lock_class;
unsigned int cache_level;
@@ -650,7 +651,7 @@ static int __i915_gem_object_create_stolen(struct
intel_memory_region *mem,
if (err)
return err;
- i915_gem_object_init_memory_region(obj, mem, 0);
+ i915_gem_object_init_memory_region(obj, mem, flags);
return 0;
}
@@ -679,7 +680,7 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
if (ret)
goto err_free;
- ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+ ret = __i915_gem_object_create_stolen(mem, obj, stolen, flags);
if (ret)
goto err_remove;
@@ -837,7 +838,8 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_i915_private *i915,
goto err_stolen;
}
- ret = __i915_gem_object_create_stolen(mem, obj, stolen);
+ ret = __i915_gem_object_create_stolen(mem, obj, stolen,
+ I915_BO_ALLOC_CONTIGUOUS);
if (ret)
goto err_object_free;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915/stolen: treat stolen local as normal local memory
Underneath it's the same stuff, so things like the PTE_LM bits for the
GTT should just keep working as-is.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 194f35342710..078484d5e3f5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -19,7 +19,10 @@ const struct drm_i915_gem_object_ops i915_gem_lmem_obj_ops =
{
bool i915_gem_object_is_lmem(struct drm_i915_gem_object *obj)
{
- return obj->ops == _gem_lmem_obj_ops;
+ struct intel_memory_region *mr = obj->mm.region;
+
+ return mr && (mr->type == INTEL_MEMORY_LOCAL ||
+ mr->type == INTEL_MEMORY_STOLEN_LOCAL);
}
struct drm_i915_gem_object *
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/stolen: enforce the min_page_size contract
From: CQ Tang Since stolen can now be device local-memory underneath, we should try to enforce any min_page_size restrictions when allocating pages. v2: Drop the min_page_size sanity checking around stolen_insert_node_in_range. Given that this is a low-level interface we shouldn't just assume that the chunks are pages intended to be inserted into the GTT. Signed-off-by: CQ Tang Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c index dfc3076abd0c..320270c35949 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c @@ -674,7 +674,8 @@ static int _i915_gem_object_stolen_init(struct intel_memory_region *mem, if (!stolen) return -ENOMEM; - ret = i915_gem_stolen_insert_node(i915, stolen, size, 4096); + ret = i915_gem_stolen_insert_node(i915, stolen, size, + mem->min_page_size); if (ret) goto err_free; @@ -814,8 +815,8 @@ i915_gem_object_create_stolen_for_preallocated(struct drm_i915_private *i915, /* KISS and expect everything to be page-aligned */ if (GEM_WARN_ON(size == 0) || - GEM_WARN_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE)) || - GEM_WARN_ON(!IS_ALIGNED(stolen_offset, I915_GTT_MIN_ALIGNMENT))) + GEM_WARN_ON(!IS_ALIGNED(size, mem->min_page_size)) || + GEM_WARN_ON(!IS_ALIGNED(stolen_offset, mem->min_page_size))) return ERR_PTR(-EINVAL); stolen = kzalloc(sizeof(*stolen), GFP_KERNEL); -- 2.26.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915: Create stolen memory region from local memory
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't care about stolen.
- mem->type is only setup after the region probe, so setting the name
as stolen-local or stolen-system based on this value won't work. Split
system vs local stolen setup to fix this.
- kill all the region->devmem/is_devmem stuff. We already differentiate
the different types of stolen so such things shouldn't be needed
anymore.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 90 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 3 +
drivers/gpu/drm/i915/i915_pci.c| 2 +-
drivers/gpu/drm/i915/i915_reg.h| 1 +
drivers/gpu/drm/i915/intel_memory_region.c | 6 ++
drivers/gpu/drm/i915/intel_memory_region.h | 5 +-
6 files changed, 97 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index c5f85296a45f..dfc3076abd0c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -10,6 +10,7 @@
#include
#include
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "i915_drv.h"
#include "i915_gem_stolen.h"
@@ -121,6 +122,14 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ /*
+* With device local memory, we don't need to check the address range,
+* this is device memory physical address, could overlap with system
+* memory.
+*/
+ if (HAS_LMEM(i915))
+ return 0;
+
/*
* Verify that nothing else uses this physical address. Stolen
* memory should be reserved by the BIOS and hidden from the
@@ -682,17 +691,30 @@ static int _i915_gem_object_stolen_init(struct
intel_memory_region *mem,
return ret;
}
+struct intel_memory_region *i915_stolen_region(struct drm_i915_private *i915)
+{
+ if (HAS_LMEM(i915))
+ return i915->mm.regions[INTEL_REGION_STOLEN_LMEM];
+
+ return i915->mm.regions[INTEL_REGION_STOLEN_SMEM];
+}
+
struct drm_i915_gem_object *
i915_gem_object_create_stolen(struct drm_i915_private *i915,
resource_size_t size)
{
- return
i915_gem_object_create_region(i915->mm.regions[INTEL_REGION_STOLEN_SMEM],
+ return i915_gem_object_create_region(i915_stolen_region(i915),
size, I915_BO_ALLOC_CONTIGUOUS);
}
static int init_stolen(struct intel_memory_region *mem)
{
- intel_memory_region_set_name(mem, "stolen");
+ if (HAS_LMEM(mem->i915)) {
+ if (!io_mapping_init_wc(>iomap,
+ mem->io_start,
+ resource_size(>region)))
+ return -EIO;
+ }
/*
* Initialise stolen early so that we may reserve preallocated
@@ -712,13 +734,65 @@ static const struct intel_memory_region_ops
i915_region_stolen_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static struct intel_memory_region *
+setup_lmem_stolen(struct drm_i915_private *i915)
+{
+ struct intel_uncore *uncore = >uncore;
+ struct pci_dev *pdev = i915->drm.pdev;
+ struct intel_memory_region *mem;
+ resource_size_t io_start;
+ resource_size_t lmem_size;
+ u64 lmem_base;
+
+ if (!IS_DGFX(i915))
+ return ERR_PTR(-ENODEV);
+
+ lmem_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
+ lmem_size = pci_resource_len(pdev, 2) - lmem_base;
+ io_start = pci_resource_start(pdev, 2) + lmem_base;
+
+ mem = intel_memory_region_create(i915, lmem_base, lmem_size,
+I915_GTT_PAGE_SIZE_4K, io_start,
+_region_stolen_ops);
+ if (IS_ERR(mem))
+ return mem;
+
+ drm_dbg(>drm, "Stolen Local memory: %pR\n", >region);
+ drm_dbg(>drm, "Stolen Local memory IO start: %pa\n",
+ >io_start);
+
+ intel_memory_region_set_name(mem, "stolen-local");
+
+ return mem;
+}
+
+static struct intel_memory_region*
+setup_smem_stolen(struct drm_i915_private *i915)
+{
+ struct intel_memory_region *mem;
+
+ mem = intel_memory_region_create(i915,
+intel_graphics_stolen_res.start,
+
resource_size(_graphics_stolen_res),
+PAGE_SIZE, 0,
+_region_stolen_ops);
+ if (IS_ERR(mem))
+ return mem;
+
+ intel_memory_region_set_name(mem, "stolen-system");
+
+ return mem;
+}
+
struct intel_memory_region
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Quoting Hans de Goede (2021-02-09 11:46:46)
> Hi,
>
> On 2/9/21 12:27 AM, Chris Wilson wrote:
> > Quoting Hans de Goede (2021-02-08 20:38:58)
> >> Hi All,
> >>
> >> We (Fedora) have been receiving reports from multiple users about gfx
> >> issues / glitches
> >> stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs
> >> and all
> >> reporters report that adding i915.mitigations=off to the cmdline fixes
> >> things, see:
> >
> > I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> > did not report any differences with and without mitigations. I have yet
> > to test other platforms. So I don't yet have an alternative.
>
> Note the original / first reporter of:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1925346
>
> Is using hsw-gt2, so it seems that the problem is not just the enabling of
> the mitigations on ivy-bridge / bay-trail but that there actually is
> a regression on devices where the WA worked fine before...
>
> If you have access to a hsw-gt2 device then testing there might help?
The current one is headless, I'm trying to get a laptop with gt2 setup
again so that I can do more than test with piglit.
> Also note that this reproduces more easily on 5.10.10, which does not have:
>
> 520d05a77b2866eb ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals")
>
> Not sure if that helps though.
It gives a clue that it's still a problem with the pipe state. (Which is
believable as there can't be much else!)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH][next] drm/i915/display: Fix spelling mistake "Couldnt" -> "Couldn't"
From: Colin Ian King
There is a spelling mistake in a drm_dbg message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 8c12d5375607..a338720cee2e 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2650,7 +2650,7 @@ void intel_dp_check_frl_training(struct intel_dp
*intel_dp)
if (intel_dp_pcon_start_frl_training(intel_dp) < 0) {
int ret, mode;
- drm_dbg(_priv->drm, "Couldnt set FRL mode, continuing with
TMDS mode\n");
+ drm_dbg(_priv->drm, "Couldn't set FRL mode, continuing with
TMDS mode\n");
ret = drm_dp_pcon_reset_frl_config(_dp->aux);
mode = drm_dp_pcon_hdmi_link_mode(_dp->aux, NULL);
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [5.10.y regression] i915 clear-residuals mitigation is causing gfx issues
Hi,
On 2/9/21 12:27 AM, Chris Wilson wrote:
> Quoting Hans de Goede (2021-02-08 20:38:58)
>> Hi All,
>>
>> We (Fedora) have been receiving reports from multiple users about gfx issues
>> / glitches
>> stating with 5.10.9. All reporters are users of Ivy Bridge / Haswell iGPUs
>> and all
>> reporters report that adding i915.mitigations=off to the cmdline fixes
>> things, see:
>
> I tried to reproduce this on the w/e on hsw-gt1, to no avail; and piglit
> did not report any differences with and without mitigations. I have yet
> to test other platforms. So I don't yet have an alternative.
Note the original / first reporter of:
https://bugzilla.redhat.com/show_bug.cgi?id=1925346
Is using hsw-gt2, so it seems that the problem is not just the enabling of
the mitigations on ivy-bridge / bay-trail but that there actually is
a regression on devices where the WA worked fine before...
If you have access to a hsw-gt2 device then testing there might help?
Also note that this reproduces more easily on 5.10.10, which does not have:
520d05a77b2866eb ("drm/i915/gt: Clear CACHE_MODE prior to clearing residuals")
Not sure if that helps though.
> Though note
> that v5.11 and v5.12 will behave similarly, so we need to urgently find
> a fix for Linus's tree anyway.
Ack.
Regards,
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for Gen9 (rev2)
From this CI warning log, there are all known warning message in i915 driver and is not caused by my patch. Warning 1: <3> [69.081809] [drm:wa_verify [i915]] *ERROR* engine workaround lost on application! (reg[b004]=0x0, relevant bits were 0x0 vs expected 0x80) Warning 2: <3> [619.188270] i915/intel_lrc_live_selftests: live_lrc_isolation failed with error -22 Warning 3: <3> [282.248111] i915 :00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/vblank: Document drm_crtc_vblank_restore constraints
== Series Details ==
Series: drm/vblank: Document drm_crtc_vblank_restore constraints
URL : https://patchwork.freedesktop.org/series/86888/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9747 -> Patchwork_19639
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/index.html
Known issues
Here are the changes found in Patchwork_19639 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@fork-gfx0:
- fi-icl-u2: NOTRUN -> [SKIP][1] ([fdo#109315]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html
* igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
- fi-cfl-8700k: NOTRUN -> [SKIP][2] ([fdo#109271]) +25 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-cfl-8700k/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +23 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_flink_basic@bad-open:
- fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#402])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-tgl-y/igt@gem_flink_ba...@bad-open.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
- fi-cfl-8700k: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: NOTRUN -> [SKIP][8] ([i915#2190])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886] / [i915#2291])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +8
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-kbl-soraka/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@vga-edid-read:
- fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +8
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-cfl-8700k/igt@kms_chamel...@vga-edid-read.html
- fi-icl-u2: NOTRUN -> [SKIP][12] ([fdo#109309]) +1 similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-icl-u2/igt@kms_chamel...@vga-edid-read.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109285])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-cfl-8700k: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#533])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-cfl-8700k/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#109278])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-icl-u2/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
- fi-kbl-soraka: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#533])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@gem_sync@basic-each:
- fi-tgl-y: [DMESG-WARN][17] ([i915#402]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9747/fi-tgl-y/igt@gem_s...@basic-each.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_19639/fi-tgl-y/igt@gem_s...@basic-each.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#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1208]:
Re: [Intel-gfx] [PATCH 30/31] drm/i915: Support secure dispatch on gen6/gen7
On 08/02/2021 20:55, Dave Airlie wrote: On Mon, 8 Feb 2021 at 20:53, Chris Wilson wrote: Re-enable secure dispatch for gen6/gen7, primarily to workaround the command parser and overly zealous command validation on Haswell. For example this prevents making accurate measurements using a journal for store results from the GPU without CPU intervention. There's 31 patches in this series, and I can't find any 00/31 or justification for any of this work. I see patches like this which seem to undo work done for security reasons under CVE patches with no oversight. Again, the GT team is not doing the right thing here, stop focusing on individual pieces of Chris's work, push back for high level architectural reviews and I want them on the list in public. All I want from the GT team in the next pull request is dma_resv locking work and restoring the hangcheck timers that seems like a regression that Chris found acceptable and nobody has pushed back on. For like the 500th time, if you want DG1 and stuff in the tree, stop this shit already, real reviewers, high-level architectural reviews, NAK the bullshit in public on the list. Since it's mostly been me reviewing the scheduler improvements in this series, I gather we have met and talked, or that you have at least have been following me closely enough to conclude I am not a "real" reviewer. Fair? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup
On Tue, Jan 26, 2021 at 01:46:25PM -0800, Brian Welty wrote:
> This patch adds tracking of which cgroup to make charges against for a
> given GEM object. We associate the current task's cgroup with GEM objects
> as they are created. First user of this is for charging DRM cgroup for
> device memory allocations. The intended behavior is for device drivers to
> make the cgroup charging calls at the time that backing store is allocated
> or deallocated for the object.
>
> Exported functions are provided for charging memory allocations for a
> GEM object to DRM cgroup. To aid in debugging, we store how many bytes
> have been charged inside the GEM object. Add helpers for setting and
> clearing the object's associated cgroup which will check that charges are
> not being leaked.
>
> For shared objects, this may make the charge against a cgroup that is
> potentially not the same cgroup as the process using the memory. Based
> on the memory cgroup's discussion of "memory ownership", this seems
> acceptable [1].
>
> [1] https://www.kernel.org/doc/Documentation/cgroup-v2.txt, "Memory Ownership"
>
> Signed-off-by: Brian Welty
Since for now we only have the generic gpu/xpu/bikeshed.memory bucket that
counts everything, why don't we also charge in these gem functions?
Also, that would remove the need for all these functions exported to
drivers. Plus the cgroups setup could also move fully into drm core code,
since all drivers (*) support it. That way this would really be a fully
generic cgroups controller, and we could land it.
The other things I'd do:
- drop gpu scheduling controller from the initial patch series. Yes we'll
need it, but we also need vram limits and all these things for full
featured controller. Having the minimal viable cgroup controller in
upstream would unblock all these other things, and we could discuss them
in separate patch series, instead of one big bikeshed that never reaches
full consensus.
- the xpu thing is probably real, I just chatted with Android people for
their gpu memory accounting needs, and cgroups sounds like a solution
for them too. But unlike on desktop/server linux, on Android all shared
buffers are allocated from dma-buf heaps, so outside of drm, and hence a
cgroup controller that's tightly tied to drm isn't that useful. So I
think we should move the controller/charge functions up one level into
drivers/gpu/cgroups.
On the naming bikeshed I think gpu is perfectly fine, just explain in
the docs that the G stands for "general" :-) Otherwise we might need to
rename drivers/gpu to drivers/xpu too, and that's maybe one bikeshed too
far. Plus, right now it really is the controller for gpu related memory,
even if we extend it to Android (where it would also include
video/camera allocatioons). Extending this cgroup controller to
accelerators in general is maybe a bit too much.
- The other disambiguation is how we account dma-buf (well, buffer based)
gpu allocations vs HMM gpu memory allocations, that might be worth
clarifying in the docs.
- Finally to accelerate this further, I think it'd be good to pull out the
cgroup spec for this more minimized series into patch 1, as a draft.
That way we could get all stakeholders to ack on that ack, so hopefully
we're building something that will work for everyone. That way we can
hopefully untangle the controller design discussions from the
implementation bikeshedding as much as possible.
Cheers, Daniel
*: vmwgfx is the only non-gem driver, but there's plans to move at least
vmwgfx internals (maybe not the uapi, we'll see) over to gem. Once that's
done it's truly all gpu memory.
> ---
> drivers/gpu/drm/drm_gem.c | 89 +++
> include/drm/drm_gem.h | 17
> 2 files changed, 106 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index c2ce78c4edc3..a12da41eaafe 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -112,6 +113,89 @@ drm_gem_init(struct drm_device *dev)
> return drmm_add_action(dev, drm_gem_init_release, NULL);
> }
>
> +/**
> + * drm_gem_object_set_cgroup - associate GEM object with a cgroup
> + * @obj: GEM object which is being associated with a cgroup
> + * @task: task associated with process control group to use
> + *
> + * This will acquire a reference on cgroup and use for charging GEM
> + * memory allocations.
> + * This helper could be extended in future to migrate charges to another
> + * cgroup, print warning if this usage occurs.
> + */
> +void drm_gem_object_set_cgroup(struct drm_gem_object *obj,
> +struct task_struct *task)
> +{
> + /* if object has existing cgroup, we migrate the charge... */
> + if (obj->drmcg) {
> + pr_warn("DRM: need to migrate cgroup charge of %lld\n",
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/vblank: Document drm_crtc_vblank_restore constraints
== Series Details == Series: drm/vblank: Document drm_crtc_vblank_restore constraints URL : https://patchwork.freedesktop.org/series/86888/ State : warning == Summary == $ dim checkpatch origin/drm-tip 37b0a64a8211 drm/vblank: Document drm_crtc_vblank_restore constraints -:81: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter ' != 'Signed-off-by: Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 53 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
On 09/02/2021 10:31, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-02-09 09:37:19) On 08/02/2021 10:52, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 35bbe2b80596..f1d009906f71 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -1,3 +1,65 @@ +choice + prompt "Preferred scheduler" + default DRM_I915_SCHED_VIRTUAL_DEADLINE + help + Select the preferred method to decide the order of execution. + + The scheduler is used for two purposes. First to defer unready + jobs to not block execution of independent ready clients, so + preventing GPU stalls while work waits for other tasks. The second + purpose is to decide which task to run next, as well as decide + if that task should preempt the currently running task, or if + the current task has exceeded its allotment of GPU time and should + be replaced. + + config DRM_I915_SCHED_FIFO + bool "FIFO" + help + No task reordering, tasks are executed in order of readiness. + First in, first out. + + Unready tasks do not block execution of other, independent clients. + A client will not be scheduled for execution until all of its + prerequisite work has completed. + + This disables the scheduler and puts it into a pass-through mode. + + config DRM_I915_SCHED_PRIORITY + bool "Priority" + help + Strict priority ordering, equal priority tasks are executed + in order of readiness. Clients are liable to starve other clients, + causing uneven execution and excess task latency. High priority + clients will preempt lower priority clients and will run + uninterrupted. + + Note that interactive desktops will implicitly perform priority + boosting to minimise frame jitter. + + config DRM_I915_SCHED_VIRTUAL_DEADLINE + bool "Virtual Deadline" + help + A fair scheduler based on MuQSS with priority-hinting. + + When a task is ready for execution, it is given a quota (from the + engine's timeslice) and a virtual deadline. The virtual deadline is + derived from the current time and the timeslice scaled by the + task's priority. Higher priority tasks are given an earlier + deadline and receive a large portion of the execution bandwidth. + + Requests are then executed in order of deadline completion. + Requests with earlier deadlines and higher priority than currently + executing on the engine will preempt the active task. + +endchoice + +config DRM_I915_SCHED + int + default 2 if DRM_I915_SCHED_VIRTUAL_DEADLINE + default 1 if DRM_I915_SCHED_PRIORITY + default 0 if DRM_I915_SCHED_FIFO + default -1 Default -1 would mean it would ask the user and not default to deadline? CONFIG_DRM_I915_SCHED is unnamed, it is never itself presented to the user. The choice is, and that ends up setting one of the 3 values, which is then mapped to an integer value by DRM_I915_SCHED. That was done to give the hierarchy to the policies which resulted in the cascade of supporting fifo as a subset of priorites and priorities as a subset of deadlines. Which also ties nicely into the different backends being able to select different scheduling levels for themselves (no scheduling at all for legacy ringbuffer and mock, deadlines for execlists/ringscheduler, and fifo for guc). Yes sorry, there is "default DRM_I915_SCHED_VIRTUAL_DEADLINE" above which I missed. Implementation wise it is very neat how you did it so there is basically very little cost for the compiled out options. And code maintenance cost to support multiple options is pretty trivial as well. Only cost I can see is potential bug reports if "wrong" scheduler was picked by someone. What do you envisage, or who, would be the use cases for not going with deadline? (I think deadline should be default.) The first thing I did with it was compare none/priority/deadlines with wsim and ift, that's what I would expect most to try as well (replace wsim with their favourite benchmark). For instance, it was reassuring that timeslicing just worked, even without priorities. Beyond testing, it is a gesture to putting policy back into the hands of the user, though to truly do that we would make it a sysfs attribute. That found a couple of bugs to make sure i915_sched_defer_request degraded back into sorting by priorities (or not). And suggested maybe we should try harder to avoid semaphores without the more adaptable scheduling modes. As for feedback in bugs, the choice should be included with the engine state dump. I think as minimum some strong sentences should be put into the "Preferred scheduler" kconfig help saying not to change the default away from deadline unless one really really knows what they are doing. You know the usual kconfig language for these sort of situations.
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
Quoting Tvrtko Ursulin (2021-02-09 09:37:19) > > On 08/02/2021 10:52, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/Kconfig.profile > > b/drivers/gpu/drm/i915/Kconfig.profile > > index 35bbe2b80596..f1d009906f71 100644 > > --- a/drivers/gpu/drm/i915/Kconfig.profile > > +++ b/drivers/gpu/drm/i915/Kconfig.profile > > @@ -1,3 +1,65 @@ > > +choice > > + prompt "Preferred scheduler" > > + default DRM_I915_SCHED_VIRTUAL_DEADLINE > > + help > > + Select the preferred method to decide the order of execution. > > + > > + The scheduler is used for two purposes. First to defer unready > > + jobs to not block execution of independent ready clients, so > > + preventing GPU stalls while work waits for other tasks. The second > > + purpose is to decide which task to run next, as well as decide > > + if that task should preempt the currently running task, or if > > + the current task has exceeded its allotment of GPU time and should > > + be replaced. > > + > > + config DRM_I915_SCHED_FIFO > > + bool "FIFO" > > + help > > + No task reordering, tasks are executed in order of readiness. > > + First in, first out. > > + > > + Unready tasks do not block execution of other, independent clients. > > + A client will not be scheduled for execution until all of its > > + prerequisite work has completed. > > + > > + This disables the scheduler and puts it into a pass-through mode. > > + > > + config DRM_I915_SCHED_PRIORITY > > + bool "Priority" > > + help > > + Strict priority ordering, equal priority tasks are executed > > + in order of readiness. Clients are liable to starve other clients, > > + causing uneven execution and excess task latency. High priority > > + clients will preempt lower priority clients and will run > > + uninterrupted. > > + > > + Note that interactive desktops will implicitly perform priority > > + boosting to minimise frame jitter. > > + > > + config DRM_I915_SCHED_VIRTUAL_DEADLINE > > + bool "Virtual Deadline" > > + help > > + A fair scheduler based on MuQSS with priority-hinting. > > + > > + When a task is ready for execution, it is given a quota (from the > > + engine's timeslice) and a virtual deadline. The virtual deadline is > > + derived from the current time and the timeslice scaled by the > > + task's priority. Higher priority tasks are given an earlier > > + deadline and receive a large portion of the execution bandwidth. > > + > > + Requests are then executed in order of deadline completion. > > + Requests with earlier deadlines and higher priority than currently > > + executing on the engine will preempt the active task. > > + > > +endchoice > > + > > +config DRM_I915_SCHED > > + int > > + default 2 if DRM_I915_SCHED_VIRTUAL_DEADLINE > > + default 1 if DRM_I915_SCHED_PRIORITY > > + default 0 if DRM_I915_SCHED_FIFO > > + default -1 > > Default -1 would mean it would ask the user and not default to deadline? CONFIG_DRM_I915_SCHED is unnamed, it is never itself presented to the user. The choice is, and that ends up setting one of the 3 values, which is then mapped to an integer value by DRM_I915_SCHED. That was done to give the hierarchy to the policies which resulted in the cascade of supporting fifo as a subset of priorites and priorities as a subset of deadlines. Which also ties nicely into the different backends being able to select different scheduling levels for themselves (no scheduling at all for legacy ringbuffer and mock, deadlines for execlists/ringscheduler, and fifo for guc). > Implementation wise it is very neat how you did it so there is basically > very little cost for the compiled out options. And code maintenance cost > to support multiple options is pretty trivial as well. > > Only cost I can see is potential bug reports if "wrong" scheduler was > picked by someone. What do you envisage, or who, would be the use cases > for not going with deadline? (I think deadline should be default.) The first thing I did with it was compare none/priority/deadlines with wsim and ift, that's what I would expect most to try as well (replace wsim with their favourite benchmark). For instance, it was reassuring that timeslicing just worked, even without priorities. Beyond testing, it is a gesture to putting policy back into the hands of the user, though to truly do that we would make it a sysfs attribute. That found a couple of bugs to make sure i915_sched_defer_request degraded back into sorting by priorities (or not). And suggested maybe we should try harder to avoid semaphores without the more adaptable scheduling modes. As for feedback in bugs, the choice should be included with the engine state dump. > Then there is a question of how these kconfig will interact, or at least > what their semantics would be, considering
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: HDCP capability enc NULL check
On Tue, Feb 09, 2021 at 07:39:17AM +0200, Gupta, Anshuman wrote:
> > > > > > [...]
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > > index ae1371c36a32..58af323d189a 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > > > > > @@ -135,11 +135,16 @@ int intel_hdcp_read_valid_bksv(struct
> > > > > > intel_digital_port *dig_port,
> > > > > > /* Is HDCP1.4 capable on Platform and Sink */
> > > > > > bool intel_hdcp_capable(struct intel_connector *connector) {
> > > > > > - struct intel_digital_port *dig_port =
> > > > > > intel_attached_dig_port(connector);
> > > > > > + struct intel_digital_port *dig_port;
> > > > > > const struct intel_hdcp_shim *shim = connector->hdcp.shim;
> > > > > > bool capable = false;
> > > > > > u8 bksv[5];
> > > > > >
> > > > > > + if (!connector->encoder)
> > > > > > + return -ENODEV;
> > > > >
> > > > > I assume this is needed when called from i915_hdcp_sink_capability
> > > > > debugfs entry. That one is lacking the locking for the connector,
> > > > > but is that entry really needed? We print the same info already
> > > > > from the i915_display_info entry which has the proper locking and
> > > > > encoder check.
> > > >
> > > > Historically HDCP capability added to i915_display_info later to
> > > > debug CI machine as i915_display_info available as CI logs. Now the
> > > > plans i915_display_info should only show the monitor capability.
> > > > and i915_hdcp_sink_capability will check both sink and platform
> > > > capability.
> > >
> > > Ok, in any case the encoder NULL check and the required locking should
> > > be done in i915_hdcp_sink_capability_show().
>
> Need one input, AFAIU we do require
> drm_modeset_lock(_priv->drm.mode_config.connection_mutex, NULL)
> lock in i915_hdcp_sink_capability ?
Yes, and there's also drm_modeset_lock_single_interruptible() that could
be used.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/vblank: Document drm_crtc_vblank_restore constraints
I got real badly confused when trying to review a fix from Ville for
this. Let's try to document better what's required for this, and check
the minimal settings at runtime - we can't check ofc that there's
indeed no races in the driver callback.
Also noticed that the drm_vblank_restore version is unused, so lets
unexport that while at it.
Cc: Ville Syrjala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_vblank.c | 25 ++---
include/drm/drm_vblank.h | 1 -
2 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index c914b14cfb43..05f4d4c078fd 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1471,20 +1471,7 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
}
EXPORT_SYMBOL(drm_crtc_vblank_on);
-/**
- * drm_vblank_restore - estimate missed vblanks and update vblank count.
- * @dev: DRM device
- * @pipe: CRTC index
- *
- * Power manamement features can cause frame counter resets between vblank
- * disable and enable. Drivers can use this function in their
- * _crtc_funcs.enable_vblank implementation to estimate missed vblanks
since
- * the last _crtc_funcs.disable_vblank using timestamps and update the
- * vblank counter.
- *
- * This function is the legacy version of drm_crtc_vblank_restore().
- */
-void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
+static void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
{
ktime_t t_vblank;
struct drm_vblank_crtc *vblank;
@@ -1520,7 +1507,6 @@ void drm_vblank_restore(struct drm_device *dev, unsigned
int pipe)
diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
}
-EXPORT_SYMBOL(drm_vblank_restore);
/**
* drm_crtc_vblank_restore - estimate missed vblanks and update vblank count.
@@ -1531,9 +1517,18 @@ EXPORT_SYMBOL(drm_vblank_restore);
* _crtc_funcs.enable_vblank implementation to estimate missed vblanks
since
* the last _crtc_funcs.disable_vblank using timestamps and update the
* vblank counter.
+ *
+ * Note that drivers must have race-free high-precision timestamping support,
+ * i.e. _crtc_funcs.get_vblank_timestamp must be hooked up and
+ * _driver.vblank_disable_immediate must be set to indicate the
+ * time-stamping functions are race-free against vblank hardware counter
+ * increments.
*/
void drm_crtc_vblank_restore(struct drm_crtc *crtc)
{
+ WARN_ON_ONCE(!crtc->funcs->get_vblank_timestamp);
+ WARN_ON_ONCE(!crtc->dev->vblank_disable_immediate);
+
drm_vblank_restore(crtc->dev, drm_crtc_index(crtc));
}
EXPORT_SYMBOL(drm_crtc_vblank_restore);
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index dd125f8c766c..733a3e2d1d10 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -247,7 +247,6 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
void drm_crtc_vblank_reset(struct drm_crtc *crtc);
void drm_crtc_vblank_on(struct drm_crtc *crtc);
u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
-void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
void drm_crtc_vblank_restore(struct drm_crtc *crtc);
void drm_calc_timestamping_constants(struct drm_crtc *crtc,
--
2.30.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vblank: Avoid storing a timestamp for the same frame twice
On Thu, Feb 04, 2021 at 04:04:00AM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_vblank_restore() exists because certain power saving states > can clobber the hardware frame counter. The way it does this is > by guesstimating how many frames were missed purely based on > the difference between the last stored timestamp vs. a newly > sampled timestamp. > > If we should call this function before a full frame has > elapsed since we sampled the last timestamp we would end up > with a possibly slightly different timestamp value for the > same frame. Currently we will happily overwrite the already > stored timestamp for the frame with the new value. This > could cause userspace to observe two different timestamps > for the same frame (and the timestamp could even go > backwards depending on how much error we introduce when > correcting the timestamp based on the scanout position). > > To avoid that let's not update the stored timestamp unless we're > also incrementing the sequence counter. We do still want to update > vblank->last with the freshly sampled hw frame counter value so > that subsequent vblank irqs/queries can actually use the hw frame > counter to determine how many frames have elapsed. > > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä Ok, top-posting because lol I got confused. I mixed up the guesstimation work we do for when we don't have a vblank counter with the precise vblank timestamp stuff. I think it'd still be good to maybe lock down/document a bit better the requirements for drm_crtc_vblank_restore, but I convinced myself now that your patch looks correct. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_vblank.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index 893165eeddf3..e127a7db2088 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -176,6 +176,17 @@ static void store_vblank(struct drm_device *dev, > unsigned int pipe, > > vblank->last = last; > > + /* > + * drm_vblank_restore() wants to always update > + * vblank->last since we can't trust the frame counter > + * across power saving states. But we don't want to alter > + * the stored timestamp for the same frame number since > + * that would cause userspace to potentially observe two > + * different timestamps for the same frame. > + */ > + if (vblank_count_inc == 0) > + return; > + > write_seqlock(>seqlock); > vblank->time = t_vblank; > atomic64_add(vblank_count_inc, >count); > -- > 2.26.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
Quoting Chris Wilson (2021-02-09 09:22:09)
> Quoting Ville Syrjala (2021-02-09 02:19:16)
> > + while ((src_x + src_w) * cpp >
> > plane_state->color_plane[0].stride) {
> > + if (offset == 0) {
> > + drm_dbg_kms(_priv->drm,
> > + "Unable to find suitable
> > display surface offset due to X-tiling\n");
> > + return -EINVAL;
> > + }
> > +
> > + offset = intel_plane_adjust_aligned_offset(_x,
> > _y, plane_state, 0,
> > + offset,
> > offset - alignment);
> The reason for choosing a nearby tile offset was to reduce src_x/src_y
> to fit within the crtc limits. While remapping could be used to solve
> that, the aligned_offset computation allows reuse of a single view.
Should there not be a second constraint on the loop to make sure src_x +
src_w is less than 4095/8191/etc?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Warn when releasing a frontbuffer while in use
Quoting Ville Syrjala (2021-02-09 02:19:18) > From: Ville Syrjälä > > Let's scream if we are about to release a frontbuffer which > is still in use. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_frontbuffer.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c > b/drivers/gpu/drm/i915/display/intel_frontbuffer.c > index 7b38eee9980f..6fc6965b6133 100644 > --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c > +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c > @@ -224,6 +224,8 @@ static void frontbuffer_release(struct kref *ref) > struct drm_i915_gem_object *obj = front->obj; > struct i915_vma *vma; > > + drm_WARN_ON(obj->base.dev, atomic_read(>bits)); I had to double check the meaning of bits, and indeed they are cleared by intel_frontbuffer_track as the scanout is switched away from the object. A stacktrace here isn't particularly useful for tracking down the leak, but it is a trivial method to make CI pay attention. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Disallow plane x+w>stride on ilk+ with X-tiling
Quoting Ville Syrjala (2021-02-09 02:19:16)
> From: Ville Syrjälä
>
> ilk+ planes get notably unhappy when the plane x+w exceeds
> the stride. This wasn't a problem previously because we
> always aligned SURF to the closest tile boundary so the
> x offset never got particularly large. But now with async
> flips we have to align to 256KiB instead and thus this
> becomes a real issue.
>
> On ilk/snb/ivb it looks like the accesses just just wrap
> early to the next tile row when scanout goes past the
> SURF+n*stride boundary, hsw/bdw suffer more heavily and
> start to underrun constantly. i965/g4x appear to be immune.
> vlv/chv I've not yet checked.
>
> Let's borrow another trick from the skl+ code and search
> backwards for a better SURF offset in the hopes of getting the
> x offset below the limit. IIRC when I ran into a similar issue
> on skl years ago it was causing the hardware to fall over
> pretty hard as well.
>
> And let's be consistent and include i965/g4x in the check
> as well, just in case I just got super lucky somehow when
> I wasn't able to reproduce the issue. Not that it really
> matters since we still use 4k SURF alignment for i965/g4x
> anyway.
>
> Fixes: 6ede6b0616b2 ("drm/i915: Implement async flips for vlv/chv")
> Fixes: 4bb18054adc4 ("drm/i915: Implement async flip for ilk/snb")
> Fixes: 2a636e240c77 ("drm/i915: Implement async flip for ivb/hsw")
> Fixes: cda195f13abd ("drm/i915: Implement async flips for bdw")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/i9xx_plane.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c
> b/drivers/gpu/drm/i915/display/i9xx_plane.c
> index 0523e2c79d16..8a52beaed2da 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_plane.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
> @@ -255,6 +255,33 @@ int i9xx_check_plane_surface(struct intel_plane_state
> *plane_state)
> else
> offset = 0;
>
> + /*
> +* When using an X-tiled surface the plane starts to
> +* misbehave if the x offset + width exceeds the stride.
> +* hsw/bdw: underrun galore
> +* ilk/snb/ivb: wrap to the next tile row mid scanout
> +* i965/g4x: so far appear immune to this
> +* vlv/chv: TODO check
> +*
> +* Linear surfaces seem to work just fine, even on hsw/bdw
> +* despite them not using the linear offset anymore.
> +*/
> + if (INTEL_GEN(dev_priv) >= 4 && fb->modifier ==
> I915_FORMAT_MOD_X_TILED) {
> + u32 alignment = intel_surf_alignment(fb, 0);
> + int cpp = fb->format->cpp[0];
> +
> + while ((src_x + src_w) * cpp >
> plane_state->color_plane[0].stride) {
> + if (offset == 0) {
> + drm_dbg_kms(_priv->drm,
> + "Unable to find suitable display
> surface offset due to X-tiling\n");
> + return -EINVAL;
> + }
> +
> + offset = intel_plane_adjust_aligned_offset(_x,
> _y, plane_state, 0,
> + offset,
> offset - alignment);
As offset decreases, src_x goes up; but modulus the pitch. So long as
the alignment is not a multiple of the pitch, src_x will change on each
iteration. And after the adjustment, the offset is stored in
plane_state.
So this loop would fail for any power-of-two stride, but at the same
time that would put the src_x + src_w out-of-bounds in the supplied
coordinates. The only way src_x + src_w would exceed stride legally is
if we have chosen an aligned offset that causes that, thus there should
exist an offset where src_x + src_w does not exceed the stride.
The reason for choosing a nearby tile offset was to reduce src_x/src_y
to fit within the crtc limits. While remapping could be used to solve
that, the aligned_offset computation allows reuse of a single view.
Since offset, src_x are a function of the plane input parameters, this
should be possible to exercise with carefully selected framebuffers and
modesetting. Right? Is there a test case for this?
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/31] drm/i915: Fair low-latency scheduling
On 08/02/2021 10:52, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 35bbe2b80596..f1d009906f71 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -1,3 +1,65 @@ +choice + prompt "Preferred scheduler" + default DRM_I915_SCHED_VIRTUAL_DEADLINE + help + Select the preferred method to decide the order of execution. + + The scheduler is used for two purposes. First to defer unready + jobs to not block execution of independent ready clients, so + preventing GPU stalls while work waits for other tasks. The second + purpose is to decide which task to run next, as well as decide + if that task should preempt the currently running task, or if + the current task has exceeded its allotment of GPU time and should + be replaced. + + config DRM_I915_SCHED_FIFO + bool "FIFO" + help + No task reordering, tasks are executed in order of readiness. + First in, first out. + + Unready tasks do not block execution of other, independent clients. + A client will not be scheduled for execution until all of its + prerequisite work has completed. + + This disables the scheduler and puts it into a pass-through mode. + + config DRM_I915_SCHED_PRIORITY + bool "Priority" + help + Strict priority ordering, equal priority tasks are executed + in order of readiness. Clients are liable to starve other clients, + causing uneven execution and excess task latency. High priority + clients will preempt lower priority clients and will run + uninterrupted. + + Note that interactive desktops will implicitly perform priority + boosting to minimise frame jitter. + + config DRM_I915_SCHED_VIRTUAL_DEADLINE + bool "Virtual Deadline" + help + A fair scheduler based on MuQSS with priority-hinting. + + When a task is ready for execution, it is given a quota (from the + engine's timeslice) and a virtual deadline. The virtual deadline is + derived from the current time and the timeslice scaled by the + task's priority. Higher priority tasks are given an earlier + deadline and receive a large portion of the execution bandwidth. + + Requests are then executed in order of deadline completion. + Requests with earlier deadlines and higher priority than currently + executing on the engine will preempt the active task. + +endchoice + +config DRM_I915_SCHED + int + default 2 if DRM_I915_SCHED_VIRTUAL_DEADLINE + default 1 if DRM_I915_SCHED_PRIORITY + default 0 if DRM_I915_SCHED_FIFO + default -1 Default -1 would mean it would ask the user and not default to deadline? Implementation wise it is very neat how you did it so there is basically very little cost for the compiled out options. And code maintenance cost to support multiple options is pretty trivial as well. Only cost I can see is potential bug reports if "wrong" scheduler was picked by someone. What do you envisage, or who, would be the use cases for not going with deadline? (I think deadline should be default.) Then there is a question of how these kconfig will interact, or at least what their semantics would be, considering the GuC. I think we can modify the kconfig blurb to say they only apply to execlists platforms, once we get a GuC scheduling platform upstream. And fudge some sched mode bits for sysfs reporting in that case. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix overlay frontbuffer tracking
Quoting Ville Syrjala (2021-02-09 02:19:17)
> From: Ville Syrjälä
>
> We don't have a persistent fb holding a reference to the frontbuffer
> object, so every time we do the get+put we throw the frontbuffer object
> immediately away. And so the next time around we get a pristine
> frontbuffer object with bits==0 even for the old vma. This confuses
> the frontbuffer tracking code which understandably expects the old
> frontbuffer to have the overlay's bit set.
>
> Fix this by hanging on to the frontbuffer reference until the next
> flip. And just to make this a bit more clear let's track the frontbuffer
> explicitly instead of just grabbing it via the old vma.
>
> Cc: sta...@vger.kernel.org
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136
> Fixes: da42104f589d ("drm/i915: Hold reference to intel_frontbuffer as we
> track activity")
Maybe more apropos, same kernel though
Fixes: 8e7cb1799b4f ("drm/i915: Extract intel_frontbuffer active tracking")
Ok, so this definitely used to be swapping between the
obj->frontbuffer_bits and so used to have a persistent reference.
Keeping the frontbuffer tracking with the overlay makes even more sense.
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/display/intel_overlay.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index 9c0113f15b58..ef8f44f5e751 100644
> --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> @@ -183,6 +183,7 @@ struct intel_overlay {
> struct intel_crtc *crtc;
> struct i915_vma *vma;
> struct i915_vma *old_vma;
> + struct intel_frontbuffer *frontbuffer;
> bool active;
> bool pfit_active;
> u32 pfit_vscale_ratio; /* shifted-point number, (1<<12) == 1.0 */
> @@ -283,21 +284,19 @@ static void intel_overlay_flip_prepare(struct
> intel_overlay *overlay,
>struct i915_vma *vma)
> {
> enum pipe pipe = overlay->crtc->pipe;
> - struct intel_frontbuffer *from = NULL, *to = NULL;
> + struct intel_frontbuffer *frontbuffer = NULL;
>
> drm_WARN_ON(>i915->drm, overlay->old_vma);
>
> - if (overlay->vma)
> - from = intel_frontbuffer_get(overlay->vma->obj);
> if (vma)
> - to = intel_frontbuffer_get(vma->obj);
> + frontbuffer = intel_frontbuffer_get(vma->obj);
>
> - intel_frontbuffer_track(from, to, INTEL_FRONTBUFFER_OVERLAY(pipe));
> + intel_frontbuffer_track(overlay->frontbuffer, frontbuffer,
> + INTEL_FRONTBUFFER_OVERLAY(pipe));
>
> - if (to)
> - intel_frontbuffer_put(to);
> - if (from)
> - intel_frontbuffer_put(from);
> + if (overlay->frontbuffer)
> + intel_frontbuffer_put(overlay->frontbuffer);
> + overlay->frontbuffer = frontbuffer;
And this will drop the ref on overlay->frontbuffer as we flip to NULL on
shutdown.
Now if only someone still had the code to expose sprites instead of
overlays.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [FYI PATCH] i915: kvmgt: the KVM mmu_lock is now an rwlock
Hi Paolo,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on linux/master drm-tip/drm-tip linus/master v5.11-rc6
next-20210125]
[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/Paolo-Bonzini/i915-kvmgt-the-KVM-mmu_lock-is-now-an-rwlock/20210209-070812
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/e1625dbf5fa4aea9c53da01a04bfb55443375c30
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Paolo-Bonzini/i915-kvmgt-the-KVM-mmu_lock-is-now-an-rwlock/20210209-070812
git checkout e1625dbf5fa4aea9c53da01a04bfb55443375c30
# save the attached .config to linux build tree
make W=1 ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'kvmgt_page_track_add':
>> drivers/gpu/drm/i915/gvt/kvmgt.c:1706:13: error: passing argument 1 of
>> '_raw_write_lock' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
1706 | write_lock(>mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock.h:70:42: note: in definition of macro 'write_lock'
70 | #define write_lock(lock) _raw_write_lock(lock)
| ^~~~
In file included from include/linux/spinlock_api_smp.h:190,
from include/linux/spinlock.h:318,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
include/linux/rwlock_api_smp.h:19:43: note: expected 'rwlock_t *' {aka
'struct *'} but argument is of type 'spinlock_t *' {aka 'struct
spinlock *'}
19 | void __lockfunc _raw_write_lock(rwlock_t *lock) __acquires(lock);
| ~~^~~~
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
>> drivers/gpu/drm/i915/gvt/kvmgt.c:1715:15: error: passing argument 1 of
>> '_raw_write_unlock' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
1715 | write_unlock(>mmu_lock);
| ^~
| |
| spinlock_t * {aka struct spinlock *}
include/linux/rwlock.h:106:47: note: in definition of macro 'write_unlock'
106 | #define write_unlock(lock) _raw_write_unlock(lock)
| ^~~~
In file included from include/linux/spinlock_api_smp.h:190,
from include/linux/spinlock.h:318,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
include/linux/rwlock_api_smp.h:31:45: note: expected 'rwlock_t *' {aka
'struct *'} but argument is of type 'spinlock_t *' {aka 'struct
spinlock *'}
31 | void __lockfunc _raw_write_unlock(rwlock_t *lock) __releases(lock);
| ~~^~~~
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux
