[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Avoid full proxy f_ops debug attributes
== Series Details ==
Series: drm/i915: Avoid full proxy f_ops debug attributes
URL : https://patchwork.freedesktop.org/series/112625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569_full -> Patchwork_112625v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/index.html
Participating hosts (14 -> 10)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Known issues
Here are the changes found in Patchwork_112625v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@massive:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-glk2/igt@gem_lmem_swapp...@massive.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3886])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-glk2/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271]) +40 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-glk2/igt@kms_frontbuffer_track...@psr-rgb565-draw-mmap-gtt.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-glk2/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html
* igt@sysfs_clients@sema-25:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2994])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-glk2/igt@sysfs_clie...@sema-25.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][10] ([i915#2582]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-4/igt@fb...@pan.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-rkl-6/igt@fb...@pan.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][12] ([i915#658]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-4/igt@feature_discov...@psr1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[FAIL][14] ([fdo#103375]) -> [PASS][15] +3 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-3/igt@gem_ctx_isolation@preservation...@bcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-rkl-1/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#2842]) -> [PASS][17] +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-rkl-5/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_mmap_wc@set-cache-level:
- {shard-rkl}:[SKIP][18] ([i915#1850]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@gem_mmap...@set-cache-level.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-rkl-6/igt@gem_mmap...@set-cache-level.html
* igt@i915_pipe_stress@stress-xrgb-untiled:
- {shard-tglu}: [SKIP][20] ([i915#1845]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-tglu-6/igt@i915_pipe_str...@stress-xrgb-untiled.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/shard-tglu-5/igt@i915_pipe_str...@stress-xrgb-untiled.html
* igt@i915_pm_rpm@system-suspend-modeset:
- {shard-rkl}:[SKIP][22] ([fdo#109308]) -> [PASS][23] +1 similar
issue
[22]:
[Intel-gfx] [PATCH v3 4/4] drm/i915: Clean up page shift operation
Remove page shift operations as ttm_resource moved
from num_pages to size_t size in bytes.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/i915/i915_scatterlist.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c
b/drivers/gpu/drm/i915/i915_scatterlist.c
index 114e5e39aa72..bd7aaf7738f4 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -94,7 +94,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
if (!rsgt)
return ERR_PTR(-ENOMEM);
- i915_refct_sgt_init(rsgt, node->size << PAGE_SHIFT);
+ i915_refct_sgt_init(rsgt, node->size);
st = >table;
if (sg_alloc_table(st, DIV_ROUND_UP_ULL(node->size, segment_pages),
GFP_KERNEL)) {
@@ -105,8 +105,8 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct
drm_mm_node *node,
sg = st->sgl;
st->nents = 0;
prev_end = (resource_size_t)-1;
- block_size = node->size << PAGE_SHIFT;
- offset = node->start << PAGE_SHIFT;
+ block_size = node->size;
+ offset = node->start;
while (block_size) {
u64 len;
--
2.32.0
[Intel-gfx] [PATCH v3 3/4] drm/amdgpu: Clean up page shift operation and GWS and OA
Remove page shift operations as ttm_resource moved
from num_pages to size_t size in bytes.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 12 ++--
2 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..19ad365dc159 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -541,12 +541,10 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
- size <<= PAGE_SHIFT;
-
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
- size = ALIGN(size, 4) << PAGE_SHIFT;
+ size = ALIGN(size, 4);
} else {
/* Memory should be aligned at least to a page size. */
page_align = ALIGN(bp->byte_align, PAGE_SIZE) >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 5c4f93ee0c57..f92b61350efe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -91,11 +91,11 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
break;
case TTM_PL_TT:
node = to_ttm_range_mgr_node(res)->mm_nodes;
- while (start >= node->size << PAGE_SHIFT)
- start -= node++->size << PAGE_SHIFT;
+ while (start >= node->size)
+ start -= node++->size;
- cur->start = (node->start << PAGE_SHIFT) + start;
- cur->size = min((node->size << PAGE_SHIFT) - start, size);
+ cur->start = (node->start) + start;
+ cur->size = min(node->size - start, size);
cur->remaining = size;
cur->node = node;
break;
@@ -155,8 +155,8 @@ static inline void amdgpu_res_next(struct amdgpu_res_cursor
*cur, uint64_t size)
node = cur->node;
cur->node = ++node;
- cur->start = node->start << PAGE_SHIFT;
- cur->size = min(node->size << PAGE_SHIFT, cur->remaining);
+ cur->start = node->start;
+ cur->size = min(node->size, cur->remaining);
break;
default:
return;
--
2.32.0
[Intel-gfx] [PATCH v3 1/4] drm/ttm: Clean up page shift operation
Remove page shift operations as ttm_resource moved
from num_pages to size_t size in bytes.
v1 -> v2: fix missing page shift to fpfn and lpfn
v2 -> v3: separate patch’s based on driver module
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index ae11d07eb63a..3703cbc6d368 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,9 +83,10 @@ static int ttm_range_man_alloc(struct ttm_resource_manager
*man,
spin_lock(>lock);
ret = drm_mm_insert_node_in_range(mm, >mm_nodes[0],
- PFN_UP(node->base.size),
+ node->base.size,
bo->page_alignment, 0,
- place->fpfn, lpfn, mode);
+ place->fpfn << PAGE_SHIFT,
+ lpfn << PAGE_SHIFT, mode);
spin_unlock(>lock);
if (unlikely(ret)) {
@@ -119,11 +120,10 @@ static bool ttm_range_man_intersects(struct
ttm_resource_manager *man,
size_t size)
{
struct drm_mm_node *node = _ttm_range_mgr_node(res)->mm_nodes[0];
- u32 num_pages = PFN_UP(size);
/* Don't evict BOs outside of the requested placement range */
- if (place->fpfn >= (node->start + num_pages) ||
- (place->lpfn && place->lpfn <= node->start))
+ if ((place->fpfn << PAGE_SHIFT) >= (node->start + size) ||
+ (place->lpfn && (place->lpfn << PAGE_SHIFT) <= node->start))
return false;
return true;
@@ -135,10 +135,9 @@ static bool ttm_range_man_compatible(struct
ttm_resource_manager *man,
size_t size)
{
struct drm_mm_node *node = _ttm_range_mgr_node(res)->mm_nodes[0];
- u32 num_pages = PFN_UP(size);
if (node->start < place->fpfn ||
- (place->lpfn && (node->start + num_pages) > place->lpfn))
+ (place->lpfn && (node->start + size) > place->lpfn << PAGE_SHIFT))
return false;
return true;
--
2.32.0
[Intel-gfx] [PATCH v3 2/4] drm/gem: Remove BUG_ON in drm_gem_private_object_init
ttm_resource allocate size in bytes to support less than page size
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/drm_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 59a0bb5ebd85..ee8b5c2b6c60 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -152,8 +152,6 @@ EXPORT_SYMBOL(drm_gem_object_init);
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
- BUG_ON((size & (PAGE_SIZE - 1)) != 0);
-
obj->dev = dev;
obj->filp = NULL;
--
2.32.0
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable YCbCr420 for VDSC
== Series Details ==
Series: Enable YCbCr420 for VDSC
URL : https://patchwork.freedesktop.org/series/112653/
State : warning
== Summary ==
Error: dim checkpatch failed
85568f88bfda drm/dp_helper: Add helper to check if the sink supports given
format with DSC
27809b830b41 drm/i915/dp: Check if DSC supports the given output_format
e8489066645a drm/i915: Adding the new registers for DSC
d3bd463de8e6 drm/i915: Enable YCbCr420 for VDSC
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_row' - possible
side-effects?
#189: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420) do { \
+ if (bpc == (_bpc)) {\
+ if (_is_420)\
+ return
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+ else\
+ return
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+ } \
} while (0)
-:189: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_col' - possible
side-effects?
#189: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420) do { \
+ if (bpc == (_bpc)) {\
+ if (_is_420)\
+ return
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+ else\
+ return
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+ } \
} while (0)
total: 0 errors, 0 warnings, 2 checks, 228 lines checked
80c563b9d7ed drm/i915: Fill in native_420 field
a91b0a3a0007 drm/i915/vdsc: Check slice design requirement
d87c707ecc91 drm/i915/dsc: Add debugfs entry to validate DSC YCbCr420
0c5d3e56ee18 drm/i915/dsc: Allow DSC only with YCbCr420 format when forced from
debugfs
bff82d7524b7 drm/i915: Code styling fixes
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add missing check and destroy for alloc_workqueue
== Series Details ==
Series: drm/i915: Add missing check and destroy for alloc_workqueue
URL : https://patchwork.freedesktop.org/series/112623/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12569_full -> Patchwork_112623v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_112623v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112623v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/index.html
Participating hosts (14 -> 10)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112623v1_full:
### IGT changes ###
Possible regressions
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk7/igt@gem_pp...@flink-and-close-vma-leak.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk6/igt@gem_pp...@flink-and-close-vma-leak.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_addfb_basic@bad-pitch-256:
- {shard-dg1}:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-dg1-14/igt@kms_addfb_ba...@bad-pitch-256.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-dg1-19/igt@kms_addfb_ba...@bad-pitch-256.html
Known issues
Here are the changes found in Patchwork_112623v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk7/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_lmem_swapping@massive:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk6/igt@gem_lmem_swapp...@massive.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk6/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +40 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk6/igt@kms_frontbuffer_track...@psr-rgb565-draw-mmap-gtt.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk6/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html
* igt@sysfs_clients@sema-25:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2994])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk6/igt@sysfs_clie...@sema-25.html
Possible fixes
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][12] ([i915#2582]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-4/igt@fb...@pan.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-rkl-6/igt@fb...@pan.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][14] ([i915#658]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-1/igt@feature_discov...@psr2.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][16] ([i915#6259]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-rkl-1/igt@gem_exec_balan...@fairslice.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: [FAIL][18] ([i915#2842]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk8/igt@gem_exec_fair@basic-n...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/shard-glk5/igt@gem_exec_fair@basic-n...@rcs0.html
*
[Intel-gfx] [PATCH v6 9/9] drm/i915: Code styling fixes
From: Swati Sharma
Removed extra newlines and did few styling fixes.
Signed-off-by: Swati Sharma
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 0d4bd9bc6dd0..b35ea3e5465f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1440,7 +1440,6 @@ static ssize_t wm_latency_write(struct file *file, const
char __user *ubuf,
return len;
}
-
static ssize_t pri_wm_latency_write(struct file *file, const char __user *ubuf,
size_t len, loff_t *offp)
{
@@ -1790,13 +1789,13 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
const char __user *ubuf,
size_t len, loff_t *offp)
{
- bool dsc_enable = false;
- int ret;
struct drm_connector *connector =
((struct seq_file *)file->private_data)->private;
struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ bool dsc_enable = false;
+ int ret;
if (len == 0)
return 0;
@@ -1813,6 +1812,7 @@ static ssize_t i915_dsc_fec_support_write(struct file
*file,
intel_dp->force_dsc_en = dsc_enable;
*offp += len;
+
return len;
}
--
2.25.1
[Intel-gfx] [PATCH v6 8/9] drm/i915/dsc: Allow DSC only with YCbCr420 format when forced from debugfs
From: Swati Sharma If force_dsc_ycbcr420_en is set through debugfs allow DSC iff output_format is INTEL_OUTPUT_FORMAT_YCBCR420. Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/display/intel_dp.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 2adac42e585d..666ee85dd23a 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -1528,6 +1528,10 @@ int intel_dp_dsc_compute_config(struct intel_dp *intel_dp, if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format)) return -EINVAL; + if (intel_dp->force_dsc_ycbcr420_en && + pipe_config->output_format != INTEL_OUTPUT_FORMAT_YCBCR420) + return -EINVAL; + if (compute_pipe_bpp) pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, conn_state->max_requested_bpc); else -- 2.25.1
[Intel-gfx] [PATCH v6 7/9] drm/i915/dsc: Add debugfs entry to validate DSC YCbCr420
From: Swati Sharma
DSC_YCBCR420_Sink_Support entry is added to i915_dsc_fec_support_show
to depict if sink supports DSC YCbCr420.
Also, new debugfs entry is created to enforce YCbCr420 output format.
This is required because of our driver policy.
If a mode is supported in both RGB and YCbCr420 output
formats by the sink, our policy is to try RGB first and
fall back to YCbCr420, if mode cannot be shown using RGB.
So, to test YCbCr420, we need a debugfs entry (force_dsc_ycbcr420)
to force thisoutput format; so that YCbCr420 code gets executed.
Signed-off-by: Swati Sharma
---
.../drm/i915/display/intel_display_debugfs.c | 85 +++
.../drm/i915/display/intel_display_types.h| 1 +
2 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 7bcd90384a46..0d4bd9bc6dd0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1772,6 +1772,9 @@ static int i915_dsc_fec_support_show(struct seq_file *m,
void *data)
str_yes_no(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
seq_printf(m, "Force_DSC_Enable: %s\n",
str_yes_no(intel_dp->force_dsc_en));
+ seq_printf(m, "DSC_YCBCR420_Sink_Support: %s\n",
+
str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
+
DP_DSC_YCbCr420_Native)));
if (!intel_dp_is_edp(intel_dp))
seq_printf(m, "FEC_Sink_Support: %s\n",
str_yes_no(drm_dp_sink_supports_fec(intel_dp->fec_capable)));
@@ -1895,6 +1898,85 @@ static const struct file_operations i915_dsc_bpc_fops = {
.write = i915_dsc_bpc_write
};
+static int i915_dsc_ycbcr420_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_dp *intel_dp;
+ struct intel_crtc_state *crtc_state;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ int ret;
+
+ if (!encoder)
+ return -ENODEV;
+
+ ret =
drm_modeset_lock_single_interruptible(>mode_config.connection_mutex);
+ if (ret)
+ return ret;
+
+ crtc = connector->state->crtc;
+ if (connector->status != connector_status_connected || !crtc) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ intel_dp = intel_attached_dp(to_intel_connector(connector));
+ crtc_state = to_intel_crtc_state(crtc->state);
+ seq_printf(m, "Force_DSC_YCBCR420_Enable: %s\n",
+ str_yes_no(intel_dp->force_dsc_ycbcr420_en));
+
+out: drm_modeset_unlock(>mode_config.connection_mutex);
+
+ return ret;
+}
+
+static ssize_t i915_dsc_ycbcr420_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ bool dsc_ycbcr420_enable = false;
+ int ret;
+
+ if (len == 0)
+ return 0;
+
+ drm_dbg(>drm,
+ "Copied %zu bytes from user to force YCBCR420 for DSC\n", len);
+
+ ret = kstrtobool_from_user(ubuf, len, _ycbcr420_enable);
+ if (ret < 0)
+ return ret;
+
+ drm_dbg(>drm, "Got %s for DSC YCBCR420 Enable\n",
+ (dsc_ycbcr420_enable) ? "true" : "false");
+ intel_dp->force_dsc_ycbcr420_en = dsc_ycbcr420_enable;
+
+ *offp += len;
+
+ return len;
+}
+
+static int i915_dsc_ycbcr420_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_dsc_ycbcr420_show, inode->i_private);
+}
+
+static const struct file_operations i915_dsc_ycbcr420_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_dsc_ycbcr420_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_dsc_ycbcr420_write
+};
+
/*
* Returns the Current CRTC's bpc.
* Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
@@ -1966,6 +2048,9 @@ void intel_connector_debugfs_add(struct intel_connector
*intel_connector)
debugfs_create_file("i915_dsc_bpc", 0644, root,
connector, _dsc_bpc_fops);
+
+ debugfs_create_file("i915_dsc_ycbcr420", 0644, root,
+
[Intel-gfx] [PATCH v6 5/9] drm/i915: Fill in native_420 field
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true
---v3
-adding display version check to solve igt issue
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 3 -
drivers/gpu/drm/i915/display/intel_vdsc.c | 74 ++-
3 files changed, 71 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ae14c794c4bc..ff9e15dd7595 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1626,8 +1626,6 @@ static int gen11_dsi_dsc_compute_config(struct
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
- vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6e531872ff38..2adac42e585d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1459,9 +1459,6 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
- vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP
- DP_DSC_SUPPORT] &
- DP_DSC_RGB;
-
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
drm_dbg_kms(>drm,
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed16f63d6355..52a82d8b289e 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -460,14 +460,47 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
pipe_config->dsc.slice_count);
-
- /* Gen 11 does not support YCbCr */
+ /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
is 0
+* else 1
+*/
+ vdsc_cfg->convert_rgb = !(pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR420 ||
+ pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR444);
+
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ vdsc_cfg->native_420 = true;
+ /* We do not support YcBCr422 as of now */
+ vdsc_cfg->native_422 = false;
+ /* Gen 11 does not support YCbCr422 */
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+ /*
+* According to DSC 1.2 specs if native_420 is set:
+* -We need to double the current bpp.
+* -second_line_bpg_offset is 12 in general and equal to
2*(slice_height-1) if slice
+* height < 8.
+* -second_line_offset_adj is 512 as shown by emperical values to yeild
best chroma
+* preservation in second line.
+* -nsl_bpg_offset is calculated as second_line_offset/slice_height -1
then rounded
+* up to 16 fractional bits, we left shift second line offset by 11 to
preserve 11
+* fractional bits.
+*/
+ if (vdsc_cfg->native_420) {
+ vdsc_cfg->bits_per_pixel <<= 1;
+ if (vdsc_cfg->slice_height >= 8)
+ vdsc_cfg->second_line_bpg_offset = 12;
+ else
+ vdsc_cfg->second_line_bpg_offset =
+ 2 * (vdsc_cfg->slice_height - 1);
+ vdsc_cfg->second_line_offset_adj = 512;
+ vdsc_cfg->nsl_bpg_offset =
DIV_ROUND_UP(vdsc_cfg->second_line_bpg_offset << 11,
+ vdsc_cfg->slice_height
- 1);
+ }
+
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
@@ -594,8 +627,13 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
DSC_VER_MIN_SHIFT |
vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
- if (vdsc_cfg->dsc_version_minor == 2)
+ if (vdsc_cfg->dsc_version_minor == 2) {
pps_val |=
[Intel-gfx] [PATCH v6 6/9] drm/i915/vdsc: Check slice design requirement
Add function to check if slice design requirements are being
met as defined in the below link section Slice Design Requirement
https://gfxspecs.intel.com/Predator/Home/Index/49259
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 52a82d8b289e..0a683d6dff33 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -447,6 +447,29 @@ calculate_rc_params(struct rc_parameters *rc,
}
}
+static int intel_dsc_check_slice_design_req(struct intel_crtc_state
*pipe_config,
+ struct drm_dsc_config *vdsc_cfg)
+{
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_RGB ||
+ pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
+ if (vdsc_cfg->slice_height > 4095)
+ return -EINVAL;
+ if (vdsc_cfg->slice_height * vdsc_cfg->slice_width < 15000)
+ return -EINVAL;
+ } else if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
+ if (!(vdsc_cfg->slice_width % 2))
+ return -EINVAL;
+ if (!(vdsc_cfg->slice_height % 2))
+ return -EINVAL;
+ if (vdsc_cfg->slice_height > 4094)
+ return -EINVAL;
+ if (vdsc_cfg->slice_height * vdsc_cfg->slice_width < 3)
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int intel_dsc_compute_params(struct intel_crtc_state *pipe_config)
{
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
@@ -455,11 +478,20 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
u16 compressed_bpp = pipe_config->dsc.compressed_bpp;
const struct rc_parameters *rc_params;
struct rc_parameters *rc = NULL;
+ int err;
u8 i = 0;
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
pipe_config->dsc.slice_count);
+
+ err = intel_dsc_check_slice_design_req(pipe_config, vdsc_cfg);
+
+ if (err) {
+ drm_dbg_kms(_priv->drm, "Slice design requirements not
met\n");
+ return err;
+ }
+
/*
* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
is 0
* else 1
--
2.25.1
[Intel-gfx] [PATCH v6 4/9] drm/i915: Enable YCbCr420 for VDSC
Implementation of VDSC for YCbCr420.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_qp_tables.c| 187 --
.../gpu/drm/i915/display/intel_qp_tables.h| 4 +-
drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-
3 files changed, 180 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c
b/drivers/gpu/drm/i915/display/intel_qp_tables.c
index 6f8e4ec5c0fb..6e86c0971d24 100644
--- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
+++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
@@ -17,6 +17,15 @@
/* from BPP 6 to 36 in steps of 0.5 */
#define RC_RANGE_QP444_12BPC_MAX_NUM_BPP 61
+/* from BPP 6 to 24 in steps of 0.5 */
+#define RC_RANGE_QP420_8BPC_MAX_NUM_BPP17
+
+/* from BPP 6 to 30 in steps of 0.5 */
+#define RC_RANGE_QP420_10BPC_MAX_NUM_BPP 23
+
+/* from BPP 6 to 36 in steps of 0.5 */
+#define RC_RANGE_QP420_12BPC_MAX_NUM_BPP 29
+
/*
* These qp tables are as per the C model
* and it has the rows pointing to bpps which increment
@@ -283,26 +292,182 @@ static const u8
rc_range_maxqp444_12bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_12BPC
11, 11, 10, 10, 10, 10, 10, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 6, 6, 5,
5, 4 }
};
-#define PARAM_TABLE(_minmax, _bpc, _row, _col) do { \
- if (bpc == (_bpc)) \
- return rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+static const u8
rc_range_minqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 3, 3, 3, 3, 3, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0 },
+ { 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+ { 3, 3, 3, 3, 3, 3, 2, 2, 1, 1, 1, 1, 1, 1, 1, 0, 0 },
+ { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+ { 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 0 },
+ { 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 2, 2, 1, 1 },
+ { 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 3, 3, 3, 3, 2, 1, 1 },
+ { 5, 5, 5, 5, 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 2, 2, 1 },
+ { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 4, 4, 3, 3, 2, 1 },
+ { 9, 8, 8, 7, 7, 7, 7, 7, 7, 6, 5, 5, 4, 3, 3, 3, 2 },
+ { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3 }
+};
+
+static const u8
rc_range_maxqp420_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_8BPC_MAX_NUM_BPP] = {
+ { 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 4, 4, 4, 4, 4, 3, 2, 2, 1, 1, 1, 1, 0, 0, 0, 0, 0 },
+ { 5, 5, 5, 5, 5, 4, 3, 2, 1, 1, 1, 1, 1, 1, 0, 0, 0 },
+ { 6, 6, 6, 6, 6, 5, 4, 3, 2, 2, 2, 1, 1, 1, 1, 0, 0 },
+ { 7, 7, 7, 7, 7, 5, 4, 3, 2, 2, 2, 2, 2, 1, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 2, 2, 2, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 6, 5, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1 },
+ { 8, 8, 8, 8, 8, 7, 6, 5, 4, 4, 4, 3, 3, 2, 2, 2, 1 },
+ { 9, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+ { 10, 10, 9, 9, 9, 8, 7, 6, 5, 5, 5, 4, 4, 3, 3, 2, 2 },
+ { 10, 10, 10, 9, 9, 8, 8, 7, 6, 6, 5, 5, 4, 4, 3, 2, 2 },
+ { 11, 11, 10, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4, 3, 3, 2 },
+ { 11, 11, 11, 10, 9, 9, 9, 8, 7, 7, 6, 5, 5, 4, 4, 3, 2 },
+ { 13, 12, 12, 11, 10, 10, 9, 8, 8, 7, 6, 6, 5, 4, 4, 4, 3 },
+ { 14, 13, 13, 12, 11, 11, 10, 9, 9, 8, 7, 7, 6, 6, 5, 5, 4 }
+};
+
+static const u8
rc_range_minqp420_10bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP420_10BPC_MAX_NUM_BPP] =
{
+ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 4, 4, 4, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 4, 4, 4, 3, 3, 3, 3, 3, 3, 2, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0 },
+ { 5, 5, 5, 4, 4, 4, 4, 4, 4, 3, 3, 2, 2, 2, 2, 1, 0, 0, 0, 0, 0, 0, 0 },
+ { 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 3, 3, 2, 2, 2, 1, 1, 1, 0, 0, 0, 0 },
+ { 7, 7, 7, 7, 7, 6, 5, 5, 5, 5, 5, 4, 3, 3, 2, 2, 1, 1, 1, 1, 1, 0, 0 },
+ { 7, 7, 7, 7, 7, 6, 6, 5, 5, 5, 5, 4, 4, 4, 3, 2, 2, 2, 2, 1, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 6, 5, 4, 4, 4, 3, 2, 2, 2, 1, 1, 1, 0 },
+ { 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 2, 1, 1 },
+ { 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1, 1 },
+ { 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 7, 7, 6, 6, 5, 5, 4, 4, 3, 3, 2, 2, 1 },
+ { 9, 9, 9, 9, 9, 9, 8, 8, 8, 8, 8, 8, 8, 7, 6, 6, 5, 4, 4, 3, 3, 2, 1 },
+ { 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 8, 8, 7, 7, 6, 5, 4, 4, 3, 3, 2, 1 },
+ { 13, 12, 12, 11, 11, 11, 11, 11, 11, 10, 9, 9, 8, 7, 7, 6, 5, 5, 4, 3,
3,
+ 2, 2 },
+ { 17, 16, 16, 15, 14, 14, 13, 12, 12, 11, 10, 10, 10, 9, 8, 8, 7, 6, 6,
5,
+ 5, 4, 4 }
+};
+
+static const u8
[Intel-gfx] [PATCH v6 3/9] drm/i915: Adding the new registers for DSC
Adding new DSC register which are introducted MTL onwards
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/i915_reg.h | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8b2cf980f323..69a645ce0fe8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7766,6 +7766,8 @@ enum skl_power_gate {
#define ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe) _MMIO_PIPE((pipe) - PIPE_B, \
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PB, \
_ICL_DSC1_PICTURE_PARAMETER_SET_0_PC)
+#define DSC_NATIVE_422_ENABLE BIT(23)
+#define DSC_NATIVE_420_ENABLE BIT(22)
#define DSC_ALT_ICH_SEL (1 << 20)
#define DSC_VBR_ENABLE(1 << 19)
#define DSC_422_ENABLE(1 << 18)
@@ -8010,6 +8012,32 @@ enum skl_power_gate {
#define DSC_SLICE_PER_LINE(slice_per_line)((slice_per_line) << 16)
#define DSC_SLICE_CHUNK_SIZE(slice_chunk_size)
((slice_chunk_size) << 0)
+/* MTL Display Stream Compression registers */
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PB 0x782B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PB 0x783B4
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_17_PC 0x784B4
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_17_PC 0x785B4
+#define MTL_DSC0_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PB, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_17_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_17(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PB, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_17_PC)
+#define DSC_SL_BPG_OFFSET(offset) ((offset) << 27)
+
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PB 0x782B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PB 0x783B8
+#define _MTL_DSC0_PICTURE_PARAMETER_SET_18_PC 0x784B8
+#define _MTL_DSC1_PICTURE_PARAMETER_SET_18_PC 0x785B8
+#define MTL_DSC0_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PB, \
+
_MTL_DSC0_PICTURE_PARAMETER_SET_18_PC)
+#define MTL_DSC1_PICTURE_PARAMETER_SET_18(pipe)_MMIO_PIPE((pipe) -
PIPE_B, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PB, \
+
_MTL_DSC1_PICTURE_PARAMETER_SET_18_PC)
+#define DSC_NSL_BPG_OFFSET(offset) ((offset) << 16)
+#define DSC_SL_OFFSET_ADJ(offset) ((offset) << 0)
+
/* Icelake Rate Control Buffer Threshold Registers */
#define DSCA_RC_BUF_THRESH_0 _MMIO(0x6B230)
#define DSCA_RC_BUF_THRESH_0_UDW _MMIO(0x6B230 + 4)
--
2.25.1
[Intel-gfx] [PATCH v6 2/9] drm/i915/dp: Check if DSC supports the given output_format
From: Ankit Nautiyal
Go with DSC only if the given output_format is supported.
v2: Use drm helper to get DSC format support for sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 30 +
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 30c55f980014..6e531872ff38 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1483,6 +1483,31 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
return drm_dsc_compute_rc_parameters(vdsc_cfg);
}
+static bool intel_dp_dsc_supports_format(struct intel_dp *intel_dp,
+enum intel_output_format output_format)
+{
+ u8 sink_dsc_format;
+
+ switch (output_format) {
+ case INTEL_OUTPUT_FORMAT_RGB:
+ sink_dsc_format = DP_DSC_RGB;
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ sink_dsc_format = DP_DSC_YCbCr444;
+ break;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ if (min(intel_dp_source_dsc_version_minor(intel_dp),
+ intel_dp_sink_dsc_version_minor(intel_dp)) < 2)
+ return false;
+ sink_dsc_format = DP_DSC_YCbCr420_Native;
+ break;
+ default:
+ return false;
+ }
+
+ return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
sink_dsc_format);
+}
+
int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
@@ -1503,11 +1528,16 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return -EINVAL;
+ if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
+ return -EINVAL;
+
if (compute_pipe_bpp)
pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
else
pipe_bpp = pipe_config->pipe_bpp;
+ pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
conn_state->max_requested_bpc);
+
if (intel_dp->force_dsc_bpc) {
pipe_bpp = intel_dp->force_dsc_bpc * 3;
drm_dbg_kms(_priv->drm, "Input DSC BPP forced to %d",
pipe_bpp);
--
2.25.1
[Intel-gfx] [PATCH v6 1/9] drm/dp_helper: Add helper to check if the sink supports given format with DSC
From: Ankit Nautiyal
Add helper function to check if the DP sink supports DSC with the given
output format.
Signed-off-by: Ankit Nautiyal
---
include/drm/display/drm_dp_helper.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2c..d529d0254b68 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -194,6 +194,13 @@ drm_dp_dsc_sink_max_slice_width(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
DP_DSC_SLICE_WIDTH_MULTIPLIER;
}
+/* Check if sink supports DSC with given output format */
+static inline bool
+drm_dp_dsc_sink_supports_format(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
u8 output_format)
+{
+ return dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
output_format;
+}
+
/* Forward Error Correction Support on DP 1.4 */
static inline bool
drm_dp_sink_supports_fec(const u8 fec_capable)
--
2.25.1
[Intel-gfx] [PATCH v6 0/9] Enable YCbCr420 for VDSC
This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. ---v2 -add fields missed for vdsc_cfg [Vandita] -add corresponding registers and writing to the [Vandita] ---v3 -add 11 bit left shift missed in nsl_bpg_offset calculation ---v4 -add display version check before writing in new pps register ---v5 -add helper to check if sink supports given format with DSC -add debugfs entry to enforce DSC with YCbCr420 format only --v6 -add patch to check dsc slice design requirement [Vandita] Ankit Nautiyal (2): drm/dp_helper: Add helper to check if the sink supports given format with DSC drm/i915/dp: Check if DSC supports the given output_format Suraj Kandpal (4): drm/i915: Adding the new registers for DSC drm/i915: Enable YCbCr420 for VDSC drm/i915: Fill in native_420 field drm/i915/vdsc: Check slice design requirement Swati Sharma (3): drm/i915/dsc: Add debugfs entry to validate DSC YCbCr420 drm/i915/dsc: Allow DSC only with YCbCr420 format when forced from debugfs drm/i915: Code styling fixes drivers/gpu/drm/i915/display/icl_dsi.c| 2 - .../drm/i915/display/intel_display_debugfs.c | 91 - .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 37 +++- .../gpu/drm/i915/display/intel_qp_tables.c| 187 -- .../gpu/drm/i915/display/intel_qp_tables.h| 4 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 108 +- drivers/gpu/drm/i915/i915_reg.h | 28 +++ include/drm/display/drm_dp_helper.h | 7 + 9 files changed, 440 insertions(+), 25 deletions(-) -- 2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Replace zero-length arrays with flexible-array members
== Series Details ==
Series: drm/i915/guc: Replace zero-length arrays with flexible-array members
URL : https://patchwork.freedesktop.org/series/112621/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569_full -> Patchwork_112621v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/index.html
Participating hosts (14 -> 11)
--
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
Here are the changes found in Patchwork_112621v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-glk1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#2017])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk1/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-glk5/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-2/igt@drm_fdinfo@i...@rcs0.html
* igt@gem_ctx_isolation@preservation-s3@bcs0:
- {shard-rkl}:[FAIL][7] ([fdo#103375]) -> [PASS][8] +3 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-3/igt@gem_ctx_isolation@preservation...@bcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-5/igt@gem_ctx_isolation@preservation...@bcs0.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- {shard-rkl}:[FAIL][9] ([i915#2842]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-5/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_reloc@basic-wc-read-noreloc:
- {shard-rkl}:[SKIP][11] ([i915#3281]) -> [PASS][12] +7 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-1/igt@gem_exec_re...@basic-wc-read-noreloc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-5/igt@gem_exec_re...@basic-wc-read-noreloc.html
* igt@gem_partial_pwrite_pread@write:
- {shard-rkl}:[SKIP][13] ([i915#3282]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-3/igt@gem_partial_pwrite_pr...@write.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-5/igt@gem_partial_pwrite_pr...@write.html
* igt@gen9_exec_parse@valid-registers:
- {shard-rkl}:[SKIP][15] ([i915#2527]) -> [PASS][16] +3 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@gen9_exec_pa...@valid-registers.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-5/igt@gen9_exec_pa...@valid-registers.html
* igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-hdmi-a:
- {shard-dg1}:[SKIP][17] ([i915#1937]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-dg1-18/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-dg1-14/igt@i915_pm_lpsp@kms-l...@kms-lpsp-hdmi-a.html
* igt@i915_pm_sseu@full-enable:
- {shard-rkl}:[SKIP][19] ([i915#4387]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@i915_pm_s...@full-enable.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/shard-rkl-5/igt@i915_pm_s...@full-enable.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[Intel-gfx] ✓ Fi.CI.IGT: success for ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops (rev3)
== Series Details ==
Series: ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell
laptops (rev3)
URL : https://patchwork.freedesktop.org/series/112572/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569_full -> Patchwork_112572v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/index.html
Participating hosts (14 -> 10)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Known issues
Here are the changes found in Patchwork_112572v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@massive:
- shard-glk: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-glk3/igt@gem_lmem_swapp...@massive.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#3886])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-glk3/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_flip@plain-flip-ts-check-interruptible@a-hdmi-a1:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2122])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-glk9/igt@kms_flip@plain-flip-ts-check-interrupti...@a-hdmi-a1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-glk6/igt@kms_flip@plain-flip-ts-check-interrupti...@a-hdmi-a1.html
* igt@kms_frontbuffer_tracking@psr-rgb565-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271]) +40 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-glk3/igt@kms_frontbuffer_track...@psr-rgb565-draw-mmap-gtt.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-glk3/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html
* igt@sysfs_clients@sema-25:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2994])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-glk3/igt@sysfs_clie...@sema-25.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-4/igt@drm_fdi...@virtual-idle.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@read:
- {shard-rkl}:[SKIP][10] ([i915#2582]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-3/igt@fb...@read.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-6/igt@fb...@read.html
* igt@gem_exec_balancer@fairslice:
- {shard-rkl}:[SKIP][12] ([i915#6259]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-5/igt@gem_exec_balan...@fairslice.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-3/igt@gem_exec_balan...@fairslice.html
* igt@gem_exec_reloc@basic-write-read-noreloc:
- {shard-rkl}:[SKIP][14] ([i915#3281]) -> [PASS][15] +9 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@gem_exec_re...@basic-write-read-noreloc.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-5/igt@gem_exec_re...@basic-write-read-noreloc.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][16] ([fdo#111656]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@gem_mmap_...@coherency.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-5/igt@gem_mmap_...@coherency.html
* igt@gem_pread@bench:
- {shard-rkl}:[SKIP][18] ([i915#3282]) -> [PASS][19] +2 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@gem_pr...@bench.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-5/igt@gem_pr...@bench.html
* igt@gen9_exec_parse@batch-invalid-length:
- {shard-rkl}:[SKIP][20] ([i915#2527]) -> [PASS][21] +3 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/shard-rkl-2/igt@gen9_exec_pa...@batch-invalid-length.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/shard-rkl-5/igt@gen9_exec_pa...@batch-invalid-length.html
* igt@i915_pipe_stress@stress-xrgb-untiled:
- {shard-tglu}: [SKIP][22] ([i915#1845]) -> [PASS][23]
[22]:
Re: [Intel-gfx] [PATCH v9 10/23] drm/i915/vm_bind: Add out fence support
On Mon, 2022-12-12 at 15:15 -0800, Niranjana Vishwanathapura wrote:
> Add support for handling out fence for vm_bind call.
>
> v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
> of vm_bind call.
> v3: Remove vm_unbind out fence uapi which is not supported yet.
> v4: Return error if I915_TIMELINE_FENCE_WAIT fence flag is set.
> Wait for bind to complete iff I915_TIMELINE_FENCE_SIGNAL is
> not specified.
> v5: Ensure __I915_TIMELINE_FENCE_UNKNOWN_FLAGS are not set.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
> Signed-off-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h | 4 +
> .../drm/i915/gem/i915_gem_vm_bind_object.c| 98 ++-
> drivers/gpu/drm/i915/i915_vma.c | 7 +-
> drivers/gpu/drm/i915/i915_vma_types.h | 7 ++
> include/uapi/drm/i915_drm.h | 58 ++-
> 5 files changed, 165 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> index 36262a6357b5..b70e900e35ab 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
> @@ -8,6 +8,7 @@
>
>
>
>
> #include
>
>
>
>
> +struct dma_fence;
> struct drm_device;
> struct drm_file;
> struct i915_address_space;
> @@ -23,4 +24,7 @@ int i915_gem_vm_unbind_ioctl(struct drm_device *dev, void
> *data,
>
>
>
>
> void i915_gem_vm_unbind_all(struct i915_address_space *vm);
>
>
>
>
> +void i915_vm_bind_signal_fence(struct i915_vma *vma,
> +struct dma_fence * const fence);
> +
> #endif /* __I915_GEM_VM_BIND_H */
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> index dc738677466b..fd1d82ce99e6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c
> @@ -7,6 +7,8 @@
>
>
>
>
> #include
>
>
>
>
> +#include
> +
> #include "gem/i915_gem_context.h"
> #include "gem/i915_gem_vm_bind.h"
>
>
>
>
> @@ -101,6 +103,77 @@ static void i915_gem_vm_bind_remove(struct i915_vma
> *vma, bool release_obj)
> i915_gem_object_put(vma->obj);
> }
>
>
>
>
> +static int i915_vm_bind_add_fence(struct drm_file *file, struct i915_vma
> *vma,
> + u32 handle, u64 point)
> +{
> + struct drm_syncobj *syncobj;
> +
> + syncobj = drm_syncobj_find(file, handle);
> + if (!syncobj) {
> + drm_dbg(>vm->i915->drm,
> + "Invalid syncobj handle provided\n");
> + return -ENOENT;
> + }
> +
> + /*
> + * For timeline syncobjs we need to preallocate chains for
> + * later signaling.
> + */
> + if (point) {
> + vma->vm_bind_fence.chain_fence = dma_fence_chain_alloc();
> + if (!vma->vm_bind_fence.chain_fence) {
> + drm_syncobj_put(syncobj);
> + return -ENOMEM;
> + }
> + } else {
> + vma->vm_bind_fence.chain_fence = NULL;
> + }
> + vma->vm_bind_fence.syncobj = syncobj;
> + vma->vm_bind_fence.value = point;
> +
> + return 0;
> +}
> +
> +static void i915_vm_bind_put_fence(struct i915_vma *vma)
> +{
> + if (!vma->vm_bind_fence.syncobj)
> + return;
> +
> + drm_syncobj_put(vma->vm_bind_fence.syncobj);
> + dma_fence_chain_free(vma->vm_bind_fence.chain_fence);
> + vma->vm_bind_fence.syncobj = NULL;
> +}
> +
> +/**
> + * i915_vm_bind_signal_fence() - Add fence to vm_bind syncobj
> + * @vma: vma mapping requiring signaling
> + * @fence: fence to be added
> + *
> + * Associate specified @fence with the @vma's syncobj to be
> + * signaled after the @fence work completes.
> + */
> +void i915_vm_bind_signal_fence(struct i915_vma *vma,
> +struct dma_fence * const fence)
> +{
> + struct drm_syncobj *syncobj = vma->vm_bind_fence.syncobj;
> +
> + if (!syncobj)
> + return;
> +
> + if (vma->vm_bind_fence.chain_fence) {
> + drm_syncobj_add_point(syncobj,
> + vma->vm_bind_fence.chain_fence,
> + fence, vma->vm_bind_fence.value);
> + /*
> + * The chain's ownership is transferred to the
> + * timeline.
> + */
> + vma->vm_bind_fence.chain_fence = NULL;
> + } else {
> + drm_syncobj_replace_fence(syncobj, fence);
> + }
> +}
> +
> static int i915_gem_vm_unbind_vma(struct i915_address_space *vm,
> struct drm_i915_gem_vm_unbind *va)
> {
> @@ -206,6 +279,11 @@ static int i915_gem_vm_bind_obj(struct
> i915_address_space *vm,
> if (!va->length || !IS_ALIGNED(va->start, I915_GTT_PAGE_SIZE))
> ret = -EINVAL;
>
>
>
>
> + /* In
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/pxp: Add MTL PXP Support
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support URL : https://patchwork.freedesktop.org/series/112647/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool CC [M] drivers/gpu/drm/i915/gt/intel_gt_irq.o In file included from drivers/gpu/drm/i915/gt/intel_gt_irq.c:16: ./drivers/gpu/drm/i915/pxp/intel_pxp_irq.h:42:21: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘intel_pxp_get_irq_gt’ 42 | struct intel_gt *gt intel_pxp_get_irq_gt(struct intel_pxp *pxp) | ^~~~ make[5]: *** [scripts/Makefile.build:252: drivers/gpu/drm/i915/gt/intel_gt_irq.o] Error 1 make[4]: *** [scripts/Makefile.build:504: drivers/gpu/drm/i915] Error 2 make[3]: *** [scripts/Makefile.build:504: drivers/gpu/drm] Error 2 make[2]: *** [scripts/Makefile.build:504: drivers/gpu] Error 2 make[1]: *** [scripts/Makefile.build:504: drivers] Error 2 make: *** [Makefile:2008: .] Error 2
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, Jan 10, 2023 at 04:39:00PM +, Matthew Brost wrote:
> On Tue, Jan 10, 2023 at 11:28:08AM +, Tvrtko Ursulin wrote:
> >
> >
> > On 09/01/2023 17:27, Jason Ekstrand wrote:
> >
> > [snip]
> >
> > > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > > contexts (per
> > > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > > invasive changes
> > > >>> to the shared code is in the spirit of the overall idea and
> > > instead
> > > >>> opportunity should be used to look at way to refactor/improve
> > > drm_sched.
> > >
> > >
> > > Maybe? I'm not convinced that what Xe is doing is an abuse at all or
> > > really needs to drive a re-factor. (More on that later.) There's only
> > > one real issue which is that it fires off potentially a lot of kthreads.
> > > Even that's not that bad given that kthreads are pretty light and you're
> > > not likely to have more kthreads than userspace threads which are much
> > > heavier. Not ideal, but not the end of the world either. Definitely
> > > something we can/should optimize but if we went through with Xe without
> > > this patch, it would probably be mostly ok.
> > >
> > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > >>
> > > >> I'm not really prepared to make large changes to DRM scheduler
> > > at the
> > > >> moment for Xe as they are not really required nor does Boris
> > > seem they
> > > >> will be required for his work either. I am interested to see
> > > what Boris
> > > >> comes up with.
> > > >>
> > > >>> Even on the low level, the idea to replace drm_sched threads
> > > with workers
> > > >>> has a few problems.
> > > >>>
> > > >>> To start with, the pattern of:
> > > >>>
> > > >>> while (not_stopped) {
> > > >>> keep picking jobs
> > > >>> }
> > > >>>
> > > >>> Feels fundamentally in disagreement with workers (while
> > > obviously fits
> > > >>> perfectly with the current kthread design).
> > > >>
> > > >> The while loop breaks and worker exists if no jobs are ready.
> > >
> > >
> > > I'm not very familiar with workqueues. What are you saying would fit
> > > better? One scheduling job per work item rather than one big work item
> > > which handles all available jobs?
> >
> > Yes and no, it indeed IMO does not fit to have a work item which is
> > potentially unbound in runtime. But it is a bit moot conceptual mismatch
> > because it is a worst case / theoretical, and I think due more fundamental
> > concerns.
> >
> > If we have to go back to the low level side of things, I've picked this
> > random spot to consolidate what I have already mentioned and perhaps expand.
> >
> > To start with, let me pull out some thoughts from workqueue.rst:
> >
> > """
> > Generally, work items are not expected to hog a CPU and consume many cycles.
> > That means maintaining just enough concurrency to prevent work processing
> > from stalling should be optimal.
> > """
> >
> > For unbound queues:
> > """
> > The responsibility of regulating concurrency level is on the users.
> > """
> >
> > Given the unbound queues will be spawned on demand to service all queued
> > work items (more interesting when mixing up with the system_unbound_wq), in
> > the proposed design the number of instantiated worker threads does not
> > correspond to the number of user threads (as you have elsewhere stated), but
> > pessimistically to the number of active user contexts. That is the number
> > which drives the maximum number of not-runnable jobs that can become
> > runnable at once, and hence spawn that many work items, and in turn unbound
> > worker threads.
> >
> > Several problems there.
> >
> > It is fundamentally pointless to have potentially that many more threads
> > than the number of CPU cores - it simply creates a scheduling storm.
> >
>
> We can use a different work queue if this is an issue, have a FIXME
> which indicates we should allow the user to pass in the work queue.
>
> > Unbound workers have no CPU / cache locality either and no connection with
> > the CPU scheduler to optimize scheduling patterns. This may matter either on
> > large systems or on small ones. Whereas the current design allows for
> > scheduler to notice userspace CPU thread keeps waking up the same drm
> > scheduler kernel thread, and so it can keep them on the same CPU, the
> > unbound workers lose that ability and so 2nd CPU might be getting woken up
> > from low sleep for every submission.
> >
>
> I guess I don't understand kthread vs. workqueue scheduling internals.
>
Looked into this and we are not using unbound workers rather we are just
using the system_wq which is indeed bound. Again we can change this so a
user can just pass in worker too. After doing a of research bound
workers allows the scheduler to use locality too avoid that exact
problem your
[Intel-gfx] [PATCH 2/2 v2] drm/i915: Replace alloc*workqueue with DRM helpers
Replace alloc*workqueue with DRM helpers in order to avoid memory leak
Because in `drivers/gpu/drm/i915/i915_driver.c`, if
intel_modeset_init_noirq fails, its workqueues will not be destroyed.
And drop the destroy_workqueue in intel_modeset_driver_remove_noirq to
avoid double free.
Moreover, check the return value since the workqueue may be NULL and
cause NULL pointer dereference.
Fixes: c26a058680dc ("drm/i915: Use a high priority wq for nonblocking plane
updates")
Fixes: 757fffcfdffb ("drm/i915: Put all non-blocking modesets onto an ordered
wq")
Signed-off-by: Jiasheng Jiang
---
Changelog:
v1 -> v2:
1. Drop the destroy_workqueue in intel_modeset_driver_remove_noirq.
---
drivers/gpu/drm/i915/display/intel_display.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c2686ecb62a..5cbec0af1773 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -8654,9 +8655,16 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
intel_dmc_ucode_init(i915);
- i915->display.wq.modeset = alloc_ordered_workqueue("i915_modeset", 0);
- i915->display.wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI |
- WQ_UNBOUND,
WQ_UNBOUND_MAX_ACTIVE);
+ ret = drmm_alloc_ordered_workqueue(>drm,
+ i915->display.wq.modeset,
"i915_modeset", 0);
+ if (ret)
+ goto cleanup_vga_client_pw_domain_dmc;
+
+ ret = drmm_alloc_workqueue(>drm, i915->display.wq.flip,
+ "i915_flip", WQ_HIGHPRI | WQ_UNBOUND,
+ WQ_UNBOUND_MAX_ACTIVE);
+ if (ret)
+ goto cleanup_vga_client_pw_domain_dmc;
intel_mode_config_init(i915);
@@ -9004,9 +9012,6 @@ void intel_modeset_driver_remove_noirq(struct
drm_i915_private *i915)
intel_gmbus_teardown(i915);
- destroy_workqueue(i915->display.wq.flip);
- destroy_workqueue(i915->display.wq.modeset);
-
intel_fbc_cleanup(i915);
}
--
2.25.1
[Intel-gfx] [PATCH 7/9] drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for uncore when touching
IRQ registers despite the pxp->ctrl_gt being the media-tile.
No difference for legacy of course.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 23 +---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..9f6e300486b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
if (!intel_pxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..2eef0c19e91a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -8,6 +8,7 @@
#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
+#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -17,6 +18,22 @@
#include "intel_pxp_types.h"
#include "intel_runtime_pm.h"
+/**
+ * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
+ * @pxp: pointer to pxp struct
+ *
+ * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
+ * but for MTL+ that has a media-tile, although the KCR engine is in the
+ * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
+ */
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ if (pxp->uses_gsccs)
+ return to_gt(pxp->ctrl_gt->i915);
+
+ return pxp->ctrl_gt;
+}
+
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
* @pxp: pointer to pxp struct
@@ -29,7 +46,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
return;
- gt = pxp->ctrl_gt;
+ gt = intel_pxp_get_irq_gt(pxp);
lockdep_assert_held(gt->irq_lock);
@@ -68,7 +85,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
void intel_pxp_irq_enable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
spin_lock_irq(gt->irq_lock);
@@ -83,7 +100,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
/*
* We always need to submit a global termination when we re-enable the
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8c292dc86f68..117159e19e94 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -9,6 +9,7 @@
#include
struct intel_pxp;
+struct intel_gt;
#define GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT BIT(1)
#define GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT BIT(2)
@@ -23,6 +24,8 @@ struct intel_pxp;
void intel_pxp_irq_enable(struct intel_pxp *pxp);
void intel_pxp_irq_disable(struct intel_pxp *pxp);
void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp);
+
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -35,6 +38,11 @@ static inline void intel_pxp_irq_enable(struct intel_pxp
*pxp)
static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
}
+
+struct intel_gt *gt intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ return NULL;
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
--
2.39.0
[Intel-gfx] [PATCH 8/9] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on the tee-component
operation before we can start sending GSC-CS firmware messages.
Thus, immediately enable KCR HW on PXP's init, fini and resume.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 52 ++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 10 ++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 13 +-
4 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 809b49f59594..90e739345924 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -143,10 +143,12 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- if (pxp->uses_gsccs)
+ if (pxp->uses_gsccs) {
ret = intel_pxp_gsccs_init(pxp);
- else
+ intel_pxp_init_hw(pxp, true);
+ } else {
ret = intel_pxp_tee_component_init(pxp);
+ }
if (ret)
goto out_context;
@@ -249,10 +251,12 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- if (i915->pxp->uses_gsccs)
+ if (i915->pxp->uses_gsccs) {
+ intel_pxp_fini_hw(i915->pxp, true);
intel_pxp_gsccs_fini(i915->pxp);
- else
+ } else {
intel_pxp_tee_component_fini(i915->pxp);
+ }
destroy_vcs_context(i915->pxp);
@@ -304,8 +308,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (!pxp->uses_gsccs)
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
mutex_lock(>arb_mutex);
@@ -331,16 +336,39 @@ int intel_pxp_start(struct intel_pxp *pxp)
return ret;
}
-void intel_pxp_init_hw(struct intel_pxp *pxp)
+static void
+intel_pxp_hw_state_change(struct intel_pxp *pxp, bool enable,
+ bool skip_if_runtime_pm_off)
+{
+ intel_wakeref_t wakeref;
+
+ if (skip_if_runtime_pm_off) {
+ /* if we are suspended, the HW will be re-initialized on resume
*/
+ wakeref =
intel_runtime_pm_get_if_in_use(>ctrl_gt->i915->runtime_pm);
+ if (!wakeref)
+ return;
+ }
+
+ if (enable) {
+ kcr_pxp_enable(pxp);
+ intel_pxp_irq_enable(pxp);
+ } else {
+ kcr_pxp_disable(pxp);
+ intel_pxp_irq_disable(pxp);
+ }
+
+ if (skip_if_runtime_pm_off)
+ intel_runtime_pm_put(>ctrl_gt->i915->runtime_pm, wakeref);
+}
+
+void intel_pxp_init_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off)
{
- kcr_pxp_enable(pxp);
- intel_pxp_irq_enable(pxp);
+ intel_pxp_hw_state_change(pxp, true, skip_if_runtime_pm_off);
}
-void intel_pxp_fini_hw(struct intel_pxp *pxp)
+void intel_pxp_fini_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off)
{
- kcr_pxp_disable(pxp);
- intel_pxp_irq_disable(pxp);
+ intel_pxp_hw_state_change(pxp, false, skip_if_runtime_pm_off);
}
int intel_pxp_key_check(struct intel_pxp *pxp,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 04440fada711..6c1fe3f0a20c 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -20,8 +20,8 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp);
int intel_pxp_init(struct drm_i915_private *i915);
void intel_pxp_fini(struct drm_i915_private *i915);
-void intel_pxp_init_hw(struct intel_pxp *pxp);
-void intel_pxp_fini_hw(struct intel_pxp *pxp);
+void intel_pxp_init_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off);
+void intel_pxp_fini_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 892d39cc61c1..94c1b2fe1eb2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -29,7 +29,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
return;
with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref) {
- intel_pxp_fini_hw(pxp);
+ intel_pxp_fini_hw(pxp, false);
pxp->hw_state_invalidated = false;
}
}
@@ -40,14 +40,14 @@ void intel_pxp_resume(struct intel_pxp *pxp)
return;
/*
-* The PXP component gets automatically unbound when we go into S3 and
+* On
[Intel-gfx] [PATCH 6/9] drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit which means the GSC firmware is busy and we should
resubmit.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 56 ++-
2 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index 52b9a61bcdd4..ee78c0817ba1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
@@ -27,4 +28,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID GENMASK(0, 0)
+ #define PXP43_INIT_SESSION_APPTYPE GENMASK(1, 1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_mode;
+ #define PXP43_INIT_SESSION_PROTECTION_ARB 0x2
+ u32 sub_session_id;
+ u32 init_flags;
+ u32 rsvd[12];
+} __packed;
+
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_out {
+ struct pxp_cmd_header header;
+ u32 rsvd[8];
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_43_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 84045e18591e..9fe30516eced 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -43,7 +43,8 @@ static inline struct gsccs_teelink_priv
*pxp_to_gsccs_priv(struct intel_pxp *pxp
static int gsccs_send_message(struct intel_pxp *pxp,
void *msg_in, size_t msg_in_size,
void *msg_out, size_t msg_out_size_max,
- size_t *msg_out_len)
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
{
struct intel_gt *gt = pxp->ctrl_gt;
struct drm_i915_private *i915 = gt->i915;
@@ -74,6 +75,9 @@ static int gsccs_send_message(struct intel_pxp *pxp,
intel_gsc_uc_heci_cmd_emit_mtl_header(header, MTL_HECI_CLIENT_PXP,
msg_in_size,
exec->host_session_handle, 0);
+ /* copy caller provided gsc message handle if this is polling for a
prior msg completion */
+ header->gsc_message_handle = *gsc_msg_handle_retry;
+
memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
pkt.addr_in = i915_vma_offset(exec->pkt_vma);
@@ -90,7 +94,7 @@ static int gsccs_send_message(struct intel_pxp *pxp,
goto unlock;
}
- /* we keep separate location for reply, so get the response header loc
first */
+ /* we keep separate location for reply, so go to the response header
now */
header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
/* Response validity marker, status and busyness */
@@ -107,6 +111,13 @@ static int gsccs_send_message(struct intel_pxp *pxp,
}
if (header->flags & MTL_GSC_HDR_FLAG_MSG_PENDING) {
drm_dbg(>drm, "gsc PXP reply is busy\n");
+ /*
+* When the GSC firmware replies with pending bit, it means
that the requested
+* operation has begun but the completion is pending and the
caller needs
+* to re-request with the gsc_message_handle that was returned
by the firmware.
+* until the pending bit is turned off.
+*/
+ *gsc_msg_handle_retry = header->gsc_message_handle;
ret = -EAGAIN;
goto unlock;
}
@@ -134,7 +145,46 @@ static int gsccs_send_message(struct intel_pxp *pxp,
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
{
- return -ENODEV;
+ struct gsccs_session_resources *exec =
_to_gsccs_priv(pxp)->arb_exec_res;
+ struct pxp43_create_arb_in msg_in = {0};
+ struct pxp43_create_arb_out msg_out = {0};
+ u64 gsc_session_retry = 0;
+ int insize, outsize, ret, tries = 0;
+ void *inptr, *outptr;
+
+ /* get a unique host-session-handle (used later in HW cmds) at time of
session creation */
+ get_random_bytes(>host_session_handle,
sizeof(exec->host_session_handle));
+
[Intel-gfx] [PATCH 5/9] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products. Use the newly
added helpers to populate the GSC-CS memory header and send the
message packet to the FW by dispatching the GSC_HECI_CMD_PKT
instruction on the GSC engine.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 97ca187e6fde..84045e18591e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,6 +6,7 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
@@ -39,6 +40,97 @@ static inline struct gsccs_teelink_priv
*pxp_to_gsccs_priv(struct intel_pxp *pxp
return (struct gsccs_teelink_priv *)pxp->gsccs_priv;
}
+static int gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec =
_to_gsccs_priv(pxp)->arb_exec_res;
+ struct intel_gsc_mtl_header *header = exec->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!intel_uc_uses_gsc_uc(>uc))
+ return -ENODEV;
+
+ if (!exec->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_IN_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ mutex_lock(>cmd_mutex);
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, MTL_HECI_CLIENT_PXP,
msg_in_size,
+ exec->host_session_handle, 0);
+
+ memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
+
+ pkt.addr_in = i915_vma_offset(exec->pkt_vma);
+ pkt.size_in = header->message_size;
+ pkt.addr_out = pkt.addr_in + PXP43_MAX_HECI_IN_SIZE;
+ pkt.size_out = msg_out_size_max + sizeof(*header);
+ pkt.heci_pkt_vma = exec->pkt_vma;
+ pkt.bb_vma = exec->bb_vma;
+
+ ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>ctrl_gt->uc.gsc,
+ exec->ce, ,
exec->bb_vaddr, 500);
+ if (ret) {
+ drm_err(>drm, "failed to send gsc PXP msg (%d)\n", ret);
+ goto unlock;
+ }
+
+ /* we keep separate location for reply, so get the response header loc
first */
+ header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
+
+ /* Response validity marker, status and busyness */
+ if (header->validity_marker != MTL_HECI_VALIDITY_MARKER) {
+ drm_err(>drm, "gsc PXP reply with invalid validity
marker\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->status != 0) {
+ drm_dbg(>drm, "gsc PXP reply status has error = 0x%08x\n",
+ header->status);
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->flags & MTL_GSC_HDR_FLAG_MSG_PENDING) {
+ drm_dbg(>drm, "gsc PXP reply is busy\n");
+ ret = -EAGAIN;
+ goto unlock;
+ }
+
+ reply_size = header->message_size - sizeof(*header);
+ if (reply_size > msg_out_size_max) {
+ drm_warn(>drm, "caller with insufficient PXP reply size
%u (%ld)\n",
+reply_size, msg_out_size_max);
+ reply_size = msg_out_size_max;
+ } else if (reply_size != msg_out_size_max) {
+ drm_dbg(>drm, "caller unexpected PXP reply size %u
(%ld)\n",
+ reply_size, msg_out_size_max);
+ }
+
+ memcpy(msg_out, exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE +
sizeof(*header),
+ reply_size);
+ if (msg_out_len)
+ *msg_out_len = reply_size;
+
+unlock:
+ mutex_unlock(>cmd_mutex);
+ return ret;
+}
+
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
{
--
2.39.0
[Intel-gfx] [PATCH 8/9] drm/i915/pxp: On MTL, KCR HW can be enabled instantly
On legacy platforms, KCR HW enabling is done at the time
the mei component interface is loaded. It's also disabled
during unbind. For MTL onwards, we don't need a separate
component driver to send FW messages via GSC-CS.
Thus, immediately enable KCR HW on PXP's init, fini
and resume.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 52 ++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 10 ++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 13 +-
4 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 809b49f59594..90e739345924 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -143,10 +143,12 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- if (pxp->uses_gsccs)
+ if (pxp->uses_gsccs) {
ret = intel_pxp_gsccs_init(pxp);
- else
+ intel_pxp_init_hw(pxp, true);
+ } else {
ret = intel_pxp_tee_component_init(pxp);
+ }
if (ret)
goto out_context;
@@ -249,10 +251,12 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- if (i915->pxp->uses_gsccs)
+ if (i915->pxp->uses_gsccs) {
+ intel_pxp_fini_hw(i915->pxp, true);
intel_pxp_gsccs_fini(i915->pxp);
- else
+ } else {
intel_pxp_tee_component_fini(i915->pxp);
+ }
destroy_vcs_context(i915->pxp);
@@ -304,8 +308,9 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (!pxp->uses_gsccs)
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
mutex_lock(>arb_mutex);
@@ -331,16 +336,39 @@ int intel_pxp_start(struct intel_pxp *pxp)
return ret;
}
-void intel_pxp_init_hw(struct intel_pxp *pxp)
+static void
+intel_pxp_hw_state_change(struct intel_pxp *pxp, bool enable,
+ bool skip_if_runtime_pm_off)
+{
+ intel_wakeref_t wakeref;
+
+ if (skip_if_runtime_pm_off) {
+ /* if we are suspended, the HW will be re-initialized on resume
*/
+ wakeref =
intel_runtime_pm_get_if_in_use(>ctrl_gt->i915->runtime_pm);
+ if (!wakeref)
+ return;
+ }
+
+ if (enable) {
+ kcr_pxp_enable(pxp);
+ intel_pxp_irq_enable(pxp);
+ } else {
+ kcr_pxp_disable(pxp);
+ intel_pxp_irq_disable(pxp);
+ }
+
+ if (skip_if_runtime_pm_off)
+ intel_runtime_pm_put(>ctrl_gt->i915->runtime_pm, wakeref);
+}
+
+void intel_pxp_init_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off)
{
- kcr_pxp_enable(pxp);
- intel_pxp_irq_enable(pxp);
+ intel_pxp_hw_state_change(pxp, true, skip_if_runtime_pm_off);
}
-void intel_pxp_fini_hw(struct intel_pxp *pxp)
+void intel_pxp_fini_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off)
{
- kcr_pxp_disable(pxp);
- intel_pxp_irq_disable(pxp);
+ intel_pxp_hw_state_change(pxp, false, skip_if_runtime_pm_off);
}
int intel_pxp_key_check(struct intel_pxp *pxp,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 04440fada711..6c1fe3f0a20c 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -20,8 +20,8 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp);
int intel_pxp_init(struct drm_i915_private *i915);
void intel_pxp_fini(struct drm_i915_private *i915);
-void intel_pxp_init_hw(struct intel_pxp *pxp);
-void intel_pxp_fini_hw(struct intel_pxp *pxp);
+void intel_pxp_init_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off);
+void intel_pxp_fini_hw(struct intel_pxp *pxp, bool skip_if_runtime_pm_off);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 892d39cc61c1..94c1b2fe1eb2 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -29,7 +29,7 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
return;
with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm, wakeref) {
- intel_pxp_fini_hw(pxp);
+ intel_pxp_fini_hw(pxp, false);
pxp->hw_state_invalidated = false;
}
}
@@ -40,14 +40,14 @@ void intel_pxp_resume(struct intel_pxp *pxp)
return;
/*
-* The PXP component gets automatically unbound when we go into S3 and
+* On Pre-MTL, PXP component gets
[Intel-gfx] [PATCH 7/9] drm/i915/pxp: MTL-KCR is in media-tile but IRQ-ctrl's in root
Add a helper for KCR hw interrupt enable/disable functions.
For MTL onwards, it will get the GT-0's handle including the
uncore fw bits and use that despite the pxp->ctrl_gt being
the media-tile. No difference for legacy of course.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 23 +---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
3 files changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..9f6e300486b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
if (!intel_pxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..2eef0c19e91a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -8,6 +8,7 @@
#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
+#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -17,6 +18,22 @@
#include "intel_pxp_types.h"
#include "intel_runtime_pm.h"
+/**
+ * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
+ * @pxp: pointer to pxp struct
+ *
+ * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
+ * but for MTL+ that has a media-tile, although the KCR engine is in the
+ * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
+ */
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ if (pxp->uses_gsccs)
+ return to_gt(pxp->ctrl_gt->i915);
+
+ return pxp->ctrl_gt;
+}
+
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
* @pxp: pointer to pxp struct
@@ -29,7 +46,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
return;
- gt = pxp->ctrl_gt;
+ gt = intel_pxp_get_irq_gt(pxp);
lockdep_assert_held(gt->irq_lock);
@@ -68,7 +85,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
void intel_pxp_irq_enable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
spin_lock_irq(gt->irq_lock);
@@ -83,7 +100,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
/*
* We always need to submit a global termination when we re-enable the
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8c292dc86f68..117159e19e94 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -9,6 +9,7 @@
#include
struct intel_pxp;
+struct intel_gt;
#define GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT BIT(1)
#define GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT BIT(2)
@@ -23,6 +24,8 @@ struct intel_pxp;
void intel_pxp_irq_enable(struct intel_pxp *pxp);
void intel_pxp_irq_disable(struct intel_pxp *pxp);
void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp);
+
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -35,6 +38,11 @@ static inline void intel_pxp_irq_enable(struct intel_pxp
*pxp)
static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
}
+
+struct intel_gt *gt intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ return NULL;
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
--
2.39.0
[Intel-gfx] [PATCH 9/9] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the timeouts for new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6cc65079b18d..a461db7ac2af 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1149,6 +1149,7 @@ static const struct intel_device_info mtl_info = {
.has_guc_deprivilege = 1,
.has_mslice_steering = 0,
.has_snoop = 1,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 7bb06e67b155..e4e60e3b9216 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -56,7 +56,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
reg,
mask,
in_play ? mask : 0,
- 100);
+ 250);
intel_runtime_pm_put(uncore->rpm, wakeref);
--
2.39.0
[Intel-gfx] [PATCH 4/9] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into (new) common heci-packet-submission files
to handle generating the MTL GSC-CS Memory-Header and emitting of
the Heci-Cmd-Packet instructions that gets submitted to the engine.
NOTE1: This common functions for heci-packet-submission will be used by
different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require very different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- When an internal subsystem needs to send a command request
to the security firmware on MTL onwards, it will send that
via the GSC-engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The command streamer DOES understand GSC_HECI_CMD_PKT but
requires an additional header before the "gsc_specific_fw_api"
is sent by the hw engine to the firmware (with additional
metadata).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers different for
GGTT (not in this series) vs PPGTT (this patch) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle everything else from
input/output packet size verification to handling the
responses from security firmware (such as requiring a retry).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 128 ++
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 74 ++
4 files changed, 205 insertions(+)
create mode 100644
[Intel-gfx] [PATCH 5/9] drm/i915/pxp: Add GSC-CS backend-teelink for send-message function
Populate the backend-teelink abstraction layer using GSC-CS engine
for MTL (and future) products. The PXP backend for sending messages
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 92 ++
1 file changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 97ca187e6fde..84045e18591e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,6 +6,7 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
@@ -39,6 +40,97 @@ static inline struct gsccs_teelink_priv
*pxp_to_gsccs_priv(struct intel_pxp *pxp
return (struct gsccs_teelink_priv *)pxp->gsccs_priv;
}
+static int gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec =
_to_gsccs_priv(pxp)->arb_exec_res;
+ struct intel_gsc_mtl_header *header = exec->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!intel_uc_uses_gsc_uc(>uc))
+ return -ENODEV;
+
+ if (!exec->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_IN_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ mutex_lock(>cmd_mutex);
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, MTL_HECI_CLIENT_PXP,
msg_in_size,
+ exec->host_session_handle, 0);
+
+ memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
+
+ pkt.addr_in = i915_vma_offset(exec->pkt_vma);
+ pkt.size_in = header->message_size;
+ pkt.addr_out = pkt.addr_in + PXP43_MAX_HECI_IN_SIZE;
+ pkt.size_out = msg_out_size_max + sizeof(*header);
+ pkt.heci_pkt_vma = exec->pkt_vma;
+ pkt.bb_vma = exec->bb_vma;
+
+ ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>ctrl_gt->uc.gsc,
+ exec->ce, ,
exec->bb_vaddr, 500);
+ if (ret) {
+ drm_err(>drm, "failed to send gsc PXP msg (%d)\n", ret);
+ goto unlock;
+ }
+
+ /* we keep separate location for reply, so get the response header loc
first */
+ header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
+
+ /* Response validity marker, status and busyness */
+ if (header->validity_marker != MTL_HECI_VALIDITY_MARKER) {
+ drm_err(>drm, "gsc PXP reply with invalid validity
marker\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->status != 0) {
+ drm_dbg(>drm, "gsc PXP reply status has error = 0x%08x\n",
+ header->status);
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->flags & MTL_GSC_HDR_FLAG_MSG_PENDING) {
+ drm_dbg(>drm, "gsc PXP reply is busy\n");
+ ret = -EAGAIN;
+ goto unlock;
+ }
+
+ reply_size = header->message_size - sizeof(*header);
+ if (reply_size > msg_out_size_max) {
+ drm_warn(>drm, "caller with insufficient PXP reply size
%u (%ld)\n",
+reply_size, msg_out_size_max);
+ reply_size = msg_out_size_max;
+ } else if (reply_size != msg_out_size_max) {
+ drm_dbg(>drm, "caller unexpected PXP reply size %u
(%ld)\n",
+ reply_size, msg_out_size_max);
+ }
+
+ memcpy(msg_out, exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE +
sizeof(*header),
+ reply_size);
+ if (msg_out_len)
+ *msg_out_len = reply_size;
+
+unlock:
+ mutex_unlock(>cmd_mutex);
+ return ret;
+}
+
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
{
--
2.39.0
[Intel-gfx] [PATCH 3/9] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 35
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 26 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 29 +++-
4 files changed, 70 insertions(+), 23 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 8fac2660e16b..957fa11373fc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -100,7 +100,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index be52bf92e847..809b49f59594 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,30 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static i915_reg_t get_kcr_reg(const struct intel_pxp *pxp)
+{
+ if (pxp->gsccs_priv)
+ return MTL_KCR_INIT;
+ return GEN12_KCR_INIT;
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ i915_reg_t reg = get_kcr_reg(pxp);
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, reg, val);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
+}
+
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
+{
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -323,14 +333,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..dd4131903d4e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR enable/disable control */
+#define GEN12_KCR_INIT _MMIO(0x320f0)
+#define MTL_KCR_INIT _MMIO(0x3860f0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define GEN12_KCR_SIP _MMIO(0x32260)
+#define MTL_KCR_SIP _MMIO(0x386260)
+
+/* PXP global terminate register for session termination */
+#define GEN12_KCR_GLOBAL_TERMINATE _MMIO(0x320f8)
+#define MTL_KCR_GLOBAL_TERMINATE _MMIO(0x3860f8)
+
+#endif /* __INTEL_PXP_REGS_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 080aa2209c5b..7bb06e67b155 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++
[Intel-gfx] [PATCH 2/9] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, PXP transport back-end uses the GSC engine to submit
HECI packets for PXP arb session management. The command submission
that uses non-priveleged mode requires us to allocate (or free)
a set of execution submission resources (buffer-object, batch-buffer
and context). Thus, do this one time allocation of resources in
GSC-CS init and clean them up in fini.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 6 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 216 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 5 +
3 files changed, 225 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..52b9a61bcdd4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -10,7 +10,11 @@
#include "intel_pxp_cmd_interface_cmn.h"
/* PXP-Cmd-Op definitions */
-#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_START_HUC_AUTH 0x003A
+
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
+#define PXP43_MAX_HECI_OUT_SIZE(SZ_32K)
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 21400650fc86..97ca187e6fde 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -3,9 +3,41 @@
* Copyright(c) 2023 Intel Corporation.
*/
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
#include "i915_drv.h"
-#include "intel_pxp_types.h"
+#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+struct gsccs_session_resources {
+ struct mutex cmd_mutex; /* Protects submission for arb session */
+ u64 host_session_handle; /* used by firmware to link commands to
sessions */
+
+ struct intel_context *ce; /* context for gsc command submission */
+ struct i915_ppgtt *ppgtt; /* ppgtt for gsc command submission */
+
+ struct drm_i915_gem_object *pkt_obj; /* PXP HECI message packet buffer
*/
+ struct i915_vma *pkt_vma; /* PXP HECI message packet vma */
+ void *pkt_vaddr; /* PXP HECI message packet virt memory pointer */
+
+ /* Buffer info for GSC engine batch buffer: */
+ struct drm_i915_gem_object *bb_obj; /* batch buffer object */
+ struct i915_vma *bb_vma; /* batch buffer vma */
+ void *bb_vaddr; /* batch buffer virtual memory pointer */
+};
+
+struct gsccs_teelink_priv {
+ /** @arb_exec_res: resources for arb-session GSC-CS PXP command
submission */
+ struct gsccs_session_resources arb_exec_res;
+};
+
+static inline struct gsccs_teelink_priv *pxp_to_gsccs_priv(struct intel_pxp
*pxp)
+{
+ return (struct gsccs_teelink_priv *)pxp->gsccs_priv;
+}
int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
int arb_session_id)
@@ -13,11 +45,193 @@ int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
return -ENODEV;
}
+static void
+gsccs_destroy_buffer(struct drm_i915_private *i915, struct i915_vma *vma,
+struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ i915_vma_unpin(vma);
+ err = i915_vma_unbind(vma);
+ if (err)
+ drm_dbg(>drm, "Unexpected failure when vma-unbinding =
%d\n", err);
+
+ i915_gem_object_unpin_map(obj);
+ i915_gem_object_unpin_pages(obj);
+ i915_gem_object_put(obj);
+}
+
+static int
+gsccs_create_buffer(struct drm_i915_private *i915, const char *bufname,
+ size_t size, struct i915_ppgtt *ppgtt,
+ struct drm_i915_gem_object **obj,
+ struct i915_vma **vma, void **map)
+{
+ int err = 0;
+
+ *obj = i915_gem_object_create_internal(i915, size);
+ if (IS_ERR(*obj)) {
+ drm_err(>drm, "Failed to allocate gsccs backend %s.\n",
bufname);
+ err = PTR_ERR(*obj);
+ goto out_none;
+ }
+
+ *vma = i915_vma_instance(*obj, >vm, NULL);
+ if (IS_ERR(*vma)) {
+ drm_err(>drm, "Failed to vma-instance gsccs backend
%s.\n", bufname);
+ err = PTR_ERR(*vma);
+ goto out_put;
+ }
+
+ err = i915_gem_object_pin_pages_unlocked(*obj);
+ if (err) {
+ drm_err(>drm, "Failed to pin gsccs backend %s.\n",
bufname);
+ goto out_put;
+ }
+
+ /* map to the virtual memory pointer */
+ *map = i915_gem_object_pin_map_unlocked(*obj,
i915_coherent_map_type(i915, *obj, true));
+ if (IS_ERR(*map)) {
+ drm_err(>drm, "Failed to map gsccs backend %s.\n",
bufname);
+ err = PTR_ERR(*map);
+ goto
[Intel-gfx] [PATCH 1/9] drm/i915/pxp: Add MTL PXP GSC-CS back-end skeleton
Add MTL PXP GSC-CS back-end stub functions hook them
up from PXP front-end and PXP session management functions.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 19 +---
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 23
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 18 +++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 6 -
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6 +
6 files changed, 69 insertions(+), 4 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index f47f00b162a4..eae4325310e8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -330,6 +330,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index cfc9af8b3d21..be52bf92e847 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (pxp->uses_gsccs)
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -157,6 +161,11 @@ static struct intel_gt
*find_gt_for_required_teelink(struct drm_i915_private *i9
return NULL;
}
+static bool pxp_has_gsccs(struct drm_i915_private *i915)
+{
+ return (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0));
+}
+
static struct intel_gt *find_gt_for_required_protected_content(struct
drm_i915_private *i915)
{
if (!IS_ENABLED(CONFIG_DRM_I915_PXP) || !INTEL_INFO(i915)->has_pxp)
@@ -167,7 +176,7 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
* the VDBOX is already present so skip that check
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (pxp_has_gsccs(i915))
return i915->media_gt;
/*
@@ -208,6 +217,7 @@ int intel_pxp_init(struct drm_i915_private *i915)
return -ENOMEM;
i915->pxp->ctrl_gt = gt;
+ i915->pxp->uses_gsccs = pxp_has_gsccs(i915);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +239,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (i915->pxp->uses_gsccs)
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..21400650fc86
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "i915_drv.h"
+#include "intel_pxp_types.h"
+#include "intel_pxp_gsccs.h"
+
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id)
+{
+ return -ENODEV;
+}
+
+void intel_pxp_gsccs_fini(struct intel_pxp *pxp)
+{
+}
+
+int intel_pxp_gsccs_init(struct intel_pxp *pxp)
+{
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
new file mode 100644
index ..967f8fc3b5b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2022, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_GSCCS_H__
+#define __INTEL_PXP_GSCCS_H__
+
+#include
+
+struct intel_pxp;
+
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id);
+void intel_pxp_gsccs_fini(struct intel_pxp *pxp);
+int intel_pxp_gsccs_init(struct intel_pxp *pxp);
+
+#endif /*__INTEL_PXP_GSCCS_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index ae413580b81a..080aa2209c5b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++
[Intel-gfx] [PATCH 0/9] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #4. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #6. Alan Previn (9): drm/i915/pxp: Add MTL PXP GSC-CS back-end skeleton drm/i915/pxp: Add GSC-CS back-end resource init and cleanup drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC drm/i915/pxp: Add GSC-CS backend to send GSC fw messages drm/i915/pxp: Add ARB session creation with new PXP API Ver4.3 drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component drm/i915/pxp: Enable PXP with MTL-GSC-CS drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_gt_irq.c| 3 +- .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 128 ++ .../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h | 74 drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 92 - drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 +- .../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 27 +- drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +- drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 379 ++ drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 18 + drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 23 +- drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 + drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 10 +- drivers/gpu/drm/i915/pxp/intel_pxp_regs.h | 26 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 37 +- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 13 +- drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 11 + 19 files changed, 804 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h base-commit: cc44a1e87ea6b788868878295119398966f98a81 -- 2.39.0
Re: [Intel-gfx] [PATCH v2] drm/i915/display: assume some pixelrate for src smaller than 1
On Tue, Jan 10, 2023 at 11:27:33PM +0200, Imre Deak wrote:
> On Sun, Jan 08, 2023 at 01:30:44PM +0200, Juha-Pekka Heikkila wrote:
> > intel_adjusted_rate() didn't take into account src rectangle
> > can be less than 1 in with or height.
>
> Thanks for catching this.
>
> > Signed-off-by: Juha-Pekka Heikkila
> > ---
> > drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > index 10e1fc9d0698..cd24d069b6eb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> > @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> > *src,
> > const struct drm_rect *dst,
> > unsigned int rate)
> > {
> > - unsigned int src_w, src_h, dst_w, dst_h;
> > + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
> >
> > src_w = drm_rect_width(src) >> 16;
> > src_h = drm_rect_height(src) >> 16;
> > @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> > *src,
> > dst_w = min(src_w, dst_w);
> > dst_h = min(src_h, dst_h);
> >
> > - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> > - dst_w * dst_h);
> > + /* in case src contained only fractional part */
> > + dst_wh = max(dst_w * dst_h, 1U);
> > +
> > + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
>
> The div-by-zero is avoided, but we'd return a 0 rate which doesn't look
> ok to me. I'd round up instead of down when converting src_w/h from
> fixed point to int above.
Looking at this more, src height < 1 isn't supported by the HW. I think
this config should be rejected already by skl_check_main_surface(), as
it's done on all other platforms.
> > }
> >
> > unsigned int intel_plane_pixel_rate(const struct intel_crtc_state
> > *crtc_state,
> > --
> > 2.39.0
> >
Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/mtl: update scaler source and destination limits for MTL
Merged the two patches. Thanks for the review and the patch.
Regards,
Radhakrishna(RK) Sripada
> -Original Message-
> From: Intel-gfx On Behalf Of
> Lisovskiy, Stanislav
> Sent: Sunday, January 8, 2023 11:32 PM
> To: Coelho, Luciano
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v7 2/2] drm/i915/mtl: update scaler source and
> destination limits for MTL
>
> On Fri, Dec 23, 2022 at 03:05:09PM +0200, Luca Coelho wrote:
> > From: Animesh Manna
> >
> > The max source and destination limits for scalers in MTL have changed.
> > Use the new values accordingly.
> >
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Animesh Manna
> > Signed-off-by: Luca Coelho
> > ---
> >
> > In v2:
> >* No changes;
> >
> > In v3:
> >* Removed stray reviewed-by tag;
> >* Added my s-o-b.
> >
> > In v4:
> >* No changes.
> >
> > In v5:
> >* Just resent with a cover letter.
> >
> > In v6:
> >* Now the correct version again (same as v4).
> >
> > In v7:
> >* Update to new MTL limits according to the bspec.
> >
> >
> > drivers/gpu/drm/i915/display/skl_scaler.c | 40 ++-
> > 1 file changed, 32 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
> b/drivers/gpu/drm/i915/display/skl_scaler.c
> > index d7390067b7d4..01e881293612 100644
> > --- a/drivers/gpu/drm/i915/display/skl_scaler.c
> > +++ b/drivers/gpu/drm/i915/display/skl_scaler.c
> > @@ -87,6 +87,10 @@ static u16 skl_scaler_calc_phase(int sub, int scale, bool
> chroma_cosited)
> > #define ICL_MAX_SRC_H 4096
> > #define ICL_MAX_DST_W 5120
> > #define ICL_MAX_DST_H 4096
> > +#define MTL_MAX_SRC_W 4096
> > +#define MTL_MAX_SRC_H 8192
> > +#define MTL_MAX_DST_W 8192
> > +#define MTL_MAX_DST_H 8192
> > #define SKL_MIN_YUV_420_SRC_W 16
> > #define SKL_MIN_YUV_420_SRC_H 16
> >
> > @@ -103,6 +107,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
> bool force_detach,
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > const struct drm_display_mode *adjusted_mode =
> > _state->hw.adjusted_mode;
> > + int min_src_w, min_src_h, min_dst_w, min_dst_h;
> > + int max_src_w, max_src_h, max_dst_w, max_dst_h;
> >
> > /*
> > * Src coordinates are already rotated by 270 degrees for
> > @@ -157,15 +163,33 @@ skl_update_scaler(struct intel_crtc_state
> *crtc_state, bool force_detach,
> > return -EINVAL;
> > }
> >
> > + min_src_w = SKL_MIN_SRC_W;
> > + min_src_h = SKL_MIN_SRC_H;
> > + min_dst_w = SKL_MIN_DST_W;
> > + min_dst_h = SKL_MIN_DST_H;
> > +
> > + if (DISPLAY_VER(dev_priv) < 11) {
> > + max_src_w = SKL_MAX_SRC_W;
> > + max_src_h = SKL_MAX_SRC_H;
> > + max_dst_w = SKL_MAX_DST_W;
> > + max_dst_h = SKL_MAX_DST_H;
> > + } else if (DISPLAY_VER(dev_priv) < 14) {
> > + max_src_w = ICL_MAX_SRC_W;
> > + max_src_h = ICL_MAX_SRC_H;
> > + max_dst_w = ICL_MAX_DST_W;
> > + max_dst_h = ICL_MAX_DST_H;
> > + } else {
> > + max_src_w = MTL_MAX_SRC_W;
> > + max_src_h = MTL_MAX_SRC_H;
> > + max_dst_w = MTL_MAX_DST_W;
> > + max_dst_h = MTL_MAX_DST_H;
> > + }
> > +
> > /* range checks */
> > - if (src_w < SKL_MIN_SRC_W || src_h < SKL_MIN_SRC_H ||
> > - dst_w < SKL_MIN_DST_W || dst_h < SKL_MIN_DST_H ||
> > - (DISPLAY_VER(dev_priv) >= 11 &&
> > -(src_w > ICL_MAX_SRC_W || src_h > ICL_MAX_SRC_H ||
> > - dst_w > ICL_MAX_DST_W || dst_h > ICL_MAX_DST_H)) ||
> > - (DISPLAY_VER(dev_priv) < 11 &&
> > -(src_w > SKL_MAX_SRC_W || src_h > SKL_MAX_SRC_H ||
> > - dst_w > SKL_MAX_DST_W || dst_h > SKL_MAX_DST_H))) {
> > + if (src_w < min_src_w || src_h < min_src_h ||
> > + dst_w < min_dst_w || dst_h < min_dst_h ||
> > + src_w > max_src_w || src_h > max_src_h ||
> > + dst_w > max_dst_w || dst_h > max_dst_h) {
>
> Yep, that looks definitely way cleaner than initial condition.
>
> Reviewed-by: Stanislav Lisovskiy
>
> > drm_dbg_kms(_priv->drm,
> > "scaler_user index %u.%u: src %ux%u dst %ux%u "
> > "size is out of scaler range\n",
> > --
> > 2.39.0
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Avoid full proxy f_ops debug attributes
== Series Details ==
Series: drm/i915/gvt: Avoid full proxy f_ops debug attributes
URL : https://patchwork.freedesktop.org/series/112630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569 -> Patchwork_112630v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/index.html
Participating hosts (41 -> 40)
--
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112630v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][1] -> [FAIL][2] ([i915#7229])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live@guc_hang:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][3] ([i915#7640])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/fi-kbl-soraka/igt@i915_selftest@live@guc_hang.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][4] -> [FAIL][5] ([i915#6298])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_lrc:
- {bat-adlp-9}: [INCOMPLETE][8] ([i915#4983]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@guc_multi_lrc:
- fi-kbl-soraka: [INCOMPLETE][10] ([i915#7640]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/fi-kbl-soraka/igt@i915_selftest@live@guc_multi_lrc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/fi-kbl-soraka/igt@i915_selftest@live@guc_multi_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7640]: https://gitlab.freedesktop.org/drm/intel/issues/7640
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12569 -> Patchwork_112630v1
CI-20190529: 20190529
CI_DRM_12569: 739b2ee4e76d9cd64e5fbe834b682e550e496cf4 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7115: c162d70b00c6f4cf6a0ba1ca7a7e2ad8f7190646 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112630v1: 739b2ee4e76d9cd64e5fbe834b682e550e496cf4 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
f66b7a25610a drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug
attributes
26f67451ed4f drm/i915/gvt: Avoid full proxy f_ops for scan_nonprivbb debug
attributes
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112630v1/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gvt: Avoid full proxy f_ops debug attributes
== Series Details == Series: drm/i915/gvt: Avoid full proxy f_ops debug attributes URL : https://patchwork.freedesktop.org/series/112630/ State : warning == Summary == Error: dim checkpatch failed 4c95e9b71212 drm/i915/gvt: Avoid full proxy f_ops for scan_nonprivbb debug attributes -:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #21: make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci total: 0 errors, 1 warnings, 0 checks, 22 lines checked 33d68a01cad3 drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes -:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #21: make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci total: 0 errors, 1 warnings, 0 checks, 18 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid full proxy f_ops debug attributes
== Series Details ==
Series: drm/i915: Avoid full proxy f_ops debug attributes
URL : https://patchwork.freedesktop.org/series/112625/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569 -> Patchwork_112625v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/index.html
Participating hosts (41 -> 41)
--
Additional (1): fi-rkl-11600
Missing(1): fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112625v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/fi-kbl-soraka/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7561])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@guc_hang:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][8] ([i915#7640])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-kbl-soraka/igt@i915_selftest@live@guc_hang.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][9] ([i915#4817])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#7828]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#4103])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109285] / [i915#4098])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#3555] / [i915#4098])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] /
[i915#3708])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][17] ([i915#5334]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112625v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_lrc:
- {bat-adlp-9}: [INCOMPLETE][19] ([i915#4983]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
[20]:
Re: [Intel-gfx] [PATCH v2] drm/i915/display: assume some pixelrate for src smaller than 1
On Sun, Jan 08, 2023 at 01:30:44PM +0200, Juha-Pekka Heikkila wrote:
> intel_adjusted_rate() didn't take into account src rectangle
> can be less than 1 in with or height.
Thanks for catching this.
> Signed-off-by: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 10e1fc9d0698..cd24d069b6eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> *src,
>const struct drm_rect *dst,
>unsigned int rate)
> {
> - unsigned int src_w, src_h, dst_w, dst_h;
> + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
>
> src_w = drm_rect_width(src) >> 16;
> src_h = drm_rect_height(src) >> 16;
> @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> *src,
> dst_w = min(src_w, dst_w);
> dst_h = min(src_h, dst_h);
>
> - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> - dst_w * dst_h);
> + /* in case src contained only fractional part */
> + dst_wh = max(dst_w * dst_h, 1U);
> +
> + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
The div-by-zero is avoided, but we'd return a 0 rate which doesn't look
ok to me. I'd round up instead of down when converting src_w/h from
fixed point to int above.
> }
>
> unsigned int intel_plane_pixel_rate(const struct intel_crtc_state
> *crtc_state,
> --
> 2.39.0
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Implement workaround for DP2 UHBR bandwidth check (rev2)
== Series Details ==
Series: drm/i915: Implement workaround for DP2 UHBR bandwidth check (rev2)
URL : https://patchwork.freedesktop.org/series/112345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12567_full -> Patchwork_112345v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/index.html
Participating hosts (14 -> 10)
--
Missing(4): shard-rkl0 pig-kbl-iris pig-glk-j5005 pig-skl-6260u
Known issues
Here are the changes found in Patchwork_112345v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-glk6/igt@gem_exec_fair@basic-p...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-glk2/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-glk4/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-1/igt@drm_fdinfo@i...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html
* igt@gem_create@hog-create@smem0:
- {shard-rkl}:[FAIL][7] ([i915#7679]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-2/igt@gem_create@hog-cre...@smem0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@gem_create@hog-cre...@smem0.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:[FAIL][9] ([fdo#103375]) -> [PASS][10] +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-3/igt@gem_...@in-flight-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-6/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_endless@dispatch@bcs0:
- {shard-rkl}:[SKIP][11] ([i915#6247]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-cmd:
- {shard-rkl}:[SKIP][15] ([fdo#109313]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-2/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@gem_exec_fl...@basic-batch-kernel-default-cmd.html
* igt@gem_exec_reloc@basic-gtt-wc-noreloc:
- {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +10 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-6/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][19] ([fdo#111656]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-1/igt@gem_mmap_...@coherency.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@gem_mmap_...@coherency.html
* igt@gem_pwrite_snooped:
- {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +8 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-6/igt@gem_pwrite_snooped.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@gem_pwrite_snooped.html
* igt@gen9_exec_parse@bb-chained:
- {shard-rkl}:[SKIP][23] ([i915#2527]) -> [PASS][24] +3 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/shard-rkl-1/igt@gen9_exec_pa...@bb-chained.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/shard-rkl-5/igt@gen9_exec_pa...@bb-chained.html
*
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Avoid full proxy f_ops debug attributes
== Series Details == Series: drm/i915: Avoid full proxy f_ops debug attributes URL : https://patchwork.freedesktop.org/series/112625/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid full proxy f_ops debug attributes
== Series Details ==
Series: drm/i915: Avoid full proxy f_ops debug attributes
URL : https://patchwork.freedesktop.org/series/112625/
State : warning
== Summary ==
Error: dim checkpatch failed
96ecad527e9e drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes
-:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#21:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
-:47: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#47: FILE: drivers/gpu/drm/i915/display/intel_drrs.c:386:
+ debugfs_create_file_unsafe("i915_drrs_ctl", 0644,
crtc->base.debugfs_entry,
+ crtc, _drrs_debugfs_ctl_fops);
total: 0 errors, 1 warnings, 1 checks, 20 lines checked
30587136fb9e drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
-:20: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#20:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
total: 0 errors, 1 warnings, 0 checks, 24 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add missing check and destroy for alloc_workqueue
== Series Details ==
Series: drm/i915: Add missing check and destroy for alloc_workqueue
URL : https://patchwork.freedesktop.org/series/112623/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569 -> Patchwork_112623v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-rkl-11600
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112623v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#7561])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][6] ([i915#4817])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7828]) +7 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#4103])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([fdo#109285] / [i915#4098])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#1072]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#4098])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301] /
[i915#3708])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {bat-adlp-9}: [INCOMPLETE][14] ([i915#4983]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112623v1/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4098]:
Re: [Intel-gfx] [PATCH] drm/i915/display: Check source height is > 0
On Tue, Jan 03, 2023 at 12:42:43PM +0200, Juha-Pekka Heikkila wrote:
> Hi Drew,
Hi Juha-Pekka, sorry for the late response since I was on vacation.
>
> this is good find. I went looking where the problem is in and saw what you
> probably also saw earlier.
>
> I was wondering if diff below would be better fix? I assume this would end
> up with einval or erange in your case but code flow otherwise would stay as
> is while fixing all future callers for same issue:
Yes, the function you identify below is where I encountered
divide-by-zero errors. If width/height less than 1 is a legitimate use
case, then your proposed solution looks like it would be better. It
should have no risk of regression in userspace either, which is nice.
I tested your patch, and as expected I did not hit the divide-by-zero
error, though the test commit was rejected due to a check further along
inside skl_update_scaler. Perhaps there is some other configuration
which would pass the test commit with a width/height less than 1, but I
didn't dig much further.
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 10e1fc9d0698..a9948e8d3543 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -144,7 +144,7 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> *src,
> const struct drm_rect *dst,
> unsigned int rate)
> {
> - unsigned int src_w, src_h, dst_w, dst_h;
> + unsigned int src_w, src_h, dst_w, dst_h, dst_wh;
>
> src_w = drm_rect_width(src) >> 16;
> src_h = drm_rect_height(src) >> 16;
> @@ -155,8 +155,10 @@ unsigned int intel_adjusted_rate(const struct drm_rect
> *src,
> dst_w = min(src_w, dst_w);
> dst_h = min(src_h, dst_h);
>
> - return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h),
> - dst_w * dst_h);
> + /* in case src contained only fractional part */
> + dst_wh = max(dst_w * dst_h, (unsigned) 1);
> +
> + return DIV_ROUND_UP_ULL(mul_u32_u32(rate, src_w * src_h), dst_wh);
> }
>
> unsigned int intel_plane_pixel_rate(const struct intel_crtc_state
> *crtc_state,
>
>
> What do you think? I'll in any case come up with some test for this in igt.
I see that you've posted your fix to the list already. Adding a
test to cover this in IGT also sounds great. Thanks!
Breadcrumbs to Juha-Pekka's patch for anyone following this
thread: https://patchwork.freedesktop.org/series/112396/
>
> /Juha-Pekka
>
> On 27.12.2022 7.53, Drew Davenport wrote:
> > The error message suggests that the height of the src rect must be at
> > least 1. Reject source with height of 0.
> >
> > Signed-off-by: Drew Davenport
> >
> > ---
> > I was investigating some divide-by-zero crash reports on ChromeOS which
> > pointed to the intel_adjusted_rate function. Further prodding showed
> > that I could reproduce this in a simple test program if I made src_h
> > some value less than 1 but greater than 0.
> >
> > This seemed to be a sensible place to check that the source height is at
> > least 1. I tried to repro this issue on an amd device I had on hand, and
> > the configuration was rejected.
> >
> > Would it make sense to add a check that source dimensions are at least 1
> > somewhere in core, like in drm_atomic_plane_check? Or is that a valid
> > use case on some devices, and thus any such check should be done on a
> > per-driver basis?
> >
> > Thanks.
> >
> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index 4b79c2d2d6177..9b172a1e90deb 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -1627,7 +1627,7 @@ static int skl_check_main_surface(struct
> > intel_plane_state *plane_state)
> > u32 offset;
> > int ret;
> > - if (w > max_width || w < min_width || h > max_height) {
> > + if (w > max_width || w < min_width || h > max_height || h < 1) {
> > drm_dbg_kms(_priv->drm,
> > "requested Y/RGB source size %dx%d outside limits
> > (min: %dx1 max: %dx%d)\n",
> > w, h, min_width, max_width, max_height);
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Replace zero-length arrays with flexible-array members
== Series Details ==
Series: drm/i915/guc: Replace zero-length arrays with flexible-array members
URL : https://patchwork.freedesktop.org/series/112621/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569 -> Patchwork_112621v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-rkl-11600
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112621v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#7561])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][6] ([i915#4817])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7828]) +7 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#4103])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([fdo#109285] / [i915#4098])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#1072]) +3 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#4098])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301] /
[i915#3708])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {bat-adlp-9}: [INCOMPLETE][14] ([i915#4983]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112621v1/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
Re: [Intel-gfx] [PATCH][next] drm/i915/guc: Replace zero-length arrays with flexible-array members
On Tue, Jan 10, 2023 at 02:28:11PM -0500, Rodrigo Vivi wrote:
>
> On Tue, Jan 10, 2023 at 10:44:53AM -0600, Gustavo A. R. Silva wrote:
> > Zero-length arrays are deprecated[1] and we are moving towards
> > adopting C99 flexible-array members, instead. So, replace zero-length
> > arrays in a couple of structures (three, actually) with flex-array
> > members.
> >
> > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> > routines on memcpy() and help us make progress towards globally
> > enabling -fstrict-flex-arrays=3 [2].
> >
> > Link:
> > https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays
> > [1]
> > Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2]
> > Link: https://github.com/KSPP/linux/issues/78
> > Signed-off-by: Gustavo A. R. Silva
>
> > ---
> > drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> > b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> > index 3624abfd22d1..9d589c28f40f 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> > @@ -73,7 +73,7 @@ struct guc_debug_capture_list_header {
> >
> > struct guc_debug_capture_list {
> > struct guc_debug_capture_list_header header;
> > - struct guc_mmio_reg regs[0];
> > + struct guc_mmio_reg regs[];
> > } __packed;
> >
> > /**
> > @@ -125,7 +125,7 @@ struct guc_state_capture_header_t {
> >
> > struct guc_state_capture_t {
> > struct guc_state_capture_header_t header;
> > - struct guc_mmio_reg mmio_entries[0];
> > + struct guc_mmio_reg mmio_entries[];
> > } __packed;
> >
> > enum guc_capture_group_types {
> > @@ -145,7 +145,7 @@ struct guc_state_capture_group_header_t {
> > /* this is the top level structure where an error-capture dump starts */
> > struct guc_state_capture_group_t {
> > struct guc_state_capture_group_header_t grp_header;
> > - struct guc_state_capture_t capture_entries[0];
> > + struct guc_state_capture_t capture_entries[];
>
> Please notice we are currently using sizeof(struct ...).
Yep; I noticed that. :)
> Along with your proposed changes, shouldn't we also start using
> the struct_size() which already take the flexible array into account?
Not necessarily. In recent times, we don't include the struct_size
changes in the same patch as the flex-array transformation. That's
usually a follow-up patch.
--
Gustavo
[Intel-gfx] ✓ Fi.CI.BAT: success for ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops (rev3)
== Series Details ==
Series: ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell
laptops (rev3)
URL : https://patchwork.freedesktop.org/series/112572/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12569 -> Patchwork_112572v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-rkl-11600
Missing(2): fi-kbl-soraka fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112572v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][2] ([i915#7793])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#7561])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [FAIL][7] ([fdo#103375])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#7828]) +7 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#4103])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([fdo#109285] / [i915#4098])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#1072]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#3555] / [i915#4098])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3301] /
[i915#3708])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/fi-rkl-11600/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {bat-adlp-9}: [INCOMPLETE][15] ([i915#4983]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/bat-adlp-9/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gt_pm:
- {bat-rpls-2}: [DMESG-FAIL][17] ([i915#4258]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12569/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112572v3/bat-rpls-2/igt@i915_selftest@live@gt_pm.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109285]:
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Do not cover all future platforms in TLB invalidation (rev3)
== Series Details ==
Series: drm/i915: Do not cover all future platforms in TLB invalidation (rev3)
URL : https://patchwork.freedesktop.org/series/112484/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12566_full -> Patchwork_112484v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/index.html
Participating hosts (13 -> 10)
--
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
Here are the changes found in Patchwork_112484v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-glk7/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-glk2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_cursor_crc@cursor-offscreen-512x170:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271]) +16 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-glk1/igt@kms_cursor_...@cursor-offscreen-512x170.html
Possible fixes
* igt@drm_read@short-buffer-nonblock:
- {shard-rkl}:[SKIP][6] ([i915#4098]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-rkl-5/igt@drm_r...@short-buffer-nonblock.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-rkl-6/igt@drm_r...@short-buffer-nonblock.html
* igt@gem_eio@kms:
- {shard-dg1}:[FAIL][8] ([i915#5784]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-dg1-12/igt@gem_...@kms.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-dg1-15/igt@gem_...@kms.html
* igt@gem_exec_reloc@basic-gtt-wc-noreloc:
- {shard-rkl}:[SKIP][10] ([i915#3281]) -> [PASS][11] +10 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-rkl-3/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-rkl-5/igt@gem_exec_re...@basic-gtt-wc-noreloc.html
* igt@gem_lmem_swapping@heavy-verify-multi@lmem0:
- {shard-dg1}:[DMESG-WARN][12] -> [PASS][13] +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-dg1-15/igt@gem_lmem_swapping@heavy-verify-mu...@lmem0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-dg1-16/igt@gem_lmem_swapping@heavy-verify-mu...@lmem0.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][14] ([fdo#111656]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-rkl-2/igt@gem_mmap_...@coherency.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-rkl-5/igt@gem_mmap_...@coherency.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- {shard-rkl}:[SKIP][16] ([i915#3282]) -> [PASS][17] +7 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-rkl-2/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-rkl-5/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [DMESG-WARN][18] ([i915#5566] / [i915#716]) ->
[PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
* igt@gen9_exec_parse@bb-chained:
- {shard-rkl}:[SKIP][20] ([i915#2527]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-rkl-2/igt@gen9_exec_pa...@bb-chained.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-rkl-5/igt@gen9_exec_pa...@bb-chained.html
* igt@i915_pm_dc@dc9-dpms:
- {shard-rkl}:[SKIP][22] ([i915#3361]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/shard-rkl-5/igt@i915_pm...@dc9-dpms.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/shard-rkl-6/igt@i915_pm...@dc9-dpms.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-dg1}:[SKIP][24] ([i915#1397]) ->
Re: [Intel-gfx] [PATCH][next] drm/i915/guc: Replace zero-length arrays with flexible-array members
On Tue, Jan 10, 2023 at 10:44:53AM -0600, Gustavo A. R. Silva wrote:
> Zero-length arrays are deprecated[1] and we are moving towards
> adopting C99 flexible-array members, instead. So, replace zero-length
> arrays in a couple of structures (three, actually) with flex-array
> members.
>
> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> routines on memcpy() and help us make progress towards globally
> enabling -fstrict-flex-arrays=3 [2].
>
> Link:
> https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays
> [1]
> Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2]
> Link: https://github.com/KSPP/linux/issues/78
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> index 3624abfd22d1..9d589c28f40f 100644
> --- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
> @@ -73,7 +73,7 @@ struct guc_debug_capture_list_header {
>
> struct guc_debug_capture_list {
> struct guc_debug_capture_list_header header;
> - struct guc_mmio_reg regs[0];
> + struct guc_mmio_reg regs[];
> } __packed;
>
> /**
> @@ -125,7 +125,7 @@ struct guc_state_capture_header_t {
>
> struct guc_state_capture_t {
> struct guc_state_capture_header_t header;
> - struct guc_mmio_reg mmio_entries[0];
> + struct guc_mmio_reg mmio_entries[];
> } __packed;
>
> enum guc_capture_group_types {
> @@ -145,7 +145,7 @@ struct guc_state_capture_group_header_t {
> /* this is the top level structure where an error-capture dump starts */
> struct guc_state_capture_group_t {
> struct guc_state_capture_group_header_t grp_header;
> - struct guc_state_capture_t capture_entries[0];
> + struct guc_state_capture_t capture_entries[];
Please notice we are currently using sizeof(struct ...).
Along with your proposed changes, shouldn't we also start using
the struct_size() which already take the flexible array into account?
> } __packed;
>
> /**
> --
> 2.34.1
>
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops (rev3)
== Series Details == Series: ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops (rev3) URL : https://patchwork.freedesktop.org/series/112572/ State : warning == Summary == Error: dim checkpatch failed 7f834ef56961 ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops -:57: WARNING:BAD_SIGN_OFF: Co-developed-by and Signed-off-by: name/email do not match #57: Co-developed-by: Rafael J. Wysocki Signed-off-by: Hans de Goede total: 0 errors, 1 warnings, 0 checks, 50 lines checked
Re: [Intel-gfx] [PATCH] drm/i915: Implement workaround for DP2 UHBR bandwidth check
On Tue, Jan 10, 2023 at 02:33:38PM +0200, Stanislav Lisovskiy wrote:
> According to spec, we should check if output_bpp * pixel_rate is less
> than DDI clock * 72, if UHBR is used.
>
> HSDES: 1406899791
> BSPEC: 49259
>
> v2: - Removed wrong comment(Rodrigo Vivi)
> - Added HSDES to the commit msg(Rodrigo Vivi)
> - Moved UHBR check to the MST specific code
I'm afraid you forgot to remove the "workaround" from the patch subject.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 8b0e4defa3f1..1f1f7f5f6501 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -339,10 +339,19 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
> conn_state, ,
> pipe_config->dp_m_n.tu,
> false);
> - }
> + if (ret < 0)
> + return ret;
>
> - if (ret)
> - return ret;
> + if (intel_dp_is_uhbr(pipe_config)) {
> + int output_bpp = pipe_config->dsc.compressed_bpp;
> +
> + if (output_bpp * adjusted_mode->crtc_clock >=
> + pipe_config->port_clock * 72) {
> + drm_dbg_kms(_priv->drm, "DP2 UHBR check
> failed\n");
I'm wondering if I misunderstood your recent reply but I believe you told
this
has nothing to do with DP2.0 so why we have DP2 in the msg still?
I believe that or:
1. We are sure this case is only happening on DP2.0 because it is impossible
2. or because we are adding a DP2.0 check
3. or we don't mention DP2.0
With the subject and the comment fixed:
Reviewed-by: Rodrigo Vivi
> + return -EINVAL;
> + }
> + }
> + }
>
> ret = intel_dp_mst_update_slots(encoder, pipe_config, conn_state);
> if (ret)
> --
> 2.37.3
>
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, Jan 10, 2023 at 04:50:55PM +, Tvrtko Ursulin wrote:
>
> On 10/01/2023 15:55, Matthew Brost wrote:
> > On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
> > >
> > > On 10/01/2023 11:28, Tvrtko Ursulin wrote:
> > > >
> > > >
> > > > On 09/01/2023 17:27, Jason Ekstrand wrote:
> > > >
> > > > [snip]
> > > >
> > > > > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > > > > contexts (per
> > > > > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > > > > invasive changes
> > > > > >>> to the shared code is in the spirit of the overall idea and
> > > > > instead
> > > > > >>> opportunity should be used to look at way to
> > > > > refactor/improve
> > > > > drm_sched.
> > > > >
> > > > >
> > > > > Maybe? I'm not convinced that what Xe is doing is an abuse at all
> > > > > or really needs to drive a re-factor. (More on that later.)
> > > > > There's only one real issue which is that it fires off potentially a
> > > > > lot of kthreads. Even that's not that bad given that kthreads are
> > > > > pretty light and you're not likely to have more kthreads than
> > > > > userspace threads which are much heavier. Not ideal, but not the
> > > > > end of the world either. Definitely something we can/should
> > > > > optimize but if we went through with Xe without this patch, it would
> > > > > probably be mostly ok.
> > > > >
> > > > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > > > >>
> > > > > >> I'm not really prepared to make large changes to DRM
> > > > > scheduler
> > > > > at the
> > > > > >> moment for Xe as they are not really required nor does Boris
> > > > > seem they
> > > > > >> will be required for his work either. I am interested to see
> > > > > what Boris
> > > > > >> comes up with.
> > > > > >>
> > > > > >>> Even on the low level, the idea to replace drm_sched threads
> > > > > with workers
> > > > > >>> has a few problems.
> > > > > >>>
> > > > > >>> To start with, the pattern of:
> > > > > >>>
> > > > > >>> while (not_stopped) {
> > > > > >>> keep picking jobs
> > > > > >>> }
> > > > > >>>
> > > > > >>> Feels fundamentally in disagreement with workers (while
> > > > > obviously fits
> > > > > >>> perfectly with the current kthread design).
> > > > > >>
> > > > > >> The while loop breaks and worker exists if no jobs are ready.
> > > > >
> > > > >
> > > > > I'm not very familiar with workqueues. What are you saying would fit
> > > > > better? One scheduling job per work item rather than one big work
> > > > > item which handles all available jobs?
> > > >
> > > > Yes and no, it indeed IMO does not fit to have a work item which is
> > > > potentially unbound in runtime. But it is a bit moot conceptual mismatch
> > > > because it is a worst case / theoretical, and I think due more
> > > > fundamental concerns.
> > > >
> > > > If we have to go back to the low level side of things, I've picked this
> > > > random spot to consolidate what I have already mentioned and perhaps
> > > > expand.
> > > >
> > > > To start with, let me pull out some thoughts from workqueue.rst:
> > > >
> > > > """
> > > > Generally, work items are not expected to hog a CPU and consume many
> > > > cycles. That means maintaining just enough concurrency to prevent work
> > > > processing from stalling should be optimal.
> > > > """
> > > >
> > > > For unbound queues:
> > > > """
> > > > The responsibility of regulating concurrency level is on the users.
> > > > """
> > > >
> > > > Given the unbound queues will be spawned on demand to service all queued
> > > > work items (more interesting when mixing up with the system_unbound_wq),
> > > > in the proposed design the number of instantiated worker threads does
> > > > not correspond to the number of user threads (as you have elsewhere
> > > > stated), but pessimistically to the number of active user contexts. That
> > > > is the number which drives the maximum number of not-runnable jobs that
> > > > can become runnable at once, and hence spawn that many work items, and
> > > > in turn unbound worker threads.
> > > >
> > > > Several problems there.
> > > >
> > > > It is fundamentally pointless to have potentially that many more threads
> > > > than the number of CPU cores - it simply creates a scheduling storm.
> > >
> > > To make matters worse, if I follow the code correctly, all these per user
> > > context worker thread / work items end up contending on the same lock or
> > > circular buffer, both are one instance per GPU:
> > >
> > > guc_engine_run_job
> > > -> submit_engine
> > > a) wq_item_append
> > > -> wq_wait_for_space
> > >-> msleep
> >
> > a) is dedicated per xe_engine
>
> Hah true, what its for then? I thought throttling the LRCA ring is done via:
>
This
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
On Tue, Jan 10, 2023 at 11:45:40PM +0530, Deepak R Varma wrote:
> Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> function adds the overhead of introducing a proxy file operation
> functions to wrap the original read/write inside file removal protection
> functions. This adds significant overhead in terms of introducing and
> managing the proxy factory file operations structure and function
> wrapping at runtime.
> As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> with debugfs_create_file_unsafe() is suggested to be used instead. The
> DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> debugfs_file_put() wrappers to protect the original read and write
> function calls for the debug attributes. There is no need for any
> runtime proxy file operations to be managed by the debugfs core.
> Following coccicheck make command helped identify this change:
>
> make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
> COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: Deepak R Varma
Reviewed-by: Rodrigo Vivi
(Are you planning to send the one for pxp file?)
> ---
> Changes in v2:
>- Include coccicheck make command in the patch log message for clarity.
> Suggested by Rodrigo Vivi
>
>
> drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 5e69d3c11d21..c508dcf415b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1807,10 +1807,10 @@ static int intel_fbc_debugfs_false_color_set(void
> *data, u64 val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
> - intel_fbc_debugfs_false_color_get,
> - intel_fbc_debugfs_false_color_set,
> - "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
> + intel_fbc_debugfs_false_color_get,
> + intel_fbc_debugfs_false_color_set,
> + "%llu\n");
>
> static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
> struct dentry *parent)
> @@ -1819,8 +1819,8 @@ static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
> fbc, _fbc_debugfs_status_fops);
>
> if (fbc->funcs->set_false_color)
> - debugfs_create_file("i915_fbc_false_color", 0644, parent,
> - fbc, _fbc_debugfs_false_color_fops);
> + debugfs_create_file_unsafe("i915_fbc_false_color", 0644, parent,
> +fbc,
> _fbc_debugfs_false_color_fops);
> }
>
> void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc)
> --
> 2.34.1
>
>
>
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes
On Tue, Jan 10, 2023 at 11:45:02PM +0530, Deepak R Varma wrote:
> Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> function adds the overhead of introducing a proxy file operation
> functions to wrap the original read/write inside file removal protection
> functions. This adds significant overhead in terms of introducing and
> managing the proxy factory file operations structure and function
> wrapping at runtime.
> As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> with debugfs_create_file_unsafe() is suggested to be used instead. The
> DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> debugfs_file_put() wrappers to protect the original read and write
> function calls for the debug attributes. There is no need for any
> runtime proxy file operations to be managed by the debugfs core.
> Following coccicheck make command helped identify this change:
>
> make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
> COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: Deepak R Varma
> ---
> Changes in v2:
>- Include coccicheck make command in the patch log message for clarity.
> Suggested by Rodrigo Vivi
Thank you
Reviewed-by: Rodrigo Vivi
>
> drivers/gpu/drm/i915/display/intel_drrs.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 5b9e3814..84ba7379d6f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -374,16 +374,16 @@ static int intel_drrs_debugfs_ctl_set(void *data, u64
> val)
> return ret;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(intel_drrs_debugfs_ctl_fops,
> - NULL, intel_drrs_debugfs_ctl_set, "%llu\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(intel_drrs_debugfs_ctl_fops,
> + NULL, intel_drrs_debugfs_ctl_set, "%llu\n");
>
> void intel_drrs_crtc_debugfs_add(struct intel_crtc *crtc)
> {
> debugfs_create_file("i915_drrs_status", 0444, crtc->base.debugfs_entry,
> crtc, _drrs_debugfs_status_fops);
>
> - debugfs_create_file("i915_drrs_ctl", 0644, crtc->base.debugfs_entry,
> - crtc, _drrs_debugfs_ctl_fops);
> + debugfs_create_file_unsafe("i915_drrs_ctl", 0644,
> crtc->base.debugfs_entry,
> + crtc, _drrs_debugfs_ctl_fops);
> }
>
> static int intel_drrs_debugfs_type_show(struct seq_file *m, void *unused)
> --
> 2.34.1
>
>
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
On Wed, Jan 11, 2023 at 12:00:12AM +0530, Deepak R Varma wrote:
> Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
> function adds the overhead of introducing a proxy file operation
> functions to wrap the original read/write inside file removal protection
> functions. This adds significant overhead in terms of introducing and
> managing the proxy factory file operations structure and function
> wrapping at runtime.
> As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
> with debugfs_create_file_unsafe() is suggested to be used instead. The
> DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
> debugfs_file_put() wrappers to protect the original read and write
> function calls for the debug attributes. There is no need for any
> runtime proxy file operations to be managed by the debugfs core.
> Following coccicheck make command helped identify this change:
>
> make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
> COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Signed-off-by: Deepak R Varma
I believe these 2 gvt cases could be done in one patch.
But anyways,
Reviewed-by: Rodrigo Vivi
for both patches... and will leave these 2 patches for gvt folks
to apply. Unless they ack and I apply in the drm-intel along with the other
ones.
> ---
> drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
> b/drivers/gpu/drm/i915/gvt/debugfs.c
> index 03f081c3d9a4..baccbf1761b7 100644
> --- a/drivers/gpu/drm/i915/gvt/debugfs.c
> +++ b/drivers/gpu/drm/i915/gvt/debugfs.c
> @@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
> return 0;
> }
>
> -DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
> +DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL,
> "0x%llx\n");
>
> /**
> * intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
> @@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
> _mmio_diff_fops);
> debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
> _scan_nonprivbb_fops);
> - debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
> - _status_fops);
> + debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
> +_status_fops);
> }
>
> /**
> --
> 2.34.1
>
>
>
[Intel-gfx] [PATCH 2/2] drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/i915/gvt/debugfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
b/drivers/gpu/drm/i915/gvt/debugfs.c
index 03f081c3d9a4..baccbf1761b7 100644
--- a/drivers/gpu/drm/i915/gvt/debugfs.c
+++ b/drivers/gpu/drm/i915/gvt/debugfs.c
@@ -165,7 +165,7 @@ static int vgpu_status_get(void *data, u64 *val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
+DEFINE_DEBUGFS_ATTRIBUTE(vgpu_status_fops, vgpu_status_get, NULL, "0x%llx\n");
/**
* intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
@@ -182,8 +182,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
_mmio_diff_fops);
debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
_scan_nonprivbb_fops);
- debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
- _status_fops);
+ debugfs_create_file_unsafe("status", 0644, vgpu->debugfs, vgpu,
+ _status_fops);
}
/**
--
2.34.1
[Intel-gfx] [PATCH 1/2] drm/i915/gvt: Avoid full proxy f_ops for scan_nonprivbb debug attributes
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma
---
drivers/gpu/drm/i915/gvt/debugfs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
b/drivers/gpu/drm/i915/gvt/debugfs.c
index 0616b73175f3..03f081c3d9a4 100644
--- a/drivers/gpu/drm/i915/gvt/debugfs.c
+++ b/drivers/gpu/drm/i915/gvt/debugfs.c
@@ -147,9 +147,9 @@ vgpu_scan_nonprivbb_set(void *data, u64 val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(vgpu_scan_nonprivbb_fops,
- vgpu_scan_nonprivbb_get, vgpu_scan_nonprivbb_set,
- "0x%llx\n");
+DEFINE_DEBUGFS_ATTRIBUTE(vgpu_scan_nonprivbb_fops,
+vgpu_scan_nonprivbb_get, vgpu_scan_nonprivbb_set,
+"0x%llx\n");
static int vgpu_status_get(void *data, u64 *val)
{
@@ -180,8 +180,8 @@ void intel_gvt_debugfs_add_vgpu(struct intel_vgpu *vgpu)
debugfs_create_file("mmio_diff", 0444, vgpu->debugfs, vgpu,
_mmio_diff_fops);
- debugfs_create_file("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
- _scan_nonprivbb_fops);
+ debugfs_create_file_unsafe("scan_nonprivbb", 0644, vgpu->debugfs, vgpu,
+ _scan_nonprivbb_fops);
debugfs_create_file("status", 0644, vgpu->debugfs, vgpu,
_status_fops);
}
--
2.34.1
[Intel-gfx] [PATCH 0/2] drm/i915/gvt: Avoid full proxy f_ops debug attributes
This patch series proposes to replace a combination of DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file() by a combination of DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe(). The change reduced overhead in terms of managing the full proxy f_ops at runtime. The patches 1 & 2 covers for the scan_nonprivbb and vgpu_status f_ops debugfs attributes respectively. Following coccicheck make command helped identify this change: make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci Deepak R Varma (2): drm/i915/gvt: Avoid full proxy f_ops for scan_nonprivbb debug attributes drm/i915/gvt: Avoid full proxy f_ops for vgpu_status debug attributes drivers/gpu/drm/i915/gvt/debugfs.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v2 2/2] drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma
---
Changes in v2:
- Include coccicheck make command in the patch log message for clarity.
Suggested by Rodrigo Vivi
drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 5e69d3c11d21..c508dcf415b4 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1807,10 +1807,10 @@ static int intel_fbc_debugfs_false_color_set(void
*data, u64 val)
return 0;
}
-DEFINE_SIMPLE_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
- intel_fbc_debugfs_false_color_get,
- intel_fbc_debugfs_false_color_set,
- "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(intel_fbc_debugfs_false_color_fops,
+intel_fbc_debugfs_false_color_get,
+intel_fbc_debugfs_false_color_set,
+"%llu\n");
static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
struct dentry *parent)
@@ -1819,8 +1819,8 @@ static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
fbc, _fbc_debugfs_status_fops);
if (fbc->funcs->set_false_color)
- debugfs_create_file("i915_fbc_false_color", 0644, parent,
- fbc, _fbc_debugfs_false_color_fops);
+ debugfs_create_file_unsafe("i915_fbc_false_color", 0644, parent,
+ fbc,
_fbc_debugfs_false_color_fops);
}
void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc)
--
2.34.1
[Intel-gfx] [PATCH v2 1/2] drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes
Using DEFINE_SIMPLE_ATTRIBUTE macro with the debugfs_create_file()
function adds the overhead of introducing a proxy file operation
functions to wrap the original read/write inside file removal protection
functions. This adds significant overhead in terms of introducing and
managing the proxy factory file operations structure and function
wrapping at runtime.
As a replacement, a combination of DEFINE_DEBUGFS_ATTRIBUTE macro paired
with debugfs_create_file_unsafe() is suggested to be used instead. The
DEFINE_DEBUGFS_ATTRIBUTE utilises debugfs_file_get() and
debugfs_file_put() wrappers to protect the original read and write
function calls for the debug attributes. There is no need for any
runtime proxy file operations to be managed by the debugfs core.
Following coccicheck make command helped identify this change:
make coccicheck M=drivers/gpu/drm/i915/ MODE=patch
COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
Signed-off-by: Deepak R Varma
---
Changes in v2:
- Include coccicheck make command in the patch log message for clarity.
Suggested by Rodrigo Vivi
drivers/gpu/drm/i915/display/intel_drrs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 5b9e3814..84ba7379d6f8 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -374,16 +374,16 @@ static int intel_drrs_debugfs_ctl_set(void *data, u64 val)
return ret;
}
-DEFINE_SIMPLE_ATTRIBUTE(intel_drrs_debugfs_ctl_fops,
- NULL, intel_drrs_debugfs_ctl_set, "%llu\n");
+DEFINE_DEBUGFS_ATTRIBUTE(intel_drrs_debugfs_ctl_fops,
+NULL, intel_drrs_debugfs_ctl_set, "%llu\n");
void intel_drrs_crtc_debugfs_add(struct intel_crtc *crtc)
{
debugfs_create_file("i915_drrs_status", 0444, crtc->base.debugfs_entry,
crtc, _drrs_debugfs_status_fops);
- debugfs_create_file("i915_drrs_ctl", 0644, crtc->base.debugfs_entry,
- crtc, _drrs_debugfs_ctl_fops);
+ debugfs_create_file_unsafe("i915_drrs_ctl", 0644,
crtc->base.debugfs_entry,
+ crtc, _drrs_debugfs_ctl_fops);
}
static int intel_drrs_debugfs_type_show(struct seq_file *m, void *unused)
--
2.34.1
[Intel-gfx] [PATCH 0/2 v2] drm/i915: Avoid full proxy f_ops debug attributes
This patch series proposes to replace a combination of DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file() by a combination of DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe(). The change reduced overhead in terms of managing the full proxy f_ops at runtime. The patches 1 & 2 covers for the DRRS and FBC f_ops debugfs attributes respectively. Following coccicheck make command helped identify this change: make coccicheck M=drivers/gpu/drm/i915/ MODE=patch COCCI=./scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci Changes in v2: - Individual patches clubbed in patch set - Update patch log message to include coccicheck make command Deepak R Varma (2): drm/i915/display: Avoid full proxy f_ops for DRRS debug attributes drm/i915/fbc: Avoid full proxy f_ops for FBC debug attributes drivers/gpu/drm/i915/display/intel_drrs.c | 8 drivers/gpu/drm/i915/display/intel_fbc.c | 12 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) -- 2.34.1
Re: [Intel-gfx] [PATCH] drm/i915: Add missing check and destroy for alloc_workqueue
On Sat, Jan 07, 2023 at 02:29:22AM +0800, Daniel Vetter wrote:
>On Fri, Jan 06, 2023 at 05:09:34PM +0800, Jiasheng Jiang wrote:
>> Add checks for the return value of alloc_workqueue and
>> alloc_ordered_workqueue as they may return NULL pointer and cause NULL
>> pointer dereference.
>> Moreover, destroy them when fails later in order to avoid memory leak.
>> Because in `drivers/gpu/drm/i915/i915_driver.c`, if
>> intel_modeset_init_noirq fails, its workqueues will not be destroyed.
>>
>> Fixes: c26a058680dc ("drm/i915: Use a high priority wq for nonblocking plane
>> updates")
>> Fixes: 757fffcfdffb ("drm/i915: Put all non-blocking modesets onto an
>> ordered wq")
>> Signed-off-by: Jiasheng Jiang
>
> So you have an entire pile of these, and I think that's a really good
> excuse to
> - create a drmm_alloc_workqueue helper for these (and
> drmm_alloc_ordered_workqueue) using the drmm_add_action_or_reset()
> function for automatic drm_device cleanup
> - use that instead in all drivers, which means you do not have to make any
> error handling mor complex
>
> Up for that? In that case please also convert any existing alloc*workqueue
> callsites in drm, and make this all a patch series (since then there would
> be dependencies).
Fine, I have submitted two patches. The first one create the
drmm_alloc_workqueue and drmm_alloc_ordered_workqueue helpers. And the
second one replace the alloc*workqueue with DRM helpers in
`drivers/gpu/drm/i915/display/intel_display.c`.
If there is no problem in these two, I will submitted the other patches
that replace the alloc*workqueue in other DRM files.
Thanks,
Jiang
[Intel-gfx] [PATCH] drm/i915: Add missing check and destroy for alloc_workqueue
Add checks for the return value of alloc_workqueue and
alloc_ordered_workqueue as they may return NULL pointer and cause NULL
pointer dereference.
Moreover, destroy them when fails later in order to avoid memory leak.
Because in `drivers/gpu/drm/i915/i915_driver.c`, if
intel_modeset_init_noirq fails, its workqueues will not be destroyed.
Fixes: c26a058680dc ("drm/i915: Use a high priority wq for nonblocking plane
updates")
Fixes: 757fffcfdffb ("drm/i915: Put all non-blocking modesets onto an ordered
wq")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/i915/display/intel_display.c | 21
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c2686ecb62a..58f6840d6bd8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8655,26 +8655,35 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
intel_dmc_ucode_init(i915);
i915->display.wq.modeset = alloc_ordered_workqueue("i915_modeset", 0);
+ if (!i915->display.wq.modeset) {
+ ret = -ENOMEM;
+ goto cleanup_vga_client_pw_domain_dmc;
+ }
+
i915->display.wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI |
WQ_UNBOUND,
WQ_UNBOUND_MAX_ACTIVE);
+ if (!i915->display.wq.flip) {
+ ret = -ENOMEM;
+ goto cleanup_modeset;
+ }
intel_mode_config_init(i915);
ret = intel_cdclk_init(i915);
if (ret)
- goto cleanup_vga_client_pw_domain_dmc;
+ goto cleanup_flip;
ret = intel_color_init(i915);
if (ret)
- goto cleanup_vga_client_pw_domain_dmc;
+ goto cleanup_flip;
ret = intel_dbuf_init(i915);
if (ret)
- goto cleanup_vga_client_pw_domain_dmc;
+ goto cleanup_flip;
ret = intel_bw_init(i915);
if (ret)
- goto cleanup_vga_client_pw_domain_dmc;
+ goto cleanup_flip;
init_llist_head(>display.atomic_helper.free_list);
INIT_WORK(>display.atomic_helper.free_work,
@@ -8686,6 +8695,10 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
return 0;
+cleanup_flip:
+ destroy_workqueue(i915->display.wq.flip);
+cleanup_modeset:
+ destroy_workqueue(i915->display.wq.modeset);
cleanup_vga_client_pw_domain_dmc:
intel_dmc_ucode_fini(i915);
intel_power_domains_driver_remove(i915);
--
2.25.1
[Intel-gfx] [PATCH][next] drm/i915/guc: Replace zero-length arrays with flexible-array members
Zero-length arrays are deprecated[1] and we are moving towards
adopting C99 flexible-array members, instead. So, replace zero-length
arrays in a couple of structures (three, actually) with flex-array
members.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [2].
Link:
https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays
[1]
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [2]
Link: https://github.com/KSPP/linux/issues/78
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
index 3624abfd22d1..9d589c28f40f 100644
--- a/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h
@@ -73,7 +73,7 @@ struct guc_debug_capture_list_header {
struct guc_debug_capture_list {
struct guc_debug_capture_list_header header;
- struct guc_mmio_reg regs[0];
+ struct guc_mmio_reg regs[];
} __packed;
/**
@@ -125,7 +125,7 @@ struct guc_state_capture_header_t {
struct guc_state_capture_t {
struct guc_state_capture_header_t header;
- struct guc_mmio_reg mmio_entries[0];
+ struct guc_mmio_reg mmio_entries[];
} __packed;
enum guc_capture_group_types {
@@ -145,7 +145,7 @@ struct guc_state_capture_group_header_t {
/* this is the top level structure where an error-capture dump starts */
struct guc_state_capture_group_t {
struct guc_state_capture_group_header_t grp_header;
- struct guc_state_capture_t capture_entries[0];
+ struct guc_state_capture_t capture_entries[];
} __packed;
/**
--
2.34.1
[Intel-gfx] [PATCH 2/2] drm/i915: Replace alloc*workqueue with DRM helpers
Replace alloc*workqueue with DRM helpers in order to avoid memory leak.
Moreover, check the return value since the workqueue may be NULL and
cause NULL pointer dereference.
Fixes: c26a058680dc ("drm/i915: Use a high priority wq for nonblocking plane
updates")
Fixes: 757fffcfdffb ("drm/i915: Put all non-blocking modesets onto an ordered
wq")
Signed-off-by: Jiasheng Jiang
---
drivers/gpu/drm/i915/display/intel_display.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c2686ecb62a..8acef38ca985 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -8654,9 +8655,16 @@ int intel_modeset_init_noirq(struct drm_i915_private
*i915)
intel_dmc_ucode_init(i915);
- i915->display.wq.modeset = alloc_ordered_workqueue("i915_modeset", 0);
- i915->display.wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI |
- WQ_UNBOUND,
WQ_UNBOUND_MAX_ACTIVE);
+ ret = drmm_alloc_ordered_workqueue(>drm,
+ i915->display.wq.modeset,
"i915_modeset", 0);
+ if (ret)
+ goto cleanup_vga_client_pw_domain_dmc;
+
+ ret = drmm_alloc_workqueue(>drm, i915->display.wq.flip,
+ "i915_flip", WQ_HIGHPRI | WQ_UNBOUND,
+ WQ_UNBOUND_MAX_ACTIVE);
+ if (ret)
+ goto cleanup_vga_client_pw_domain_dmc;
intel_mode_config_init(i915);
--
2.25.1
Re: [Intel-gfx] [PATCH 1/5] linux/minmax.h: add non-atomic version of xchg
On Thu, Jan 05, 2023 at 03:57:25PM +0100, Daniel Vetter wrote: > It's more fun, for the atomic functions which don't have the atomic_ > prefix in their names, the __ prefixed versions provide the non-atomic > implementation. This pattern was started with the long * bitops stuff for > managing really big bitmasks. > > And I really don't think it's a great function name scheme that we should > proliferate. FWIW I agree it's not great, but we're stuck between a rock and a bikeshed w.r.t. better naming -- it's quite hard to clean that up becuase the atomic_*() namespace is reserved for atomic_t (and mirrors atomic64_*() and atomic_long_*()). We could consider renaming atomic_t to atomic32_t and atomic_*() to atomic32_*(), which'd free up the atomic_*() namespace for more genral usage (e.g. allowing us to have atomic_xchg() and xhcg(), with the latter not being atomic). Thanks, Mark.
Re: [Intel-gfx] [PATCH] drm/i915: Remove i915_drm_suspend_mode
On Tue, Jan 10, 2023 at 11:59:02AM +0100, Maarten Lankhorst wrote:
> enum i915_drm_suspend_mode suspend_mode is only used in
> intel_display_power, while we only care about whether we perform a
> s2idle. Remove it and use a simple bool.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Rodrigo Vivi
> ---
> .../gpu/drm/i915/display/intel_display_power.c | 8 +++-
> .../gpu/drm/i915/display/intel_display_power.h | 3 +--
> drivers/gpu/drm/i915/i915_driver.c | 16 ++--
> drivers/gpu/drm/i915/intel_runtime_pm.h | 6 --
> 4 files changed, 6 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 060e0a2770f7..6ef937afe48e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -2029,7 +2029,7 @@ void intel_power_domains_disable(struct
> drm_i915_private *i915)
> /**
> * intel_power_domains_suspend - suspend power domain state
> * @i915: i915 device instance
> - * @suspend_mode: specifies the target suspend state (idle, mem, hibernation)
> + * @s2idle: specifies whether we go to idle, or deeper sleep
> *
> * This function prepares the hardware power domain state before entering
> * system suspend.
> @@ -2037,8 +2037,7 @@ void intel_power_domains_disable(struct
> drm_i915_private *i915)
> * It must be called with power domains already disabled (after a call to
> * intel_power_domains_disable()) and paired with
> intel_power_domains_resume().
> */
> -void intel_power_domains_suspend(struct drm_i915_private *i915,
> - enum i915_drm_suspend_mode suspend_mode)
> +void intel_power_domains_suspend(struct drm_i915_private *i915, bool s2idle)
> {
> struct i915_power_domains *power_domains = >display.power.domains;
> intel_wakeref_t wakeref __maybe_unused =
> @@ -2054,8 +2053,7 @@ void intel_power_domains_suspend(struct
> drm_i915_private *i915,
>* that would be blocked if the firmware was inactive.
>*/
> if (!(i915->display.dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
> - suspend_mode == I915_DRM_SUSPEND_IDLE &&
> - intel_dmc_has_payload(i915)) {
> + s2idle && intel_dmc_has_payload(i915)) {
> intel_display_power_flush_work(i915);
> intel_power_domains_verify_state(i915);
> return;
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> b/drivers/gpu/drm/i915/display/intel_display_power.h
> index 6480afcfe0d8..04216be1d6fe 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -164,8 +164,7 @@ void intel_power_domains_init_hw(struct drm_i915_private
> *dev_priv, bool resume)
> void intel_power_domains_driver_remove(struct drm_i915_private *dev_priv);
> void intel_power_domains_enable(struct drm_i915_private *dev_priv);
> void intel_power_domains_disable(struct drm_i915_private *dev_priv);
> -void intel_power_domains_suspend(struct drm_i915_private *dev_priv,
> - enum i915_drm_suspend_mode);
> +void intel_power_domains_suspend(struct drm_i915_private *dev_priv, bool
> s2idle);
> void intel_power_domains_resume(struct drm_i915_private *dev_priv);
> void intel_power_domains_sanitize_state(struct drm_i915_private *dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 9c49cc7a246d..a02dd8e38f2a 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1232,18 +1232,6 @@ static int i915_drm_suspend(struct drm_device *dev)
> return 0;
> }
>
> -static enum i915_drm_suspend_mode
> -get_suspend_mode(struct drm_i915_private *dev_priv, bool hibernate)
> -{
> - if (hibernate)
> - return I915_DRM_SUSPEND_HIBERNATE;
> -
> - if (suspend_to_idle(dev_priv))
> - return I915_DRM_SUSPEND_IDLE;
> -
> - return I915_DRM_SUSPEND_MEM;
> -}
> -
> static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -1251,6 +1239,7 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
> struct intel_runtime_pm *rpm = _priv->runtime_pm;
> struct intel_gt *gt;
> int ret, i;
> + bool s2idle = !hibernation && suspend_to_idle(dev_priv);
>
> disable_rpm_wakeref_asserts(rpm);
>
> @@ -1259,8 +1248,7 @@ static int i915_drm_suspend_late(struct drm_device
> *dev, bool hibernation)
> for_each_gt(gt, dev_priv, i)
> intel_uncore_suspend(gt->uncore);
>
> - intel_power_domains_suspend(dev_priv,
> - get_suspend_mode(dev_priv, hibernation));
> + intel_power_domains_suspend(dev_priv, s2idle);
>
>
Re: [Intel-gfx] [PATCH] drm/i915/gt: Cover rest of SVG unit MCR registers
On Thu, Jan 05, 2023 at 10:37:01AM -0300, Gustavo Sousa wrote:
> CHICKEN_RASTER_{1,2} got overlooked with the move done in a9e69428b1b4
> ("drm/i915: Define MCR registers explicitly"). Registers from the SVG
> unit became multicast as of Xe_HP graphics.
>
> BSpec: 66534
> Fixes: a9e69428b1b4 ("drm/i915: Define MCR registers explicitly").
> Signed-off-by: Gustavo Sousa
> Cc: Matt Roper
Applied to drm-intel-gt-next. Thanks for the patch.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++--
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index f8eb807b56f9..570699548c77 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -407,10 +407,10 @@
> #define GEN9_WM_CHICKEN3 _MMIO(0x5588)
> #define GEN9_FACTOR_IN_CLR_VAL_HIZ (1 << 9)
>
> -#define CHICKEN_RASTER_1 _MMIO(0x6204)
> +#define CHICKEN_RASTER_1 MCR_REG(0x6204)
> #define DIS_SF_ROUND_NEAREST_EVEN REG_BIT(8)
>
> -#define CHICKEN_RASTER_2 _MMIO(0x6208)
> +#define CHICKEN_RASTER_2 MCR_REG(0x6208)
> #define TBIMR_FAST_CLIPREG_BIT(5)
>
> #define VFLSKPD MCR_REG(0x62a8)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index bf84efb3f15f..9a40aa61e86e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -645,7 +645,7 @@ static void icl_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> static void dg2_ctx_gt_tuning_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> {
> - wa_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
> + wa_mcr_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
> wa_mcr_write_clr_set(wal, XEHP_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
>REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
> wa_mcr_add(wal,
> @@ -780,7 +780,7 @@ static void dg2_ctx_workarounds_init(struct
> intel_engine_cs *engine,
> wa_masked_en(wal, PSS_MODE2, SCOREBOARD_STALL_FLUSH_CONTROL);
>
> /* Wa_15010599737:dg2 */
> - wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
> + wa_mcr_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN);
>
> /* Wa_18019271663:dg2 */
> wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE);
> --
> 2.39.0
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove i915_drm_suspend_mode
== Series Details ==
Series: drm/i915: Remove i915_drm_suspend_mode
URL : https://patchwork.freedesktop.org/series/112607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12565_full -> Patchwork_112607v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/index.html
Participating hosts (13 -> 10)
--
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
Here are the changes found in Patchwork_112607v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-glk9/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-glk9/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +23 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-glk9/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-hdmi-a-1.html
* igt@sysfs_clients@fair-3:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2994])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-glk9/igt@sysfs_clie...@fair-3.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][9] ([i915#7742]) -> [PASS][10] +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-rkl-1/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@unaligned-write:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-3/igt@fb...@unaligned-write.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-rkl-6/igt@fb...@unaligned-write.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][13] ([i915#6268]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-2/igt@gem_ctx_e...@basic-nohangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][15] ([i915#6252]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-rkl-2/igt@gem_ctx_persiste...@hang.html
* igt@gem_eio@kms:
- {shard-dg1}:[FAIL][17] ([i915#5784]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-dg1-18/igt@gem_...@kms.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-dg1-14/igt@gem_...@kms.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20] +5 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-3/igt@gem_exec_fair@basic-p...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-rkl-5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_reloc@basic-write-read-noreloc:
- {shard-rkl}:[SKIP][21] ([i915#3281]) -> [PASS][22] +9 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-1/igt@gem_exec_re...@basic-write-read-noreloc.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/shard-rkl-5/igt@gem_exec_re...@basic-write-read-noreloc.html
* igt@gem_mmap_gtt@coherency:
- {shard-rkl}:[SKIP][23]
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On 10/01/2023 15:55, Matthew Brost wrote:
On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
On 10/01/2023 11:28, Tvrtko Ursulin wrote:
On 09/01/2023 17:27, Jason Ekstrand wrote:
[snip]
>>> AFAICT it proposes to have 1:1 between *userspace* created
contexts (per
>>> context _and_ engine) and drm_sched. I am not sure avoiding
invasive changes
>>> to the shared code is in the spirit of the overall idea and
instead
>>> opportunity should be used to look at way to refactor/improve
drm_sched.
Maybe? I'm not convinced that what Xe is doing is an abuse at all
or really needs to drive a re-factor. (More on that later.)
There's only one real issue which is that it fires off potentially a
lot of kthreads. Even that's not that bad given that kthreads are
pretty light and you're not likely to have more kthreads than
userspace threads which are much heavier. Not ideal, but not the
end of the world either. Definitely something we can/should
optimize but if we went through with Xe without this patch, it would
probably be mostly ok.
>> Yes, it is 1:1 *userspace* engines and drm_sched.
>>
>> I'm not really prepared to make large changes to DRM scheduler
at the
>> moment for Xe as they are not really required nor does Boris
seem they
>> will be required for his work either. I am interested to see
what Boris
>> comes up with.
>>
>>> Even on the low level, the idea to replace drm_sched threads
with workers
>>> has a few problems.
>>>
>>> To start with, the pattern of:
>>>
>>> while (not_stopped) {
>>> keep picking jobs
>>> }
>>>
>>> Feels fundamentally in disagreement with workers (while
obviously fits
>>> perfectly with the current kthread design).
>>
>> The while loop breaks and worker exists if no jobs are ready.
I'm not very familiar with workqueues. What are you saying would fit
better? One scheduling job per work item rather than one big work
item which handles all available jobs?
Yes and no, it indeed IMO does not fit to have a work item which is
potentially unbound in runtime. But it is a bit moot conceptual mismatch
because it is a worst case / theoretical, and I think due more
fundamental concerns.
If we have to go back to the low level side of things, I've picked this
random spot to consolidate what I have already mentioned and perhaps
expand.
To start with, let me pull out some thoughts from workqueue.rst:
"""
Generally, work items are not expected to hog a CPU and consume many
cycles. That means maintaining just enough concurrency to prevent work
processing from stalling should be optimal.
"""
For unbound queues:
"""
The responsibility of regulating concurrency level is on the users.
"""
Given the unbound queues will be spawned on demand to service all queued
work items (more interesting when mixing up with the system_unbound_wq),
in the proposed design the number of instantiated worker threads does
not correspond to the number of user threads (as you have elsewhere
stated), but pessimistically to the number of active user contexts. That
is the number which drives the maximum number of not-runnable jobs that
can become runnable at once, and hence spawn that many work items, and
in turn unbound worker threads.
Several problems there.
It is fundamentally pointless to have potentially that many more threads
than the number of CPU cores - it simply creates a scheduling storm.
To make matters worse, if I follow the code correctly, all these per user
context worker thread / work items end up contending on the same lock or
circular buffer, both are one instance per GPU:
guc_engine_run_job
-> submit_engine
a) wq_item_append
-> wq_wait_for_space
-> msleep
a) is dedicated per xe_engine
Hah true, what its for then? I thought throttling the LRCA ring is done via:
drm_sched_init(>sched, _sched_ops,
e->lrc[0].ring.size / MAX_JOB_SIZE_BYTES,
Is there something more to throttle other than the ring? It is
throttling something using msleeps..
Also you missed the step of programming the ring which is dedicated per
xe_engine
I was trying to quickly find places which serialize on something in the
backend, ringbuffer emission did not seem to do that but maybe I missed
something.
b) xe_guc_ct_send
-> guc_ct_send
-> mutex_lock(>lock);
-> later a potential msleep in h2g_has_room
Techincally there is 1 instance per GT not GPU, yes this is shared but
in practice there will always be space in the CT channel so contention
on the lock should be rare.
Yeah I used the term GPU to be more understandable to outside audience.
I am somewhat disappointed that the Xe opportunity hasn't been used to
improve upon the CT communication bottlenecks. I mean those backoff
sleeps and lock contention. I wish there
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, Jan 10, 2023 at 11:28:08AM +, Tvrtko Ursulin wrote:
>
>
> On 09/01/2023 17:27, Jason Ekstrand wrote:
>
> [snip]
>
> > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > contexts (per
> > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > invasive changes
> > >>> to the shared code is in the spirit of the overall idea and instead
> > >>> opportunity should be used to look at way to refactor/improve
> > drm_sched.
> >
> >
> > Maybe? I'm not convinced that what Xe is doing is an abuse at all or
> > really needs to drive a re-factor. (More on that later.) There's only
> > one real issue which is that it fires off potentially a lot of kthreads.
> > Even that's not that bad given that kthreads are pretty light and you're
> > not likely to have more kthreads than userspace threads which are much
> > heavier. Not ideal, but not the end of the world either. Definitely
> > something we can/should optimize but if we went through with Xe without
> > this patch, it would probably be mostly ok.
> >
> > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > >>
> > >> I'm not really prepared to make large changes to DRM scheduler
> > at the
> > >> moment for Xe as they are not really required nor does Boris
> > seem they
> > >> will be required for his work either. I am interested to see
> > what Boris
> > >> comes up with.
> > >>
> > >>> Even on the low level, the idea to replace drm_sched threads
> > with workers
> > >>> has a few problems.
> > >>>
> > >>> To start with, the pattern of:
> > >>>
> > >>> while (not_stopped) {
> > >>> keep picking jobs
> > >>> }
> > >>>
> > >>> Feels fundamentally in disagreement with workers (while
> > obviously fits
> > >>> perfectly with the current kthread design).
> > >>
> > >> The while loop breaks and worker exists if no jobs are ready.
> >
> >
> > I'm not very familiar with workqueues. What are you saying would fit
> > better? One scheduling job per work item rather than one big work item
> > which handles all available jobs?
>
> Yes and no, it indeed IMO does not fit to have a work item which is
> potentially unbound in runtime. But it is a bit moot conceptual mismatch
> because it is a worst case / theoretical, and I think due more fundamental
> concerns.
>
> If we have to go back to the low level side of things, I've picked this
> random spot to consolidate what I have already mentioned and perhaps expand.
>
> To start with, let me pull out some thoughts from workqueue.rst:
>
> """
> Generally, work items are not expected to hog a CPU and consume many cycles.
> That means maintaining just enough concurrency to prevent work processing
> from stalling should be optimal.
> """
>
> For unbound queues:
> """
> The responsibility of regulating concurrency level is on the users.
> """
>
> Given the unbound queues will be spawned on demand to service all queued
> work items (more interesting when mixing up with the system_unbound_wq), in
> the proposed design the number of instantiated worker threads does not
> correspond to the number of user threads (as you have elsewhere stated), but
> pessimistically to the number of active user contexts. That is the number
> which drives the maximum number of not-runnable jobs that can become
> runnable at once, and hence spawn that many work items, and in turn unbound
> worker threads.
>
> Several problems there.
>
> It is fundamentally pointless to have potentially that many more threads
> than the number of CPU cores - it simply creates a scheduling storm.
>
We can use a different work queue if this is an issue, have a FIXME
which indicates we should allow the user to pass in the work queue.
> Unbound workers have no CPU / cache locality either and no connection with
> the CPU scheduler to optimize scheduling patterns. This may matter either on
> large systems or on small ones. Whereas the current design allows for
> scheduler to notice userspace CPU thread keeps waking up the same drm
> scheduler kernel thread, and so it can keep them on the same CPU, the
> unbound workers lose that ability and so 2nd CPU might be getting woken up
> from low sleep for every submission.
>
I guess I don't understand kthread vs. workqueue scheduling internals.
> Hence, apart from being a bit of a impedance mismatch, the proposal has the
> potential to change performance and power patterns and both large and small
> machines.
>
We are going to have to test this out I suppose and play around to see
if this design has any real world impacts. As Jason said, yea probably
will need a bit of help here from others. Will CC relavent parties on
next rev.
> > >>> Secondly, it probably demands separate workers (not optional),
> > otherwise
> > >>> behaviour of shared workqueues has either the potential to
> > explode
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable HDCP2.x via GSC CS (rev7)
== Series Details ==
Series: Enable HDCP2.x via GSC CS (rev7)
URL : https://patchwork.freedesktop.org/series/111876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12565_full -> Patchwork_111876v7_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/index.html
Participating hosts (13 -> 11)
--
Additional (1): shard-rkl0
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Known issues
Here are the changes found in Patchwork_111876v7_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-glk2/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk3/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-glk8/igt@gem_exec_fair@basic-p...@vecs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk5/igt@gem_exec_fair@basic-p...@vecs0.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk2/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +2
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk2/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_flip@plain-flip-ts-check-interruptible@a-hdmi-a1:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2122])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-glk4/igt@kms_flip@plain-flip-ts-check-interrupti...@a-hdmi-a1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk2/igt@kms_flip@plain-flip-ts-check-interrupti...@a-hdmi-a1.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271]) +27 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk2/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-c-hdmi-a-1.html
* igt@sysfs_clients@fair-3:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2994])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-glk2/igt@sysfs_clie...@fair-3.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][13] ([i915#658]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-1/igt@feature_discov...@psr2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_create@hog-create@smem0:
- {shard-rkl}:[FAIL][15] ([i915#7679]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-1/igt@gem_create@hog-cre...@smem0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-rkl-5/igt@gem_create@hog-cre...@smem0.html
* igt@gem_ctx_persistence@hang:
- {shard-rkl}:[SKIP][17] ([i915#6252]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-5/igt@gem_ctx_persiste...@hang.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-rkl-4/igt@gem_ctx_persiste...@hang.html
* igt@gem_eio@kms:
- {shard-dg1}:[FAIL][19] ([i915#5784]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-dg1-18/igt@gem_...@kms.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-dg1-12/igt@gem_...@kms.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/shard-rkl-1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111876v7/shard-rkl-4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
Re: [Intel-gfx] [PATCH v3] drm/i915/display/misc: use intel_de_rmw if possible
On Tue, Jan 10, 2023 at 12:36:56PM +0100, Andrzej Hajda wrote:
> The helper makes the code more compact and readable.
next time, please add the revision comments here so we know what
changed from one version to the next.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c | 12
> drivers/gpu/drm/i915/display/intel_drrs.c | 12 +++-
> drivers/gpu/drm/i915/display/intel_dvo.c | 7 ++-
> drivers/gpu/drm/i915/display/intel_lvds.c | 12
> drivers/gpu/drm/i915/display/intel_tv.c | 6 ++
> 5 files changed, 15 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index 24ef36ec2d3d3c..9629b174ec5d2c 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -136,16 +136,12 @@ static void intel_dp_prepare(struct intel_encoder
> *encoder,
>
> intel_dp->DP |= DP_PIPE_SEL_IVB(crtc->pipe);
> } else if (HAS_PCH_CPT(dev_priv) && port != PORT_A) {
> - u32 trans_dp;
> -
> intel_dp->DP |= DP_LINK_TRAIN_OFF_CPT;
>
> - trans_dp = intel_de_read(dev_priv, TRANS_DP_CTL(crtc->pipe));
> - if (drm_dp_enhanced_frame_cap(intel_dp->dpcd))
> - trans_dp |= TRANS_DP_ENH_FRAMING;
> - else
> - trans_dp &= ~TRANS_DP_ENH_FRAMING;
> - intel_de_write(dev_priv, TRANS_DP_CTL(crtc->pipe), trans_dp);
> + intel_de_rmw(dev_priv, TRANS_DP_CTL(crtc->pipe),
> + TRANS_DP_ENH_FRAMING,
> + drm_dp_enhanced_frame_cap(intel_dp->dpcd) ?
> + TRANS_DP_ENH_FRAMING : 0);
yet another case with risk of change in behavior, but here again I believe
this is the right thing.
Reviewed-by: Rodrigo Vivi
> } else {
> if (IS_G4X(dev_priv) && pipe_config->limited_color_range)
> intel_dp->DP |= DP_COLOR_RANGE_16_235;
> diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
> b/drivers/gpu/drm/i915/display/intel_drrs.c
> index 5b9e3814e9..a52974f5f66042 100644
> --- a/drivers/gpu/drm/i915/display/intel_drrs.c
> +++ b/drivers/gpu/drm/i915/display/intel_drrs.c
> @@ -68,21 +68,15 @@ intel_drrs_set_refresh_rate_pipeconf(struct intel_crtc
> *crtc,
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> enum transcoder cpu_transcoder = crtc->drrs.cpu_transcoder;
> - u32 val, bit;
> + u32 bit;
>
> if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> bit = PIPECONF_REFRESH_RATE_ALT_VLV;
> else
> bit = PIPECONF_REFRESH_RATE_ALT_ILK;
>
> - val = intel_de_read(dev_priv, PIPECONF(cpu_transcoder));
> -
> - if (refresh_rate == DRRS_REFRESH_RATE_LOW)
> - val |= bit;
> - else
> - val &= ~bit;
> -
> - intel_de_write(dev_priv, PIPECONF(cpu_transcoder), val);
> + intel_de_rmw(dev_priv, PIPECONF(cpu_transcoder),
> + bit, refresh_rate == DRRS_REFRESH_RATE_LOW ? bit : 0);
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/display/intel_dvo.c
> b/drivers/gpu/drm/i915/display/intel_dvo.c
> index 4aeae0f3ac9172..77d413781020de 100644
> --- a/drivers/gpu/drm/i915/display/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_dvo.c
> @@ -444,11 +444,8 @@ static bool intel_dvo_init_dev(struct drm_i915_private
> *dev_priv,
>* the clock enabled before we attempt to initialize
>* the device.
>*/
> - for_each_pipe(dev_priv, pipe) {
> - dpll[pipe] = intel_de_read(dev_priv, DPLL(pipe));
> - intel_de_write(dev_priv, DPLL(pipe),
> -dpll[pipe] | DPLL_DVO_2X_MODE);
> - }
> + for_each_pipe(dev_priv, pipe)
> + dpll[pipe] = intel_de_rmw(dev_priv, DPLL(pipe), 0,
> DPLL_DVO_2X_MODE);
>
> ret = dvo->dev_ops->init(_dvo->dev, i2c);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
> b/drivers/gpu/drm/i915/display/intel_lvds.c
> index aecec992cd0d2d..e8f47b7ef87649 100644
> --- a/drivers/gpu/drm/i915/display/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/display/intel_lvds.c
> @@ -316,11 +316,9 @@ static void intel_enable_lvds(struct intel_atomic_state
> *state,
> struct intel_lvds_encoder *lvds_encoder = to_lvds_encoder(encoder);
> struct drm_i915_private *dev_priv = to_i915(dev);
>
> - intel_de_write(dev_priv, lvds_encoder->reg,
> -intel_de_read(dev_priv, lvds_encoder->reg) |
> LVDS_PORT_EN);
> + intel_de_rmw(dev_priv, lvds_encoder->reg, 0, LVDS_PORT_EN);
>
> - intel_de_write(dev_priv, PP_CONTROL(0),
> -intel_de_read(dev_priv, PP_CONTROL(0)) | PANEL_POWER_ON);
> + intel_de_rmw(dev_priv, PP_CONTROL(0), 0, PANEL_POWER_ON);
> intel_de_posting_read(dev_priv, lvds_encoder->reg);
>
> if
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement workaround for DP2 UHBR bandwidth check (rev2)
== Series Details ==
Series: drm/i915: Implement workaround for DP2 UHBR bandwidth check (rev2)
URL : https://patchwork.freedesktop.org/series/112345/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12567 -> Patchwork_112345v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/index.html
Participating hosts (41 -> 40)
--
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112345v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-rte:
- {bat-adlp-6}: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/bat-adlp-6/igt@i915_pm_...@basic-rte.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/bat-adlp-6/igt@i915_pm_...@basic-rte.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
Known issues
Here are the changes found in Patchwork_112345v2 that come from known issues:
### IGT changes ###
Issues hit
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-n3050: [PASS][5] -> [FAIL][6] ([i915#6298])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][7] ([i915#4983]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/bat-rpls-1/igt@i915_selftest@l...@reset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#7359]: https://gitlab.freedesktop.org/drm/intel/issues/7359
[i915#7625]: https://gitlab.freedesktop.org/drm/intel/issues/7625
Build changes
-
* Linux: CI_DRM_12567 -> Patchwork_112345v2
CI-20190529: 20190529
CI_DRM_12567: a5cd9627b806f2f42bbacbf9649145f3954830d9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7114: 2fd839599a200c089a5c9dbf5048609faf9b8104 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112345v2: a5cd9627b806f2f42bbacbf9649145f3954830d9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
be2425bbc34b drm/i915: Implement workaround for DP2 UHBR bandwidth check
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112345v2/index.html
Re: [Intel-gfx] [RFC 2/2] drm/i915/display: Add 480 MHz CDCLK steps for RPL-U
On Tue, 10 Jan 2023, Matt Roper wrote: > On Tue, Jan 10, 2023 at 11:06:14AM +0200, Jani Nikula wrote: >> On Sat, 07 Jan 2023, Chaitanya Kumar Borah >> wrote: >> > @@ -3353,6 +3374,8 @@ void intel_init_cdclk_hooks(struct drm_i915_private >> > *dev_priv) >> >/* Wa_22011320316:adl-p[a0] */ >> >if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0)) >> >dev_priv->display.cdclk.table = adlp_a_step_cdclk_table; >> >> Are RPL-U A0-B0 going to enter this branch? Is this the right thing to >> do? > > There's no such thing as a RPL A0/B0. RPL continues the stepping > progression from ADL, and all RPL parts have E0 or newer display > steppings (bspec 55376). Ok, thanks. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v4] drm/i915: Do not cover all future platforms in TLB invalidation
On Tue, Jan 10, 2023 at 11:35:33AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Revert to the original explicit approach and document the reasoning
> behind it.
>
> v2:
> * DG2 needs to be covered too. (Matt)
>
> v3:
> * Full version check for Gen12 to avoid catching all future platforms.
>(Matt)
>
> v4:
> * Be totally explicit on the Gen12 branch. (Andrzej)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Matt Roper
> Cc: Balasubramani Vivekanandan
> Cc: Andrzej Hajda
> Reviewed-by: Andrzej Hajda # v1
> Reviewed-by: Matt Roper # v3
Reviewed-by: Matt Roper
for v4 as well.
Matt
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 75a7cb33..5721bf85d119 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -1070,10 +1070,23 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> unsigned int num = 0;
> unsigned long flags;
>
> - if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> + /*
> + * New platforms should not be added with catch-all-newer (>=)
> + * condition so that any later platform added triggers the below warning
> + * and in turn mandates a human cross-check of whether the invalidation
> + * flows have compatible semantics.
> + *
> + * For instance with the 11.00 -> 12.00 transition three out of five
> + * respective engine registers were moved to masked type. Then after the
> + * 12.00 -> 12.50 transition multi cast handling is required too.
> + */
> +
> + if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 50) ||
> + GRAPHICS_VER_FULL(i915) == IP_VER(12, 55)) {
> regs = NULL;
> num = ARRAY_SIZE(xehp_regs);
> - } else if (GRAPHICS_VER(i915) == 12) {
> + } else if (GRAPHICS_VER_FULL(i915) == IP_VER(12, 0) ||
> +GRAPHICS_VER_FULL(i915) == IP_VER(12, 10)) {
> regs = gen12_regs;
> num = ARRAY_SIZE(gen12_regs);
> } else if (GRAPHICS_VER(i915) >= 8 && GRAPHICS_VER(i915) <= 11) {
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, Jan 10, 2023 at 12:19:35PM +, Tvrtko Ursulin wrote:
>
> On 10/01/2023 11:28, Tvrtko Ursulin wrote:
> >
> >
> > On 09/01/2023 17:27, Jason Ekstrand wrote:
> >
> > [snip]
> >
> > > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > > contexts (per
> > > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > > invasive changes
> > > >>> to the shared code is in the spirit of the overall idea and
> > > instead
> > > >>> opportunity should be used to look at way to refactor/improve
> > > drm_sched.
> > >
> > >
> > > Maybe? I'm not convinced that what Xe is doing is an abuse at all
> > > or really needs to drive a re-factor. (More on that later.)
> > > There's only one real issue which is that it fires off potentially a
> > > lot of kthreads. Even that's not that bad given that kthreads are
> > > pretty light and you're not likely to have more kthreads than
> > > userspace threads which are much heavier. Not ideal, but not the
> > > end of the world either. Definitely something we can/should
> > > optimize but if we went through with Xe without this patch, it would
> > > probably be mostly ok.
> > >
> > > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > > >>
> > > >> I'm not really prepared to make large changes to DRM scheduler
> > > at the
> > > >> moment for Xe as they are not really required nor does Boris
> > > seem they
> > > >> will be required for his work either. I am interested to see
> > > what Boris
> > > >> comes up with.
> > > >>
> > > >>> Even on the low level, the idea to replace drm_sched threads
> > > with workers
> > > >>> has a few problems.
> > > >>>
> > > >>> To start with, the pattern of:
> > > >>>
> > > >>> while (not_stopped) {
> > > >>> keep picking jobs
> > > >>> }
> > > >>>
> > > >>> Feels fundamentally in disagreement with workers (while
> > > obviously fits
> > > >>> perfectly with the current kthread design).
> > > >>
> > > >> The while loop breaks and worker exists if no jobs are ready.
> > >
> > >
> > > I'm not very familiar with workqueues. What are you saying would fit
> > > better? One scheduling job per work item rather than one big work
> > > item which handles all available jobs?
> >
> > Yes and no, it indeed IMO does not fit to have a work item which is
> > potentially unbound in runtime. But it is a bit moot conceptual mismatch
> > because it is a worst case / theoretical, and I think due more
> > fundamental concerns.
> >
> > If we have to go back to the low level side of things, I've picked this
> > random spot to consolidate what I have already mentioned and perhaps
> > expand.
> >
> > To start with, let me pull out some thoughts from workqueue.rst:
> >
> > """
> > Generally, work items are not expected to hog a CPU and consume many
> > cycles. That means maintaining just enough concurrency to prevent work
> > processing from stalling should be optimal.
> > """
> >
> > For unbound queues:
> > """
> > The responsibility of regulating concurrency level is on the users.
> > """
> >
> > Given the unbound queues will be spawned on demand to service all queued
> > work items (more interesting when mixing up with the system_unbound_wq),
> > in the proposed design the number of instantiated worker threads does
> > not correspond to the number of user threads (as you have elsewhere
> > stated), but pessimistically to the number of active user contexts. That
> > is the number which drives the maximum number of not-runnable jobs that
> > can become runnable at once, and hence spawn that many work items, and
> > in turn unbound worker threads.
> >
> > Several problems there.
> >
> > It is fundamentally pointless to have potentially that many more threads
> > than the number of CPU cores - it simply creates a scheduling storm.
>
> To make matters worse, if I follow the code correctly, all these per user
> context worker thread / work items end up contending on the same lock or
> circular buffer, both are one instance per GPU:
>
> guc_engine_run_job
> -> submit_engine
> a) wq_item_append
> -> wq_wait_for_space
> -> msleep
a) is dedicated per xe_engine
Also you missed the step of programming the ring which is dedicated per
xe_engine
> b) xe_guc_ct_send
> -> guc_ct_send
> -> mutex_lock(>lock);
> -> later a potential msleep in h2g_has_room
Techincally there is 1 instance per GT not GPU, yes this is shared but
in practice there will always be space in the CT channel so contention
on the lock should be rare.
I haven't read your rather long reply yet, but also FWIW using a
workqueue has suggested by AMD (original authors of the DRM scheduler)
when we ran this design by them.
Matt
>
> Regards,
>
> Tvrtko
Re: [Intel-gfx] [PATCH] drm: Alloc high address for drm buddy topdown flag
On 10/01/2023 12:02, Matthew Auld wrote:
On 07/01/2023 15:15, Arunpravin Paneer Selvam wrote:
As we are observing low numbers in viewperf graphics benchmark, we
are strictly not allowing the top down flag enabled allocations
to steal the memory space from cpu visible region.
The approach is, we are sorting each order list entries in
ascending order and compare the last entry of each order
list in the freelist and return the max block.
Did you also run the selftests? Does everything still pass and complete
in a reasonable amount of time?
This patch improves the viewperf 3D benchmark scores.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 81 -
1 file changed, 54 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 11bb59399471..50916b2f2fc5 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -38,6 +38,25 @@ static void drm_block_free(struct drm_buddy *mm,
kmem_cache_free(slab_blocks, block);
}
+static void list_insert_sorted(struct drm_buddy *mm,
+ struct drm_buddy_block *block)
+{
+ struct drm_buddy_block *node;
+ struct list_head *head;
+
+ head = >free_list[drm_buddy_block_order(block)];
+ if (list_empty(head)) {
+ list_add(>link, head);
+ return;
+ }
+
+ list_for_each_entry(node, head, link)
+ if (drm_buddy_block_offset(block) <
drm_buddy_block_offset(node))
+ break;
+
+ __list_add(>link, node->link.prev, >link);
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -52,8 +71,7 @@ static void mark_free(struct drm_buddy *mm,
block->header &= ~DRM_BUDDY_HEADER_STATE;
block->header |= DRM_BUDDY_FREE;
- list_add(>link,
- >free_list[drm_buddy_block_order(block)]);
+ list_insert_sorted(mm, block);
One advantage of not sorting is when splitting down a large block.
Previously the most-recently-split would be at the start of the list for
the next order down, where potentially the next allocation could use it.
So perhaps less fragmentation if it's all part of one BO. Otherwise I
don't see any other downsides, other than the extra overhead of sorting.
}
static void mark_split(struct drm_buddy_block *block)
@@ -387,20 +405,26 @@ alloc_range_bias(struct drm_buddy *mm,
}
static struct drm_buddy_block *
-get_maxblock(struct list_head *head)
+get_maxblock(struct drm_buddy *mm, unsigned int order)
{
struct drm_buddy_block *max_block = NULL, *node;
+ unsigned int i;
- max_block = list_first_entry_or_null(head,
- struct drm_buddy_block,
- link);
- if (!max_block)
- return NULL;
+ for (i = order; i <= mm->max_order; ++i) {
+ if (!list_empty(>free_list[i])) {
+ node = list_last_entry(>free_list[i],
+ struct drm_buddy_block,
+ link);
+ if (!max_block) {
+ max_block = node;
+ continue;
+ }
- list_for_each_entry(node, head, link) {
- if (drm_buddy_block_offset(node) >
- drm_buddy_block_offset(max_block))
- max_block = node;
+ if (drm_buddy_block_offset(node) >
+ drm_buddy_block_offset(max_block)) {
Formatting doesn't look right here.
Going to test this today with some workloads with small-bar and i915
just to see if this improves/impacts anything for us.
No surprises, and as advertised seems to lead to reduced utilisation of
the mappable part for buffers that don't explicitly need it (TOPDOWN).
Assuming the selftests are still happy,
Reviewed-by: Matthew Auld
+ max_block = node;
+ }
+ }
}
return max_block;
@@ -412,20 +436,23 @@ alloc_from_freelist(struct drm_buddy *mm,
unsigned long flags)
{
struct drm_buddy_block *block = NULL;
- unsigned int i;
+ unsigned int tmp;
int err;
- for (i = order; i <= mm->max_order; ++i) {
- if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
- block = get_maxblock(>free_list[i]);
- if (block)
- break;
- } else {
- block = list_first_entry_or_null(>free_list[i],
- struct drm_buddy_block,
- link);
- if (block)
- break;
+ if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
+ block = get_maxblock(mm, order);
+ if (block)
+ /* Store the obtained block order */
+ tmp = drm_buddy_block_order(block);
+ } else {
+ for (tmp = order; tmp <= mm->max_order; ++tmp) {
+ if (!list_empty(>free_list[tmp])) {
+ block = list_last_entry(>free_list[tmp],
+ struct drm_buddy_block,
+
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/9] drm/i915/display/core: use intel_de_rmw if possible (rev3)
== Series Details ==
Series: series starting with [v2,1/9] drm/i915/display/core: use intel_de_rmw
if possible (rev3)
URL : https://patchwork.freedesktop.org/series/112438/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12567 -> Patchwork_112438v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_112438v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112438v3, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/index.html
Participating hosts (41 -> 41)
--
Additional (1): fi-kbl-soraka
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112438v3:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@guc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/fi-kbl-soraka/igt@i915_selftest@l...@guc.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@guc:
- {bat-rpls-2}: [PASS][2] -> [DMESG-WARN][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12567/bat-rpls-2/igt@i915_selftest@l...@guc.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/bat-rpls-2/igt@i915_selftest@l...@guc.html
Known issues
Here are the changes found in Patchwork_112438v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271]) +15 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#5334])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][8] ([i915#1886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.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#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6257]: https://gitlab.freedesktop.org/drm/intel/issues/6257
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
Build changes
-
* Linux: CI_DRM_12567 -> Patchwork_112438v3
CI-20190529: 20190529
CI_DRM_12567: a5cd9627b806f2f42bbacbf9649145f3954830d9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7114: 2fd839599a200c089a5c9dbf5048609faf9b8104 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112438v3: a5cd9627b806f2f42bbacbf9649145f3954830d9 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
737bb731534e drm/i915/display/misc: use intel_de_rmw if possible
4219e82d96cf drm/i915/display/interfaces: use intel_de_rmw if possible
bcb374d246e2 drm/i915/display/panel: use intel_de_rmw if possible in panel
related code
db81cb0d0791 drm/i915/display/hdmi: use intel_de_rmw if possible
a1b81bc46443 drm/i915/display/pch: use intel_de_rmw if possible
16d27bbb75d3 drm/i915/display/phys: use intel_de_rmw if possible
5717847cc9c8 drm/i915/display/dpll: use intel_de_rmw if possible
ed71f8596212 drm/i915/display/power: use intel_de_rmw if possible
842075203e0b drm/i915/display/core: use intel_de_rmw if possible
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112438v3/index.html
Re: [Intel-gfx] [RFC 2/2] drm/i915/display: Add 480 MHz CDCLK steps for RPL-U
On Tue, Jan 10, 2023 at 11:06:14AM +0200, Jani Nikula wrote:
> On Sat, 07 Jan 2023, Chaitanya Kumar Borah
> wrote:
> > A new step of 480MHz has been added on SKUs that have a RPL-U
> > device id to support 120Hz displays more efficiently. Use a
> > new quirk to identify the machine for which this change needs
> > to be applied.
> >
> > BSpec: 55409
> >
> > Signed-off-by: Chaitanya Kumar Borah
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 23 ++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 0c107a38f9d0..a437ac446871 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1329,6 +1329,27 @@ static const struct intel_cdclk_vals
> > adlp_cdclk_table[] = {
> > {}
> > };
> >
> > +static const struct intel_cdclk_vals rplu_cdclk_table[] = {
> > + { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27 },
> > + { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> > + { .refclk = 19200, .cdclk = 48, .divider = 2, .ratio = 50 },
> > + { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> > + { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> > +
> > + { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22 },
> > + { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> > + { .refclk = 24000, .cdclk = 48, .divider = 2, .ratio = 40 },
> > + { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> > + { .refclk = 24400, .cdclk = 648000, .divider = 2, .ratio = 54 },
> > +
> > + { .refclk = 38400, .cdclk = 179200, .divider = 3, .ratio = 14 },
> > + { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> > + { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25 },
> > + { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> > + { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
> > + {}
> > +};
> > +
> > static const struct intel_cdclk_vals dg2_cdclk_table[] = {
> > { .refclk = 38400, .cdclk = 163200, .divider = 2, .ratio = 34,
> > .waveform = 0x },
> > { .refclk = 38400, .cdclk = 204000, .divider = 2, .ratio = 34,
> > .waveform = 0x9248 },
> > @@ -3353,6 +3374,8 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> > *dev_priv)
> > /* Wa_22011320316:adl-p[a0] */
> > if (IS_ADLP_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0))
> > dev_priv->display.cdclk.table = adlp_a_step_cdclk_table;
>
> Are RPL-U A0-B0 going to enter this branch? Is this the right thing to
> do?
There's no such thing as a RPL A0/B0. RPL continues the stepping
progression from ADL, and all RPL parts have E0 or newer display
steppings (bspec 55376).
Matt
>
> BR,
> Jani.
>
>
> > + else if (IS_ADLP_RPLU(dev_priv))
> > + dev_priv->display.cdclk.table = rplu_cdclk_table;
> > else
> > dev_priv->display.cdclk.table = adlp_cdclk_table;
> > } else if (IS_ROCKETLAKE(dev_priv)) {
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH 1/4] vfio-mdev: allow building the samples into the kernel
On Tue, Jan 10, 2023 at 09:54:51AM -0500, Anthony Krowiak wrote: >> +tristate "Build VFIO mtty example mediated device sample code" >> +depends on VFIO_MDEV > > > Admittedly, I'm not very fluent with Kconfig, but in patch 2 you stated, > "VFIO_MDEV is just a library with helpers for the drivers. Stop making it a > user choice and just select it by the drivers that use the helpers". Why > are you not selecting it here? Because this changes one thing at a time. Patch 2 then switches this depends to a select.
Re: [Intel-gfx] [PATCH 1/4] vfio-mdev: allow building the samples into the kernel
On 1/10/23 10:27 AM, Christoph Hellwig wrote: On Tue, Jan 10, 2023 at 09:54:51AM -0500, Anthony Krowiak wrote: + tristate "Build VFIO mtty example mediated device sample code" + depends on VFIO_MDEV Admittedly, I'm not very fluent with Kconfig, but in patch 2 you stated, "VFIO_MDEV is just a library with helpers for the drivers. Stop making it a user choice and just select it by the drivers that use the helpers". Why are you not selecting it here? Because this changes one thing at a time. Patch 2 then switches this depends to a select. My bad, I missed it. Reviewed-by: Tony Krowiak
[Intel-gfx] [PATCH v2] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops
The Dell Latitude E6430 both with and without the optional NVidia dGPU
has a bug in its ACPI tables which is causing Linux to assign the wrong
ACPI fwnode / companion to the pci_device for the i915 iGPU.
Specifically under the PCI root bridge there are these 2 ACPI Device()s :
Scope (_SB.PCI0)
{
Device (GFX0)
{
Name (_ADR, 0x0002) // _ADR: Address
}
...
Device (VID)
{
Name (_ADR, 0x0002) // _ADR: Address
...
Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
{
VDP8 = Arg0
VDP1 (One, VDP8)
}
Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
{
...
}
...
}
}
The non-functional GFX0 ACPI device is a problem, because this gets
returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
This is a long standing problem and the i915 driver does use the ACPI
companion for some things, but works fine without it.
However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
and that is set on the wrong acpi_device because of the wrong
acpi_find_child_device() return. This breaks the ACPI video code,
leading to non working backlight control in some cases.
Add a type.backlight flag, mark ACPI video bus devices with this and make
find_child_checks() return a higher score for children with this flag set,
so that it picks the right companion-device.
Co-developed-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
Changes in v2:
- Switch to Rafael's suggested implementation using a type.backlight flag
and only make find_child_checks() return a higher score when this is set
---
drivers/acpi/glue.c | 14 --
drivers/acpi/scan.c | 7 +--
include/acpi/acpi_bus.h | 3 ++-
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 204fe94c7e45..a194f30876c5 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device
*dev)
}
#define FIND_CHILD_MIN_SCORE 1
-#define FIND_CHILD_MAX_SCORE 2
+#define FIND_CHILD_MID_SCORE 2
+#define FIND_CHILD_MAX_SCORE 3
static int match_any(struct acpi_device *adev, void *not_used)
{
@@ -96,8 +97,17 @@ static int find_child_checks(struct acpi_device *adev, bool
check_children)
return -ENODEV;
status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
- if (status == AE_NOT_FOUND)
+ if (status == AE_NOT_FOUND) {
+ /*
+* Special case: backlight device objects without _STA are
+* preferred to other objects with the same _ADR value, because
+* it is more likely that they are actually useful.
+*/
+ if (adev->pnp.type.backlight)
+ return FIND_CHILD_MID_SCORE;
+
return FIND_CHILD_MIN_SCORE;
+ }
if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
return -ENODEV;
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 274344434282..0c6f06abe3f4 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle handle, struct
acpi_device_pnp *pnp,
* Some devices don't reliably have _HIDs & _CIDs, so add
* synthetic HIDs to make sure drivers can find them.
*/
- if (acpi_is_video_device(handle))
+ if (acpi_is_video_device(handle)) {
acpi_add_id(pnp, ACPI_VIDEO_HID);
- else if (acpi_bay_match(handle))
+ pnp->type.backlight = 1;
+ break;
+ }
+ if (acpi_bay_match(handle))
acpi_add_id(pnp, ACPI_BAY_HID);
else if (acpi_dock_match(handle))
acpi_add_id(pnp, ACPI_DOCK_HID);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index cd3b75e08ec3..e44be31115a6 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -230,7 +230,8 @@ struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
u32 platform_id:1;
- u32 reserved:29;
+ u32 backlight:1;
+ u32 reserved:28;
};
struct acpi_device_pnp {
--
2.39.0
Re: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops
Hi Rafael,
On 1/10/23 14:33, Rafael J. Wysocki wrote:
> On Monday, January 9, 2023 9:57:21 PM CET Hans de Goede wrote:
>> The Dell Latitude E6430 both with and without the optional NVidia dGPU
>> has a bug in its ACPI tables which is causing Linux to assign the wrong
>> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>>
>> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
>>
>> Scope (_SB.PCI0)
>> {
>> Device (GFX0)
>> {
>> Name (_ADR, 0x0002) // _ADR: Address
>> }
>>
>> ...
>>
>> Device (VID)
>> {
>> Name (_ADR, 0x0002) // _ADR: Address
>> ...
>>
>> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
>> {
>> VDP8 = Arg0
>> VDP1 (One, VDP8)
>> }
>>
>> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
>> {
>> ...
>> }
>> ...
>> }
>> }
>>
>> The non-functional GFX0 ACPI device is a problem, because this gets
>> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
>>
>> This is a long standing problem and the i915 driver does use the ACPI
>> companion for some things, but works fine without it.
>>
>> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
>> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
>> and that is set on the wrong acpi_device because of the wrong
>> acpi_find_child_device() return. This breaks the ACPI video code, leading
>> to non working backlight control in some cases.
>
> Interesting. Sorry for the trouble.
No problem, as mentioned this is actually a long standing issue / bug
in the ACPI tables, it just never surfaced before.
>> Make find_child_checks() return a higher score for children which have
>> pnp-ids set by various scan helpers like acpi_is_video_device(), so
>> that it picks the right companion-device.
>
> This has a potential of changing the behavior in some cases that are not
> relevant here which is generally risky.
>
>> An alternative approach would be to directly call acpi_is_video_device()
>> from find_child_checks() but that would be somewhat computationally
>> expensive given that acpi_find_child_device() iterates over all the
>> PCI0 children every time it is called.
>
> I agree with the above, but my fix would be something like the patch below
> (not
> really tested, but it builds).
Thanks, I have just given this a spin on my E6430 and I can confirm
it still fixes things.
I'll send out this version (re-using most of the v1 commitmsg) as a v2
right away.
Regards,
Hans
>
> ---
> drivers/acpi/glue.c | 14 --
> drivers/acpi/scan.c |7 +--
> include/acpi/acpi_bus.h |3 ++-
> 3 files changed, 19 insertions(+), 5 deletions(-)
>
> Index: linux-pm/include/acpi/acpi_bus.h
> ===
> --- linux-pm.orig/include/acpi/acpi_bus.h
> +++ linux-pm/include/acpi/acpi_bus.h
> @@ -230,7 +230,8 @@ struct acpi_pnp_type {
> u32 hardware_id:1;
> u32 bus_address:1;
> u32 platform_id:1;
> - u32 reserved:29;
> + u32 backlight:1;
> + u32 reserved:28;
> };
>
> struct acpi_device_pnp {
> Index: linux-pm/drivers/acpi/scan.c
> ===
> --- linux-pm.orig/drivers/acpi/scan.c
> +++ linux-pm/drivers/acpi/scan.c
> @@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle
>* Some devices don't reliably have _HIDs & _CIDs, so add
>* synthetic HIDs to make sure drivers can find them.
>*/
> - if (acpi_is_video_device(handle))
> + if (acpi_is_video_device(handle)) {
> acpi_add_id(pnp, ACPI_VIDEO_HID);
> - else if (acpi_bay_match(handle))
> + pnp->type.backlight = 1;
> + break;
> + }
> + if (acpi_bay_match(handle))
> acpi_add_id(pnp, ACPI_BAY_HID);
> else if (acpi_dock_match(handle))
> acpi_add_id(pnp, ACPI_DOCK_HID);
> Index: linux-pm/drivers/acpi/glue.c
> ===
> --- linux-pm.orig/drivers/acpi/glue.c
> +++ linux-pm/drivers/acpi/glue.c
> @@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bu
> }
>
> #define FIND_CHILD_MIN_SCORE 1
> -#define FIND_CHILD_MAX_SCORE 2
> +#define FIND_CHILD_MID_SCORE 2
> +#define FIND_CHILD_MAX_SCORE 3
>
> static int match_any(struct acpi_device *adev, void *not_used)
> {
> @@ -96,8 +97,17 @@ static int find_child_checks(struct acpi
> return -ENODEV;
>
> status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
> - if (status == AE_NOT_FOUND)
> + if (status == AE_NOT_FOUND) {
> + /*
> + * Special case:
Re: [Intel-gfx] [PATCH] drm: Alloc high address for drm buddy topdown flag
Hi Matthew,
On 1/10/2023 5:32 PM, Matthew Auld wrote:
On 07/01/2023 15:15, Arunpravin Paneer Selvam wrote:
As we are observing low numbers in viewperf graphics benchmark, we
are strictly not allowing the top down flag enabled allocations
to steal the memory space from cpu visible region.
The approach is, we are sorting each order list entries in
ascending order and compare the last entry of each order
list in the freelist and return the max block.
Did you also run the selftests? Does everything still pass and
complete in a reasonable amount of time?
I will try giving a run
This patch improves the viewperf 3D benchmark scores.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/drm_buddy.c | 81 -
1 file changed, 54 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 11bb59399471..50916b2f2fc5 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -38,6 +38,25 @@ static void drm_block_free(struct drm_buddy *mm,
kmem_cache_free(slab_blocks, block);
}
+static void list_insert_sorted(struct drm_buddy *mm,
+ struct drm_buddy_block *block)
+{
+ struct drm_buddy_block *node;
+ struct list_head *head;
+
+ head = >free_list[drm_buddy_block_order(block)];
+ if (list_empty(head)) {
+ list_add(>link, head);
+ return;
+ }
+
+ list_for_each_entry(node, head, link)
+ if (drm_buddy_block_offset(block) <
drm_buddy_block_offset(node))
+ break;
+
+ __list_add(>link, node->link.prev, >link);
+}
+
static void mark_allocated(struct drm_buddy_block *block)
{
block->header &= ~DRM_BUDDY_HEADER_STATE;
@@ -52,8 +71,7 @@ static void mark_free(struct drm_buddy *mm,
block->header &= ~DRM_BUDDY_HEADER_STATE;
block->header |= DRM_BUDDY_FREE;
- list_add(>link,
- >free_list[drm_buddy_block_order(block)]);
+ list_insert_sorted(mm, block);
One advantage of not sorting is when splitting down a large block.
Previously the most-recently-split would be at the start of the list
for the next order down, where potentially the next allocation could
use it. So perhaps less fragmentation if it's all part of one BO.
Otherwise I don't see any other downsides, other than the extra
overhead of sorting.
Allocating from freelist is traversing through right side (i.e top most
address range) and for TOPDOWN flag allocations we just split the top
most large block once and the subsequent TOPDOWN low order allocations
would get block from same already split large block
For the normal allocations, I modified to retrieve the blocks in each
order list from the last entry which has the high probability of getting
top most blocks as we have sorted the blocks in each order list.
Thus the bottom most large blocks are not frequently used, hence we have
more space for the visible region on dGPU.
For APU which has small sized VRAM space, the allocations are now
ordered and we don't allocate randomly from freelist solving
fragmentation issues.
}
static void mark_split(struct drm_buddy_block *block)
@@ -387,20 +405,26 @@ alloc_range_bias(struct drm_buddy *mm,
}
static struct drm_buddy_block *
-get_maxblock(struct list_head *head)
+get_maxblock(struct drm_buddy *mm, unsigned int order)
{
struct drm_buddy_block *max_block = NULL, *node;
+ unsigned int i;
- max_block = list_first_entry_or_null(head,
- struct drm_buddy_block,
- link);
- if (!max_block)
- return NULL;
+ for (i = order; i <= mm->max_order; ++i) {
+ if (!list_empty(>free_list[i])) {
+ node = list_last_entry(>free_list[i],
+ struct drm_buddy_block,
+ link);
+ if (!max_block) {
+ max_block = node;
+ continue;
+ }
- list_for_each_entry(node, head, link) {
- if (drm_buddy_block_offset(node) >
- drm_buddy_block_offset(max_block))
- max_block = node;
+ if (drm_buddy_block_offset(node) >
+ drm_buddy_block_offset(max_block)) {
Formatting doesn't look right here.
I will check.
Going to test this today with some workloads with small-bar and i915
just to see if this improves/impacts anything for us.
+ max_block = node;
+ }
+ }
}
return max_block;
@@ -412,20 +436,23 @@ alloc_from_freelist(struct drm_buddy *mm,
unsigned long flags)
{
struct drm_buddy_block *block = NULL;
- unsigned int i;
+ unsigned int tmp;
int err;
- for (i = order; i <= mm->max_order; ++i) {
- if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
- block = get_maxblock(>free_list[i]);
- if (block)
- break;
- } else {
- block = list_first_entry_or_null(>free_list[i],
-
Re: [Intel-gfx] [PATCH] Copy highest enabled wm level to disabled wm levels for gen >= 12
On Tue, Dec 20, 2022 at 01:19:54PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 19, 2022 at 09:29:19AM +0200, Stanislav Lisovskiy wrote:
> > There was a specific SW workaround requested, which should prevent
> > some watermark issues happening, which requires copying highest
> > enabled wm level to those disabled wm levels(bit 31 is of course
> > still needs to be cleared).
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > drivers/gpu/drm/i915/display/skl_watermark.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> > b/drivers/gpu/drm/i915/display/skl_watermark.c
> > index ae4e9e680c2e3..b12e11cd6e579 100644
> > --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> > +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> > @@ -1591,6 +1591,13 @@ skl_crtc_allocate_plane_ddb(struct
> > intel_atomic_state *state,
> > wm->wm[level].lines = wm->wm[0].lines;
> > wm->wm[level].ignore_lines =
> > wm->wm[0].ignore_lines;
> > }
> > +
> > + /* Wa_14017887344 */
> > + if (DISPLAY_VER(i915) >= 12 && level > 0) {
> > + wm->wm[level].blocks = wm->wm[level - 1].blocks;
> > + wm->wm[level].lines = wm->wm[level - 1].lines;
> > + wm->wm[level].ignore_lines = wm->wm[level -
> > 1].ignore_lines;
> > + }
>
> Hmm. Reading the parent hsd this smells at least partially as
> some kind of race in the Windows driver between async flip,
> wm1+ disable, and the PSR wm level override behaviour.
>
> We never do async flip + wm1+ disable from the same commit
> which itself might be sufficient to avoid the issue. I
> didn't think that even worked, but maybe it sort of does
> if Windows attempts it. However since we don't do that we
> might never hit this. Not sure.
>
> The PSR wm level override stuff we don't handle at all
> currently. I'm thinking that is something we should
> remedy first.
>
> Also while thinking about how to unify this and the
> already existing wm1 w/a I realized that we don't
> check if the wm level is actually enabled or not.
> So it's interfering with commit a301cb0fca2d ("drm/i915:
> Keep plane watermarks enabled more aggressively").
> My gut reaction is that we want a wm[level].enable
> check there, but I've not fully thought through the
> implications...
As I understand in order for this W/A to become essential,
following conditions should be combined:
1) We are doing async flips, with all WM levels > 0 being
disabled(this all 0's are written to wm level registers)
2) PSR optimization has to be turned on(controlled in CHICKEN_DCPR_1 reg)
This optimization enables the highest possible WM level, when PSR
is used.
This seems to get into contradiction with 1).
We have actually already this W/A implemented to disable that optimization
for small vblanks, however as I understand it isn't always enabled
(it is enabled only for DG1/TGL for some reason in our code)
so that's why we also set those WM level regs to some sane values.
But could be that we need to limit it to async flips only?
Stan
>
> > }
> > }
> >
> > --
> > 2.37.3
>
> --
> Ville Syrjälä
> Intel
Re: [Intel-gfx] [PATCH 1/4] vfio-mdev: allow building the samples into the kernel
On 1/10/23 4:10 AM, Christoph Hellwig wrote: There is nothing in the vfio-mdev sample drivers that requires building them as modules, so remove that restriction. Signed-off-by: Christoph Hellwig --- samples/Kconfig | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/samples/Kconfig b/samples/Kconfig index 0d81c00289ee36..f1b8d4ff123036 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -184,23 +184,23 @@ config SAMPLE_UHID Build UHID sample program. config SAMPLE_VFIO_MDEV_MTTY - tristate "Build VFIO mtty example mediated device sample code -- loadable modules only" - depends on VFIO_MDEV && m + tristate "Build VFIO mtty example mediated device sample code" + depends on VFIO_MDEV Admittedly, I'm not very fluent with Kconfig, but in patch 2 you stated, "VFIO_MDEV is just a library with helpers for the drivers. Stop making it a user choice and just select it by the drivers that use the helpers". Why are you not selecting it here? help Build a virtual tty sample driver for use as a VFIO mediated device config SAMPLE_VFIO_MDEV_MDPY - tristate "Build VFIO mdpy example mediated device sample code -- loadable modules only" - depends on VFIO_MDEV && m + tristate "Build VFIO mdpy example mediated device sample code" + depends on VFIO_MDEV help Build a virtual display sample driver for use as a VFIO mediated device. It is a simple framebuffer and supports the region display interface (VFIO_GFX_PLANE_TYPE_REGION). config SAMPLE_VFIO_MDEV_MDPY_FB - tristate "Build VFIO mdpy example guest fbdev driver -- loadable module only" - depends on FB && m + tristate "Build VFIO mdpy example guest fbdev driver" + depends on FB select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT @@ -208,8 +208,8 @@ config SAMPLE_VFIO_MDEV_MDPY_FB Guest fbdev driver for the virtual display sample driver. config SAMPLE_VFIO_MDEV_MBOCHS - tristate "Build VFIO mdpy example mediated device sample code -- loadable modules only" - depends on VFIO_MDEV && m + tristate "Build VFIO mdpy example mediated device sample code" + depends on VFIO_MDEV select DMA_SHARED_BUFFER help Build a virtual display sample driver for use as a VFIO
Re: [Intel-gfx] [PATCH 2/4] vfio-mdev: turn VFIO_MDEV into a selectable symbol
Reviewed-by: Tony Krowiak On 1/10/23 4:10 AM, Christoph Hellwig wrote: VFIO_MDEV is just a library with helpers for the drivers. Stop making it a user choice and just select it by the drivers that use the helpers. Signed-off-by: Christoph Hellwig --- Documentation/s390/vfio-ap.rst| 1 - arch/s390/Kconfig | 6 -- arch/s390/configs/debug_defconfig | 1 - arch/s390/configs/defconfig | 1 - drivers/gpu/drm/i915/Kconfig | 2 +- drivers/vfio/mdev/Kconfig | 8 +--- samples/Kconfig | 6 +++--- 7 files changed, 9 insertions(+), 16 deletions(-) diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index 00f4a04f6d4c6a..d46e98c7c1ec6c 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -553,7 +553,6 @@ These are the steps: * ZCRYPT * S390_AP_IOMMU * VFIO - * VFIO_MDEV * KVM If using make menuconfig select the following to build the vfio_ap module:: diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 318fce77601d35..60fddcdad495e6 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -705,7 +705,8 @@ config EADM_SCH config VFIO_CCW def_tristate n prompt "Support for VFIO-CCW subchannels" - depends on S390_CCW_IOMMU && VFIO_MDEV + depends on S390_CCW_IOMMU + select VFIO_MDEV help This driver allows usage of I/O subchannels via VFIO-CCW. @@ -715,7 +716,8 @@ config VFIO_CCW config VFIO_AP def_tristate n prompt "VFIO support for AP devices" - depends on S390_AP_IOMMU && VFIO_MDEV && KVM + depends on S390_AP_IOMMU && KVM + select VFIO_MDEV depends on ZCRYPT help This driver grants access to Adjunct Processor (AP) devices diff --git a/arch/s390/configs/debug_defconfig b/arch/s390/configs/debug_defconfig index 2a827002934bc6..e78fc3ba7d442a 100644 --- a/arch/s390/configs/debug_defconfig +++ b/arch/s390/configs/debug_defconfig @@ -596,7 +596,6 @@ CONFIG_SYNC_FILE=y CONFIG_VFIO=m CONFIG_VFIO_PCI=m CONFIG_MLX5_VFIO_PCI=m -CONFIG_VFIO_MDEV=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m CONFIG_VIRTIO_INPUT=y diff --git a/arch/s390/configs/defconfig b/arch/s390/configs/defconfig index fb780e80e4c8f7..f7eb2e527b6e65 100644 --- a/arch/s390/configs/defconfig +++ b/arch/s390/configs/defconfig @@ -585,7 +585,6 @@ CONFIG_SYNC_FILE=y CONFIG_VFIO=m CONFIG_VFIO_PCI=m CONFIG_MLX5_VFIO_PCI=m -CONFIG_VFIO_MDEV=m CONFIG_VIRTIO_PCI=m CONFIG_VIRTIO_BALLOON=m CONFIG_VIRTIO_INPUT=y diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig index 3efce05d7b57ca..d06da455253cdb 100644 --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -116,9 +116,9 @@ config DRM_I915_GVT_KVMGT depends on X86 depends on 64BIT depends on KVM - depends on VFIO_MDEV select DRM_I915_GVT select KVM_EXTERNAL_WRITE_TRACKING + select VFIO_MDEV help Choose this option if you want to enable Intel GVT-g graphics diff --git a/drivers/vfio/mdev/Kconfig b/drivers/vfio/mdev/Kconfig index 646dbed44eb283..e5fb84e0796507 100644 --- a/drivers/vfio/mdev/Kconfig +++ b/drivers/vfio/mdev/Kconfig @@ -1,10 +1,4 @@ # SPDX-License-Identifier: GPL-2.0-only config VFIO_MDEV - tristate "Mediated device driver framework" - default n - help - Provides a framework to virtualize devices. - See Documentation/driver-api/vfio-mediated-device.rst for more details. - - If you don't know what do here, say N. + tristate diff --git a/samples/Kconfig b/samples/Kconfig index f1b8d4ff123036..56b191d128d88f 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -185,14 +185,14 @@ config SAMPLE_UHID config SAMPLE_VFIO_MDEV_MTTY tristate "Build VFIO mtty example mediated device sample code" - depends on VFIO_MDEV + select VFIO_MDEV help Build a virtual tty sample driver for use as a VFIO mediated device config SAMPLE_VFIO_MDEV_MDPY tristate "Build VFIO mdpy example mediated device sample code" - depends on VFIO_MDEV + select VFIO_MDEV help Build a virtual display sample driver for use as a VFIO mediated device. It is a simple framebuffer and supports @@ -209,7 +209,7 @@ config SAMPLE_VFIO_MDEV_MDPY_FB config SAMPLE_VFIO_MDEV_MBOCHS tristate "Build VFIO mdpy example mediated device sample code" - depends on VFIO_MDEV + select VFIO_MDEV select DMA_SHARED_BUFFER help Build a virtual display sample driver for use as a VFIO
Re: [Intel-gfx] [PATCH 4/4] vfio-mdev: remove an non-existing driver from vfio-mediated-device
LGTM Reviewed-by: Tony Krowiak On 1/10/23 4:10 AM, Christoph Hellwig wrote: The nvidia mdev driver does not actually exist anywhere in the tree. Signed-off-by: Christoph Hellwig --- Documentation/driver-api/vfio-mediated-device.rst | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index d4267243b4f525..bbd548b66b4255 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -60,7 +60,7 @@ devices as examples, as these devices are the first devices to use this module:: | mdev.ko | | +---+ | mdev_register_parent() +--+ | | | +<+ | - | | | | | nvidia.ko |<-> physical + | | | | | ccw_device.ko|<-> physical | | | +>+ |device | | | |callbacks+--+ | | Physical | | @@ -69,12 +69,6 @@ devices as examples, as these devices are the first devices to use this module:: | | | | | i915.ko |<-> physical | | | +>+ |device | | | |callbacks+--+ - | | | | - | | | | mdev_register_parent() +--+ - | | | +<+ | - | | | | | ccw_device.ko|<-> physical - | | | +>+ |device - | | | |callbacks+--+ | +---+ | +---+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not cover all future platforms in TLB invalidation (rev3)
== Series Details ==
Series: drm/i915: Do not cover all future platforms in TLB invalidation (rev3)
URL : https://patchwork.freedesktop.org/series/112484/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12566 -> Patchwork_112484v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/index.html
Participating hosts (42 -> 39)
--
Missing(3): fi-kbl-soraka fi-snb-2520m fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112484v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@reset:
- {bat-rpls-2}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/bat-rpls-2/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/bat-rpls-2/igt@i915_selftest@l...@reset.html
Known issues
Here are the changes found in Patchwork_112484v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_lrc:
- fi-rkl-guc: [PASS][3] -> [INCOMPLETE][4] ([i915#4983])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/fi-rkl-guc/igt@i915_selftest@live@gt_lrc.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- {fi-ehl-2}: [DMESG-FAIL][5] ([i915#5334]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/fi-ehl-2/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/fi-ehl-2/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_lrc:
- {bat-adln-1}: [INCOMPLETE][7] ([i915#4983] / [i915#7609]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/bat-adln-1/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][9] ([i915#6367]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][11] ([fdo#103375]) -> [INCOMPLETE][12]
([i915#4817])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12566/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
Build changes
-
* Linux: CI_DRM_12566 -> Patchwork_112484v3
CI-20190529: 20190529
CI_DRM_12566: bf50c1a489dcc0e8a77211a8145f359c4996a538 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7114: 2fd839599a200c089a5c9dbf5048609faf9b8104 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112484v3: bf50c1a489dcc0e8a77211a8145f359c4996a538 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
ed809ebb5f30 drm/i915: Do not cover all future platforms in TLB invalidation
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112484v3/index.html
Re: [Intel-gfx] [RFC PATCH 04/20] drm/sched: Convert drm scheduler to use a work queue rather than kthread
On Tue, Jan 10, 2023 at 5:28 AM Tvrtko Ursulin <
tvrtko.ursu...@linux.intel.com> wrote:
>
>
> On 09/01/2023 17:27, Jason Ekstrand wrote:
>
> [snip]
>
> > >>> AFAICT it proposes to have 1:1 between *userspace* created
> > contexts (per
> > >>> context _and_ engine) and drm_sched. I am not sure avoiding
> > invasive changes
> > >>> to the shared code is in the spirit of the overall idea and
> instead
> > >>> opportunity should be used to look at way to refactor/improve
> > drm_sched.
> >
> >
> > Maybe? I'm not convinced that what Xe is doing is an abuse at all or
> > really needs to drive a re-factor. (More on that later.) There's only
> > one real issue which is that it fires off potentially a lot of kthreads.
> > Even that's not that bad given that kthreads are pretty light and you're
> > not likely to have more kthreads than userspace threads which are much
> > heavier. Not ideal, but not the end of the world either. Definitely
> > something we can/should optimize but if we went through with Xe without
> > this patch, it would probably be mostly ok.
> >
> > >> Yes, it is 1:1 *userspace* engines and drm_sched.
> > >>
> > >> I'm not really prepared to make large changes to DRM scheduler
> > at the
> > >> moment for Xe as they are not really required nor does Boris
> > seem they
> > >> will be required for his work either. I am interested to see
> > what Boris
> > >> comes up with.
> > >>
> > >>> Even on the low level, the idea to replace drm_sched threads
> > with workers
> > >>> has a few problems.
> > >>>
> > >>> To start with, the pattern of:
> > >>>
> > >>>while (not_stopped) {
> > >>> keep picking jobs
> > >>>}
> > >>>
> > >>> Feels fundamentally in disagreement with workers (while
> > obviously fits
> > >>> perfectly with the current kthread design).
> > >>
> > >> The while loop breaks and worker exists if no jobs are ready.
> >
> >
> > I'm not very familiar with workqueues. What are you saying would fit
> > better? One scheduling job per work item rather than one big work item
> > which handles all available jobs?
>
> Yes and no, it indeed IMO does not fit to have a work item which is
> potentially unbound in runtime. But it is a bit moot conceptual mismatch
> because it is a worst case / theoretical, and I think due more
> fundamental concerns.
>
> If we have to go back to the low level side of things, I've picked this
> random spot to consolidate what I have already mentioned and perhaps
> expand.
>
> To start with, let me pull out some thoughts from workqueue.rst:
>
> """
> Generally, work items are not expected to hog a CPU and consume many
> cycles. That means maintaining just enough concurrency to prevent work
> processing from stalling should be optimal.
> """
>
> For unbound queues:
> """
> The responsibility of regulating concurrency level is on the users.
> """
>
> Given the unbound queues will be spawned on demand to service all queued
> work items (more interesting when mixing up with the system_unbound_wq),
> in the proposed design the number of instantiated worker threads does
> not correspond to the number of user threads (as you have elsewhere
> stated), but pessimistically to the number of active user contexts.
Those are pretty much the same in practice. Rather, user threads is
typically an upper bound on the number of contexts. Yes, a single user
thread could have a bunch of contexts but basically nothing does that
except IGT. In real-world usage, it's at most one context per user thread.
> That
> is the number which drives the maximum number of not-runnable jobs that
> can become runnable at once, and hence spawn that many work items, and
> in turn unbound worker threads.
>
> Several problems there.
>
> It is fundamentally pointless to have potentially that many more threads
> than the number of CPU cores - it simply creates a scheduling storm.
>
> Unbound workers have no CPU / cache locality either and no connection
> with the CPU scheduler to optimize scheduling patterns. This may matter
> either on large systems or on small ones. Whereas the current design
> allows for scheduler to notice userspace CPU thread keeps waking up the
> same drm scheduler kernel thread, and so it can keep them on the same
> CPU, the unbound workers lose that ability and so 2nd CPU might be
> getting woken up from low sleep for every submission.
>
> Hence, apart from being a bit of a impedance mismatch, the proposal has
> the potential to change performance and power patterns and both large
> and small machines.
>
Ok, thanks for explaining the issue you're seeing in more detail. Yes,
deferred kwork does appear to mismatch somewhat with what the scheduler
needs or at least how it's worked in the past. How much impact will that
mismatch have? Unclear.
> > >>> Secondly, it probably demands separate workers (not
Re: [Intel-gfx] [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
On Tue, Jan 10, 2023 at 01:46:37PM +0100, Andrzej Hajda wrote: > On 10.01.2023 12:07, Andy Shevchenko wrote: > > On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote: ... > > > + return __xchg(_chain->p_prod_elem, > > > + (void *)(((u8 *)p_chain->p_prod_elem) + > > > p_chain->elem_size)); > > > > Wondering if you still need a (void *) casting after the change. Ditto for > > the > > rest of similar cases. > > IMHO it is not needed also before the change and IIRC gcc has an extension > which allows to drop (u8 *) cast as well [1]. I guess you can drop at least the former one. > [1]: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html ... > > Btw, is it done by coccinelle? If no, why not providing the script? > > Yes I have used cocci. My cocci skills are far from perfect, so I did not > want to share my dirty code, but this is nothing secret: Thank you! It's not about secrecy, it's about automation / error proofness. -- With Best Regards, Andy Shevchenko
Re: [Intel-gfx] [PATCH] ACPI: Fix selecting the wrong ACPI fwnode for the iGPU on some Dell laptops
On Monday, January 9, 2023 9:57:21 PM CET Hans de Goede wrote:
> The Dell Latitude E6430 both with and without the optional NVidia dGPU
> has a bug in its ACPI tables which is causing Linux to assign the wrong
> ACPI fwnode / companion to the pci_device for the i915 iGPU.
>
> Specifically under the PCI root bridge there are these 2 ACPI Device()s :
>
> Scope (_SB.PCI0)
> {
> Device (GFX0)
> {
> Name (_ADR, 0x0002) // _ADR: Address
> }
>
> ...
>
> Device (VID)
> {
> Name (_ADR, 0x0002) // _ADR: Address
> ...
>
> Method (_DOS, 1, NotSerialized) // _DOS: Disable Output Switching
> {
> VDP8 = Arg0
> VDP1 (One, VDP8)
> }
>
> Method (_DOD, 0, NotSerialized) // _DOD: Display Output Devices
> {
> ...
> }
> ...
> }
> }
>
> The non-functional GFX0 ACPI device is a problem, because this gets
> returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
>
> This is a long standing problem and the i915 driver does use the ACPI
> companion for some things, but works fine without it.
>
> However since commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
> and that is set on the wrong acpi_device because of the wrong
> acpi_find_child_device() return. This breaks the ACPI video code, leading
> to non working backlight control in some cases.
Interesting. Sorry for the trouble.
> Make find_child_checks() return a higher score for children which have
> pnp-ids set by various scan helpers like acpi_is_video_device(), so
> that it picks the right companion-device.
This has a potential of changing the behavior in some cases that are not
relevant here which is generally risky.
> An alternative approach would be to directly call acpi_is_video_device()
> from find_child_checks() but that would be somewhat computationally
> expensive given that acpi_find_child_device() iterates over all the
> PCI0 children every time it is called.
I agree with the above, but my fix would be something like the patch below (not
really tested, but it builds).
---
drivers/acpi/glue.c | 14 --
drivers/acpi/scan.c |7 +--
include/acpi/acpi_bus.h |3 ++-
3 files changed, 19 insertions(+), 5 deletions(-)
Index: linux-pm/include/acpi/acpi_bus.h
===
--- linux-pm.orig/include/acpi/acpi_bus.h
+++ linux-pm/include/acpi/acpi_bus.h
@@ -230,7 +230,8 @@ struct acpi_pnp_type {
u32 hardware_id:1;
u32 bus_address:1;
u32 platform_id:1;
- u32 reserved:29;
+ u32 backlight:1;
+ u32 reserved:28;
};
struct acpi_device_pnp {
Index: linux-pm/drivers/acpi/scan.c
===
--- linux-pm.orig/drivers/acpi/scan.c
+++ linux-pm/drivers/acpi/scan.c
@@ -1370,9 +1370,12 @@ static void acpi_set_pnp_ids(acpi_handle
* Some devices don't reliably have _HIDs & _CIDs, so add
* synthetic HIDs to make sure drivers can find them.
*/
- if (acpi_is_video_device(handle))
+ if (acpi_is_video_device(handle)) {
acpi_add_id(pnp, ACPI_VIDEO_HID);
- else if (acpi_bay_match(handle))
+ pnp->type.backlight = 1;
+ break;
+ }
+ if (acpi_bay_match(handle))
acpi_add_id(pnp, ACPI_BAY_HID);
else if (acpi_dock_match(handle))
acpi_add_id(pnp, ACPI_DOCK_HID);
Index: linux-pm/drivers/acpi/glue.c
===
--- linux-pm.orig/drivers/acpi/glue.c
+++ linux-pm/drivers/acpi/glue.c
@@ -75,7 +75,8 @@ static struct acpi_bus_type *acpi_get_bu
}
#define FIND_CHILD_MIN_SCORE 1
-#define FIND_CHILD_MAX_SCORE 2
+#define FIND_CHILD_MID_SCORE 2
+#define FIND_CHILD_MAX_SCORE 3
static int match_any(struct acpi_device *adev, void *not_used)
{
@@ -96,8 +97,17 @@ static int find_child_checks(struct acpi
return -ENODEV;
status = acpi_evaluate_integer(adev->handle, "_STA", NULL, );
- if (status == AE_NOT_FOUND)
+ if (status == AE_NOT_FOUND) {
+ /*
+* Special case: backlight device objects without _STA are
+* preferred to other objects with the same _ADR value, because
+* it is more likely that they are actually useful.
+*/
+ if (adev->pnp.type.backlight)
+ return FIND_CHILD_MID_SCORE;
+
return FIND_CHILD_MIN_SCORE;
+ }
if (ACPI_FAILURE(status) || !(sta & ACPI_STA_DEVICE_ENABLED))
return -ENODEV;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove i915_drm_suspend_mode
== Series Details ==
Series: drm/i915: Remove i915_drm_suspend_mode
URL : https://patchwork.freedesktop.org/series/112607/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12565 -> Patchwork_112607v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-kbl-soraka
Missing(2): fi-rkl-11600 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_112607v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +15 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@guc_multi_lrc:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][5] ([i915#7640])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/fi-kbl-soraka/igt@i915_selftest@live@guc_multi_lrc.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adln-1}: [DMESG-WARN][6] ([i915#2867]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/bat-adln-1/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/bat-adln-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@mman:
- fi-rkl-guc: [TIMEOUT][8] ([i915#6794]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12565/fi-rkl-guc/igt@i915_selftest@l...@mman.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/fi-rkl-guc/igt@i915_selftest@l...@mman.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#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794
[i915#7640]: https://gitlab.freedesktop.org/drm/intel/issues/7640
Build changes
-
* Linux: CI_DRM_12565 -> Patchwork_112607v1
CI-20190529: 20190529
CI_DRM_12565: 1617f7f4ff6b95ef03d4228bf9f757a6c6488c91 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7114: 2fd839599a200c089a5c9dbf5048609faf9b8104 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112607v1: 1617f7f4ff6b95ef03d4228bf9f757a6c6488c91 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
76c3d69af607 drm/i915: Remove i915_drm_suspend_mode
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112607v1/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: drop redundant display/ from #includes (rev5)
== Series Details ==
Series: drm/i915/display: drop redundant display/ from #includes (rev5)
URL : https://patchwork.freedesktop.org/series/111803/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12562_full -> Patchwork_111803v5_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/index.html
Participating hosts (13 -> 10)
--
Missing(3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_111803v5_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@system-suspend-execbuf:
- {shard-tglu-10}:NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-tglu-10/igt@i915_pm_...@system-suspend-execbuf.html
Known issues
Here are the changes found in Patchwork_111803v5_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_capture@capture-invisible@smem0:
- shard-glk: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#6334])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-glk1/igt@gem_exec_capture@capture-invisi...@smem0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-glk1/igt@kms_ccs@pipe-a-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_edid@dp-edid-change-during-suspend:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +15 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-glk1/igt@kms_chamelium_e...@dp-edid-change-during-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-glk9/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-glk1/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][9] ([i915#7742]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-rkl-3/igt@fb...@pan.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-rkl-6/igt@fb...@pan.html
* igt@feature_discovery@psr1:
- {shard-rkl}:[SKIP][13] ([i915#658]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-rkl-4/igt@feature_discov...@psr1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-rkl-6/igt@feature_discov...@psr1.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][15] ([i915#6268]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-rkl-2/igt@gem_ctx_e...@basic-nohangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-rkl-5/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_eio@in-flight-contexts-1us:
- {shard-rkl}:[TIMEOUT][17] ([i915#3063]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-rkl-1/igt@gem_...@in-flight-contexts-1us.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-rkl-2/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_eio@kms:
- {shard-dg1}:[FAIL][19] ([i915#5784]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12562/shard-dg1-19/igt@gem_...@kms.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_111803v5/shard-dg1-18/igt@gem_...@kms.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][21] ([i915#2842]) -> [PASS][22] +2 similar
issues
[21]:
Re: [Intel-gfx] [RFC DO NOT MERGE] treewide: use __xchg in most obvious places
On 10.01.2023 12:07, Andy Shevchenko wrote:
On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote:
This patch tries to show usability of __xchg helper.
It is not intended to be merged, but I can convert
it to proper patchset if necessary.
There are many more places where __xchg can be used.
This demo shows the most spectacular cases IMHO:
- previous value is returned from function,
- temporary variables are in use.
As a result readability is much better and diffstat is quite
nice, less local vars to look at.
In many cases whole body of functions is replaced
with __xchg(ptr, val), so as further refactoring the whole
function can be removed and __xchg can be called directly.
...
arch_uretprobe_hijack_return_addr(unsigned long trampoline_vaddr,
struct pt_regs *regs)
{
- unsigned long orig_ret_vaddr;
-
- orig_ret_vaddr = regs->ARM_lr;
- /* Replace the return addr with trampoline addr */
- regs->ARM_lr = trampoline_vaddr;
- return orig_ret_vaddr;
+ return __xchg(>ARM_lr, trampoline_vaddr);
}
If it's not a callback, the entire function can be killed.
And this is a good example of the function usage.
OTOH, these places might have a side effect (if it's in deep CPU
handlers), means we need to do this carefully.
...
static inline void *qed_chain_produce(struct qed_chain *p_chain)
{
- void *p_ret = NULL, *p_prod_idx, *p_prod_page_idx;
+ void *p_prod_idx, *p_prod_page_idx;
if (is_chain_u16(p_chain)) {
if ((p_chain->u.chain16.prod_idx &
@@ -390,11 +391,8 @@ static inline void *qed_chain_produce(struct qed_chain
*p_chain)
p_chain->u.chain32.prod_idx++;
}
- p_ret = p_chain->p_prod_elem;
- p_chain->p_prod_elem = (void *)(((u8 *)p_chain->p_prod_elem) +
- p_chain->elem_size);
-
- return p_ret;
+ return __xchg(_chain->p_prod_elem,
+ (void *)(((u8 *)p_chain->p_prod_elem) +
p_chain->elem_size));
Wondering if you still need a (void *) casting after the change. Ditto for the
rest of similar cases.
IMHO it is not needed also before the change and IIRC gcc has an
extension which allows to drop (u8 *) cast as well [1].
[1]: https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
}
...
Btw, is it done by coccinelle? If no, why not providing the script?
Yes I have used cocci. My cocci skills are far from perfect, so I did
not want to share my dirty code, but this is nothing secret:
@r1@
expression x, v;
local idexpression p;
@@
- p = x;
- x = v;
- return p;
+ return __xchg(, v);
@depends on r1@
expression e;
@@
__xchg(
- &*e,
+ e,
...)
@depends on r1@
expression t;
@@
- if (t) {
+ if (t)
return __xchg(...);
- }
@depends on r1@
type t;
identifier p;
expression e;
@@
(
- t p;
|
- t p = e;
)
... when != p
Regards
Andrzej
Re: [Intel-gfx] [RFC PATCH 00/20] Initial Xe driver submission
+Frank, who's also working on the pvr uAPI. Hi, On Thu, 22 Dec 2022 14:21:07 -0800 Matthew Brost wrote: > The code has been organized such that we have all patches that touch areas > outside of drm/xe first for review, and then the actual new driver in a > separate > commit. The code which is outside of drm/xe is included in this RFC while > drm/xe is not due to the size of the commit. The drm/xe is code is available > in > a public repo listed below. > > Xe driver commit: > https://cgit.freedesktop.org/drm/drm-xe/commit/?h=drm-xe-next=9cb016ebbb6a275f57b1cb512b95d5a842391ad7 > > Xe kernel repo: > https://cgit.freedesktop.org/drm/drm-xe/ Sorry to hijack this thread, again, but I'm currently working on the pancsf uAPI, and I was wondering how DRM maintainers/developers felt about the new direction taken by the Xe driver on some aspects of their uAPI (to decide if I should copy these patterns or go the old way): - plan for ioctl extensions through '__u64 extensions;' fields (the vulkan way, basically) - turning the GETPARAM in DEV_QUERY which can return more than a 64-bit integer at a time - having ioctls taking sub-operations instead of one ioctl per operation (I'm referring to VM_BIND here, which handles map, unmap, restart, ... through a single entry point) Regards, Boris
