[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Don't use port enum as register offset (rev3)
== Series Details ==
Series: drm/i915/display: Don't use port enum as register offset (rev3)
URL : https://patchwork.freedesktop.org/series/108833/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12171 -> Patchwork_108833v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/index.html
Participating hosts (44 -> 43)
--
Missing(1): fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108833v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-adln-1}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-adln-1/igt@i915_module_l...@load.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-adln-1/igt@i915_module_l...@load.html
- {bat-rplp-1}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-rplp-1/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-rplp-1/igt@i915_module_l...@load.html
- {bat-dg2-9}:[PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-dg2-9/igt@i915_module_l...@load.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-dg2-9/igt@i915_module_l...@load.html
- {bat-adlp-6}: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-adlp-6/igt@i915_module_l...@load.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-adlp-6/igt@i915_module_l...@load.html
- {bat-dg2-11}: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-dg2-11/igt@i915_module_l...@load.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-dg2-11/igt@i915_module_l...@load.html
- {bat-adlm-1}: [PASS][11] -> [DMESG-WARN][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-adlm-1/igt@i915_module_l...@load.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-adlm-1/igt@i915_module_l...@load.html
- {bat-dg2-8}:[PASS][13] -> [DMESG-WARN][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-dg2-8/igt@i915_module_l...@load.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/bat-dg2-8/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_108833v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@load:
- fi-adl-ddr5:[PASS][15] -> [INCOMPLETE][16] ([i915#1982])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-adl-ddr5/igt@i915_module_l...@load.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-adl-ddr5/igt@i915_module_l...@load.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][17] -> [INCOMPLETE][18] ([i915#4785])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][19] ([i915#4817])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][20] ([fdo#109271] / [i915#4312] /
[i915#5594])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-hsw-4770/igt@run...@aborted.html
- fi-adl-ddr5:NOTRUN -> [FAIL][21] ([i915#4312])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-adl-ddr5/igt@run...@aborted.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-tgl-mst}: [DMESG-WARN][22] -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [INCOMPLETE][24] ([i915#2940]) -> [PASS][25]
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-mst}: [DMESG-FAIL][26] ([i9
Re: [Intel-gfx] [PATCH] drm/i915: Fix CFI violations in gt_sysfs
Hi Nathan,
On 22/09/2022 20:51, Nathan Chancellor wrote:
When booting with clang's kernel control flow integrity series [1],
there are numerous violations when accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
$ grep . *
id:0
punit_req_freq_mhz:350
rc6_enable:1
rc6_residency_ms:214934
rps_act_freq_mhz:1300
rps_boost_freq_mhz:1300
rps_cur_freq_mhz:350
rps_max_freq_mhz:1300
rps_min_freq_mhz:350
rps_RP0_freq_mhz:1300
rps_RP1_freq_mhz:350
rps_RPn_freq_mhz:350
throttle_reason_pl1:0
throttle_reason_pl2:0
throttle_reason_pl4:0
throttle_reason_prochot:0
throttle_reason_ratl:0
throttle_reason_status:0
throttle_reason_thermal:0
throttle_reason_vr_tdc:0
throttle_reason_vr_thermalert:0
$ sudo dmesg &| grep "CFI failure at"
CFI = control flow integrity - adding Andi and Ashutosh as primary
authors of the code in question on our side to take a look please.
Regards,
Tvrtko
[ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target:
id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
[ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target:
punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
[ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target:
rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
[ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target:
act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target:
boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target:
cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target:
max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target:
min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target:
RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target:
RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
[ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
[ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target:
throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
With kCFI, indirect calls are validated against their expected type
versus actual type and failures occur when the two types do not match.
The ultimate issue is that these sysfs functions are expecting to be
called via dev_attr_show() but they may also be called via
kobj_attr_show(), as certain files are created under two different
kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
hence the warnings above. When accessing the gt_ files under
/sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
sysfs functions, there are no violations, meaning the functions are
being called with the proper type.
To make everything work properly, adjust certain functions to match the
type of the ->show() and ->store() members in 'struct kobj_attribute'.
Add a macro to generate functions for that can be called via both
dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
called through both kobject locations without violating kCFI and adjust
the attribute groups to account for this.
[1]: https://lore.kernel.org/20220908215504.3686827-1-samitolva...@google.com/
Link: https://github.com/
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Delay disabling GuC scheduling of an idle context
== Series Details == Series: Delay disabling GuC scheduling of an idle context URL : https://patchwork.freedesktop.org/series/108931/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH] drm/i915: Improve debug print in vm_fault_ttm
On 9/22/2022 6:38 PM, Matthew Auld wrote:
On 22/09/2022 13:09, Nirmoy Das wrote:
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..9619c0fe1025 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault
*vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU accessible(err
= %pe)\n", err);
Yeah, looks useful. I think for that bug the object is just too large
for the mappable part of lmem, so this just gives -2big or similar on
small-bar systems. I presume that the test needs to be updated to
account for the cpu_size or so.
Yeah, can't think of any other case. The test need to be updated, going
to send out igt fixes for this.
With the kernel test robot warning fixed:
Acked-by: Matthew Auld
Thanks, I will resend a updated one.
I looked at the GEM_BUG_ON(rq->reserved_space > ring->space), and I
think the issue is maybe with emit_pte() using the ring->space to
manually figure out the number of dwords it can emit (instead of the
usual ring_begin()), which I guess works, but if we are unlucky and
get interrupted (like with a very well timed sigbus here), while
waiting for more ring space and end up bailing early, we might have
trampled over the reserved_space when submitting the request. I guess
normally the next ring_begin() would take care of the reserved_space,
like when constructing the actual copy packet.
I am not so familiar with the code but sounds logical.
Nirmoy
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
[Intel-gfx] [PATCH 1/2] drm/i915: Fix a potential UAF at device unload
i915_gem_drain_freed_objects() might not be enough to
free all the objects and RCU delayed work might get
scheduled after the i915 device struct gets freed.
Call i915_gem_drain_workqueue() to catch all RCU delayed work.
Suggested-by: Chris Wilson
Acked-by: Tvrtko Ursulin
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 88df9a35e0fe..7541028caebd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1278,7 +1278,7 @@ void i915_gem_init_early(struct drm_i915_private
*dev_priv)
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv)
{
- i915_gem_drain_freed_objects(dev_priv);
+ i915_gem_drain_workqueue(dev_priv);
GEM_BUG_ON(!llist_empty(&dev_priv->mm.free_list));
GEM_BUG_ON(atomic_read(&dev_priv->mm.free_count));
drm_WARN_ON(&dev_priv->drm, dev_priv->mm.shrink_count);
--
2.37.3
[Intel-gfx] [PATCH 2/2] drm/i915: remove excessive i915_gem_drain_freed_objects
i915_gem_drain_workqueue() call i915_gem_drain_freed_objects() so no need to call that again. Reviewed-by: Tvrtko Ursulin Signed-off-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_gem.c | 2 -- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 - 2 files changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 7541028caebd..55d605c0c55d 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1236,8 +1236,6 @@ void i915_gem_driver_remove(struct drm_i915_private *dev_priv) /* Flush any outstanding unpin_work. */ i915_gem_drain_workqueue(dev_priv); - - i915_gem_drain_freed_objects(dev_priv); } void i915_gem_driver_release(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c index fff11c90f1fa..f6a7c0bd2955 100644 --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c @@ -67,7 +67,6 @@ static void mock_device_release(struct drm_device *dev) intel_gt_driver_remove(to_gt(i915)); i915_gem_drain_workqueue(i915); - i915_gem_drain_freed_objects(i915); mock_fini_ggtt(to_gt(i915)->ggtt); destroy_workqueue(i915->wq); -- 2.37.3
[Intel-gfx] ✓ Fi.CI.BAT: success for Delay disabling GuC scheduling of an idle context
== Series Details ==
Series: Delay disabling GuC scheduling of an idle context
URL : https://patchwork.freedesktop.org/series/108931/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12171 -> Patchwork_108931v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/index.html
Participating hosts (44 -> 42)
--
Missing(2): fi-hsw-4770 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_108931v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][1] ([i915#4817])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-tgl-mst}: [DMESG-WARN][2] -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][4] ([i915#2867]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][6] ([i915#6816]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [INCOMPLETE][8] ([i915#2940]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-mst}: [DMESG-FAIL][10] ([i915#3987]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hugepages:
- {bat-rpls-1}: [DMESG-WARN][12] ([i915#5278]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][14] ([i915#6298]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6816]: https://gitlab.freedesktop.org/drm/intel/issues/6816
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12171 -> Patchwork_108931v1
CI-20190529: 20190529
CI_DRM_12171: 37f64f22c82d8003c6509dd8e4928ee0348bd27f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108931v1: 37f64f22c82d8003c6509dd8e4928ee0348bd27f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
889a8f07d9c4 drm/i915/guc: Delay disabling guc_id scheduling for better
hysteresis
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/index.html
[Intel-gfx] [PULL] drm-misc-next
Hi Daniel, Dave, We haven't had a drm-misc-next PR for a while, so here it is. It should be the last drm-misc-next PR for 6.1 Maxime drm-misc-next-2022-09-23: drm-misc-next for 6.1: UAPI Changes: Cross-subsystem Changes: - dma-buf: Improve signaling when debugging Core Changes: - Backlight handling improvements - format-helper: Add drm_fb_build_fourcc_list() - fourcc: Kunit tests improvements - modes: Add DRM_MODE_INIT() macro - plane: Remove drm_plane_init(), Allocate planes with drm_universal_plane_alloc() - plane-helper: Add drm_plane_helper_atomic_check() - probe-helper: Add drm_connector_helper_get_modes_fixed() and drm_crtc_helper_mode_valid_fixed() - tests: Conversion to parametrized tests, test name consistency Driver Changes: - amdgpu: Fix for a VRAM eviction issue - ast: Resolution handling improvements - mediatek: small code improvements for DP - omap: Refcounting fix, small improvements - rockchip: RK3568 support, Gamma support for RK3399 - sun4i: Build failure fix when !OF - udl: Multiple fixes here and there - vc4: HDMI hotplug handling improvements - vkms: Warning fix The following changes since commit 213cb76ddc8b875e772f9f4d173feefa122716af: Merge tag 'drm-intel-gt-next-2022-09-09' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-09-12 21:12:23 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-09-23 for you to fetch changes up to 39dd0cc2e5bd0d5188dd69f27e18783cea7ff06a: drm/amdgpu: Fix VRAM eviction issue (2022-09-22 19:53:06 +0200) drm-misc-next for 6.1: UAPI Changes: Cross-subsystem Changes: - dma-buf: Improve signaling when debugging Core Changes: - Backlight handling improvements - format-helper: Add drm_fb_build_fourcc_list() - fourcc: Kunit tests improvements - modes: Add DRM_MODE_INIT() macro - plane: Remove drm_plane_init(), Allocate planes with drm_universal_plane_alloc() - plane-helper: Add drm_plane_helper_atomic_check() - probe-helper: Add drm_connector_helper_get_modes_fixed() and drm_crtc_helper_mode_valid_fixed() - tests: Conversion to parametrized tests, test name consistency Driver Changes: - amdgpu: Fix for a VRAM eviction issue - ast: Resolution handling improvements - mediatek: small code improvements for DP - omap: Refcounting fix, small improvements - rockchip: RK3568 support, Gamma support for RK3399 - sun4i: Build failure fix when !OF - udl: Multiple fixes here and there - vc4: HDMI hotplug handling improvements - vkms: Warning fix Arunpravin Paneer Selvam (1): drm/amdgpu: Fix VRAM eviction issue Arvind Yadav (5): dma-buf: Remove the signaled bit status check dma-buf: set signaling bit for the stub fence dma-buf: Enable signaling on fence for selftests dma-buf: dma_fence_wait must enable signaling drm/sched: Use parent fence instead of finished Bo-Chen Chen (3): drm/mediatek: dp: Reduce indentation in mtk_dp_bdg_detect() drm/mediatek: dp: Remove unused register definitions drm/mediatek: dp: Fix compiler warning in mtk_dp_video_mute() Chris Morgan (2): dt-bindings: display: rockchip-dsi: add rk3568 compatible drm/rockchip: dsi: add rk3568 support Christian König (1): dma-buf: fix dma_fence_default_wait() signaling check Gaosheng Cui (5): drm/vmwgfx: remove unused vmw_bo_is_vmw_bo() declaration drm/radeon/r600_cs: remove r600_cs_legacy_get_tiling_conf() declaration drm/radeon: remove unused declarations for radeon drm/gma500: remove unused declarations in psb_intel_drv.h drm/amd/pm: remove unused declarations in hardwaremanager.h Guo Zhengkui (1): drm: omapdrm: dss: replace ternary operator with max() Hamza Mahfooz (1): drm/bridge: it6505: use drm_debug_enabled() in it6505_debug_print() Hans de Goede (42): ACPI: video: Add acpi_video_backlight_use_native() helper drm/i915: Don't register backlight when another backlight should be used (v2) drm/amdgpu: Don't register backlight when another backlight should be used (v3) drm/radeon: Don't register backlight when another backlight should be used (v3) drm/nouveau: Don't register backlight when another backlight should be used (v2) ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() ACPI: video: Remove acpi_video_bus from list before tearing it down ACPI: video: Simplify acpi_video_unregister_backlight() ACPI: video: Make backlight class device registration a separate step (v2) ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers drm/i915: Call acpi_video_register_backlight() (v3) drm/nouveau: Register ACPI video backlight when nv_ba
Re: [Intel-gfx] [RFC v4 03/14] drm/i915/vm_bind: Expose i915_gem_object_max_page_size()
On 22/09/2022 17:18, Matthew Auld wrote:
On 22/09/2022 09:09, Tvrtko Ursulin wrote:
On 21/09/2022 19:00, Niranjana Vishwanathapura wrote:
On Wed, Sep 21, 2022 at 10:13:12AM +0100, Tvrtko Ursulin wrote:
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
Expose i915_gem_object_max_page_size() function non-static
which will be used by the vm_bind feature.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/gem/i915_gem_create.c | 20 +++-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 ++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..3b3ab4abb0a3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -11,14 +11,24 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
+#include "i915_gem_context.h"
I can't spot that you are adding any code which would need this?
I915_GTT_PAGE_SIZE_4K? It is in intel_gtt.h.
This include should have been added in a later patch for calling
i915_gem_vm_lookup(). But got added here while patch refactoring.
Will fix.
#include "i915_gem_create.h"
#include "i915_trace.h"
#include "i915_user_extensions.h"
-static u32 object_max_page_size(struct intel_memory_region
**placements,
- unsigned int n_placements)
+/**
+ * i915_gem_object_max_page_size() - max of min_page_size of the
regions
+ * @placements: list of regions
+ * @n_placements: number of the placements
+ *
+ * Calculates the max of the min_page_size of a list of placements
passed in.
+ *
+ * Return: max of the min_page_size
+ */
+u32 i915_gem_object_max_page_size(struct intel_memory_region
**placements,
+ unsigned int n_placements)
{
- u32 max_page_size = 0;
+ u32 max_page_size = I915_GTT_PAGE_SIZE_4K;
int i;
for (i = 0; i < n_placements; i++) {
@@ -28,7 +38,6 @@ static u32 object_max_page_size(struct
intel_memory_region **placements,
max_page_size = max_t(u32, max_page_size, mr->min_page_size);
}
- GEM_BUG_ON(!max_page_size);
return max_page_size;
}
@@ -99,7 +108,8 @@ __i915_gem_object_create_user_ext(struct
drm_i915_private *i915, u64 size,
i915_gem_flush_free_objects(i915);
- size = round_up(size, object_max_page_size(placements,
n_placements));
+ size = round_up(size, i915_gem_object_max_page_size(placements,
+ n_placements));
if (size == 0)
return ERR_PTR(-EINVAL);
Because of the changes above this path is now unreachable. I suppose
it was meant to tell the user "you have supplied no placements"? But
then GEM_BUG_ON (which you remove) used to be wrong.
Yah, looks like an existing problem. May be this "size == 0" check
should have been made before we do the round_up()? ie., check input
'size'
paramter is not 0?
I think for now, I will remove this check as it was unreachable anyhow.
Hm that's true as well. i915_gem_create_ext_ioctl ensures at least one
placement and internal callers do as well.
To be safe, instead of removing maybe move to before "size = " and
change to "if (GEM_WARN_ON(n_placements == 0))"? Not sure.. Matt any
thoughts here given the changes in this patch?
The check is also to reject a zero sized object with args->size = 0, i.e
round_up(0, PAGE_SIZE) == 0. So for sure that is still needed here.
Oh yeah sneaky round up.. Thanks, my bad.
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Mark FBC B gone if pipe B is gone
On Fri, Sep 23, 2022 at 09:24:28AM +0300, Luca Coelho wrote:
> On Thu, 2022-09-22 at 14:57 +0300, Ville Syrjälä wrote:
> > On Thu, Sep 22, 2022 at 02:37:35PM +0300, Luca Coelho wrote:
> > > On Thu, 2022-09-22 at 12:36 +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 22, 2022 at 11:51:16AM +0300, Jani Nikula wrote:
> > > > > On Thu, 22 Sep 2022, Ville Syrjälä
> > > > > wrote:
> > > > > > On Thu, Sep 22, 2022 at 11:18:55AM +0300, Luca Coelho wrote:
> > > > > > > On Fri, 2022-09-16 at 19:52 +0300, Ville Syrjala wrote:
> > > > > > > > From: Ville Syrjälä
> > > > > > > >
> > > > > > > > If pipe B is fused off we also shouldn't have FBC B.
> > > > > > > >
> > > > > > > > Signed-off-by: Ville Syrjälä
> > > > > > > > ---
> > > > > > > > drivers/gpu/drm/i915/intel_device_info.c | 1 +
> > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_device_info.c
> > > > > > > > index 1434dc33cf49..fbefebc023f1 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > > > > > > > @@ -394,6 +394,7 @@ void intel_device_info_runtime_init(struct
> > > > > > > > drm_i915_private *dev_priv)
> > > > > > > > if (dfsm & SKL_DFSM_PIPE_B_DISABLE) {
> > > > > > > > runtime->pipe_mask &= ~BIT(PIPE_B);
> > > > > > > > runtime->cpu_transcoder_mask &=
> > > > > > > > ~BIT(TRANSCODER_B);
> > > > > > > > + runtime->fbc_mask &= ~BIT(INTEL_FBC_B);
> > > > > > > > }
> > > > > > > > if (dfsm & SKL_DFSM_PIPE_C_DISABLE) {
> > > > > > > > runtime->pipe_mask &= ~BIT(PIPE_C);
> > > > > > >
> > > > > > > I don't know (yet) what exactly this does, but it makes sense if
> > > > > > > you
> > > > > > > think of consistency: we already do that for PIPE_A.
> > > > > >
> > > > > > It's basically saying the entire pipe is fused off, so anything
> > > > > > living inside that pipe should also be fused off.
> > > > > >
> > > > > > >
> > > > > > > But what about PIPE_C and PIPE_D? Wouldn't it make sense to do
> > > > > > > the same
> > > > > > > thing for them as well?
> > > > > >
> > > > > > There is no FBC engine on those pipes (we don't even have
> > > > > > the INTEL_FBC_C+ enum values defined), at least for now.
> > > > >
> > > > > A future proof way would be to add
> > > > >
> > > > > runtime->fbc_mask &= runtime->pipe_mask;
> > > >
> > > > Dunno if I entirely like the extra assumption that the enums match.
> > > > Also would need to make sure we don't accidentally screw up any
> > > > old platforms where FBC is not tied to a specific pipe, but I
> > > > guess we should never have pipe A fused off on those w/o
> > > > the entire display engine fused off as well.
> > >
> > > I must say I don't like the idea of making these assumptions across
> > > different masks either.
> > >
> > > I think that, since you are reading the DFSM register at runtime to
> > > check whether those pipes are fused off, you should go all the way and
> > > disable everything, including in the fbc_mask for all pipes. Then you
> > > don't need to make any assumptions about whether a pipe has FBC or not.
> > >
> > > In short, I think you could add those INTEL_FBC_C+ definitions and
> > > force-unset them here too...
> >
> > Hmm. I don't see any real problem with adding the FBC C+D
> > enum values even if not used by any platform currently.
> > Do you want to write that patch?
>
> Sure, I can do it. I guess it should be done _after_ your patch? Or
> should I just add those definitions and you'll rebase your patch? And
> there's a third option: I can add the definitions and replace your
> patch with one that does this for all PIPEs at once...
>
> Which one do you prefer?
I'm fine with just dropping my patch and you taking over the
the wholew thing. Less stuff for me to do ;)
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for DG2 fix for CCS starvation
== Series Details == Series: DG2 fix for CCS starvation URL : https://patchwork.freedesktop.org/series/108919/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12168_full -> Patchwork_108919v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108919v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108919v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108919v1_full: ### IGT changes ### Possible regressions * igt@kms_universal_plane@universal-plane-pipe-b-functional: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-tglb7/igt@kms_universal_pl...@universal-plane-pipe-b-functional.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-tglb8/igt@kms_universal_pl...@universal-plane-pipe-b-functional.html Known issues Here are the changes found in Patchwork_108919v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [FAIL][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) ([i915#4392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk1/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk1/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk2/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk2/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk3/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk3/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk3/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk6/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk6/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk8/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk9/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk3/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk3/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk2/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk2/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk2/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108919v1/shard-glk1/boot.html
Re: [Intel-gfx] [PATCH v2 01/33] drm/tests: Order Kunit tests in Makefile
Am 22.09.22 um 16:25 schrieb Maxime Ripard: Since we've recently added a ton of tests, the list starts to be a bit of a mess and creates unneeded conflicts. Let's order it alphabetically. Signed-off-by: Maxime Ripard Acked-by: Thomas Zimmermann diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile index 91b70f7d2769..2d9f49b62ecb 100644 --- a/drivers/gpu/drm/tests/Makefile +++ b/drivers/gpu/drm/tests/Makefile @@ -1,5 +1,13 @@ # SPDX-License-Identifier: GPL-2.0 -obj-$(CONFIG_DRM_KUNIT_TEST) += drm_format_helper_test.o drm_damage_helper_test.o \ - drm_cmdline_parser_test.o drm_rect_test.o drm_format_test.o drm_plane_helper_test.o \ - drm_dp_mst_helper_test.o drm_framebuffer_test.o drm_buddy_test.o drm_mm_test.o +obj-$(CONFIG_DRM_KUNIT_TEST) += \ + drm_buddy_test.o \ + drm_cmdline_parser_test.o \ + drm_damage_helper_test.o \ + drm_dp_mst_helper_test.o \ + drm_format_helper_test.o \ + drm_format_test.o \ + drm_framebuffer_test.o \ + drm_mm_test.o \ + drm_plane_helper_test.o \ + drm_rect_test.o -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Extend PSR support
On Wed, Sep 07, 2022 at 11:15:43AM +0300, Mika Kahola wrote:
> From: José Roberto de Souza
>
> Meteorlake and display 14 platform don't have any PSR differences
> when comparing to Alderlake-P display, so it was only necessary to
> extend some checks to properly program hardware.
>
> BSpec: 55229, 49196
Reviewed-by: Stanislav Lisovskiy
>
> Cc: Mika Kahola
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 31 +++-
> drivers/gpu/drm/i915/i915_reg.h | 5
> 2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 079b7d3d0c53..4170017969c9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -515,7 +515,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> val |= psr_compute_idle_frames(intel_dp) << EDP_PSR2_IDLE_FRAME_SHIFT;
>
> - if (!IS_ALDERLAKE_P(dev_priv))
> + if (DISPLAY_VER(dev_priv) <= 13 && !IS_ALDERLAKE_P(dev_priv))
> val |= EDP_SU_TRACK_ENABLE;
>
> if (DISPLAY_VER(dev_priv) >= 10 && DISPLAY_VER(dev_priv) <= 12)
> @@ -598,7 +598,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> static bool
> transcoder_has_psr2(struct drm_i915_private *dev_priv, enum transcoder trans)
> {
> - if (IS_ALDERLAKE_P(dev_priv))
> + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
> return trans == TRANSCODER_A || trans == TRANSCODER_B;
> else if (DISPLAY_VER(dev_priv) >= 12)
> return trans == TRANSCODER_A;
> @@ -678,7 +678,7 @@ dc3co_is_pipe_port_compatible(struct intel_dp *intel_dp,
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> enum port port = dig_port->base.port;
>
> - if (IS_ALDERLAKE_P(dev_priv))
> + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
> return pipe <= PIPE_B && port <= PORT_B;
> else
> return pipe == PIPE_A && port == PORT_A;
> @@ -777,11 +777,11 @@ static bool psr2_granularity_check(struct intel_dp
> *intel_dp,
> return intel_dp->psr.su_y_granularity == 4;
>
> /*
> - * adl_p has 1 line granularity. For other platforms with SW tracking we
> - * can adjust the y coordinates to match sink requirement if multiple of
> - * 4.
> + * adl_p and display 14+ platforms has 1 line granularity.
> + * For other platforms with SW tracking we can adjust the y coordinates
> + * to match sink requirement if multiple of 4.
>*/
> - if (IS_ALDERLAKE_P(dev_priv))
> + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14)
> y_granularity = intel_dp->psr.su_y_granularity;
> else if (intel_dp->psr.su_y_granularity <= 2)
> y_granularity = 4;
> @@ -864,7 +864,8 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
>* resolution requires DSC to be enabled, priority is given to DSC
>* over PSR2.
>*/
> - if (crtc_state->dsc.compression_enable) {
> + if (crtc_state->dsc.compression_enable &&
> + (DISPLAY_VER(dev_priv) <= 13 && !IS_ALDERLAKE_P(dev_priv))) {
> drm_dbg_kms(&dev_priv->drm,
> "PSR2 cannot be enabled since DSC is enabled\n");
> return false;
> @@ -1457,7 +1458,7 @@ static u32 man_trk_ctl_enable_bit_get(struct
> drm_i915_private *dev_priv)
>
> static u32 man_trk_ctl_single_full_frame_bit_get(struct drm_i915_private
> *dev_priv)
> {
> - return IS_ALDERLAKE_P(dev_priv) ?
> + return IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14 ?
> ADLP_PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME :
> PSR2_MAN_TRK_CTL_SF_SINGLE_FULL_FRAME;
> }
> @@ -1610,7 +1611,7 @@ static void psr2_man_trk_ctl_calc(struct
> intel_crtc_state *crtc_state,
> if (clip->y1 == -1)
> goto exit;
>
> - if (IS_ALDERLAKE_P(dev_priv)) {
> + if (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14) {
> val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_START_ADDR(clip->y1);
> val |= ADLP_PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR(clip->y2 - 1);
> } else {
> @@ -1647,7 +1648,15 @@ static void intel_psr2_sel_fetch_pipe_alignment(const
> struct intel_crtc_state *c
> struct drm_rect *pipe_clip)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> - const u16 y_alignment = crtc_state->su_y_granularity;
> + const struct drm_dsc_config *vdsc_cfg = &crtc_state->dsc.config;
> + u16 y_alignment;
> +
> + /* ADLP aligns the SU region to vdsc slice height in case dsc is
> enabled */
> + if (crtc_state->dsc.compression_enable &&
> + (IS_ALDERLAKE_P(dev_priv) || DISPLAY_VER(dev_priv) >= 14))
Re: [Intel-gfx] [PATCH v2 03/33] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
We currently have two sets of TV properties.
The first one is there to deal with analog TV properties, creating
properties such as the TV mode, subconnectors, saturation, hue and so on.
It's created by calling the drm_mode_create_tv_properties() function.
The second one is there to deal with properties that might be useful on a
TV, creating the overscan margins for example. It's created by calling the
drm_mode_create_tv_margin_properties().
However, we also have a drm_atomic_helper_connector_tv_reset() function
that will reset the TV margin properties to their default values, and thus
is supposed to be called for the latter set. This creates an ambiguity due
to the inconsistent naming.
We can thus rename the drm_atomic_helper_connector_tv_reset() function to
drm_atomic_helper_connector_tv_margins_reset() to remove that ambiguity
and hopefully make it more obvious.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index bf31b9d92094..dfb57217253b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -464,12 +464,12 @@ void drm_atomic_helper_connector_reset(struct
drm_connector *connector)
EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
/**
- * drm_atomic_helper_connector_tv_reset - Resets TV connector properties
+ * drm_atomic_helper_connector_tv_margins_reset - Resets TV connector
properties
* @connector: DRM connector
*
* Resets the TV-related properties attached to a connector.
*/
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector)
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector
*connector)
{
struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
struct drm_connector_state *state = connector->state;
@@ -479,7 +479,7 @@ void drm_atomic_helper_connector_tv_reset(struct
drm_connector *connector)
state->tv.margins.top = cmdline->tv_margins.top;
state->tv.margins.bottom = cmdline->tv_margins.bottom;
}
-EXPORT_SYMBOL(drm_atomic_helper_connector_tv_reset);
+EXPORT_SYMBOL(drm_atomic_helper_connector_tv_margins_reset);
/**
* __drm_atomic_helper_connector_duplicate_state - copy atomic connector state
diff --git a/drivers/gpu/drm/gud/gud_connector.c
b/drivers/gpu/drm/gud/gud_connector.c
index d0addd478815..fa636206f232 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -355,7 +355,7 @@ static void gud_connector_reset(struct drm_connector
*connector)
drm_atomic_helper_connector_reset(connector);
connector->state->tv = gconn->initial_tv_state;
/* Set margins from command line */
- drm_atomic_helper_connector_tv_reset(connector);
+ drm_atomic_helper_connector_tv_margins_reset(connector);
if (gconn->initial_brightness >= 0)
connector->state->tv.brightness = gconn->initial_brightness;
}
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 4d3ff51ad2a8..fe01ca5a07d3 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -396,7 +396,7 @@ static void vc4_hdmi_connector_reset(struct drm_connector
*connector)
new_state->base.max_bpc = 8;
new_state->base.max_requested_bpc = 8;
new_state->output_format = VC4_HDMI_OUTPUT_RGB;
- drm_atomic_helper_connector_tv_reset(connector);
+ drm_atomic_helper_connector_tv_margins_reset(connector);
}
static struct drm_connector_state *
diff --git a/include/drm/drm_atomic_state_helper.h
b/include/drm/drm_atomic_state_helper.h
index 3f8f1d627f7c..192766656b88 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -70,7 +70,7 @@ void __drm_atomic_helper_connector_state_reset(struct
drm_connector_state *conn_
void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
struct drm_connector_state
*conn_state);
void drm_atomic_helper_connector_reset(struct drm_connector *connector);
-void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
+void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector
*connector);
void
__drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector,
struct drm_connector_state *state);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 248206bbd975..23112f0c11cf 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -692,7 +692,7 @@ struct drm_connector_tv_margins {
/**
* struct drm_tv_connector_state - TV connector related states
- * @subconnector: selected subconnector
+ * @select_subconnector: selected subconnector
* @margins: TV margins
* @mode: TV mode
* @brightn
[Intel-gfx] ✓ Fi.CI.BAT: success for Add PXP firmware respose on ARB failure
== Series Details ==
Series: Add PXP firmware respose on ARB failure
URL : https://patchwork.freedesktop.org/series/108935/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12171 -> Patchwork_108935v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/index.html
Participating hosts (44 -> 43)
--
Missing(1): fi-bdw-samus
Known issues
Here are the changes found in Patchwork_108935v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#4785])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][3] ([i915#4817])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][4] ([fdo#109295] / [i915#3301])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#4312] /
[i915#5594])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-tgl-mst}: [DMESG-WARN][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][8] ([i915#2867]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][10] ([i915#6816]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [INCOMPLETE][12] ([i915#2940]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-mst}: [DMESG-FAIL][14] ([i915#3987]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][16] ([i915#6298]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.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#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#2940]: https://gitlab.freedesktop.org/drm/intel/issues/2940
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
[i915#6816]: https://gitlab.freedesktop.org/drm/in
Re: [Intel-gfx] [PATCH v2 04/33] drm/connector: Rename subconnector state variable
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
There is two TV subconnector related properties registered by
drm_mode_create_tv_properties(): subconnector and select subconnector.
While the select subconnector property is stored in the kernel by the
drm_tv_connector_state structure, the subconnector property isn't stored
anywhere.
Worse, the select subconnector property is stored in a field called
subconnector, creating some ambiguity about which property content we're
accessing.
Let's rename that field to one called select_subconnector to make it move
obvious what it's about.
Is this the place where that extra chuck in patch 3 belong to?
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
Acked-by: Thomas Zimmermann
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 79730fa1dd8e..c74c78a28171 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -687,7 +687,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*/
return -EINVAL;
} else if (property == config->tv_select_subconnector_property) {
- state->tv.subconnector = val;
+ state->tv.select_subconnector = val;
} else if (property == config->tv_left_margin_property) {
state->tv.margins.left = val;
} else if (property == config->tv_right_margin_property) {
@@ -795,7 +795,7 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
else
*val = connector->dpms;
} else if (property == config->tv_select_subconnector_property) {
- *val = state->tv.subconnector;
+ *val = state->tv.select_subconnector;
} else if (property == config->tv_left_margin_property) {
*val = state->tv.margins.left;
} else if (property == config->tv_right_margin_property) {
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 23112f0c11cf..60b5662dec7c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -703,7 +703,7 @@ struct drm_connector_tv_margins {
* @hue: hue in percent
*/
struct drm_tv_connector_state {
- enum drm_mode_subconnector subconnector;
+ enum drm_mode_subconnector select_subconnector;
struct drm_connector_tv_margins margins;
unsigned int mode;
unsigned int brightness;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2 06/33] drm/connector: Rename legacy TV property
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away from it.
Signed-off-by: Maxime Ripard
It's not wrong, but 'legacy' is already overloaded with meaning. If you
can, maybe name it 'driver_tv_mode_property' or
'custom_tv_mode_property' instead.
Acked-by: Thomas Zimmermann
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c06d0639d552..7f2b9a07fbdf 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -698,8 +698,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->tv.margins.top = val;
} else if (property == config->tv_bottom_margin_property) {
state->tv.margins.bottom = val;
- } else if (property == config->tv_mode_property) {
- state->tv.mode = val;
+ } else if (property == config->legacy_tv_mode_property) {
+ state->tv.legacy_mode = val;
} else if (property == config->tv_brightness_property) {
state->tv.brightness = val;
} else if (property == config->tv_contrast_property) {
@@ -808,8 +808,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->tv.margins.top;
} else if (property == config->tv_bottom_margin_property) {
*val = state->tv.margins.bottom;
- } else if (property == config->tv_mode_property) {
- *val = state->tv.mode;
+ } else if (property == config->legacy_tv_mode_property) {
+ *val = state->tv.legacy_mode;
} else if (property == config->tv_brightness_property) {
*val = state->tv.brightness;
} else if (property == config->tv_contrast_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..ede6025638d7 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1686,14 +1686,14 @@ int drm_mode_create_tv_properties(struct drm_device
*dev,
if (drm_mode_create_tv_margin_properties(dev))
goto nomem;
- dev->mode_config.tv_mode_property =
+ dev->mode_config.legacy_tv_mode_property =
drm_property_create(dev, DRM_MODE_PROP_ENUM,
"mode", num_modes);
- if (!dev->mode_config.tv_mode_property)
+ if (!dev->mode_config.legacy_tv_mode_property)
goto nomem;
for (i = 0; i < num_modes; i++)
- drm_property_add_enum(dev->mode_config.tv_mode_property,
+ drm_property_add_enum(dev->mode_config.legacy_tv_mode_property,
i, modes[i]);
dev->mode_config.tv_brightness_property =
diff --git a/drivers/gpu/drm/gud/gud_connector.c
b/drivers/gpu/drm/gud/gud_connector.c
index fa636206f232..86e992b2108b 100644
--- a/drivers/gpu/drm/gud/gud_connector.c
+++ b/drivers/gpu/drm/gud/gud_connector.c
@@ -303,7 +303,7 @@ static int gud_connector_atomic_check(struct drm_connector
*connector,
old_state->tv.margins.right != new_state->tv.margins.right ||
old_state->tv.margins.top != new_state->tv.margins.top ||
old_state->tv.margins.bottom != new_state->tv.margins.bottom ||
- old_state->tv.mode != new_state->tv.mode ||
+ old_state->tv.legacy_mode != new_state->tv.legacy_mode ||
old_state->tv.brightness != new_state->tv.brightness ||
old_state->tv.contrast != new_state->tv.contrast ||
old_state->tv.flicker_reduction != new_state->tv.flicker_reduction
||
@@ -424,7 +424,7 @@ gud_connector_property_lookup(struct drm_connector
*connector, u16 prop)
case GUD_PROPERTY_TV_BOTTOM_MARGIN:
return config->tv_bottom_margin_property;
case GUD_PROPERTY_TV_MODE:
- return config->tv_mode_property;
+ return config->legacy_tv_mode_property;
case GUD_PROPERTY_TV_BRIGHTNESS:
return config->tv_brightness_property;
case GUD_PROPERTY_TV_CONTRAST:
@@ -454,7 +454,7 @@ static unsigned int *gud_connector_tv_state_val(u16 prop,
struct drm_tv_connecto
case GUD_PROPERTY_TV_BOTTOM_MARGIN:
return &state->margins.bottom;
case GUD_PROPERTY_TV_MODE:
- return &state->mode;
+ return &state->legacy_mode;
case GUD_PROPERTY_TV_BRIGHTNESS:
return &state->brightness;
case GUD_PROPERTY_TV_CONTRAST:
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index b91e48d2190d..d29b63fd6178 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gp
Re: [Intel-gfx] [PATCH v2] drm/i915: Move hotplug inversion logic into separate helper
On Thu, 22 Sep 2022, Gustavo Sousa wrote:
> Use *_hpd_invert() helpers whenever possible to isolate logic specific
> to hotplug inversion from common HPD setup logic to improve readability
> and maintainability of the source code.
>
> While we only define dg1_hpd_invert() here, future platforms are likely
> to have different hotplug inversion needs, thus it makes sense grouping
> different implementations under a common suffix.
>
> v2: Fix coding style and prefer to use small *_hdp_invert() helpers
> instead of a generic one.
>
> CC: Jani Nikula
> CC: Lucas De Marchi
> Signed-off-by: Gustavo Sousa
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_irq.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index de06f293e173..87cb05b3b6ce 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3411,17 +3411,18 @@ static u32 gen11_hotplug_enables(struct
> drm_i915_private *i915,
> }
> }
>
> +static void dg1_hpd_invert(struct drm_i915_private *i915)
> +{
> + u32 val = (INVERT_DDIA_HPD |
> +INVERT_DDIB_HPD |
> +INVERT_DDIC_HPD |
> +INVERT_DDID_HPD);
> + intel_uncore_rmw(&i915->uncore, SOUTH_CHICKEN1, 0, val);
> +}
> +
> static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> - u32 val;
> -
> - val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
> - val |= (INVERT_DDIA_HPD |
> - INVERT_DDIB_HPD |
> - INVERT_DDIC_HPD |
> - INVERT_DDID_HPD);
> - intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
> -
> + dg1_hpd_invert(dev_priv);
> icp_hpd_irq_setup(dev_priv);
> }
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH v11 0/9] Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
This patch series fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation, etc. We need to check that we avoid integer overflows when looking up a page, and so fix all the instances where we have mistakenly used a plain integer instead of a more suitable long. And there is an impedance mismatch between the scatterlist API using unsigned int and our memory/page accounting in unsigned long. That is we may try to create a scatterlist for a large object that overflows returning a small table into which we try to fit very many pages. As the object size is under the control of userspace, we have to be prudent and catch the conversion errors. To catch the implicit truncation as we switch from unsigned long into the scatterlist's unsigned int, we use improved overflows_type check and report E2BIG prior to the operation. This is already used in our create ioctls to indicate if the uABI request is simply too large for the backing store. And ttm place also has the same problem with scatterlist creation, and we fix the integer truncation problem with the way approached by scatterlist creation. And It corrects the error code to return -E2BIG when creating gem objects using ttm or shmem, if the size is too large in each case. In order to provide a common macro, it moves and adds a few utility macros into overflow/compiler_types header. It introduces assert_same_type() assert_same_typable() macros to catch type mismatch while compiling. The existing typecheck() macro outputs build warnings, but the newly added assert_same_type() macro uses the static_assert macro (which uses _Static_assert keyword and it introduced in C11) to generate a build break when the types are different and can be used to detect explicit build errors. Unlike the assert_same_type() macro, assert_same_typable() macro allows a constant value as the second argument. Since static_assert is used at compile time and it requires constant-expression as an argument [2][3], overflows_type_ret_const_expr() is newly added. the overflows_type() has the same behavior, but the macro uses __builtin_add_overflow() internally, and __builtin_add_overflows returns a bool type [4], so it is difficult to use as an argument of _Static_assert. The assert_same_type and assert_same_typable macros have been added to compiler_types.h, but the overflows_type_ret_const_expr macro has been added to overflow.h So, overflow.h has to be included to use assert_same_typable which internally uses overflows_type_ret_const_expr. And it adds unit tests for overflows_type, overflows_type_ret_const_expr, assert_same_type and assert_same_typable. The overflows_type has been added as well to compare whether the overflows_type_ret_const_expr unit test has the same as the result. And it also introduces check_assign() and check_assign_user_ptr() macros to perform an assigning source value into the destination pointer along with an overflow check. In order to implemente check_assign(), overflows_type() on top of updated check_add_overflow() macro, this series include the patch which came from Kees [1] (this patch is under reviewing from other patch mail). [1] https://lore.kernel.org/all/202208311040.C6CA8253@keescook/ [2] https://en.cppreference.com/w/c/language/_Static_assert [3] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions [4] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html 6.56 Built-in Functions to Perform Arithmetic with Overflow Checking Built-in Function: bool __builtin_add_overflow (type1 a, type2 b, type3 *res) v11: Update macro description (Andi) Change _Static_assert to static_assert (Rasmus) Rename assert_type to assert_same_type and assert_typable to assert_same_typable (Rasmus) Update assert_same_typable macro to handle an overflow check on the target type when a constant value is used. (Kees) Add overflows_type_ret_const_expr which returns constant-expression value (G.G) Add is_unsigned_type (G.G) Add unit tests for overflows_type, overflows_type_ret_const_expr, assert_same_type and assert_same_typable. (Kees) Fix incorrect type assignment between different address spaces caused by the wrong use of __user macro. (kernel test robot) v10: Add check_assign_user_ptr() macro and drop overflows_ptr() macro(Kees) Use assert_typable instead of exactly_pgoff_t() macro (Kees) Remove a redundant type checking for a pointer. (Andrzej) Add patch "compiler_types.h: Add assert_type to catch type mis-match while compiling" and drop patch "util_macros: Add exact_type macro to catch type mis-match while compiling" from patch series (G.G.) (adding of assert_type(t1, t2) and assert_typable(t, n) were suggested by Kees v9's comments) v9: Fix overflows_type() to use __builtin_add_overflow() instead of __builtin_add_overflow_p() (Andrzej) Fix overflows
[Intel-gfx] [PATCH v11 2/9] overflow: Move and add few utility macros into overflow
Moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source value into destination pointer along with an
overflow check. overflow_type macro has been improved to handle the
different data types between source and destination by check_add_overflow
macro. It also adds check_assign_user_ptr macro which performs an assigning
source value into destination pointer type variable along with an overflow
check. If an explicit overflow check is required while assigning,
check_assign_user_ptr() can be used to assign integers into pointers along
with an overflow check.
v3: Add is_type_unsigned() macro (Mauro)
Modify overflows_type() macro to consider signed data types (Mauro)
Fix the problem that safe_conversion() macro always returns true
v4: Fix kernel-doc markups
v6: Move macro addition location so that it can be used by other than drm
subsystem (Jani, Mauro, Andi)
Change is_type_unsigned to is_unsigned_type to have the same name form
as is_signed_type macro
v8: Add check_assign() and remove safe_conversion() (Kees)
Fix overflows_type() to use gcc's built-in overflow function (Andrzej)
Add overflows_ptr() to allow overflow checking when assigning a value
into a pointer variable (G.G.)
v9: Fix overflows_type() to use __builtin_add_overflow() instead of
__builtin_add_overflow_p() (Andrzej)
Fix overflows_ptr() to use overflows_type() with the unsigned long type
(Andrzej)
v10: Remove a redundant type checking for a pointer. (Andrzej)
Use updated check_add_overflow macro instead of __builtin_add_overflow
(G.G)
Add check_assign_user_ptr() macro and drop overflows_ptr() macro(Kees)
v11: Fix incorrect type assignment between different address spaces caused
by the wrong use of __user macro. (kernel test robot)
Update macro description (G.G)
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Mauro Carvalho Chehab
Cc: Kees Cook
Reviewed-by: Mauro Carvalho Chehab (v5)
Reviewed-by: Andrzej Hajda (v9)
Acked-by: Kees Cook
Reported-by: kernel test robot
---
drivers/gpu/drm/i915/i915_user_extensions.c | 6 +-
drivers/gpu/drm/i915/i915_utils.h | 5 +-
include/linux/overflow.h| 64 +
3 files changed, 68 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_user_extensions.c
b/drivers/gpu/drm/i915/i915_user_extensions.c
index c822d0aafd2d..80ec8390b0d8 100644
--- a/drivers/gpu/drm/i915/i915_user_extensions.c
+++ b/drivers/gpu/drm/i915/i915_user_extensions.c
@@ -50,11 +50,11 @@ int i915_user_extensions(struct i915_user_extension __user
*ext,
if (err)
return err;
- if (get_user(next, &ext->next_extension) ||
- overflows_type(next, ext))
+ if (get_user(next, &ext->next_extension))
return -EFAULT;
- ext = u64_to_user_ptr(next);
+ if (check_assign_user_ptr(next, ext))
+ return -EFAULT;
}
return 0;
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 6c14d13364bf..efd3d69b78f7 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_X86
#include
@@ -111,10 +112,6 @@ bool i915_error_injected(void);
#define range_overflows_end_t(type, start, size, max) \
range_overflows_end((type)(start), (type)(size), (type)(max))
-/* Note we don't consider signbits :| */
-#define overflows_type(x, T) \
- (sizeof(x) > sizeof(T) && (x) >> BITS_PER_TYPE(T))
-
#define ptr_mask_bits(ptr, n) ({ \
unsigned long __v = (unsigned long)(ptr); \
(typeof(ptr))(__v & -BIT(n)); \
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 19dfdd74835e..0eca3d8281b2 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
/*
* We need to compute the minimum and maximum values representable in a given
@@ -127,6 +128,69 @@ static inline bool __must_check __must_check_overflow(bool
overflow)
(*_d >> _to_shift) != _a); \
}))
+/**
+ * check_assign - perform an assigning source value into destination pointer
+ *along with an overflow check.
+ *
+ * @value: source value
+ * @ptr: Destination pointer address
+ *
+ * Returns:
+ * If the value would overflow the destination, it returns true. If not return
+ * false. When overflow does not occur, the assigning into dest
[Intel-gfx] [PATCH v11 1/9] overflow: Allow mixed type arguments
From: Kees Cook
When the check_[op]_overflow() helpers were introduced, all arguments were
required to be the same type to make the fallback macros simpler. However,
now that the fallback macros have been removed[1], it is fine to allow
mixed types, which makes using the helpers much more useful, as they
can be used to test for type-based overflows (e.g. adding two large ints
but storing into a u8), as would be handy in the drm core[2].
Remove the restriction, and add additional self-tests that exercise some
of the mixed-type overflow cases, and double-check for accidental macro
side-effects.
[1] https://git.kernel.org/linus/4eb6bd55cfb22ffc20652732340c4962f3ac9a91
[2]
https://lore.kernel.org/lkml/20220824084514.2261614-2-gwan-gyeong@intel.com
Cc: Rasmus Villemoes
Cc: Andrzej Hajda
Cc: "Gustavo A. R. Silva"
Cc: Nick Desaulniers
Cc: linux-harden...@vger.kernel.org
Signed-off-by: Kees Cook
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Andrzej Hajda
---
include/linux/overflow.h | 72
lib/overflow_kunit.c | 101 ---
2 files changed, 113 insertions(+), 60 deletions(-)
diff --git a/include/linux/overflow.h b/include/linux/overflow.h
index 0eb3b192f07a..19dfdd74835e 100644
--- a/include/linux/overflow.h
+++ b/include/linux/overflow.h
@@ -51,40 +51,50 @@ static inline bool __must_check __must_check_overflow(bool
overflow)
return unlikely(overflow);
}
-/*
- * For simplicity and code hygiene, the fallback code below insists on
- * a, b and *d having the same type (similar to the min() and max()
- * macros), whereas gcc's type-generic overflow checkers accept
- * different types. Hence we don't just make check_add_overflow an
- * alias for __builtin_add_overflow, but add type checks similar to
- * below.
+/** check_add_overflow() - Calculate addition with overflow checking
+ *
+ * @a: first addend
+ * @b: second addend
+ * @d: pointer to store sum
+ *
+ * Returns 0 on success.
+ *
+ * *@d holds the results of the attempted addition, but is not considered
+ * "safe for use" on a non-zero return value, which indicates that the
+ * sum has overflowed or been truncated.
*/
-#define check_add_overflow(a, b, d) __must_check_overflow(({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- typeof(d) __d = (d);\
- (void) (&__a == &__b); \
- (void) (&__a == __d); \
- __builtin_add_overflow(__a, __b, __d); \
-}))
+#define check_add_overflow(a, b, d)\
+ __must_check_overflow(__builtin_add_overflow(a, b, d))
-#define check_sub_overflow(a, b, d) __must_check_overflow(({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- typeof(d) __d = (d);\
- (void) (&__a == &__b); \
- (void) (&__a == __d); \
- __builtin_sub_overflow(__a, __b, __d); \
-}))
+/** check_sub_overflow() - Calculate subtraction with overflow checking
+ *
+ * @a: minuend; value to subtract from
+ * @b: subtrahend; value to subtract from @a
+ * @d: pointer to store difference
+ *
+ * Returns 0 on success.
+ *
+ * *@d holds the results of the attempted subtraction, but is not considered
+ * "safe for use" on a non-zero return value, which indicates that the
+ * difference has underflowed or been truncated.
+ */
+#define check_sub_overflow(a, b, d)\
+ __must_check_overflow(__builtin_sub_overflow(a, b, d))
-#define check_mul_overflow(a, b, d) __must_check_overflow(({ \
- typeof(a) __a = (a);\
- typeof(b) __b = (b);\
- typeof(d) __d = (d);\
- (void) (&__a == &__b); \
- (void) (&__a == __d); \
- __builtin_mul_overflow(__a, __b, __d); \
-}))
+/** check_mul_overflow() - Calculate multiplication with overflow checking
+ *
+ * @a: first factor
+ * @b: second factor
+ * @d: pointer to store product
+ *
+ * Returns 0 on success.
+ *
+ * *@d holds the results of the attempted multiplication, but is not
+ * considered "safe for use" on a non-zero return value, which indicates
+ * that the product has overflowed or been truncated.
+ */
+#define check_mul_overflow(a, b, d)\
+ __must_check_overflow(__builtin_mul_overflow(a, b, d))
/** check_shl_overflow() - Calculate a left-shifted value and check overflow
*
diff --git a/lib/overflow_kunit.c b/lib/overflow_kunit.c
index 7e3e43679b73..0d98c9bc75da 100644
--- a/lib/overflow_kunit.c
+++ b/lib/overflow_kunit.c
@@ -16,12 +16,15 @@
#include
#include
-#define DEFINE_TEST_ARRAY(t) \
- static const struct test_ ## t {\
- t a, b; \
- t sum, diff, prod; \
- bool s_of, d_of, p_of; \
- }
[Intel-gfx] [PATCH v11 3/9] compiler_types.h: Add assert_same_type to catch type mis-match while compiling
Adds assert_same_type and assert_same_typable macros to catch type
mis-match while compiling. The existing typecheck() macro outputs build
warnings, but the newly added assert_same_type() macro uses the
static_assert macro (which uses _Static_assert keyword and it introduced
in C11) to generate a build break when the types are different and can be
used to detect explicit build errors. Unlike the assert_same_type() macro,
assert_same_typable() macro allows a constant value as the second argument.
Since static_assert is used at compile time and it requires
constant-expression as an argument [1][2], overflows_type_ret_const_expr()
is newly added. There is overflows_type() that has the same behavior, but
the macro uses __builtin_add_overflow() internally, and
__builtin_add_overflows returns a bool type [3], so it is difficult to use
as an argument of _Static_assert. The assert_same_type and
assert_same_typable macros have been added to compiler_types.h, but the
overflows_type_ret_const_expr macro has been added to overflow.h
So, overflow.h has to be included to use assert_same_typable which
internally uses overflows_type_ret_const_expr.
And it adds unit tests for overflows_type, overflows_type_ret_const_expr,
assert_same_type and assert_same_typable. The overflows_type has been added
as well to compare whether the overflows_type_ret_const_expr unit test has
the same as the result.
[1] https://en.cppreference.com/w/c/language/_Static_assert
[2] C11 standard (ISO/IEC 9899:2011): 6.7.10 Static assertions
[3] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
6.56 Built-in Functions to Perform Arithmetic with Overflow Checking
Built-in Function: bool __builtin_add_overflow (type1 a, type2 b,
type3 *res)
v11: Update macro description (Andi)
Change _Static_assert to static_assert (Rasmus)
Rename assert_type to assert_same_type and assert_typable to
assert_same_typable (Rasmus)
Update assert_same_typable macro to handle an overflow check on the
target type when a constant value is used. (Kees)
Add overflows_type_ret_const_expr which returns constant-expression
value (G.G)
Add is_unsigned_type (G.G)
Add unit tests for overflows_type, overflows_type_ret_const_expr,
assert_same_type and assert_same_typable. (Kees)
Suggested-by: Kees Cook
Signed-off-by: Gwan-gyeong Mun
Cc: Thomas Hellström
Cc: Matthew Auld
Cc: Nirmoy Das
Cc: Jani Nikula
Cc: Andi Shyti
Cc: Mauro Carvalho Chehab
Cc: Andrzej Hajda
Cc: Kees Cook
Cc: Rasmus Villemoes
---
include/linux/compiler.h | 1 +
include/linux/compiler_types.h | 43 +
include/linux/overflow.h | 27
lib/overflow_kunit.c | 283 +
4 files changed, 354 insertions(+)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 7713d7bcdaea..c631107e93b1 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -244,6 +244,7 @@ static inline void *offset_to_ptr(const int *off)
* bool and also pointer types.
*/
#define is_signed_type(type) (((type)(-1)) < (__force type)1)
+#define is_unsigned_type(type) (!is_signed_type(type))
/*
* This is needed in functions which generate the stack canary, see
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 4f2a819fd60a..e6f5d68e5eba 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -294,6 +294,49 @@ struct ftrace_likely_data {
/* Are two types/vars the same type (ignoring qualifiers)? */
#define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
+/**
+ * assert_same_type - abort compilation if the first argument's data type and
+ *the second argument's data type are not the same
+ * @t1: data type or variable
+ * @t2: data type or variable
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). It determines whether the first argument's data type and the second
+ * argument's data type are the same while compiling, and it aborts compilation
+ * if the two types are not the same.
+ * See also assert_same_typable().
+ */
+#define assert_same_type(t1, t2) static_assert(__same_type(t1, t2))
+
+/**
+ * assert_same_typable - abort compilation if the first argument's data type
and
+ * the second argument's data type are not the same
+ * @t: data type or variable
+ * @n: data type or variable or constant value
+ *
+ * The first and second arguments can be data types or variables or mixed (the
+ * first argument is the data type and the second argument is variable or vice
+ * versa). Unlike the assert_same_type() macro, this macro allows a constant
+ * value as the second argument. And if the second argument is a constant
+ * value, it checks overflows between the first argument
[Intel-gfx] [PATCH v11 5/9] drm/i915: Check for integer truncation on scatterlist creation
From: Chris Wilson
There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the object size
is under control of userspace, we have to be prudent and catch the
conversion errors.
To catch the implicit truncation as we switch from unsigned long into the
scatterlist's unsigned int, we use overflows_type check and report
E2BIG prior to the operation. This is already used in our create ioctls to
indicate if the uABI request is simply too large for the backing store.
Failing that type check, we have a second check at sg_alloc_table time
to make sure the values we are passing into the scatterlist API are not
truncated.
It uses pgoff_t for locals that are dealing with page indices, in this
case, the page count is the limit of the page index.
And it uses safe_conversion() macro which performs a type conversion (cast)
of an integer value into a new variable, checking that the destination is
large enough to hold the source value.
v2: Move added i915_utils's macro into drm_util header (Jani N)
v5: Fix macros to be enclosed in parentheses for complex values
Fix too long line warning
v8: Replace safe_conversion() with check_assign() (Kees)
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Brian Welty
Cc: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Nirmoy Das
Reviewed-by: Mauro Carvalho Chehab
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 6 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 ---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 4
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 5 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 5 -
drivers/gpu/drm/i915/gvt/dmabuf.c| 9 +
drivers/gpu/drm/i915/i915_scatterlist.h | 11 +++
8 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15f..53fa27e1c950 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -37,10 +37,13 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
struct sg_table *st;
struct scatterlist *sg;
unsigned int sg_page_sizes;
- unsigned int npages;
+ pgoff_t npages; /* restricted by sg_alloc_table */
int max_order;
gfp_t gfp;
+ if (check_assign(obj->base.size >> PAGE_SHIFT, &npages))
+ return -E2BIG;
+
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
if (is_swiotlb_active(obj->base.dev->dev)) {
@@ -67,7 +70,6 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
if (!st)
return -ENOMEM;
- npages = obj->base.size / PAGE_SIZE;
if (sg_alloc_table(st, npages, GFP_KERNEL)) {
kfree(st);
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index f2c4de31d563..b1f89b1cc0b2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -26,9 +26,6 @@ enum intel_region_id;
* this and catch if we ever need to fix it. In the meantime, if you do
* spot such a local variable, please consider fixing!
*
- * Aside from our own locals (for which we have no excuse!):
- * - sg_table embeds unsigned int for nents
- *
* We can check for invalidly typed locals with typecheck(), see for example
* i915_gem_object_get_sg().
*/
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
index 0d0e46dae559..88ba7266a3a5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c
@@ -28,6 +28,10 @@ static int i915_gem_object_get_pages_phys(struct
drm_i915_gem_object *obj)
void *dst;
int i;
+ /* Contiguous chunk, with a single scatterlist element */
+ if (overflows_type(obj->base.size, sg->length))
+ return -E2BIG;
+
if (GEM_WARN_ON(i915_gem_object_needs_bit17_swizzle(obj)))
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index f42ca1179f37..339b0a9cf2d0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -193,13 +193,16 @@ static int shmem_get_pages(struct drm_i915_gem_object
*obj)
struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct intel_memory_region *mem = obj->mm.region;
struct address_space *mapping = obj->base.filp->f_mapping;
- const unsigned long p
[Intel-gfx] [PATCH v11 6/9] drm/i915: Check for integer truncation on the configuration of ttm place
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we switch from unsigned long to
unsigned, we use overflows_type check and report E2BIG or overflow_type
prior to the operation.
v3: Not to change execution inside a macro. (Mauro)
Add safe_conversion_gem_bug_on() macro and remove temporal
SAFE_CONVERSION() macro.
v4: Fix unhandled GEM_BUG_ON() macro call from safe_conversion_gem_bug_on()
v6: Fix to follow general use case for GEM_BUG_ON(). (Jani)
v7: Fix to use WARN_ON() macro where GEM_BUG_ON() macro was used. (Jani)
v8: Replace safe_conversion() with check_assign() (Kees)
Signed-off-by: Gwan-gyeong Mun
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Thomas Hellström
Cc: Jani Nikula
Reviewed-by: Nirmoy Das (v2)
Reviewed-by: Mauro Carvalho Chehab (v3)
Reported-by: kernel test robot
Reviewed-by: Andrzej Hajda (v5)
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 6 +++---
drivers/gpu/drm/i915/intel_region_ttm.c | 17 ++---
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index bf99d1f02bd9..e6bbc0f8b7e6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -140,14 +140,14 @@ i915_ttm_place_from_region(const struct
intel_memory_region *mr,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place->flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
- place->fpfn = offset >> PAGE_SHIFT;
- place->lpfn = place->fpfn + (size >> PAGE_SHIFT);
+ WARN_ON(check_assign(offset >> PAGE_SHIFT, &place->fpfn));
+ WARN_ON(check_assign(place->fpfn + (size >> PAGE_SHIFT),
&place->lpfn));
} else if (mr->io_size && mr->io_size < mr->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place->flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place->fpfn = 0;
- place->lpfn = mr->io_size >> PAGE_SHIFT;
+ WARN_ON(check_assign(mr->io_size >> PAGE_SHIFT,
&place->lpfn));
}
}
}
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..37a964b20b36 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -209,14 +209,23 @@ intel_region_ttm_resource_alloc(struct
intel_memory_region *mem,
if (flags & I915_BO_ALLOC_CONTIGUOUS)
place.flags |= TTM_PL_FLAG_CONTIGUOUS;
if (offset != I915_BO_INVALID_OFFSET) {
- place.fpfn = offset >> PAGE_SHIFT;
- place.lpfn = place.fpfn + (size >> PAGE_SHIFT);
+ if (WARN_ON(check_assign(offset >> PAGE_SHIFT, &place.fpfn))) {
+ ret = -E2BIG;
+ goto out;
+ }
+ if (WARN_ON(check_assign(place.fpfn + (size >> PAGE_SHIFT),
&place.lpfn))) {
+ ret = -E2BIG;
+ goto out;
+ }
} else if (mem->io_size && mem->io_size < mem->total) {
if (flags & I915_BO_ALLOC_GPU_ONLY) {
place.flags |= TTM_PL_FLAG_TOPDOWN;
} else {
place.fpfn = 0;
- place.lpfn = mem->io_size >> PAGE_SHIFT;
+ if (WARN_ON(check_assign(mem->io_size >> PAGE_SHIFT,
&place.lpfn))) {
+ ret = -E2BIG;
+ goto out;
+ }
}
}
@@ -224,6 +233,8 @@ intel_region_ttm_resource_alloc(struct intel_memory_region
*mem,
mock_bo.bdev = &mem->i915->bdev;
ret = man->func->alloc(man, &mock_bo, &place, &res);
+
+out:
if (ret == -ENOSPC)
ret = -ENXIO;
if (!ret)
--
2.37.1
[Intel-gfx] [PATCH v11 4/9] drm/i915/gem: Typecheck page lookups
From: Chris Wilson
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
And it also uses pgoff_t as our page lookups must remain compatible with
the page cache, pgoff_t is currently exactly unsigned long.
v2: Move added i915_utils's macro into drm_util header (Jani N)
v3: Make not use the same macro name on a function. (Mauro)
For kernel-doc, macros and functions are handled in the same namespace,
the same macro name on a function prevents ever adding documentation
for it.
v4: Add kernel-doc markups to the kAPI functions and macros (Mauoro)
v5: Fix an alignment to match open parenthesis
v6: Rebase
v10: Use assert_typable instead of exactly_pgoff_t() macro. (Kees)
v11: Change the use of assert_typable to assert_same_typable (G.G)
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Thomas Hellström
Cc: Kees Cook
Reviewed-by: Nirmoy Das (v2)
Reviewed-by: Mauro Carvalho Chehab (v3)
Reviewed-by: Andrzej Hajda (v5)
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 7 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h| 293 --
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 27 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 12 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 8 +-
.../drm/i915/gem/selftests/i915_gem_object.c | 8 +-
drivers/gpu/drm/i915/i915_gem.c | 18 +-
drivers/gpu/drm/i915/i915_utils.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 8 +-
10 files changed, 323 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 7ff9c7877bec..29ed0ec05d12 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -413,10 +413,11 @@ void __i915_gem_object_invalidate_frontbuffer(struct
drm_i915_gem_object *obj,
static void
i915_gem_object_read_from_page_kmap(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
+ pgoff_t idx = offset >> PAGE_SHIFT;
void *src_map;
void *src_ptr;
- src_map = kmap_atomic(i915_gem_object_get_page(obj, offset >>
PAGE_SHIFT));
+ src_map = kmap_atomic(i915_gem_object_get_page(obj, idx));
src_ptr = src_map + offset_in_page(offset);
if (!(obj->cache_coherent & I915_BO_CACHE_COHERENT_FOR_READ))
@@ -429,9 +430,10 @@ i915_gem_object_read_from_page_kmap(struct
drm_i915_gem_object *obj, u64 offset,
static void
i915_gem_object_read_from_page_iomap(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
+ pgoff_t idx = offset >> PAGE_SHIFT;
+ dma_addr_t dma = i915_gem_object_get_dma_address(obj, idx);
void __iomem *src_map;
void __iomem *src_ptr;
- dma_addr_t dma = i915_gem_object_get_dma_address(obj, offset >>
PAGE_SHIFT);
src_map = io_mapping_map_wc(&obj->mm.region->iomap,
dma - obj->mm.region->region.start,
@@ -460,6 +462,7 @@ i915_gem_object_read_from_page_iomap(struct
drm_i915_gem_object *obj, u64 offset
*/
int i915_gem_object_read_from_page(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size)
{
+ GEM_BUG_ON(overflows_type(offset >> PAGE_SHIFT, pgoff_t));
GEM_BUG_ON(offset >= obj->base.size);
GEM_BUG_ON(offset_in_page(offset) > PAGE_SIZE - size);
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..f2c4de31d563 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -27,8 +27,10 @@ enum intel_region_id;
* spot such a local variable, please consider fixing!
*
* Aside from our own locals (for which we have no excuse!):
- * - sg_table embeds unsigned int for num_pages
- * - get_user_pages*() mixed ints with longs
+ * - sg_table embeds unsigned int for nents
+ *
+ * We can check for invalidly typed locals with typecheck(), see for example
+ * i915_gem_object_get_sg().
*/
#define GEM_CHECK_SIZE_OVERFLOW(sz) \
GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
@@ -363,44 +365,289 @@ i915_gem_object_get_tile_row_size(const struct
drm_i915_gem_object *obj)
int i915_gem_object_set_tiling(struct drm_i915_gem_object *obj,
unsigned int tiling, unsigned int stride);
+/**
+ * __i915_gem_object_page_iter_get_sg - helper to find the target scatterlist
+ * pointer and the target page position using pgoff_t n input argument and
+ * i915_gem_object_page_iter
+ * @obj: i915 GEM buffer object
+ * @iter: i915 GEM buffer object page
[Intel-gfx] [PATCH v11 8/9] drm/i915: Use error code as -E2BIG when the size of gem ttm object is too large
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big to add vma. The direct function that returns -ENOSPC is drm_mm_insert_node_in_range(). To handle the same error as other code returning -E2BIG when the size is too large, it converts return value to -E2BIG. Signed-off-by: Gwan-gyeong Mun Cc: Chris Wilson Cc: Matthew Auld Cc: Thomas Hellström Reviewed-by: Nirmoy Das Reviewed-by: Mauro Carvalho Chehab Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c index e6bbc0f8b7e6..62d3924a6377 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c @@ -1242,6 +1242,17 @@ int __i915_gem_ttm_object_init(struct intel_memory_region *mem, ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), bo_type, &i915_sys_placement, page_size >> PAGE_SHIFT, &ctx, NULL, NULL, i915_ttm_bo_destroy); + + /* +* XXX: The ttm_bo_init_reserved() functions returns -ENOSPC if the size +* is too big to add vma. The direct function that returns -ENOSPC is +* drm_mm_insert_node_in_range(). To handle the same error as other code +* that returns -E2BIG when the size is too large, it converts -ENOSPC to +* -E2BIG. +*/ + if (size >> PAGE_SHIFT > INT_MAX && ret == -ENOSPC) + ret = -E2BIG; + if (ret) return i915_ttm_err_to_gem(ret); -- 2.37.1
[Intel-gfx] [PATCH v11 9/9] drm/i915: Remove truncation warning for large objects
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warning
put in place to remind us to complete the review.
Signed-off-by: Chris Wilson
Signed-off-by: Gwan-gyeong Mun
Cc: Tvrtko Ursulin
Cc: Brian Welty
Cc: Matthew Auld
Cc: Thomas Hellström
Testcase: igt@gem_create@create-massive
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4991
Reviewed-by: Nirmoy Das
Reviewed-by: Mauro Carvalho Chehab
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index b1f89b1cc0b2..9a77fa95e771 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -20,25 +20,10 @@
enum intel_region_id;
-/*
- * XXX: There is a prevalence of the assumption that we fit the
- * object's page count inside a 32bit _signed_ variable. Let's document
- * this and catch if we ever need to fix it. In the meantime, if you do
- * spot such a local variable, please consider fixing!
- *
- * We can check for invalidly typed locals with typecheck(), see for example
- * i915_gem_object_get_sg().
- */
-#define GEM_CHECK_SIZE_OVERFLOW(sz) \
- GEM_WARN_ON((sz) >> PAGE_SHIFT > INT_MAX)
-
static inline bool i915_gem_object_size_2big(u64 size)
{
struct drm_i915_gem_object *obj;
- if (GEM_CHECK_SIZE_OVERFLOW(size))
- return true;
-
if (overflows_type(size, obj->base.size))
return true;
--
2.37.1
[Intel-gfx] [PATCH v11 7/9] drm/i915: Check if the size is too big while creating shmem file
The __shmem_file_setup() function returns -EINVAL if size is greater than MAX_LFS_FILESIZE. To handle the same error as other code that returns -E2BIG when the size is too large, it add a code that returns -E2BIG when the size is larger than the size that can be handled. v4: If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, so it checks only when BITS_PER_LONG is 64. Signed-off-by: Gwan-gyeong Mun Cc: Chris Wilson Cc: Matthew Auld Cc: Thomas Hellström Reviewed-by: Nirmoy Das Reviewed-by: Mauro Carvalho Chehab Reported-by: kernel test robot Reviewed-by: Andrzej Hajda --- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c index 339b0a9cf2d0..ca30060e34ab 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c @@ -541,6 +541,20 @@ static int __create_shmem(struct drm_i915_private *i915, drm_gem_private_object_init(&i915->drm, obj, size); + /* XXX: The __shmem_file_setup() function returns -EINVAL if size is +* greater than MAX_LFS_FILESIZE. +* To handle the same error as other code that returns -E2BIG when +* the size is too large, we add a code that returns -E2BIG when the +* size is larger than the size that can be handled. +* If BITS_PER_LONG is 32, size > MAX_LFS_FILESIZE is always false, +* so we only needs to check when BITS_PER_LONG is 64. +* If BITS_PER_LONG is 32, E2BIG checks are processed when +* i915_gem_object_size_2big() is called before init_object() callback +* is called. +*/ + if (BITS_PER_LONG == 64 && size > MAX_LFS_FILESIZE) + return -E2BIG; + if (i915->mm.gemfs) filp = shmem_file_setup_with_mnt(i915->mm.gemfs, "i915", size, flags); -- 2.37.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove unused function parameter (rev2)
== Series Details == Series: drm/i915: Remove unused function parameter (rev2) URL : https://patchwork.freedesktop.org/series/108863/ State : success == Summary == CI Bug Log - changes from CI_DRM_12168_full -> Patchwork_108863v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108863v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#2842]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: NOTRUN -> [FAIL][3] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> [SKIP][4] ([fdo#109313]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_lmem_swapping@basic: - shard-iclb: NOTRUN -> [SKIP][5] ([i915#4613]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb8/igt@gem_lmem_swapp...@basic.html * igt@gem_pxp@create-regular-context-1: - shard-iclb: NOTRUN -> [SKIP][6] ([i915#4270]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb1/igt@gem_...@create-regular-context-1.html * igt@gem_render_copy@y-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][7] ([i915#768]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb2/igt@gem_render_c...@y-tiled-to-vebox-linear.html * igt@gem_softpin@evict-single-offset: - shard-tglb: [PASS][8] -> [FAIL][9] ([i915#4171]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-tglb8/igt@gem_soft...@evict-single-offset.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-tglb8/igt@gem_soft...@evict-single-offset.html * igt@gem_softpin@evict-snoop-interruptible: - shard-iclb: NOTRUN -> [SKIP][10] ([fdo#109312]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb2/igt@gem_soft...@evict-snoop-interruptible.html * igt@gem_spin_batch@spin-each: - shard-apl: NOTRUN -> [FAIL][11] ([i915#2898]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-apl3/igt@gem_spin_ba...@spin-each.html * igt@gem_userptr_blits@coherency-unsync: - shard-iclb: NOTRUN -> [SKIP][12] ([i915#3297]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb1/igt@gem_userptr_bl...@coherency-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-iclb: NOTRUN -> [FAIL][13] ([i915#3318]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb1/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_render_linear_blits: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#109289]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb8/igt@gen3_render_linear_blits.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#5566] / [i915#716]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk3/igt@gen9_exec_pa...@allowed-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-glk5/igt@gen9_exec_pa...@allowed-all.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#5566] / [i915#716]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-apl3/igt@gen9_exec_pa...@allowed-single.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-apl8/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@bb-start-param: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#2856]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb8/igt@gen9_exec_pa...@bb-start-param.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#588]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108863v2/shard-iclb2/igt@i915_pm...@dc3co-vpb-simulation.html * igt@i915_pm_rpm@modeset-non-lpsp: - shard-iclb: NOTRUN -> [SKIP][21] ([fdo#110892]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/P
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for iommu: Remove iova cpu hotplugging flushing
On Thursday, 22 September 2022 21:18:51 CEST Patchwork wrote: > == Series Details == > > Series: iommu: Remove iova cpu hotplugging flushing > URL : https://patchwork.freedesktop.org/series/108880/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12166_full -> Patchwork_108880v1_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_108880v1_full absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_108880v1_full, please notify your bug team to allow them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (11 -> 12) > -- > > Additional (1): shard-dg1 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in Patchwork_108880v1_full: > > ### IGT changes ### > > Possible regressions > > * igt@i915_pm_dc@dc6-psr: > - shard-skl: NOTRUN -> [CRASH][1] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v1/shard-skl9/igt@i915_pm...@dc6-psr.html > > * igt@i915_selftest@live@gt_pm: > - shard-skl: NOTRUN -> [DMESG-FAIL][2] >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v1/shard-skl4/igt@i915_selftest@live@gt_pm.html > > * igt@kms_color@ctm-0-75@pipe-b-edp-1: > - shard-skl: NOTRUN -> [FAIL][3] +5 similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v1/shard-skl9/igt@kms_color@ctm-0...@pipe-b-edp-1.html > > * igt@kms_cursor_legacy@cursor-vs-flip@varying-size: > - shard-skl: NOTRUN -> [INCOMPLETE][4] +2 similar issues >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v1/shard-skl3/igt@kms_cursor_legacy@cursor-vs-f...@varying-size.html > > * igt@perf@non-zero-reason: > - shard-skl: NOTRUN -> [TIMEOUT][5] >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108880v1/shard-skl9/igt@p...@non-zero-reason.html All those "regressions" look to me like not related, possibly old, potentially hidden before due to CI blocked on some platforms by the issue that the patch has just resolved. I've asked Bug Filing to update CI buglog filters and re- report. Thanks, Janusz
Re: [Intel-gfx] [RFC v4 13/14] drm/i915/vm_bind: Skip vma_lookup for persistent vmas
On 21/09/2022 08:09, Niranjana Vishwanathapura wrote:
vma_lookup is tied to segment of the object instead of section
Can be, but not only that. It would be more accurate to say it is based
of gtt views.
of VA space. Hence, it do not support aliasing (ie., multiple
bindings to the same section of the object).
Skip vma_lookup for persistent vmas as it supports aliasing.
What's broken without this patch? If something is, should it go
somewhere earlier in the series? If so should be mentioned in the commit
message.
Or is it just a performance optimisation to skip unused tracking? If so
should also be mentioned in the commit message.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fb_pin.c | 2 +-
.../drm/i915/display/intel_plane_initial.c| 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 4 +-
.../drm/i915/gem/i915_gem_vm_bind_object.c| 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 16 +++
.../i915/gem/selftests/i915_gem_client_blt.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 12 ++---
.../drm/i915/gem/selftests/i915_gem_migrate.c | 2 +-
.../drm/i915/gem/selftests/i915_gem_mman.c| 6 ++-
.../drm/i915/gem/selftests/igt_gem_utils.c| 2 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
drivers/gpu/drm/i915/gt/mock_engine.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 +++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
.../drm/i915/gt/selftest_ring_submission.c| 2 +-
drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 2 +-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 26 +++
drivers/gpu/drm/i915/i915_vma.h | 3 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 44 +--
drivers/gpu/drm/i915/selftests/i915_request.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 2 +-
37 files changed, 106 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fb_pin.c
b/drivers/gpu/drm/i915/display/intel_fb_pin.c
index c86e5d4ee016..5a718b247bb3 100644
--- a/drivers/gpu/drm/i915/display/intel_fb_pin.c
+++ b/drivers/gpu/drm/i915/display/intel_fb_pin.c
@@ -47,7 +47,7 @@ intel_pin_fb_obj_dpt(struct drm_framebuffer *fb,
goto err;
}
- vma = i915_vma_instance(obj, vm, view);
+ vma = i915_vma_instance(obj, vm, view, false);
Hey why are you touching all the legacy paths? >:P
if (IS_ERR(vma))
goto err;
diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index 76be796df255..7667e2faa3fb 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -136,7 +136,7 @@ initial_plane_vma(struct drm_i915_private *i915,
goto err_obj;
}
- vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
+ vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL, false);
if (IS_ERR(vma))
goto err_obj;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 363b2a788cdf..0ee43cb601b5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -876,7 +876,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
}
}
- vma = i915_vma_instance(obj, vm, NULL);
+ vma = i915_vma_instance(obj, vm, NULL, false);
if (IS_ERR(vma)) {
i915_gem_object_put(obj);
return vma;
@@ -2208,7 +2208,7 @@ shadow_batch_pin(struct i915_execbuffer *eb,
struct i915_vma *vma;
int err;
- vma = i915_vma_instance(obj, vm, NULL);
+ vma = i915_vma_instance(obj, vm, NULL, false);
if (IS_ERR(vma))
return vma;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix a potential UAF at device unload
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix a potential UAF at device
unload
URL : https://patchwork.freedesktop.org/series/108944/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12171 -> Patchwork_108944v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/index.html
Participating hosts (44 -> 42)
--
Missing(2): fi-hsw-4770 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_108944v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-bxt-dsi: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [PASS][3] -> [INCOMPLETE][4] ([i915#3303] /
[i915#4785])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@runner@aborted:
- fi-hsw-g3258: NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#4312])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- {fi-tgl-mst}: [DMESG-WARN][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][8] ([i915#2867]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][10] ([i915#6816]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}: [DMESG-WARN][12] ([i915#2867]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-mst}: [DMESG-FAIL][14] ([i915#3987]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hugepages:
- {bat-rpls-1}: [DMESG-WARN][16] ([i915#5278]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/bat-rpls-1/igt@i915_selftest@l...@hugepages.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][18] ([i915#6298]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Warnings
* igt@runner@aborted:
- fi-kbl-soraka: [FAIL][20] ([i915#6641] / [i915#6894]) -> [FAIL][21]
([i915#6641])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/fi-kbl-soraka/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/fi-kbl-soraka/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3987]: https://gitlab.freedesktop.org/drm/intel/issues/3987
[i915#4312]: https://gitlab.freedesktop.
[Intel-gfx] [PATCH v2] drm/i915: Improve debug print in vm_fault_ttm
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..55455321f652 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n", ERR_PTR(err));
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
--
2.37.3
Re: [Intel-gfx] [PATCH v2 10/33] drm/modes: Add a function to generate analog display modes
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency. Thus, we created a function that will create a display
mode from the standard, the pixel frequency and the active area.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 304004fb80aa..76ab700f56ff 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_mode_probed_add);
+enum drm_mode_analog {
+ DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
+ DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
+};
+
+/*
+ * The timings come from:
+ * -
https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
+ * -
https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
+ * -
https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
+ */
+#define NTSC_LINE_DURATION_NS 63556U
+#define NTSC_LINES_NUMBER 525
+
+#define NTSC_HBLK_DURATION_TYP_NS 10900U
+#define NTSC_HBLK_DURATION_MIN_NS (NTSC_HBLK_DURATION_TYP_NS - 200)
+#define NTSC_HBLK_DURATION_MAX_NS (NTSC_HBLK_DURATION_TYP_NS + 200)
+
+#define NTSC_HACT_DURATION_TYP_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_TYP_NS)
+#define NTSC_HACT_DURATION_MIN_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_MAX_NS)
+#define NTSC_HACT_DURATION_MAX_NS (NTSC_LINE_DURATION_NS -
NTSC_HBLK_DURATION_MIN_NS)
+
+#define NTSC_HFP_DURATION_TYP_NS 1500
+#define NTSC_HFP_DURATION_MIN_NS 1270
+#define NTSC_HFP_DURATION_MAX_NS 2220
+
+#define NTSC_HSLEN_DURATION_TYP_NS 4700
+#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
+#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
+
+#define NTSC_HBP_DURATION_TYP_NS 4700
+
+/*
+ * I couldn't find the actual tolerance for the back porch, so let's
+ * just reuse the sync length ones.
+ */
+#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
+#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
+
+#define PAL_LINE_DURATION_NS 64000U
+#define PAL_LINES_NUMBER 625
+
+#define PAL_HACT_DURATION_TYP_NS 51950U
+#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
+#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
+
+#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_TYP_NS)
+#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_MAX_NS)
+#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS -
PAL_HACT_DURATION_MIN_NS)
+
+#define PAL_HFP_DURATION_TYP_NS1650
+#define PAL_HFP_DURATION_MIN_NS(PAL_HFP_DURATION_TYP_NS - 100)
+#define PAL_HFP_DURATION_MAX_NS(PAL_HFP_DURATION_TYP_NS + 400)
+
+#define PAL_HSLEN_DURATION_TYP_NS 4700
+#define PAL_HSLEN_DURATION_MIN_NS (PAL_HSLEN_DURATION_TYP_NS - 200)
+#define PAL_HSLEN_DURATION_MAX_NS (PAL_HSLEN_DURATION_TYP_NS + 200)
+
+#define PAL_HBP_DURATION_TYP_NS5700
+#define PAL_HBP_DURATION_MIN_NS(PAL_HBP_DURATION_TYP_NS - 200)
+#define PAL_HBP_DURATION_MAX_NS(PAL_HBP_DURATION_TYP_NS + 200)
+
+struct analog_param_field {
+ unsigned int even, odd;
+};
+
+#define PARAM_FIELD(_odd, _even) \
+ { .even = _even, .odd = _odd }
+
+struct analog_param_range {
+ unsigned intmin, typ, max;
+};
+
+#define PARAM_RANGE(_min, _typ, _max) \
+ { .min = _min, .typ = _typ, .max = _max }
+
+struct analog_parameters {
+ unsigned intnum_lines;
+ unsigned intline_duration_ns;
+
+ struct analog_param_range hact_ns;
+ struct analog_param_range hfp_ns;
+ struct analog_param_range hslen_ns;
+ struct analog_param_range hbp_ns;
+ struct analog_param_range hblk_ns;
+
+ unsigned intbt601_hfp;
+
+ struct analog_param_field vfp_lines;
+ struct analog_param_field vslen_lines;
+ struct analog_param_field vbp_lines;
+};
+
+#define TV_MODE_PARAMETER(_mode, _lines, _line_dur, _hact, _hfp, _hslen, _hbp,
_hblk, _bt601_hfp, _vfp, _vslen, _vbp) \
+ [_mode] = { \
+ .num_lines = _lines,
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..d553e793e673 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
*client, int mode)
return ret;
}
EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
I strongly dislike this style of including source files in each other.
It's a recipe for all kind of build errors. Can you do something else?
As the tested function is an internal interface, maybe export a wrapper
if tests are enabled, like this:
#ifdef CONFIG_DRM_KUNIT_TEST
struct drm_display_mode *
drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
{
return drm_connector_pick_cmdline_mode(connector)
}
EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
#endif
The wrapper's declaration can be located in the kunit test file.
Best regards
Thomas
diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
b/drivers/gpu/drm/tests/drm_client_modeset_test.c
new file mode 100644
index ..46335de7bc6b
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
@@ -0,0 +1,114 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Maxime Ripard
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drm_kunit_helpers.h"
+
+struct drm_client_modeset_test_priv {
+ struct drm_device *drm;
+ struct drm_connector connector;
+};
+
+static int drm_client_modeset_connector_get_modes(struct drm_connector
*connector)
+{
+ struct drm_display_mode *mode;
+ int count;
+
+ count = drm_add_modes_noedid(connector, 1920, 1200);
+
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
drm_client_modeset_connector_helper_funcs = {
+ .get_modes = drm_client_modeset_connector_get_modes,
+};
+
+static const struct drm_connector_funcs drm_client_modeset_connector_funcs = {
+};
+
+static int drm_client_modeset_test_init(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv;
+ int ret;
+
+ priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ test->priv = priv;
+
+ priv->drm = drm_kunit_device_init("drm-client-modeset-test");
+ if (IS_ERR(priv->drm))
+ return PTR_ERR(priv->drm);
+
+ ret = drmm_connector_init(priv->drm, &priv->connector,
+ &drm_client_modeset_connector_funcs,
+ DRM_MODE_CONNECTOR_Unknown,
+ NULL);
+ if (ret)
+ return ret;
+ drm_connector_helper_add(&priv->connector,
&drm_client_modeset_connector_helper_funcs);
+
+ return 0;
+}
+
+static void drm_client_modeset_test_exit(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+
+ drm_kunit_device_exit(priv->drm);
+}
+
+static void drm_pick_cmdline_res_1920_1080_60(struct kunit *test)
+{
+ struct drm_client_modeset_test_priv *priv = test->priv;
+ struct drm_device *drm = priv->drm;
+ struct drm_connector *connector = &priv->connector;
+ struct drm_cmdline_mode *cmdline_mode = &connector->cmdline_mode;
+ struct drm_display_mode *expected_mode, *mode;
+ const char *cmdline = "1920x1080@60";
+ int ret;
+
+ expected_mode = drm_mode_find_dmt(priv->drm, 1920, 1080, 60, false);
+ KUNIT_ASSERT_PTR_NE(test, expected_mode, NULL);
+
+ KUNIT_ASSERT_TRUE(test,
+ drm_mode_parse_command_line_for_connector(cmdline,
+ connector,
+
cmdline_mode));
+
+ mutex_lock(&drm->mode_config.mutex);
+ ret = drm_helper_probe_single_connector_modes(connector, 1920, 1080);
+ mutex_unlock(&drm->mode_config.mutex);
+ KUNIT_ASSERT_GT(test, ret, 0);
+
+ mode = drm_connector_pick_cmdline_mode(connector);
+ KUNIT_ASSERT_PTR_NE(test, mode, NULL);
+
+ KUNIT_EXPECT_TRUE(test, drm_mode_equal(expected_mode, mode));
+}
+
+static struct kunit_case drm_pick_cmdline_tests[] = {
+ KUNIT_CASE(drm_pick_cmdline_res_1920_1080_60),
+ {}
+};
+
+static struct kunit_suite drm_pick_cmdline_test_suite = {
+ .name = "drm_pick_cmdline",
+ .init = drm_client_modeset_test_init,
+ .exit = drm_client_modeset_test_exit,
+ .test_cases = drm_pick_cmdline_tests
+};
+
Re: [Intel-gfx] [PATCH v2 10/33] drm/modes: Add a function to generate analog display modes
On Fri, 23 Sep 2022, Thomas Zimmermann wrote: > Am 22.09.22 um 16:25 schrieb Maxime Ripard: >> +drm_dbg_kms(dev, >> +"Generating a %ux%u%c, %u-line mode with a %lu kHz clock\n", >> +hactive, vactive, >> +interlace ? 'i' : 'p', >> +params->num_lines, >> +pixel_clock_hz / 1000); > > Divide by HZ_PER_KHZ here and in other places. > >https://elixir.bootlin.com/linux/latest/source/include/linux/units.h#L23 >From the Department of Bikeshedding: I find "pixel_clock_hz / 1000" has much more clarity than "pixel_clock_hz / HZ_PER_KHZ". I don't consider the SI prefixes magic numbers. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: prepare for uC loading on MTL
== Series Details == Series: drm/i915: prepare for uC loading on MTL URL : https://patchwork.freedesktop.org/series/108925/ State : success == Summary == CI Bug Log - changes from CI_DRM_12168_full -> Patchwork_108925v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108925v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#4525]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][2] ([i915#2842]) +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb2/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-cmd: - shard-iclb: NOTRUN -> [SKIP][5] ([fdo#109313]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html * igt@gem_lmem_swapping@basic: - shard-iclb: NOTRUN -> [SKIP][6] ([i915#4613]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@gem_lmem_swapp...@basic.html * igt@gem_pxp@create-regular-context-1: - shard-iclb: NOTRUN -> [SKIP][7] ([i915#4270]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_...@create-regular-context-1.html * igt@gem_render_copy@y-tiled-to-vebox-linear: - shard-iclb: NOTRUN -> [SKIP][8] ([i915#768]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@gem_render_c...@y-tiled-to-vebox-linear.html * igt@gem_softpin@evict-snoop-interruptible: - shard-iclb: NOTRUN -> [SKIP][9] ([fdo#109312]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@gem_soft...@evict-snoop-interruptible.html * igt@gem_userptr_blits@coherency-unsync: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#3297]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_userptr_bl...@coherency-unsync.html * igt@gem_userptr_blits@vma-merge: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#3318]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb8/igt@gem_userptr_bl...@vma-merge.html * igt@gen3_render_linear_blits: - shard-iclb: NOTRUN -> [SKIP][12] ([fdo#109289]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@gen3_render_linear_blits.html * igt@gen9_exec_parse@bb-start-param: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#2856]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@gen9_exec_pa...@bb-start-param.html * igt@i915_pm_dc@dc3co-vpb-simulation: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#658]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@i915_pm...@dc3co-vpb-simulation.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#3989] / [i915#454]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-iclb6/igt@i915_pm...@dc6-dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_rpm@modeset-non-lpsp: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110892]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb1/igt@i915_pm_...@modeset-non-lpsp.html * igt@i915_selftest@live@gt_heartbeat: - shard-glk: [PASS][18] -> [DMESG-FAIL][19] ([i915#5334]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12168/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-glk7/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_big_fb@4-tiled-8bpp-rotate-180: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#5286]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v1/shard-iclb5/igt@kms_big...@4-tiled-8bpp-rotate-180.html * igt@kms_big_fb@y-tiled-64bpp-rotate-90: - shard-
Re: [Intel-gfx] [PATCH 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
On Thu, 22 Sep 2022, Daniele Ceraolo Spurio
wrote:
> From: Aravind Iddamsetty
>
> With MTL standalone media architecture the wopcm layout has changed with
> separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
> of WOPCM is 4MB with lower 2MB for SA Media and upper 2MB for GCD/GT.
>
> +=+===> ++ <== WOPCM TOP
> ^ ^ ||
> | | ||
> |GCD| GCD RC6 Image|
> |GuC|Power Context |
> |WOPCM ||
> |Size ++
> | | | GCD GuC Image|
> | | ||
> | v ||
> | +===> ++ <== SA Media GuC WOPCM Top
> | ^ ||
> | SA Media||
> |GuC| SA Media RC6 Image |
> | WOPCM |Power Context |
> |Size ||
> WOPCM | ++
> | | ||
> | | | SA Media GuC Image |
> | v ||
> | +===> ++ <== GuC WOPCM base
> | | WOPCM RSVD |
> | +--- + <== HuC Firmware Top
> v | HuC FW|
> +=> ++ <== WOPCM Base
>
> Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
> by the bios. Therefore, we can skip all the math for the partitioning
> and just limit ourselves to sanity checking the values.
>
> Signed-off-by: Aravind Iddamsetty
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
> Cc: John Harrison
> Cc: Alan Previn
> ---
> drivers/gpu/drm/i915/Makefile | 7 +--
> drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
> drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
> drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 +++---
> drivers/gpu/drm/i915/i915_driver.c | 2 -
> drivers/gpu/drm/i915/i915_drv.h | 3 --
> drivers/gpu/drm/i915/i915_gem.c | 5 ++-
> 11 files changed, 56 insertions(+), 32 deletions(-)
> rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
> rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index a26edcdadc21..6ed4c745b226 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -129,7 +129,9 @@ gt-y += \
> gt/intel_timeline.o \
> gt/intel_workarounds.o \
> gt/shmem_utils.o \
> - gt/sysfs_engines.o
> + gt/sysfs_engines.o \
> + gt/intel_wopcm.o
The comment near the top of the file:
# Please keep these build lists sorted!
> +
> # x86 intel-gtt module support
> gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
> # autogenerated null render state
> @@ -183,8 +185,7 @@ i915-y += \
> i915_trace_points.o \
> i915_ttm_buddy_manager.o \
> i915_vma.o \
> - i915_vma_resource.o \
> - intel_wopcm.o
> + i915_vma_resource.o
>
> # general-purpose microcontroller (GuC) support
> i915-y += gt/uc/intel_uc.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 30cf5c3369d9..605e1aa674d4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
>* why.
>*/
> ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
> -intel_wopcm_guc_size(&ggtt->vm.i915->wopcm));
> +intel_wopcm_guc_size(&ggtt->vm.gt->wopcm));
>
> ret = intel_vgt_balloon(ggtt);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index b367cfff48d5..a95eb0b656d2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
> seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
> intel_gt_pm_init_early(gt);
>
> + intel_wopcm_init_early(>->wopcm);
> intel_uc_init_early(>->uc);
> intel_rps_init_early(>->rps);
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index f19c2de77ff6..c20a32d2700f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -30,6 +30,7 @@
> #include "intel_migrate_types.h"
> #include "intel_wakeref.h"
> #include "pxp/intel_pxp_types.h"
> +#include "intel_wopcm.h"
>
> struct drm_i915_
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On 9/23/22 11:15, Thomas Zimmermann wrote:
> Hi
>
> Am 22.09.22 um 16:25 schrieb Maxime Ripard:
>> drm_connector_pick_cmdline_mode() is in charge of finding a proper
>> drm_display_mode from the definition we got in the video= command line
>> argument.
>>
>> Let's add some unit tests to make sure we're not getting any regressions
>> there.
>>
>> Signed-off-by: Maxime Ripard
>>
>> diff --git a/drivers/gpu/drm/drm_client_modeset.c
>> b/drivers/gpu/drm/drm_client_modeset.c
>> index bbc535cc50dd..d553e793e673 100644
>> --- a/drivers/gpu/drm/drm_client_modeset.c
>> +++ b/drivers/gpu/drm/drm_client_modeset.c
>> @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
>> *client, int mode)
>> return ret;
>> }
>> EXPORT_SYMBOL(drm_client_modeset_dpms);
>> +
>> +#ifdef CONFIG_DRM_KUNIT_TEST
>> +#include "tests/drm_client_modeset_test.c"
>> +#endif
>
> I strongly dislike this style of including source files in each other.
> It's a recipe for all kind of build errors. Can you do something else?
>
This seems to be the convention used to test static functions and what's
documented in the Kunit docs:
https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
I agree with you that's not ideal but I think that consistency with how
it is done by other subsystems is also important.
> As the tested function is an internal interface, maybe export a wrapper
> if tests are enabled, like this:
>
> #ifdef CONFIG_DRM_KUNIT_TEST
> struct drm_display_mode *
> drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
> {
>return drm_connector_pick_cmdline_mode(connector)
> }
> EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
> #endif
>
> The wrapper's declaration can be located in the kunit test file.
>
But that's also not nice since we are artificially exposing these only
to allow the static functions to be called from unit tests. And would
be a different approach than the one used by all other subsystems...
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Re: [Intel-gfx] [bug report] drm/i915/guc: Implement multi-lrc submission
On Thu, Sep 22, 2022 at 01:01:48PM -0700, John Harrison wrote:
> On 9/22/2022 07:26, Dan Carpenter wrote:
> > Hello Matthew Brost,
> >
> > The patch 6b540bf6f143: "drm/i915/guc: Implement multi-lrc
> > submission" from Oct 14, 2021, leads to the following Smatch static
> > checker warning:
> >
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:752
> > __guc_add_request()
> > warn: refcount leak 'ce->ref.refcount.refs.counter': lines='752'
> >
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > 672 static int __guc_add_request(struct intel_guc *guc, struct
> > i915_request *rq)
> > 673 {
> > 674 int err = 0;
> > 675 struct intel_context *ce =
> > request_to_scheduling_context(rq);
> > 676 u32 action[3];
> > 677 int len = 0;
> > 678 u32 g2h_len_dw = 0;
> > 679 bool enabled;
> > 680
> > 681 lockdep_assert_held(&rq->engine->sched_engine->lock);
> > 682
> > 683 /*
> > 684 * Corner case where requests were sitting in the priority
> > list or a
> > 685 * request resubmitted after the context was banned.
> > 686 */
> > 687 if (unlikely(intel_context_is_banned(ce))) {
> > 688 i915_request_put(i915_request_mark_eio(rq));
> > 689 intel_engine_signal_breadcrumbs(ce->engine);
> > 690 return 0;
> > 691 }
> > 692
> > 693 GEM_BUG_ON(!atomic_read(&ce->guc_id.ref));
> > 694 GEM_BUG_ON(context_guc_id_invalid(ce));
> > 695
> > 696 if (context_policy_required(ce)) {
> > 697 err = guc_context_policy_init_v70(ce, false);
> > 698 if (err)
> > 699 return err;
> > 700 }
> > 701
> > 702 spin_lock(&ce->guc_state.lock);
> > 703
> > 704 /*
> > 705 * The request / context will be run on the hardware when
> > scheduling
> > 706 * gets enabled in the unblock. For multi-lrc we still
> > submit the
> > 707 * context to move the LRC tails.
> > 708 */
> > 709 if (unlikely(context_blocked(ce) &&
> > !intel_context_is_parent(ce)))
> > 710 goto out;
> > 711
> > 712 enabled = context_enabled(ce) || context_blocked(ce);
> > 713
> > 714 if (!enabled) {
> > 715 action[len++] =
> > INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET;
> > 716 action[len++] = ce->guc_id.id;
> > 717 action[len++] = GUC_CONTEXT_ENABLE;
> > 718 set_context_pending_enable(ce);
> > 719 intel_context_get(ce);
> > 720 g2h_len_dw = G2H_LEN_DW_SCHED_CONTEXT_MODE_SET;
> > 721 } else {
> > 722 action[len++] = INTEL_GUC_ACTION_SCHED_CONTEXT;
> > 723 action[len++] = ce->guc_id.id;
> > 724 }
> > 725
> > 726 err = intel_guc_send_nb(guc, action, len, g2h_len_dw);
> > 727 if (!enabled && !err) {
> > 728 trace_intel_context_sched_enable(ce);
> > 729 atomic_inc(&guc->outstanding_submission_g2h);
> > 730 set_context_enabled(ce);
> > 731
> > 732 /*
> > 733 * Without multi-lrc KMD does the submission step
> > (moving the
> > 734 * lrc tail) so enabling scheduling is sufficient
> > to submit the
> > 735 * context. This isn't the case in multi-lrc
> > submission as the
> > 736 * GuC needs to move the tails, hence the need for
> > another H2G
> > 737 * to submit a multi-lrc context after enabling
> > scheduling.
> > 738 */
> > 739 if (intel_context_is_parent(ce)) {
> > 740 action[0] = INTEL_GUC_ACTION_SCHED_CONTEXT;
> > 741 err = intel_guc_send_nb(guc, action, len -
> > 1, 0);
> >
> > Should this have a something like:
> >
> > if (err)
> > intel_context_put(ce);
> No.
>
> The ce has been marked as enabled above because the actual enable call
> succeeded.? This is a secondary call to 'poke' the context. If this fails,
> the context might not get scheduled in a timely manner but the tracking
> state is still correct. The context is now in use by GuC and therefore must
> be reference locked. And the 'context_enabled' flag is set on the i915 side
> to note that the reference count is held.
>
> If you want to unwind at this point, you would need to send a
> CONTEXT_MODE_SET(DISABLE) H2G message (amongst other things) and only once
> that call has completed
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Don't use port enum as register offset
On Wed, 21 Sep 2022, Balasubramani Vivekanandan
wrote:
> Display DDI ports are enumerated as PORT_A,PORT_B... . The enums are
> also used as an index to access the DDI_BUF_CTL register for the port.
>
> With the introduction of TypeC ports, new enums PORT_TC1,PORT_TC2.. were
> added starting from enum value 4 to match the index position of the
> DDI_BUF_CTL register of those ports. Because those early platforms had
> only 3 non-TypeC ports PORT_A,PORT_B, PORT_C followed by TypeC ports.
> So the enums PORT_D,PORT_E.. and PORT_TC1,PORT_TC2.. used the same enum
> values.
>
> Driver also used the condition `if (port > PORT_TC1)` to identify if a
> port is a TypeC port or non-TypeC.
>
> From XELPD, additional non-TypeC ports were added in the platform
> calling them as PORT D, PORT E and the DDI registers for those ports
> were positioned after TypeC ports. So the enums PORT_D and PORT_E can't
> be used as their values do not match with register position. It led to
> creating new enums PORT_D_XELPD, PORT_E_XELPD for ports D and E.
>
> The condition `if (port > PORT_TC1)` was no more valid for XELPD to
> identify a TypeC port. Also it led to many additional special checks for
> ports PORT_D_XELPD/PORT_E_XELPD.
>
> With new platforms indicating that the DDI register positions of ports
> can vary across platforms it makes no more feasible to maintain the port
> enum values to match the DDI register position.
>
> Port DDI register position is now maintained in a separate datastructure
> part of the platform device info and ports are enumerated independently.
> With enums for TypeC ports defined at the bottom, driver can easily
> identify the TypeC ports.
>
> Removed a WARN_ON as it is no longer valid. The WARN was added in
> commit - "327f8d8c336d drm/i915: simplify setting of ddi_io_power_domain"
> The ddi_io_power_domain calculation has changed completely since the
> commit and doesn't need this WARN_ON anymore.
>
> Signed-off-by: Balasubramani Vivekanandan
>
I agree with the premise that defining platform specific port enums such
as PORT_D_XELPD to tackle differences in register offsets is handling
the problem at the wrong abstraction level.
I am not (at least not yet) convinced with the approach of adding
platform specific mappings in .display.ddi_offsets. The main problem I
have with that is adding yet another way to deal with different register
offsets. We already have many, and adding a new one isn't appealing.
Not that this *is* different from .display.pipe_offsets and
.display.trans_offsets which are actual *offsets*. The solution here is
actually misnamed; it's about indexes, not offsets.
Finally, even if we were to choose this approach, this should be split
to at least three separate patches. First, pass i915 to the register
macro, no other changes, totally non-functional. Second, use the
indexes. Third, remove PORT_D_XELPD etc.
I'm still considering alternatives. In the mean time, please find some
random comments on the details inline.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 12 ++--
> drivers/gpu/drm/i915/display/intel_bios.c | 4 +-
> drivers/gpu/drm/i915/display/intel_ddi.c | 63 +++---
> drivers/gpu/drm/i915/display/intel_display.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_display.h | 8 +--
> .../drm/i915/display/intel_display_power.c| 40 +--
> drivers/gpu/drm/i915/display/intel_fdi.c | 14 ++--
> drivers/gpu/drm/i915/display/intel_tc.c | 6 +-
> drivers/gpu/drm/i915/gvt/display.c| 30 -
> drivers/gpu/drm/i915/gvt/handlers.c | 17 +++--
> drivers/gpu/drm/i915/i915_pci.c | 66 ---
> drivers/gpu/drm/i915/i915_reg.h | 8 ++-
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 10 +--
> include/drm/i915_component.h | 2 +-
> 15 files changed, 144 insertions(+), 149 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ed4d93942dbd..70098b67149b 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -548,11 +548,11 @@ static void gen11_dsi_enable_ddi_buffer(struct
> intel_encoder *encoder)
> enum port port;
>
> for_each_dsi_port(port, intel_dsi->ports) {
> - tmp = intel_de_read(dev_priv, DDI_BUF_CTL(port));
> + tmp = intel_de_read(dev_priv, DDI_BUF_CTL(dev_priv, port));
> tmp |= DDI_BUF_CTL_ENABLE;
> - intel_de_write(dev_priv, DDI_BUF_CTL(port), tmp);
> + intel_de_write(dev_priv, DDI_BUF_CTL(dev_priv, port), tmp);
>
> - if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
> + if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(dev_priv,
> port)) &
> DDI_BUF_IS_IDLE),
> 500
Re: [Intel-gfx] [PATCH v2 10/33] drm/modes: Add a function to generate analog display modes
Hi Am 23.09.22 um 11:18 schrieb Jani Nikula: On Fri, 23 Sep 2022, Thomas Zimmermann wrote: Am 22.09.22 um 16:25 schrieb Maxime Ripard: + drm_dbg_kms(dev, + "Generating a %ux%u%c, %u-line mode with a %lu kHz clock\n", + hactive, vactive, + interlace ? 'i' : 'p', + params->num_lines, + pixel_clock_hz / 1000); Divide by HZ_PER_KHZ here and in other places. https://elixir.bootlin.com/linux/latest/source/include/linux/units.h#L23 From the Department of Bikeshedding: I find "pixel_clock_hz / 1000" has much more clarity than "pixel_clock_hz / HZ_PER_KHZ". This one's easy to see because it tells you with the _hz postfix. Many places don't and then it quickly gets confusing what units the code's converting. Best regards Thomas I don't consider the SI prefixes magic numbers. BR, Jani. -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Don't use port enum as register offset
On Fri, Sep 23, 2022 at 12:52:48PM +0300, Jani Nikula wrote: > On Wed, 21 Sep 2022, Balasubramani Vivekanandan > wrote: > > Display DDI ports are enumerated as PORT_A,PORT_B... . The enums are > > also used as an index to access the DDI_BUF_CTL register for the port. > > > > With the introduction of TypeC ports, new enums PORT_TC1,PORT_TC2.. were > > added starting from enum value 4 to match the index position of the > > DDI_BUF_CTL register of those ports. Because those early platforms had > > only 3 non-TypeC ports PORT_A,PORT_B, PORT_C followed by TypeC ports. > > So the enums PORT_D,PORT_E.. and PORT_TC1,PORT_TC2.. used the same enum > > values. > > > > Driver also used the condition `if (port > PORT_TC1)` to identify if a > > port is a TypeC port or non-TypeC. > > > > From XELPD, additional non-TypeC ports were added in the platform > > calling them as PORT D, PORT E and the DDI registers for those ports > > were positioned after TypeC ports. So the enums PORT_D and PORT_E can't > > be used as their values do not match with register position. It led to > > creating new enums PORT_D_XELPD, PORT_E_XELPD for ports D and E. > > > > The condition `if (port > PORT_TC1)` was no more valid for XELPD to > > identify a TypeC port. Also it led to many additional special checks for > > ports PORT_D_XELPD/PORT_E_XELPD. > > > > With new platforms indicating that the DDI register positions of ports > > can vary across platforms it makes no more feasible to maintain the port > > enum values to match the DDI register position. > > > > Port DDI register position is now maintained in a separate datastructure > > part of the platform device info and ports are enumerated independently. > > With enums for TypeC ports defined at the bottom, driver can easily > > identify the TypeC ports. > > > > Removed a WARN_ON as it is no longer valid. The WARN was added in > > commit - "327f8d8c336d drm/i915: simplify setting of ddi_io_power_domain" > > The ddi_io_power_domain calculation has changed completely since the > > commit and doesn't need this WARN_ON anymore. > > > > Signed-off-by: Balasubramani Vivekanandan > > > > I agree with the premise that defining platform specific port enums such > as PORT_D_XELPD to tackle differences in register offsets is handling > the problem at the wrong abstraction level. > > I am not (at least not yet) convinced with the approach of adding > platform specific mappings in .display.ddi_offsets. The main problem I > have with that is adding yet another way to deal with different register > offsets. We already have many, and adding a new one isn't appealing. > > Not that this *is* different from .display.pipe_offsets and > .display.trans_offsets which are actual *offsets*. The solution here is > actually misnamed; it's about indexes, not offsets. > > Finally, even if we were to choose this approach, this should be split > to at least three separate patches. First, pass i915 to the register > macro, no other changes, totally non-functional. Second, use the > indexes. Third, remove PORT_D_XELPD etc. > > I'm still considering alternatives. In the mean time, please find some > random comments on the details inline. One of the earlier alternatives proposed was some kind of declarative struct to describe each port, which would include separate indexes needed for different things (among information on the type of DDI/PHY/etc.) I think there was some attempt at something like that, but IIRC it tried to do a bunch of other stuff too so it got bikeshedded to death. I guess one key question is: Do we need to freestanding DDI/AUX/etc. register accesses or can we assume the encoder struct is always there? That would dictate whether we need any magic in the register macros at all, or whether we can just trust the caller to pass in the right index. Oh, and the other key question is: Is an index enough, or are the register offsets going to get really random at some point? So far I'm not aware of any changes the status-quo in the forseeable future, so not really seeing this part as super urgent compared to the whole PHY mess, which has been much more volatile in recent times. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
Hi
Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas:
On 9/23/22 11:15, Thomas Zimmermann wrote:
Hi
Am 22.09.22 um 16:25 schrieb Maxime Ripard:
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
diff --git a/drivers/gpu/drm/drm_client_modeset.c
b/drivers/gpu/drm/drm_client_modeset.c
index bbc535cc50dd..d553e793e673 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
*client, int mode)
return ret;
}
EXPORT_SYMBOL(drm_client_modeset_dpms);
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
I strongly dislike this style of including source files in each other.
It's a recipe for all kind of build errors. Can you do something else?
This seems to be the convention used to test static functions and what's
documented in the Kunit docs:
https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
That document says "...one option is to conditionally #include the test
file...". This doesn't sound like a strong requirement.
I agree with you that's not ideal but I think that consistency with how
it is done by other subsystems is also important.
As the tested function is an internal interface, maybe export a wrapper
if tests are enabled, like this:
#ifdef CONFIG_DRM_KUNIT_TEST
struct drm_display_mode *
drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
{
return drm_connector_pick_cmdline_mode(connector)
}
EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
#endif
The wrapper's declaration can be located in the kunit test file.
But that's also not nice since we are artificially exposing these only
to allow the static functions to be called from unit tests. And would
be a different approach than the one used by all other subsystems...
There's the problem of interference between the source files when
building the code. It's also not the same source code after including
the test file. At a minimum, including the tests' source file further
includes more files. also includes quite a few of Linux
header files.
IMHO the current convention (if any) is far from optimal and we should
consider breaking it.
Best regards
Thomas
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove flush_scheduled_work() from live_execlists
Reviewed-by: Nirmoy Das
On 6/30/2022 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to avoid several cases of potentential problems when
flushing is done from certain contexts.
Remove the call from the live_execlists selftest. Its purpose was to be
thorough and sync with the execlists capture state handling, but that is
not strictly required for the test to function and can be removed.
Signed-off-by: Tvrtko Ursulin
Cc: Tetsuo Handa
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 09f8cd2d0e2c..e62d089257ae 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -85,8 +85,6 @@ static int wait_for_reset(struct intel_engine_cs *engine,
break;
} while (time_before(jiffies, timeout));
- flush_scheduled_work();
-
if (rq->fence.error != -EIO) {
pr_err("%s: hanging request %llx:%lld not reset\n",
engine->name,
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation
URL : https://patchwork.freedesktop.org/series/108945/
State : warning
== Summary ==
Error: dim checkpatch failed
c7e564bf76cd overflow: Allow mixed type arguments
-:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#18:
[2]
https://lore.kernel.org/lkml/20220824084514.2261614-2-gwan-gyeong@intel.com
-:137: CHECK:SPACING: No space is necessary after a cast
#137: FILE: lib/overflow_kunit.c:27:
+#define DEFINE_TEST_ARRAY(t) DEFINE_TEST_ARRAY_TYPED(t, t, t)
-:137: CHECK:MACRO_ARG_REUSE: Macro argument reuse 't' - possible side-effects?
#137: FILE: lib/overflow_kunit.c:27:
+#define DEFINE_TEST_ARRAY(t) DEFINE_TEST_ARRAY_TYPED(t, t, t)
-:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'fmt' - possible
side-effects?
#151: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+ int _a_orig = a, _a_bump = a + 1; \
+ int _b_orig = b, _b_bump = b + 1; \
+ bool _of; \
+ t _r; \
+ \
+ _of = check_ ## op ## _overflow(a, b, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _of, of, \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+ a, b, of ? "" : " not", #t);\
+ KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+ a, b, r, _r, #t); \
+ /* Check for internal macro side-effects. */\
+ _of = check_ ## op ## _overflow(_a_orig++, _b_orig++, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _a_orig, _a_bump, "Unexpected " #op " macro
side-effect!\n"); \
+ KUNIT_EXPECT_EQ_MSG(test, _b_orig, _b_bump, "Unexpected " #op " macro
side-effect!\n"); \
} while (0)
-:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'sym' - possible
side-effects?
#151: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+ int _a_orig = a, _a_bump = a + 1; \
+ int _b_orig = b, _b_bump = b + 1; \
+ bool _of; \
+ t _r; \
+ \
+ _of = check_ ## op ## _overflow(a, b, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _of, of, \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+ a, b, of ? "" : " not", #t);\
+ KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+ a, b, r, _r, #t); \
+ /* Check for internal macro side-effects. */\
+ _of = check_ ## op ## _overflow(_a_orig++, _b_orig++, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _a_orig, _a_bump, "Unexpected " #op " macro
side-effect!\n"); \
+ KUNIT_EXPECT_EQ_MSG(test, _b_orig, _b_bump, "Unexpected " #op " macro
side-effect!\n"); \
} while (0)
-:151: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'a' - possible side-effects?
#151: FILE: lib/overflow_kunit.c:228:
+#define check_one_op(t, fmt, op, sym, a, b, r, of) do {
\
+ int _a_orig = a, _a_bump = a + 1; \
+ int _b_orig = b, _b_bump = b + 1; \
+ bool _of; \
+ t _r; \
+ \
+ _of = check_ ## op ## _overflow(a, b, &_r); \
+ KUNIT_EXPECT_EQ_MSG(test, _of, of, \
"expected "fmt" "sym" "fmt" to%s overflow (type %s)\n", \
+ a, b, of ? "" : " not", #t);\
+ KUNIT_EXPECT_EQ_MSG(test, _r, r,\
"expected "fmt" "sym" "fmt" == "fmt", got "fmt" (type %s)\n", \
+ a, b, r, _r, #t); \
+ /* Check for internal macro side-effects. */\
+ _of = check_ ## op ## _overflow(_a_orig++,
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details == Series: Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation URL : https://patchwork.freedesktop.org/series/108945/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.
Based on code from Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
drivers/gpu/drm/i915/i915_drv.h| 9 ++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
* HuC-specific commands.
*/
+static bool vcs_supported(struct intel_gt *gt)
+{
+ intel_engine_mask_t mask = gt->info.engine_mask;
+
+ /*
+* we can reach here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence fall back to the device info's
+* engine mask
+*/
+ if (!mask && gt_is_root(gt))
+ mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
Is it possible for all instances to be fused off? Wondering if the
function shouldn't just use platform_engine_mask.
Regards,
Tvrtko
+
+ return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+ struct intel_gt *gt = huc_to_gt(huc);
intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
+ if (!vcs_supported(gt)) {
+ intel_uc_fw_change_status(&huc->fw,
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+ return;
+ }
+
if (GRAPHICS_VER(i915) >= 11) {
huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
#define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
-#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({ \
unsigned int first__ = (first); \
unsigned int count__ = (count); \
- ((gt)->info.engine_mask &
\
-GENMASK(first__ + count__ - 1, first__)) >> first__; \
+ ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__;\
})
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+ __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
#define RCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
#define BCS_MASK(gt) \
[Intel-gfx] [PATCH 0/3] Add SLPC selftest live_slpc_power
live_slpc_power tests if running at low frequency saves power Rev2 : Add multi-tile support Riana Tauro (3): drm/i915/guc/slpc: Run SLPC selftests on all tiles drm/i915/selftests: Add helper function measure_power drm/i915/guc/slpc: Add SLPC selftest live_slpc_power drivers/gpu/drm/i915/gt/selftest_rps.c | 12 +- drivers/gpu/drm/i915/gt/selftest_slpc.c | 172 +--- 2 files changed, 164 insertions(+), 20 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 3/3] drm/i915/guc/slpc: Add SLPC selftest live_slpc_power
A fundamental assumption is that at lower frequencies,
not only do we run slower, but we save power compared to
higher frequencies.
live_slpc_power checks if running at low frequency saves power
v2: re-use code to measure power
fixed cosmetic review comments (Vinay)
Signed-off-by: Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 127 ++--
1 file changed, 118 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index 928f74718881..4c6e9257e593 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -11,7 +11,8 @@
enum test_type {
VARY_MIN,
VARY_MAX,
- MAX_GRANTED
+ MAX_GRANTED,
+ SLPC_POWER,
};
static int slpc_set_min_freq(struct intel_guc_slpc *slpc, u32 freq)
@@ -41,6 +42,39 @@ static int slpc_set_max_freq(struct intel_guc_slpc *slpc,
u32 freq)
return ret;
}
+static int slpc_set_freq(struct intel_gt *gt, u32 freq)
+{
+ int err;
+ struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+
+ err = slpc_set_max_freq(slpc, freq);
+ if (err) {
+ pr_err("Unable to update max freq");
+ return err;
+ }
+
+ err = slpc_set_min_freq(slpc, freq);
+ if (err) {
+ pr_err("Unable to update min freq");
+ return err;
+ }
+
+ return err;
+}
+
+static u64 measure_power_at_freq(struct intel_gt *gt, int *freq, u64 *power)
+{
+ int err = 0;
+
+ err = slpc_set_freq(gt, *freq);
+ if (err)
+ return err;
+ *freq = intel_rps_read_actual_frequency(>->rps);
+ *power = measure_power(>->rps, freq);
+
+ return err;
+}
+
static int vary_max_freq(struct intel_guc_slpc *slpc, struct intel_rps *rps,
u32 *max_act_freq)
{
@@ -113,6 +147,58 @@ static int vary_min_freq(struct intel_guc_slpc *slpc,
struct intel_rps *rps,
return err;
}
+static int slpc_power(struct intel_gt *gt, struct intel_engine_cs *engine)
+{
+ struct intel_guc_slpc *slpc = >->uc.guc.slpc;
+ struct {
+ u64 power;
+ int freq;
+ } min, max;
+ int err = 0;
+
+ /*
+* Our fundamental assumption is that running at lower frequency
+* actually saves power. Let's see if our RAPL measurement supports
+* that theory.
+*/
+ if (!librapl_supported(gt->i915))
+ return 0;
+
+ min.freq = slpc->min_freq;
+ err = measure_power_at_freq(gt, &min.freq, &min.power);
+
+ if (err)
+ return err;
+
+ max.freq = slpc->rp0_freq;
+ err = measure_power_at_freq(gt, &max.freq, &max.power);
+
+ if (err)
+ return err;
+
+ pr_info("%s: min:%llumW @ %uMHz, max:%llumW @ %uMHz\n",
+ engine->name,
+ min.power, min.freq,
+ max.power, max.freq);
+
+ if (10 * min.freq >= 9 * max.freq) {
+ pr_notice("Could not control frequency, ran at [%uMHz,
%uMhz]\n",
+ min.freq, max.freq);
+ }
+
+ if (11 * min.power > 10 * max.power) {
+ pr_err("%s: did not conserve power when setting lower
frequency!\n",
+ engine->name);
+ err = -EINVAL;
+ }
+
+ /* Restore min/max frequencies */
+ slpc_set_max_freq(slpc, slpc->rp0_freq);
+ slpc_set_min_freq(slpc, slpc->min_freq);
+
+ return err;
+}
+
static int max_granted_freq(struct intel_guc_slpc *slpc, struct intel_rps
*rps, u32 *max_act_freq)
{
struct intel_gt *gt = rps_to_gt(rps);
@@ -233,17 +319,23 @@ static int run_test(struct intel_gt *gt, int test_type)
err = max_granted_freq(slpc, rps, &max_act_freq);
break;
+
+ case SLPC_POWER:
+ err = slpc_power(gt, engine);
+ break;
}
- pr_info("Max actual frequency for %s was %d\n",
- engine->name, max_act_freq);
+ if (test_type != SLPC_POWER) {
+ pr_info("Max actual frequency for %s was %d\n",
+ engine->name, max_act_freq);
- /* Actual frequency should rise above min */
- if (max_act_freq <= slpc_min_freq) {
- pr_err("Actual freq did not rise above min\n");
- pr_err("Perf Limit Reasons: 0x%x\n",
- intel_uncore_read(gt->uncore,
GT0_PERF_LIMIT_REASONS));
- err = -EINVAL;
+ /* Actual frequency should rise above min */
+ if (max_act_freq <= slpc_min_freq) {
+ pr_err("Actual freq did not rise above min\n");
+ pr_err("Perf Limit Reasons: 0x%x\n",
+
[Intel-gfx] [PATCH 2/3] drm/i915/selftests: Add helper function measure_power
move the power measurement and the triangle filter
to a different function. No functional changes.
Signed-off-by: Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_rps.c
b/drivers/gpu/drm/i915/gt/selftest_rps.c
index cfb4708dd62e..99a372486fb7 100644
--- a/drivers/gpu/drm/i915/gt/selftest_rps.c
+++ b/drivers/gpu/drm/i915/gt/selftest_rps.c
@@ -1107,21 +1107,27 @@ static u64 __measure_power(int duration_ms)
return div64_u64(1000 * 1000 * dE, dt);
}
-static u64 measure_power_at(struct intel_rps *rps, int *freq)
+static u64 measure_power(struct intel_rps *rps, int *freq)
{
u64 x[5];
int i;
- *freq = rps_set_check(rps, *freq);
for (i = 0; i < 5; i++)
x[i] = __measure_power(5);
- *freq = (*freq + read_cagf(rps)) / 2;
+
+ *freq = (*freq + intel_rps_read_actual_frequency(rps)) / 2;
/* A simple triangle filter for better result stability */
sort(x, 5, sizeof(*x), cmp_u64, NULL);
return div_u64(x[1] + 2 * x[2] + x[3], 4);
}
+static u64 measure_power_at(struct intel_rps *rps, int *freq)
+{
+ *freq = rps_set_check(rps, *freq);
+ return measure_power(rps, freq);
+}
+
int live_rps_power(void *arg)
{
struct intel_gt *gt = arg;
--
2.25.1
[Intel-gfx] [PATCH 1/3] drm/i915/guc/slpc: Run SLPC selftests on all tiles
Run slpc selftests on all tiles
Signed-off-by: Riana Tauro
---
drivers/gpu/drm/i915/gt/selftest_slpc.c | 45 -
1 file changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_slpc.c
b/drivers/gpu/drm/i915/gt/selftest_slpc.c
index f8a1d27df272..928f74718881 100644
--- a/drivers/gpu/drm/i915/gt/selftest_slpc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_slpc.c
@@ -270,26 +270,50 @@ static int run_test(struct intel_gt *gt, int test_type)
static int live_slpc_vary_min(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
+ unsigned int i;
+ int ret;
+
+ for_each_gt(gt, i915, i) {
+ ret = run_test(gt, VARY_MIN);
+ if (ret)
+ return ret;
+ }
- return run_test(gt, VARY_MIN);
+ return ret;
}
static int live_slpc_vary_max(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
+ unsigned int i;
+ int ret;
+
+ for_each_gt(gt, i915, i) {
+ ret = run_test(gt, VARY_MAX);
+ if (ret)
+ return ret;
+ }
- return run_test(gt, VARY_MAX);
+ return ret;
}
/* check if pcode can grant RP0 */
static int live_slpc_max_granted(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
+ unsigned int i;
+ int ret;
+
+ for_each_gt(gt, i915, i) {
+ ret = run_test(gt, MAX_GRANTED);
+ if (ret)
+ return ret;
+ }
- return run_test(gt, MAX_GRANTED);
+ return ret;
}
int intel_slpc_live_selftests(struct drm_i915_private *i915)
@@ -300,8 +324,13 @@ int intel_slpc_live_selftests(struct drm_i915_private
*i915)
SUBTEST(live_slpc_max_granted),
};
- if (intel_gt_is_wedged(to_gt(i915)))
- return 0;
+ struct intel_gt *gt;
+ unsigned int i;
+
+ for_each_gt(gt, i915, i) {
+ if (intel_gt_is_wedged(gt))
+ return 0;
+ }
return i915_live_subtests(tests, i915);
}
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove flush_scheduled_work() from live_execlists
On 23/09/2022 11:32, Das, Nirmoy wrote:
Reviewed-by: Nirmoy Das
Thanks!
Pushed now. Should land with 6.2.
Regards,
Tvrtko
On 6/30/2022 2:57 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
There are ongoing efforts to remove usages of flush_scheduled_work() from
drivers in order to avoid several cases of potentential problems when
flushing is done from certain contexts.
Remove the call from the live_execlists selftest. Its purpose was to be
thorough and sync with the execlists capture state handling, but that is
not strictly required for the test to function and can be removed.
Signed-off-by: Tvrtko Ursulin
Cc: Tetsuo Handa
---
drivers/gpu/drm/i915/gt/selftest_execlists.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_execlists.c
b/drivers/gpu/drm/i915/gt/selftest_execlists.c
index 09f8cd2d0e2c..e62d089257ae 100644
--- a/drivers/gpu/drm/i915/gt/selftest_execlists.c
+++ b/drivers/gpu/drm/i915/gt/selftest_execlists.c
@@ -85,8 +85,6 @@ static int wait_for_reset(struct intel_engine_cs
*engine,
break;
} while (time_before(jiffies, timeout));
- flush_scheduled_work();
-
if (rq->fence.error != -EIO) {
pr_err("%s: hanging request %llx:%lld not reset\n",
engine->name,
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On 9/23/22 12:30, Thomas Zimmermann wrote:
[...]
+
+#ifdef CONFIG_DRM_KUNIT_TEST
+#include "tests/drm_client_modeset_test.c"
+#endif
>>>
>>> I strongly dislike this style of including source files in each other.
>>> It's a recipe for all kind of build errors. Can you do something else?
>>>
>>
>> This seems to be the convention used to test static functions and what's
>> documented in the Kunit docs:
>> https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
>
> That document says "...one option is to conditionally #include the test
> file...". This doesn't sound like a strong requirement.
>
That's true.
>>
>> I agree with you that's not ideal but I think that consistency with how
>> it is done by other subsystems is also important.
>>
>>> As the tested function is an internal interface, maybe export a wrapper
>>> if tests are enabled, like this:
>>>
>>> #ifdef CONFIG_DRM_KUNIT_TEST
>>> struct drm_display_mode *
>>> drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
>>> {
>>> return drm_connector_pick_cmdline_mode(connector)
>>> }
>>> EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
>>> #endif
>>>
>>> The wrapper's declaration can be located in the kunit test file.
>>>
>>
>> But that's also not nice since we are artificially exposing these only
>> to allow the static functions to be called from unit tests. And would
>> be a different approach than the one used by all other subsystems...
>>
>
> There's the problem of interference between the source files when
> building the code. It's also not the same source code after including
> the test file. At a minimum, including the tests' source file further
> includes more files. also includes quite a few of Linux
> header files.
>
> IMHO the current convention (if any) is far from optimal and we should
> consider breaking it.
>
Yes, I agree with that. But probably we should be explicit about the
wrapper export symbols to access static functions pattern in the KUnit
docs so other subsystems could do the same and it becomes a convention ?
> Best regards
> Thomas
>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
[Intel-gfx] ✓ Fi.CI.BAT: success for Fixes integer overflow or integer truncation issues in page lookups, ttm place configuration and scatterlist creation
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation
URL : https://patchwork.freedesktop.org/series/108945/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12173 -> Patchwork_108945v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/index.html
Participating hosts (43 -> 42)
--
Additional (1): fi-hsw-4770
Missing(2): fi-bdw-samus fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108945v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- {bat-dg2-11}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_108945v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3012])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- fi-rkl-guc: [PASS][5] -> [INCOMPLETE][6] ([i915#4418])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-rkl-guc/igt@i915_selftest@live@gt_engines.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#6298])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1072]) +3
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-rkl-guc: NOTRUN -> [FAIL][11] ([i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-rkl-guc/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][12] ([i915#6816]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}: [DMESG-WARN][14] ([i915#2867]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_pm:
- {fi-tgl-mst}: [DMESG-FAIL][16] ([i915#3987]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/fi-tgl-mst/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hugepages:
- {bat-adln-1}: [DMESG-WARN][18] ([i915#5278]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12173/bat-adln-1/igt@i915_selftest@l...@hugepages.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108945v1/bat-adln-1/igt@i915_selftest@l...@hugepages.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [INCOMPLETE][20] ([i915#6257] / [i915#6380]) ->
[PASS][21]
[20]:
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On Fri, Sep 23, 2022 at 12:30:09PM +0200, Thomas Zimmermann wrote:
> Am 23.09.22 um 11:26 schrieb Javier Martinez Canillas:
> > On 9/23/22 11:15, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 22.09.22 um 16:25 schrieb Maxime Ripard:
> > > > drm_connector_pick_cmdline_mode() is in charge of finding a proper
> > > > drm_display_mode from the definition we got in the video= command line
> > > > argument.
> > > >
> > > > Let's add some unit tests to make sure we're not getting any regressions
> > > > there.
> > > >
> > > > Signed-off-by: Maxime Ripard
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_client_modeset.c
> > > > b/drivers/gpu/drm/drm_client_modeset.c
> > > > index bbc535cc50dd..d553e793e673 100644
> > > > --- a/drivers/gpu/drm/drm_client_modeset.c
> > > > +++ b/drivers/gpu/drm/drm_client_modeset.c
> > > > @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
> > > > *client, int mode)
> > > > return ret;
> > > >}
> > > >EXPORT_SYMBOL(drm_client_modeset_dpms);
> > > > +
> > > > +#ifdef CONFIG_DRM_KUNIT_TEST
> > > > +#include "tests/drm_client_modeset_test.c"
> > > > +#endif
> > >
> > > I strongly dislike this style of including source files in each other.
> > > It's a recipe for all kind of build errors. Can you do something else?
> > >
> >
> > This seems to be the convention used to test static functions and what's
> > documented in the Kunit docs:
> > https://kunit.dev/third_party/kernel/docs/tips.html#testing-static-functions
>
> That document says "...one option is to conditionally #include the test
> file...". This doesn't sound like a strong requirement.
No, but this is the only option documented, which still indicates a very
strong preference.
> > I agree with you that's not ideal but I think that consistency with how
> > it is done by other subsystems is also important.
> > > As the tested function is an internal interface, maybe export a wrapper
> > > if tests are enabled, like this:
> > >
> > > #ifdef CONFIG_DRM_KUNIT_TEST
> > > struct drm_display_mode *
> > > drm_connector_pick_cmdline_mode_kunit(drm_conenctor)
> > > {
> > > return drm_connector_pick_cmdline_mode(connector)
> > > }
> > > EXPORT_SYMBOL(drm_connector_pick_cmdline_mode_kunit)
> > > #endif
> > >
> > > The wrapper's declaration can be located in the kunit test file.
And I'm afraid this just doesn't scale. If we start testing more and
more static functions, do we really want to have that wrapper for each
of them?
> > But that's also not nice since we are artificially exposing these only
> > to allow the static functions to be called from unit tests. And would
> > be a different approach than the one used by all other subsystems...
> >
>
> There's the problem of interference between the source files when building
> the code. It's also not the same source code after including the test file.
> At a minimum, including the tests' source file further includes more files.
> also includes quite a few of Linux header files.
>
> IMHO the current convention (if any) is far from optimal and we should
> consider breaking it.
I mean... this is a discussion about theoretical issues. If there is
indeed some regular build errors on this, then sure, we can change it.
I'm confident that will affect pretty much every one using kunit equally
though, so I'm fairly sure the documentation itself will have changed.
But right now we're discussing an alternative because of a problem we
never experienced. I don't see the point of breaking the consistency
provided by the documentation for something not backed by any actual
problem.
Maxime
signature.asc
Description: PGP signature
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915/pxp: Add firmware status when ARB session fails
== Series Details == Series: series starting with [1/1] drm/i915/pxp: Add firmware status when ARB session fails URL : https://patchwork.freedesktop.org/series/108928/ State : success == Summary == CI Bug Log - changes from CI_DRM_12169_full -> Patchwork_108928v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108928v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4338]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb2/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb2/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb6/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108928v1/shard-snb5/boot.html [43]: https://intel-gfx-ci.01.
Re: [Intel-gfx] [PATCH v2 13/33] drm/client: Add some tests for drm_connector_pick_cmdline_mode()
On Thu, 22 Sep 2022, Maxime Ripard wrote:
> drm_connector_pick_cmdline_mode() is in charge of finding a proper
> drm_display_mode from the definition we got in the video= command line
> argument.
>
> Let's add some unit tests to make sure we're not getting any regressions
> there.
>
> Signed-off-by: Maxime Ripard
>
> diff --git a/drivers/gpu/drm/drm_client_modeset.c
> b/drivers/gpu/drm/drm_client_modeset.c
> index bbc535cc50dd..d553e793e673 100644
> --- a/drivers/gpu/drm/drm_client_modeset.c
> +++ b/drivers/gpu/drm/drm_client_modeset.c
> @@ -1237,3 +1237,7 @@ int drm_client_modeset_dpms(struct drm_client_dev
> *client, int mode)
> return ret;
> }
> EXPORT_SYMBOL(drm_client_modeset_dpms);
> +
> +#ifdef CONFIG_DRM_KUNIT_TEST
> +#include "tests/drm_client_modeset_test.c"
> +#endif
> diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> new file mode 100644
> index ..46335de7bc6b
> --- /dev/null
> +++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
[snip]
> +MODULE_AUTHOR("Maxime Ripard ");
> +MODULE_LICENSE("GPL");
I think these annotations are incompatible with including the unit test,
and, in this case, affect drm.ko.
And we'll have two kinds of tests, those that get built via
tests/Makefile, and those that get included, like this one, which should
not be mentioned in tests/Makefile.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for Add PXP firmware respose on ARB failure
== Series Details == Series: Add PXP firmware respose on ARB failure URL : https://patchwork.freedesktop.org/series/108929/ State : success == Summary == CI Bug Log - changes from CI_DRM_12169_full -> Patchwork_108929v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108929v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-snb: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) ([i915#4338]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12169/shard-snb2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb6/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb6/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb6/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb5/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb4/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb2/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108929v1/shard-snb
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Fix PSR_IMR/IIR field handling
On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift
> > > for
> > > bits in PSR_IMR/IIR registers:
> > >
> > > /*
> > > * gen12+ has registers relative to transcoder and one per
> > > transcoder
> > > * using the same bit definition: handle it as TRANSCODER_EDP to
> > > force
> > > * 0 shift in bit definition
> > > */
> > >
> > > At the time of writing the code assumption "TRANSCODER_EDP == 0"
> > > was made.
> > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > shifted
> > > incorrectly if DISPLAY_VER >= 12.
> >
> > From where are you getting that TRANSCODER_EDP == 0?
>
> It's not. That is my point. If you look at this commit:
>
> https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
>
> adding this comment:
>
> + /*
> +* gen12+ has registers relative to transcoder and one per
> transcoder
> +* using the same bit definition: handle it as TRANSCODER_EDP
> to force
> +* 0 shift in bit definition
> +*/
>
> and the code added by this commit is doing
>
> ...
> + trans_shift = 0;
> mask = EDP_PSR_ERROR(trans_shift);
> ...
>
> + mask = EDP_PSR_ERROR(trans_shift);
> ...
>
> and if we look at EDP_PSR_ERROR definition:
>
> ...
> #define _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> TRANSCODER_EDP ? \
>0 : ((trans) -
> TRANSCODER_A + 1) * 8)
> ...
> #define EDP_PSR_ERROR(trans)(0x4 <<
> _EDP_PSR_TRANS_SHIFT(trans))
> ...
>
> EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> TRANSCODER_EDP as mentioned in the added comment:
> EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
>
> My patch is doing what is in the comment. There are other way to fix
> this, but to my opinion original idea using TRANSCODER_EDP in commit
> 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> code pretty clean.
>
> >
> > enum pipe {
> > INVALID_PIPE = -1,
> >
> > PIPE_A = 0,
> > PIPE_B,
> > PIPE_C,
> > PIPE_D,
> > _PIPE_EDP,
> >
> > I915_MAX_PIPES = _PIPE_EDP
> > };
> >
> > #define pipe_name(p) ((p) + 'A')
> >
> > enum transcoder {
> > INVALID_TRANSCODER = -1,
> > /*
> > * The following transcoders have a 1:1 transcoder -> pipe
> > mapping,
> > * keep their values fixed: the code assumes that
> > TRANSCODER_A=0, the
> > * rest have consecutive values and match the enum values of
> > the pipes
> > * they map to.EDP_PSR_TRANS_
> > */
> > TRANSCODER_A = PIPE_A,
> > TRANSCODER_B = PIPE_B,
> > TRANSCODER_C = PIPE_C,
> > TRANSCODER_D = PIPE_D,
> >
> > /*
> > * The following transcoders can map to any pipe, their enum
> > value
> > * doesn't need to stay fixed.
> > */
> > TRANSCODER_EDP,
> >
> > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> >
> > >
> > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > thought
> > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this way
> > > keeps
> > > code clean and readable.
> >
> > trans_shift = 0 is fine, we needed this because display12+ splited
> > from a single register with all transcoder to one register per
> > transcoder.
> >
>
> No, it's not. See the definition of _EDP_PSR_TRANS_SHIFT and
> EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would prevent
> misunderstanding here.
Okay now I understood.
In my opinion the proper fix would be add TGL_X macros to be used in diplay12+
paths and drop the EDP transcoder concept that do not exist in TGL+.
Also please include a fixes tag pointing to
8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf so this gets backported.
>
> > >
> > > v2: Improve commit message (José)
> > >
> > > Cc: Mika Kahola
> > > Cc: José Roberto de Souza
> > >
> > > Signed-off-by: Jouni Högander
> > > ---
> > > drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> > > b/drivers/gpu/drm/i915/display/intel_psr.c
> > > index 9def8d9fade6..9ecf1a9a1120 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> > > @@ -129,7 +129,7 @@ static void psr_irq_control(struct intel_dp
> > > *intel_dp)
> > > * 0 shift in bit definition
> > > */
> > > if (DISPLAY_VER(dev_priv) >= 12) {
> > > - trans_shift = 0;
> > > + trans_shift = TRANSCODER_EDP;
> > > imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
> > > } else {
> >
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Fix PSR_IMR/IIR field handling
On Fri, 2022-09-23 at 12:37 +, Souza, Jose wrote:
> On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> > On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > > Current PSR code is supposed to use TRANSCODER_EDP to force 0
> > > > shift
> > > > for
> > > > bits in PSR_IMR/IIR registers:
> > > >
> > > > /*
> > > > * gen12+ has registers relative to transcoder and one per
> > > > transcoder
> > > > * using the same bit definition: handle it as TRANSCODER_EDP
> > > > to
> > > > force
> > > > * 0 shift in bit definition
> > > > */
> > > >
> > > > At the time of writing the code assumption "TRANSCODER_EDP ==
> > > > 0"
> > > > was made.
> > > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > > shifted
> > > > incorrectly if DISPLAY_VER >= 12.
> > >
> > > From where are you getting that TRANSCODER_EDP == 0?
> >
> > It's not. That is my point. If you look at this commit:
> >
> > https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
> >
> > adding this comment:
> >
> > + /*
> > + * gen12+ has registers relative to transcoder and one per
> > transcoder
> > + * using the same bit definition: handle it as
> > TRANSCODER_EDP
> > to force
> > + * 0 shift in bit definition
> > + */
> >
> > and the code added by this commit is doing
> >
> > ...
> > + trans_shift = 0;
> > mask = EDP_PSR_ERROR(trans_shift);
> > ...
> >
> > + mask = EDP_PSR_ERROR(trans_shift);
> > ...
> >
> > and if we look at EDP_PSR_ERROR definition:
> >
> > ...
> > #define _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> > TRANSCODER_EDP ? \
> > 0 : ((trans) -
> > TRANSCODER_A + 1) * 8)
> > ...
> > #define EDP_PSR_ERROR(trans) (0x4 <<
> > _EDP_PSR_TRANS_SHIFT(trans))
> > ...
> >
> > EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> > TRANSCODER_EDP as mentioned in the added comment:
> > EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
> >
> > My patch is doing what is in the comment. There are other way to
> > fix
> > this, but to my opinion original idea using TRANSCODER_EDP in
> > commit
> > 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> > code pretty clean.
> >
> > >
> > > enum pipe {
> > > INVALID_PIPE = -1,
> > >
> > > PIPE_A = 0,
> > > PIPE_B,
> > > PIPE_C,
> > > PIPE_D,
> > > _PIPE_EDP,
> > >
> > > I915_MAX_PIPES = _PIPE_EDP
> > > };
> > >
> > > #define pipe_name(p) ((p) + 'A')
> > >
> > > enum transcoder {
> > > INVALID_TRANSCODER = -1,
> > > /*
> > > * The following transcoders have a 1:1 transcoder ->
> > > pipe
> > > mapping,
> > > * keep their values fixed: the code assumes that
> > > TRANSCODER_A=0, the
> > > * rest have consecutive values and match the enum values
> > > of
> > > the pipes
> > > * they map to.EDP_PSR_TRANS_
> > > */
> > > TRANSCODER_A = PIPE_A,
> > > TRANSCODER_B = PIPE_B,
> > > TRANSCODER_C = PIPE_C,
> > > TRANSCODER_D = PIPE_D,
> > >
> > > /*
> > > * The following transcoders can map to any pipe, their
> > > enum
> > > value
> > > * doesn't need to stay fixed.
> > > */
> > > TRANSCODER_EDP,
> > >
> > > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> > >
> > > >
> > > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > > thought
> > > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this
> > > > way
> > > > keeps
> > > > code clean and readable.
> > >
> > > trans_shift = 0 is fine, we needed this because display12+
> > > splited
> > > from a single register with all transcoder to one register per
> > > transcoder.
> > >
> >
> > No, it's not. See the definition of _EDP_PSR_TRANS_SHIFT and
> > EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would
> > prevent
> > misunderstanding here.
>
> Okay now I understood.
> In my opinion the proper fix would be add TGL_X macros to be used in
> diplay12+ paths and drop the EDP transcoder concept that do not exist
> in TGL+.
Ok, I started to look at this originally and it gets a bit messy as
each bit in PSR_IMR/PSR_ISR needs separate handling. If we choose this
then I was thinking adding similar _bit_get functions as we have for
man_trk_ctl bits. What do you think?
I would still consider current approach as forcing 0 shifting using
EDP_PSR_TRANS_* keeps it pretty simple.
>
> Also please include a fixes tag pointing to
> 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf so this gets backported.
>
> >
> > > >
> > > > v2: Improve commit message (José)
> > > >
> > > > Cc: Mika Kahola
> > > > Cc: José Roberto de Souza
> > > >
> > > > Signed-off-by: Jouni Högander
> > > > ---
> > > > d
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Improve debug print in vm_fault_ttm (rev2)
== Series Details == Series: drm/i915: Improve debug print in vm_fault_ttm (rev2) URL : https://patchwork.freedesktop.org/series/108887/ State : warning == Summary == Error: dim checkpatch failed 751ba3d859b3 drm/i915: Improve debug print in vm_fault_ttm -:24: WARNING:LONG_LINE: line length of 106 exceeds 100 columns #24: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1037: + drm_dbg(dev, "Unable to make resource CPU accessible(err = %pe)\n", ERR_PTR(err)); total: 0 errors, 1 warnings, 0 checks, 8 lines checked
Re: [Intel-gfx] [PATCH v2] drm/i915/psr: Fix PSR_IMR/IIR field handling
On Fri, 2022-09-23 at 12:45 +, Hogander, Jouni wrote:
> On Fri, 2022-09-23 at 12:37 +, Souza, Jose wrote:
> > On Fri, 2022-09-23 at 06:11 +, Hogander, Jouni wrote:
> > > On Thu, 2022-09-22 at 13:08 +, Souza, Jose wrote:
> > > > On Thu, 2022-09-22 at 10:59 +0300, Jouni Högander wrote:
> > > > > Current PSR code is supposed to use TRANSCODER_EDP to force 0
> > > > > shift
> > > > > for
> > > > > bits in PSR_IMR/IIR registers:
> > > > >
> > > > > /*
> > > > > * gen12+ has registers relative to transcoder and one per
> > > > > transcoder
> > > > > * using the same bit definition: handle it as TRANSCODER_EDP
> > > > > to
> > > > > force
> > > > > * 0 shift in bit definition
> > > > > */
> > > > >
> > > > > At the time of writing the code assumption "TRANSCODER_EDP ==
> > > > > 0"
> > > > > was made.
> > > > > This is not the case and all fields in PSR_IMR and PSR_IIR are
> > > > > shifted
> > > > > incorrectly if DISPLAY_VER >= 12.
> > > >
> > > > From where are you getting that TRANSCODER_EDP == 0?
> > >
> > > It's not. That is my point. If you look at this commit:
> > >
> > > https://github.com/freedesktop/drm-tip/commit/8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf
> > >
> > > adding this comment:
> > >
> > > + /*
> > > + * gen12+ has registers relative to transcoder and one per
> > > transcoder
> > > + * using the same bit definition: handle it as
> > > TRANSCODER_EDP
> > > to force
> > > + * 0 shift in bit definition
> > > + */
> > >
> > > and the code added by this commit is doing
> > >
> > > ...
> > > + trans_shift = 0;
> > > mask = EDP_PSR_ERROR(trans_shift);
> > > ...
> > >
> > > + mask = EDP_PSR_ERROR(trans_shift);
> > > ...
> > >
> > > and if we look at EDP_PSR_ERROR definition:
> > >
> > > ...
> > > #define _EDP_PSR_TRANS_SHIFT(trans) ((trans) ==
> > > TRANSCODER_EDP ? \
> > > 0 : ((trans) -
> > > TRANSCODER_A + 1) * 8)
> > > ...
> > > #define EDP_PSR_ERROR(trans) (0x4 <<
> > > _EDP_PSR_TRANS_SHIFT(trans))
> > > ...
> > >
> > > EDP_PSR_ERROR(0) is 0x400 which is wrong for e.g. TGL. Using
> > > TRANSCODER_EDP as mentioned in the added comment:
> > > EDP_PSR_ERROR(TRANSCODER_EDP) is 0x4 which is correct.
> > >
> > > My patch is doing what is in the comment. There are other way to
> > > fix
> > > this, but to my opinion original idea using TRANSCODER_EDP in
> > > commit
> > > 8241cfbe67f4082eee5fc72e5a8025c5b58c2ddf to force 0 shift keeps the
> > > code pretty clean.
> > >
> > > >
> > > > enum pipe {
> > > > INVALID_PIPE = -1,
> > > >
> > > > PIPE_A = 0,
> > > > PIPE_B,
> > > > PIPE_C,
> > > > PIPE_D,
> > > > _PIPE_EDP,
> > > >
> > > > I915_MAX_PIPES = _PIPE_EDP
> > > > };
> > > >
> > > > #define pipe_name(p) ((p) + 'A')
> > > >
> > > > enum transcoder {
> > > > INVALID_TRANSCODER = -1,
> > > > /*
> > > > * The following transcoders have a 1:1 transcoder ->
> > > > pipe
> > > > mapping,
> > > > * keep their values fixed: the code assumes that
> > > > TRANSCODER_A=0, the
> > > > * rest have consecutive values and match the enum values
> > > > of
> > > > the pipes
> > > > * they map to.EDP_PSR_TRANS_
> > > > */
> > > > TRANSCODER_A = PIPE_A,
> > > > TRANSCODER_B = PIPE_B,
> > > > TRANSCODER_C = PIPE_C,
> > > > TRANSCODER_D = PIPE_D,
> > > >
> > > > /*
> > > > * The following transcoders can map to any pipe, their
> > > > enum
> > > > value
> > > > * doesn't need to stay fixed.
> > > > */
> > > > TRANSCODER_EDP,
> > > >
> > > > https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/i915/display/intel_display.h#n87
> > > >
> > > > >
> > > > > Fix this by using TRANSCODER_EDP definition instead of 0. Even
> > > > > thought
> > > > > TRANSCODER_EDP doesn't exist in display_ver >= 12 doing it this
> > > > > way
> > > > > keeps
> > > > > code clean and readable.
> > > >
> > > > trans_shift = 0 is fine, we needed this because display12+
> > > > splited
> > > > from a single register with all transcoder to one register per
> > > > transcoder.
> > > >
> > >
> > > No, it's not. See the definition of _EDP_PSR_TRANS_SHIFT and
> > > EDP_PSR_TRANS_*. Maybe renaming trans_shift to transcoder would
> > > prevent
> > > misunderstanding here.
> >
> > Okay now I understood.
> > In my opinion the proper fix would be add TGL_X macros to be used in
> > diplay12+ paths and drop the EDP transcoder concept that do not exist
> > in TGL+.
>
> Ok, I started to look at this originally and it gets a bit messy as
> each bit in PSR_IMR/PSR_ISR needs separate handling. If we choose this
> then I was thinking adding similar _bit_get functions as we have for
> man_trk_ctl bits. What do you think?
If the code gets simpler go ahead with functions to return the bits.
>
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve debug print in vm_fault_ttm (rev2)
== Series Details ==
Series: drm/i915: Improve debug print in vm_fault_ttm (rev2)
URL : https://patchwork.freedesktop.org/series/108887/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12174 -> Patchwork_108887v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/index.html
Participating hosts (42 -> 44)
--
Additional (3): fi-kbl-soraka fi-hsw-4770 fi-bxt-dsi
Missing(1): fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108887v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- {bat-dg2-11}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_108887v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271]) +9 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +12 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3012])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1072]) +3
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][11] ([fdo#109295] / [i915#3301])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][12] ([i915#6641])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][13] ([i915#2867]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][15] ([i915#6816]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12174/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v2/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.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#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2
[Intel-gfx] ✓ Fi.CI.BAT: success for Add SLPC selftest live_slpc_power (rev2)
== Series Details == Series: Add SLPC selftest live_slpc_power (rev2) URL : https://patchwork.freedesktop.org/series/108900/ State : success == Summary == CI Bug Log - changes from CI_DRM_12174 -> Patchwork_108900v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/index.html Participating hosts (42 -> 46) -- Additional (5): fi-kbl-soraka fi-cml-u2 fi-bxt-dsi fi-icl-u2 fi-hsw-4770 Missing(1): fi-bdw-samus Known issues Here are the changes found in Patchwork_108900v2 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@bcs0: - fi-cml-u2: NOTRUN -> [SKIP][1] ([i915#1208]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@gem_huc_c...@huc-copy.html - fi-cml-u2: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@gem_huc_c...@huc-copy.html - fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-cml-u2: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@gem_lmem_swapp...@parallel-random-engines.html - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html * igt@gem_softpin@allocator-basic-reserve: - fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271]) +9 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html * igt@gem_tiled_blits@basic: - fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271]) +12 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3012]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_heartbeat: - fi-bxt-dsi: NOTRUN -> [DMESG-FAIL][11] ([i915#5334]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html - fi-cml-u2: NOTRUN -> [SKIP][13] ([fdo#109284] / [fdo#111827]) +8 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-bxt-dsi: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#111827]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-cml-u2: NOTRUN -> [SKIP][16] ([i915#4213]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html - fi-icl-u2: NOTRUN -> [SKIP][17] ([i915#4103]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-connector-state: - fi-icl-u2: NOTRUN -> [WARN][18] ([i915#6008]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108900v2/fi-icl-u2/igt@kms_force_connector_ba...@force-connector-state.html * igt@kms_force_connector_basic@force-load-detect: - fi-cml-u2: NOTRUN -> [SKIP][19] ([fdo#109285]) [19]
[Intel-gfx] [PATCH] drm/i915: Stop using flush_scheduled_work on driver remove
From: Tvrtko Ursulin Kernel is trying to eliminate callers of flush_scheduled_work so lets try to accommodate. We currently call it from intel_modeset_driver_remove_noirq on the driver remove path but the comment next to it does not tell me what exact work it wants to flush. I can spot three (or four) works using the system_wq: ..hotplug.reenable_work ..hotplug.hotplug_work ..psr.dc3co_work ..crtc->drrs.work So if I replace it with intel_hpd_cancel_work() that appears would handle the first two. What about the other two? Signed-off-by: Tvrtko Ursulin Cc: Jani Nikula Cc: Ville Syrjälä Cc: Tetsuo Handa --- I am clueless about the display paths and only send this because Jani convinced me to send a patch to kick off the discussion. No expectations whatsoever this is correct or complete. --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 2d0018ae34b1..0eb72530a003 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -8980,7 +8980,7 @@ void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915) intel_unregister_dsm_handler(); /* flush any delayed tasks or pending work */ - flush_scheduled_work(); + intel_hpd_cancel_work(i915); intel_hdcp_component_fini(i915); -- 2.34.1
[Intel-gfx] [PATCH] drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
We had already grabbed the rpm wakeref at obj destruction path,
but it also required to grab the wakeref when object moves.
When i915_gem_object_release_mmap_offset() gets called by
i915_ttm_move_notify(), it will release the mmap offset without
grabbing the wakeref. We want to avoid that therefore,
grab the wakreref at i915_ttm_unmap_virtual() accordingly.
While doing that also changed the lmem_userfault_lock from
mutex to spinlock, as spinlock widely used for list.
Also changed if (obj->userfault_count) to
GEM_BUG_ON(!obj->userfault_count).
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Suggested-by: Matthew Auld
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 +---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 39
drivers/gpu/drm/i915/gt/intel_gt.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
4 files changed, 45 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 73d9eda1d6b7..9da561c19a47 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -557,11 +557,13 @@ void
i915_gem_object_runtime_pm_release_mmap_offset(struct drm_i915_gem_object *
drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
- if (obj->userfault_count) {
- /* rpm wakeref provide exclusive access */
- list_del(&obj->userfault_link);
- obj->userfault_count = 0;
- }
+ /*
+* We have exclusive access here via runtime suspend. All other callers
+* must first grab the rpm wakeref.
+*/
+ GEM_BUG_ON(!obj->userfault_count);
+ list_del(&obj->userfault_link);
+ obj->userfault_count = 0;
}
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
@@ -587,13 +589,6 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_lock(&obj->mmo.lock);
}
spin_unlock(&obj->mmo.lock);
-
- if (obj->userfault_count) {
- mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
- list_del(&obj->userfault_link);
-
mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
- obj->userfault_count = 0;
- }
}
static struct i915_mmap_offset *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..0630eeca7316 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -509,18 +509,9 @@ static int i915_ttm_shrink(struct drm_i915_gem_object
*obj, unsigned int flags)
static void i915_ttm_delete_mem_notify(struct ttm_buffer_object *bo)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- intel_wakeref_t wakeref = 0;
if (bo->resource && likely(obj)) {
- /* ttm_bo_release() already has dma_resv_lock */
- if (i915_ttm_cpu_maps_iomem(bo->resource))
- wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
-
__i915_gem_object_pages_fini(obj);
-
- if (wakeref)
-
intel_runtime_pm_put(&to_i915(obj->base.dev)->runtime_pm, wakeref);
-
i915_ttm_free_cached_io_rsgt(obj);
}
}
@@ -1052,12 +1043,15 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
goto out_rpm;
- /* ttm_bo_vm_reserve() already has dma_resv_lock */
+ /*
+* ttm_bo_vm_reserve() already has dma_resv_lock.
+* userfault_count is protected by dma_resv lock and rpm wakeref.
+*/
if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) {
obj->userfault_count = 1;
- mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+ spin_lock(to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
list_add(&obj->userfault_link,
&to_gt(to_i915(obj->base.dev))->lmem_userfault_list);
-
mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+ spin_unlock(to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
}
if (wakeref & CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
@@ -1123,7 +1117,28 @@ static u64 i915_ttm_mmap_offset(struct
drm_i915_gem_object *obj)
static void i915_ttm_unmap_virtual(struct drm_i915_gem_object *obj)
{
+ struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ intel_wakeref_t wakeref = 0;
+
+ assert_object_held_shared(obj);
+
+ if (i915_ttm_cpu_maps_iomem(bo->resource)) {
+ wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
+
+ /* userfault_count is protected by obj lock and rpm wakeref. */
[Intel-gfx] [PATCH v3] drm/i915: Improve debug print in vm_fault_ttm
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
v3: Fix dim checkpatch warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..3dc6acfcf4ec 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,8 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU
accessible(err = %pe)\n",
+ ERR_PTR(err));
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
--
2.37.3
Re: [Intel-gfx] [PATCH v2] drm/i915: Improve debug print in vm_fault_ttm
On 23.09.2022 10:45, Nirmoy Das wrote:
Print the error code returned by __i915_ttm_migrate()
for better debuggability.
v2: Fix kernel test robot warning.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6889
Acked-by: Matthew Auld
Signed-off-by: Nirmoy Das ---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index e3fc38dd5db0..55455321f652 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1034,7 +1034,7 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
}
if (err) {
- drm_dbg(dev, "Unable to make resource CPU
accessible\n");
+ drm_dbg(dev, "Unable to make resource CPU accessible(err =
%pe)\n", ERR_PTR(err));
Reviewed-by: Andrzej Hajda
Regards
Andrzej
dma_resv_unlock(bo->base.resv);
ret = VM_FAULT_SIGBUS;
goto out_rpm;
Re: [Intel-gfx] [PATCH 5/7] drm/i915/mtl: Handle wopcm per-GT and limit calculations.
On 9/23/2022 2:24 AM, Jani Nikula wrote:
On Thu, 22 Sep 2022, Daniele Ceraolo Spurio
wrote:
From: Aravind Iddamsetty
With MTL standalone media architecture the wopcm layout has changed with
separate partitioning in WOPCM for GCD/GT GuC and SA Media GuC. The size
of WOPCM is 4MB with lower 2MB for SA Media and upper 2MB for GCD/GT.
+=+===> ++ <== WOPCM TOP
^ ^ ||
| | ||
|GCD| GCD RC6 Image|
|GuC|Power Context |
|WOPCM ||
|Size ++
| | | GCD GuC Image|
| | ||
| v ||
| +===> ++ <== SA Media GuC WOPCM Top
| ^ ||
| SA Media||
|GuC| SA Media RC6 Image |
| WOPCM |Power Context |
|Size ||
WOPCM | ++
| | ||
| | | SA Media GuC Image |
| v ||
| +===> ++ <== GuC WOPCM base
| | WOPCM RSVD |
| +--- + <== HuC Firmware Top
v | HuC FW|
+=> ++ <== WOPCM Base
Given that MTL has GuC deprivilege, the WOPCM registers are pre-locked
by the bios. Therefore, we can skip all the math for the partitioning
and just limit ourselves to sanity checking the values.
Signed-off-by: Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 7 +--
drivers/gpu/drm/i915/gt/intel_ggtt.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 2 +
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c | 48 +++--
drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h | 0
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 4 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c| 14 +++---
drivers/gpu/drm/i915/i915_driver.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 3 --
drivers/gpu/drm/i915/i915_gem.c | 5 ++-
11 files changed, 56 insertions(+), 32 deletions(-)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.c (86%)
rename drivers/gpu/drm/i915/{ => gt}/intel_wopcm.h (100%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..6ed4c745b226 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -129,7 +129,9 @@ gt-y += \
gt/intel_timeline.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
- gt/sysfs_engines.o
+ gt/sysfs_engines.o \
+ gt/intel_wopcm.o
The comment near the top of the file:
# Please keep these build lists sorted!
D'oh! My monkey brain saw that "wopcm" was correctly ordered after
"engines" and completely ignored the first part of the name :/
Will fix next rev.
Daniele
+
# x86 intel-gtt module support
gt-$(CONFIG_X86) += gt/intel_ggtt_gmch.o
# autogenerated null render state
@@ -183,8 +185,7 @@ i915-y += \
i915_trace_points.o \
i915_ttm_buddy_manager.o \
i915_vma.o \
- i915_vma_resource.o \
- intel_wopcm.o
+ i915_vma_resource.o
# general-purpose microcontroller (GuC) support
i915-y += gt/uc/intel_uc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 30cf5c3369d9..605e1aa674d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -560,7 +560,7 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* why.
*/
ggtt->pin_bias = max_t(u32, I915_GTT_PAGE_SIZE,
- intel_wopcm_guc_size(&ggtt->vm.i915->wopcm));
+ intel_wopcm_guc_size(&ggtt->vm.gt->wopcm));
ret = intel_vgt_balloon(ggtt);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b367cfff48d5..a95eb0b656d2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -56,6 +56,7 @@ void intel_gt_common_init_early(struct intel_gt *gt)
seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
intel_gt_pm_init_early(gt);
+ intel_wopcm_init_early(>->wopcm);
intel_uc_init_early(>->uc);
intel_rps_init_early(>->rps);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f19c2de77ff6..c20a32d2700f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -30,6 +30,7 @@
#include "intel_migrate_types.h"
#include "intel_wakeref.h"
#include "px
Re: [Intel-gfx] [PATCH 1/7] drm/i915/huc: only load HuC on GTs that have VCS engines
On 9/23/2022 3:53 AM, Tvrtko Ursulin wrote:
On 22/09/2022 23:11, Daniele Ceraolo Spurio wrote:
On MTL the primary GT doesn't have any media capabilities, so no video
engines and no HuC. We must therefore skip the HuC fetch and load on
that specific case. Given that other multi-GT platforms might have HuC
on the primary GT, we can't just check for that and it is easier to
instead check for the lack of VCS engines.
Based on code from Aravind Iddamsetty
Signed-off-by: Daniele Ceraolo Spurio
Cc: Aravind Iddamsetty
Cc: John Harrison
Cc: Alan Previn
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 21 +
drivers/gpu/drm/i915/i915_drv.h | 9 ++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 3bb8838e325a..d4e2b252f16c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -42,12 +42,33 @@
* HuC-specific commands.
*/
+static bool vcs_supported(struct intel_gt *gt)
+{
+ intel_engine_mask_t mask = gt->info.engine_mask;
+
+ /*
+ * we can reach here from i915_driver_early_probe for primary
+ * GT with it being not fully setup hence fall back to the
device info's
+ * engine mask
+ */
+ if (!mask && gt_is_root(gt))
+ mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
Is it possible for all instances to be fused off? Wondering if the
function shouldn't just use platform_engine_mask.
The spec says that there is always going to be at least 1 VCS (bspec
55417 in case you want to double-check). I don't see that changing in
the future, because what's the point of having a media GT if you don't
have any enabled VCS engines on it?
Also, platform_engine_mask only contains the entries of the primary GT,
for the other GTs we'd have to navigate the array in the device info
structure and I don't think we want to do that from here when we've
already copied the mask inside gt->info.engine_mask.
Daniele
Regards,
Tvrtko
+
+ return __ENGINE_INSTANCES_MASK(mask, VCS0, I915_MAX_VCS);
+}
+
void intel_huc_init_early(struct intel_huc *huc)
{
struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
+ struct intel_gt *gt = huc_to_gt(huc);
intel_uc_fw_init_early(&huc->fw, INTEL_UC_FW_TYPE_HUC);
+ if (!vcs_supported(gt)) {
+ intel_uc_fw_change_status(&huc->fw,
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+ return;
+ }
+
if (GRAPHICS_VER(i915) >= 11) {
huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO;
huc->status.mask = HUC_LOAD_SUCCESSFUL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..8ca575202e5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -777,12 +777,15 @@ IS_SUBPLATFORM(const struct drm_i915_private
*i915,
#define __HAS_ENGINE(engine_mask, id) ((engine_mask) & BIT(id))
#define HAS_ENGINE(gt, id) __HAS_ENGINE((gt)->info.engine_mask, id)
-#define ENGINE_INSTANCES_MASK(gt, first, count) ({ \
+#define __ENGINE_INSTANCES_MASK(mask, first, count) ({ \
unsigned int first__ = (first); \
unsigned int count__ = (count); \
- ((gt)->info.engine_mask & \
- GENMASK(first__ + count__ - 1, first__)) >> first__; \
+ ((mask) & GENMASK(first__ + count__ - 1, first__)) >> first__; \
})
+
+#define ENGINE_INSTANCES_MASK(gt, first, count) \
+ __ENGINE_INSTANCES_MASK((gt)->info.engine_mask, first, count)
+
#define RCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, RCS0, I915_MAX_RCS)
#define BCS_MASK(gt) \
[Intel-gfx] [PATCH i-g-t] gem_ctx_persistence: adjust reset timeout
Tests on DG2 show that context cancel can take even 350ms,
due to error state capturing in guc_handle_context_reset.
Since it happens only in debug mode and tests runs in debug mode
it should be fine to adjust the timeout.
Let's double this value, to be on safe side.
It should fix multiple test timeout failures.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5891
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3952
Signed-off-by: Andrzej Hajda
---
tests/i915/gem_ctx_persistence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_persistence.c b/tests/i915/gem_ctx_persistence.c
index 50196edb19f..a844439de19 100644
--- a/tests/i915/gem_ctx_persistence.c
+++ b/tests/i915/gem_ctx_persistence.c
@@ -1214,7 +1214,7 @@ static void do_test(void (*test)(int i915, const
intel_ctx_cfg_t *cfg,
if (timeout != -1) {
igt_require(gem_engine_property_printf(i915, name,
ATTR, "%d", 50) > 0);
- reset_timeout_ms = 200;
+ reset_timeout_ms = 700;
}
test(i915, cfg, engine);
--
2.34.1
Re: [Intel-gfx] [PATCH i-g-t] tests/i915/gem_ctx_persistence: adjust saturated-hostile test timeout
On 22.09.2022 10:13, Andrzej Hajda wrote:
GPU occasionally can hang during saturated-hostile test. Detection of
such case and reset can take up to 5 seconds. While at it fix typo in
definition of RESET_TIMEOUT_MS.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1551
Signed-off-by: Andrzej Hajda
Please ignore the patch, it has been superseded by:
https://patchwork.freedesktop.org/patch/504450/
Regards
Andrzej
---
tests/i915/gem_ctx_persistence.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_ctx_persistence.c b/tests/i915/gem_ctx_persistence.c
index 50196edb19f..603fdd84438 100644
--- a/tests/i915/gem_ctx_persistence.c
+++ b/tests/i915/gem_ctx_persistence.c
@@ -46,7 +46,8 @@
#include "intel_allocator.h"
#include "sw_sync.h"
-#define RESET_TIMEOUT_MS 2 * MSEC_PER_SEC; /* default: 640ms */
+#define RESET_TIMEOUT_MS (2 * MSEC_PER_SEC) /* default: 640ms */
+#define RESET_TIMEOUT_GPU_HANG_MS (1 * MSEC_PER_SEC)
static unsigned long reset_timeout_ms = RESET_TIMEOUT_MS;
#define NSEC_PER_MSEC (1000 * 1000ull)
@@ -370,7 +371,7 @@ static void test_nohangcheck_hostile(int i915, const intel_ctx_cfg_t *cfg)
igt_require(__enable_hangcheck(dir, false));
for_each_ctx_cfg_engine(i915, cfg, e) {
- int64_t timeout = 1 * NSEC_PER_MSEC;
+ int64_t timeout = RESET_TIMEOUT_GPU_HANG_MS;
const intel_ctx_t *ctx = intel_ctx_create(i915, cfg);
uint64_t ahnd = get_reloc_ahnd(i915, ctx->id);
igt_spin_t *spin;
@@ -951,7 +952,7 @@ test_saturated_hostile_all(int i915, const intel_ctx_t
*base_ctx,
intel_ctx_destroy(i915, ctx);
/* Hostile request requires a GPU reset to terminate */
- igt_assert_eq(wait_for_status(spin->out_fence, reset_timeout_ms), -EIO);
+ igt_assert_eq(wait_for_status(spin->out_fence,
RESET_TIMEOUT_GPU_HANG_MS), -EIO);
/* All other spinners should be left unharmed */
gem_quiescent_gpu(i915);
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop using flush_scheduled_work on driver remove
== Series Details ==
Series: drm/i915: Stop using flush_scheduled_work on driver remove
URL : https://patchwork.freedesktop.org/series/108970/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12175 -> Patchwork_108970v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/index.html
Participating hosts (46 -> 44)
--
Missing(2): fi-icl-u2 fi-tgl-dsi
Known issues
Here are the changes found in Patchwork_108970v1 that come from known issues:
### IGT changes ###
Issues hit
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][1] -> [FAIL][2] ([i915#6298])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][3] ([i915#2867]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
- {bat-adlm-1}: [DMESG-WARN][5] ([i915#2867]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-hsw-4770:[DMESG-FAIL][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5828]: https://gitlab.freedesktop.org/drm/intel/issues/5828
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12175 -> Patchwork_108970v1
CI-20190529: 20190529
CI_DRM_12175: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108970v1: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
36d2561cb127 drm/i915: Stop using flush_scheduled_work on driver remove
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108970v1/index.html
Re: [Intel-gfx] [PATCH] drm/i915: Stop using flush_scheduled_work on driver remove
On Fri, Sep 23, 2022 at 03:29:34PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Kernel is trying to eliminate callers of flush_scheduled_work so lets > try to accommodate. > > We currently call it from intel_modeset_driver_remove_noirq on the driver > remove path but the comment next to it does not tell me what exact work it > wants to flush. > > I can spot three (or four) works using the system_wq: > > ..hotplug.reenable_work > ..hotplug.hotplug_work Looks like we at least try to shoot those down via intel_irq_uninstall() ->intel_hpd_cancel_work() ->cancel_delayed_work_sync() But I'm not sure how broken the hpd disable path is here. I know hpd cancel vs. irq disable has some known ordering issues during suspend at least, some of which I think may have gotten fixed recently. But hpd cancel is still a bit of a mess in general. Here we at least do cancel all the hpd works after irqs have been disabled, so I don't think any further flushing should help with whatever races we have left in there. > ..psr.dc3co_work I think the whole dc3co thing should be disabled atm, so nothing should ever schedule this. We should probably garbage collect the whole thing... > ..crtc->drrs.work That one should have been killed in intel_display_driver_unregister() ->drm_atomic_helper_shutdown() ->... ->intel_drrs_deactivate() ->cancel_delayed_work_sync() > So if I replace it with intel_hpd_cancel_work() that appears would handle > the first two. What about the other two? Other stuff that comes to mind is the pps vdd_off work. But looks like that should get taken down in the encoder->destroy() hook at the latest (via intel_mode_config_cleanup()). psr.work at least has a cancel_work_sync() in intel_psr_disable(), so should hopefully get killed the same way as drrs. opregion.asle_work seems to get cancelled from the unregister path. The ones that look broken to me are dmc.work and fbc underrun_work. > > Signed-off-by: Tvrtko Ursulin > Cc: Jani Nikula > Cc: Ville Syrjälä > Cc: Tetsuo Handa > --- > I am clueless about the display paths and only send this because Jani > convinced me to send a patch to kick off the discussion. No expectations > whatsoever this is correct or complete. > --- > drivers/gpu/drm/i915/display/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 2d0018ae34b1..0eb72530a003 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -8980,7 +8980,7 @@ void intel_modeset_driver_remove_noirq(struct > drm_i915_private *i915) > intel_unregister_dsm_handler(); > > /* flush any delayed tasks or pending work */ > - flush_scheduled_work(); > + intel_hpd_cancel_work(i915); > > intel_hdcp_component_fini(i915); > > -- > 2.34.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Tuesday, September 20, 2022 2:59 PM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > -Original Message- > > > From: Ville Syrjälä > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > To: Srivatsa, Anusha > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > ; Vivi, Rodrigo > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > This is a prep series for the actual cdclk refactoring that will > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > holds the following: > > > > - cdclk action (squash, crawl or modeset) > > > > - cdclk frequency > > > > which gets populated in atomic check. Driver uses the populated > > > > values during atomic commit to do the suitable sequence of actions > > > > like programming squash ctl registers in case of squashing or PLL > > > > sequence incase of modeset and so on. > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > in the atomic commit phase will be sent shortly. > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > quickly. This to me seems like the most straightforward way to do what > we need: > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > approach should produce sane values. > > Ville, > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > purpose? > > You either > - start at old, crawl to mid, then squash to new > - start at old, squash to mid, then crawl to new Tested the changes on TGL(legacy) and DG2(squash). Took some time to understand the code but the mid cdclk config logic works. @Ville Syrjälä does replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your new cdclk_crawl_and_squash in atomic check make sense? Anusha > -- > Ville Syrjälä > Intel
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Series Details == Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual URL : https://patchwork.freedesktop.org/series/108972/ State : warning == Summary == Error: dim checkpatch failed 09fac79aedc6 drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual -:122: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #122: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1136: + + } -:148: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #148: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:74: + gt->lmem_userfault_lock = drmm_kzalloc(&i915->drm, sizeof(*gt->lmem_userfault_lock), GFP_KERNEL); -:160: WARNING:LONG_LINE: line length of 101 exceeds 100 columns #160: FILE: drivers/gpu/drm/i915/gt/intel_gt.c:821: + sizeof(*gt->lmem_userfault_lock), GFP_KERNEL); -:176: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #176: FILE: drivers/gpu/drm/i915/gt/intel_gt_types.h:156: + spinlock_t *lmem_userfault_lock; total: 0 errors, 2 warnings, 2 checks, 132 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Series Details == Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual URL : https://patchwork.freedesktop.org/series/108972/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Series Details ==
Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
URL : https://patchwork.freedesktop.org/series/108972/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12175 -> Patchwork_108972v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/index.html
Participating hosts (46 -> 45)
--
Missing(1): fi-tgl-dsi
Known issues
Here are the changes found in Patchwork_108972v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u: [PASS][1] -> [INCOMPLETE][2] ([i915#146] /
[i915#6712])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}: [DMESG-WARN][3] ([i915#2867]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-hsw-4770:[DMESG-FAIL][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5886]: https://gitlab.freedesktop.org/drm/intel/issues/5886
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6712]: https://gitlab.freedesktop.org/drm/intel/issues/6712
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12175 -> Patchwork_108972v1
CI-20190529: 20190529
CI_DRM_12175: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108972v1: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
26360024b21d drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v1/index.html
Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Read graphics/media/display arch version from hw
On Thu, Sep 15, 2022 at 06:46:46PM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
Going forward, the hardware teams no longer consider new platforms to
have a "generation" in the way we've defined it for past platforms.
Instead, each IP block (graphics, media, display) will have their own
architecture major.minor versions and stepping ID's which should be read
directly from a register in the MMIO space. New hardware programming
styles, features, and workarounds should be conditional solely on the
architecture version, and should no longer be derived from the PCI
device ID, revision ID, or platform-specific feature flags.
I'd just remove "New hardware programming ..." until the end, because:
1) Binding to the device will always happen by using the PCI ID.
2) I don't see us moving away from grouping them per-platform.
3) Flags may still be convenient to convey paths to take in the software
regardless of what the hardware provides.
Basically there is a new way to read the individual IP versions: we
didn't have that before and we were just hardcoding the info per
platform. And the new scheme for reading the stepping replaces what we
were reading before from PCI config space.
Bspec: 63361, 64111
v2:
- Move the IP version readout to intel_device_info.c
- Convert the macro into a function
v3:
- Move subplatform init to runtime early init
- Cache runtime ver, release info to compare with hardware values.
- Use IP_VER for snaity check(MattR)
v4:
- Minor doccumentation changes.
- Normalize HAS_GMD_ID macro value.(JaniN)
Signed-off-by: Matt Roper
Signed-off-by: Rodrigo Vivi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 +
drivers/gpu/drm/i915/i915_driver.c | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_device_info.c | 67 +++-
drivers/gpu/drm/i915/intel_device_info.h | 12 -
7 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 2275ee47da95..2d2044f2ed9d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -39,6 +39,8 @@
#define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0xd84)
#define FORCEWAKE_ACK_MEDIA_GEN9_MMIO(0xd88)
+#define GMD_ID_GRAPHICS_MMIO(0xd8c)
+
#define MCFG_MCR_SELECTOR _MMIO(0xfd0)
#define SF_MCR_SELECTOR _MMIO(0xfd8)
#define GEN8_MCR_SELECTOR _MMIO(0xfdc)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index c459eb362c47..e86798eaecb6 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -337,7 +337,8 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
if (i915_inject_probe_failure(dev_priv))
return -ENODEV;
- intel_device_info_subplatform_init(dev_priv);
+ intel_device_info_runtime_init_early(dev_priv);
+
intel_step_init(dev_priv);
intel_uncore_mmio_debug_init_early(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9f9372931fd2..7034ea848d65 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -940,6 +940,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
+#define HAS_GMD_ID(i915) (INTEL_INFO(i915)->has_gmd_id)
+
#define HAS_LSPCON(dev_priv) (IS_DISPLAY_VER(dev_priv, 9, 10))
#define HAS_L3_CCS_READ(i915) (INTEL_INFO(i915)->has_l3_ccs_read)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..cace897e1db1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1143,6 +1143,7 @@ static const struct intel_device_info mtl_info = {
.display.has_modular_fia = 1,
.extra_gt_list = xelpmp_extra_gt,
.has_flat_ccs = 0,
+ .has_gmd_id = 1,
heh... this basically proves what I just said above ;)
.has_snoop = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a9bd829fc7e..acfcd155c8d0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5839,6 +5839,11 @@
#define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz (1 << 29)
#define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz (2 << 29)
+#define GMD_ID_DISPLAY _MMIO(0x510a0)
+#define GMD_ID_ARCH_MASK REG_GENMASK(31, 22)
+#define GMD_ID_RELEASE_MASK REG_GENMASK(21, 14)
+#define GMD_ID_
Re: [Intel-gfx] [PATCH v6 2/3] drm/i915: Parse and set stepping for platforms with GMD
On Thu, Sep 15, 2022 at 06:46:47PM -0700, Radhakrishna Sripada wrote:
From: José Roberto de Souza
Expand the current stepping convention to accommodate the GMD
stepping info. Typically GMD step maps to letter stepping
by "A + step %4" and number to "A + step /4" i.e, GMD step
0 maps to STEP_A0, 1 to _A1, 2 to _A2, 3 to _A3, 4 to STEP_B0...
Future platforms might break this formulae and may require a table
mapping to decode GMD step compatible with the convention.
v2:
- Pass the updated ip version structure
v3:
- Skip using GMD to step table(MattR)
Cc: Balasubramani Vivekanandan
Cc: Matt Roper
Signed-off-by: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_step.c | 25 +
drivers/gpu/drm/i915/intel_step.h | 24 +++-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_step.c
b/drivers/gpu/drm/i915/intel_step.c
index 42b3133d8387..91e7c51991b0 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -135,6 +135,19 @@ static const struct intel_step_info adlp_n_revids[] = {
[0x0] = { COMMON_GT_MEDIA_STEP(A0), .display_step = STEP_D0 },
};
+static u8 gmd_to_intel_step(struct drm_i915_private *i915,
+ struct ip_version *gmd)
+{
+ u8 step = gmd->step + STEP_A0;
+
+ if (step >= STEP_FUTURE) {
+ drm_dbg(&i915->drm, "Using future steppings\n");
+ return STEP_FUTURE;
+ }
+
+ return step;
+}
+
static void pvc_step_init(struct drm_i915_private *i915, int pci_revid);
void intel_step_init(struct drm_i915_private *i915)
@@ -144,6 +157,18 @@ void intel_step_init(struct drm_i915_private *i915)
int revid = INTEL_REVID(i915);
struct intel_step_info step = {};
+ if (HAS_GMD_ID(i915)) {
+ step.graphics_step = gmd_to_intel_step(i915,
+
&RUNTIME_INFO(i915)->graphics.ip);
+ step.media_step = gmd_to_intel_step(i915,
+
&RUNTIME_INFO(i915)->media.ip);
+ step.display_step = gmd_to_intel_step(i915,
+
&RUNTIME_INFO(i915)->display.ip);
+ RUNTIME_INFO(i915)->step = step;
+
+ return;
+ }
+
if (IS_PONTEVECCHIO(i915)) {
pvc_step_init(i915, revid);
return;
diff --git a/drivers/gpu/drm/i915/intel_step.h
b/drivers/gpu/drm/i915/intel_step.h
index a6b12bfa9744..57b9928ddca6 100644
--- a/drivers/gpu/drm/i915/intel_step.h
+++ b/drivers/gpu/drm/i915/intel_step.h
@@ -23,21 +23,43 @@ struct intel_step_info {
missing comment in this struct that it's expected to have 4 number steps
per letter. I don't want someone to add a stepping B4 in future without
realizing that will render gmd_to_intel_step() invalid
with that added: Reviewed-by: Lucas De Marchi
Lucas De Marchi
Re: [Intel-gfx] [PATCH] drm/i915/dg2: introduce Wa_22015475538
On Tue, Sep 20, 2022 at 01:43:59PM -0700, Matt Atwood wrote:
> Wa_22015475538 applies to all DG2 (and ATSM) skus. The workaround
> implementation is identical to Wa_16011620976. LSC_CHICKEN_BIT_0_UDW is
> a general render register instead of rcs so adding this move to the
> proper wa init function.
>
> bspec:54077
>
> Signed-off-by: Matt Atwood
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 6d2003d598e6..c16e9e3f0d6c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2108,9 +2108,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0)) {
> /* Wa_14013392000:dg2_g11 */
> wa_masked_en(wal, GEN7_ROW_CHICKEN2,
> GEN12_ENABLE_LARGE_GRF_MODE);
> -
> - /* Wa_16011620976:dg2_g11 */
> - wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
> }
>
> if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_FOREVER) ||
> @@ -2780,6 +2777,14 @@ general_render_compute_wa_init(struct intel_engine_cs
> *engine, struct i915_wa_li
> wa_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
> wa_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
> }
> +
> + if (IS_DG2(i915)) {
> + /*
> + * Wa_16011620976:dg2_g11
> + * Wa_22015475538:dg2
> + */
> + wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
> + }
> }
>
> static void
> --
> 2.37.3
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Don't use port enum as register offset (rev3)
== Series Details ==
Series: drm/i915/display: Don't use port enum as register offset (rev3)
URL : https://patchwork.freedesktop.org/series/108833/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108833v3_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108833v3_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_lease@lease_unleased_connector@pipe-a-hdmi-a-1:
- {shard-tglu}: [PASS][1] -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-tglu-4/igt@kms_lease@lease_unleased_connec...@pipe-a-hdmi-a-1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-tglu-2/igt@kms_lease@lease_unleased_connec...@pipe-a-hdmi-a-1.html
* igt@kms_lease@lease_unleased_connector@pipe-d-hdmi-a-1:
- {shard-tglu}: [PASS][3] -> [FAIL][4] +2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-tglu-4/igt@kms_lease@lease_unleased_connec...@pipe-d-hdmi-a-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-tglu-2/igt@kms_lease@lease_unleased_connec...@pipe-d-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_108833v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_buddy@all:
- shard-iclb: NOTRUN -> [SKIP][5] ([i915#6433])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@drm_bu...@all.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-tglb2/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs1:
- shard-iclb: NOTRUN -> [FAIL][14] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html
* igt@gem_exec_nop@basic-series:
- shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#118])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk1/igt@gem_exec_...@basic-series.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk3/igt@gem_exec_...@basic-series.html
* igt@gem_lmem_swapping@parallel-random-verify-ccs:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +3
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-apl8/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html
* igt@gem_pxp@reject-modify-context-protection-off-1:
- shard-iclb: NOTRUN -> [SKIP][18] ([i915#4270])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@gem_...@reject-modify-context-protection-off-1.html
* igt@gem_render_copy@linear-to-vebox-y-tiled:
- shard-iclb: NOTRUN -> [SKIP][19] ([i915#768])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-iclb2/igt@gem_render_c...@linear-to-vebox-y-tiled.html
* igt@gem_userptr_blits@access-control:
- shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271]) +4 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108833v3/shard-glk3/igt@gem_userptr_bl...@access-control.html
* igt@kms_big_fb@y-tiled-8bpp-rotate-270:
- shard-iclb: NOTRUN -> [SKIP][21] ([fdo#110725] / [fdo#111614])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_1
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: introduce Wa_22015475538
On Wed, Sep 21, 2022 at 12:19:05AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dg2: introduce Wa_22015475538
> URL : https://patchwork.freedesktop.org/series/108795/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12161_full -> Patchwork_108795v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_108795v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_108795v1_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Participating hosts (9 -> 11)
> --
>
> Additional (2): shard-rkl shard-tglu
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_108795v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_pm_rpm@reg-read-ioctl:
> - shard-tglb: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-tglb7/igt@i915_pm_...@reg-read-ioctl.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/shard-tglb8/igt@i915_pm_...@reg-read-ioctl.html
Random incomplete with no errors reported. Not related to this patch.
Applied to drm-intel-gt-next. Thanks for the patch.
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@kms_color@ctm-0-75@pipe-a-hdmi-a-1:
> - {shard-tglu}: NOTRUN -> [FAIL][3] +7 similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/shard-tglu-6/igt@kms_color@ctm-0...@pipe-a-hdmi-a-1.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_12161_full and
> Patchwork_108795v1_full:
>
> ### New IGT tests (2) ###
>
> * igt@kms_lease@lease_revoke@pipe-d-hdmi-a-1:
> - Statuses : 1 pass(s)
> - Exec time: [0.05] s
>
> * igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-1:
> - Statuses : 1 pass(s)
> - Exec time: [0.15] s
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_108795v1_full that come from known
> issues:
>
> ### CI changes ###
>
> Possible fixes
>
> * boot:
> - shard-glk: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
> [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
> [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
> [PASS][20], [PASS][21], [PASS][22], [PASS][23], [FAIL][24], [PASS][25],
> [PASS][26], [PASS][27], [PASS][28]) ([i915#4392]) -> ([PASS][29], [PASS][30],
> [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
> [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
> [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
> [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk2/boot.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk2/boot.html
>[21]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
>[22]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
>[23]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
>[24]
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve debug print in vm_fault_ttm (rev3)
== Series Details ==
Series: drm/i915: Improve debug print in vm_fault_ttm (rev3)
URL : https://patchwork.freedesktop.org/series/108887/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12175 -> Patchwork_108887v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/index.html
Participating hosts (46 -> 44)
--
Missing(2): fi-hsw-4770 fi-skl-6700k2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108887v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}: [INCOMPLETE][1] ([i915#2411]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/fi-tgl-dsi/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-2:
- {bat-dg2-11}: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-2.html
Known issues
Here are the changes found in Patchwork_108887v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][5] -> [FAIL][6] ([i915#6298])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][7] ([i915#4312])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@lmem0:
- {bat-dg2-11}: [DMESG-WARN][8] ([i915#6816]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12175/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/bat-dg2-11/igt@gem_exec_suspend@basic...@lmem0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6380]: https://gitlab.freedesktop.org/drm/intel/issues/6380
[i915#6816]: https://gitlab.freedesktop.org/drm/intel/issues/6816
[i915#6818]: https://gitlab.freedesktop.org/drm/intel/issues/6818
Build changes
-
* Linux: CI_DRM_12175 -> Patchwork_108887v3
CI-20190529: 20190529
CI_DRM_12175: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6662: dcb1d7a8822e62935f4fe3f2e6a04caaee669369 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_108887v3: a916f2c47c5965886be7a023eb78e67470237fe3 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
824c9b8b86b0 drm/i915: Improve debug print in vm_fault_ttm
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108887v3/index.html
Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not actively managing a known PCI device.
Rafael, could you please add your thoughts here?
On Thu, 2022-09-22 at 12:40 +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Gupta, Anshuman
> > Sent: Thursday, September 22, 2022 4:40 PM
> > To: Vivi, Rodrigo ; Tvrtko Ursulin
> >
> > Cc: Nikula, Jani ; intel-
> > g...@lists.freedesktop.org; Daniel
> > J Blueman ; Wysocki, Rafael J
> > ; sta...@vger.kernel.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow D3 when we are not
> > actively
> > managing a known PCI device.
> >
> >
> >
> > On 9/22/2022 3:13 PM, Rodrigo Vivi wrote:
> > > On Thu, Sep 22, 2022 at 08:56:00AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 21/09/2022 18:39, Rodrigo Vivi wrote:
> > > > > The force_probe protection actively avoids the probe of i915
> > > > > to
> > > > > manage a device that is currently under development. It is a
> > > > > nice
> > > > > protection for future users when getting a new platform but
> > > > > using
> > > > > some older kernel.
> > > > >
> > > > > However, when we avoid the probe we don't take back the
> > > > > registration
> > > > > of the device. We cannot give up the registration anyway
> > > > > since we
> > > > > can have multiple devices present. For instance an integrated
> > > > > and a
> > > > > discrete one.
> > > > >
> > > > > When this scenario occurs, the user will not be able to
> > > > > change any
> > > > > of the runtime pm configuration of the unmanaged device. So,
> > > > > it will
> > > > > be blocked in D0 state wasting power. This is specially bad
> > > > > in the
> > > > > case where we have a discrete platform attached, but the user
> > > > > is
> > > > > able to fully use the integrated one for everything else.
> > > > >
> > > > > So, let's put the protected and unmanaged device in D3. So we
> > > > > can
> > > > > save some power.
> > > > >
> > > > > Reported-by: Daniel J Blueman
> > > > > Cc: sta...@vger.kernel.org
> > > > > Cc: Daniel J Blueman
> > > > > Cc: Tvrtko Ursulin
> > > > > Cc: Anshuman Gupta
> > > > > Signed-off-by: Rodrigo Vivi
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_pci.c | 8
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > > > > b/drivers/gpu/drm/i915/i915_pci.c index
> > > > > 77e7df21f539..fc3e7c69af2a
> > > > > 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > > @@ -25,6 +25,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > #include "gt/intel_gt_regs.h"
> > > > > #include "gt/intel_sa_media.h"
> > > > > @@ -1304,6 +1305,7 @@ static int i915_pci_probe(struct
> > > > > pci_dev *pdev,
> > const struct pci_device_id *ent)
> > > > > {
> > > > > struct intel_device_info *intel_info =
> > > > > (struct intel_device_info *) ent-
> > > > > >driver_data;
> > > > > + struct device *kdev = &pdev->dev;
> > > > > int err;
> > > > > if (intel_info->require_force_probe && @@ -1314,6
> > > > > +1316,12 @@
> > > > > static int i915_pci_probe(struct pci_dev *pdev, const struct
> > > > > pci_device_id
> > *ent)
> > > > > "module parameter or
> > CONFIG_DRM_I915_FORCE_PROBE=%04x configuration option,\n"
> > > > > "or (recommended) check for kernel
> > > > > updates.\n",
> > > > > pdev->device, pdev->device, pdev-
> > > > > >device);
> > > > > +
> > > > > + /* Let's not waste power if we are not
> > > > > managing the device */
> > > > > + pm_runtime_use_autosuspend(kdev);
> > > > > + pm_runtime_allow(kdev);
> > > > > + pm_runtime_put_autosuspend(kdev);
> > AFAIK we don't need to enable autosuspend here,
> > pm_runtime_put_autosuspend() will cause a NULL pointer de-reference
> > as it will
> > immediately call the intel_runtime_suspend()(because we haven't
> > called the
> > pm_runtime_mark_last_busy) without initializing i915.
I don't see any null pointer dereference here.
The problem is exactly that we do the initialization and the we give up
on the
device and end up blocking the runtime pm in some state that we cannot
change.
> >
> > Having said that we only need below, in order to let pci core keep
> > the pci dev in
> > D3.
> >
> > pm_runtime_put_noidle()
as for this one here I get:
[ 9036.357078] i915 :03:00.0: Runtime PM usage count underflow!
>
> Hi Rodrigo ,
> It seems playing with these runtime hooks, will only enable the
> "runtime suspend"
> but actual state in "PMCSR" pci config is D0 despite device is
> runtime suspended, when there is no driver.
> Example:
> root@DUT2135-DG2MRB:/home/gta# cat
> /sys/bus/pci/devices/\:03\:00.0/power/runtime_status
> suspended
> root@DUT2135-DG2MRB:/home/gta# setpci -s 03:00.0 0xd4.l
> 0008
> (Bits 00:01 are the power state in PMCSR(offset = 4) config register
> from PM Cap offset at
[Intel-gfx] ✓ Fi.CI.IGT: success for Delay disabling GuC scheduling of an idle context
== Series Details == Series: Delay disabling GuC scheduling of an idle context URL : https://patchwork.freedesktop.org/series/108931/ State : success == Summary == CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108931v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108931v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_buddy@all: - shard-iclb: NOTRUN -> [SKIP][1] ([i915#6433]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@drm_bu...@all.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][2] -> [FAIL][3] ([i915#2846]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk5/igt@gem_exec_f...@basic-deadline.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-glk5/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_lmem_swapping@parallel-random-verify-ccs: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl3/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html * igt@gem_pxp@reject-modify-context-protection-off-1: - shard-iclb: NOTRUN -> [SKIP][9] ([i915#4270]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@gem_...@reject-modify-context-protection-off-1.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][10] ([i915#768]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@gen9_exec_parse@allowed-single: - shard-apl: NOTRUN -> [DMESG-WARN][11] ([i915#5566] / [i915#716]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl3/igt@gen9_exec_pa...@allowed-single.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl2/igt@i915_susp...@sysfs-reader.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl3/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@y-tiled-8bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][14] ([fdo#110725] / [fdo#111614]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@kms_big...@y-tiled-8bpp-rotate-270.html * igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs: - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#109278]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs.html * igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3886]) +5 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl2/igt@kms_ccs@pipe-c-bad-pixel-format-y_tiled_gen12_mc_ccs.html * igt@kms_color_chamelium@ctm-0-50: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl2/igt@kms_color_chamel...@ctm-0-50.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#4103]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-iclb8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#2346]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108931v1/shard-apl6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html * igt@kms_flip@2x-nonexisting-fb: - shard-apl: NOTRUN -> [SKIP][21] (
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
On Fri, Sep 23, 2022 at 04:56:53PM +, Srivatsa, Anusha wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, September 20, 2022 2:59 PM > > To: Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > ; Vivi, Rodrigo > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > > > > > > > -Original Message- > > > > From: Ville Syrjälä > > > > Sent: Tuesday, September 20, 2022 1:20 AM > > > > To: Srivatsa, Anusha > > > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > > > ; Vivi, Rodrigo > > > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > > > This is a prep series for the actual cdclk refactoring that will > > > > > be sent following this. Idea is to have a struct - cdclk_step that > > > > > holds the following: > > > > > - cdclk action (squash, crawl or modeset) > > > > > - cdclk frequency > > > > > which gets populated in atomic check. Driver uses the populated > > > > > values during atomic commit to do the suitable sequence of actions > > > > > like programming squash ctl registers in case of squashing or PLL > > > > > sequence incase of modeset and so on. > > > > > > > > > > This series just addresses the initial idea. The actual plumming > > > > > in the atomic commit phase will be sent shortly. > > > > > > > > OK, people keep ignoring what I say so I just typed up the code > > > > quickly. This to me seems like the most straightforward way to do what > > we need: > > > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > > > > > Totally untested ofc, apart from me doing a quick scan through our > > > > cdclk tables for the crawl+squahs platforms to make sure that this > > > > approach should produce sane values. > > > Ville, > > > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > > purpose? > > > > You either > > - start at old, crawl to mid, then squash to new > > - start at old, squash to mid, then crawl to new > > Tested the changes on TGL(legacy) and DG2(squash). Took some time to > understand the code but the mid cdclk config logic works. @Ville Syrjälä does > replacing the intel_cdclk_can_squash() and intel_cdclk_can_crawl() with your > new cdclk_crawl_and_squash in atomic check make sense? I don't think we should need any real logic at that point. If we can squash and crawl then I think we can always do the cdclk change w/o a modeset, at least with what we currently have defined in the cdclk tables. -- Ville Syrjälä Intel
[Intel-gfx] ✓ Fi.CI.IGT: success for Add PXP firmware respose on ARB failure
== Series Details == Series: Add PXP firmware respose on ARB failure URL : https://patchwork.freedesktop.org/series/108935/ State : success == Summary == CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108935v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_108935v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [FAIL][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22]) ([i915#5032]) -> ([PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl9/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl6/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl6/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl5/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl4/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl3/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl2/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl1/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl1/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl1/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl10/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl10/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-skl10/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl10/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl4/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl4/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl4/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl9/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl9/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl9/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl5/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl6/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108935v1/shard-skl6/boot.html [44]: h
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix a potential UAF at device unload
== Series Details == Series: series starting with [1/2] drm/i915: Fix a potential UAF at device unload URL : https://patchwork.freedesktop.org/series/108944/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12171_full -> Patchwork_108944v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108944v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108944v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108944v1_full: ### IGT changes ### Possible regressions * igt@gem_eio@hibernate: - shard-snb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-snb7/igt@gem_...@hibernate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-snb2/igt@gem_...@hibernate.html Known issues Here are the changes found in Patchwork_108944v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_buddy@all: - shard-iclb: NOTRUN -> [SKIP][3] ([i915#6433]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@drm_bu...@all.html * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-iclb1/igt@gem_exec_balan...@parallel-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk5/igt@gem_exec_f...@basic-deadline.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-glk1/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-glk8/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_lmem_swapping@parallel-random-verify-ccs: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl6/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html * igt@gem_pxp@reject-modify-context-protection-off-1: - shard-iclb: NOTRUN -> [SKIP][13] ([i915#4270]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@gem_...@reject-modify-context-protection-off-1.html * igt@gem_render_copy@linear-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][14] ([i915#768]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@gem_render_c...@linear-to-vebox-y-tiled.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12171/shard-apl2/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl2/igt@i915_susp...@sysfs-reader.html * igt@kms_big_fb@y-tiled-8bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][17] ([fdo#110725] / [fdo#111614]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@kms_big...@y-tiled-8bpp-rotate-270.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886]) +6 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-apl2/igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html * igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#109278]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108944v1/shard-iclb6/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs.html * igt@kms_chamelium@vga-
[Intel-gfx] [PATCH 0/7] drm/i915: Add HWMON support
This series adds the HWMON support for DGFX Test-with: 20220919144408.251981-1-riana.ta...@intel.com v2: - Reorganized series. Created first patch as infrastructure patch followed by feature patches. (Ashutosh) - Fixed review comments (Jani) - Fixed review comments (Ashutosh) v3: - Fixed review comments from Guenter - Exposed energy inferface as standard hwmon interface (Ashutosh) - For power interface added entries for critical power and maintained standard interface for all the entries except power1_max_interval - Extended support for XEHPSDV (Ashutosh) v4: - Fixed review comment from Guenter - Cleaned up unused code v5: - Fixed review comments (Jani) v6: - Fixed review comments (Ashutosh) - Updated date and kernel version in documentation v7: - Fixed review comments (Anshuman) - KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko) Ashutosh Dixit (2): drm/i915/hwmon: Expose card reactive critical power drm/i915/hwmon: Expose power1_max_interval Dale B Stimson (4): drm/i915/hwmon: Add HWMON infrastructure drm/i915/hwmon: Power PL1 limit and TDP setting drm/i915/hwmon: Show device level energy usage drm/i915/hwmon: Extend power/energy for XEHPSDV Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 75 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 762 ++ drivers/gpu/drm/i915/i915_hwmon.h | 21 + drivers/gpu/drm/i915/i915_reg.h | 6 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 21 + 9 files changed, 903 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h -- 2.25.1
[Intel-gfx] [PATCH 1/7] drm/i915/hwmon: Add HWMON infrastructure
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jani)
- Remove "select HWMON" from i915/Kconfig (Jani)
v3: Use hwm_ prefix for static functions (Ashutosh)
v4: s/#ifdef CONFIG_HWMON/#if IS_REACHABLE(CONFIG_HWMON)/ since the former
doesn't work if hwmon is compiled as a module (Guenter)
v5: Fixed review comments (Jani)
v6: s/kzalloc/devm_kzalloc/ (Andi)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
drivers/gpu/drm/i915/i915_hwmon.c | 131 +
drivers/gpu/drm/i915/i915_hwmon.h | 20 +
5 files changed, 161 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a26edcdadc21..66a6023e61a6 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -209,6 +209,9 @@ i915-y += gt/uc/intel_uc.o \
# graphics system controller (GSC) support
i915-y += gt/intel_gsc.o
+# graphics hardware monitoring (HWMON) support
+i915-$(CONFIG_HWMON) += i915_hwmon.o
+
# modesetting core code
i915-y += \
display/hsw_ips.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 9d1fc2477f80..ae0414037625 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -81,6 +81,7 @@
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_getparam.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_ioctl.h"
#include "i915_irq.h"
@@ -763,6 +764,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_register(gt);
+ i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -795,6 +798,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
for_each_gt(gt, dev_priv, i)
intel_gt_driver_unregister(gt);
+ i915_hwmon_unregister(dev_priv);
+
i915_perf_unregister(dev_priv);
i915_pmu_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 134fc1621821..3197aa9d35d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -350,6 +350,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt0;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..2847ca4e1a77
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "i915_reg.h"
+#include "intel_mchbar_regs.h"
+
+struct hwm_reg {
+};
+
+struct hwm_drvdata {
+ struct i915_hwmon *hwmon;
+ struct intel_uncore *uncore;
+ struct device *hwmon_dev;
+ char name[12];
+};
+
+struct i915_hwmon {
+ struct hwm_drvdata ddat;
+ struct mutex hwmon_lock;/* counter overflow logic and
rmw */
+ struct hwm_reg rg;
+};
+
+static const struct hwmon_channel_info *hwm_info[] = {
+ NULL
+};
+
+static umode_t
+hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (type) {
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+int channel, long *val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int
+hwm_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ switch (type) {
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static const struct hwmon_ops hwm_ops = {
+ .is_visible = hwm_is_visible,
+ .read = hwm_read,
+ .write = hwm_write,
+};
+
+static const struct hwmon_chip_info hwm_chip_info = {
+ .ops = &hwm_ops,
+ .info = hwm_info,
+};
+
+static void
+hwm_get_preregistration_info(struct drm_i915_private *i915)
+{
+}
+
+void i915_hwmon_register(struct
[Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm_ prefix for static functions (Ashutosh)
v5: Added unit of voltage as millivolts (Ashutosh)
v6: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Cc: Guenter Roeck
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ++
drivers/gpu/drm/i915/i915_hwmon.c | 53 +++
3 files changed, 63 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..cd9554c1a4f8
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,7 @@
+What: /sys/devices/.../hwmon/hwmon/in0_input
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 755a2c101269..c7639ae79a8f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1516,6 +1516,9 @@
#define VLV_RENDER_C0_COUNT_MMIO(0x138118)
#define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
+#define GEN12_RPSTAT1 _MMIO(0x1381b4)
+#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
+
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
#define GEN11_CSME (31)
#define GEN11_GUNIT (28)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 2847ca4e1a77..7b6de7b9c8b1 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,8 +11,16 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "gt/intel_gt_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - voltage - millivolts
+ */
+#define SF_VOLTAGE 1000
struct hwm_reg {
+ i915_reg_t gt_perf_status;
};
struct hwm_drvdata {
@@ -29,14 +37,49 @@ struct i915_hwmon {
};
static const struct hwmon_channel_info *hwm_info[] = {
+ HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
NULL
};
+static umode_t
+hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_input:
+ return i915_mmio_reg_valid(ddat->hwmon->rg.gt_perf_status) ?
0444 : 0;
+ default:
+ return 0;
+ }
+}
+
+static int
+hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ switch (attr) {
+ case hwmon_in_input:
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(ddat->uncore,
hwmon->rg.gt_perf_status);
+ /* HW register value in units of 2.5 millivolt */
+ *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
reg_value) * 25, 10);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
static umode_t
hwm_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -46,7 +89,11 @@ static int
hwm_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
int channel, long *val)
{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+
switch (type) {
+ case hwmon_in:
+ return hwm_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -76,6 +123,12 @@ static const struct hwmon_chip_info hwm_chip_info = {
static void
hwm_get_preregistration_info(struct drm_i915_private *i915)
{
+ struct i915_hwmon *hwmon = i915->hwmon;
+
+ if (IS_DG1(i915) || IS_DG2(i915))
+ hwmon->rg.gt_perf_status = GEN12_RPSTAT1;
+ else
+ hwmon->rg.gt_perf_status = INVALID_MMIO_REG;
}
void i915_hwmon_register(struct drm_i915_private *i915)
--
2.25.1
[Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
- Fix review comments (Jani)
- Remove endianness conversion (Ashutosh)
v3: Add power1_rated_max (Ashutosh)
v4:
- Use macro HWMON_CHANNEL_INFO to define power channel (Guenter)
- Update the date and kernel version in Documentation (Badal)
v5: Use hwm_ prefix for static functions (Ashutosh)
v6: Fix review comments (Ashutosh)
v7:
- Define PCU_PACKAGE_POWER_SKU for DG1,DG2 and move
PKG_PKG_TDP to intel_mchbar_regs.h (Anshuman)
- KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Cc: Guenter Roeck
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 +++
drivers/gpu/drm/i915/i915_hwmon.c | 158 +-
drivers/gpu/drm/i915/intel_mchbar_regs.h | 12 ++
3 files changed, 188 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index cd9554c1a4f8..16e697b1db3d 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -5,3 +5,23 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_rated_max
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7b6de7b9c8b1..5d2e68217e8c 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -16,11 +16,16 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
+ * - power - microwatts
*/
#define SF_VOLTAGE 1000
+#define SF_POWER 100
struct hwm_reg {
i915_reg_t gt_perf_status;
+ i915_reg_t pkg_power_sku_unit;
+ i915_reg_t pkg_power_sku;
+ i915_reg_t pkg_rapl_limit;
};
struct hwm_drvdata {
@@ -34,10 +39,68 @@ struct i915_hwmon {
struct hwm_drvdata ddat;
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
+ int scl_shift_power;
};
+static void
+hwm_locked_with_pm_intel_uncore_rmw(struct hwm_drvdata *ddat,
+ i915_reg_t reg, u32 clear, u32 set)
+{
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ intel_uncore_rmw(uncore, reg, clear, set);
+
+ mutex_unlock(&hwmon->hwmon_lock);
+}
+
+/*
+ * This function's return type of u64 allows for the case where the scaling
+ * of the field taken from the 32-bit register value might cause a result to
+ * exceed 32 bits.
+ */
+static u64
+hwm_field_read_and_scale(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+u32 field_msk, int nshift, u32 scale_factor)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgadr);
+
+ reg_value = REG_FIELD_GET(field_msk, reg_value);
+
+ return mul_u64_u32_shr(reg_value, scale_factor, nshift);
+}
+
+static void
+hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
+ u32 field_msk, int nshift,
+ unsigned int scale_factor, long lval)
+{
+ u32 nval;
+ u32 bits_to_clear;
+ u32 bits_to_set;
+
+ /* Computation in 64-bits to avoid overflow. Round to nearest. */
+ nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
+
+ bits_to_clear =
[Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2: Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 ++
drivers/gpu/drm/i915/i915_hwmon.c | 107 +-
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 116 insertions(+), 2 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 16e697b1db3d..7525db243d74 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 5d2e68217e8c..60da956fae0e 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -17,21 +17,30 @@
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_ENERGY 100
struct hwm_reg {
i915_reg_t gt_perf_status;
i915_reg_t pkg_power_sku_unit;
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
+ i915_reg_t energy_status_all;
+};
+
+struct hwm_energy_info {
+ u32 reg_val_prev;
+ long accum_energy; /* Accumulated energy for
energy1_input */
};
struct hwm_drvdata {
struct i915_hwmon *hwmon;
struct intel_uncore *uncore;
struct device *hwmon_dev;
+ struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
};
@@ -40,6 +49,7 @@ struct i915_hwmon {
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
+ int scl_shift_energy;
};
static void
@@ -98,9 +108,60 @@ hwm_field_scale_and_write(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * hwm_energy - Obtain energy value
+ *
+ * The underlying energy hardware register is 32-bits and is subject to
+ * overflow. How long before overflow? For example, with an example
+ * scaling bit shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and
+ * a power draw of 1000 watts, the 32-bit counter will overflow in
+ * approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ *
+ * The function significantly increases overflow duration (from 4.36
+ * minutes) by accumulating the energy register into a 'long' as allowed by
+ * the hwmon API. Using x86_64 128 bit arithmetic (see mul_u64_u32_shr()),
+ * a 'long' of 63 bits, SF_ENERGY of 1e6 (~20 bits) and
+ * hwmon->scl_shift_energy of 14 bits we have 57 (63 - 20 + 14) bits before
+ * energy1_input overflows. This at 1000 W is an overflow duration of 278
years.
+ */
+static int
+hwm_energy(struct hwm_drvdata *ddat, long *energy)
+{
+ struct intel_uncore *uncore = ddat->uncore;
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ struct hwm_energy_info *ei = &ddat->ei;
+ intel_wakeref_t wakeref;
+ i915_reg_t rgaddr;
+ u32 reg_val;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ mutex_lock(&hwmon->hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_val = intel_uncore_read(uncore, rgaddr);
+
+ if (reg_val >= ei->reg_val_prev)
+ ei->accum_energy += reg_val - ei->reg_val_prev;
+ else
+ ei->accum_energy += UINT_MAX - ei->reg_val_prev + reg_val;
+ ei->reg_val_prev = reg_val;
+
+ *energy = mul_u64_u32_shr(ei->accum_energy, SF_ENERGY,
+ hwmon->scl_shift_energy);
+ mutex_unlock(&hwmon->hwmon_lock);
+
+ return 0;
+}
+
stat
[Intel-gfx] [PATCH 5/7] drm/i915/hwmon: Expose card reactive critical power
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4: Use hwm_ prefix for static functions (Ashutosh)
v5: KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Cc: Sujaritha Sundaresan
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 26 +
drivers/gpu/drm/i915/i915_hwmon.c | 95 ++-
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 126 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7525db243d74..f9d6d3b08bba 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,32 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_crit
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in microwatts.
+
+ Card reactive critical (I1) power limit in microwatts is exposed
+ for client products. The power controller will throttle the
+ operating frequency if the power averaged over a window exceeds
+ this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/curr1_crit
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive critical (I1) power limit in milliamperes.
+
+ Card reactive critical (I1) power limit in milliamperes is
+ exposed for server products. The power controller will throttle
+ the operating frequency if the power averaged over a window
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/energy1_input
Date: February 2023
KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 60da956fae0e..f743ac5c59c4 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -11,16 +11,19 @@
#include "i915_hwmon.h"
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
+#include "intel_pcode.h"
#include "gt/intel_gt_regs.h"
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - voltage - millivolts
* - power - microwatts
+ * - curr - milliamperes
* - energy - microjoules
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
+#define SF_CURR1000
#define SF_ENERGY 100
struct hwm_reg {
@@ -160,11 +163,25 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
static const struct hwmon_channel_info *hwm_info[] = {
HWMON_CHANNEL_INFO(in, HWMON_I_INPUT),
- HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX),
+ HWMON_CHANNEL_INFO(power, HWMON_P_MAX | HWMON_P_RATED_MAX |
HWMON_P_CRIT),
HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ HWMON_CHANNEL_INFO(curr, HWMON_C_CRIT),
NULL
};
+/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
+static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
+{
+ return snb_pcode_read_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_READ_I1, 0, uval);
+}
+
+static int hwm_pcode_write_i1(struct drm_i915_private *i915, u32 uval)
+{
+ return snb_pcode_write_p(&i915->uncore, PCODE_POWER_SETUP,
+ POWER_SETUP_SUBCOMMAND_WRITE_I1, 0, uval);
+}
+
static umode_t
hwm_in_is_visible(const struct hwm_drvdata *ddat, u32 attr)
{
@@ -198,13 +215,18 @@ hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
static umode_t
hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 attr, int chan)
{
+ struct drm_i915_private *i915 = ddat->uncore->i915;
struct i915_hwmon *hwmon = ddat->hwmon;
+ u32 uval;
switch (attr) {
case hwmon_power_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit) ? 0664 : 0;
case hwmon_power_rated_max:
return i915_mmio_reg_valid(hwmon->rg.pkg_power_sku) ? 0444 : 0;
+ case hwmon_power_crit:
+ return (hwm_pcode_read_i1(i915, &uval) ||
+ !(uval & POWER_SETUP_I1_WATTS)) ? 0 : 0644;
[Intel-gfx] [PATCH 7/7] drm/i915/hwmon: Extend power/energy for XEHPSDV
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
Reviewed-by: Ashutosh Dixit
Reviewed-by: Anshuman Gupta
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 +
drivers/gpu/drm/i915/i915_hwmon.c | 114 +-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 19b9fe3ef237..dbd16b0f56d0 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -65,6 +65,11 @@ What:
/sys/devices/.../hwmon/hwmon/energy1_input
Date: February 2023
KernelVersion: 6.2
Contact: dri-de...@lists.freedesktop.org
-Description: RO. Energy input of device in microjoules.
+Description: RO. Energy input of device or gt in microjoules.
+
+ For i915 device level hwmon devices (name "i915") this
+ reflects energy input for the entire device. For gt level
+ hwmon devices (name "i915_gtN") this reflects energy input
+ for the gt.
Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index c7639ae79a8f..2d06610cbec9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1589,6 +1589,11 @@
#define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000)
+#define GT0_PACKAGE_ENERGY_STATUS _MMIO(0x250004)
+#define GT0_PACKAGE_RAPL_LIMIT _MMIO(0x250008)
+#define GT0_PACKAGE_POWER_SKU_UNIT _MMIO(0x250068)
+#define GT0_PLATFORM_ENERGY_STATUS _MMIO(0x25006c)
+
/*
* Standalone Media's non-engine GT registers are located at their regular GT
* offsets plus 0x38. This extra offset is stored inside the intel_uncore
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b95f54d274be..0c569bbfbeaf 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include "i915_reg.h"
#include "intel_mchbar_regs.h"
#include "intel_pcode.h"
+#include "gt/intel_gt.h"
#include "gt/intel_gt_regs.h"
/*
@@ -34,6 +35,7 @@ struct hwm_reg {
i915_reg_t pkg_power_sku;
i915_reg_t pkg_rapl_limit;
i915_reg_t energy_status_all;
+ i915_reg_t energy_status_tile;
};
struct hwm_energy_info {
@@ -47,10 +49,12 @@ struct hwm_drvdata {
struct device *hwmon_dev;
struct hwm_energy_info ei; /* Energy info for
energy1_input */
char name[12];
+ int gt_n;
};
struct i915_hwmon {
struct hwm_drvdata ddat;
+ struct hwm_drvdata ddat_gt[I915_MAX_GT];
struct mutex hwmon_lock;/* counter overflow logic and
rmw */
struct hwm_reg rg;
int scl_shift_power;
@@ -144,7 +148,10 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
i915_reg_t rgaddr;
u32 reg_val;
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
mutex_lock(&hwmon->hwmon_lock);
@@ -286,6 +293,11 @@ static const struct hwmon_channel_info *hwm_info[] = {
NULL
};
+static const struct hwmon_channel_info *hwm_gt_info[] = {
+ HWMON_CHANNEL_INFO(energy, HWMON_E_INPUT),
+ NULL
+};
+
/* I1 is exposed as power_crit or as curr_crit depending on bit 31 */
static int hwm_pcode_read_i1(struct drm_i915_private *i915, u32 *uval)
{
@@ -415,7 +427,10 @@ hwm_energy_is_visible(const struct hwm_drvdata *ddat, u32
attr)
switch (attr) {
case hwmon_energy_input:
- rgaddr = hwmon->rg.energy_status_all;
+ if (ddat->gt_n >= 0)
+ rgaddr = hwmon->rg.energy_status_tile;
+ else
+ rgaddr = hwmon->rg.energy_status_all;
return i915_mmio_reg_valid(rgaddr) ? 0444 : 0;
default:
return 0;
@@ -550,6 +565,44 @@ static const struct hwmon_chip_info hwm_chip_info = {
.info = hwm_info,
};
+static umode_t
+hwm_gt_is_visible(const void *drvdata, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ struct hwm_drvdata *ddat = (struct hwm_drvdata *)drvdata;
+
+ switch (type) {
+ case hwmon_energy:
+ return hwm_energy_is_visible(ddat, attr);
+ default:
+
[Intel-gfx] [PATCH 6/7] drm/i915/hwmon: Expose power1_max_interval
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm_power1_max_interval_store() (Badal)
v4:
- Fixed review comments (Anshuman)
- In hwm_power1_max_interval_store() get PKG_MAX_WIN from
pkg_power_sku when it is valid (Ashutosh)
- KernelVersion: 6.2, Date: February 2023 in doc (Tvrtko)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 9 ++
drivers/gpu/drm/i915/i915_hwmon.c | 120 +-
drivers/gpu/drm/i915/intel_mchbar_regs.h | 7 +
3 files changed, 135 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index f9d6d3b08bba..19b9fe3ef237 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -26,6 +26,15 @@ Description: RO. Card default power limit (default TDP
setting).
Only supported for particular Intel i915 graphics platforms.
+What: /sys/devices/.../hwmon/hwmon/power1_max_interval
+Date: February 2023
+KernelVersion: 6.2
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
+ milliseconds over which sustained power is averaged.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_crit
Date: February 2023
KernelVersion: 6.2
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index f743ac5c59c4..b95f54d274be 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -20,11 +20,13 @@
* - power - microwatts
* - curr - milliamperes
* - energy - microjoules
+ * - time - milliseconds
*/
#define SF_VOLTAGE 1000
#define SF_POWER 100
#define SF_CURR1000
#define SF_ENERGY 100
+#define SF_TIME1000
struct hwm_reg {
i915_reg_t gt_perf_status;
@@ -53,6 +55,7 @@ struct i915_hwmon {
struct hwm_reg rg;
int scl_shift_power;
int scl_shift_energy;
+ int scl_shift_time;
};
static void
@@ -161,6 +164,120 @@ hwm_energy(struct hwm_drvdata *ddat, long *energy)
return 0;
}
+static ssize_t
+hwm_power1_max_interval_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ u32 r, x, y, x_w = 2; /* 2 bits */
+ u64 tau4, out;
+
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+
+ x = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_X, r);
+ y = REG_FIELD_GET(PKG_PWR_LIM_1_TIME_Y, r);
+ /*
+* tau = 1.x * power(2,y), x = bits(23:22), y = bits(21:17)
+* = (4 | x) << (y - 2)
+* where (y - 2) ensures a 1.x fixed point representation of 1.x
+* However because y can be < 2, we compute
+* tau4 = (4 | x) << y
+* but add 2 when doing the final right shift to account for units
+*/
+ tau4 = ((1 << x_w) | x) << y;
+ /* val in hwmon interface units (millisec) */
+ out = mul_u64_u32_shr(tau4, SF_TIME, hwmon->scl_shift_time + x_w);
+
+ return sysfs_emit(buf, "%llu\n", out);
+}
+
+static ssize_t
+hwm_power1_max_interval_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct hwm_drvdata *ddat = dev_get_drvdata(dev);
+ struct i915_hwmon *hwmon = ddat->hwmon;
+ intel_wakeref_t wakeref;
+ long val, max_win, ret;
+ u32 x, y, rxy, x_w = 2; /* 2 bits */
+ u64 tau4, r;
+
+#define PKG_MAX_WIN_DEFAULT 0x12ull
+
+ ret = kstrtoul(buf, 0, &val);
+ if (ret)
+ return ret;
+
+ /*
+* val must be < max in hwmon interface units. The steps below are
+* explained in i915_power1_max_interval_show()
+*/
+ if (i915_mmio_reg_valid(hwmon->rg.pkg_power_sku))
+ with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+ r = intel_uncore_read64(ddat->uncore,
hwmon->rg.pkg_power_sku);
+ else
+ r = FIELD_PREP(PKG_MAX_WIN, PKG_MAX_WIN_DEFAULT);
+
+ x = REG_FIELD_GET(PKG_MAX_WIN_X, r);
+ y = REG_FIELD_GET(PKG_MAX_WIN_Y, r);
+ tau4 = ((1 << x_w) | x) << y;
+ max_win = mul_u64_u32_shr(tau4, SF_TIME, hwm
[Intel-gfx] [PATCH v2 00/15] Add DG2 OA support
Add OA format support for DG2 and various fixes for DG2. This series has 2 uapi changes listed below: 1) drm/i915/perf: Add OAG and OAR formats for DG2 DG2 has new OA formats defined that can be selected by the user. The UMD changes that are consumed by GPUvis are: https://patchwork.freedesktop.org/patch/504456/?series=107633&rev=5 2) drm/i915/perf: Apply Wa_18013179988 DG2 has a bug where the OA timestamp does not tick at the CS timestamp frequency. Instead it ticks at a multiple that is determined from the CTC_SHIFT value in RPM_CONFIG. Since the timestamp is used by UMD to make sense of all the counters in the report, expose the OA timestamp frequency to the user. The interface is generic and applies to all platforms. On platforms where the bug is not present, this returns the CS timestamp frequency. UMD specific changes consumed by GPUvis are: https://patchwork.freedesktop.org/patch/504464/?series=107633&rev=5 v2: - Add review comments - Update uapi changes in cover letter - Drop patches for non-production platforms drm/i915/perf: Use helpers to process reports w.r.t. OA buffer size drm/i915/perf: Add Wa_16010703925:dg2 - Drop 64-bit OA format changes for now drm/i915/perf: Parse 64bit report header formats correctly drm/i915/perf: Add Wa_1608133521:dg2 Test-with: 20220823183036.5270-1-umesh.nerlige.rama...@intel.com Signed-off-by: Umesh Nerlige Ramappa Umesh Nerlige Ramappa (14): drm/i915/perf: Fix OA filtering logic for GuC mode drm/i915/perf: Add OAG and OAR formats for DG2 drm/i915/perf: Fix noa wait predication for DG2 drm/i915/perf: Determine gen12 oa ctx offset at runtime drm/i915/perf: Enable commands per clock reporting in OA drm/i915/perf: Simply use stream->ctx drm/i915/perf: Move gt-specific data from i915->perf to gt->perf drm/i915/perf: Replace gt->perf.lock with stream->lock for file ops drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers drm/i915/perf: Store a pointer to oa_format in oa_buffer drm/i915/perf: Add Wa_1508761755:dg2 drm/i915/perf: Apply Wa_18013179988 drm/i915/perf: Save/restore EU flex counters across reset drm/i915/perf: Enable OA for DG2 Vinay Belgaumkar (1): drm/i915/guc: Support OA when Wa_16011777198 is enabled drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 4 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/gt/intel_lrc.h | 2 + drivers/gpu/drm/i915/gt/intel_sseu.c | 4 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 9 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 8 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 66 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 2 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 564 ++ drivers/gpu/drm/i915/i915_perf.h | 2 + drivers/gpu/drm/i915/i915_perf_oa_regs.h | 6 +- drivers/gpu/drm/i915/i915_perf_types.h| 47 +- drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/selftests/i915_perf.c| 16 +- include/uapi/drm/i915_drm.h | 10 + 20 files changed, 606 insertions(+), 147 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH v2 04/15] drm/i915/perf: Determine gen12 oa ctx offset at runtime
Some SKUs of same gen12 platform may have different oactxctrl
offsets. For gen12, determine oactxctrl offsets at runtime.
v2: (Lionel)
- Move MI definitions to intel_gpu_commands.h
- Ensure __find_reg_in_lri does read past context image size
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 4 +
drivers/gpu/drm/i915/i915_perf.c | 146 +++
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 2 +-
3 files changed, 121 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index d4e9702d3c8e..f50ea92910d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -187,6 +187,10 @@
#define MI_BATCH_RESOURCE_STREAMER REG_BIT(10)
#define MI_BATCH_PREDICATE REG_BIT(15) /* HSW+ on RCS only*/
+#define MI_OPCODE(x) (((x) >> 23) & 0x3f)
+#define IS_MI_LRI_CMD(x) (MI_OPCODE(x) == MI_OPCODE(MI_INSTR(0x22, 0)))
+#define MI_LRI_LEN(x) (((x) & 0xff) + 1)
+
/*
* 3D instructions used by the kernel
*/
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index cd57b5836386..fb705f24705b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1358,6 +1358,64 @@ static int gen12_get_render_context_id(struct
i915_perf_stream *stream)
return 0;
}
+#define __valid_oactxctrl_offset(x) ((x) && (x) != U32_MAX)
+static bool __find_reg_in_lri(u32 *state, u32 reg, u32 *offset, u32 end)
+{
+ u32 idx = *offset;
+ u32 len = min(MI_LRI_LEN(state[idx]) + idx, end);
+
+ idx++;
+ for (; idx < len; idx += 2)
+ if (state[idx] == reg)
+ break;
+
+ *offset = idx;
+ return state[idx] == reg;
+}
+
+static u32 __context_image_offset(struct intel_context *ce, u32 reg)
+{
+ u32 offset, len = (ce->engine->context_size - PAGE_SIZE) / 4;
+ u32 *state = ce->lrc_reg_state;
+
+ for (offset = 0; offset < len; ) {
+ if (IS_MI_LRI_CMD(state[offset])) {
+ if (__find_reg_in_lri(state, reg, &offset, len))
+ break;
+ } else {
+ offset++;
+ }
+ }
+
+ return offset < len ? offset : U32_MAX;
+}
+
+static int __set_oa_ctx_ctrl_offset(struct intel_context *ce)
+{
+ i915_reg_t reg = GEN12_OACTXCONTROL(ce->engine->mmio_base);
+ struct i915_perf *perf = &ce->engine->i915->perf;
+ u32 saved_offset = perf->ctx_oactxctrl_offset;
+ u32 offset;
+
+ /* Do this only once. Failure is stored as offset of U32_MAX */
+ if (saved_offset)
+ return 0;
+
+ offset = __context_image_offset(ce, i915_mmio_reg_offset(reg));
+ perf->ctx_oactxctrl_offset = offset;
+
+ drm_dbg(&ce->engine->i915->drm,
+ "%s oa ctx control at 0x%08x dword offset\n",
+ ce->engine->name, offset);
+
+ return __valid_oactxctrl_offset(offset) ? 0 : -ENODEV;
+}
+
+static bool engine_supports_mi_query(struct intel_engine_cs *engine)
+{
+ return engine->class == RENDER_CLASS;
+}
+
/**
* oa_get_render_ctx_id - determine and hold ctx hw id
* @stream: An i915-perf stream opened for OA metrics
@@ -1377,6 +1435,17 @@ static int oa_get_render_ctx_id(struct i915_perf_stream
*stream)
if (IS_ERR(ce))
return PTR_ERR(ce);
+ if (engine_supports_mi_query(stream->engine)) {
+ ret = __set_oa_ctx_ctrl_offset(ce);
+ if (ret && !(stream->sample_flags & SAMPLE_OA_REPORT)) {
+ intel_context_unpin(ce);
+ drm_err(&stream->perf->i915->drm,
+ "Enabling perf query failed for %s\n",
+ stream->engine->name);
+ return ret;
+ }
+ }
+
switch (GRAPHICS_VER(ce->engine->i915)) {
case 7: {
/*
@@ -2408,10 +2477,11 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
int err;
struct intel_context *ce = stream->pinned_ctx;
u32 format = stream->oa_buffer.format;
+ u32 offset = stream->perf->ctx_oactxctrl_offset;
struct flex regs_context[] = {
{
GEN8_OACTXCONTROL,
- stream->perf->ctx_oactxctrl_offset + 1,
+ offset + 1,
active ? GEN8_OA_COUNTER_RESUME : 0,
},
};
@@ -2436,15 +2506,18 @@ static int gen12_configure_oar_context(struct
i915_perf_stream *stream,
},
};
- /* Modify the context image of pinned context with regs_context*/
- err = intel_context_lock_pinned(ce);
- if (err)
- return err;
+ /* Modify the context image of pinned
