Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support
> From: Nicolin Chen > Sent: Wednesday, March 1, 2023 10:29 AM > > On Tue, Feb 28, 2023 at 04:58:06PM +, Xu, Terrence wrote: > > > Verified this series by "Intel GVT-g GPU device mediated passthrough" > and "Intel GVT-d GPU device direct passthrough" technologies. > > Both passed VFIO legacy mode / compat mode / cdev mode, including > negative tests. > > > > Tested-by: Terrence Xu > > Sanity-tested this series on ARM64 with my wip branch: > https://github.com/nicolinc/iommufd/commits/wip/iommufd-v6.2-nesting > (Covering new iommufd and vfio-compat) > > Tested-by: Nicolin Chen Thanks. Regards, Yi Liu
Re: [Intel-gfx] [PATCH v7 00/15] dma-fence: Deadline awareness
On 2/28/23 22:44, Rob Clark wrote: > You can find my branch here: > > https://gitlab.freedesktop.org/robclark/msm/-/commits/dma-fence/deadline > Pulled, thanks! -- An old man doll... just what I always wanted! - Clara
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: Fix csync detailed mode parsing (rev2)
== Series Details ==
Series: drm/edid: Fix csync detailed mode parsing (rev2)
URL : https://patchwork.freedesktop.org/series/114424/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12794_full -> Patchwork_114424v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114424v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114424v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114424v2_full:
### IGT changes ###
Possible regressions
* igt@kms_plane@plane-panning-top-left@pipe-a-planes:
- shard-apl: [PASS][1] -> [DMESG-WARN][2] +7 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/shard-apl2/igt@kms_plane@plane-panning-top-l...@pipe-a-planes.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-apl6/igt@kms_plane@plane-panning-top-l...@pipe-a-planes.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_isolation@preservation-s3@vecs0:
- {shard-tglu}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/shard-tglu-4/igt@gem_ctx_isolation@preservation...@vecs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-8/igt@gem_ctx_isolation@preservation...@vecs0.html
Known issues
Here are the changes found in Patchwork_114424v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@crc32:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#6230])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@api_intel...@crc32.html
* igt@device_reset@unbind-cold-reset-rebind:
- shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#7701])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@device_re...@unbind-cold-reset-rebind.html
* igt@drm_mm@all-tests:
- shard-tglu-9: NOTRUN -> [SKIP][7] ([i915#6433])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-9/igt@drm...@all-tests.html
* igt@gem_close_race@multigpu-basic-threads:
- shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#7697])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_close_r...@multigpu-basic-threads.html
* igt@gem_create@create-ext-cpu-access-big:
- shard-tglu-10: NOTRUN -> [SKIP][9] ([i915#6335])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_cre...@create-ext-cpu-access-big.html
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglu-10: NOTRUN -> [FAIL][10] ([i915#6268])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@processes:
- shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1099]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-snb1/igt@gem_ctx_persiste...@processes.html
* igt@gem_ctx_sseu@engines:
- shard-tglu-10: NOTRUN -> [SKIP][12] ([i915#280])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_ctx_s...@engines.html
* igt@gem_eio@hibernate:
- shard-tglu-10: NOTRUN -> [ABORT][13] ([i915#7975])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_...@hibernate.html
* igt@gem_exec_capture@capture-invisible@smem0:
- shard-tglu-10: NOTRUN -> [SKIP][14] ([i915#6334])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_exec_capture@capture-invisi...@smem0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu-10: NOTRUN -> [FAIL][15] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@basic:
- shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#4613])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-9/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@heavy-multi:
- shard-tglu-10: NOTRUN -> [SKIP][17] ([i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/shard-tglu-10/igt@gem_lmem_swapp...@heavy-multi.html
* igt@gem_lmem_swapping@verify:
- shard-glk: NOTRUN ->
Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support
On Tue, Feb 28, 2023 at 04:58:06PM +, Xu, Terrence wrote: > Verified this series by "Intel GVT-g GPU device mediated passthrough" and > "Intel GVT-d GPU device direct passthrough" technologies. > Both passed VFIO legacy mode / compat mode / cdev mode, including negative > tests. > > Tested-by: Terrence Xu Sanity-tested this series on ARM64 with my wip branch: https://github.com/nicolinc/iommufd/commits/wip/iommufd-v6.2-nesting (Covering new iommufd and vfio-compat) Tested-by: Nicolin Chen
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Create per-tile debugfs files
== Series Details == Series: drm/i915/gt: Create per-tile debugfs files URL : https://patchwork.freedesktop.org/series/114495/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12794 -> Patchwork_114495v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114495v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114495v1, 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_114495v1/index.html Participating hosts (39 -> 38) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114495v1: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-kbl-soraka/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/fi-kbl-soraka/igt@core_hotunp...@unbind-rebind.html Warnings * igt@i915_pm_rps@basic-api: - bat-dg2-11: [SKIP][3] ([i915#6621]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-dg2-11/igt@i915_pm_...@basic-api.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-dg2-11/igt@i915_pm_...@basic-api.html Known issues Here are the changes found in Patchwork_114495v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-adlm-1: [PASS][5] -> [DMESG-WARN][6] ([i915#2867]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html - bat-rpls-1: [PASS][7] -> [ABORT][8] ([i915#6687] / [i915#7978]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_heartbeat: - fi-rkl-11600: [PASS][9] -> [DMESG-FAIL][10] ([i915#5334]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-rkl-11600/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/fi-rkl-11600/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][11] -> [TIMEOUT][12] ([i915#6794]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-1/igt@i915_selftest@l...@mman.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][13] -> [ABORT][14] ([i915#4983]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-2/igt@i915_selftest@l...@reset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][15] ([i915#7828]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - bat-dg2-11: [INCOMPLETE][16] -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rps@basic-api: - bat-dg1-7: [SKIP][18] ([i915#6621]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-dg1-7/igt@i915_pm_...@basic-api.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-dg1-7/igt@i915_pm_...@basic-api.html - bat-rpls-2: [SKIP][20] ([i915#6621]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-2/igt@i915_pm_...@basic-api.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-rpls-2/igt@i915_pm_...@basic-api.html - bat-adlp-9: [SKIP][22] ([i915#6621]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-adlp-9/igt@i915_pm_...@basic-api.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114495v1/bat-adlp-9/igt@i915_pm_...@basic-api.html - bat-dg1-6:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Create per-tile debugfs files
== Series Details == Series: drm/i915/gt: Create per-tile debugfs files URL : https://patchwork.freedesktop.org/series/114495/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev4)
== Series Details ==
Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev4)
URL : https://patchwork.freedesktop.org/series/114199/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12794_full -> Patchwork_114199v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114199v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114199v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114199v4_full:
### IGT changes ###
Possible regressions
* igt@kms_flip@flip-vs-suspend-interruptible@a-dp1:
- shard-apl: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/shard-apl6/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-apl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@sysfs-reader:
- {shard-tglu}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/shard-tglu-3/igt@i915_susp...@sysfs-reader.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-3/igt@i915_susp...@sysfs-reader.html
Known issues
Here are the changes found in Patchwork_114199v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@device_reset@cold-reset-bound:
- shard-tglu-9: NOTRUN -> [SKIP][5] ([i915#7701])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@device_re...@cold-reset-bound.html
* igt@feature_discovery@chamelium:
- shard-tglu-10: NOTRUN -> [SKIP][6] ([fdo#111827]) +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-10/igt@feature_discov...@chamelium.html
* igt@gem_ccs@ctrl-surf-copy:
- shard-tglu-9: NOTRUN -> [SKIP][7] ([i915#3555] / [i915#5325])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_...@ctrl-surf-copy.html
* igt@gem_ccs@suspend-resume:
- shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#5325])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-10/igt@gem_...@suspend-resume.html
* igt@gem_close_race@multigpu-basic-process:
- shard-tglu-9: NOTRUN -> [SKIP][9] ([i915#7697]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_close_r...@multigpu-basic-process.html
* igt@gem_ctx_persistence@processes:
- shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +4
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-snb4/igt@gem_ctx_persiste...@processes.html
* igt@gem_ctx_sseu@invalid-sseu:
- shard-tglu-9: NOTRUN -> [SKIP][11] ([i915#280]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_ctx_s...@invalid-sseu.html
* igt@gem_exec_balancer@parallel-ordering:
- shard-tglu-9: NOTRUN -> [FAIL][12] ([i915#6117])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_exec_balan...@parallel-ordering.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglu-9: NOTRUN -> [SKIP][13] ([fdo#109283])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_huc_copy@huc-copy:
- shard-tglu-9: NOTRUN -> [SKIP][14] ([i915#2190])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-tglu-9: NOTRUN -> [SKIP][15] ([i915#4613])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-9/igt@gem_lmem_swapp...@heavy-verify-random.html
* igt@gem_lmem_swapping@smem-oom:
- shard-tglu-10: NOTRUN -> [SKIP][16] ([i915#4613]) +2 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-tglu-10/igt@gem_lmem_swapp...@smem-oom.html
* igt@gem_lmem_swapping@verify:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/shard-glk8/igt@gem_lmem_swapp...@verify.html
* igt@gem_media_vme:
[Intel-gfx] [PATCH] drm/i915/gt: Create per-tile debugfs files
To support multi-GT configurations, we need to generate
independent debug files for each GT.
To achieve this create a separate directory for each GT under the
debugfs directory. For instance, in a system with four tiles, the
debugfs structure would look like this:
/sys/kernel/debug/dri
└── 0
├── gt0
│ ├── drpc
│ ├── engines
│ ├── forcewake
│ ├── frequency
│ └── rps_boost
├── gt1
│ ├── drpc
│ ├── engines
│ ├── forcewake
│ ├── frequency
│ └── rps_boost
├── gt2
│ ├── drpc
│ ├── engines
│ ├── forcewake
│ ├── frequency
│ └── rps_boost
└─- gt3
: ├── drpc
: ├── engines
: ├── forcewake
├── frequency
└── rps_boost
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 4 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c| 5 -
drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c | 2 ++
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index 5fc2df01aa0d..4dc23b8d3aa2 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -83,11 +83,13 @@ static void gt_debugfs_register(struct intel_gt *gt, struct
dentry *root)
void intel_gt_debugfs_register(struct intel_gt *gt)
{
struct dentry *root;
+ char gtname[4];
if (!gt->i915->drm.primary->debugfs_root)
return;
- root = debugfs_create_dir("gt", gt->i915->drm.primary->debugfs_root);
+ snprintf(gtname, sizeof(gtname), "gt%u", gt->info.id);
+ root = debugfs_create_dir(gtname, gt->i915->drm.primary->debugfs_root);
if (IS_ERR(root))
return;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index bb4dfe707a7d..e46aac1a41e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -42,6 +42,8 @@ struct intel_guc {
/** @capture: the error-state-capture module's data and objects */
struct intel_guc_state_capture *capture;
+ struct dentry *dbgfs_node;
+
/** @sched_engine: Global engine used to submit requests to GuC */
struct i915_sched_engine *sched_engine;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
index 195db8c9d420..55bc8b55fbc0 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
@@ -542,8 +542,11 @@ static int guc_log_relay_create(struct intel_guc_log *log)
*/
n_subbufs = 8;
+ if (!guc->dbgfs_node)
+ return -ENOENT;
+
guc_log_relay_chan = relay_open("guc_log",
- i915->drm.primary->debugfs_root,
+ guc->dbgfs_node,
subbuf_size, n_subbufs,
_callbacks, i915);
if (!guc_log_relay_chan) {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
index 284d6fbc2d08..2f93cc4e408a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_debugfs.c
@@ -54,6 +54,8 @@ void intel_uc_debugfs_register(struct intel_uc *uc, struct
dentry *gt_root)
if (IS_ERR(root))
return;
+ uc->guc.dbgfs_node = root;
+
intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), uc);
intel_guc_debugfs_register(>guc, root);
--
2.34.1
Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg file for PICA registers
On Fri, Feb 24, 2023 at 12:13:37PM +0200, Mika Kahola wrote: Create a separate file to store registers for PICA chips C10 and C20. v2: Rename file (Jani) Signed-off-by: Radhakrishna Sripada Signed-off-by: Mika Kahola --- .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 136 ++ 1 file changed, 136 insertions(+) create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h new file mode 100644 index ..d6b3709d3762 --- /dev/null +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h @@ -0,0 +1,136 @@ +/* SPDX-License-Identifier: MIT + * + * Copyright © 2022 Intel Corporation + */ + +#ifndef __INTEL_CX0_PHY_REGS_H__ +#define __INTEL_CX0_PHY_REGS_H__ + +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A 0x64040 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B 0x64140 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1 0x16F240 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2 0x16F440 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3 0x16F640 +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4 0x16F840 +#define _XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)(_PICK(port, \ + [PORT_A] = _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ + [PORT_B] = _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ + [PORT_TC1] = _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ + [PORT_TC2] = _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2, \ + [PORT_TC3] = _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3, \ + [PORT_TC4] = _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4) + ((lane) * 4)) + stray newline +#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)) one of the reasons _PICK_EVEN_2RANGES() was added. We usually have 2 ranges for the ports due to the combo vs tc distinction. #define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) _MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2)) +#define XELPDP_PORT_M2P_TRANSACTION_PENDING REG_BIT(31) ^ wrong amount of spaces. See the example on top of i915_reg.h here and everywhere in this file +#define XELPDP_PORT_M2P_COMMAND_TYPE_MASK REG_GENMASK(30, 27) +#define XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1) +#define XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2) +#define XELPDP_PORT_M2P_COMMAND_READ REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3) +#define XELPDP_PORT_M2P_DATA_MASK REG_GENMASK(23, 16) +#define XELPDP_PORT_M2P_DATA(val) REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val) +#define XELPDP_PORT_M2P_TRANSACTION_RESET REG_BIT(15) +#define XELPDP_PORT_M2P_ADDRESS_MASK REG_GENMASK(11, 0) +#define XELPDP_PORT_M2P_ADDRESS(val) REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val) + +#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane) _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) + 8) +#define XELPDP_PORT_P2M_RESPONSE_READYREG_BIT(31) +#define XELPDP_PORT_P2M_COMMAND_TYPE_MASK REG_GENMASK(30, 27) +#define XELPDP_PORT_P2M_COMMAND_READ_ACK 0x4 +#define XELPDP_PORT_P2M_COMMAND_WRITE_ACK 0x5 +#define XELPDP_PORT_P2M_DATA_MASK REG_GENMASK(23, 16) +#define XELPDP_PORT_P2M_DATA(val) REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val) +#define XELPDP_PORT_P2M_ERROR_SET REG_BIT(15) +#define XELPDP_MSGBUS_TIMEOUT_SLOW1 +#define XELPDP_MSGBUS_TIMEOUT_FAST_US 2 + +#define XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US 3200 +#define XELPDP_PCLK_PLL_DISABLE_TIMEOUT_US 20 +#define XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US 100 +#define XELPDP_PORT_RESET_START_TIMEOUT_US 5 +#define XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US100 +#define XELPDP_PORT_RESET_END_TIMEOUT 15 +#define XELPDP_REFCLK_ENABLE_TIMEOUT_US1 + +#define
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: Fix csync detailed mode parsing (rev2)
== Series Details == Series: drm/edid: Fix csync detailed mode parsing (rev2) URL : https://patchwork.freedesktop.org/series/114424/ State : success == Summary == CI Bug Log - changes from CI_DRM_12794 -> Patchwork_114424v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/index.html Participating hosts (39 -> 38) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114424v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][1] -> [ABORT][2] ([i915#7911]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334] / [i915#7872]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html - fi-apl-guc: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - fi-kbl-soraka: [PASS][7] -> [INCOMPLETE][8] ([i915#7913]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#7828]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][10] ([i915#3546]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[FAIL][11] ([i915#7229]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3@smem: - bat-dg2-11: [INCOMPLETE][13] -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][15] ([i915#8073]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-atsm-1: [DMESG-FAIL][17] ([i915#7699]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-atsm-1/igt@i915_selftest@l...@migrate.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/bat-atsm-1/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][19] ([i915#6367] / [i915#7996]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-1/igt@i915_selftest@l...@slpc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_selftest@live@workarounds: - bat-rpls-2: [DMESG-WARN][21] ([i915#7852]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v2/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7852]:
[Intel-gfx] [PATCH v8 16/16] drm/i915: Add deadline based boost support
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence
*fence)
return i915_request_enable_breadcrumb(to_request(fence));
}
+static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+ struct i915_request *rq = to_request(fence);
+
+ if (i915_request_completed(rq))
+ return;
+
+ if (i915_request_started(rq))
+ return;
+
+ /*
+* TODO something more clever for deadlines that are in the
+* future. I think probably track the nearest deadline in
+* rq->timeline and set timer to trigger boost accordingly?
+*/
+
+ intel_rps_boost(rq);
+}
+
static signed long i915_fence_wait(struct dma_fence *fence,
bool interruptible,
signed long timeout)
@@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
.signaled = i915_fence_signaled,
.wait = i915_fence_wait,
.release = i915_fence_release,
+ .set_deadline = i915_fence_set_deadline,
};
static void irq_execute_cb(struct irq_work *wrk)
--
2.39.1
[Intel-gfx] [PATCH v8 00/16] dma-fence: Deadline awareness
From: Rob Clark This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To continue to be able to use the atomic helpers 2) To support cases where display and gpu are different drivers This iteration adds a dma-fence ioctl to set a deadline (both to support igt-tests, and compositors which delay decisions about which client buffer to display), and a sw_sync ioctl to read back the deadline. IGT tests utilizing these can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. v8: Add patch to surface sync_file UAPI, and more docs updates. Rob Clark (16): dma-buf/dma-fence: Add deadline awareness dma-buf/fence-array: Add fence deadline support dma-buf/fence-chain: Add fence deadline support dma-buf/dma-resv: Add a way to set fence deadline dma-buf/sync_file: Surface sync-file uABI dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sync_file: Support (E)POLLPRI dma-buf/sw_sync: Add fence deadline support drm/scheduler: Add fence deadline support drm/syncobj: Add deadline support for syncobj waits drm/vblank: Add helper to get next vblank time drm/atomic-helper: Set fence deadline for vblank drm/msm: Add deadline based boost support drm/msm: Add wait-boost support drm/msm/atomic: Switch to vblank_start helper drm/i915: Add deadline based boost support Documentation/driver-api/dma-buf.rst| 16 - drivers/dma-buf/dma-fence-array.c | 11 drivers/dma-buf/dma-fence-chain.c | 12 drivers/dma-buf/dma-fence.c | 60 ++ drivers/dma-buf/dma-resv.c | 22 +++ drivers/dma-buf/sw_sync.c | 81 + drivers/dma-buf/sync_debug.h| 2 + drivers/dma-buf/sync_file.c | 27 + drivers/gpu/drm/drm_atomic_helper.c | 36 +++ drivers/gpu/drm/drm_syncobj.c | 64 +++ drivers/gpu/drm/drm_vblank.c| 53 +--- drivers/gpu/drm/i915/i915_request.c | 20 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 - drivers/gpu/drm/msm/msm_atomic.c| 8 ++- drivers/gpu/drm/msm/msm_drv.c | 12 ++-- drivers/gpu/drm/msm/msm_fence.c | 74 ++ drivers/gpu/drm/msm/msm_fence.h | 20 ++ drivers/gpu/drm/msm/msm_gem.c | 5 ++ drivers/gpu/drm/msm/msm_kms.h | 8 --- drivers/gpu/drm/scheduler/sched_fence.c | 46 ++ drivers/gpu/drm/scheduler/sched_main.c | 2 +- include/drm/drm_vblank.h| 1 + include/drm/gpu_scheduler.h | 17 ++ include/linux/dma-fence.h | 22 +++ include/linux/dma-resv.h| 2 + include/uapi/drm/drm.h | 17 ++ include/uapi/drm/msm_drm.h | 14 - include/uapi/linux/sync_file.h | 57 ++--- 28 files changed, 646 insertions(+), 78 deletions(-) -- 2.39.1
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/edid: Fix csync detailed mode parsing (rev2)
== Series Details == Series: drm/edid: Fix csync detailed mode parsing (rev2) URL : https://patchwork.freedesktop.org/series/114424/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v3 7/9] drm/i915/perf: Handle non-power-of-2 reports
On Mon, 27 Feb 2023 18:23:27 -0800, Umesh Nerlige Ramappa wrote: > > Some of the newer OA formats are not powers of 2. For those formats, > adjust the hw_tail accordingly when checking for new reports. > > v2: (Ashutosh) > - Switch to OA_TAKEN for diff calculation > - Use OA_BUFFER_SIZE instead of the vma size > - Update comments Reviewed-by: Ashutosh Dixit
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev4)
== Series Details == Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev4) URL : https://patchwork.freedesktop.org/series/114199/ State : success == Summary == CI Bug Log - changes from CI_DRM_12794 -> Patchwork_114199v4 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/index.html Participating hosts (39 -> 37) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_114199v4 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@requests: - bat-rpls-2: [PASS][1] -> [ABORT][2] ([i915#4983] / [i915#7694]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-2/igt@i915_selftest@l...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/bat-rpls-2/igt@i915_selftest@l...@requests.html - bat-rpls-1: [PASS][3] -> [ABORT][4] ([i915#4983] / [i915#7694] / [i915#7911] / [i915#7981]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-1/igt@i915_selftest@l...@requests.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/bat-dg2-11/igt@kms_chamelium_...@common-hpd-after-suspend.html Possible fixes * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[FAIL][6] ([i915#7229]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3@smem: - bat-dg2-11: [INCOMPLETE][8] -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/bat-dg2-11/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [DMESG-WARN][10] ([i915#8073]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-atsm-1: [DMESG-FAIL][12] ([i915#7699]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-atsm-1/igt@i915_selftest@l...@migrate.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/bat-atsm-1/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@workarounds: - bat-rpls-2: [DMESG-WARN][14] ([i915#7852]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12794/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/bat-rpls-2/igt@i915_selftest@l...@workarounds.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229 [i915#7694]: https://gitlab.freedesktop.org/drm/intel/issues/7694 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7852]: https://gitlab.freedesktop.org/drm/intel/issues/7852 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981 [i915#8073]: https://gitlab.freedesktop.org/drm/intel/issues/8073 Build changes - * Linux: CI_DRM_12794 -> Patchwork_114199v4 CI-20190529: 20190529 CI_DRM_12794: 09f45ee84b4e66b882286806fb4b2b03907db5dc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7176: ffe88a907c0fafe6a736f5f17cee8ba8eddd6fa7 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114199v4: 09f45ee84b4e66b882286806fb4b2b03907db5dc @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits bb1a3712cbfe drm/i915/sseu: fix max_subslices array-index-out-of-bounds access == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v4/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev4)
== Series Details == Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev4) URL : https://patchwork.freedesktop.org/series/114199/ State : warning == Summary == Error: dim checkpatch failed ae91b70fbe2e drm/i915/sseu: fix max_subslices array-index-out-of-bounds access -:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #12: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27 total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] [PATCH v2] drm/edid: Fix csync detailed mode parsing
From: Ville Syrjälä
Remove the bogus csync check and replace it with something that:
- triggers for all forms of csync, not just the basic analog variant
- actually populates the mode csync flags so that drivers can
decide what to do with the mode
Originally the code tried to outright reject csync, but that
apparently broke some bogus LCD monitor that claimed to have
a detailed mode that uses analog csync, despite also claiming
the monitor only support separate sync:
https://bugzilla.redhat.com/show_bug.cgi?id=540024
Potentially that monitor should just be quirked or something.
Anyways, what we are dealing with now is some kind of funny i915
JSL machine with eDP where the panel claims to support a sensible
60Hz separate sync mode, and a 50Hz mode with bipolar analog
csync. The 50Hz mode does not work so we want to not use it.
Easiest way is to just correctly flag it as csync and the driver
will reject it.
TODO: or should we just reject any form of csync (or at least
the analog variants) for digital display interfaces?
v2: Grab digital csync polarity from hsync polarity bit (Jani)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146
Reviewed-by: Jani Nikula #v1
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 29 +
include/drm/drm_edid.h | 12 +---
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ebab862b8b1a..c18ec866678d 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3424,10 +3424,6 @@ static struct drm_display_mode *drm_mode_detailed(struct
drm_connector *connecto
connector->base.id, connector->name);
return NULL;
}
- if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) {
- drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Composite sync not
supported\n",
- connector->base.id, connector->name);
- }
/* it is incorrect if hsync/vsync width is zero */
if (!hsync_pulse_width || !vsync_pulse_width) {
@@ -3474,10 +3470,27 @@ static struct drm_display_mode
*drm_mode_detailed(struct drm_connector *connecto
if (info->quirks & EDID_QUIRK_DETAILED_SYNC_PP) {
mode->flags |= DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC;
} else {
- mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
- DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
- mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
- DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+ switch (pt->misc & DRM_EDID_PT_SYNC_MASK) {
+ case DRM_EDID_PT_ANALOG_CSYNC:
+ case DRM_EDID_PT_BIPOLAR_ANALOG_CSYNC:
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Analog composite
sync!\n",
+ connector->base.id, connector->name);
+ mode->flags |= DRM_MODE_FLAG_CSYNC |
DRM_MODE_FLAG_NCSYNC;
+ break;
+ case DRM_EDID_PT_DIGITAL_CSYNC:
+ drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Digital composite
sync!\n",
+ connector->base.id, connector->name);
+ mode->flags |= DRM_MODE_FLAG_CSYNC;
+ mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
+ DRM_MODE_FLAG_PCSYNC : DRM_MODE_FLAG_NCSYNC;
+ break;
+ case DRM_EDID_PT_DIGITAL_SEPARATE_SYNC:
+ mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
+ DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
+ mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
+ DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
+ break;
+ }
}
set_size:
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 70ae6c290bdc..571885d32907 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -61,9 +61,15 @@ struct std_timing {
u8 vfreq_aspect;
} __attribute__((packed));
-#define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1)
-#define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2)
-#define DRM_EDID_PT_SEPARATE_SYNC (3 << 3)
+#define DRM_EDID_PT_SYNC_MASK (3 << 3)
+# define DRM_EDID_PT_ANALOG_CSYNC (0 << 3)
+# define DRM_EDID_PT_BIPOLAR_ANALOG_CSYNC (1 << 3)
+# define DRM_EDID_PT_DIGITAL_CSYNC (2 << 3)
+# define DRM_EDID_PT_CSYNC_ON_RGB (1 << 1) /* analog csync only */
+# define DRM_EDID_PT_CSYNC_SERRATE(1 << 2)
+# define DRM_EDID_PT_DIGITAL_SEPARATE_SYNC (3 << 3)
+# define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1) /* also digital csync */
+# define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2)
#define DRM_EDID_PT_STEREO (1 << 5)
#define DRM_EDID_PT_INTERLACED (1 <<
Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
On Fri, 12 Aug 2022 11:06:58 -0700, Guenter Roeck wrote: > Hi Guenter/linux-hwmon, > On 8/12/22 10:37, Badal Nilawar wrote: > > From: Dale B Stimson > > > > Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting. > > /snip/ > > Acked-by: Guenter Roeck > > > --- > > .../ABI/testing/sysfs-driver-intel-i915-hwmon | 20 ++ > > drivers/gpu/drm/i915/i915_hwmon.c | 176 +- > > drivers/gpu/drm/i915/i915_reg.h | 16 ++ > > drivers/gpu/drm/i915/intel_mchbar_regs.h | 7 + > > 4 files changed, 217 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > index 24c4b7477d51..9a2d10edfce8 100644 > > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > @@ -5,3 +5,23 @@ Contact: dri-de...@lists.freedesktop.org > > Description: RO. Current Voltage in millivolt. > > Only supported for particular Intel i915 graphics > > platforms. > > + > > +What: /sys/devices/.../hwmon/hwmon/power1_max > > +Date: June 2022 > > +KernelVersion: 5.19 > > +Contact: dri-de...@lists.freedesktop.org > > +Description: RW. Card reactive sustained (PL1/Tau) power limit in > > microwatts. > > + > > + The power controller will throttle the operating frequency > > + if the power averaged over a window (typically seconds) > > + exceeds this limit. We exposed this as 'power1_max' previously. However this is a "power limit". https://github.com/torvalds/linux/blob/master/Documentation/hwmon/sysfs-interface.rst says power1_max is "Maximum power". On the other hand, power1_cap is "If power use rises above this limit, the system should take action to reduce power use". So it would seem we should have chosen power1_cap for this power limit instead of power1_max? So do you think we should change this to power1_cap instead? Though even power1_max has an associated alarm so it also seems to be a sort of limit. Is there any guidance as to how these different power limits should be used? Generally speaking is: power1_max <= power1_cap <= power1_crit, or is it arbitrary or something else? Also, only power1_cap seems to have power1_cap_min and power1_cap_max (in case we wanted to use min/max values for the limits), not the others. Separately, we have already used up power1_crit (which is the other limit in official hwmon power limits) so we can't use that. Thanks. -- Ashutosh
Re: [Intel-gfx] [PATCH] drm/edid: Fix csync detailed mode parsing
On Tue, Feb 28, 2023 at 10:10:26PM +0200, Jani Nikula wrote:
> On Mon, 27 Feb 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Remove the bogus csync check and replace it with something that:
> > - triggers for all forms of csync, not just the basic analog variant
> > - actually populates the mode csync flags so that drivers can
> > decide what to do with the mode
> >
> > Originally the code tried to outright reject csync, but that
> > apparently broke some bogus LCD monitor that claimed to have
> > a detailed mode that uses analog csync, despite also claiming
> > the monitor only support separate sync:
> > https://bugzilla.redhat.com/show_bug.cgi?id=540024
> > Potentially that monitor should just be quirked or something.
> >
> > Anyways, what we are dealing with now is some kind of funny i915
> > JSL machine with eDP where the panel claims to support a sensible
> > 60Hz separate sync mode, and a 50Hz mode with bipolar analog
> > csync. The 50Hz mode does not work so we want to not use it.
> > Easiest way is to just correctly flag it as csync and the driver
> > will reject it.
> >
> > TODO: or should we just reject any form of csync (or at least
> > the analog variants) for digital display interfaces?
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_edid.c | 23 +++
> > include/drm/drm_edid.h | 12 +---
> > 2 files changed, 24 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index ebab862b8b1a..fa20b1107ce3 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3424,10 +3424,6 @@ static struct drm_display_mode
> > *drm_mode_detailed(struct drm_connector *connecto
> > connector->base.id, connector->name);
> > return NULL;
> > }
> > - if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) {
> > - drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Composite sync not
> > supported\n",
> > - connector->base.id, connector->name);
> > - }
> >
> > /* it is incorrect if hsync/vsync width is zero */
> > if (!hsync_pulse_width || !vsync_pulse_width) {
> > @@ -3474,10 +3470,21 @@ static struct drm_display_mode
> > *drm_mode_detailed(struct drm_connector *connecto
> > if (info->quirks & EDID_QUIRK_DETAILED_SYNC_PP) {
> > mode->flags |= DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC;
> > } else {
> > - mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
> > - DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
> > - mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
> > - DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
> > + switch (pt->misc & DRM_EDID_PT_SYNC_MASK) {
> > + case DRM_EDID_PT_ANALOG_CSYNC:
> > + case DRM_EDID_PT_BIPOLAR_ANALOG_CSYNC:
> > + case DRM_EDID_PT_DIGITAL_CSYNC:
> > + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Composite sync!\n",
> > + connector->base.id, connector->name);
> > + mode->flags |= DRM_MODE_FLAG_CSYNC |
> > DRM_MODE_FLAG_NCSYNC;
>
> Not sure it makes a huge difference, and I expect this case to be rare,
> but what's the _N_ CSYNC based on here?
I think csync is pretty much always negative. Well, tri-state sync is
both negative and positive, but it goes negative first.
>
> I also observe the spec appears to indicate "Horizontal Sync is Negative
> (outside of V-sync)" and "Horizontal Sync is Positive (outside of
> V-sync)" bit is valid also for Digital Composite Sync.
>
> See how the bits for vertical sync have "1 1 0" or "1 1 1" but for
> horizontal sync it's "1 _ _ 0" and "1 _ _ 1". Does that indicate the
> polarity for digital composite sync?! The spec is not super clear.
Hmm. I tought EDID 1.4 got rid of that, but I guess it still
implies the hsync polarity applies to csync too.
Confusuingly it only talks about hsync and nothing about vsync.
Maybe it means both really. Not sure how anything would work
anyway if hsync and vsync had opposite polarity here. Wouldn't
that just mean everything looks like vsync?
So I guess grabbing the csync polarity from that bit is
probably correct.
>
> > + break;
> > + case DRM_EDID_PT_DIGITAL_SEPARATE_SYNC:
> > + mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
> > + DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
> > + mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
> > + DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
>
> I think this is the good stuff, we shouldn't be looking at these flags
> and setting PHSYNC/NHSYNC/PVSYNC/NVSYNC unless we have digital separate
> sync.
>
> Overall I think
>
> Reviewed-by: Jani Nikula
>
> Although it's not all
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access
On Fri, Feb 24, 2023 at 07:27:09AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/2] drm/i915: Whitelist COMMON_SLICE_CHICKEN3 > for UMD access > URL : https://patchwork.freedesktop.org/series/114317/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_12774_full -> Patchwork_114317v1_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > Applied to drm-intel-gt-next. Thanks Gustavo for the reviews. Matt > > > Participating hosts (9 -> 10) > -- > > Additional (1): shard-tglu-9 > > Known issues > > > Here are the changes found in Patchwork_114317v1_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@api_intel_bb@crc32: > - shard-tglu-10: NOTRUN -> [SKIP][1] ([i915#6230]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@api_intel...@crc32.html > > * igt@debugfs_test@basic-hwmon: > - shard-tglu-10: NOTRUN -> [SKIP][2] ([i915#7456]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@debugfs_t...@basic-hwmon.html > > * igt@fbdev@write: > - shard-tglu-9: NOTRUN -> [SKIP][3] ([i915#2582]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-9/igt@fb...@write.html > > * igt@gem_ccs@block-copy-compressed: > - shard-tglu-10: NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325]) +1 > similar issue >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_...@block-copy-compressed.html > > * igt@gem_exec_capture@capture-recoverable: > - shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#6344]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_exec_capt...@capture-recoverable.html > > * igt@gem_exec_fair@basic-none-share@rcs0: > - shard-tglu-10: NOTRUN -> [FAIL][6] ([i915#2842]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_exec_fair@basic-none-sh...@rcs0.html > > * igt@gem_exec_fair@basic-none-solo@rcs0: > - shard-tglu-9: NOTRUN -> [FAIL][7] ([i915#2842]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-9/igt@gem_exec_fair@basic-none-s...@rcs0.html > > * igt@gem_exec_fair@basic-pace-share@rcs0: > - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12774/shard-glk7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html > > * igt@gem_exec_params@secure-non-root: > - shard-tglu-10: NOTRUN -> [SKIP][10] ([fdo#112283]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_exec_par...@secure-non-root.html > > * igt@gem_lmem_swapping@heavy-random: > - shard-tglu-9: NOTRUN -> [SKIP][11] ([i915#4613]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-9/igt@gem_lmem_swapp...@heavy-random.html > > * igt@gem_lmem_swapping@parallel-random-verify-ccs: > - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-apl2/igt@gem_lmem_swapp...@parallel-random-verify-ccs.html > > * igt@gem_lmem_swapping@verify-ccs: > - shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#4613]) +2 similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_lmem_swapp...@verify-ccs.html > > * igt@gem_pread@exhaustion: > - shard-tglu-10: NOTRUN -> [WARN][14] ([i915#2658]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_pr...@exhaustion.html > > * igt@gem_pxp@create-regular-context-1: > - shard-tglu-9: NOTRUN -> [SKIP][15] ([i915#4270]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-9/igt@gem_...@create-regular-context-1.html > > * igt@gem_pxp@reject-modify-context-protection-off-1: > - shard-tglu-10: NOTRUN -> [SKIP][16] ([i915#4270]) +3 similar issues >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-tglu-10/igt@gem_...@reject-modify-context-protection-off-1.html > > * igt@gem_render_copy@x-tiled-to-vebox-yf-tiled: > - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271]) +53 similar > issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114317v1/shard-apl2/igt@gem_render_c...@x-tiled-to-vebox-yf-tiled.html > > * igt@gem_userptr_blits@unsync-unmap-after-close: > - shard-tglu-9: NOTRUN -> [SKIP][18] ([i915#3297]) >[18]: >
Re: [Intel-gfx] [PATCH] drm/edid: Fix csync detailed mode parsing
On Mon, 27 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the bogus csync check and replace it with something that:
> - triggers for all forms of csync, not just the basic analog variant
> - actually populates the mode csync flags so that drivers can
> decide what to do with the mode
>
> Originally the code tried to outright reject csync, but that
> apparently broke some bogus LCD monitor that claimed to have
> a detailed mode that uses analog csync, despite also claiming
> the monitor only support separate sync:
> https://bugzilla.redhat.com/show_bug.cgi?id=540024
> Potentially that monitor should just be quirked or something.
>
> Anyways, what we are dealing with now is some kind of funny i915
> JSL machine with eDP where the panel claims to support a sensible
> 60Hz separate sync mode, and a 50Hz mode with bipolar analog
> csync. The 50Hz mode does not work so we want to not use it.
> Easiest way is to just correctly flag it as csync and the driver
> will reject it.
>
> TODO: or should we just reject any form of csync (or at least
> the analog variants) for digital display interfaces?
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8146
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 23 +++
> include/drm/drm_edid.h | 12 +---
> 2 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ebab862b8b1a..fa20b1107ce3 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3424,10 +3424,6 @@ static struct drm_display_mode
> *drm_mode_detailed(struct drm_connector *connecto
> connector->base.id, connector->name);
> return NULL;
> }
> - if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) {
> - drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Composite sync not
> supported\n",
> - connector->base.id, connector->name);
> - }
>
> /* it is incorrect if hsync/vsync width is zero */
> if (!hsync_pulse_width || !vsync_pulse_width) {
> @@ -3474,10 +3470,21 @@ static struct drm_display_mode
> *drm_mode_detailed(struct drm_connector *connecto
> if (info->quirks & EDID_QUIRK_DETAILED_SYNC_PP) {
> mode->flags |= DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC;
> } else {
> - mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
> - DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
> - mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
> - DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
> + switch (pt->misc & DRM_EDID_PT_SYNC_MASK) {
> + case DRM_EDID_PT_ANALOG_CSYNC:
> + case DRM_EDID_PT_BIPOLAR_ANALOG_CSYNC:
> + case DRM_EDID_PT_DIGITAL_CSYNC:
> + drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Composite sync!\n",
> + connector->base.id, connector->name);
> + mode->flags |= DRM_MODE_FLAG_CSYNC |
> DRM_MODE_FLAG_NCSYNC;
Not sure it makes a huge difference, and I expect this case to be rare,
but what's the _N_ CSYNC based on here?
I also observe the spec appears to indicate "Horizontal Sync is Negative
(outside of V-sync)" and "Horizontal Sync is Positive (outside of
V-sync)" bit is valid also for Digital Composite Sync.
See how the bits for vertical sync have "1 1 0" or "1 1 1" but for
horizontal sync it's "1 _ _ 0" and "1 _ _ 1". Does that indicate the
polarity for digital composite sync?! The spec is not super clear.
> + break;
> + case DRM_EDID_PT_DIGITAL_SEPARATE_SYNC:
> + mode->flags |= (pt->misc & DRM_EDID_PT_HSYNC_POSITIVE) ?
> + DRM_MODE_FLAG_PHSYNC : DRM_MODE_FLAG_NHSYNC;
> + mode->flags |= (pt->misc & DRM_EDID_PT_VSYNC_POSITIVE) ?
> + DRM_MODE_FLAG_PVSYNC : DRM_MODE_FLAG_NVSYNC;
I think this is the good stuff, we shouldn't be looking at these flags
and setting PHSYNC/NHSYNC/PVSYNC/NVSYNC unless we have digital separate
sync.
Overall I think
Reviewed-by: Jani Nikula
Although it's not all completely clear. But I think being explicit is
better than assuming something and simply debug logging about csync and
not really doing anything about it.
> + break;
> + }
> }
>
> set_size:
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 70ae6c290bdc..49ee10272603 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -61,9 +61,15 @@ struct std_timing {
> u8 vfreq_aspect;
> } __attribute__((packed));
>
> -#define DRM_EDID_PT_HSYNC_POSITIVE (1 << 1)
> -#define DRM_EDID_PT_VSYNC_POSITIVE (1 << 2)
> -#define DRM_EDID_PT_SEPARATE_SYNC (3 << 3)
> +#define DRM_EDID_PT_SYNC_MASK (3 << 3)
> +# define DRM_EDID_PT_ANALOG_CSYNC
Re: [Intel-gfx] [PATCH v3 04/22] drm/i915: Introduce _hotplug_mask()
On Tue, Feb 28, 2023 at 08:36:16PM +0200, Jani Nikula wrote:
> On Wed, 22 Feb 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Pair each _hotplug_enables() function with
> > a corresponding _hotplug_mask() function so that
> > we can determine right bits to clear on a per hpd_pin basis.
> > We'll need this for turning on HPD sense for a specific
> > encoder rather than just all of them.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 231 ++--
> > 1 file changed, 160 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 13ada0916c2a..ecfa6dad145a 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2835,8 +2835,25 @@ static void cherryview_irq_reset(struct
> > drm_i915_private *dev_priv)
> > vlv_display_irq_reset(dev_priv);
> > spin_unlock_irq(_priv->irq_lock);
> > }
> >
> > +static u32 ibx_hotplug_mask(struct drm_i915_private *i915,
> > + enum hpd_pin hpd_pin)
>
>
> What's the reason for passing i915 to these functions? I see no use in
> this series, am I missing something? Seems like it makes some calls a
> bit convoluted.
>
> BR,
> Jani.
>
> > +{
> > + switch (hpd_pin) {
> > + case HPD_PORT_A:
I think I initially copied over the LPT-LP check from
ibx_hotplug_enables(), which is what needed i915. But
apparently I got rid of it later, and so looks like
i915 can go too.
> > + return PORTA_HOTPLUG_ENABLE;
> > + case HPD_PORT_B:
> > + return PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_MASK;
> > + case HPD_PORT_C:
> > + return PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_MASK;
> > + case HPD_PORT_D:
> > + return PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_MASK;
> > + default:
> > + return 0;
> > + }
> > +}
> > +
> > static u32 ibx_hotplug_enables(struct intel_encoder *encoder)
> > {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> >
> > @@ -2869,15 +2886,12 @@ static void ibx_hpd_detection_setup(struct
> > drm_i915_private *dev_priv)
> > * duration to 2ms (which is the minimum in the Display Port spec).
> > * The pulse duration bits are reserved on LPT+.
> > */
> > intel_uncore_rmw(_priv->uncore, PCH_PORT_HOTPLUG,
> > -PORTA_HOTPLUG_ENABLE |
No LPT-LP check here either, so presumably clearing the bit
unconditionally is fine... Yeah, doesn't look like there was
anything else there, ever.
> > -PORTB_HOTPLUG_ENABLE |
> > -PORTC_HOTPLUG_ENABLE |
> > -PORTD_HOTPLUG_ENABLE |
> > -PORTB_PULSE_DURATION_MASK |
> > -PORTC_PULSE_DURATION_MASK |
> > -PORTD_PULSE_DURATION_MASK,
> > +ibx_hotplug_mask(dev_priv, HPD_PORT_A) |
> > +ibx_hotplug_mask(dev_priv, HPD_PORT_B) |
> > +ibx_hotplug_mask(dev_priv, HPD_PORT_C) |
> > +ibx_hotplug_mask(dev_priv, HPD_PORT_D),
> > intel_hpd_hotplug_enables(dev_priv,
> > ibx_hotplug_enables));
> > }
> >
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access
On Tue, Feb 28, 2023 at 04:42:43PM -0300, Gustavo Sousa wrote:
> On Thu, Feb 23, 2023 at 04:22:59PM -0800, Matt Roper wrote:
> > A recommended tuning setting for both gen12 and Xe_HP platforms requires
> > that we grant userspace r/w access to the COMMON_SLICE_CHICKEN3
> > register.
> >
> > Bspec: 73993, 73994, 31870, 68331
> > Cc: Dongwon Kim
> > Signed-off-by: Matt Roper
>
> Reviewed-by: Gustavo Sousa
Oops! Wrong email address here. Please, consider the following as the correct
one:
Reviewed-by: Gustavo Sousa
>
> > ---
> > The bspec update to add COMMON_SLICE_CHICKEN3 to the tuning guide pages
> > is still pending at the moment, but should be finalized shortly.
> >
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 25 -
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > index 1ef9c9fa2eff..0444c715998a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > @@ -2194,6 +2194,10 @@ static void tgl_whitelist_build(struct
> > intel_engine_cs *engine)
> >
> > /* Wa_1806527549:tgl */
> > whitelist_reg(w, HIZ_CHICKEN);
> > +
> > + /* Required by recommended tuning setting (not a workaround) */
> > + whitelist_reg(w, GEN11_COMMON_SLICE_CHICKEN3);
> > +
> > break;
> > default:
> > break;
> > @@ -2227,6 +2231,9 @@ static void dg2_whitelist_build(struct
> > intel_engine_cs *engine)
> > RING_FORCE_TO_NONPRIV_ACCESS_RD |
> > RING_FORCE_TO_NONPRIV_RANGE_4);
> >
> > + /* Required by recommended tuning setting (not a workaround) */
> > + whitelist_mcr_reg(w, XEHP_COMMON_SLICE_CHICKEN3);
> > +
> > break;
> > case COMPUTE_CLASS:
> > /* Wa_16011157294:dg2_g10 */
> > @@ -2264,6 +2271,22 @@ static void pvc_whitelist_build(struct
> > intel_engine_cs *engine)
> > blacklist_trtt(engine);
> > }
> >
> > +static void mtl_whitelist_build(struct intel_engine_cs *engine)
> > +{
> > + struct i915_wa_list *w = >whitelist;
> > +
> > + switch (engine->class) {
> > + case RENDER_CLASS:
> > + /* Required by recommended tuning setting (not a workaround) */
> > + whitelist_mcr_reg(w, XEHP_COMMON_SLICE_CHICKEN3);
> > +
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > +}
> > +
> > void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> > {
> > struct drm_i915_private *i915 = engine->i915;
> > @@ -2272,7 +2295,7 @@ void intel_engine_init_whitelist(struct
> > intel_engine_cs *engine)
> > wa_init_start(w, engine->gt, "whitelist", engine->name);
> >
> > if (IS_METEORLAKE(i915))
> > - ; /* noop; none at this time */
> > + mtl_whitelist_build(engine);
> > else if (IS_PONTEVECCHIO(i915))
> > pvc_whitelist_build(engine);
> > else if (IS_DG2(i915))
> > --
> > 2.39.1
> >
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Stop whitelisting CS_CTX_TIMESTAMP on Xe_HP platforms
On Thu, Feb 23, 2023 at 04:23:00PM -0800, Matt Roper wrote:
> Xe_HP architecture already makes the CS_CTX_TIMESTAMP readable by
> userspace on all engines; there's no longer a need to add it to the
> software-managed whitelist for the non-RCS engines.
>
> Bspec: 45545
> Signed-off-by: Matt Roper
Acked-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 11 +--
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 0444c715998a..ee0649851a4c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2204,17 +2204,10 @@ static void tgl_whitelist_build(struct
> intel_engine_cs *engine)
> }
> }
>
> -static void xehpsdv_whitelist_build(struct intel_engine_cs *engine)
> -{
> - allow_read_ctx_timestamp(engine);
> -}
> -
> static void dg2_whitelist_build(struct intel_engine_cs *engine)
> {
> struct i915_wa_list *w = >whitelist;
>
> - allow_read_ctx_timestamp(engine);
> -
> switch (engine->class) {
> case RENDER_CLASS:
> /*
> @@ -2265,8 +2258,6 @@ static void blacklist_trtt(struct intel_engine_cs
> *engine)
>
> static void pvc_whitelist_build(struct intel_engine_cs *engine)
> {
> - allow_read_ctx_timestamp(engine);
> -
> /* Wa_16014440446:pvc */
> blacklist_trtt(engine);
> }
> @@ -2301,7 +2292,7 @@ void intel_engine_init_whitelist(struct intel_engine_cs
> *engine)
> else if (IS_DG2(i915))
> dg2_whitelist_build(engine);
> else if (IS_XEHPSDV(i915))
> - xehpsdv_whitelist_build(engine);
> + ; /* none needed */
> else if (GRAPHICS_VER(i915) == 12)
> tgl_whitelist_build(engine);
> else if (GRAPHICS_VER(i915) == 11)
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Whitelist COMMON_SLICE_CHICKEN3 for UMD access
On Thu, Feb 23, 2023 at 04:22:59PM -0800, Matt Roper wrote:
> A recommended tuning setting for both gen12 and Xe_HP platforms requires
> that we grant userspace r/w access to the COMMON_SLICE_CHICKEN3
> register.
>
> Bspec: 73993, 73994, 31870, 68331
> Cc: Dongwon Kim
> Signed-off-by: Matt Roper
Reviewed-by: Gustavo Sousa
> ---
> The bspec update to add COMMON_SLICE_CHICKEN3 to the tuning guide pages
> is still pending at the moment, but should be finalized shortly.
>
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 25 -
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 1ef9c9fa2eff..0444c715998a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2194,6 +2194,10 @@ static void tgl_whitelist_build(struct intel_engine_cs
> *engine)
>
> /* Wa_1806527549:tgl */
> whitelist_reg(w, HIZ_CHICKEN);
> +
> + /* Required by recommended tuning setting (not a workaround) */
> + whitelist_reg(w, GEN11_COMMON_SLICE_CHICKEN3);
> +
> break;
> default:
> break;
> @@ -2227,6 +2231,9 @@ static void dg2_whitelist_build(struct intel_engine_cs
> *engine)
> RING_FORCE_TO_NONPRIV_ACCESS_RD |
> RING_FORCE_TO_NONPRIV_RANGE_4);
>
> + /* Required by recommended tuning setting (not a workaround) */
> + whitelist_mcr_reg(w, XEHP_COMMON_SLICE_CHICKEN3);
> +
> break;
> case COMPUTE_CLASS:
> /* Wa_16011157294:dg2_g10 */
> @@ -2264,6 +2271,22 @@ static void pvc_whitelist_build(struct intel_engine_cs
> *engine)
> blacklist_trtt(engine);
> }
>
> +static void mtl_whitelist_build(struct intel_engine_cs *engine)
> +{
> + struct i915_wa_list *w = >whitelist;
> +
> + switch (engine->class) {
> + case RENDER_CLASS:
> + /* Required by recommended tuning setting (not a workaround) */
> + whitelist_mcr_reg(w, XEHP_COMMON_SLICE_CHICKEN3);
> +
> + break;
> + default:
> + break;
> + }
> +
> +}
> +
> void intel_engine_init_whitelist(struct intel_engine_cs *engine)
> {
> struct drm_i915_private *i915 = engine->i915;
> @@ -2272,7 +2295,7 @@ void intel_engine_init_whitelist(struct intel_engine_cs
> *engine)
> wa_init_start(w, engine->gt, "whitelist", engine->name);
>
> if (IS_METEORLAKE(i915))
> - ; /* noop; none at this time */
> + mtl_whitelist_build(engine);
> else if (IS_PONTEVECCHIO(i915))
> pvc_whitelist_build(engine);
> else if (IS_DG2(i915))
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH v3 04/22] drm/i915: Introduce _hotplug_mask()
On Wed, 22 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pair each _hotplug_enables() function with
> a corresponding _hotplug_mask() function so that
> we can determine right bits to clear on a per hpd_pin basis.
> We'll need this for turning on HPD sense for a specific
> encoder rather than just all of them.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 231 ++--
> 1 file changed, 160 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 13ada0916c2a..ecfa6dad145a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2835,8 +2835,25 @@ static void cherryview_irq_reset(struct
> drm_i915_private *dev_priv)
> vlv_display_irq_reset(dev_priv);
> spin_unlock_irq(_priv->irq_lock);
> }
>
> +static u32 ibx_hotplug_mask(struct drm_i915_private *i915,
> + enum hpd_pin hpd_pin)
What's the reason for passing i915 to these functions? I see no use in
this series, am I missing something? Seems like it makes some calls a
bit convoluted.
BR,
Jani.
> +{
> + switch (hpd_pin) {
> + case HPD_PORT_A:
> + return PORTA_HOTPLUG_ENABLE;
> + case HPD_PORT_B:
> + return PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_MASK;
> + case HPD_PORT_C:
> + return PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_MASK;
> + case HPD_PORT_D:
> + return PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_MASK;
> + default:
> + return 0;
> + }
> +}
> +
> static u32 ibx_hotplug_enables(struct intel_encoder *encoder)
> {
> struct drm_i915_private *i915 = to_i915(encoder->base.dev);
>
> @@ -2869,15 +2886,12 @@ static void ibx_hpd_detection_setup(struct
> drm_i915_private *dev_priv)
>* duration to 2ms (which is the minimum in the Display Port spec).
>* The pulse duration bits are reserved on LPT+.
>*/
> intel_uncore_rmw(_priv->uncore, PCH_PORT_HOTPLUG,
> - PORTA_HOTPLUG_ENABLE |
> - PORTB_HOTPLUG_ENABLE |
> - PORTC_HOTPLUG_ENABLE |
> - PORTD_HOTPLUG_ENABLE |
> - PORTB_PULSE_DURATION_MASK |
> - PORTC_PULSE_DURATION_MASK |
> - PORTD_PULSE_DURATION_MASK,
> + ibx_hotplug_mask(dev_priv, HPD_PORT_A) |
> + ibx_hotplug_mask(dev_priv, HPD_PORT_B) |
> + ibx_hotplug_mask(dev_priv, HPD_PORT_C) |
> + ibx_hotplug_mask(dev_priv, HPD_PORT_D),
>intel_hpd_hotplug_enables(dev_priv,
> ibx_hotplug_enables));
> }
>
> static void ibx_hpd_irq_setup(struct drm_i915_private *dev_priv)
> @@ -2891,55 +2905,75 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
> *dev_priv)
>
> ibx_hpd_detection_setup(dev_priv);
> }
>
> +static u32 _icp_ddi_hotplug_enables(enum hpd_pin hpd_pin)
> +{
> + switch (hpd_pin) {
> + case HPD_PORT_A:
> + case HPD_PORT_B:
> + case HPD_PORT_C:
> + case HPD_PORT_D:
> + return SHOTPLUG_CTL_DDI_HPD_ENABLE(hpd_pin);
> + default:
> + return 0;
> + }
> +}
> +
> +static u32 icp_ddi_hotplug_mask(struct drm_i915_private *i915, enum hpd_pin
> hpd_pin)
> +{
> + return _icp_ddi_hotplug_enables(hpd_pin);
> +}
> +
> static u32 icp_ddi_hotplug_enables(struct intel_encoder *encoder)
> {
> - switch (encoder->hpd_pin) {
> - case HPD_PORT_A:
> - case HPD_PORT_B:
> - case HPD_PORT_C:
> - case HPD_PORT_D:
> - return SHOTPLUG_CTL_DDI_HPD_ENABLE(encoder->hpd_pin);
> + return _icp_ddi_hotplug_enables(encoder->hpd_pin);
> +}
> +
> +static u32 _icp_tc_hotplug_enables(enum hpd_pin hpd_pin)
> +{
> + switch (hpd_pin) {
> + case HPD_PORT_TC1:
> + case HPD_PORT_TC2:
> + case HPD_PORT_TC3:
> + case HPD_PORT_TC4:
> + case HPD_PORT_TC5:
> + case HPD_PORT_TC6:
> + return ICP_TC_HPD_ENABLE(hpd_pin);
> default:
> return 0;
> }
> }
>
> +static u32 icp_tc_hotplug_mask(struct drm_i915_private *i915, enum hpd_pin
> hpd_pin)
> +{
> + return _icp_tc_hotplug_enables(hpd_pin);
> +}
> +
> static u32 icp_tc_hotplug_enables(struct intel_encoder *encoder)
> {
> - switch (encoder->hpd_pin) {
> - case HPD_PORT_TC1:
> - case HPD_PORT_TC2:
> - case HPD_PORT_TC3:
> - case HPD_PORT_TC4:
> - case HPD_PORT_TC5:
> - case HPD_PORT_TC6:
> - return ICP_TC_HPD_ENABLE(encoder->hpd_pin);
> - default:
> - return 0;
> - }
> + return _icp_tc_hotplug_enables(encoder->hpd_pin);
> }
>
> static void icp_ddi_hpd_detection_setup(struct drm_i915_private *dev_priv)
> {
> intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_DDI,
> -
Re: [Intel-gfx] [PATCH v3 03/22] drm/i915: Get rid of the gm45 HPD live state nonsense
On Wed, 22 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The idea that ctg uses different HPD live state bits is
> total nonsense, at least on my machine (Dell Latitude
> E5400).
>
> The only reason DP-B even works on my ctg is that DP-D
> live state is stuck high, even though there is no physical
> DP-D port. So when the detect checks DP-B live state it
> sees the stuck live state of DP-D instead. If I hack
> the driver to not register DP-D at all, and thus we never
> enabe DP-D HPD, DP-B stops working as well.
>
> Just to put some conclusive evidence into this mess,
> here are the actual hotplug register values for each port:
> Everything disconnected:
> PORT_HOTPLUG_EN (0x00061110): 0x
> PORT_HOTPLUG_STAT (0x00061114): 0x
> PORT_HOTPLUG_EN (0x00061110): 0x0800
> PORT_HOTPLUG_STAT (0x00061114): 0x0800
> PORT_HOTPLUG_EN (0x00061110): 0x1000
> PORT_HOTPLUG_STAT (0x00061114): 0x
> PORT_HOTPLUG_EN (0x00061110): 0x2000
> PORT_HOTPLUG_STAT (0x00061114): 0x
> Only port B connected:
> PORT_HOTPLUG_EN (0x00061110): 0x
> PORT_HOTPLUG_STAT (0x00061114): 0x
> PORT_HOTPLUG_EN (0x00061110): 0x0800
> PORT_HOTPLUG_STAT (0x00061114): 0x0800
> PORT_HOTPLUG_EN (0x00061110): 0x1000
> PORT_HOTPLUG_STAT (0x00061114): 0x
> PORT_HOTPLUG_EN (0x00061110): 0x2000
> PORT_HOTPLUG_STAT (0x00061114): 0x2000
> Only port C connected:
> PORT_HOTPLUG_EN (0x00061110): 0x
> PORT_HOTPLUG_STAT (0x00061114): 0x
> PORT_HOTPLUG_EN (0x00061110): 0x0800
> PORT_HOTPLUG_STAT (0x00061114): 0x0800
> PORT_HOTPLUG_EN (0x00061110): 0x1000
> PORT_HOTPLUG_STAT (0x00061114): 0x1000
> PORT_HOTPLUG_EN (0x00061110): 0x2000
> PORT_HOTPLUG_STAT (0x00061114): 0x
>
> So the enable bit and live state bit always match 1:1.
>
> Signed-off-by: Ville Syrjälä
I'll take your word for it.
Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c | 28 +--
> drivers/gpu/drm/i915/i915_reg.h | 13 +
> 2 files changed, 2 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
> b/drivers/gpu/drm/i915/display/g4x_dp.c
> index a50ad0fff57c..920d570f7594 100644
> --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> @@ -1196,31 +1196,8 @@ static bool g4x_digital_port_connected(struct
> intel_encoder *encoder)
>
> return intel_de_read(dev_priv, PORT_HOTPLUG_STAT) & bit;
> }
>
> -static bool gm45_digital_port_connected(struct intel_encoder *encoder)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - u32 bit;
> -
> - switch (encoder->hpd_pin) {
> - case HPD_PORT_B:
> - bit = PORTB_HOTPLUG_LIVE_STATUS_GM45;
> - break;
> - case HPD_PORT_C:
> - bit = PORTC_HOTPLUG_LIVE_STATUS_GM45;
> - break;
> - case HPD_PORT_D:
> - bit = PORTD_HOTPLUG_LIVE_STATUS_GM45;
> - break;
> - default:
> - MISSING_CASE(encoder->hpd_pin);
> - return false;
> - }
> -
> - return intel_de_read(dev_priv, PORT_HOTPLUG_STAT) & bit;
> -}
> -
> static bool ilk_digital_port_connected(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> u32 bit = dev_priv->display.hotplug.hpd[encoder->hpd_pin];
> @@ -1383,12 +1360,9 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
>
> dig_port->hpd_pulse = intel_dp_hpd_pulse;
>
> if (HAS_GMCH(dev_priv)) {
> - if (IS_GM45(dev_priv))
> - dig_port->connected = gm45_digital_port_connected;
> - else
> - dig_port->connected = g4x_digital_port_connected;
> + dig_port->connected = g4x_digital_port_connected;
> } else {
> if (port == PORT_A)
> dig_port->connected = ilk_digital_port_connected;
> else
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c1efa655fb68..de58695ad1c0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2482,20 +2482,9 @@
> #define CRT_HOTPLUG_DETECT_VOLTAGE_325MV (0 << 2)
> #define CRT_HOTPLUG_DETECT_VOLTAGE_475MV (1 << 2)
>
> #define PORT_HOTPLUG_STAT_MMIO(DISPLAY_MMIO_BASE(dev_priv) + 0x61114)
> -/*
> - * HDMI/DP bits are g4x+
> - *
> - * WARNING: Bspec for hpd status
Re: [Intel-gfx] [PATCH v3 02/22] drm/i915: Fix SKL DDI A digital port .connected()
On Wed, 22 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> SKL doesn't have any north DE hotplug stuff. Currently we're
> trying to read DDI A live state from the BDW north DE bit,
> instead of the approproate south DE bit. Fix it.
>
> And for good measure clear the pointer to the north hpd
> pin array, so that we'll actually notice if some other
> place is also using the wrong thing.
>
> Signed-off-by: Ville Syrjälä
Finally found the clue in bspec for skl+, "This field is unused in
projects that have a PCH."
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 11 +++
> drivers/gpu/drm/i915/i915_irq.c | 2 ++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 40b5c93f9223..1a042f3658eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4508,15 +4508,18 @@ void intel_ddi_init(struct drm_i915_private
> *dev_priv, enum port port)
> if (intel_phy_is_tc(dev_priv, phy))
> dig_port->connected = intel_tc_port_connected;
> else
> dig_port->connected = lpt_digital_port_connected;
> - } else if (DISPLAY_VER(dev_priv) >= 8) {
> - if (port == PORT_A || IS_GEMINILAKE(dev_priv) ||
> - IS_BROXTON(dev_priv))
> + } else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) {
> + dig_port->connected = bdw_digital_port_connected;
> + } else if (DISPLAY_VER(dev_priv) == 9) {
> + dig_port->connected = lpt_digital_port_connected;
> + } else if (IS_BROADWELL(dev_priv)) {
> + if (port == PORT_A)
> dig_port->connected = bdw_digital_port_connected;
> else
> dig_port->connected = lpt_digital_port_connected;
> - } else {
> + } else if (IS_HASWELL(dev_priv)) {
> if (port == PORT_A)
> dig_port->connected = hsw_digital_port_connected;
> else
> dig_port->connected = lpt_digital_port_connected;
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b024a3a7ca19..13ada0916c2a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -197,8 +197,10 @@ static void intel_hpd_init_pins(struct drm_i915_private
> *dev_priv)
> if (DISPLAY_VER(dev_priv) >= 11)
> hpd->hpd = hpd_gen11;
> else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
> hpd->hpd = hpd_bxt;
> + else if (DISPLAY_VER(dev_priv) == 9)
> + hpd->hpd = NULL; /* no north HPD on SKL */
> else if (DISPLAY_VER(dev_priv) >= 8)
> hpd->hpd = hpd_bdw;
> else if (DISPLAY_VER(dev_priv) >= 7)
> hpd->hpd = hpd_ivb;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3 01/22] drm/i915: Populate dig_port->connected() before connector init
On Wed, 22 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We'll need dig_port->connected() to be there for a HPD live
> state check during eDP connector probing. Reorder intel_ddi_init()
> accordingly. g4x_dp_init() is already fine.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 40
> 1 file changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index e5979427b38b..40b5c93f9223 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4503,8 +4503,28 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
>
> drm_WARN_ON(_priv->drm, port > PORT_I);
> dig_port->ddi_io_power_domain =
> intel_display_power_ddi_io_domain(dev_priv, port);
>
> + if (DISPLAY_VER(dev_priv) >= 11) {
> + if (intel_phy_is_tc(dev_priv, phy))
> + dig_port->connected = intel_tc_port_connected;
> + else
> + dig_port->connected = lpt_digital_port_connected;
> + } else if (DISPLAY_VER(dev_priv) >= 8) {
> + if (port == PORT_A || IS_GEMINILAKE(dev_priv) ||
> + IS_BROXTON(dev_priv))
> + dig_port->connected = bdw_digital_port_connected;
> + else
> + dig_port->connected = lpt_digital_port_connected;
> + } else {
> + if (port == PORT_A)
> + dig_port->connected = hsw_digital_port_connected;
> + else
> + dig_port->connected = lpt_digital_port_connected;
> + }
> +
> + intel_infoframe_init(dig_port);
> +
> if (init_dp) {
> if (!intel_ddi_init_dp_connector(dig_port))
> goto err;
>
> @@ -4520,28 +4540,8 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> if (!intel_ddi_init_hdmi_connector(dig_port))
> goto err;
> }
>
> - if (DISPLAY_VER(dev_priv) >= 11) {
> - if (intel_phy_is_tc(dev_priv, phy))
> - dig_port->connected = intel_tc_port_connected;
> - else
> - dig_port->connected = lpt_digital_port_connected;
> - } else if (DISPLAY_VER(dev_priv) >= 8) {
> - if (port == PORT_A || IS_GEMINILAKE(dev_priv) ||
> - IS_BROXTON(dev_priv))
> - dig_port->connected = bdw_digital_port_connected;
> - else
> - dig_port->connected = lpt_digital_port_connected;
> - } else {
> - if (port == PORT_A)
> - dig_port->connected = hsw_digital_port_connected;
> - else
> - dig_port->connected = lpt_digital_port_connected;
> - }
> -
> - intel_infoframe_init(dig_port);
> -
> return;
>
> err:
> drm_encoder_cleanup(>base);
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.IGT: success for Revert "drm/shmem-helper: Switch to reservation lock"
== Series Details ==
Series: Revert "drm/shmem-helper: Switch to reservation lock"
URL : https://patchwork.freedesktop.org/series/114478/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12790_full -> Patchwork_114478v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (9 -> 11)
--
Additional (2): shard-rkl shard-tglu-10
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114478v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_isolation@preservation-s3@vcs0:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-7/igt@gem_ctx_isolation@preservation...@vcs0.html
* {igt@kms_hdr@invalid-hdr}:
- {shard-tglu}: NOTRUN -> [SKIP][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-6/igt@kms_...@invalid-hdr.html
* {igt@kms_hdr@invalid-hdr@pipe-a-dp-1}:
- shard-apl: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-apl4/igt@kms_hdr@invalid-...@pipe-a-dp-1.html
Known issues
Here are the changes found in Patchwork_114478v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- shard-tglu-10: NOTRUN -> [SKIP][4] ([i915#7456])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-10/igt@debugfs_t...@basic-hwmon.html
* igt@device_reset@unbind-cold-reset-rebind:
- shard-tglu-10: NOTRUN -> [SKIP][5] ([i915#7701])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-10/igt@device_re...@unbind-cold-reset-rebind.html
* igt@feature_discovery@display-4x:
- shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#1839])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-10/igt@feature_discov...@display-4x.html
* igt@gem_ccs@block-copy-compressed:
- shard-tglu-9: NOTRUN -> [SKIP][7] ([i915#3555] / [i915#5325])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-9/igt@gem_...@block-copy-compressed.html
* igt@gem_create@create-ext-cpu-access-big:
- shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#6335])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-10/igt@gem_cre...@create-ext-cpu-access-big.html
* igt@gem_ctx_persistence@engines-mixed-process:
- shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#1099]) +15
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-snb6/igt@gem_ctx_persiste...@engines-mixed-process.html
* igt@gem_ctx_sseu@invalid-args:
- shard-tglu-9: NOTRUN -> [SKIP][10] ([i915#280])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-9/igt@gem_ctx_s...@invalid-args.html
* igt@gem_eio@unwedge-stress:
- shard-snb: NOTRUN -> [FAIL][11] ([i915#3354])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-snb4/igt@gem_...@unwedge-stress.html
* igt@gem_exec_capture@capture-invisible@smem0:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#6334])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-glk4/igt@gem_exec_capture@capture-invisi...@smem0.html
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#6334])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-apl7/igt@gem_exec_capture@capture-invisi...@smem0.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: NOTRUN -> [FAIL][14] ([i915#2846])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-apl2/igt@gem_exec_f...@basic-deadline.html
- shard-glk: NOTRUN -> [FAIL][15] ([i915#2846])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-glk9/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-glk: NOTRUN -> [FAIL][16] ([i915#2842]) +6 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html
- shard-tglu-10: NOTRUN -> [FAIL][17] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-10/igt@gem_exec_fair@basic-none-r...@rcs0.html
* igt@gem_exec_params@rsvd2-dirt:
- shard-tglu-10: NOTRUN -> [SKIP][18] ([fdo#109283])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/shard-tglu-10/igt@gem_exec_par...@rsvd2-dirt.html
* igt@gem_huc_copy@huc-copy:
- shard-apl: NOTRUN -> [SKIP][19]
Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support
> From: Liu, Yi L > Sent: Tuesday, February 28, 2023 11:03 AM > > From: Jason Gunthorpe > > Sent: Tuesday, February 28, 2023 3:21 AM > > > > On Mon, Feb 27, 2023 at 03:11:16AM -0800, Yi Liu wrote: > > > Existing VFIO provides group-centric user APIs for userspace. > > > Userspace opens the /dev/vfio/$group_id first before getting device > > > fd and hence getting access to device. This is not the desired model > > > for iommufd. Per the conclusion of community discussion[1], iommufd > > > provides device- > > centric > > > kAPIs and requires its consumer (like VFIO) to be device-centric > > > user APIs. Such user APIs are used to associate device with iommufd > > > and also the I/O address spaces managed by the iommufd. > > > > > > This series first introduces a per device file structure to be > > > prepared for further enhancement and refactors the kvm-vfio code to > > > be prepared for accepting device file from userspace. Then refactors > > > the vfio to be able to handle iommufd binding. This refactor > > > includes the mechanism of blocking device access before iommufd > > > bind, making the device_open > > exclusive. > > > between the group path and the cdev path. Eventually, adds the cdev > > support > > > for vfio device, and makes group infrastructure optional as it is > > > not needed when vfio device cdev is compiled. > > > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > > > The complete code can be found in below branch, simple test done > > > with > > the > > > legacy group path and the cdev path. Draft QEMU branch can be found > > at[3] > > > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v5 > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > > > base-commit: 63777bd2daa3625da6eada88bd9081f047664dad > > > > This needs to be rebased onto a clean v6.3-rc1 when it comes out > > Yes, I'll send rebase and send one more version when v6.3-rc1 comes. Here > just try to be near to the vfio code in Alex's next branch. > > Regards, > Yi Liu Verified this series by "Intel GVT-g GPU device mediated passthrough" and "Intel GVT-d GPU device direct passthrough" technologies. Both passed VFIO legacy mode / compat mode / cdev mode, including negative tests. Tested-by: Terrence Xu
Re: [Intel-gfx] [PATCH 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> The array of rc_parameters contains a mixture of parameters from DSC 1.1
> and DSC 1.2 standards. Split these tow configuration arrays in
> preparation to adding more configuration data.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 127 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c | 10 +-
> include/drm/display/drm_dsc_helper.h | 7 +-
> 3 files changed, 119 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index a6d11f474656..51794b40526a 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -326,11 +326,81 @@ struct rc_parameters_data {
>
> #define DSC_BPP(bpp) ((bpp) << 4)
>
> +static const struct rc_parameters_data rc_parameters_pre_scr[] = {
> +{ DSC_BPP(8), 8,
> + /* 8BPP/8BPC */
I still dislike this indentation...
> + { 512, 12, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
> + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(8), 10,
> + /* 8BPP/10BPC */
> + { 512, 12, 6144, 7, 16, 15, 15, {
> + /*
> + * DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
> + * VESA DSC 1.1 Table E-5 sets it to 4.
> + */
> + { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(8), 12,
> + /* 8BPP/12BPC */
> + { 512, 12, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(12), 8,
> + /* 12BPP/8BPC */
> + { 341, 15, 2048, 3, 12, 11, 11, {
> + { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
> + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(12), 10,
> + /* 12BPP/10BPC */
> + { 341, 15, 2048, 7, 16, 15, 15, {
> + { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
> + { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(12), 12,
> + /* 12BPP/12BPC */
> + { 341, 15, 2048, 11, 20, 19, 19, {
> + { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
> + { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> +},
> +{ /* sentinel */ }
> +};
> +
> /*
> * Selected Rate Control Related Parameter Recommended Values
> * from DSC_v1.11 spec & C Model release: DSC_model_20161212
> */
> -static const struct rc_parameters_data rc_parameters[] = {
> +static const struct rc_parameters_data rc_parameters_1_2_444[] = {
> { DSC_BPP(6), 8,
> /* 6BPP/8BPC */
> { 768, 15, 6144, 3, 13, 11, 11, {
> @@ -390,22 +460,18 @@ static const struct rc_parameters_data rc_parameters[]
> = {
> { 512, 12, 6144, 3, 12, 11, 11, {
> { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> - { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
> - { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, -12 },
> + { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
> }
> }
> },
> { DSC_BPP(8), 10,
> /* 8BPP/10BPC */
> { 512, 12, 6144, 7, 16, 15, 15, {
> - /*
> - * DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
> - * VESA DSC 1.1 Table E-5 sets it to 4.
> - */
> - { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 0, 8, 2 }, { 4, 8, 0 },
Re: [Intel-gfx] [PATCH 07/10] drm/display/dsc: include the rest of pre-SCR parameters
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
> include them here for completeness.
Need to run now, note to self:
Does i915 use the arrays to limit the bpp/bpc combos supported by
hardware? Do we need to add separate limiting in i915.
BR,
Jani.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 72
> 1 file changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index 51794b40526a..1612536014ea 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -327,6 +327,16 @@ struct rc_parameters_data {
> #define DSC_BPP(bpp) ((bpp) << 4)
>
> static const struct rc_parameters_data rc_parameters_pre_scr[] = {
> +{ DSC_BPP(6), 8,
> + /* 6BPP/8BPC */
> + { 683, 15, 6144, 3, 13, 11, 11, {
> + { 0, 2, 0 }, { 1, 4, -2 }, { 3, 6, -2 }, { 4, 6, -4 },
> + { 5, 7, -6 }, { 5, 7, -6 }, { 6, 7, -6 }, { 6, 8, -8 },
> + { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 }, { 10, 12, -12 },
> + { 10, 13, -12 }, { 12, 14, -12 }, { 15, 15, -12 }
> + }
> + }
> +},
> { DSC_BPP(8), 8,
> /* 8BPP/8BPC */
> { 512, 12, 6144, 3, 12, 11, 11, {
> @@ -362,6 +372,37 @@ static const struct rc_parameters_data
> rc_parameters_pre_scr[] = {
> }
> }
> },
> +{ DSC_BPP(10), 8,
> + /* 10BPP/8BPC */
> + { 410, 12, 5632, 3, 12, 11, 11, {
> + { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 11, -10 },
> + { 5, 12, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(10), 10,
> + /* 10BPP/10BPC */
> + { 410, 12, 5632, 7, 16, 15, 15, {
> + { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
> + { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 15, -10 },
> + { 9, 16, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(10), 12,
> + /* 10BPP/12BPC */
> + { 410, 12, 5632, 11, 20, 19, 19, {
> + { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
> + { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
> + { 13, 19, -10 }, { 13, 20, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> +},
> { DSC_BPP(12), 8,
> /* 12BPP/8BPC */
> { 341, 15, 2048, 3, 12, 11, 11, {
> @@ -393,6 +434,37 @@ static const struct rc_parameters_data
> rc_parameters_pre_scr[] = {
> }
> }
> },
> +{ DSC_BPP(15), 8,
> + /* 15BPP/8BPC */
> + { 273, 15, 2048, 3, 12, 11, 11, {
> + { 0, 0, 10 }, { 0, 1, 8 }, { 0, 1, 6 }, { 0, 2, 4 },
> + { 1, 2, 2 }, { 1, 3, 0 }, { 1, 4, -2 }, { 2, 4, -4 },
> + { 3, 4, -6 }, { 3, 5, -8 }, { 4, 6, -10 }, { 5, 7, -10 },
> + { 5, 8, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(15), 10,
> + /* 15BPP/10BPC */
> + { 273, 15, 2048, 7, 16, 15, 15, {
> + { 0, 2, 10 }, { 2, 5, 8 }, { 3, 5, 6 }, { 4, 6, 4 },
> + { 5, 6, 2 }, { 5, 7, 0 }, { 5, 8, -2 }, { 6, 8, -4 },
> + { 7, 8, -6 }, { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 },
> + { 9, 12, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> +},
> +{ DSC_BPP(15), 12,
> + /* 15BPP/12BPC */
> + { 273, 15, 2048, 11, 20, 19, 19, {
> + { 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
> + { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 },
> + { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
> + { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> +},
> { /* sentinel */ }
> };
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 05/10] drm/display/dsc: use flat array for rc_parameters lookup
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> Next commits are going to add support for additional RC parameter lookup
> tables. These tables are going to use different bpp/bpc combinations,
> thus it makes little sense to keep the 2d array for RC parameters.
> Switch to using the flat array.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 188 +++
> 1 file changed, 88 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index deaa84722bd4..a6d11f474656 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -307,24 +307,6 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config
> *vdsc_cfg)
> }
> EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
>
> -enum ROW_INDEX_BPP {
> - ROW_INDEX_6BPP = 0,
> - ROW_INDEX_8BPP,
> - ROW_INDEX_10BPP,
> - ROW_INDEX_12BPP,
> - ROW_INDEX_15BPP,
> - MAX_ROW_INDEX
> -};
> -
> -enum COLUMN_INDEX_BPC {
> - COLUMN_INDEX_8BPC = 0,
> - COLUMN_INDEX_10BPC,
> - COLUMN_INDEX_12BPC,
> - COLUMN_INDEX_14BPC,
> - COLUMN_INDEX_16BPC,
> - MAX_COLUMN_INDEX
> -};
> -
> struct rc_parameters {
> u16 initial_xmit_delay;
> u8 first_line_bpg_offset;
> @@ -336,12 +318,20 @@ struct rc_parameters {
> struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> };
>
> +struct rc_parameters_data {
> + u8 bpp;
> + u8 bpc;
> + struct rc_parameters params;
> +};
> +
> +#define DSC_BPP(bpp) ((bpp) << 4)
> +
> /*
> * Selected Rate Control Related Parameter Recommended Values
> * from DSC_v1.11 spec & C Model release: DSC_model_20161212
> */
> -static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
> -{
> +static const struct rc_parameters_data rc_parameters[] = {
> +{ DSC_BPP(6), 8,
I was kind of hoping for a patch that would clean up the hideous
indentation in the tables. Please at least let's not add more with the
one space indent?
> /* 6BPP/8BPC */
With designated initializers I think we could just toss the comments
out.
.bpp = DSC_BPP(6), .bpc = 8,
With that,
Reviewed-by: Jani Nikula
> { 768, 15, 6144, 3, 13, 11, 11, {
> { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
> @@ -349,7 +339,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 12, -12 },
> { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
> }
> - },
> + }
> +},
> +{ DSC_BPP(6), 10,
> /* 6BPP/10BPC */
> { 768, 15, 6144, 7, 17, 15, 15, {
> { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 },
> @@ -358,7 +350,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
> { 17, 18, -12 }
> }
> - },
> + }
> +},
> +{ DSC_BPP(6), 12,
> /* 6BPP/12BPC */
> { 768, 15, 6144, 11, 21, 19, 19, {
> { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, -4 },
> @@ -367,7 +361,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
> { 21, 22, -12 }
> }
> - },
> + }
> +},
> +{ DSC_BPP(6), 14,
> /* 6BPP/14BPC */
> { 768, 15, 6144, 15, 25, 23, 23, {
> { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
> @@ -376,7 +372,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
> { 25, 26, -12 }
> }
> - },
> + }
> +},
> +{ DSC_BPP(6), 16,
> /* 6BPP/16BPC */
> { 768, 15, 6144, 19, 29, 27, 27, {
> { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, -4 },
> @@ -385,9 +383,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
> { 29, 30, -12 }
> }
> - },
> + }
> },
> -{
> +{ DSC_BPP(8), 8,
> /* 8BPP/8BPC */
> { 512, 12, 6144, 3, 12, 11, 11, {
> { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> @@ -395,7 +393,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
> { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> }
> - },
> + }
> +},
> +{ DSC_BPP(8), 10,
> /* 8BPP/10BPC */
> { 512, 12, 6144, 7, 16, 15, 15, {
> /*
> @@ -407,7 +407,9 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, {
Re: [Intel-gfx] [PATCH 04/10] drm/i915/dsc: stop using interim structure for calculated params
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> Stop using an interim structure rc_parameters for storing calculated
> params and then setting drm_dsc_config using that structure. Instead put
> calculated params into the struct drm_dsc_config directly.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 89 +--
> 1 file changed, 20 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index d5a7e9494b23..1ee8d13c9d64 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -18,17 +18,6 @@
> #include "intel_qp_tables.h"
> #include "intel_vdsc.h"
>
> -struct rc_parameters {
> - u16 initial_xmit_delay;
> - u8 first_line_bpg_offset;
> - u16 initial_offset;
> - u8 flatness_min_qp;
> - u8 flatness_max_qp;
> - u8 rc_quant_incr_limit0;
> - u8 rc_quant_incr_limit1;
> - struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> -};
> -
> bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
> {
> const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -63,8 +52,7 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum
> transcoder cpu_transcoder)
> }
>
> static void
> -calculate_rc_params(struct rc_parameters *rc,
> - struct drm_dsc_config *vdsc_cfg)
> +calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
> {
> int bpc = vdsc_cfg->bits_per_component;
> int bpp = vdsc_cfg->bits_per_pixel >> 4;
> @@ -84,54 +72,54 @@ calculate_rc_params(struct rc_parameters *rc,
> u32 res, buf_i, bpp_i;
>
> if (vdsc_cfg->slice_height >= 8)
> - rc->first_line_bpg_offset =
> + vdsc_cfg->first_line_bpg_offset =
> 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height -
> 8)), 100);
> else
> - rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
> + vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height -
> 1);
>
> /* Our hw supports only 444 modes as of today */
> if (bpp >= 12)
> - rc->initial_offset = 2048;
> + vdsc_cfg->initial_offset = 2048;
> else if (bpp >= 10)
> - rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584),
> 2);
> + vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) *
> 3584), 2);
> else if (bpp >= 8)
> - rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
> + vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) *
> 512), 2);
> else
> - rc->initial_offset = 6144;
> + vdsc_cfg->initial_offset = 6144;
>
> /* initial_xmit_delay = rc_model_size/2/compression_bpp */
> - rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
> + vdsc_cfg->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2
> * bpp);
>
> - rc->flatness_min_qp = 3 + qp_bpc_modifier;
> - rc->flatness_max_qp = 12 + qp_bpc_modifier;
> + vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
> + vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
>
> - rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
> - rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
> + vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
> + vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
>
> bpp_i = (2 * (bpp - 6));
> for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
> /* Read range_minqp and range_max_qp from qp tables */
> - rc->rc_range_params[buf_i].range_min_qp =
> + vdsc_cfg->rc_range_params[buf_i].range_min_qp =
> intel_lookup_range_min_qp(bpc, buf_i, bpp_i);
> - rc->rc_range_params[buf_i].range_max_qp =
> + vdsc_cfg->rc_range_params[buf_i].range_max_qp =
> intel_lookup_range_max_qp(bpc, buf_i, bpp_i);
>
> /* Calculate range_bgp_offset */
> if (bpp <= 6) {
> - rc->rc_range_params[buf_i].range_bpg_offset =
> ofs_und6[buf_i];
> + vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
> ofs_und6[buf_i];
> } else if (bpp <= 8) {
> res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] -
> ofs_und6[buf_i])), 2);
> - rc->rc_range_params[buf_i].range_bpg_offset =
> + vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
> ofs_und6[buf_i]
> + res;
> } else if (bpp <= 12) {
> - rc->rc_range_params[buf_i].range_bpg_offset =
> + vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
>
Re: [Intel-gfx] [PATCH 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> This moves DSC RC tables to DRM DSC helper. No additional code changes
> and/or cleanups are a part of this commit, it will be cleaned up in the
> followup commits.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 364 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c | 319 +--
> include/drm/display/drm_dsc_helper.h | 1 +
> 3 files changed, 372 insertions(+), 312 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index ab8679c158b5..deaa84722bd4 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -307,6 +307,370 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config
> *vdsc_cfg)
> }
> EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
>
> +enum ROW_INDEX_BPP {
> + ROW_INDEX_6BPP = 0,
> + ROW_INDEX_8BPP,
> + ROW_INDEX_10BPP,
> + ROW_INDEX_12BPP,
> + ROW_INDEX_15BPP,
> + MAX_ROW_INDEX
> +};
> +
> +enum COLUMN_INDEX_BPC {
> + COLUMN_INDEX_8BPC = 0,
> + COLUMN_INDEX_10BPC,
> + COLUMN_INDEX_12BPC,
> + COLUMN_INDEX_14BPC,
> + COLUMN_INDEX_16BPC,
> + MAX_COLUMN_INDEX
> +};
> +
> +struct rc_parameters {
> + u16 initial_xmit_delay;
> + u8 first_line_bpg_offset;
> + u16 initial_offset;
> + u8 flatness_min_qp;
> + u8 flatness_max_qp;
> + u8 rc_quant_incr_limit0;
> + u8 rc_quant_incr_limit1;
> + struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
> +};
> +
> +/*
> + * Selected Rate Control Related Parameter Recommended Values
> + * from DSC_v1.11 spec & C Model release: DSC_model_20161212
> + */
> +static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
> +{
> + /* 6BPP/8BPC */
> + { 768, 15, 6144, 3, 13, 11, 11, {
> + { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
> + { 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
> + { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 12, -12 },
> + { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
> + }
> + },
> + /* 6BPP/10BPC */
> + { 768, 15, 6144, 7, 17, 15, 15, {
> + { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 },
> + { 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, -8 },
> + { 11, 15, -8 }, { 12, 16, -10 }, { 13, 16, -10 },
> + { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
> + { 17, 18, -12 }
> + }
> + },
> + /* 6BPP/12BPC */
> + { 768, 15, 6144, 11, 21, 19, 19, {
> + { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, -4 },
> + { 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 18, -8 },
> + { 15, 19, -8 }, { 16, 20, -10 }, { 17, 20, -10 },
> + { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
> + { 21, 22, -12 }
> + }
> + },
> + /* 6BPP/14BPC */
> + { 768, 15, 6144, 15, 25, 23, 23, {
> + { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
> + { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
> + { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
> + { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
> + { 25, 26, -12 }
> + }
> + },
> + /* 6BPP/16BPC */
> + { 768, 15, 6144, 19, 29, 27, 27, {
> + { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, -4 },
> + { 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 26, -8 },
> + { 23, 27, -8 }, { 24, 28, -10 }, { 25, 28, -10 },
> + { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
> + { 29, 30, -12 }
> + }
> + },
> +},
> +{
> + /* 8BPP/8BPC */
> + { 512, 12, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
> + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + },
> + /* 8BPP/10BPC */
> + { 512, 12, 6144, 7, 16, 15, 15, {
> + /*
> + * DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
> + * VESA DSC 1.1 Table E-5 sets it to 4.
> + */
> + { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + },
> + /* 8BPP/12BPC */
> + { 512, 12, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> +
Re: [Intel-gfx] [PATCH 01/10] drm/i915/dsc: change DSC param tables to follow the DSC model
On 28/02/2023 17:56, Jani Nikula wrote:
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.
Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
the table in the VESA DSC 1.1 sets it to 4.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 207b2a648d32..d080741fd0b3 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -86,7 +86,7 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
}
},
/* 6BPP/14BPC */
- { 768, 15, 6144, 15, 25, 23, 27, {
+ { 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
{ 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
@@ -115,6 +115,10 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
{ 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
@@ -132,7 +136,7 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/14BPC */
{ 512, 12, 6144, 15, 24, 23, 23, {
- { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+ { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
{ 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
{ 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
{ 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
@@ -529,6 +533,16 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
DSC_RANGE_BPG_OFFSET_MASK;
}
+ if (DISPLAY_VER(dev_priv) < 13) {
+ if (compressed_bpp == 6 &&
+ vdsc_cfg->bits_per_component == 8)
+ vdsc_cfg->rc_quant_incr_limit1 = 23;
+
+ if (compressed_bpp == 8 &&
+ vdsc_cfg->bits_per_component == 14)
+ vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
+ }
+
I wonder if we shouldn't just use the updated values...
I also wondered about this, so I wanted to get a double check from
somebody having better knowledge of this part, if it is a typo in the
original patch or a typo in the cfg files.
E.g. the pre_scr_cfg_files_for_reference/rc_10bpc_8bpp.cfg has 8 as
RX_MAXQP[0], which (for me) looks like a typo in the CFG file itself,
rather than being a typo in the driver.
On the other hand, these two issues belong to the 'current' CFG files,
so they, most probably, received more attention from anybody working
with the standard and with the model.
I can change this patch to become a fix for the tables (dropping the if
clause), if you can confirm that these values are typos in the driver.
Maybe add a FIXME comment above the block to consider removing it?
Reviewed-by: Jani Nikula
/*
* BitsPerComponent value determines mux_word_size:
* When BitsPerComponent is less than or 10bpc, muxWordSize will be
equal to
--
With best wishes
Dmitry
Re: [Intel-gfx] [PATCH 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> The rc_buf_thresh values are common to all DSC implementations. Move
> them to the common helper together with the code to propagage them to
> the drm_dsc_config.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 37 +++
> drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +--
> include/drm/display/drm_dsc_helper.h | 1 +
> 3 files changed, 39 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index c869c6e51e2b..ab8679c158b5 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -270,6 +270,43 @@ void drm_dsc_pps_payload_pack(struct
> drm_dsc_picture_parameter_set *pps_payload,
> }
> EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
>
> +/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
> +const u16 drm_dsc_rc_buf_thresh[] = {
> + 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> + 7744, 7872, 8000, 8064
> +};
> +EXPORT_SYMBOL(drm_dsc_rc_buf_thresh);
> +
> +/**
> + * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
> + * in accordance with the DSC 1.2 specification.
> + *
> + * @vdsc_cfg: DSC Configuration data partially filled by driver
> + */
> +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
> +{
> + int i = 0;
> +
> + for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
> + /*
> + * six 0s are appended to the lsb of each threshold value
> + * internally in h/w.
> + * Only 8 bits are allowed for programming RcBufThreshold
> + */
Not sure how appropriate the hardware references are, maybe clean it up
a bit.
With that, and +static and -export mentioned earlier,
Reviewed-by: Jani Nikula
> + vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
> + }
> +
> + /*
> + * For 6bpp, RC Buffer threshold 12 and 13 need a different value
> + * as per C Model
> + */
> + if (vdsc_cfg->bits_per_pixel == 6 << 4) {
> + vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
> + vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
> + }
> +}
> +EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
> +
> /**
> * drm_dsc_compute_rc_parameters() - Write rate control
> * parameters to the dsc configuration defined in
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index d080741fd0b3..b4faab4c8fb3 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
> MAX_COLUMN_INDEX
> };
>
> -/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
> -static const u16 rc_buf_thresh[] = {
> - 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> - 7744, 7872, 8000, 8064
> -};
> -
> struct rc_parameters {
> u16 initial_xmit_delay;
> u8 first_line_bpg_offset;
> @@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
> vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
>
> - for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
> - /*
> - * six 0s are appended to the lsb of each threshold value
> - * internally in h/w.
> - * Only 8 bits are allowed for programming RcBufThreshold
> - */
> - vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
> - }
> -
> - /*
> - * For 6bpp, RC Buffer threshold 12 and 13 need a different value
> - * as per C Model
> - */
> - if (compressed_bpp == 6) {
> - vdsc_cfg->rc_buf_thresh[12] = 0x7C;
> - vdsc_cfg->rc_buf_thresh[13] = 0x7D;
> - }
> + drm_dsc_set_rc_buf_thresh(vdsc_cfg);
>
> /*
>* From XE_LPD onwards we supports compression bpps in steps of 1
> diff --git a/include/drm/display/drm_dsc_helper.h
> b/include/drm/display/drm_dsc_helper.h
> index 8b41edbbabab..706ba1d34742 100644
> --- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
> *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to reservation lock"
> -Original Message- > From: Intel-gfx On Behalf Of Thomas > Zimmermann > Sent: tiistai 28. helmikuuta 2023 17.46 > To: Dmitry Osipenko ; > maarten.lankho...@linux.intel.com; airl...@gmail.com; dan...@ffwll.ch; Nikula, > Jani > Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to > reservation lock" > > Hi > > Am 28.02.23 um 16:28 schrieb Dmitry Osipenko: > > On 2/28/23 18:26, Thomas Zimmermann wrote: > >> This reverts commit 67b7836d4458790f1261e31fe0ce3250989784f0. > >> > >> The locking appears incomplete. A caller of SHMEM helper's pin > >> function never acquires the dma-buf reservation lock. So we get > >> > >>WARNING: CPU: 3 PID: 967 at > >> drivers/gpu/drm/drm_gem_shmem_helper.c:243 > >> drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper] > >> > >> Signed-off-by: Thomas Zimmermann > >> --- > > > > Thanks Thomas, > > > > Acked-by: Dmitry Osipenko > > > > Thanks, merged now. I hope this fixes the immediate issues. According to pre-merge results: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/index.html? So should fix. > > Best regards > Thomas > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH 01/10] drm/i915/dsc: change DSC param tables to follow the DSC model
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> After cross-checking DSC models (20150914, 20161212, 20210623) change
> values in rc_parameters tables to follow config files present inside
> the DSC model. Handle two places, where i915 tables diverged from the
> model, by patching the rc values in the code.
>
> Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
> the table in the VESA DSC 1.1 sets it to 4.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 207b2a648d32..d080741fd0b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -86,7 +86,7 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> }
> },
> /* 6BPP/14BPC */
> - { 768, 15, 6144, 15, 25, 23, 27, {
> + { 768, 15, 6144, 15, 25, 23, 23, {
> { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
> { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
> { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
> @@ -115,6 +115,10 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> },
> /* 8BPP/10BPC */
> { 512, 12, 6144, 7, 16, 15, 15, {
> + /*
> + * DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
> + * VESA DSC 1.1 Table E-5 sets it to 4.
> + */
> { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
> { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
> @@ -132,7 +136,7 @@ static const struct rc_parameters
> rc_parameters[][MAX_COLUMN_INDEX] = {
> },
> /* 8BPP/14BPC */
> { 512, 12, 6144, 15, 24, 23, 23, {
> - { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
> + { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
> { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
> { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
> { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
> @@ -529,6 +533,16 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
> DSC_RANGE_BPG_OFFSET_MASK;
> }
>
> + if (DISPLAY_VER(dev_priv) < 13) {
> + if (compressed_bpp == 6 &&
> + vdsc_cfg->bits_per_component == 8)
> + vdsc_cfg->rc_quant_incr_limit1 = 23;
> +
> + if (compressed_bpp == 8 &&
> + vdsc_cfg->bits_per_component == 14)
> + vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
> + }
> +
I wonder if we shouldn't just use the updated values...
Maybe add a FIXME comment above the block to consider removing it?
Reviewed-by: Jani Nikula
> /*
>* BitsPerComponent value determines mux_word_size:
>* When BitsPerComponent is less than or 10bpc, muxWordSize will be
> equal to
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/shmem-helper: Switch to reservation lock"
== Series Details == Series: Revert "drm/shmem-helper: Switch to reservation lock" URL : https://patchwork.freedesktop.org/series/114478/ State : success == Summary == CI Bug Log - changes from CI_DRM_12790 -> Patchwork_114478v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/index.html Participating hosts (2 -> 36) -- Additional (35): fi-rkl-11600 bat-dg1-6 bat-dg1-5 bat-adlp-6 fi-apl-guc fi-pnv-d510 bat-rpls-1 fi-blb-e6850 bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-ilk-650 fi-hsw-4770 bat-adln-1 fi-ivb-3770 bat-jsl-3 bat-rplp-1 fi-elk-e7500 bat-dg2-11 fi-bsw-nick fi-kbl-7567u bat-dg1-7 bat-adlp-9 fi-skl-guc fi-cfl-8700k fi-glk-j4005 bat-jsl-1 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc fi-kbl-x1275 fi-cfl-8109u Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114478v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-2: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html - bat-adlp-9: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-adlp-9/igt@debugfs_t...@basic-hwmon.html - bat-adlp-6: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html - bat-rplp-1: NOTRUN -> [SKIP][4] ([i915#7456]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-rplp-1/igt@debugfs_t...@basic-hwmon.html - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#7456]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html - bat-jsl-3: NOTRUN -> [SKIP][6] ([i915#7456]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-jsl-3/igt@debugfs_t...@basic-hwmon.html - bat-adln-1: NOTRUN -> [SKIP][7] ([i915#7456]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-adln-1/igt@debugfs_t...@basic-hwmon.html - bat-adlm-1: NOTRUN -> [SKIP][8] ([i915#7456]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][9] ([i915#7456]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][10] ([i915#7456]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html - bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#7456]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-rpls-1/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@eof: - bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#2582]) +4 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-adlm-1/igt@fb...@eof.html * igt@fbdev@read: - bat-rpls-2: NOTRUN -> [SKIP][13] ([i915#2582]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-rpls-2/igt@fb...@read.html * igt@fbdev@write: - bat-rpls-1: NOTRUN -> [SKIP][14] ([i915#2582]) +4 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-rpls-1/igt@fb...@write.html - bat-dg1-7: NOTRUN -> [SKIP][15] ([i915#2582]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-dg1-7/igt@fb...@write.html * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: NOTRUN -> [ABORT][16] ([i915#6687] / [i915#7978]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html - fi-kbl-7567u: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/fi-kbl-7567u/igt@gem_huc_c...@huc-copy.html - fi-tgl-1115g4: NOTRUN -> [SKIP][19] ([i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/fi-tgl-1115g4/igt@gem_huc_c...@huc-copy.html - bat-jsl-1: NOTRUN -> [SKIP][20] ([i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114478v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#2190]) [21]:
Re: [Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to reservation lock"
Hi Am 28.02.23 um 16:28 schrieb Dmitry Osipenko: On 2/28/23 18:26, Thomas Zimmermann wrote: This reverts commit 67b7836d4458790f1261e31fe0ce3250989784f0. The locking appears incomplete. A caller of SHMEM helper's pin function never acquires the dma-buf reservation lock. So we get WARNING: CPU: 3 PID: 967 at drivers/gpu/drm/drm_gem_shmem_helper.c:243 drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper] Signed-off-by: Thomas Zimmermann --- Thanks Thomas, Acked-by: Dmitry Osipenko Thanks, merged now. I hope this fixes the immediate issues. Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH v7 00/15] dma-fence: Deadline awareness
On Tue, Feb 28, 2023 at 4:43 AM Bagas Sanjaya wrote: > > On Mon, Feb 27, 2023 at 11:35:06AM -0800, Rob Clark wrote: > > From: Rob Clark > > > > This series adds a deadline hint to fences, so realtime deadlines > > such as vblank can be communicated to the fence signaller for power/ > > frequency management decisions. > > > > This is partially inspired by a trick i915 does, but implemented > > via dma-fence for a couple of reasons: > > > > 1) To continue to be able to use the atomic helpers > > 2) To support cases where display and gpu are different drivers > > > > This iteration adds a dma-fence ioctl to set a deadline (both to > > support igt-tests, and compositors which delay decisions about which > > client buffer to display), and a sw_sync ioctl to read back the > > deadline. IGT tests utilizing these can be found at: > > > > > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > > > > > v1: https://patchwork.freedesktop.org/series/93035/ > > v2: Move filtering out of later deadlines to fence implementation > > to avoid increasing the size of dma_fence > > v3: Add support in fence-array and fence-chain; Add some uabi to > > support igt tests and userspace compositors. > > v4: Rebase, address various comments, and add syncobj deadline > > support, and sync_file EPOLLPRI based on experience with perf/ > > freq issues with clvk compute workloads on i915 (anv) > > v5: Clarify that this is a hint as opposed to a more hard deadline > > guarantee, switch to using u64 ns values in UABI (still absolute > > CLOCK_MONOTONIC values), drop syncobj related cap and driver > > feature flag in favor of allowing count_handles==0 for probing > > kernel support. > > v6: Re-work vblank helper to calculate time of _start_ of vblank, > > and work correctly if the last vblank event was more than a > > frame ago. Add (mostly unrelated) drm/msm patch which also > > uses the vblank helper. Use dma_fence_chain_contained(). More > > verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > v7: Fix kbuild complaints about vblank helper. Add more docs. > > > > I want to apply this series for testing, but it can't be applied cleanly > on current drm-misc tree. On what tree (and commit) is this series based > on? You can find my branch here: https://gitlab.freedesktop.org/robclark/msm/-/commits/dma-fence/deadline BR, -R
Re: [Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to reservation lock"
On 2/28/23 18:26, Thomas Zimmermann wrote: > This reverts commit 67b7836d4458790f1261e31fe0ce3250989784f0. > > The locking appears incomplete. A caller of SHMEM helper's pin > function never acquires the dma-buf reservation lock. So we get > > WARNING: CPU: 3 PID: 967 at drivers/gpu/drm/drm_gem_shmem_helper.c:243 > drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper] > > Signed-off-by: Thomas Zimmermann > --- Thanks Thomas, Acked-by: Dmitry Osipenko -- Best regards, Dmitry
[Intel-gfx] [PATCH] Revert "drm/shmem-helper: Switch to reservation lock"
This reverts commit 67b7836d4458790f1261e31fe0ce3250989784f0.
The locking appears incomplete. A caller of SHMEM helper's pin
function never acquires the dma-buf reservation lock. So we get
WARNING: CPU: 3 PID: 967 at drivers/gpu/drm/drm_gem_shmem_helper.c:243
drm_gem_shmem_pin+0x42/0x90 [drm_shmem_helper]
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c| 185 +++---
drivers/gpu/drm/lima/lima_gem.c | 8 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 7 +-
.../gpu/drm/panfrost/panfrost_gem_shrinker.c | 6 +-
drivers/gpu/drm/panfrost/panfrost_mmu.c | 19 +-
include/drm/drm_gem_shmem_helper.h| 14 +-
6 files changed, 148 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 3d43e5961573..f75e50273d7a 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -88,6 +88,8 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size,
bool private)
if (ret)
goto err_release;
+ mutex_init(>pages_lock);
+ mutex_init(>vmap_lock);
INIT_LIST_HEAD(>madv_list);
if (!private) {
@@ -139,13 +141,11 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
*shmem)
{
struct drm_gem_object *obj = >base;
+ drm_WARN_ON(obj->dev, shmem->vmap_use_count);
+
if (obj->import_attach) {
drm_prime_gem_destroy(obj, shmem->sgt);
} else {
- dma_resv_lock(shmem->base.resv, NULL);
-
- drm_WARN_ON(obj->dev, shmem->vmap_use_count);
-
if (shmem->sgt) {
dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
DMA_BIDIRECTIONAL, 0);
@@ -154,18 +154,18 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
*shmem)
}
if (shmem->pages)
drm_gem_shmem_put_pages(shmem);
-
- drm_WARN_ON(obj->dev, shmem->pages_use_count);
-
- dma_resv_unlock(shmem->base.resv);
}
+ drm_WARN_ON(obj->dev, shmem->pages_use_count);
+
drm_gem_object_release(obj);
+ mutex_destroy(>pages_lock);
+ mutex_destroy(>vmap_lock);
kfree(shmem);
}
EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
-static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
+static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
struct page **pages;
@@ -197,16 +197,35 @@ static int drm_gem_shmem_get_pages(struct
drm_gem_shmem_object *shmem)
}
/*
- * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a
shmem GEM object
+ * drm_gem_shmem_get_pages - Allocate backing pages for a shmem GEM object
* @shmem: shmem GEM object
*
- * This function decreases the use count and puts the backing pages when use
drops to zero.
+ * This function makes sure that backing pages exists for the shmem GEM object
+ * and increases the use count.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
*/
-void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
+int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
+ int ret;
- dma_resv_assert_held(shmem->base.resv);
+ drm_WARN_ON(obj->dev, obj->import_attach);
+
+ ret = mutex_lock_interruptible(>pages_lock);
+ if (ret)
+ return ret;
+ ret = drm_gem_shmem_get_pages_locked(shmem);
+ mutex_unlock(>pages_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_shmem_get_pages);
+
+static void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem)
+{
+ struct drm_gem_object *obj = >base;
if (drm_WARN_ON_ONCE(obj->dev, !shmem->pages_use_count))
return;
@@ -224,6 +243,19 @@ void drm_gem_shmem_put_pages(struct drm_gem_shmem_object
*shmem)
shmem->pages_mark_accessed_on_put);
shmem->pages = NULL;
}
+
+/*
+ * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a
shmem GEM object
+ * @shmem: shmem GEM object
+ *
+ * This function decreases the use count and puts the backing pages when use
drops to zero.
+ */
+void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
+{
+ mutex_lock(>pages_lock);
+ drm_gem_shmem_put_pages_locked(shmem);
+ mutex_unlock(>pages_lock);
+}
EXPORT_SYMBOL(drm_gem_shmem_put_pages);
/**
@@ -240,8 +272,6 @@ int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem)
{
struct drm_gem_object *obj = >base;
- dma_resv_assert_held(shmem->base.resv);
-
drm_WARN_ON(obj->dev, obj->import_attach);
return drm_gem_shmem_get_pages(shmem);
@@ -259,31 +289,14 @@ void drm_gem_shmem_unpin(struct drm_gem_shmem_object
*shmem)
{
Re: [Intel-gfx] [PATCH 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm/drm-next v6.2]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-i915-dsc-change-DSC-param-tables-to-follow-the-DSC-model/20230228-193505
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230228113342.2051425-4-dmitry.baryshkov%40linaro.org
patch subject: [PATCH 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper
config: x86_64-randconfig-a002-20230227
(https://download.01.org/0day-ci/archive/20230228/202302282241.qrmajdx8-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/ee048cb6c2ec7f7f92bea6b72e8cd3ef9921993e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Dmitry-Baryshkov/drm-i915-dsc-change-DSC-param-tables-to-follow-the-DSC-model/20230228-193505
git checkout ee048cb6c2ec7f7f92bea6b72e8cd3ef9921993e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/display/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202302282241.qrmajdx8-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/display/drm_dsc_helper.c:635: warning: expecting prototype
>> for drm_dsc_compute_rc_parameters(). Prototype was for
>> drm_dsc_setup_rc_params() instead
vim +635 drivers/gpu/drm/display/drm_dsc_helper.c
627
628 /**
629 * drm_dsc_compute_rc_parameters() - Set parameters and limits for RC
model in
630 * accordance with the DSC 1.1 or 1.2 specification and DSC C Model
631 *
632 * @vdsc_cfg: DSC Configuration data partially filled by driver
633 */
634 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg)
> 635 {
636 const struct rc_parameters *rc_params;
637 int i;
638
639 /* fractional BPP is not supported */
640 if (vdsc_cfg->bits_per_pixel & 0xf)
641 return -EINVAL;
642
643 rc_params = get_rc_params(vdsc_cfg->bits_per_pixel >> 4,
644vdsc_cfg->bits_per_component);
645 if (!rc_params)
646 return -EINVAL;
647
648 vdsc_cfg->first_line_bpg_offset =
rc_params->first_line_bpg_offset;
649 vdsc_cfg->initial_xmit_delay = rc_params->initial_xmit_delay;
650 vdsc_cfg->initial_offset = rc_params->initial_offset;
651 vdsc_cfg->flatness_min_qp = rc_params->flatness_min_qp;
652 vdsc_cfg->flatness_max_qp = rc_params->flatness_max_qp;
653 vdsc_cfg->rc_quant_incr_limit0 =
rc_params->rc_quant_incr_limit0;
654 vdsc_cfg->rc_quant_incr_limit1 =
rc_params->rc_quant_incr_limit1;
655
656 for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
657 vdsc_cfg->rc_range_params[i].range_min_qp =
658 rc_params->rc_range_params[i].range_min_qp;
659 vdsc_cfg->rc_range_params[i].range_max_qp =
660 rc_params->rc_range_params[i].range_max_qp;
661 /*
662 * Range BPG Offset uses 2's complement and is only a 6
bits. So
663 * mask it to get only 6 bits.
664 */
665 vdsc_cfg->rc_range_params[i].range_bpg_offset =
666 rc_params->rc_range_params[i].range_bpg_offset &
667 DSC_RANGE_BPG_OFFSET_MASK;
668 }
669
670 return 0;
671 }
672 EXPORT_SYMBOL(drm_dsc_setup_rc_params);
673
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
Hi,
> > >> >> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
> > >> >> > lock") removes the drm_gem_shmem_get_pages_locked() and
> > >> >> > drm_gem_shmem_put_pages_locked().
> > >> >> >
> > >> >> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
> > >> >> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
> > >> >> >
> > >> >> > Somehow these two commits got mixed up and produce the following
> > >> >> > compile error:
> > >> >>
> > >> >> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a
> > >> >> bad merge conflict resolution in drm-tip that was fixed yesterday,
> > >> >> there is no problem in misc-next. Where do you see this error?
> > >> >
> > >> > yes, indeed! I was indeed surprised to see this mismatch.
> > >> >
> > >> > I see it in the Intel's drm-tip branch[*]
> > >>
> > >> To set the record straight, drm-tip isn't Intel's, it's an
> > >> integration branch shared by the drm community.
> > >
> > > yes of course... it's a matter of fast writing :)
> > >
> > >> Looks like the same bad merge resolution has resurrected itself
> > >> somehow, maybe Thomas'
> > >>
> > >> commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
> > >> Author: Thomas Zimmermann
> > >> Date: Tue Feb 28 10:03:24 2023 +0100
> > >>
> > >> 2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
> > >>
> > >> git version 2.39.2
> > >>
> > >> in drm-rerere brought it back.
> > >>
> > >> And the build is indeed currently broken.
> > >>
> > >> Moreover, when the build was fine for a while, apparently the changes
> > >> in shmem broke a bunch of machines in Intel CI. And due to this, we
> > >> aren't getting any CI results for incoming patches right now.
> > >
> > > Is there any plans for fixing it?
> >
> > Someone(tm) needs to step up and do it. Personally, I'm clueless.
yeah... I think we either need to fix the rerere branch (which,
allow me, is like talking to an angry wife without knowing why
she's angry) or just take my patch and have it fixed right away
(with some bisect broken in between, I guess).
I don't know what's the best approach and in any case I don't
have the power to fix it (let me know, in any case, if I can
help).
> > The whole thing is made worse by the conflict and the various resolutions.
> > At this
> > time, I'm not certain whether the whole thing was broken to begin with, or
> > if it's
> > just the conflict resolution that caused the issues.
> >
> > I'll just note that for future reference, Cc'ing intel-gfx for anything
> > non-trivial
> > touching the guts of drm will be useful for running CI on our test farm
> > pre-merge.
> > Now, we don't know.
Yes, fully agree!
Andi
> Yeah, and sad story can be seen from
> https://intel-gfx-ci.01.org/tree/drm-tip/index.html? .
> All systems now abort on BAT run.
> Just to pick one:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/fi-tgl-1115g4/igt@gem_exec_fence@basic-b...@vecs0.html
> Please fix asap. Or revert from tree asap.
>
> >
> >
> > BR,
> > Jani.
> >
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
On 2/28/23 17:40, Jani Nikula wrote: ... >>> And the build is indeed currently broken. >>> >>> Moreover, when the build was fine for a while, apparently the changes in >>> shmem broke a bunch of machines in Intel CI. And due to this, we aren't >>> getting any CI results for incoming patches right now. >> >> Is there any plans for fixing it? > > Someone(tm) needs to step up and do it. Personally, I'm clueless. > > The whole thing is made worse by the conflict and the various > resolutions. At this time, I'm not certain whether the whole thing was > broken to begin with, or if it's just the conflict resolution that > caused the issues. > > I'll just note that for future reference, Cc'ing intel-gfx for anything > non-trivial touching the guts of drm will be useful for running CI on > our test farm pre-merge. Now, we don't know. Apparently, there is a missing lock for dma-buf vgem (and probably some other similar drivers) exporting code path that I missed before. I've reproduced the IGT warning locally and looking into fixing it. Will keep updating you on it. Thanks for reporting it! -- Best regards, Dmitry
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
Hi,
> -Original Message-
> From: Nikula, Jani
> Sent: tiistai 28. helmikuuta 2023 16.40
> To: Andi Shyti
> Cc: Andi Shyti ; Dmitry Osipenko
> ; dri-de...@lists.freedesktop.org; Maarten
> Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ; David
> Airlie ; Daniel Vetter ; Javier Martinez
> Canillas ; Asahi Lina ; Andi Shyti
> ; Intel GFX ; Tvrtko
> Ursulin
> ; Vivi, Rodrigo ;
> Joonas
> Lahtinen ; Saarinen, Jani
>
> Subject: Re: [PATCH] drm/shmem-helper: Fix compile error
>
> On Tue, 28 Feb 2023, Andi Shyti wrote:
> > Hi,
> >
> >> >> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
> >> >> > lock") removes the drm_gem_shmem_get_pages_locked() and
> >> >> > drm_gem_shmem_put_pages_locked().
> >> >> >
> >> >> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
> >> >> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
> >> >> >
> >> >> > Somehow these two commits got mixed up and produce the following
> >> >> > compile error:
> >> >>
> >> >> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a
> >> >> bad merge conflict resolution in drm-tip that was fixed yesterday,
> >> >> there is no problem in misc-next. Where do you see this error?
> >> >
> >> > yes, indeed! I was indeed surprised to see this mismatch.
> >> >
> >> > I see it in the Intel's drm-tip branch[*]
> >>
> >> To set the record straight, drm-tip isn't Intel's, it's an
> >> integration branch shared by the drm community.
> >
> > yes of course... it's a matter of fast writing :)
> >
> >> Looks like the same bad merge resolution has resurrected itself
> >> somehow, maybe Thomas'
> >>
> >> commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
> >> Author: Thomas Zimmermann
> >> Date: Tue Feb 28 10:03:24 2023 +0100
> >>
> >> 2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
> >>
> >> git version 2.39.2
> >>
> >> in drm-rerere brought it back.
> >>
> >> And the build is indeed currently broken.
> >>
> >> Moreover, when the build was fine for a while, apparently the changes
> >> in shmem broke a bunch of machines in Intel CI. And due to this, we
> >> aren't getting any CI results for incoming patches right now.
> >
> > Is there any plans for fixing it?
>
> Someone(tm) needs to step up and do it. Personally, I'm clueless.
>
> The whole thing is made worse by the conflict and the various resolutions. At
> this
> time, I'm not certain whether the whole thing was broken to begin with, or if
> it's
> just the conflict resolution that caused the issues.
>
> I'll just note that for future reference, Cc'ing intel-gfx for anything
> non-trivial
> touching the guts of drm will be useful for running CI on our test farm
> pre-merge.
> Now, we don't know.
Yeah, and sad story can be seen from
https://intel-gfx-ci.01.org/tree/drm-tip/index.html? .
All systems now abort on BAT run.
Just to pick one:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/fi-tgl-1115g4/igt@gem_exec_fence@basic-b...@vecs0.html
Please fix asap. Or revert from tree asap.
>
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper
Hi Dmitry,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm/drm-next linus/master v6.2 next-20230228]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-i915-dsc-change-DSC-param-tables-to-follow-the-DSC-model/20230228-193505
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230228113342.2051425-4-dmitry.baryshkov%40linaro.org
patch subject: [PATCH 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper
config: ia64-allyesconfig
(https://download.01.org/0day-ci/archive/20230228/202302282203.ghupsryf-...@intel.com/config)
compiler: ia64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/ee048cb6c2ec7f7f92bea6b72e8cd3ef9921993e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Dmitry-Baryshkov/drm-i915-dsc-change-DSC-param-tables-to-follow-the-DSC-model/20230228-193505
git checkout ee048cb6c2ec7f7f92bea6b72e8cd3ef9921993e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=ia64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/gpu/drm/display/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202302282203.ghupsryf-...@intel.com/
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/display/drm_dsc_helper.c:635: warning: expecting prototype
>> for drm_dsc_compute_rc_parameters(). Prototype was for
>> drm_dsc_setup_rc_params() instead
vim +635 drivers/gpu/drm/display/drm_dsc_helper.c
627
628 /**
629 * drm_dsc_compute_rc_parameters() - Set parameters and limits for RC
model in
630 * accordance with the DSC 1.1 or 1.2 specification and DSC C Model
631 *
632 * @vdsc_cfg: DSC Configuration data partially filled by driver
633 */
634 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg)
> 635 {
636 const struct rc_parameters *rc_params;
637 int i;
638
639 /* fractional BPP is not supported */
640 if (vdsc_cfg->bits_per_pixel & 0xf)
641 return -EINVAL;
642
643 rc_params = get_rc_params(vdsc_cfg->bits_per_pixel >> 4,
644vdsc_cfg->bits_per_component);
645 if (!rc_params)
646 return -EINVAL;
647
648 vdsc_cfg->first_line_bpg_offset =
rc_params->first_line_bpg_offset;
649 vdsc_cfg->initial_xmit_delay = rc_params->initial_xmit_delay;
650 vdsc_cfg->initial_offset = rc_params->initial_offset;
651 vdsc_cfg->flatness_min_qp = rc_params->flatness_min_qp;
652 vdsc_cfg->flatness_max_qp = rc_params->flatness_max_qp;
653 vdsc_cfg->rc_quant_incr_limit0 =
rc_params->rc_quant_incr_limit0;
654 vdsc_cfg->rc_quant_incr_limit1 =
rc_params->rc_quant_incr_limit1;
655
656 for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
657 vdsc_cfg->rc_range_params[i].range_min_qp =
658 rc_params->rc_range_params[i].range_min_qp;
659 vdsc_cfg->rc_range_params[i].range_max_qp =
660 rc_params->rc_range_params[i].range_max_qp;
661 /*
662 * Range BPG Offset uses 2's complement and is only a 6
bits. So
663 * mask it to get only 6 bits.
664 */
665 vdsc_cfg->rc_range_params[i].range_bpg_offset =
666 rc_params->rc_range_params[i].range_bpg_offset &
667 DSC_RANGE_BPG_OFFSET_MASK;
668 }
669
670 return 0;
671 }
672 EXPORT_SYMBOL(drm_dsc_setup_rc_params);
673
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
On Tue, 28 Feb 2023, Andi Shyti wrote:
> Hi,
>
>> >> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
>> >> > lock") removes the drm_gem_shmem_get_pages_locked() and
>> >> > drm_gem_shmem_put_pages_locked().
>> >> >
>> >> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
>> >> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
>> >> >
>> >> > Somehow these two commits got mixed up and produce the following
>> >> > compile error:
>> >>
>> >> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a bad
>> >> merge conflict resolution in drm-tip that was fixed yesterday, there is
>> >> no problem in misc-next. Where do you see this error?
>> >
>> > yes, indeed! I was indeed surprised to see this mismatch.
>> >
>> > I see it in the Intel's drm-tip branch[*]
>>
>> To set the record straight, drm-tip isn't Intel's, it's an integration
>> branch shared by the drm community.
>
> yes of course... it's a matter of fast writing :)
>
>> Looks like the same bad merge resolution has resurrected itself somehow,
>> maybe Thomas'
>>
>> commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
>> Author: Thomas Zimmermann
>> Date: Tue Feb 28 10:03:24 2023 +0100
>>
>> 2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
>>
>> git version 2.39.2
>>
>> in drm-rerere brought it back.
>>
>> And the build is indeed currently broken.
>>
>> Moreover, when the build was fine for a while, apparently the changes in
>> shmem broke a bunch of machines in Intel CI. And due to this, we aren't
>> getting any CI results for incoming patches right now.
>
> Is there any plans for fixing it?
Someone(tm) needs to step up and do it. Personally, I'm clueless.
The whole thing is made worse by the conflict and the various
resolutions. At this time, I'm not certain whether the whole thing was
broken to begin with, or if it's just the conflict resolution that
caused the issues.
I'll just note that for future reference, Cc'ing intel-gfx for anything
non-trivial touching the guts of drm will be useful for running CI on
our test farm pre-merge. Now, we don't know.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
On Tue, Feb 28, 2023 at 02:01:36PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, February 28, 2023 9:44 PM
> >
> > On Tue, Feb 28, 2023 at 01:36:24PM +, Liu, Yi L wrote:
> > > > From: Jason Gunthorpe
> > > > Sent: Tuesday, February 28, 2023 9:26 PM
> > > >
> > > > On Tue, Feb 28, 2023 at 01:22:50PM +, Liu, Yi L wrote:
> > > >
> > > > > > A null iommufd pointer and a bound df flag is sufficient to see that
> > > > > > it is compat mode.
> > > > >
> > > > > Hope df->is_cdev_device suits your expectation.:-) The code will look
> > > > > like below:
> > > >
> > > > Yes, this is better.. However I'd suggest 'uses_container' as it is
> > > > clearer what the special case is
> > >
> > > Surely doable. Need to add a helper like below:
> > >
> > > bool vfio_device_group_uses_container()
> > > {
> > > lockdep_assert_held(>group->group_lock);
> > > return device->group->container;
> > > }
> >
> > It should come from the df.
> >
> > If you have a df then by definition:
> > smp_load_acquire(..) == false - Not bound
> > df->device->iommufd_ctx != NULL - Using iommufd
> > df->group->containter != NULL - Using legacy container
> > all other cases - NO_IOMMU
> >
> > No locking required since all these cases after the smp_load_acquire
> > must be fixed for the lifetime of the df.
>
> Do you mean the df->access_granted (introduced in patch 07) or a new
> flag?
yes
> Following your suggestion, it seems a mandatory requirement to do the
> smp_load_acquire(..) == false check first, and then call into the
> vfio_device_open()
> which further calls vfio_device_first_open() to check the iommufd/
> legacy container/noiommu stuffs. Is it?
Figuring out if an open should happen or not is a different operation,
you already build exclusion between cdev/group so we don't need to
care about the open path.
> df->group->containter this may need a helper to avoid decoding group
> field. May be just store container in df?
At worst a flag, but a helper seems like a good idea anyhow, then it
can be compiled out
Jason
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
Hi,
> >> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
> >> > lock") removes the drm_gem_shmem_get_pages_locked() and
> >> > drm_gem_shmem_put_pages_locked().
> >> >
> >> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
> >> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
> >> >
> >> > Somehow these two commits got mixed up and produce the following
> >> > compile error:
> >>
> >> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a bad
> >> merge conflict resolution in drm-tip that was fixed yesterday, there is
> >> no problem in misc-next. Where do you see this error?
> >
> > yes, indeed! I was indeed surprised to see this mismatch.
> >
> > I see it in the Intel's drm-tip branch[*]
>
> To set the record straight, drm-tip isn't Intel's, it's an integration
> branch shared by the drm community.
yes of course... it's a matter of fast writing :)
> Looks like the same bad merge resolution has resurrected itself somehow,
> maybe Thomas'
>
> commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
> Author: Thomas Zimmermann
> Date: Tue Feb 28 10:03:24 2023 +0100
>
> 2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
>
> git version 2.39.2
>
> in drm-rerere brought it back.
>
> And the build is indeed currently broken.
>
> Moreover, when the build was fine for a while, apparently the changes in
> shmem broke a bunch of machines in Intel CI. And due to this, we aren't
> getting any CI results for incoming patches right now.
Is there any plans for fixing it?
Andi
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
On 27/02/2023 17:19, Jonathan Cavitt wrote:
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into
live selftests as their requirements have recently become platform-dependent.
Additionally, apply necessary platform dependency checks to these tests.
v2: Reorder
Signed-off-by: Jonathan Cavitt
r-b still stands for the series. Note that CI is busted atm though, so
we can't merge this yet. Likely need to re-trigger testing for the
series once CI/drm-tip is working again.
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index defece0bcb81..375f119ab261 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -710,7 +710,7 @@ static void close_object_list(struct list_head *objects,
}
}
-static int igt_mock_ppgtt_huge_fill(void *arg)
+static int igt_ppgtt_huge_fill(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -784,7 +784,8 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
GEM_BUG_ON(!expected_gtt);
GEM_BUG_ON(size);
- if (expected_gtt & I915_GTT_PAGE_SIZE_4K)
+ if (expected_gtt & I915_GTT_PAGE_SIZE_4K &&
+ GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
expected_gtt &= ~I915_GTT_PAGE_SIZE_64K;
i915_vma_unpin(vma);
@@ -831,7 +832,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
return err;
}
-static int igt_mock_ppgtt_64K(void *arg)
+static int igt_ppgtt_64K(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -913,6 +914,17 @@ static int igt_mock_ppgtt_64K(void *arg)
unsigned int offset = objects[i].offset;
unsigned int flags = PIN_USER;
+ /*
+* For modern GTT models, the requirements for marking a
page-table
+* as 64K have been relaxed. Account for this.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ expected_gtt = 0;
+ expected_gtt |= size & (SZ_64K | SZ_2M) ?
I915_GTT_PAGE_SIZE_64K : 0;
+ expected_gtt |= size & SZ_4K ? I915_GTT_PAGE_SIZE_4K :
0;
+ }
+
for (single = 0; single <= 1; single++) {
obj = fake_huge_pages_object(i915, size, !!single);
if (IS_ERR(obj))
@@ -1910,8 +1922,6 @@ int i915_gem_huge_page_mock_selftests(void)
SUBTEST(igt_mock_exhaust_device_supported_pages),
SUBTEST(igt_mock_memory_region_huge_pages),
SUBTEST(igt_mock_ppgtt_misaligned_dma),
- SUBTEST(igt_mock_ppgtt_huge_fill),
- SUBTEST(igt_mock_ppgtt_64K),
};
struct drm_i915_private *dev_priv;
struct i915_ppgtt *ppgtt;
@@ -1962,6 +1972,8 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_ppgtt_sanity_check),
SUBTEST(igt_ppgtt_compact),
SUBTEST(igt_ppgtt_mixed),
+ SUBTEST(igt_ppgtt_huge_fill),
+ SUBTEST(igt_ppgtt_64K),
};
if (!HAS_PPGTT(i915)) {
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
On Tue, 28 Feb 2023, Andi Shyti wrote:
> Hi Dmitry,
>
> On Tue, Feb 28, 2023 at 04:15:28PM +0300, Dmitry Osipenko wrote:
>> Hi,
>>
>> On 2/28/23 15:50, Andi Shyti wrote:
>> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
>> > lock") removes the drm_gem_shmem_get_pages_locked() and
>> > drm_gem_shmem_put_pages_locked().
>> >
>> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
>> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
>> >
>> > Somehow these two commits got mixed up and produce the following
>> > compile error:
>>
>> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a bad
>> merge conflict resolution in drm-tip that was fixed yesterday, there is
>> no problem in misc-next. Where do you see this error?
>
> yes, indeed! I was indeed surprised to see this mismatch.
>
> I see it in the Intel's drm-tip branch[*]
To set the record straight, drm-tip isn't Intel's, it's an integration
branch shared by the drm community.
Looks like the same bad merge resolution has resurrected itself somehow,
maybe Thomas'
commit 418ce969b4c8533c7c76cc0b7adeb432ccdc137e
Author: Thomas Zimmermann
Date: Tue Feb 28 10:03:24 2023 +0100
2023y-02m-28d-09h-02m-44s UTC: drm-tip rerere cache update
git version 2.39.2
in drm-rerere brought it back.
And the build is indeed currently broken.
Moreover, when the build was fine for a while, apparently the changes in
shmem broke a bunch of machines in Intel CI. And due to this, we aren't
getting any CI results for incoming patches right now.
BR,
Jani.
>
> Cc'ing the Intel's mailing list and maintainers, as well.
>
> Tnanks,
> Andi
>
> [*] git.freedesktop.org/git/drm-tip
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 9:44 PM
>
> On Tue, Feb 28, 2023 at 01:36:24PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, February 28, 2023 9:26 PM
> > >
> > > On Tue, Feb 28, 2023 at 01:22:50PM +, Liu, Yi L wrote:
> > >
> > > > > A null iommufd pointer and a bound df flag is sufficient to see that
> > > > > it is compat mode.
> > > >
> > > > Hope df->is_cdev_device suits your expectation.:-) The code will look
> > > > like below:
> > >
> > > Yes, this is better.. However I'd suggest 'uses_container' as it is
> > > clearer what the special case is
> >
> > Surely doable. Need to add a helper like below:
> >
> > bool vfio_device_group_uses_container()
> > {
> > lockdep_assert_held(>group->group_lock);
> > return device->group->container;
> > }
>
> It should come from the df.
>
> If you have a df then by definition:
> smp_load_acquire(..) == false - Not bound
> df->device->iommufd_ctx != NULL - Using iommufd
> df->group->containter != NULL - Using legacy container
> all other cases - NO_IOMMU
>
> No locking required since all these cases after the smp_load_acquire
> must be fixed for the lifetime of the df.
Do you mean the df->access_granted (introduced in patch 07) or a new flag?
Following your suggestion, it seems a mandatory requirement to do the
smp_load_acquire(..) == false check first, and then call into the
vfio_device_open()
which further calls vfio_device_first_open() to check the iommufd/
legacy container/noiommu stuffs. Is it?
df->group->containter this may need a helper to avoid decoding group
field. May be just store container in df?
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
On Tue, Feb 28, 2023 at 01:36:24PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, February 28, 2023 9:26 PM
> >
> > On Tue, Feb 28, 2023 at 01:22:50PM +, Liu, Yi L wrote:
> >
> > > > A null iommufd pointer and a bound df flag is sufficient to see that
> > > > it is compat mode.
> > >
> > > Hope df->is_cdev_device suits your expectation.:-) The code will look
> > > like below:
> >
> > Yes, this is better.. However I'd suggest 'uses_container' as it is
> > clearer what the special case is
>
> Surely doable. Need to add a helper like below:
>
> bool vfio_device_group_uses_container()
> {
> lockdep_assert_held(>group->group_lock);
> return device->group->container;
> }
It should come from the df.
If you have a df then by definition:
smp_load_acquire(..) == false - Not bound
df->device->iommufd_ctx != NULL - Using iommufd
df->group->containter != NULL - Using legacy container
all other cases - NO_IOMMU
No locking required since all these cases after the smp_load_acquire
must be fixed for the lifetime of the df.
Jason
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 9:26 PM
>
> On Tue, Feb 28, 2023 at 01:22:50PM +, Liu, Yi L wrote:
>
> > > A null iommufd pointer and a bound df flag is sufficient to see that
> > > it is compat mode.
> >
> > Hope df->is_cdev_device suits your expectation.:-) The code will look
> > like below:
>
> Yes, this is better.. However I'd suggest 'uses_container' as it is
> clearer what the special case is
Surely doable. Need to add a helper like below:
bool vfio_device_group_uses_container()
{
lockdep_assert_held(>group->group_lock);
return device->group->container;
}
But I'm poor at naming it. If it is true, the code would call
vfio_device_group_use_iommu(). If doing it in this way,
I think it's better to rename vfio_device_group_use_iommu()
as well.
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
On Tue, Feb 28, 2023 at 01:22:50PM +, Liu, Yi L wrote: > > A null iommufd pointer and a bound df flag is sufficient to see that > > it is compat mode. > > Hope df->is_cdev_device suits your expectation.:-) The code will look > like below: Yes, this is better.. However I'd suggest 'uses_container' as it is clearer what the special case is Jason
Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg file for PICA registers
> -Original Message- > From: Roper, Matthew D > Sent: Tuesday, February 28, 2023 2:17 AM > To: Kahola, Mika > Cc: intel-gfx@lists.freedesktop.org; Sripada, Radhakrishna > ; Sousa, Gustavo > Subject: Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg > file > for PICA registers > > On Fri, Feb 24, 2023 at 12:13:37PM +0200, Mika Kahola wrote: > > Create a separate file to store registers for PICA chips > > C10 and C20. > > > > v2: Rename file (Jani) > > > > Signed-off-by: Radhakrishna Sripada > > Signed-off-by: Mika Kahola > > --- > > .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 136 > > ++ > > 1 file changed, 136 insertions(+) > > create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > > b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > > new file mode 100644 > > index ..d6b3709d3762 > > --- /dev/null > > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > > @@ -0,0 +1,136 @@ > > +/* SPDX-License-Identifier: MIT > > + * > > + * Copyright © 2022 Intel Corporation */ > > + > > +#ifndef __INTEL_CX0_PHY_REGS_H__ > > +#define __INTEL_CX0_PHY_REGS_H__ > > + > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A 0x64040 > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B 0x64140 > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1 > 0x16F240 > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2 > 0x16F440 > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3 > 0x16F640 > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4 > 0x16F840 > > +#define _XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) > (_PICK(port, \ > > + [PORT_A] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ > > + [PORT_B] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ > > + [PORT_TC1] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ > > + [PORT_TC2] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2, \ > > + [PORT_TC3] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3, \ > > + [PORT_TC4] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4) + ((lane) > > +* 4)) > > + > > +#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) > _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)) > > +#define XELPDP_PORT_M2P_TRANSACTION_PENDING > REG_BIT(31) > > +#define XELPDP_PORT_M2P_COMMAND_TYPE_MASK > REG_GENMASK(30, 27) > > +#define XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1) > > +#define XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2) > > +#define XELPDP_PORT_M2P_COMMAND_READ > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3) > > +#define XELPDP_PORT_M2P_DATA_MASK > REG_GENMASK(23, 16) > > +#define XELPDP_PORT_M2P_DATA(val) > REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val) > > +#define XELPDP_PORT_M2P_TRANSACTION_RESET REG_BIT(15) > > +#define XELPDP_PORT_M2P_ADDRESS_MASK > REG_GENMASK(11, 0) > > +#define XELPDP_PORT_M2P_ADDRESS(val) > REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val) > > + > > +#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane) > _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) + 8) > > +#define XELPDP_PORT_P2M_RESPONSE_READY > REG_BIT(31) > > +#define XELPDP_PORT_P2M_COMMAND_TYPE_MASK > REG_GENMASK(30, 27) > > +#define XELPDP_PORT_P2M_COMMAND_READ_ACK 0x4 > > +#define XELPDP_PORT_P2M_COMMAND_WRITE_ACK 0x5 > > +#define XELPDP_PORT_P2M_DATA_MASK > REG_GENMASK(23, 16) > > +#define XELPDP_PORT_P2M_DATA(val) > REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val) > > +#define XELPDP_PORT_P2M_ERROR_SET REG_BIT(15) > > +#define XELPDP_MSGBUS_TIMEOUT_SLOW1 > > +#define XELPDP_MSGBUS_TIMEOUT_FAST_US 2 > > + > > +#define XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US 3200 > > +#define XELPDP_PCLK_PLL_DISABLE_TIMEOUT_US 20 > > +#define XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US 100 > > +#define XELPDP_PORT_RESET_START_TIMEOUT_US 5 > > +#define XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US > 100 > > Drive-by comment: is this constant correct? On bspec 65450 it looks like > there's > a table of different values (anywhere from 2 to 1380) that get used depending > on the old/new state combination. Your're right that there is a table for this. I think this needs to be sorted out and use the correct value for timeout in intel_cx0_powerdown_change_sequence() Thanks for spotting this! -Mika- > > > Matt > > > +#define XELPDP_PORT_RESET_END_TIMEOUT 15 > > +#define XELPDP_REFCLK_ENABLE_TIMEOUT_US
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 8:53 PM > > On Tue, Feb 28, 2023 at 12:48:23PM +, Liu, Yi L wrote: > > > From: Jason Gunthorpe > > > Sent: Tuesday, February 28, 2023 8:30 PM > > > > > > On Tue, Feb 28, 2023 at 02:35:25AM +, Liu, Yi L wrote: > > > > > > > > And the commit message is sort of out of sync with the patch, more > like: > > > > > > > > > > vfio: Pass the pt_id as an argument to vfio_iommufd_bind() > > > > > > > > > > To support binding the cdev the pt_id must come from userspace > > > instead > > > > > of being forced to the compat_ioas_id. > > > > > > > > > > > > > Got it. not only pt_id, also dev_id. > > > > > > Maybe dev_id should be read back from the iommufd_device pointer in > > > the vfio_device. It is trivially stored in that memory already > > > > Yes. this somehow gives me a doubt. Why iommufd_device_bind() > returns > > both iommufd_device pointer and the id back as id is already stored in the > > iommufd_device. Is it? > > Yes, it was done this way to avoid another API to get the ID, but > perhaps that is more conveient for vfio anyhow. We could get rid of > the id return pointer as well Ok, maybe I can have a small patch to add API like iommufd_device_id() to get devid, and get rid of the id return pointer as part of this series or an independent prerequisite patch for this series. Regards, Yi Liu
Re: [Intel-gfx] [PATCH] drm/shmem-helper: Fix compile error
Hi Dmitry,
On Tue, Feb 28, 2023 at 04:15:28PM +0300, Dmitry Osipenko wrote:
> Hi,
>
> On 2/28/23 15:50, Andi Shyti wrote:
> > Commit 67b7836d4458 ("drm/shmem-helper: Switch to reservation
> > lock") removes the drm_gem_shmem_get_pages_locked() and
> > drm_gem_shmem_put_pages_locked().
> >
> > But then commit edaa0db9 ("drm/shmem-helper: Fix locking for
> > drm_gem_shmem_get_pages_sgt()") reintroduces it.
> >
> > Somehow these two commits got mixed up and produce the following
> > compile error:
>
> The 67b7836d4458 goes after edaa0db9 in misc-next. It was a bad
> merge conflict resolution in drm-tip that was fixed yesterday, there is
> no problem in misc-next. Where do you see this error?
yes, indeed! I was indeed surprised to see this mismatch.
I see it in the Intel's drm-tip branch[*]
Cc'ing the Intel's mailing list and maintainers, as well.
Tnanks,
Andi
[*] git.freedesktop.org/git/drm-tip
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 8:54 PM
>
> On Tue, Feb 28, 2023 at 12:42:31PM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, February 28, 2023 8:32 PM
> > >
> > > On Tue, Feb 28, 2023 at 02:51:28AM +, Liu, Yi L wrote:
> > > > > This seems strange. no iommu mode should have a NULL dev-
> > > >iommufctx.
> > > > > Why do we have a df->noiommu at all?
> > > >
> > > > This is due to the vfio_device_first_open(). Detail as below comment
> (part
> > > of
> > > > patch 0016).
> > > >
> > > > + /*
> > > > +* For group/container path, iommufd pointer is NULL when comes
> > > > +* into this helper. Its noiommu support is handled by
> > > > +* vfio_device_group_use_iommu()
> > > > +*
> > > > +* For iommufd compat mode, iommufd pointer here is a valid
> > > > value.
> > > > +* Its noiommu support is in vfio_iommufd_bind().
> > > > +*
> > > > +* For device cdev path, iommufd pointer here is a valid value
> > > > for
> > > > +* normal cases, but it is NULL if it's noiommu. Check
> > > > df->noiommu
> > > > +* to differentiate cdev noiommu from the group/container path
> > > which
> > > > +* also passes NULL iommufd pointer in. If set then do nothing.
> > > > +*/
> > >
> > > If the group is in iommufd mode then it should set this pointer too.
> >
> > Yes, but the key point is that both the group in legacy mode and the
> > cdev path sets iommufd==NULL. And the handling for the two should
> > be different. So needs this extra info to differentiate them in
> > vfio_device_first_open().
>
> Don't encode that in the iommufd pointer, it is confusing.
Maybe I failed to make it clear. As the below code, When
iommufd==!NULL, no need to differentiate whether it is
the group compat mode or the cdev path. But if iommufd==NULL,
it may be the legacy group code or the cdev noiommu mode. So
df->noiommu is added. But I agree this noiommu flag is confusing.
May use the df->is_cdev_device flag as the purpose here is to
differentiate cdev path and group path.
if (iommufd)
ret = vfio_iommufd_bind(device, iommufd, dev_id);
else if (!df->noiommu)
ret = vfio_device_group_use_iommu(device);
if (ret)
goto err_module_put;
> A null iommufd pointer and a bound df flag is sufficient to see that
> it is compat mode.
Hope df->is_cdev_device suits your expectation.:-) The code will look
like below:
if (iommufd) {
ret = vfio_iommufd_bind(device, iommufd, dev_id);
if (!ret && !df->is_cdev_device) {
ret = vfio_iommufd_attach_compat(device); // new helper
as in patch 10 discussed
if (ret)
vfio_iommufd_unbind(device);
}
} else if (!df->is_cdev_device) {
ret = vfio_device_group_use_iommu(device);
}
if (ret)
goto err_module_put;
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Apply Wa_14017073508 for MTL SoC Step
Hi Matt,
On 24-02-2023 02:43, Matt Roper wrote:
On Thu, Feb 23, 2023 at 03:20:28PM -0500, Rodrigo Vivi wrote:
On Fri, Feb 24, 2023 at 12:11:40AM +0530, Badal Nilawar wrote:
Apply Wa_14017073508 for MTL SoC die A step instead of graphics step.
To get the SoC die stepping there is no direct interface so using
revid as revid 0 aligns with SoC die A step.
Bspec: 55420
This doesn't prove anything. It is just saying Die A0 with GT A0,
die B0 with GT B0 and so on... Please help me to understand that
better offline before we move forward...
The definition of the workaround doesn't say anything about SoC
steppings that I can see. The workaround itself is tagged as being
being tied to Xe_LPM+ (i.e., the media IP), not to MTL as a platform and
not to the Xe_LPG graphics IP. In relation to the media IP
specifically, the bounds are listed as needed from A0, fixed in B0. So
unless there's a belief that the workaround itself is incorrect, I think
the bounds should be
IS_MTL_MEDIA_STEP(i915, STEP_A0, STEP_B0)
As discussed offline I will update the patch with above change and resend.
Thanks,
Badal
Matt
Fixes: 8f70f1ec587d ("drm/i915/mtl: Add Wa_14017073508 for SAMedia")
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index cef3d6f5c34e..4ba3c8c97ccc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -29,7 +29,7 @@
static void mtl_media_busy(struct intel_gt *gt)
{
/* Wa_14017073508: mtl */
- if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+ if (IS_METEORLAKE(gt->i915) && INTEL_REVID(gt->i915) == 0 &&
gt->type == GT_MEDIA)
snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
PCODE_MBOX_GT_STATE_MEDIA_BUSY,
@@ -39,7 +39,7 @@ static void mtl_media_busy(struct intel_gt *gt)
static void mtl_media_idle(struct intel_gt *gt)
{
/* Wa_14017073508: mtl */
- if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+ if (IS_METEORLAKE(gt->i915) && INTEL_REVID(gt->i915) == 0 &&
gt->type == GT_MEDIA)
snb_pcode_write_p(gt->uncore, PCODE_MBOX_GT_STATE,
PCODE_MBOX_GT_STATE_MEDIA_NOT_BUSY,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
index fcf51614f9a4..7429c233ad45 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
@@ -19,7 +19,7 @@ static bool __guc_rc_supported(struct intel_guc *guc)
* Do not enable gucrc to avoid additional interrupts which
* may disrupt pcode wa.
*/
- if (IS_MTL_GRAPHICS_STEP(gt->i915, P, STEP_A0, STEP_B0) &&
+ if (IS_METEORLAKE(gt->i915) && INTEL_REVID(gt->i915) == 0 &&
gt->type == GT_MEDIA)
return false;
--
2.25.1
Re: [Intel-gfx] [PATCH 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper
On 28/02/2023 14:49, Jani Nikula wrote:
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
On Tue, 28 Feb 2023 at 14:25, Jani Nikula wrote:
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagage them to
the drm_dsc_config.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 37 +++
drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +--
include/drm/display/drm_dsc_helper.h | 1 +
3 files changed, 39 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index c869c6e51e2b..ab8679c158b5 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,43 @@ void drm_dsc_pps_payload_pack(struct
drm_dsc_picture_parameter_set *pps_payload,
}
EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
+/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
+const u16 drm_dsc_rc_buf_thresh[] = {
+ 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
+ 7744, 7872, 8000, 8064
+};
+EXPORT_SYMBOL(drm_dsc_rc_buf_thresh);
This needs to be static, without exports.
Exported this to let other drivers use it, while skipping the
drm_dsc_set_rc_buf_thresh(). For example amdgpu driver sets buffer
thresholds on the interim structure, so the helper is not directly
applicable. See _do_calc_rc_params().
Regardless, I'm still saying don't do that.
Data is not an interface.
If you make it easy to just use the data, nobody will ever fix their
drivers to use proper interfaces, and you'll lock yourself to a
particular representation of the data even though it's supposed to be a
hidden implementation detail.
Yes, I usually do not export data, exactly for these reasons. I could
have argued here that the data is constant here, etc. etc.
However let's stop caring about other drivers. I'll drop the export for v2.
BR,
Jani.
+
+/**
+ * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
+ * in accordance with the DSC 1.2 specification.
+ *
+ * @vdsc_cfg: DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
+{
+ int i = 0;
Unnecessary initialization.
My bad.
+
+ for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
Please use ARRAY_SIZE(). Maybe add BUILD_BUG_ON() for DSC_NUM_BUF_RANGES
vs. ARRAY_SIZE(). (Yes, we should've used ARRAY_SIZE() in i915.)
Ack
+ /*
+ * six 0s are appended to the lsb of each threshold value
+ * internally in h/w.
+ * Only 8 bits are allowed for programming RcBufThreshold
+ */
+ vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
+ }
+
+ /*
+ * For 6bpp, RC Buffer threshold 12 and 13 need a different value
+ * as per C Model
+ */
+ if (vdsc_cfg->bits_per_pixel == 6 << 4) {
+ vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
+ vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
+ }
+}
+EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+
/**
* drm_dsc_compute_rc_parameters() - Write rate control
* parameters to the dsc configuration defined in
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d080741fd0b3..b4faab4c8fb3 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
MAX_COLUMN_INDEX
};
-/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static const u16 rc_buf_thresh[] = {
- 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
- 7744, 7872, 8000, 8064
-};
-
struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
- for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
- /*
- * six 0s are appended to the lsb of each threshold value
- * internally in h/w.
- * Only 8 bits are allowed for programming RcBufThreshold
- */
- vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
- }
-
- /*
- * For 6bpp, RC Buffer threshold 12 and 13 need a different value
- * as per C Model
- */
- if (compressed_bpp == 6) {
- vdsc_cfg->rc_buf_thresh[12] = 0x7C;
- vdsc_cfg->rc_buf_thresh[13] = 0x7D;
- }
+ drm_dsc_set_rc_buf_thresh(vdsc_cfg);
/*
* From XE_LPD onwards we supports compression bpps in steps of 1
diff --git a/include/drm/display/drm_dsc_helper.h
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
On Tue, Feb 28, 2023 at 12:56:11PM +, Liu, Yi L wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, February 28, 2023 8:52 PM > > > > On Tue, Feb 28, 2023 at 12:45:47PM +, Liu, Yi L wrote: > > > > From: Jason Gunthorpe > > > > Sent: Tuesday, February 28, 2023 8:31 PM > > > > > > > > On Tue, Feb 28, 2023 at 06:58:38AM +, Liu, Yi L wrote: > > > > > > > > > Seems like pt_id is no more needed in the vfio_iommufd_bind() > > > > > since it can get compat_ioas_id in the function itself. Cdev path > > > > > never passes a pt_id to vfio_iommufd_bind() as its attach is done > > > > > by separate ATTACH ioctl. Can we use the dev_id pointer to indicate > > > > > if it needs to get the compat ioas and attach it? > > > > > > > > In this case you need to split the group code to also use the two step > > > > attach and then the attach will take in the null pt_id. > > > > > > This seems to be the current way in this patch. Right? Group code passes > > > a pt_id pointer to vfio_iommufd_bind(). While the cdev path just passes > > > in a null pt_id pointer. Its attach is done later when user gives pt_id. > > > > I mean actually explicitly call attach and remove the implicit attach > > during bind flow entirely. > > Okay, so I can wrap the iommufd_vfio_compat_ioas_id() and ops->attach_ioas > in a helper for group code to do attach after bind_iommufd. This can avoid to > moving the iommufd_vfio_compat_ioas_id() out of iommufd.c as your original > remark. > > Is this ok? Yes, some 'attach compat' helper makes sense Jason
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: move DSC RC tables to drm_dsc_helper.c
== Series Details ==
Series: drm/i915: move DSC RC tables to drm_dsc_helper.c
URL : https://patchwork.freedesktop.org/series/114473/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12790_full -> Patchwork_114473v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/index.html
Participating hosts (9 -> 9)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_114473v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@multigpu-basic-threads:
- shard-tglu-9: NOTRUN -> [SKIP][1] ([i915#7697])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@gem_close_r...@multigpu-basic-threads.html
* igt@gem_eio@in-flight-1us:
- shard-tglu-9: NOTRUN -> [ABORT][2] ([i915#8233]) +1 similar issue
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@gem_...@in-flight-1us.html
* igt@gem_huc_copy@huc-copy:
- shard-tglu-9: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@gem_huc_c...@huc-copy.html
* igt@gem_userptr_blits@vma-merge:
- shard-tglu-9: NOTRUN -> [FAIL][4] ([i915#3318])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@gem_userptr_bl...@vma-merge.html
* igt@kms_async_flips@crc:
- shard-tglu-9: NOTRUN -> [SKIP][5] ([i915#1845]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_async_fl...@crc.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-tglu-9: NOTRUN -> [SKIP][6] ([i915#1845] / [i915#7651]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cdclk@plane-scaling:
- shard-tglu-9: NOTRUN -> [SKIP][7] ([i915#3742])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_cd...@plane-scaling.html
* igt@kms_chamelium_color@ctm-max:
- shard-tglu-9: NOTRUN -> [SKIP][8] ([fdo#111827])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_chamelium_co...@ctm-max.html
* igt@kms_chamelium_hpd@dp-hpd-after-suspend:
- shard-tglu-9: NOTRUN -> [SKIP][9] ([i915#7828]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_chamelium_...@dp-hpd-after-suspend.html
* igt@kms_flip@2x-flip-vs-suspend:
- shard-tglu-9: NOTRUN -> [SKIP][10] ([fdo#109274] / [i915#3637])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_f...@2x-flip-vs-suspend.html
* igt@kms_flip@blocking-wf_vblank:
- shard-tglu-9: NOTRUN -> [SKIP][11] ([i915#3637])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_flip@blocking-wf_vblank.html
* igt@kms_flip_scaled_crc@flip-32bpp-4tile-to-32bpp-4tiledg2rcccs-upscaling:
- shard-tglu-9: NOTRUN -> [SKIP][12] ([i915#3555])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_flip_scaled_...@flip-32bpp-4tile-to-32bpp-4tiledg2rcccs-upscaling.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-cur-indfb-draw-mmap-gtt:
- shard-tglu-9: NOTRUN -> [SKIP][13] ([i915#1849]) +10 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_frontbuffer_track...@psr-2p-scndscrn-cur-indfb-draw-mmap-gtt.html
* igt@kms_plane_alpha_blend@alpha-transparent-fb:
- shard-tglu-9: NOTRUN -> [SKIP][14] ([i915#7128] / [i915#7294])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_plane_alpha_bl...@alpha-transparent-fb.html
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25:
- shard-tglu-9: NOTRUN -> [SKIP][15] ([i915#6953] / [i915#8152])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_plane_scal...@planes-upscale-factor-0-25-downscale-factor-0-25.html
* igt@kms_psr@psr2_cursor_plane_move:
- shard-tglu-9: NOTRUN -> [SKIP][16] ([fdo#110189])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/shard-tglu-9/igt@kms_psr@psr2_cursor_plane_move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
[fdo#109280]:
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 8:52 PM > > On Tue, Feb 28, 2023 at 12:45:47PM +, Liu, Yi L wrote: > > > From: Jason Gunthorpe > > > Sent: Tuesday, February 28, 2023 8:31 PM > > > > > > On Tue, Feb 28, 2023 at 06:58:38AM +, Liu, Yi L wrote: > > > > > > > Seems like pt_id is no more needed in the vfio_iommufd_bind() > > > > since it can get compat_ioas_id in the function itself. Cdev path > > > > never passes a pt_id to vfio_iommufd_bind() as its attach is done > > > > by separate ATTACH ioctl. Can we use the dev_id pointer to indicate > > > > if it needs to get the compat ioas and attach it? > > > > > > In this case you need to split the group code to also use the two step > > > attach and then the attach will take in the null pt_id. > > > > This seems to be the current way in this patch. Right? Group code passes > > a pt_id pointer to vfio_iommufd_bind(). While the cdev path just passes > > in a null pt_id pointer. Its attach is done later when user gives pt_id. > > I mean actually explicitly call attach and remove the implicit attach > during bind flow entirely. Okay, so I can wrap the iommufd_vfio_compat_ioas_id() and ops->attach_ioas in a helper for group code to do attach after bind_iommufd. This can avoid to moving the iommufd_vfio_compat_ioas_id() out of iommufd.c as your original remark. Is this ok? Regards, Yi Liu
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
On Tue, Feb 28, 2023 at 12:42:31PM +, Liu, Yi L wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, February 28, 2023 8:32 PM > > > > On Tue, Feb 28, 2023 at 02:51:28AM +, Liu, Yi L wrote: > > > > This seems strange. no iommu mode should have a NULL dev- > > >iommufctx. > > > > Why do we have a df->noiommu at all? > > > > > > This is due to the vfio_device_first_open(). Detail as below comment (part > > of > > > patch 0016). > > > > > > + /* > > > + * For group/container path, iommufd pointer is NULL when comes > > > + * into this helper. Its noiommu support is handled by > > > + * vfio_device_group_use_iommu() > > > + * > > > + * For iommufd compat mode, iommufd pointer here is a valid value. > > > + * Its noiommu support is in vfio_iommufd_bind(). > > > + * > > > + * For device cdev path, iommufd pointer here is a valid value for > > > + * normal cases, but it is NULL if it's noiommu. Check df->noiommu > > > + * to differentiate cdev noiommu from the group/container path > > which > > > + * also passes NULL iommufd pointer in. If set then do nothing. > > > + */ > > > > If the group is in iommufd mode then it should set this pointer too. > > Yes, but the key point is that both the group in legacy mode and the > cdev path sets iommufd==NULL. And the handling for the two should > be different. So needs this extra info to differentiate them in > vfio_device_first_open(). Don't encode that in the iommufd pointer, it is confusing. A null iommufd pointer and a bound df flag is sufficient to see that it is compat mode. Jason
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
On Tue, Feb 28, 2023 at 12:48:23PM +, Liu, Yi L wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, February 28, 2023 8:30 PM > > > > On Tue, Feb 28, 2023 at 02:35:25AM +, Liu, Yi L wrote: > > > > > > And the commit message is sort of out of sync with the patch, more like: > > > > > > > > vfio: Pass the pt_id as an argument to vfio_iommufd_bind() > > > > > > > > To support binding the cdev the pt_id must come from userspace > > instead > > > > of being forced to the compat_ioas_id. > > > > > > > > > > Got it. not only pt_id, also dev_id. > > > > Maybe dev_id should be read back from the iommufd_device pointer in > > the vfio_device. It is trivially stored in that memory already > > Yes. this somehow gives me a doubt. Why iommufd_device_bind() returns > both iommufd_device pointer and the id back as id is already stored in the > iommufd_device. Is it? Yes, it was done this way to avoid another API to get the ID, but perhaps that is more conveient for vfio anyhow. We could get rid of the id return pointer as well Jason
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
On Tue, Feb 28, 2023 at 12:45:47PM +, Liu, Yi L wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, February 28, 2023 8:31 PM > > > > On Tue, Feb 28, 2023 at 06:58:38AM +, Liu, Yi L wrote: > > > > > Seems like pt_id is no more needed in the vfio_iommufd_bind() > > > since it can get compat_ioas_id in the function itself. Cdev path > > > never passes a pt_id to vfio_iommufd_bind() as its attach is done > > > by separate ATTACH ioctl. Can we use the dev_id pointer to indicate > > > if it needs to get the compat ioas and attach it? > > > > In this case you need to split the group code to also use the two step > > attach and then the attach will take in the null pt_id. > > This seems to be the current way in this patch. Right? Group code passes > a pt_id pointer to vfio_iommufd_bind(). While the cdev path just passes > in a null pt_id pointer. Its attach is done later when user gives pt_id. I mean actually explicitly call attach and remove the implicit attach during bind flow entirely. Jason
Re: [Intel-gfx] [PATCH v3 05/22] drm/i915: Introduce intel_hpd_detection()
On Tue, Feb 28, 2023 at 02:40:20PM +0200, Jani Nikula wrote: > On Wed, 22 Feb 2023, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Add a mechanism by which we can toggle the HPD sense for > > individual encoders. > > > > This will be used during eDP probing to figure out if > > anything is actually connected. The normal intel_hpd_irq_setup() > > thing doesn't work since we only do that after probing the > > outputs, and we only enable HPD sense for encoders that were > > successfully probed. > > > > The other idea that crossed my minds was to just turn on > > HPD sense for all pins before output probing and let hpd_irq_setup() > > clean it up afterwards. But that doesn't work for BXT/GLK where > > the HPD invert information comes from the VBT child device. > > So looks like this really needs to be per-encoder. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/i915_irq.c | 132 > > drivers/gpu/drm/i915/i915_irq.h | 2 + > > 2 files changed, 134 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > b/drivers/gpu/drm/i915/i915_irq.c > > index ecfa6dad145a..c5058d834f99 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -2893,8 +2893,17 @@ static void ibx_hpd_detection_setup(struct > > drm_i915_private *dev_priv) > > ibx_hotplug_mask(dev_priv, HPD_PORT_D), > > intel_hpd_hotplug_enables(dev_priv, > > ibx_hotplug_enables)); > > } > > > > +static void ibx_hpd_detection(struct intel_encoder *encoder, bool enable) > > Just quickly skimming through the series... > > ...and nitpicking, *_detection() should really be a verb. > > It isn't obvious to me what intel_hpd_detection() does without looking > at the implementation. I was origianlly musing about foo_enable_hpd_detection(), but then passing in a 'bool enable' for an enable() function seems a bit crap. I guess it could be foo_set_hpd_detection() or something like that. -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> On Tue, 28 Feb 2023 at 14:25, Jani Nikula wrote:
>>
>> On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
>> > The rc_buf_thresh values are common to all DSC implementations. Move
>> > them to the common helper together with the code to propagage them to
>> > the drm_dsc_config.
>> >
>> > Signed-off-by: Dmitry Baryshkov
>> > ---
>> > drivers/gpu/drm/display/drm_dsc_helper.c | 37 +++
>> > drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +--
>> > include/drm/display/drm_dsc_helper.h | 1 +
>> > 3 files changed, 39 insertions(+), 23 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
>> > b/drivers/gpu/drm/display/drm_dsc_helper.c
>> > index c869c6e51e2b..ab8679c158b5 100644
>> > --- a/drivers/gpu/drm/display/drm_dsc_helper.c
>> > +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
>> > @@ -270,6 +270,43 @@ void drm_dsc_pps_payload_pack(struct
>> > drm_dsc_picture_parameter_set *pps_payload,
>> > }
>> > EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
>> >
>> > +/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically
>> > constant */
>> > +const u16 drm_dsc_rc_buf_thresh[] = {
>> > + 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
>> > + 7744, 7872, 8000, 8064
>> > +};
>> > +EXPORT_SYMBOL(drm_dsc_rc_buf_thresh);
>>
>> This needs to be static, without exports.
>
> Exported this to let other drivers use it, while skipping the
> drm_dsc_set_rc_buf_thresh(). For example amdgpu driver sets buffer
> thresholds on the interim structure, so the helper is not directly
> applicable. See _do_calc_rc_params().
Regardless, I'm still saying don't do that.
Data is not an interface.
If you make it easy to just use the data, nobody will ever fix their
drivers to use proper interfaces, and you'll lock yourself to a
particular representation of the data even though it's supposed to be a
hidden implementation detail.
BR,
Jani.
>
>>
>> > +
>> > +/**
>> > + * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
>> > + * in accordance with the DSC 1.2 specification.
>> > + *
>> > + * @vdsc_cfg: DSC Configuration data partially filled by driver
>> > + */
>> > +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
>> > +{
>> > + int i = 0;
>>
>> Unnecessary initialization.
>
> My bad.
>
>>
>> > +
>> > + for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
>>
>> Please use ARRAY_SIZE(). Maybe add BUILD_BUG_ON() for DSC_NUM_BUF_RANGES
>> vs. ARRAY_SIZE(). (Yes, we should've used ARRAY_SIZE() in i915.)
>
> Ack
>
>>
>> > + /*
>> > + * six 0s are appended to the lsb of each threshold value
>> > + * internally in h/w.
>> > + * Only 8 bits are allowed for programming RcBufThreshold
>> > + */
>> > + vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
>> > + }
>> > +
>> > + /*
>> > + * For 6bpp, RC Buffer threshold 12 and 13 need a different value
>> > + * as per C Model
>> > + */
>> > + if (vdsc_cfg->bits_per_pixel == 6 << 4) {
>> > + vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
>> > + vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
>> > + }
>> > +}
>> > +EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
>> > +
>> > /**
>> > * drm_dsc_compute_rc_parameters() - Write rate control
>> > * parameters to the dsc configuration defined in
>> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
>> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
>> > index d080741fd0b3..b4faab4c8fb3 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
>> > @@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
>> > MAX_COLUMN_INDEX
>> > };
>> >
>> > -/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically
>> > constant */
>> > -static const u16 rc_buf_thresh[] = {
>> > - 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
>> > - 7744, 7872, 8000, 8064
>> > -};
>> > -
>> > struct rc_parameters {
>> > u16 initial_xmit_delay;
>> > u8 first_line_bpg_offset;
>> > @@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
>> > *pipe_config)
>> > vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
>> > vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
>> >
>> > - for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
>> > - /*
>> > - * six 0s are appended to the lsb of each threshold value
>> > - * internally in h/w.
>> > - * Only 8 bits are allowed for programming RcBufThreshold
>> > - */
>> > - vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
>> > - }
>> > -
>> > - /*
>> > - * For 6bpp, RC Buffer threshold 12 and 13 need a different value
>> > - * as per C Model
>> > - */
>> > - if (compressed_bpp == 6) {
>> > - vdsc_cfg->rc_buf_thresh[12] = 0x7C;
>> > -
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 8:30 PM > > On Tue, Feb 28, 2023 at 02:35:25AM +, Liu, Yi L wrote: > > > > And the commit message is sort of out of sync with the patch, more like: > > > > > > vfio: Pass the pt_id as an argument to vfio_iommufd_bind() > > > > > > To support binding the cdev the pt_id must come from userspace > instead > > > of being forced to the compat_ioas_id. > > > > > > > Got it. not only pt_id, also dev_id. > > Maybe dev_id should be read back from the iommufd_device pointer in > the vfio_device. It is trivially stored in that memory already Yes. this somehow gives me a doubt. Why iommufd_device_bind() returns both iommufd_device pointer and the id back as id is already stored in the iommufd_device. Is it? Regards, Yi Liu
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 8:31 PM > > On Tue, Feb 28, 2023 at 06:58:38AM +, Liu, Yi L wrote: > > > Seems like pt_id is no more needed in the vfio_iommufd_bind() > > since it can get compat_ioas_id in the function itself. Cdev path > > never passes a pt_id to vfio_iommufd_bind() as its attach is done > > by separate ATTACH ioctl. Can we use the dev_id pointer to indicate > > if it needs to get the compat ioas and attach it? > > In this case you need to split the group code to also use the two step > attach and then the attach will take in the null pt_id. This seems to be the current way in this patch. Right? Group code passes a pt_id pointer to vfio_iommufd_bind(). While the cdev path just passes in a null pt_id pointer. Its attach is done later when user gives pt_id. Regards, Yi Liu
Re: [Intel-gfx] [PATCH v5 11/19] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 8:33 PM
>
> On Tue, Feb 28, 2023 at 02:57:42AM +, Liu, Yi L wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, February 28, 2023 2:45 AM
> > >
> > > On Mon, Feb 27, 2023 at 03:11:27AM -0800, Yi Liu wrote:
> > > > diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c b/drivers/vfio/fsl-
> > > mc/vfio_fsl_mc.c
> > > > index c89a047a4cd8..d540cf683d93 100644
> > > > --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> > > > +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> > > > @@ -594,6 +594,7 @@ static const struct vfio_device_ops
> > > vfio_fsl_mc_ops = {
> > > > .bind_iommufd = vfio_iommufd_physical_bind,
> > > > .unbind_iommufd = vfio_iommufd_physical_unbind,
> > > > .attach_ioas= vfio_iommufd_physical_attach_ioas,
> > > > + .detach_ioas= vfio_iommufd_physical_detach_ioas,
> > > > };
> > > >
> > > > static struct fsl_mc_driver vfio_fsl_mc_driver = {
> > > > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > > > index beef6ca21107..bfaa9876499b 100644
> > > > --- a/drivers/vfio/iommufd.c
> > > > +++ b/drivers/vfio/iommufd.c
> > > > @@ -88,6 +88,14 @@ int vfio_iommufd_physical_attach_ioas(struct
> > > vfio_device *vdev, u32 *pt_id)
> > > > {
> > > > int rc;
> > > >
> > > > + lockdep_assert_held(>dev_set->lock);
> > > > +
> > > > + if (!vdev->iommufd_device)
> > > > + return -EINVAL;
> > >
> > > This should be a WARN_ON. The vdev->iommufd_ctx should be NULL if it
> > > hasn't been bound, and it can't be bound unless the
> > > iommufd_device/attach was created.
> >
> > sure. But it is a user-triggerable warn. If userspace triggers it on
> > purpose, will it be a bad thing for kernel? Maybe use
> > dev_warn_ratelimited()?
>
> How can it be user triggerable? You shouldn't be able to reach this
> function until the device is bound because the ioctl should be after
> the is it bound check
Oh, yes. it is! ioctls are blocked until bound to iommufd.
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH v7 00/15] dma-fence: Deadline awareness
On Mon, Feb 27, 2023 at 11:35:06AM -0800, Rob Clark wrote: > From: Rob Clark > > This series adds a deadline hint to fences, so realtime deadlines > such as vblank can be communicated to the fence signaller for power/ > frequency management decisions. > > This is partially inspired by a trick i915 does, but implemented > via dma-fence for a couple of reasons: > > 1) To continue to be able to use the atomic helpers > 2) To support cases where display and gpu are different drivers > > This iteration adds a dma-fence ioctl to set a deadline (both to > support igt-tests, and compositors which delay decisions about which > client buffer to display), and a sw_sync ioctl to read back the > deadline. IGT tests utilizing these can be found at: > > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > > > v1: https://patchwork.freedesktop.org/series/93035/ > v2: Move filtering out of later deadlines to fence implementation > to avoid increasing the size of dma_fence > v3: Add support in fence-array and fence-chain; Add some uabi to > support igt tests and userspace compositors. > v4: Rebase, address various comments, and add syncobj deadline > support, and sync_file EPOLLPRI based on experience with perf/ > freq issues with clvk compute workloads on i915 (anv) > v5: Clarify that this is a hint as opposed to a more hard deadline > guarantee, switch to using u64 ns values in UABI (still absolute > CLOCK_MONOTONIC values), drop syncobj related cap and driver > feature flag in favor of allowing count_handles==0 for probing > kernel support. > v6: Re-work vblank helper to calculate time of _start_ of vblank, > and work correctly if the last vblank event was more than a > frame ago. Add (mostly unrelated) drm/msm patch which also > uses the vblank helper. Use dma_fence_chain_contained(). More > verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > v7: Fix kbuild complaints about vblank helper. Add more docs. > I want to apply this series for testing, but it can't be applied cleanly on current drm-misc tree. On what tree (and commit) is this series based on? -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 8:32 PM > > On Tue, Feb 28, 2023 at 02:51:28AM +, Liu, Yi L wrote: > > > This seems strange. no iommu mode should have a NULL dev- > >iommufctx. > > > Why do we have a df->noiommu at all? > > > > This is due to the vfio_device_first_open(). Detail as below comment (part > of > > patch 0016). > > > > + /* > > +* For group/container path, iommufd pointer is NULL when comes > > +* into this helper. Its noiommu support is handled by > > +* vfio_device_group_use_iommu() > > +* > > +* For iommufd compat mode, iommufd pointer here is a valid value. > > +* Its noiommu support is in vfio_iommufd_bind(). > > +* > > +* For device cdev path, iommufd pointer here is a valid value for > > +* normal cases, but it is NULL if it's noiommu. Check df->noiommu > > +* to differentiate cdev noiommu from the group/container path > which > > +* also passes NULL iommufd pointer in. If set then do nothing. > > +*/ > > If the group is in iommufd mode then it should set this pointer too. Yes, but the key point is that both the group in legacy mode and the cdev path sets iommufd==NULL. And the handling for the two should be different. So needs this extra info to differentiate them in vfio_device_first_open(). Regards, Yi Liu
Re: [Intel-gfx] [PATCH v3 05/22] drm/i915: Introduce intel_hpd_detection()
On Wed, 22 Feb 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a mechanism by which we can toggle the HPD sense for
> individual encoders.
>
> This will be used during eDP probing to figure out if
> anything is actually connected. The normal intel_hpd_irq_setup()
> thing doesn't work since we only do that after probing the
> outputs, and we only enable HPD sense for encoders that were
> successfully probed.
>
> The other idea that crossed my minds was to just turn on
> HPD sense for all pins before output probing and let hpd_irq_setup()
> clean it up afterwards. But that doesn't work for BXT/GLK where
> the HPD invert information comes from the VBT child device.
> So looks like this really needs to be per-encoder.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 132
> drivers/gpu/drm/i915/i915_irq.h | 2 +
> 2 files changed, 134 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index ecfa6dad145a..c5058d834f99 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2893,8 +2893,17 @@ static void ibx_hpd_detection_setup(struct
> drm_i915_private *dev_priv)
>ibx_hotplug_mask(dev_priv, HPD_PORT_D),
>intel_hpd_hotplug_enables(dev_priv,
> ibx_hotplug_enables));
> }
>
> +static void ibx_hpd_detection(struct intel_encoder *encoder, bool enable)
Just quickly skimming through the series...
...and nitpicking, *_detection() should really be a verb.
It isn't obvious to me what intel_hpd_detection() does without looking
at the implementation.
BR,
Jani.
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + intel_uncore_rmw(>uncore, PCH_PORT_HOTPLUG,
> + ibx_hotplug_mask(i915, encoder->hpd_pin),
> + enable ? ibx_hotplug_enables(encoder) : 0);
> +}
> +
> static void ibx_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> u32 hotplug_irqs, enabled_irqs;
>
> @@ -2963,8 +2972,17 @@ static void icp_ddi_hpd_detection_setup(struct
> drm_i915_private *dev_priv)
>icp_ddi_hotplug_mask(dev_priv, HPD_PORT_D),
>intel_hpd_hotplug_enables(dev_priv,
> icp_ddi_hotplug_enables));
> }
>
> +static void icp_ddi_hpd_detection(struct intel_encoder *encoder, bool enable)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + intel_uncore_rmw(>uncore, SHOTPLUG_CTL_DDI,
> + icp_ddi_hotplug_mask(i915, encoder->hpd_pin),
> + enable ? icp_ddi_hotplug_enables(encoder) : 0);
> +}
> +
> static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
> {
> intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_TC,
>icp_tc_hotplug_mask(dev_priv, HPD_PORT_TC1) |
> @@ -2975,8 +2993,23 @@ static void icp_tc_hpd_detection_setup(struct
> drm_i915_private *dev_priv)
>icp_tc_hotplug_mask(dev_priv, HPD_PORT_TC6),
>intel_hpd_hotplug_enables(dev_priv,
> icp_tc_hotplug_enables));
> }
>
> +static void icp_tc_hpd_detection(struct intel_encoder *encoder, bool enable)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + intel_uncore_rmw(>uncore, SHOTPLUG_CTL_TC,
> + icp_tc_hotplug_mask(i915, encoder->hpd_pin),
> + enable ? icp_tc_hotplug_enables(encoder) : 0);
> +}
> +
> +static void icp_hpd_detection(struct intel_encoder *encoder, bool enable)
> +{
> + icp_ddi_hpd_detection(encoder, enable);
> + icp_tc_hpd_detection(encoder, enable);
> +}
> +
> static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> u32 hotplug_irqs, enabled_irqs;
>
> @@ -3025,8 +3058,16 @@ static void dg1_hpd_invert(struct drm_i915_private
> *i915)
> INVERT_DDID_HPD);
> intel_uncore_rmw(>uncore, SOUTH_CHICKEN1, 0, val);
> }
>
> +static void dg1_hpd_detection(struct intel_encoder *encoder, bool enable)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + dg1_hpd_invert(i915);
> + icp_hpd_detection(encoder, enable);
> +}
> +
> static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> dg1_hpd_invert(dev_priv);
> icp_hpd_irq_setup(dev_priv);
> @@ -3043,8 +3084,17 @@ static void gen11_tc_hpd_detection_setup(struct
> drm_i915_private *dev_priv)
>gen11_hotplug_mask(dev_priv, HPD_PORT_TC6),
>intel_hpd_hotplug_enables(dev_priv,
> gen11_hotplug_enables));
> }
>
> +static void gen11_tc_hpd_detection(struct intel_encoder *encoder, bool
> enable)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> +
> + intel_uncore_rmw(>uncore, GEN11_TC_HOTPLUG_CTL,
> + gen11_hotplug_mask(i915, encoder->hpd_pin),
> +
Re: [Intel-gfx] [PATCH v5 18/19] vfio: Compile group optionally
On Tue, Feb 28, 2023 at 06:00:09AM +, Liu, Yi L wrote: > > From: Liu, Yi L > > Sent: Monday, February 27, 2023 7:12 PM > > > > group code is not needed for vfio device cdev, so with vfio device cdev > > introduced, the group infrastructures can be compiled out if only cdev > > is needed. > > > > Signed-off-by: Yi Liu > > --- > > drivers/vfio/Kconfig | 14 + > > drivers/vfio/Makefile | 2 +- > > drivers/vfio/vfio.h | 72 > > +++ > > include/linux/vfio.h | 24 ++- > > 4 files changed, 110 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > > index 169762316513..c3ab06c314ea 100644 > > --- a/drivers/vfio/Kconfig > > +++ b/drivers/vfio/Kconfig > > @@ -4,6 +4,8 @@ menuconfig VFIO > > select IOMMU_API > > depends on IOMMUFD || !IOMMUFD > > select INTERVAL_TREE > > + select VFIO_GROUP if SPAPR_TCE_IOMMU > > + select VFIO_DEVICE_CDEV if !VFIO_GROUP && (X86 || S390 || ARM || ARM64) > > Got below warning when IOMMUFD=n, VFIO_GROUP=n. so may remove > this select or needs to let VFIO_DEVICE_CDEV select IOMMUFD instead of > depends on IOMMUFD. Add select VFIO_GROUP if !IOMMUFD Jason
Re: [Intel-gfx] [PATCH 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper
On Tue, 28 Feb 2023 at 14:25, Jani Nikula wrote:
>
> On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> > The rc_buf_thresh values are common to all DSC implementations. Move
> > them to the common helper together with the code to propagage them to
> > the drm_dsc_config.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/display/drm_dsc_helper.c | 37 +++
> > drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +--
> > include/drm/display/drm_dsc_helper.h | 1 +
> > 3 files changed, 39 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> > b/drivers/gpu/drm/display/drm_dsc_helper.c
> > index c869c6e51e2b..ab8679c158b5 100644
> > --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> > @@ -270,6 +270,43 @@ void drm_dsc_pps_payload_pack(struct
> > drm_dsc_picture_parameter_set *pps_payload,
> > }
> > EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
> >
> > +/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant
> > */
> > +const u16 drm_dsc_rc_buf_thresh[] = {
> > + 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> > + 7744, 7872, 8000, 8064
> > +};
> > +EXPORT_SYMBOL(drm_dsc_rc_buf_thresh);
>
> This needs to be static, without exports.
Exported this to let other drivers use it, while skipping the
drm_dsc_set_rc_buf_thresh(). For example amdgpu driver sets buffer
thresholds on the interim structure, so the helper is not directly
applicable. See _do_calc_rc_params().
>
> > +
> > +/**
> > + * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
> > + * in accordance with the DSC 1.2 specification.
> > + *
> > + * @vdsc_cfg: DSC Configuration data partially filled by driver
> > + */
> > +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
> > +{
> > + int i = 0;
>
> Unnecessary initialization.
My bad.
>
> > +
> > + for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
>
> Please use ARRAY_SIZE(). Maybe add BUILD_BUG_ON() for DSC_NUM_BUF_RANGES
> vs. ARRAY_SIZE(). (Yes, we should've used ARRAY_SIZE() in i915.)
Ack
>
> > + /*
> > + * six 0s are appended to the lsb of each threshold value
> > + * internally in h/w.
> > + * Only 8 bits are allowed for programming RcBufThreshold
> > + */
> > + vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
> > + }
> > +
> > + /*
> > + * For 6bpp, RC Buffer threshold 12 and 13 need a different value
> > + * as per C Model
> > + */
> > + if (vdsc_cfg->bits_per_pixel == 6 << 4) {
> > + vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
> > + vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
> > + }
> > +}
> > +EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
> > +
> > /**
> > * drm_dsc_compute_rc_parameters() - Write rate control
> > * parameters to the dsc configuration defined in
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index d080741fd0b3..b4faab4c8fb3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
> > MAX_COLUMN_INDEX
> > };
> >
> > -/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant
> > */
> > -static const u16 rc_buf_thresh[] = {
> > - 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> > - 7744, 7872, 8000, 8064
> > -};
> > -
> > struct rc_parameters {
> > u16 initial_xmit_delay;
> > u8 first_line_bpg_offset;
> > @@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
> > *pipe_config)
> > vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> > vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
> >
> > - for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
> > - /*
> > - * six 0s are appended to the lsb of each threshold value
> > - * internally in h/w.
> > - * Only 8 bits are allowed for programming RcBufThreshold
> > - */
> > - vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
> > - }
> > -
> > - /*
> > - * For 6bpp, RC Buffer threshold 12 and 13 need a different value
> > - * as per C Model
> > - */
> > - if (compressed_bpp == 6) {
> > - vdsc_cfg->rc_buf_thresh[12] = 0x7C;
> > - vdsc_cfg->rc_buf_thresh[13] = 0x7D;
> > - }
> > + drm_dsc_set_rc_buf_thresh(vdsc_cfg);
> >
> > /*
> >* From XE_LPD onwards we supports compression bpps in steps of 1
> > diff --git a/include/drm/display/drm_dsc_helper.h
> > b/include/drm/display/drm_dsc_helper.h
> > index 8b41edbbabab..706ba1d34742 100644
> > --- a/include/drm/display/drm_dsc_helper.h
> > +++ b/include/drm/display/drm_dsc_helper.h
> > @@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct
Re: [Intel-gfx] [PATCH v5 14/19] vfio: Make vfio_device_open() single open for device cdev path
On Tue, Feb 28, 2023 at 03:11:34AM +, Liu, Yi L wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, February 28, 2023 2:52 AM > > > > On Mon, Feb 27, 2023 at 03:11:30AM -0800, Yi Liu wrote: > > > @@ -535,7 +542,8 @@ static int vfio_device_fops_release(struct inode > > *inode, struct file *filep) > > > struct vfio_device_file *df = filep->private_data; > > > struct vfio_device *device = df->device; > > > > > > - vfio_device_group_close(df); > > > + if (!df->is_cdev_device) > > > + vfio_device_group_close(df); > > > > This hunk should go in another patch > > Patch 15 or 16? Which one is your preference? To me, I guess patch > 15 is better since the user may open cdev fds after it. But its release > op should not call vfio_device_group_close(); It should go with the patch that allows creating the struct file withotu calling vfio_device_group_open() Jason
Re: [Intel-gfx] [PATCH v5 11/19] vfio-iommufd: Add detach_ioas support for physical VFIO devices
On Tue, Feb 28, 2023 at 02:57:42AM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, February 28, 2023 2:45 AM
> >
> > On Mon, Feb 27, 2023 at 03:11:27AM -0800, Yi Liu wrote:
> > > diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c b/drivers/vfio/fsl-
> > mc/vfio_fsl_mc.c
> > > index c89a047a4cd8..d540cf683d93 100644
> > > --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> > > +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> > > @@ -594,6 +594,7 @@ static const struct vfio_device_ops
> > vfio_fsl_mc_ops = {
> > > .bind_iommufd = vfio_iommufd_physical_bind,
> > > .unbind_iommufd = vfio_iommufd_physical_unbind,
> > > .attach_ioas= vfio_iommufd_physical_attach_ioas,
> > > + .detach_ioas= vfio_iommufd_physical_detach_ioas,
> > > };
> > >
> > > static struct fsl_mc_driver vfio_fsl_mc_driver = {
> > > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > > index beef6ca21107..bfaa9876499b 100644
> > > --- a/drivers/vfio/iommufd.c
> > > +++ b/drivers/vfio/iommufd.c
> > > @@ -88,6 +88,14 @@ int vfio_iommufd_physical_attach_ioas(struct
> > vfio_device *vdev, u32 *pt_id)
> > > {
> > > int rc;
> > >
> > > + lockdep_assert_held(>dev_set->lock);
> > > +
> > > + if (!vdev->iommufd_device)
> > > + return -EINVAL;
> >
> > This should be a WARN_ON. The vdev->iommufd_ctx should be NULL if it
> > hasn't been bound, and it can't be bound unless the
> > iommufd_device/attach was created.
>
> sure. But it is a user-triggerable warn. If userspace triggers it on
> purpose, will it be a bad thing for kernel? Maybe use
> dev_warn_ratelimited()?
How can it be user triggerable? You shouldn't be able to reach this
function until the device is bound because the ioctl should be after
the is it bound check
Jason
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
On Tue, Feb 28, 2023 at 02:51:28AM +, Liu, Yi L wrote: > > This seems strange. no iommu mode should have a NULL dev->iommufctx. > > Why do we have a df->noiommu at all? > > This is due to the vfio_device_first_open(). Detail as below comment (part of > patch 0016). > > + /* > + * For group/container path, iommufd pointer is NULL when comes > + * into this helper. Its noiommu support is handled by > + * vfio_device_group_use_iommu() > + * > + * For iommufd compat mode, iommufd pointer here is a valid value. > + * Its noiommu support is in vfio_iommufd_bind(). > + * > + * For device cdev path, iommufd pointer here is a valid value for > + * normal cases, but it is NULL if it's noiommu. Check df->noiommu > + * to differentiate cdev noiommu from the group/container path which > + * also passes NULL iommufd pointer in. If set then do nothing. > + */ If the group is in iommufd mode then it should set this pointer too. Jason
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
On Tue, Feb 28, 2023 at 06:58:38AM +, Liu, Yi L wrote: > Seems like pt_id is no more needed in the vfio_iommufd_bind() > since it can get compat_ioas_id in the function itself. Cdev path > never passes a pt_id to vfio_iommufd_bind() as its attach is done > by separate ATTACH ioctl. Can we use the dev_id pointer to indicate > if it needs to get the compat ioas and attach it? In this case you need to split the group code to also use the two step attach and then the attach will take in the null pt_id. Jason
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
On Tue, Feb 28, 2023 at 02:35:25AM +, Liu, Yi L wrote: > > And the commit message is sort of out of sync with the patch, more like: > > > > vfio: Pass the pt_id as an argument to vfio_iommufd_bind() > > > > To support binding the cdev the pt_id must come from userspace instead > > of being forced to the compat_ioas_id. > > > > Got it. not only pt_id, also dev_id. Maybe dev_id should be read back from the iommufd_device pointer in the vfio_device. It is trivially stored in that memory already Jason
Re: [Intel-gfx] [PATCH 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
> The rc_buf_thresh values are common to all DSC implementations. Move
> them to the common helper together with the code to propagage them to
> the drm_dsc_config.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/display/drm_dsc_helper.c | 37 +++
> drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +--
> include/drm/display/drm_dsc_helper.h | 1 +
> 3 files changed, 39 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index c869c6e51e2b..ab8679c158b5 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -270,6 +270,43 @@ void drm_dsc_pps_payload_pack(struct
> drm_dsc_picture_parameter_set *pps_payload,
> }
> EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
>
> +/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
> +const u16 drm_dsc_rc_buf_thresh[] = {
> + 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> + 7744, 7872, 8000, 8064
> +};
> +EXPORT_SYMBOL(drm_dsc_rc_buf_thresh);
This needs to be static, without exports.
> +
> +/**
> + * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
> + * in accordance with the DSC 1.2 specification.
> + *
> + * @vdsc_cfg: DSC Configuration data partially filled by driver
> + */
> +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
> +{
> + int i = 0;
Unnecessary initialization.
> +
> + for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
Please use ARRAY_SIZE(). Maybe add BUILD_BUG_ON() for DSC_NUM_BUF_RANGES
vs. ARRAY_SIZE(). (Yes, we should've used ARRAY_SIZE() in i915.)
> + /*
> + * six 0s are appended to the lsb of each threshold value
> + * internally in h/w.
> + * Only 8 bits are allowed for programming RcBufThreshold
> + */
> + vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
> + }
> +
> + /*
> + * For 6bpp, RC Buffer threshold 12 and 13 need a different value
> + * as per C Model
> + */
> + if (vdsc_cfg->bits_per_pixel == 6 << 4) {
> + vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
> + vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
> + }
> +}
> +EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
> +
> /**
> * drm_dsc_compute_rc_parameters() - Write rate control
> * parameters to the dsc configuration defined in
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index d080741fd0b3..b4faab4c8fb3 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
> MAX_COLUMN_INDEX
> };
>
> -/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
> -static const u16 rc_buf_thresh[] = {
> - 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
> - 7744, 7872, 8000, 8064
> -};
> -
> struct rc_parameters {
> u16 initial_xmit_delay;
> u8 first_line_bpg_offset;
> @@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
> vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
>
> - for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
> - /*
> - * six 0s are appended to the lsb of each threshold value
> - * internally in h/w.
> - * Only 8 bits are allowed for programming RcBufThreshold
> - */
> - vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
> - }
> -
> - /*
> - * For 6bpp, RC Buffer threshold 12 and 13 need a different value
> - * as per C Model
> - */
> - if (compressed_bpp == 6) {
> - vdsc_cfg->rc_buf_thresh[12] = 0x7C;
> - vdsc_cfg->rc_buf_thresh[13] = 0x7D;
> - }
> + drm_dsc_set_rc_buf_thresh(vdsc_cfg);
>
> /*
>* From XE_LPD onwards we supports compression bpps in steps of 1
> diff --git a/include/drm/display/drm_dsc_helper.h
> b/include/drm/display/drm_dsc_helper.h
> index 8b41edbbabab..706ba1d34742 100644
> --- a/include/drm/display/drm_dsc_helper.h
> +++ b/include/drm/display/drm_dsc_helper.h
> @@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
> *pps_header);
> int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
> void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
> const struct drm_dsc_config *dsc_cfg);
> +void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
> int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
>
> #endif /* _DRM_DSC_HELPER_H_ */
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move DSC RC tables to drm_dsc_helper.c
== Series Details == Series: drm/i915: move DSC RC tables to drm_dsc_helper.c URL : https://patchwork.freedesktop.org/series/114473/ State : success == Summary == CI Bug Log - changes from CI_DRM_12790 -> Patchwork_114473v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/index.html Participating hosts (2 -> 36) -- Additional (35): fi-rkl-11600 bat-dg1-6 bat-dg1-5 bat-adlp-6 fi-apl-guc fi-pnv-d510 bat-rpls-1 fi-blb-e6850 bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-ilk-650 fi-hsw-4770 bat-adln-1 fi-ivb-3770 bat-jsl-3 bat-rplp-1 fi-elk-e7500 bat-dg2-11 fi-bsw-nick fi-kbl-7567u bat-dg1-7 bat-adlp-9 fi-skl-guc fi-cfl-8700k fi-glk-j4005 bat-jsl-1 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc fi-kbl-x1275 fi-cfl-8109u Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114473v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-skl-guc: NOTRUN -> [SKIP][1] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-skl-guc/igt@debugfs_t...@basic-hwmon.html - bat-rpls-2: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-rpls-2/igt@debugfs_t...@basic-hwmon.html - fi-glk-j4005: NOTRUN -> [SKIP][3] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-glk-j4005/igt@debugfs_t...@basic-hwmon.html - fi-hsw-4770:NOTRUN -> [SKIP][4] ([fdo#109271]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-hsw-4770/igt@debugfs_t...@basic-hwmon.html - fi-cfl-8109u: NOTRUN -> [SKIP][5] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-cfl-8109u/igt@debugfs_t...@basic-hwmon.html - bat-adlp-9: NOTRUN -> [SKIP][6] ([i915#7456]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-adlp-9/igt@debugfs_t...@basic-hwmon.html - fi-kbl-7567u: NOTRUN -> [SKIP][7] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-kbl-7567u/igt@debugfs_t...@basic-hwmon.html - bat-adln-1: NOTRUN -> [SKIP][8] ([i915#7456]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-adln-1/igt@debugfs_t...@basic-hwmon.html - fi-ivb-3770:NOTRUN -> [SKIP][9] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-ivb-3770/igt@debugfs_t...@basic-hwmon.html - fi-elk-e7500: NOTRUN -> [SKIP][10] ([fdo#109271]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-elk-e7500/igt@debugfs_t...@basic-hwmon.html - fi-cfl-8700k: NOTRUN -> [SKIP][11] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-cfl-8700k/igt@debugfs_t...@basic-hwmon.html - bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#7456]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html - fi-ilk-650: NOTRUN -> [SKIP][13] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-ilk-650/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][14] ([i915#7456]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html - fi-tgl-1115g4: NOTRUN -> [SKIP][15] ([i915#7456]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-tgl-1115g4/igt@debugfs_t...@basic-hwmon.html - bat-adlp-6: NOTRUN -> [SKIP][16] ([i915#7456]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-adlp-6/igt@debugfs_t...@basic-hwmon.html - bat-rplp-1: NOTRUN -> [SKIP][17] ([i915#7456]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-rplp-1/igt@debugfs_t...@basic-hwmon.html - fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#7456]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html - fi-bsw-n3050: NOTRUN -> [SKIP][19] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-bsw-n3050/igt@debugfs_t...@basic-hwmon.html - bat-rpls-1: NOTRUN -> [SKIP][20] ([i915#7456]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/bat-rpls-1/igt@debugfs_t...@basic-hwmon.html - fi-apl-guc: NOTRUN -> [SKIP][21] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114473v1/fi-apl-guc/igt@debugfs_t...@basic-hwmon.html - fi-cfl-guc: NOTRUN -> [SKIP][22] ([fdo#109271]) [22]:
[Intel-gfx] [PATCH 08/10] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 438 +++
include/drm/display/drm_dsc_helper.h | 2 +
2 files changed, 440 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 1612536014ea..d11ee8f1efa7 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -742,6 +742,438 @@ static const struct rc_parameters_data
rc_parameters_1_2_444[] = {
{ /* sentinel */ }
};
+static const struct rc_parameters_data rc_parameters_1_2_422[] = {
+{ DSC_BPP(6), 8,
+ /* 12BPP/8BPC */
+ { 512, 15, 6144, 3, 12, 11, 11, {
+ { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, -12 },
+ { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
+ }
+ }
+},
+{ DSC_BPP(6), 10,
+ /* 12BPP/10BPC */
+ { 512, 15, 6144, 7, 16, 15, 15, {
+ { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15, -12 },
+ { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
+ }
+ }
+},
+{ DSC_BPP(6), 12,
+ /* 12BPP/12BPC */
+ { 512, 15, 6144, 11, 20, 19, 19, {
+ { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
+ { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
+ { 20, 21, -12 }
+ }
+ }
+},
+{ DSC_BPP(6), 14,
+ /* 12BPP/14BPC */
+ { 512, 15, 6144, 15, 24, 23, 23, {
+ { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+ { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
+ { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
+ { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
+ { 24, 25, -12 }
+ }
+ }
+},
+{ DSC_BPP(6), 16,
+ /* 12BPP/16BPC */
+ { 512, 15, 6144, 19, 28, 27, 27, {
+ { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2 },
+ { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19, 24, -8 },
+ { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
+ { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
+ { 28, 29, -12 }
+ }
+ }
+},
+{ DSC_BPP(7), 8,
+ /* 14BPP/8BPC */
+ { 410, 15, 5632, 3, 12, 11, 11, {
+ { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10, -10 },
+ { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
+ }
+ }
+},
+{ DSC_BPP(7), 10,
+ /* 14BPP/10BPC */
+ { 410, 15, 5632, 7, 16, 15, 15, {
+ { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
+ { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14, -10 },
+ { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
+ }
+ }
+},
+{ DSC_BPP(7), 12,
+ /* 14BPP/12BPC */
+ { 410, 15, 5632, 11, 20, 19, 19, {
+ { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
+ { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+ { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
+ { 19, 20, -12 }
+ }
+ }
+},
+{ DSC_BPP(7), 14,
+ /* 14BPP/14BPC */
+ { 410, 15, 5632, 15, 24, 23, 23, {
+ { 0, 11, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 13, 18, -2 },
+ { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
+ { 15, 21, -8 }, { 15, 21, -10 }, { 17, 22, -10 },
+ { 17, 22, -10 }, { 17, 23, -12 }, { 19, 23, -12 },
+ { 23, 24, -12 }
+ }
+ }
+},
+{ DSC_BPP(7), 16,
+ /* 14BPP/16BPC */
+ { 410, 15, 5632, 19, 28, 27, 27, {
+ { 0, 11, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 16, 20, -2 },
+ { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19, 24, -8 },
+ { 19, 25, -8 }, { 19, 25, -10 }, { 21, 26, -10 },
+ { 21, 26, -10 }, { 21, 27, -12 }, { 23, 27, -12 },
+ { 27, 28, -12 }
+ }
+ }
+},
+{ DSC_BPP(8), 8,
+ /* 16BPP/8BPC */
+ { 341, 15, 2048,
[Intel-gfx] [PATCH 09/10] drm/display/dsc: add helper to set semi-const parameters
Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 21 +
include/drm/display/drm_dsc_helper.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index d11ee8f1efa7..7de1d84f5bc7 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,27 @@ void drm_dsc_pps_payload_pack(struct
drm_dsc_picture_parameter_set *pps_payload,
}
EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
+/**
+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+ vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+ vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+ vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+ vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+ if (vdsc_cfg->bits_per_component <= 10)
+ vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+ else
+ vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h
b/include/drm/display/drm_dsc_helper.h
index 0bb0c3afd740..4448c482b092 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
*pps_header);
int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
drm_dsc_params_kind kind);
int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
--
2.39.2
[Intel-gfx] [PATCH 10/10] drm/msm/dsi: use new helpers for DSC setup
Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 61 --
1 file changed, 8 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 18fa30e1e858..dda989727921 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1735,28 +1735,9 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host
*msm_host,
return -EINVAL;
}
-static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
- 0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
- 0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
-};
-
-/* only 8bpc, 8bpp added */
-static char min_qp[DSC_NUM_BUF_RANGES] = {
- 0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
-};
-
-static char max_qp[DSC_NUM_BUF_RANGES] = {
- 4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
-};
-
-static char bpg_offset[DSC_NUM_BUF_RANGES] = {
- 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-};
-
static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct
drm_dsc_config *dsc)
{
- int i;
- u16 bpp = dsc->bits_per_pixel >> 4;
+ int ret;
if (dsc->bits_per_pixel & 0xf) {
DRM_DEV_ERROR(_host->pdev->dev, "DSI does not support
fractional bits_per_pixel\n");
@@ -1768,49 +1749,23 @@ static int dsi_populate_dsc_params(struct msm_dsi_host
*msm_host, struct drm_dsc
return -EOPNOTSUPP;
}
- dsc->rc_model_size = 8192;
- dsc->first_line_bpg_offset = 12;
- dsc->rc_edge_factor = 6;
- dsc->rc_tgt_offset_high = 3;
- dsc->rc_tgt_offset_low = 3;
dsc->simple_422 = 0;
dsc->convert_rgb = 1;
dsc->vbr_enable = 0;
- /* handle only bpp = bpc = 8 */
- for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
- dsc->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+ drm_dsc_set_const_params(dsc);
+ drm_dsc_set_rc_buf_thresh(dsc);
- for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
- dsc->rc_range_params[i].range_min_qp = min_qp[i];
- dsc->rc_range_params[i].range_max_qp = max_qp[i];
- /*
-* Range BPG Offset contains two's-complement signed values
that fill
-* 8 bits, yet the registers and DCS PPS field are only 6 bits
wide.
-*/
- dsc->rc_range_params[i].range_bpg_offset = bpg_offset[i] &
DSC_RANGE_BPG_OFFSET_MASK;
+ /* handle only bpp = bpc = 8, pre-SCR panels */
+ ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
+ if (ret) {
+ DRM_DEV_ERROR(_host->pdev->dev, "could not find DSC RC
parameters\n");
+ return ret;
}
- dsc->initial_offset = 6144; /* Not bpp 12 */
- if (bpp != 8)
- dsc->initial_offset = 2048; /* bpp = 12 */
-
- if (dsc->bits_per_component <= 10)
- dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
- else
- dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
-
- dsc->initial_xmit_delay = 512;
dsc->initial_scale_value = 32;
- dsc->first_line_bpg_offset = 12;
dsc->line_buf_depth = dsc->bits_per_component + 1;
- /* bpc 8 */
- dsc->flatness_min_qp = 3;
- dsc->flatness_max_qp = 12;
- dsc->rc_quant_incr_limit0 = 11;
- dsc->rc_quant_incr_limit1 = 11;
-
return drm_dsc_compute_rc_parameters(dsc);
}
--
2.39.2
[Intel-gfx] [PATCH 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in
preparation to adding more configuration data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 127 ++
drivers/gpu/drm/i915/display/intel_vdsc.c | 10 +-
include/drm/display/drm_dsc_helper.h | 7 +-
3 files changed, 119 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index a6d11f474656..51794b40526a 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -326,11 +326,81 @@ struct rc_parameters_data {
#define DSC_BPP(bpp) ((bpp) << 4)
+static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+{ DSC_BPP(8), 8,
+ /* 8BPP/8BPC */
+ { 512, 12, 6144, 3, 12, 11, 11, {
+ { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
+ { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+},
+{ DSC_BPP(8), 10,
+ /* 8BPP/10BPC */
+ { 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+ { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
+ { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+},
+{ DSC_BPP(8), 12,
+ /* 8BPP/12BPC */
+ { 512, 12, 6144, 11, 20, 19, 19, {
+ { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+ { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+},
+{ DSC_BPP(12), 8,
+ /* 12BPP/8BPC */
+ { 341, 15, 2048, 3, 12, 11, 11, {
+ { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
+ { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+},
+{ DSC_BPP(12), 10,
+ /* 12BPP/10BPC */
+ { 341, 15, 2048, 7, 16, 15, 15, {
+ { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
+ { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
+ { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+},
+{ DSC_BPP(12), 12,
+ /* 12BPP/12BPC */
+ { 341, 15, 2048, 11, 20, 19, 19, {
+ { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
+ { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+ { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+},
+{ /* sentinel */ }
+};
+
/*
* Selected Rate Control Related Parameter Recommended Values
* from DSC_v1.11 spec & C Model release: DSC_model_20161212
*/
-static const struct rc_parameters_data rc_parameters[] = {
+static const struct rc_parameters_data rc_parameters_1_2_444[] = {
{ DSC_BPP(6), 8,
/* 6BPP/8BPC */
{ 768, 15, 6144, 3, 13, 11, 11, {
@@ -390,22 +460,18 @@ static const struct rc_parameters_data rc_parameters[] = {
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
- { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
- { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, -12 },
+ { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
}
}
},
{ DSC_BPP(8), 10,
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
- /*
-* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
-* VESA DSC 1.1 Table E-5 sets it to 4.
-*/
- { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
- { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9,
[Intel-gfx] [PATCH 07/10] drm/display/dsc: include the rest of pre-SCR parameters
DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 72
1 file changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 51794b40526a..1612536014ea 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -327,6 +327,16 @@ struct rc_parameters_data {
#define DSC_BPP(bpp) ((bpp) << 4)
static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+{ DSC_BPP(6), 8,
+ /* 6BPP/8BPC */
+ { 683, 15, 6144, 3, 13, 11, 11, {
+ { 0, 2, 0 }, { 1, 4, -2 }, { 3, 6, -2 }, { 4, 6, -4 },
+ { 5, 7, -6 }, { 5, 7, -6 }, { 6, 7, -6 }, { 6, 8, -8 },
+ { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 }, { 10, 12, -12 },
+ { 10, 13, -12 }, { 12, 14, -12 }, { 15, 15, -12 }
+ }
+ }
+},
{ DSC_BPP(8), 8,
/* 8BPP/8BPC */
{ 512, 12, 6144, 3, 12, 11, 11, {
@@ -362,6 +372,37 @@ static const struct rc_parameters_data
rc_parameters_pre_scr[] = {
}
}
},
+{ DSC_BPP(10), 8,
+ /* 10BPP/8BPC */
+ { 410, 12, 5632, 3, 12, 11, 11, {
+ { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 11, -10 },
+ { 5, 12, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+},
+{ DSC_BPP(10), 10,
+ /* 10BPP/10BPC */
+ { 410, 12, 5632, 7, 16, 15, 15, {
+ { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
+ { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 15, -10 },
+ { 9, 16, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+},
+{ DSC_BPP(10), 12,
+ /* 10BPP/12BPC */
+ { 410, 12, 5632, 11, 20, 19, 19, {
+ { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
+ { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+ { 13, 19, -10 }, { 13, 20, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+},
{ DSC_BPP(12), 8,
/* 12BPP/8BPC */
{ 341, 15, 2048, 3, 12, 11, 11, {
@@ -393,6 +434,37 @@ static const struct rc_parameters_data
rc_parameters_pre_scr[] = {
}
}
},
+{ DSC_BPP(15), 8,
+ /* 15BPP/8BPC */
+ { 273, 15, 2048, 3, 12, 11, 11, {
+ { 0, 0, 10 }, { 0, 1, 8 }, { 0, 1, 6 }, { 0, 2, 4 },
+ { 1, 2, 2 }, { 1, 3, 0 }, { 1, 4, -2 }, { 2, 4, -4 },
+ { 3, 4, -6 }, { 3, 5, -8 }, { 4, 6, -10 }, { 5, 7, -10 },
+ { 5, 8, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ }
+},
+{ DSC_BPP(15), 10,
+ /* 15BPP/10BPC */
+ { 273, 15, 2048, 7, 16, 15, 15, {
+ { 0, 2, 10 }, { 2, 5, 8 }, { 3, 5, 6 }, { 4, 6, 4 },
+ { 5, 6, 2 }, { 5, 7, 0 }, { 5, 8, -2 }, { 6, 8, -4 },
+ { 7, 8, -6 }, { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 },
+ { 9, 12, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ }
+},
+{ DSC_BPP(15), 12,
+ /* 15BPP/12BPC */
+ { 273, 15, 2048, 11, 20, 19, 19, {
+ { 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
+ { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 },
+ { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
+ { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
+ { 21, 23, -12 }
+ }
+ }
+},
{ /* sentinel */ }
};
--
2.39.2
[Intel-gfx] [PATCH 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper
This moves DSC RC tables to DRM DSC helper. No additional code changes
and/or cleanups are a part of this commit, it will be cleaned up in the
followup commits.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 364 ++
drivers/gpu/drm/i915/display/intel_vdsc.c | 319 +--
include/drm/display/drm_dsc_helper.h | 1 +
3 files changed, 372 insertions(+), 312 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index ab8679c158b5..deaa84722bd4 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -307,6 +307,370 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config
*vdsc_cfg)
}
EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+enum ROW_INDEX_BPP {
+ ROW_INDEX_6BPP = 0,
+ ROW_INDEX_8BPP,
+ ROW_INDEX_10BPP,
+ ROW_INDEX_12BPP,
+ ROW_INDEX_15BPP,
+ MAX_ROW_INDEX
+};
+
+enum COLUMN_INDEX_BPC {
+ COLUMN_INDEX_8BPC = 0,
+ COLUMN_INDEX_10BPC,
+ COLUMN_INDEX_12BPC,
+ COLUMN_INDEX_14BPC,
+ COLUMN_INDEX_16BPC,
+ MAX_COLUMN_INDEX
+};
+
+struct rc_parameters {
+ u16 initial_xmit_delay;
+ u8 first_line_bpg_offset;
+ u16 initial_offset;
+ u8 flatness_min_qp;
+ u8 flatness_max_qp;
+ u8 rc_quant_incr_limit0;
+ u8 rc_quant_incr_limit1;
+ struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+};
+
+/*
+ * Selected Rate Control Related Parameter Recommended Values
+ * from DSC_v1.11 spec & C Model release: DSC_model_20161212
+ */
+static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+{
+ /* 6BPP/8BPC */
+ { 768, 15, 6144, 3, 13, 11, 11, {
+ { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
+ { 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
+ { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 12, -12 },
+ { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
+ }
+ },
+ /* 6BPP/10BPC */
+ { 768, 15, 6144, 7, 17, 15, 15, {
+ { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 },
+ { 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, -8 },
+ { 11, 15, -8 }, { 12, 16, -10 }, { 13, 16, -10 },
+ { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
+ { 17, 18, -12 }
+ }
+ },
+ /* 6BPP/12BPC */
+ { 768, 15, 6144, 11, 21, 19, 19, {
+ { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, -4 },
+ { 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 18, -8 },
+ { 15, 19, -8 }, { 16, 20, -10 }, { 17, 20, -10 },
+ { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
+ { 21, 22, -12 }
+ }
+ },
+ /* 6BPP/14BPC */
+ { 768, 15, 6144, 15, 25, 23, 23, {
+ { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
+ { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
+ { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
+ { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
+ { 25, 26, -12 }
+ }
+ },
+ /* 6BPP/16BPC */
+ { 768, 15, 6144, 19, 29, 27, 27, {
+ { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, -4 },
+ { 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 26, -8 },
+ { 23, 27, -8 }, { 24, 28, -10 }, { 25, 28, -10 },
+ { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
+ { 29, 30, -12 }
+ }
+ },
+},
+{
+ /* 8BPP/8BPC */
+ { 512, 12, 6144, 3, 12, 11, 11, {
+ { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+ { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+ { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
+ { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+ }
+ },
+ /* 8BPP/10BPC */
+ { 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+ { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+ { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
+ { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
+ { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+ }
+ },
+ /* 8BPP/12BPC */
+ { 512, 12, 6144, 11, 20, 19, 19, {
+ { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+ { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 16, -8 },
+ { 11, 17, -8 }, { 11, 18, -10 }, { 13,
[Intel-gfx] [PATCH 04/10] drm/i915/dsc: stop using interim structure for calculated params
Stop using an interim structure rc_parameters for storing calculated
params and then setting drm_dsc_config using that structure. Instead put
calculated params into the struct drm_dsc_config directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 89 +--
1 file changed, 20 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d5a7e9494b23..1ee8d13c9d64 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -18,17 +18,6 @@
#include "intel_qp_tables.h"
#include "intel_vdsc.h"
-struct rc_parameters {
- u16 initial_xmit_delay;
- u8 first_line_bpg_offset;
- u16 initial_offset;
- u8 flatness_min_qp;
- u8 flatness_max_qp;
- u8 rc_quant_incr_limit0;
- u8 rc_quant_incr_limit1;
- struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
-};
-
bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
{
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -63,8 +52,7 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum
transcoder cpu_transcoder)
}
static void
-calculate_rc_params(struct rc_parameters *rc,
- struct drm_dsc_config *vdsc_cfg)
+calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
{
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
@@ -84,54 +72,54 @@ calculate_rc_params(struct rc_parameters *rc,
u32 res, buf_i, bpp_i;
if (vdsc_cfg->slice_height >= 8)
- rc->first_line_bpg_offset =
+ vdsc_cfg->first_line_bpg_offset =
12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height -
8)), 100);
else
- rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
+ vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height -
1);
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
- rc->initial_offset = 2048;
+ vdsc_cfg->initial_offset = 2048;
else if (bpp >= 10)
- rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584),
2);
+ vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) *
3584), 2);
else if (bpp >= 8)
- rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
+ vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) *
512), 2);
else
- rc->initial_offset = 6144;
+ vdsc_cfg->initial_offset = 6144;
/* initial_xmit_delay = rc_model_size/2/compression_bpp */
- rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
+ vdsc_cfg->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2
* bpp);
- rc->flatness_min_qp = 3 + qp_bpc_modifier;
- rc->flatness_max_qp = 12 + qp_bpc_modifier;
+ vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
+ vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
- rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
- rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
+ vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
+ vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
bpp_i = (2 * (bpp - 6));
for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
/* Read range_minqp and range_max_qp from qp tables */
- rc->rc_range_params[buf_i].range_min_qp =
+ vdsc_cfg->rc_range_params[buf_i].range_min_qp =
intel_lookup_range_min_qp(bpc, buf_i, bpp_i);
- rc->rc_range_params[buf_i].range_max_qp =
+ vdsc_cfg->rc_range_params[buf_i].range_max_qp =
intel_lookup_range_max_qp(bpc, buf_i, bpp_i);
/* Calculate range_bgp_offset */
if (bpp <= 6) {
- rc->rc_range_params[buf_i].range_bpg_offset =
ofs_und6[buf_i];
+ vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
ofs_und6[buf_i];
} else if (bpp <= 8) {
res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] -
ofs_und6[buf_i])), 2);
- rc->rc_range_params[buf_i].range_bpg_offset =
+ vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
ofs_und6[buf_i]
+ res;
} else if (bpp <= 12) {
- rc->rc_range_params[buf_i].range_bpg_offset =
+ vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
ofs_und8[buf_i];
} else if (bpp <= 15) {
res = DIV_ROUND_UP(((bpp - 12) * (ofs_und15[buf_i] -
ofs_und12[buf_i])),
[Intel-gfx] [PATCH 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper
The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagage them to
the drm_dsc_config.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 37 +++
drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +--
include/drm/display/drm_dsc_helper.h | 1 +
3 files changed, 39 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index c869c6e51e2b..ab8679c158b5 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,43 @@ void drm_dsc_pps_payload_pack(struct
drm_dsc_picture_parameter_set *pps_payload,
}
EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
+/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
+const u16 drm_dsc_rc_buf_thresh[] = {
+ 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
+ 7744, 7872, 8000, 8064
+};
+EXPORT_SYMBOL(drm_dsc_rc_buf_thresh);
+
+/**
+ * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
+ * in accordance with the DSC 1.2 specification.
+ *
+ * @vdsc_cfg: DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
+{
+ int i = 0;
+
+ for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
+ /*
+* six 0s are appended to the lsb of each threshold value
+* internally in h/w.
+* Only 8 bits are allowed for programming RcBufThreshold
+*/
+ vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
+ }
+
+ /*
+* For 6bpp, RC Buffer threshold 12 and 13 need a different value
+* as per C Model
+*/
+ if (vdsc_cfg->bits_per_pixel == 6 << 4) {
+ vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
+ vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
+ }
+}
+EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+
/**
* drm_dsc_compute_rc_parameters() - Write rate control
* parameters to the dsc configuration defined in
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d080741fd0b3..b4faab4c8fb3 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -36,12 +36,6 @@ enum COLUMN_INDEX_BPC {
MAX_COLUMN_INDEX
};
-/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static const u16 rc_buf_thresh[] = {
- 896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
- 7744, 7872, 8000, 8064
-};
-
struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -474,23 +468,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
- for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
- /*
-* six 0s are appended to the lsb of each threshold value
-* internally in h/w.
-* Only 8 bits are allowed for programming RcBufThreshold
-*/
- vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
- }
-
- /*
-* For 6bpp, RC Buffer threshold 12 and 13 need a different value
-* as per C Model
-*/
- if (compressed_bpp == 6) {
- vdsc_cfg->rc_buf_thresh[12] = 0x7C;
- vdsc_cfg->rc_buf_thresh[13] = 0x7D;
- }
+ drm_dsc_set_rc_buf_thresh(vdsc_cfg);
/*
* From XE_LPD onwards we supports compression bpps in steps of 1
diff --git a/include/drm/display/drm_dsc_helper.h
b/include/drm/display/drm_dsc_helper.h
index 8b41edbbabab..706ba1d34742 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header
*pps_header);
int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
#endif /* _DRM_DSC_HELPER_H_ */
--
2.39.2
[Intel-gfx] [PATCH 05/10] drm/display/dsc: use flat array for rc_parameters lookup
Next commits are going to add support for additional RC parameter lookup
tables. These tables are going to use different bpp/bpc combinations,
thus it makes little sense to keep the 2d array for RC parameters.
Switch to using the flat array.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 188 +++
1 file changed, 88 insertions(+), 100 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
b/drivers/gpu/drm/display/drm_dsc_helper.c
index deaa84722bd4..a6d11f474656 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -307,24 +307,6 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config
*vdsc_cfg)
}
EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
-enum ROW_INDEX_BPP {
- ROW_INDEX_6BPP = 0,
- ROW_INDEX_8BPP,
- ROW_INDEX_10BPP,
- ROW_INDEX_12BPP,
- ROW_INDEX_15BPP,
- MAX_ROW_INDEX
-};
-
-enum COLUMN_INDEX_BPC {
- COLUMN_INDEX_8BPC = 0,
- COLUMN_INDEX_10BPC,
- COLUMN_INDEX_12BPC,
- COLUMN_INDEX_14BPC,
- COLUMN_INDEX_16BPC,
- MAX_COLUMN_INDEX
-};
-
struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -336,12 +318,20 @@ struct rc_parameters {
struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
};
+struct rc_parameters_data {
+ u8 bpp;
+ u8 bpc;
+ struct rc_parameters params;
+};
+
+#define DSC_BPP(bpp) ((bpp) << 4)
+
/*
* Selected Rate Control Related Parameter Recommended Values
* from DSC_v1.11 spec & C Model release: DSC_model_20161212
*/
-static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
-{
+static const struct rc_parameters_data rc_parameters[] = {
+{ DSC_BPP(6), 8,
/* 6BPP/8BPC */
{ 768, 15, 6144, 3, 13, 11, 11, {
{ 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
@@ -349,7 +339,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 12, -12 },
{ 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
}
- },
+ }
+},
+{ DSC_BPP(6), 10,
/* 6BPP/10BPC */
{ 768, 15, 6144, 7, 17, 15, 15, {
{ 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 },
@@ -358,7 +350,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
{ 17, 18, -12 }
}
- },
+ }
+},
+{ DSC_BPP(6), 12,
/* 6BPP/12BPC */
{ 768, 15, 6144, 11, 21, 19, 19, {
{ 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, -4 },
@@ -367,7 +361,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
{ 21, 22, -12 }
}
- },
+ }
+},
+{ DSC_BPP(6), 14,
/* 6BPP/14BPC */
{ 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
@@ -376,7 +372,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
{ 25, 26, -12 }
}
- },
+ }
+},
+{ DSC_BPP(6), 16,
/* 6BPP/16BPC */
{ 768, 15, 6144, 19, 29, 27, 27, {
{ 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, -4 },
@@ -385,9 +383,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
{ 29, 30, -12 }
}
- },
+ }
},
-{
+{ DSC_BPP(8), 8,
/* 8BPP/8BPC */
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
@@ -395,7 +393,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, -12 },
{ 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
}
- },
+ }
+},
+{ DSC_BPP(8), 10,
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
/*
@@ -407,7 +407,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
{ 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
}
- },
+ }
+},
+{ DSC_BPP(8), 12,
/* 8BPP/12BPC */
{ 512, 12, 6144, 11, 20, 19, 19, {
{ 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
@@ -416,7 +418,9 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
{ 21, 23, -12 }
}
[Intel-gfx] [PATCH 01/10] drm/i915/dsc: change DSC param tables to follow the DSC model
After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.
Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
the table in the VESA DSC 1.1 sets it to 4.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 207b2a648d32..d080741fd0b3 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -86,7 +86,7 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
}
},
/* 6BPP/14BPC */
- { 768, 15, 6144, 15, 25, 23, 27, {
+ { 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
{ 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
@@ -115,6 +115,10 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
+ /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
{ 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
@@ -132,7 +136,7 @@ static const struct rc_parameters
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/14BPC */
{ 512, 12, 6144, 15, 24, 23, 23, {
- { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+ { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
{ 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
{ 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
{ 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
@@ -529,6 +533,16 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
DSC_RANGE_BPG_OFFSET_MASK;
}
+ if (DISPLAY_VER(dev_priv) < 13) {
+ if (compressed_bpp == 6 &&
+ vdsc_cfg->bits_per_component == 8)
+ vdsc_cfg->rc_quant_incr_limit1 = 23;
+
+ if (compressed_bpp == 8 &&
+ vdsc_cfg->bits_per_component == 14)
+ vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
+ }
+
/*
* BitsPerComponent value determines mux_word_size:
* When BitsPerComponent is less than or 10bpc, muxWordSize will be
equal to
--
2.39.2
[Intel-gfx] [PATCH 00/10] drm/i915: move DSC RC tables to drm_dsc_helper.c
Other platforms (msm) will benefit from sharing the DSC config setup functions. This series moves parts of static DSC config data from the i915 driver to the common helpers to be used by other drivers. Note: the RC parameters were cross-checked against config files found in DSC model 2021062, 20161212 (and 20150914). The first patch modifies tables according to those config files, while preserving parameter values using the code. I have not changed one of the values in the pre-SCR config file as it clearly looks like a typo in the config file, considering the table E in DSC 1.1 and in the DSC 1.1 SCR. Dmitry Baryshkov (10): drm/i915/dsc: change DSC param tables to follow the DSC model drm/i915/dsc: move rc_buf_thresh values to common helper drm/i915/dsc: move DSC tables to DRM DSC helper drm/i915/dsc: stop using interim structure for calculated params drm/display/dsc: use flat array for rc_parameters lookup drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters drm/display/dsc: include the rest of pre-SCR parameters drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters drm/display/dsc: add helper to set semi-const parameters drm/msm/dsi: use new helpers for DSC setup drivers/gpu/drm/display/drm_dsc_helper.c | 1001 + drivers/gpu/drm/i915/display/intel_vdsc.c | 432 + drivers/gpu/drm/msm/dsi/dsi_host.c| 61 +- include/drm/display/drm_dsc_helper.h | 10 + 4 files changed, 1058 insertions(+), 446 deletions(-) -- 2.39.2
Re: [Intel-gfx] [RFC 0/2] Add new CDCLK step for RPL-U
> -Original Message- > From: Roper, Matthew D > Sent: Tuesday, February 28, 2023 6:06 AM > To: Borah, Chaitanya Kumar > Cc: intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Shankar, > Uma ; Syrjala, Ville ; > Srivatsa, Anusha ; Atwood, Matthew S > > Subject: Re: [RFC 0/2] Add new CDCLK step for RPL-U > > On Mon, Jan 30, 2023 at 03:38:04PM +0530, Chaitanya Kumar Borah wrote: > > A new step of 480MHz has been added on SKUs that have an RPL-U device > > id. This particular step is to support 120Hz panels more efficiently. > > > > This patchset adds a new table to include this new CDCLK step. Details > > can be found in BSpec entry 55409. > > Hi Chaitanya. It looks like we probably need one more change related to the > 480MHz rate beyond what was in this series. For platforms that support this > rate, we can set voltage level 1 (see bspec 49208) whereas the i915 code at > the moment will push it up to voltage level 2 instead. Hello Matt, Thank you for pointing it out. I will have a look and float a patch ASAP. Regards Chaitanya > > > Matt > > > > > Create a new sub-platform to identify RPL-U which will enable us to > > make the differentiation during CDCLK initialization. > > > > Furthermore, we need to make a distinction between ES (Engineering > > Sample) and QS (Quality Sample) parts as this change comes only to QS > > parts. This version of the patch does not include this change as we > > are yet to make a decision if this particular part needs to be > > upstreamed.(see comments on revision 2) > > > > Chaitanya Kumar Borah (2): > > drm/i915: Add RPL-U sub platform > > drm/i915/display: Add 480 MHz CDCLK steps for RPL-U > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 > ++ > > drivers/gpu/drm/i915/i915_drv.h| 2 ++ > > drivers/gpu/drm/i915/intel_device_info.c | 7 ++ > > drivers/gpu/drm/i915/intel_device_info.h | 1 + > > include/drm/i915_pciids.h | 12 ++ > > 5 files changed, 44 insertions(+), 4 deletions(-) > > > > -- > > 2.25.1 > > > > -- > Matt Roper > Graphics Software Engineer > Linux GPU Platform Enablement > Intel Corporation
