[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
== Series Details == Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC URL : https://patchwork.freedesktop.org/series/92088/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20500_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20500_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20500_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20500_full: ### IGT changes ### Possible regressions * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-skl9/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html Known issues Here are the changes found in Patchwork_20500_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][2] ([i915#3002]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-apl1/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-hostile-preempt: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][4] -> [TIMEOUT][5] ([i915#2369] / [i915#3063]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-skl5/igt@gem_...@unwedge-stress.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-skl5/igt@gem_...@unwedge-stress.html - shard-iclb: [PASS][6] -> [TIMEOUT][7] ([i915#2369] / [i915#2481] / [i915#3070]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-iclb3/igt@gem_...@unwedge-stress.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-iclb8/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-apl: [PASS][8] -> [SKIP][9] ([fdo#109271]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-apl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-apl7/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][10] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_whisper@basic-queues-forked: - shard-skl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-skl7/igt@gem_exec_whis...@basic-queues-forked.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-skl6/igt@gem_exec_whis...@basic-queues-forked.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-apl1/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-iclb: [PASS][14] -> [FAIL][15] ([i915#307]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-iclb4/igt@gem_mmap_...@big-copy-odd.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-iclb4/igt@gem_mmap_...@big-copy-odd.html * igt@gem_mmap_gtt@big-copy-xy: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#307]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-glk6/igt@gem_mmap_...@big-copy-xy.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-glk3/igt@gem_mmap_...@big-copy-xy.html * igt@gem_pwrite@basic-exhaustion: - shard-snb: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-snb5/igt@gem_pwr...@basic-exhaustion.html - shard-apl: NOTRUN -> [WARN][19] ([i915#2658]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-apl8/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#3323]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/shard-apl3/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][21] ([i915#3318]) [21]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
== Series Details ==
Series: drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
URL : https://patchwork.freedesktop.org/series/92094/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20501
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20501/index.html
Known issues
Here are the changes found in Patchwork_20501 that come from known issues:
### IGT changes ###
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717
Participating hosts (39 -> 34)
--
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-bdw-samus
fi-snb-2600
Build changes
-
* Linux: CI_DRM_10295 -> Patchwork_20501
CI-20190529: 20190529
CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20501: dc23ac4acc64b6b3596447a0623dcdc6c7ab5dea @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dc23ac4acc64 drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20501/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/dg1: Correctly map DPLLs during state readout
== Series Details ==
Series: drm/i915/display/dg1: Correctly map DPLLs during state readout
URL : https://patchwork.freedesktop.org/series/92086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20499_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20499_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20499_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20499_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-skl2/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-psr:
- {shard-rkl}:[FAIL][2] ([i915#2951]) -> [SKIP][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@i915_pm...@dc6-psr.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-1/igt@i915_pm...@dc6-psr.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- {shard-rkl}:[PASS][4] -> [SKIP][5] +66 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-1/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs:
- {shard-rkl}:NOTRUN -> [FAIL][6] +7 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-2/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs:
- {shard-rkl}:[FAIL][7] -> [SKIP][8] +9 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-5/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-6/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- {shard-rkl}:[PASS][9] -> [FAIL][10] +6 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- {shard-rkl}:[SKIP][11] -> [FAIL][12] +9 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-2/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
* igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs:
- {shard-rkl}:[SKIP][13] ([i915#533]) -> [FAIL][14] +4 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-2/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
* igt@kms_content_protection@atomic:
- {shard-rkl}:[SKIP][15] ([fdo#109300]) -> [SKIP][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-2/igt@kms_content_protect...@atomic.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-rapid-movement:
- {shard-rkl}:[SKIP][17] ([fdo#112022]) -> [SKIP][18] +5 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-5/igt@kms_cursor_...@pipe-a-cursor-64x64-rapid-movement.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/shard-rkl-1/igt@kms_cursor_...@pipe-a-cursor-64x64-rapid-movement.html
* igt@kms_cursor_crc@pipe-b-cursor-max-size-onscreen:
- {shard-rkl}:[SKIP][19] ([i915#3359]) -> [SKIP][20] +4 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_cursor_...@pipe-b-cursor-max-size-onscreen.html
[20]:
[Intel-gfx] [PATCH 1/1] drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
From: Clint Taylor
The PUNIT FW is currently returning 0 for all memory bandwidth
parameters. Read the values directly from MCHBAR offsets 0x5918 and
0x4000(4).
v2 (Lucas): tidy up checking for ret slightly
v3 (Lucas):
- Squash change to double the memory bandwidth based on
MCHBAR Gear_type
- Move ICL_GEAR_TYPE_MASK to the appropriate place and change prefix
to DG1
- Move register definitions to i915_reg.h
- Make the MCHBAR path permanent for DG1
- Convert to REG_BIT()/REG_GENMASK()
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Jani Saarinen
Signed-off-by: Clint Taylor
Signed-off-by: Jani Nikula
Signed-off-by: Matthew Auld
Reviewed-by: Lucas De Marchi
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_bw.c | 41 -
drivers/gpu/drm/i915/i915_reg.h | 12
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
b/drivers/gpu/drm/i915/display/intel_bw.c
index bfb398f0432e..c913c2151680 100644
--- a/drivers/gpu/drm/i915/display/intel_bw.c
+++ b/drivers/gpu/drm/i915/display/intel_bw.c
@@ -23,6 +23,41 @@ struct intel_qgv_info {
u8 t_bl;
};
+static int dg1_mchbar_read_qgv_point_info(struct drm_i915_private *dev_priv,
+ struct intel_qgv_point *sp,
+ int point)
+{
+ u32 dclk_ratio = 0, dclk_reference = 0;
+ u32 val = 0;
+
+ val = intel_uncore_read(_priv->uncore,
SA_PERF_STATUS_0_0_0_MCHBAR_PC);
+ dclk_ratio = REG_FIELD_GET(DG1_QCLK_RATIO_MASK, val);
+ if (val & DG1_QCLK_REFERENCE)
+ dclk_reference = 6; /* 6 * 16.666 MHz = 100 MHz */
+ else
+ dclk_reference = 8; /* 8 * 16.666 MHz = 133 MHz */
+ sp->dclk = dclk_ratio * dclk_reference;
+
+ val = intel_uncore_read(_priv->uncore,
SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
+ if (val & DG1_GEAR_TYPE)
+ sp->dclk *= 2;
+
+ if (sp->dclk == 0)
+ return -EINVAL;
+
+ val = intel_uncore_read(_priv->uncore,
MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR);
+ sp->t_rp = REG_FIELD_GET(DG1_DRAM_T_RP_MASK, val);
+ sp->t_rdpre = REG_FIELD_GET(DG1_DRAM_T_RDPRE_MASK, val);
+
+ val = intel_uncore_read(_priv->uncore,
MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR_HIGH);
+ sp->t_rcd = REG_FIELD_GET(DG1_DRAM_T_RCD_MASK, val);
+ sp->t_ras = REG_FIELD_GET(DG1_DRAM_T_RAS_MASK, val);
+
+ sp->t_rc = sp->t_rp + sp->t_ras;
+
+ return 0;
+}
+
static int icl_pcode_read_qgv_point_info(struct drm_i915_private *dev_priv,
struct intel_qgv_point *sp,
int point)
@@ -99,7 +134,11 @@ static int icl_get_qgv_points(struct drm_i915_private
*dev_priv,
for (i = 0; i < qi->num_points; i++) {
struct intel_qgv_point *sp = >points[i];
- ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
+ if (IS_DG1(dev_priv))
+ ret = dg1_mchbar_read_qgv_point_info(dev_priv, sp, i);
+ else
+ ret = icl_pcode_read_qgv_point_info(dev_priv, sp, i);
+
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65c155b14189..182190da3036 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -11063,6 +11063,7 @@ enum skl_power_gate {
#define SKL_MEMORY_FREQ_MULTIPLIER_HZ 2
#define SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x5E04)
#define SKL_REQ_DATA_MASK (0xF << 0)
+#define DG1_GEAR_TYPE REG_BIT(16)
#define SKL_MAD_INTER_CHANNEL_0_0_0_MCHBAR_MCMAIN _MMIO(MCHBAR_MIRROR_BASE_SNB
+ 0x5000)
#define SKL_DRAM_DDR_TYPE_MASK(0x3 << 0)
@@ -11098,6 +11099,17 @@ enum skl_power_gate {
#define CNL_DRAM_RANK_3 (0x2 << 9)
#define CNL_DRAM_RANK_4 (0x3 << 9)
+#define SA_PERF_STATUS_0_0_0_MCHBAR_PC _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x5918)
+#define DG1_QCLK_RATIO_MASK REG_GENMASK(9, 2)
+#define DG1_QCLK_REFERENCEREG_BIT(10)
+
+#define MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x4000)
+#define DG1_DRAM_T_RDPRE_MASKREG_GENMASK(16, 11)
+#define DG1_DRAM_T_RP_MASK REG_GENMASK(6, 0)
+#define MCHBAR_CH0_CR_TC_PRE_0_0_0_MCHBAR_HIGH _MMIO(MCHBAR_MIRROR_BASE_SNB +
0x4004)
+#define DG1_DRAM_T_RCD_MASK REG_GENMASK(15, 9)
+#define DG1_DRAM_T_RAS_MASK REG_GENMASK(8, 1)
+
/*
* Please see hsw_read_dcomp() and hsw_write_dcomp() before using this
register,
* since on HSW we can't write to it using intel_uncore_write.
--
2.31.1
___
[Intel-gfx] [PATCH 0/1] drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
Replacement for https://patchwork.freedesktop.org/series/91848/ Those 2 commits are now squashed and received a round of cleanup. My changes were mostly cosmetic, so I'm leaving my r-b there. It would be good to get an ack though. Clint Taylor (1): drm/i915/dg1: Compute MEM Bandwidth using MCHBAR drivers/gpu/drm/i915/display/intel_bw.c | 41 - drivers/gpu/drm/i915/i915_reg.h | 12 2 files changed, 52 insertions(+), 1 deletion(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Update to new HuC for TGL+ and enable GuC/HuC on ADL-P (rev2)
== Series Details ==
Series: Update to new HuC for TGL+ and enable GuC/HuC on ADL-P (rev2)
URL : https://patchwork.freedesktop.org/series/91932/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20498_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20498_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20498_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20498_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-skl5/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-psr:
- {shard-rkl}:[FAIL][2] ([i915#2951]) -> [SKIP][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@i915_pm...@dc6-psr.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@i915_pm...@dc6-psr.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- {shard-rkl}:[PASS][4] -> [SKIP][5] +81 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs:
- {shard-rkl}:NOTRUN -> [FAIL][6] +7 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-2/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- {shard-rkl}:[PASS][7] -> [FAIL][8] +5 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- {shard-rkl}:[SKIP][9] -> [FAIL][10] +9 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs:
- {shard-rkl}:[FAIL][11] -> [SKIP][12] +6 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-1/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-6/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs:
- {shard-rkl}:[SKIP][13] ([i915#533]) -> [FAIL][14] +4 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
* igt@kms_content_protection@atomic:
- {shard-rkl}:[SKIP][15] ([fdo#109300]) -> [SKIP][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@kms_content_protect...@atomic.html
* igt@kms_cursor_crc@pipe-b-cursor-64x21-random:
- {shard-rkl}:[SKIP][17] ([fdo#112022]) -> [SKIP][18] +12 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-5/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/shard-rkl-1/igt@kms_cursor_...@pipe-b-cursor-64x21-random.html
* igt@kms_cursor_crc@pipe-b-cursor-max-size-onscreen:
- {shard-rkl}:[SKIP][19] ([i915#3359]) -> [SKIP][20] +4 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_cursor_...@pipe-b-cursor-max-size-onscreen.html
[20]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fix -EDEADLK handling regression
== Series Details ==
Series: drm/i915/gt: Fix -EDEADLK handling regression
URL : https://patchwork.freedesktop.org/series/92082/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20497_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20497_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20497_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20497_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-skl3/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_fair@basic-throttle@rcs0:
- {shard-rkl}:NOTRUN -> [FAIL][2] +15 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-1/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@i915_pm_dc@dc6-psr:
- {shard-rkl}:[FAIL][3] ([i915#2951]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@i915_pm...@dc6-psr.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-1/igt@i915_pm...@dc6-psr.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- {shard-rkl}:NOTRUN -> [SKIP][5] +61 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-1/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs:
- {shard-rkl}:[PASS][6] -> [FAIL][7] +5 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-1/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-yf_tiled_ccs:
- {shard-rkl}:[FAIL][8] -> [SKIP][9] +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-5/igt@kms_ccs@pipe-a-crc-primary-rotation-180-yf_tiled_ccs.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-6/igt@kms_ccs@pipe-a-crc-primary-rotation-180-yf_tiled_ccs.html
* igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- {shard-rkl}:[SKIP][10] -> [FAIL][11] +10 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-2/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
* igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs:
- {shard-rkl}:[SKIP][12] ([i915#533]) -> [FAIL][13] +3 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-2/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
* igt@kms_content_protection@atomic:
- {shard-rkl}:[SKIP][14] ([fdo#109300]) -> [SKIP][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@atomic.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-2/igt@kms_content_protect...@atomic.html
* igt@kms_content_protection@dp-mst-type-0:
- {shard-rkl}:[SKIP][16] ([i915#3116]) -> [SKIP][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@dp-mst-type-0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-2/igt@kms_content_protect...@dp-mst-type-0.html
* igt@kms_cursor_crc@pipe-a-cursor-32x10-onscreen:
- {shard-rkl}:[SKIP][18] ([i915#3359]) -> [SKIP][19] +4 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_cursor_...@pipe-a-cursor-32x10-onscreen.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/shard-rkl-2/igt@kms_cursor_...@pipe-a-cursor-32x10-onscreen.html
* igt@kms_cursor_crc@pipe-b-cursor-128x42-random:
- {shard-rkl}:[SKIP][20] ([fdo#112022]) -> [SKIP][21] +14 similar
issues
[20]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for New uAPI drm properties for color management (rev3)
== Series Details == Series: New uAPI drm properties for color management (rev3) URL : https://patchwork.freedesktop.org/series/91523/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20496_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20496_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20496_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20496_full: ### IGT changes ### Possible regressions * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-skl: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-skl9/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html * igt@kms_properties@get_properties-sanity-atomic: - shard-kbl: NOTRUN -> [FAIL][2] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-kbl2/igt@kms_properties@get_properties-sanity-atomic.html * igt@kms_properties@get_properties-sanity-non-atomic: - shard-apl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-apl8/igt@kms_properties@get_properties-sanity-non-atomic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-apl2/igt@kms_properties@get_properties-sanity-non-atomic.html - shard-iclb: [PASS][5] -> [FAIL][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-iclb7/igt@kms_properties@get_properties-sanity-non-atomic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-iclb2/igt@kms_properties@get_properties-sanity-non-atomic.html - shard-kbl: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-kbl3/igt@kms_properties@get_properties-sanity-non-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-kbl7/igt@kms_properties@get_properties-sanity-non-atomic.html - shard-tglb: [PASS][9] -> [FAIL][10] +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-tglb2/igt@kms_properties@get_properties-sanity-non-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-tglb2/igt@kms_properties@get_properties-sanity-non-atomic.html - shard-skl: [PASS][11] -> [FAIL][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-skl6/igt@kms_properties@get_properties-sanity-non-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/shard-skl8/igt@kms_properties@get_properties-sanity-non-atomic.html ### Piglit changes ### Possible regressions * spec@arb_texture_gather@texturegatheroffset@vs-rgb-blue-int-2darray (NEW): - pig-snb-2600: NOTRUN -> [FAIL][13] +15851 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/pig-snb-2600/spec@arb_texture_gather@texturegatheroff...@vs-rgb-blue-int-2darray.html * spec@glsl-4.20@execution@vs_in@vs-input-double_dmat2x3_array5-position-uint_uvec3 (NEW): - pig-snb-2600: NOTRUN -> [INCOMPLETE][14] +7 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/pig-snb-2600/spec@glsl-4.20@execution@vs_in@vs-input-double_dmat2x3_array5-position-uint_uvec3.html New tests - New tests have been introduced between CI_DRM_10295_full and Patchwork_20496_full: ### New Piglit tests (15713) ### * fast_color_clear@all-colors: - Statuses : 1 fail(s) - Exec time: [0.05] s * fast_color_clear@fast-slow-clear-interaction: - Statuses : 1 fail(s) - Exec time: [0.04] s * fast_color_clear@fcc-blit-between-clears: - Statuses : 1 fail(s) - Exec time: [0.04] s * fast_color_clear@fcc-read-after-clear blit rb: - Statuses : 1 fail(s) - Exec time: [0.05] s * fast_color_clear@fcc-read-after-clear blit tex: - Statuses : 1 fail(s) - Exec time: [0.04] s * fast_color_clear@fcc-read-after-clear copy rb: - Statuses : 1 fail(s) - Exec time: [0.05] s * fast_color_clear@fcc-read-after-clear copy tex: - Statuses : 1 fail(s) - Exec time: [0.03] s * fast_color_clear@fcc-read-after-clear read_pixels rb: - Statuses : 1 fail(s) - Exec time: [0.03] s * fast_color_clear@fcc-read-after-clear read_pixels tex: - Statuses : 1 fail(s) - Exec time: [0.03] s * fast_color_clear@fcc-read-after-clear sample tex: - Statuses : 1 fail(s) - Exec time: [0.05] s * fast_color_clear@fcc-read-to-pbo-after-clear: - Statuses : 1 fail(s)
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: address potential UAF bugs with drm_master ptrs
== Series Details == Series: drm: address potential UAF bugs with drm_master ptrs URL : https://patchwork.freedesktop.org/series/92076/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20495_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20495_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20495_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20495_full: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-cpu-wc: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-kbl3/igt@gem_exec_re...@basic-cpu-wc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-kbl3/igt@gem_exec_re...@basic-cpu-wc.html * igt@gem_exec_reloc@basic-write-wc: - shard-snb: [PASS][3] -> [DMESG-WARN][4] +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-snb2/igt@gem_exec_re...@basic-write-wc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-snb7/igt@gem_exec_re...@basic-write-wc.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-snb: NOTRUN -> [DMESG-WARN][5] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-snb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html * igt@kms_plane_alpha_blend@pipe-a-alpha-transparent-fb: - shard-iclb: [PASS][6] -> [DMESG-WARN][7] +12 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-iclb2/igt@kms_plane_alpha_bl...@pipe-a-alpha-transparent-fb.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb7/igt@kms_plane_alpha_bl...@pipe-a-alpha-transparent-fb.html * igt@kms_vblank@pipe-a-wait-busy: - shard-tglb: [PASS][8] -> [DMESG-WARN][9] +9 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-tglb5/igt@kms_vbl...@pipe-a-wait-busy.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-tglb6/igt@kms_vbl...@pipe-a-wait-busy.html Warnings * igt@runner@aborted: - shard-iclb: ([FAIL][10], [FAIL][11]) ([i915#3002]) -> ([FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36]) ([i915#1814] / [i915#2426] / [i915#3690]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-iclb3/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-iclb2/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb1/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb4/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb6/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb4/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb7/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb7/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb3/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb8/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb6/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb4/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb3/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb7/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb3/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb1/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb5/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb3/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/shard-iclb2/igt@run...@aborted.html [29]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/vgem: Use 256B aligned pitch
== Series Details ==
Series: drm/vgem: Use 256B aligned pitch
URL : https://patchwork.freedesktop.org/series/92067/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20492_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20492_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20492_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20492_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-skl5/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-psr:
- {shard-rkl}:[FAIL][2] ([i915#2951]) -> [SKIP][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@i915_pm...@dc6-psr.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-2/igt@i915_pm...@dc6-psr.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- {shard-rkl}:[PASS][4] -> [SKIP][5] +56 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-2/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs:
- {shard-rkl}:NOTRUN -> [FAIL][6] +7 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-5/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_ccs:
- {shard-rkl}:[FAIL][7] -> [SKIP][8] +11 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_ccs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- {shard-rkl}:[PASS][9] -> [FAIL][10] +8 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-2/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs:
- {shard-rkl}:[SKIP][11] -> [FAIL][12] +12 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-2/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
* igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs:
- {shard-rkl}:[SKIP][13] ([i915#533]) -> [FAIL][14] +5 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-2/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_gen12_rc_ccs.html
* igt@kms_content_protection@atomic:
- {shard-rkl}:[SKIP][15] ([fdo#109300]) -> [SKIP][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-2/igt@kms_content_protect...@atomic.html
* igt@kms_content_protection@dp-mst-type-0:
- {shard-rkl}:[SKIP][17] ([i915#3116]) -> [SKIP][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@dp-mst-type-0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-1/igt@kms_content_protect...@dp-mst-type-0.html
* igt@kms_cursor_crc@pipe-a-cursor-32x10-onscreen:
- {shard-rkl}:[SKIP][19] ([i915#3359]) -> [SKIP][20] +6 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_cursor_...@pipe-a-cursor-32x10-onscreen.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/shard-rkl-1/igt@kms_cursor_...@pipe-a-cursor-32x10-onscreen.html
*
Re: [Intel-gfx] [PATCH 5/7] drm/i915/guc: Add stall timer to non blocking CTB send function
On Thu, Jul 01, 2021 at 01:23:36AM +0200, Michal Wajdeczko wrote:
>
>
> On 28.06.2021 01:14, Matthew Brost wrote:
> > Implement a stall timer which fails H2G CTBs once a period of time
> > with no forward progress is reached to prevent deadlock.
> >
> > v2:
> > (Michal)
> > - Improve error message in ct_deadlock()
> > - Set broken when ct_deadlock() returns true
> > - Return -EPIPE on ct_deadlock()
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 62 ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 4 ++
> > 2 files changed, 59 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 90ee95a240e8..8f553f7f9619 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -319,6 +319,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> > goto err_deregister;
> >
> > ct->enabled = true;
> > + ct->stall_time = KTIME_MAX;
> >
> > return 0;
> >
> > @@ -391,9 +392,6 @@ static int ct_write(struct intel_guc_ct *ct,
> > u32 *cmds = ctb->cmds;
> > unsigned int i;
> >
> > - if (unlikely(ctb->broken))
> > - return -EPIPE;
> > -
> > if (unlikely(desc->status))
> > goto corrupted;
> >
> > @@ -509,6 +507,25 @@ static int wait_for_ct_request_update(struct
> > ct_request *req, u32 *status)
> > return err;
> > }
> >
> > +#define GUC_CTB_TIMEOUT_MS 1500
> > +static inline bool ct_deadlocked(struct intel_guc_ct *ct)
> > +{
> > + long timeout = GUC_CTB_TIMEOUT_MS;
> > + bool ret = ktime_ms_delta(ktime_get(), ct->stall_time) > timeout;
> > +
> > + if (unlikely(ret)) {
> > + struct guc_ct_buffer_desc *send = ct->ctbs.send.desc;
> > + struct guc_ct_buffer_desc *recv = ct->ctbs.send.desc;
> > +
> > + CT_ERROR(ct, "Communication stalled for %lld, desc
> > status=%#x,%#x\n",
>
> nit: missing unit in "stalled for ... ms"
>
Yep, will fix.
>
> > +ktime_ms_delta(ktime_get(), ct->stall_time),
> > +send->status, recv->status);
> > + ct->ctbs.send.broken = true;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32
> > len_dw)
> > {
> > struct guc_ct_buffer_desc *desc = ctb->desc;
> > @@ -520,6 +537,26 @@ static inline bool h2g_has_room(struct
> > intel_guc_ct_buffer *ctb, u32 len_dw)
> > return space >= len_dw;
> > }
> >
> > +static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
> > +{
> > + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> > +
> > + lockdep_assert_held(>ctbs.send.lock);
> > +
> > + if (unlikely(!h2g_has_room(ctb, len_dw))) {
> > + if (ct->stall_time == KTIME_MAX)
> > + ct->stall_time = ktime_get();
> > +
> > + if (unlikely(ct_deadlocked(ct)))
> > + return -EPIPE;
> > + else
> > + return -EBUSY;
> > + }
> > +
> > + ct->stall_time = KTIME_MAX;
> > + return 0;
> > +}
> > +
> > static int ct_send_nb(struct intel_guc_ct *ct,
> > const u32 *action,
> > u32 len,
> > @@ -530,13 +567,14 @@ static int ct_send_nb(struct intel_guc_ct *ct,
> > u32 fence;
> > int ret;
> >
> > + if (unlikely(ctb->broken))
> > + return -EPIPE;
> > +
> > spin_lock_irqsave(>lock, spin_flags);
> >
> > - ret = h2g_has_room(ctb, len + GUC_CTB_HDR_LEN);
> > - if (unlikely(!ret)) {
> > - ret = -EBUSY;
> > + ret = has_room_nb(ct, len + GUC_CTB_HDR_LEN);
> > + if (unlikely(ret))
> > goto out;
> > - }
> >
> > fence = ct_get_next_fence(ct);
> > ret = ct_write(ct, action, len, fence, flags);
> > @@ -571,6 +609,9 @@ static int ct_send(struct intel_guc_ct *ct,
> > GEM_BUG_ON(!response_buf && response_buf_size);
> > might_sleep();
> >
> > + if (unlikely(ctb->broken))
> > + return -EPIPE;
>
> ok, but likely could be part of ct_can_send/has_room
>
No, this actually should be apart of 'intel_guc_ct_send'.
> > +
> > /*
> > * We use a lazy spin wait loop here as we believe that if the CT
> > * buffers are sized correctly the flow control condition should be
> > @@ -579,8 +620,13 @@ static int ct_send(struct intel_guc_ct *ct,
> > retry:
> > spin_lock_irqsave(>lock, flags);
> > if (unlikely(!h2g_has_room(ctb, len + GUC_CTB_HDR_LEN))) {
> > + if (ct->stall_time == KTIME_MAX)
> > + ct->stall_time = ktime_get();
> > spin_unlock_irqrestore(>lock, flags);
> >
> > + if (unlikely(ct_deadlocked(ct)))
> > + return -EPIPE;
> > +
>
> can't we really put all this into one
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Add non blocking CTB send function
On Thu, Jul 01, 2021 at 12:52:58AM +0200, Michal Wajdeczko wrote: > > > On 28.06.2021 01:14, Matthew Brost wrote: > > Add non blocking CTB send function, intel_guc_send_nb. GuC submission > > will send CTBs in the critical path and does not need to wait for these > > CTBs to complete before moving on, hence the need for this new function. > > > > The non-blocking CTB now must have a flow control mechanism to ensure > > the buffer isn't overrun. A lazy spin wait is used as we believe the > > flow control condition should be rare with a properly sized buffer. > > > > The function, intel_guc_send_nb, is exported in this patch but unused. > > Several patches later in the series make use of this function. > > > > v2: > > (Michal) > > - Use define for H2G room calculations > > - Move INTEL_GUC_SEND_NB define > > (Daniel Vetter) > > - Use msleep_interruptible rather than cond_resched > > > > Signed-off-by: John Harrison > > Signed-off-by: Matthew Brost > > --- > > .../gt/uc/abi/guc_communication_ctb_abi.h | 3 +- > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 ++- > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 90 +-- > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 4 +- > > 4 files changed, 94 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h > > b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h > > index e933ca02d0eb..99e1fad5ca20 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h > > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h > > @@ -79,7 +79,8 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64); > > * > > +---+---+--+ > > */ > > > > -#define GUC_CTB_MSG_MIN_LEN1u > > +#define GUC_CTB_HDR_LEN1u > > +#define GUC_CTB_MSG_MIN_LENGUC_CTB_HDR_LEN > > if you insist to use dedicated macro for the CTB header len then to be > consistent you need rename header bitfield macros as well, thus > sections/tables will look like: > Kernel doc can't link to defines, right? So what does it matter? This example is also a reason why I think the kernel doc included is too verbose to hand generate. Either we auto-gen this or just don't include it. > /** > * DOC: CTB Message > * > * +---+---+-+ > * | | Bits | Description | > * +===+===+=+ > * | 0 | 31:0 | `CTB Header`_ | > * +---+---+-+ > * | 1 | 31:0 | +---+ | > * +---+---+ | | | > * |...| | | CTB Payload | | > * +---+---+ | | | > * | n | 31:0 | +---+ | > * +---+---+-+ > */ > > /** > * DOC: CTB Header > * > * +---+---+-+ > * | | Bits | Description | > * +===+===+=+ > * | 0 | 31:16 | **FENCE** - ... | > * | +---+-+ > * | | 15:12 | **FORMAT** - ...| > * | +---+-+ > * | | 11:8 | **RESERVED**| > * | +---+-+ > * | | 7:0 | **NUM_DWORDS** - ...| > * +---+---+-+ > */ > > #define GUC_CTB_HDR_0_FENCE (0x << 16) > #define GUC_CTB_HDR_0_FORMAT (0xf << 12) > #define GUC_CTB_FORMAT_HXG 0u > #define GUC_CTB_HDR_0_RESERVED(0xf << 8) > #define GUC_CTB_HDR_0_NUM_DWORDS (0xff << 0) > #define GUC_CTB_MAX_DWORDS 255u > > #define GUC_CTB_MSG_MIN_LEN GUC_CTB_HDR_LEN > #define GUC_CTB_MSG_MAX_LEN (GUC_CTB_HDR_LEN + GUC_CTB_MAX_DWORDS) > > > alternatively leave ABI defs as-as and just move your HDR definition out > of ABI headers to inteL_guc_fwif.h as: > > #define GUC_CTB_HDR_LEN GUC_CTB_MSG_MIN_LEN This is backwards. The minimum length of a message is the header length. > > > > #define GUC_CTB_MSG_MAX_LEN256u > > #define GUC_CTB_MSG_0_FENCE(0x << 16) > > #define GUC_CTB_MSG_0_FORMAT (0xf << 12) > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h > > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h > > index 4abc59f6f3cd..efc690fc8fb1 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h > > @@ -74,7 +74,14 @@ static inline struct intel_guc *log_to_guc(struct
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
On Wed, Jun 30, 2021 at 05:15:00PM -0700, Jose Souza wrote:
On Wed, 2021-06-30 at 17:01 -0700, Lucas De Marchi wrote:
Typo: RUNTIME_INFO->stp
On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
> On the dmc side,we maintain a lookup table with different display
> stepping-substepping combinations.
>
> Instead of adding new table for every new platform, lets ues
> the stepping info from RUNTIME_INFO(dev_priv)->step
> Adding the helper intel_get_display_step().
>
> Cc: Lucas De Marchi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 49 ++--
> 1 file changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
> index f8789d4543bf..c7ff7ff3f412 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -266,14 +266,55 @@ static const struct stepping_info icl_stepping_info[] =
{
> };
>
> static const struct stepping_info no_stepping_info = { '*', '*' };
> +struct stepping_info *display_step;
> +
> +static struct stepping_info *
> +intel_get_display_stepping(struct intel_step_info step)
> +{
> +
> + switch (step.display_step) {
> + case STEP_A0:
> + display_step->stepping = 'A';
> + display_step->substepping = '0';
> + break;
> + case STEP_A2:
> + display_step->stepping = 'A';
> + display_step->substepping = '2';
> + break;
> + case STEP_B0:
> + display_step->stepping = 'B';
> + display_step->substepping = '0';
> + break;
> + case STEP_B1:
> + display_step->stepping = 'B';
> + display_step->substepping = '1';
> + break;
> + case STEP_C0:
> + display_step->stepping = 'C';
> + display_step->substepping = '0';
> + break;
> + case STEP_D0:
> + display_step->stepping = 'D';
> + display_step->substepping = '0';
> + break;
> + default:
> + display_step->stepping = '*';
> + display_step->substepping = '*';
> + break;
> + }
"crazy" idea that would avoid this type of conversion:
changing the step enum to be:
#define make_step(letter, num) (int)(((letter) << 8 ) | (num))
STEP_A0 = make_step('A', '0'),
STEP_A1 = make_step('A', '1'),
Looks a good idea to me, we could also keep it u8 using 4bits for each if there
is memory concerns.
humn... indeed. Not much a concern actually, but not having to change
additional code is already a good thing.
I hope no stepping goes beyond Z9 :)
Lucas De Marchi
and adapt the rest of the code to play with u16 instead of u8, and
handle the STEP_FUTURE/STEP_NONE/STEP_FOREVER.
Maybe it is crazy, dunno.
+Jani / +Jose. Thoughts?
For this version the next comment is probably more important.
> + return display_step;
> +}
>
> static const struct stepping_info *
> intel_get_stepping_info(struct drm_i915_private *dev_priv)
> {
>const struct stepping_info *si;
> + struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
>unsigned int size;
>
> - if (IS_ICELAKE(dev_priv)) {
> + if (DISPLAY_VER(dev_priv) >= 12) {
> + si = intel_get_display_stepping(step);
> + } else if (IS_ICELAKE(dev_priv)) {
>size = ARRAY_SIZE(icl_stepping_info);
>si = icl_stepping_info;
can we move the other ones too? Just use display_step for all platforms.
Notice that before the separation we will have display_step ==
graphics_step, so it should just work.
Lucas De Marchi
>} else if (IS_SKYLAKE(dev_priv)) {
> @@ -287,10 +328,10 @@ intel_get_stepping_info(struct drm_i915_private
*dev_priv)
>si = NULL;
>}
>
> - if (INTEL_REVID(dev_priv) < size)
> - return si + INTEL_REVID(dev_priv);
> + if (DISPLAY_VER(dev_priv) < 12)
> + return INTEL_REVID(dev_priv) < size ? si + INTEL_REVID(dev_priv) :
_stepping_info;
>
> - return _stepping_info;
> + return si;
> }
>
> static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
> --
> 2.32.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
On Wed, 2021-06-30 at 17:01 -0700, Lucas De Marchi wrote:
> Typo: RUNTIME_INFO->stp
>
> On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
> > On the dmc side,we maintain a lookup table with different display
> > stepping-substepping combinations.
> >
> > Instead of adding new table for every new platform, lets ues
> > the stepping info from RUNTIME_INFO(dev_priv)->step
> > Adding the helper intel_get_display_step().
> >
> > Cc: Lucas De Marchi
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_dmc.c | 49 ++--
> > 1 file changed, 45 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> > b/drivers/gpu/drm/i915/display/intel_dmc.c
> > index f8789d4543bf..c7ff7ff3f412 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> > @@ -266,14 +266,55 @@ static const struct stepping_info icl_stepping_info[]
> > = {
> > };
> >
> > static const struct stepping_info no_stepping_info = { '*', '*' };
> > +struct stepping_info *display_step;
> > +
> > +static struct stepping_info *
> > +intel_get_display_stepping(struct intel_step_info step)
> > +{
> > +
> > + switch (step.display_step) {
> > + case STEP_A0:
> > + display_step->stepping = 'A';
> > + display_step->substepping = '0';
> > + break;
> > + case STEP_A2:
> > + display_step->stepping = 'A';
> > + display_step->substepping = '2';
> > + break;
> > + case STEP_B0:
> > + display_step->stepping = 'B';
> > + display_step->substepping = '0';
> > + break;
> > + case STEP_B1:
> > + display_step->stepping = 'B';
> > + display_step->substepping = '1';
> > + break;
> > + case STEP_C0:
> > + display_step->stepping = 'C';
> > + display_step->substepping = '0';
> > + break;
> > + case STEP_D0:
> > + display_step->stepping = 'D';
> > + display_step->substepping = '0';
> > + break;
> > + default:
> > + display_step->stepping = '*';
> > + display_step->substepping = '*';
> > + break;
> > + }
>
>
> "crazy" idea that would avoid this type of conversion:
> changing the step enum to be:
>
>
> #define make_step(letter, num) (int)(((letter) << 8 ) | (num))
>
> STEP_A0 = make_step('A', '0'),
> STEP_A1 = make_step('A', '1'),
Looks a good idea to me, we could also keep it u8 using 4bits for each if there
is memory concerns.
>
> and adapt the rest of the code to play with u16 instead of u8, and
> handle the STEP_FUTURE/STEP_NONE/STEP_FOREVER.
> Maybe it is crazy, dunno.
>
> +Jani / +Jose. Thoughts?
>
>
> For this version the next comment is probably more important.
>
> > + return display_step;
> > +}
> >
> > static const struct stepping_info *
> > intel_get_stepping_info(struct drm_i915_private *dev_priv)
> > {
> > const struct stepping_info *si;
> > + struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
> > unsigned int size;
> >
> > - if (IS_ICELAKE(dev_priv)) {
> > + if (DISPLAY_VER(dev_priv) >= 12) {
> > + si = intel_get_display_stepping(step);
> > + } else if (IS_ICELAKE(dev_priv)) {
> > size = ARRAY_SIZE(icl_stepping_info);
> > si = icl_stepping_info;
>
> can we move the other ones too? Just use display_step for all platforms.
> Notice that before the separation we will have display_step ==
> graphics_step, so it should just work.
>
>
> Lucas De Marchi
>
> > } else if (IS_SKYLAKE(dev_priv)) {
> > @@ -287,10 +328,10 @@ intel_get_stepping_info(struct drm_i915_private
> > *dev_priv)
> > si = NULL;
> > }
> >
> > - if (INTEL_REVID(dev_priv) < size)
> > - return si + INTEL_REVID(dev_priv);
> > + if (DISPLAY_VER(dev_priv) < 12)
> > + return INTEL_REVID(dev_priv) < size ? si +
> > INTEL_REVID(dev_priv) : _stepping_info;
> >
> > - return _stepping_info;
> > + return si;
> > }
> >
> > static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
> > --
> > 2.32.0
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: IRQ fixes (rev2)
== Series Details ==
Series: drm/i915: IRQ fixes (rev2)
URL : https://patchwork.freedesktop.org/series/92053/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20491_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20491_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20491_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20491_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-skl: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-skl9/igt@kms_big...@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_persistence@many-contexts:
- {shard-rkl}:[PASS][2] -> [FAIL][3] +5 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-2/igt@gem_ctx_persiste...@many-contexts.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-2/igt@gem_ctx_persiste...@many-contexts.html
* igt@i915_pm_dc@dc6-psr:
- {shard-rkl}:[FAIL][4] ([i915#2951]) -> [SKIP][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@i915_pm...@dc6-psr.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-5/igt@i915_pm...@dc6-psr.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip:
- {shard-rkl}:NOTRUN -> [SKIP][6] +59 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-5/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip-async-flip.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs:
- {shard-rkl}:NOTRUN -> [FAIL][7] +14 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-1/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_ccs.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-yf_tiled_ccs:
- {shard-rkl}:[SKIP][8] -> [FAIL][9] +6 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-yf_tiled_ccs.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-5/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-yf_tiled_ccs.html
* igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_ccs:
- {shard-rkl}:[FAIL][10] -> [SKIP][11] +6 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-1/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_ccs.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-6/igt@kms_ccs@pipe-b-ccs-on-another-bo-y_tiled_ccs.html
* igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_ccs:
- {shard-rkl}:[SKIP][12] ([i915#533]) -> [FAIL][13] +2 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_ccs.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-5/igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_ccs.html
* igt@kms_content_protection@dp-mst-type-0:
- {shard-rkl}:[SKIP][14] ([i915#3116]) -> [SKIP][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@dp-mst-type-0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-5/igt@kms_content_protect...@dp-mst-type-0.html
* igt@kms_content_protection@lic:
- {shard-rkl}:[SKIP][16] ([fdo#109300]) -> [SKIP][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_content_protect...@lic.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-5/igt@kms_content_protect...@lic.html
* igt@kms_cursor_crc@pipe-a-cursor-128x42-offscreen:
- {shard-rkl}:[SKIP][18] ([fdo#112022]) -> [SKIP][19] +27 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-5/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/shard-rkl-1/igt@kms_cursor_...@pipe-a-cursor-128x42-offscreen.html
* igt@kms_cursor_crc@pipe-a-cursor-32x10-onscreen:
- {shard-rkl}:[SKIP][20] ([i915#3359]) -> [SKIP][21] +4 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/shard-rkl-6/igt@kms_cursor_...@pipe-a-cursor-32x10-onscreen.html
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
Typo: RUNTIME_INFO->stp
On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
On the dmc side,we maintain a lookup table with different display
stepping-substepping combinations.
Instead of adding new table for every new platform, lets ues
the stepping info from RUNTIME_INFO(dev_priv)->step
Adding the helper intel_get_display_step().
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 49 ++--
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f8789d4543bf..c7ff7ff3f412 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -266,14 +266,55 @@ static const struct stepping_info icl_stepping_info[] = {
};
static const struct stepping_info no_stepping_info = { '*', '*' };
+struct stepping_info *display_step;
+
+static struct stepping_info *
+intel_get_display_stepping(struct intel_step_info step)
+{
+
+ switch (step.display_step) {
+ case STEP_A0:
+ display_step->stepping = 'A';
+ display_step->substepping = '0';
+ break;
+ case STEP_A2:
+ display_step->stepping = 'A';
+ display_step->substepping = '2';
+ break;
+ case STEP_B0:
+ display_step->stepping = 'B';
+ display_step->substepping = '0';
+ break;
+ case STEP_B1:
+ display_step->stepping = 'B';
+ display_step->substepping = '1';
+ break;
+ case STEP_C0:
+ display_step->stepping = 'C';
+ display_step->substepping = '0';
+ break;
+ case STEP_D0:
+ display_step->stepping = 'D';
+ display_step->substepping = '0';
+ break;
+ default:
+ display_step->stepping = '*';
+ display_step->substepping = '*';
+ break;
+ }
"crazy" idea that would avoid this type of conversion:
changing the step enum to be:
#define make_step(letter, num) (int)(((letter) << 8 ) | (num))
STEP_A0 = make_step('A', '0'),
STEP_A1 = make_step('A', '1'),
and adapt the rest of the code to play with u16 instead of u8, and
handle the STEP_FUTURE/STEP_NONE/STEP_FOREVER.
Maybe it is crazy, dunno.
+Jani / +Jose. Thoughts?
For this version the next comment is probably more important.
+ return display_step;
+}
static const struct stepping_info *
intel_get_stepping_info(struct drm_i915_private *dev_priv)
{
const struct stepping_info *si;
+ struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
unsigned int size;
- if (IS_ICELAKE(dev_priv)) {
+ if (DISPLAY_VER(dev_priv) >= 12) {
+ si = intel_get_display_stepping(step);
+ } else if (IS_ICELAKE(dev_priv)) {
size = ARRAY_SIZE(icl_stepping_info);
si = icl_stepping_info;
can we move the other ones too? Just use display_step for all platforms.
Notice that before the separation we will have display_step ==
graphics_step, so it should just work.
Lucas De Marchi
} else if (IS_SKYLAKE(dev_priv)) {
@@ -287,10 +328,10 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
si = NULL;
}
- if (INTEL_REVID(dev_priv) < size)
- return si + INTEL_REVID(dev_priv);
+ if (DISPLAY_VER(dev_priv) < 12)
+ return INTEL_REVID(dev_priv) < size ? si + INTEL_REVID(dev_priv) :
_stepping_info;
- return _stepping_info;
+ return si;
}
static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
== Series Details == Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC URL : https://patchwork.freedesktop.org/series/92088/ State : success == Summary == CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20500 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/index.html Known issues Here are the changes found in Patchwork_20500 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-bdw-5557u: [PASS][1] -> [DMESG-FAIL][2] ([i915#541]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/fi-bdw-5557u/igt@i915_selftest@live@gt_heartbeat.html [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (39 -> 33) -- Missing(6): fi-ilk-m540 fi-tgl-dsi fi-tgl-1115g4 fi-bsw-cyan fi-dg1-1 fi-bdw-samus Build changes - * Linux: CI_DRM_10295 -> Patchwork_20500 CI-20190529: 20190529 CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20500: dc34e57ce63492d648bec07e172458837b8d71d8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == dc34e57ce634 drm/i915/dmc: Use RUNTIME_INFO->stp for DMC == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20500/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915/guc: Add stall timer to non blocking CTB send function
On 28.06.2021 01:14, Matthew Brost wrote:
> Implement a stall timer which fails H2G CTBs once a period of time
> with no forward progress is reached to prevent deadlock.
>
> v2:
> (Michal)
> - Improve error message in ct_deadlock()
> - Set broken when ct_deadlock() returns true
> - Return -EPIPE on ct_deadlock()
>
> Signed-off-by: John Harrison
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 62 ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 4 ++
> 2 files changed, 59 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 90ee95a240e8..8f553f7f9619 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> @@ -319,6 +319,7 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
> goto err_deregister;
>
> ct->enabled = true;
> + ct->stall_time = KTIME_MAX;
>
> return 0;
>
> @@ -391,9 +392,6 @@ static int ct_write(struct intel_guc_ct *ct,
> u32 *cmds = ctb->cmds;
> unsigned int i;
>
> - if (unlikely(ctb->broken))
> - return -EPIPE;
> -
> if (unlikely(desc->status))
> goto corrupted;
>
> @@ -509,6 +507,25 @@ static int wait_for_ct_request_update(struct ct_request
> *req, u32 *status)
> return err;
> }
>
> +#define GUC_CTB_TIMEOUT_MS 1500
> +static inline bool ct_deadlocked(struct intel_guc_ct *ct)
> +{
> + long timeout = GUC_CTB_TIMEOUT_MS;
> + bool ret = ktime_ms_delta(ktime_get(), ct->stall_time) > timeout;
> +
> + if (unlikely(ret)) {
> + struct guc_ct_buffer_desc *send = ct->ctbs.send.desc;
> + struct guc_ct_buffer_desc *recv = ct->ctbs.send.desc;
> +
> + CT_ERROR(ct, "Communication stalled for %lld, desc
> status=%#x,%#x\n",
nit: missing unit in "stalled for ... ms"
> + ktime_ms_delta(ktime_get(), ct->stall_time),
> + send->status, recv->status);
> + ct->ctbs.send.broken = true;
> + }
> +
> + return ret;
> +}
> +
> static inline bool h2g_has_room(struct intel_guc_ct_buffer *ctb, u32 len_dw)
> {
> struct guc_ct_buffer_desc *desc = ctb->desc;
> @@ -520,6 +537,26 @@ static inline bool h2g_has_room(struct
> intel_guc_ct_buffer *ctb, u32 len_dw)
> return space >= len_dw;
> }
>
> +static int has_room_nb(struct intel_guc_ct *ct, u32 len_dw)
> +{
> + struct intel_guc_ct_buffer *ctb = >ctbs.send;
> +
> + lockdep_assert_held(>ctbs.send.lock);
> +
> + if (unlikely(!h2g_has_room(ctb, len_dw))) {
> + if (ct->stall_time == KTIME_MAX)
> + ct->stall_time = ktime_get();
> +
> + if (unlikely(ct_deadlocked(ct)))
> + return -EPIPE;
> + else
> + return -EBUSY;
> + }
> +
> + ct->stall_time = KTIME_MAX;
> + return 0;
> +}
> +
> static int ct_send_nb(struct intel_guc_ct *ct,
> const u32 *action,
> u32 len,
> @@ -530,13 +567,14 @@ static int ct_send_nb(struct intel_guc_ct *ct,
> u32 fence;
> int ret;
>
> + if (unlikely(ctb->broken))
> + return -EPIPE;
> +
> spin_lock_irqsave(>lock, spin_flags);
>
> - ret = h2g_has_room(ctb, len + GUC_CTB_HDR_LEN);
> - if (unlikely(!ret)) {
> - ret = -EBUSY;
> + ret = has_room_nb(ct, len + GUC_CTB_HDR_LEN);
> + if (unlikely(ret))
> goto out;
> - }
>
> fence = ct_get_next_fence(ct);
> ret = ct_write(ct, action, len, fence, flags);
> @@ -571,6 +609,9 @@ static int ct_send(struct intel_guc_ct *ct,
> GEM_BUG_ON(!response_buf && response_buf_size);
> might_sleep();
>
> + if (unlikely(ctb->broken))
> + return -EPIPE;
ok, but likely could be part of ct_can_send/has_room
> +
> /*
>* We use a lazy spin wait loop here as we believe that if the CT
>* buffers are sized correctly the flow control condition should be
> @@ -579,8 +620,13 @@ static int ct_send(struct intel_guc_ct *ct,
> retry:
> spin_lock_irqsave(>lock, flags);
> if (unlikely(!h2g_has_room(ctb, len + GUC_CTB_HDR_LEN))) {
> + if (ct->stall_time == KTIME_MAX)
> + ct->stall_time = ktime_get();
> spin_unlock_irqrestore(>lock, flags);
>
> + if (unlikely(ct_deadlocked(ct)))
> + return -EPIPE;
> +
can't we really put all this into one place?
static int ct_can_send(struct intel_guc_ct *ct, u32 len_dw, bool wait)
{
struct intel_guc_ct_buffer *ctb = >ctbs.send;
lockdep_assert_held(>ctbs.send.lock);
retry:
if (ct->broken)
return -EPIPE;
if (unlikely(!ctb_has_room(ctb, len_dw +
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
== Series Details == Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC URL : https://patchwork.freedesktop.org/series/92088/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_dmc.c:269:22: warning: symbol 'display_step' was not declared. Should it be static? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
== Series Details ==
Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
URL : https://patchwork.freedesktop.org/series/92088/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc34e57ce634 drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
-:29: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#29: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:274:
+{
+
-:84: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#84: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:332:
+ return INTEL_REVID(dev_priv) < size ? si +
INTEL_REVID(dev_priv) : _stepping_info;
total: 0 errors, 1 warnings, 1 checks, 69 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
On the dmc side,we maintain a lookup table with different display
stepping-substepping combinations.
Instead of adding new table for every new platform, lets ues
the stepping info from RUNTIME_INFO(dev_priv)->step
Adding the helper intel_get_display_step().
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 49 ++--
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f8789d4543bf..c7ff7ff3f412 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -266,14 +266,55 @@ static const struct stepping_info icl_stepping_info[] = {
};
static const struct stepping_info no_stepping_info = { '*', '*' };
+struct stepping_info *display_step;
+
+static struct stepping_info *
+intel_get_display_stepping(struct intel_step_info step)
+{
+
+ switch (step.display_step) {
+ case STEP_A0:
+ display_step->stepping = 'A';
+ display_step->substepping = '0';
+ break;
+ case STEP_A2:
+ display_step->stepping = 'A';
+ display_step->substepping = '2';
+ break;
+ case STEP_B0:
+ display_step->stepping = 'B';
+ display_step->substepping = '0';
+ break;
+ case STEP_B1:
+ display_step->stepping = 'B';
+ display_step->substepping = '1';
+ break;
+ case STEP_C0:
+ display_step->stepping = 'C';
+ display_step->substepping = '0';
+ break;
+ case STEP_D0:
+ display_step->stepping = 'D';
+ display_step->substepping = '0';
+ break;
+ default:
+ display_step->stepping = '*';
+ display_step->substepping = '*';
+ break;
+ }
+ return display_step;
+}
static const struct stepping_info *
intel_get_stepping_info(struct drm_i915_private *dev_priv)
{
const struct stepping_info *si;
+ struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
unsigned int size;
- if (IS_ICELAKE(dev_priv)) {
+ if (DISPLAY_VER(dev_priv) >= 12) {
+ si = intel_get_display_stepping(step);
+ } else if (IS_ICELAKE(dev_priv)) {
size = ARRAY_SIZE(icl_stepping_info);
si = icl_stepping_info;
} else if (IS_SKYLAKE(dev_priv)) {
@@ -287,10 +328,10 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
si = NULL;
}
- if (INTEL_REVID(dev_priv) < size)
- return si + INTEL_REVID(dev_priv);
+ if (DISPLAY_VER(dev_priv) < 12)
+ return INTEL_REVID(dev_priv) < size ? si +
INTEL_REVID(dev_priv) : _stepping_info;
- return _stepping_info;
+ return si;
}
static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915/guc: Add non blocking CTB send function
On 28.06.2021 01:14, Matthew Brost wrote:
> Add non blocking CTB send function, intel_guc_send_nb. GuC submission
> will send CTBs in the critical path and does not need to wait for these
> CTBs to complete before moving on, hence the need for this new function.
>
> The non-blocking CTB now must have a flow control mechanism to ensure
> the buffer isn't overrun. A lazy spin wait is used as we believe the
> flow control condition should be rare with a properly sized buffer.
>
> The function, intel_guc_send_nb, is exported in this patch but unused.
> Several patches later in the series make use of this function.
>
> v2:
> (Michal)
> - Use define for H2G room calculations
> - Move INTEL_GUC_SEND_NB define
> (Daniel Vetter)
> - Use msleep_interruptible rather than cond_resched
>
> Signed-off-by: John Harrison
> Signed-off-by: Matthew Brost
> ---
> .../gt/uc/abi/guc_communication_ctb_abi.h | 3 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 ++-
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 90 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 4 +-
> 4 files changed, 94 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index e933ca02d0eb..99e1fad5ca20 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -79,7 +79,8 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> *
> +---+---+--+
> */
>
> -#define GUC_CTB_MSG_MIN_LEN 1u
> +#define GUC_CTB_HDR_LEN 1u
> +#define GUC_CTB_MSG_MIN_LEN GUC_CTB_HDR_LEN
if you insist to use dedicated macro for the CTB header len then to be
consistent you need rename header bitfield macros as well, thus
sections/tables will look like:
/**
* DOC: CTB Message
*
* +---+---+-+
* | | Bits | Description |
* +===+===+=+
* | 0 | 31:0 | `CTB Header`_ |
* +---+---+-+
* | 1 | 31:0 | +---+ |
* +---+---+ | | |
* |...| | | CTB Payload | |
* +---+---+ | | |
* | n | 31:0 | +---+ |
* +---+---+-+
*/
/**
* DOC: CTB Header
*
* +---+---+-+
* | | Bits | Description |
* +===+===+=+
* | 0 | 31:16 | **FENCE** - ... |
* | +---+-+
* | | 15:12 | **FORMAT** - ...|
* | +---+-+
* | | 11:8 | **RESERVED**|
* | +---+-+
* | | 7:0 | **NUM_DWORDS** - ...|
* +---+---+-+
*/
#define GUC_CTB_HDR_0_FENCE (0x << 16)
#define GUC_CTB_HDR_0_FORMAT(0xf << 12)
#define GUC_CTB_FORMAT_HXG0u
#define GUC_CTB_HDR_0_RESERVED (0xf << 8)
#define GUC_CTB_HDR_0_NUM_DWORDS(0xff << 0)
#define GUC_CTB_MAX_DWORDS255u
#define GUC_CTB_MSG_MIN_LEN GUC_CTB_HDR_LEN
#define GUC_CTB_MSG_MAX_LEN (GUC_CTB_HDR_LEN + GUC_CTB_MAX_DWORDS)
alternatively leave ABI defs as-as and just move your HDR definition out
of ABI headers to inteL_guc_fwif.h as:
#define GUC_CTB_HDR_LEN GUC_CTB_MSG_MIN_LEN
> #define GUC_CTB_MSG_MAX_LEN 256u
> #define GUC_CTB_MSG_0_FENCE (0x << 16)
> #define GUC_CTB_MSG_0_FORMAT (0xf << 12)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 4abc59f6f3cd..efc690fc8fb1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -74,7 +74,14 @@ static inline struct intel_guc *log_to_guc(struct
> intel_guc_log *log)
> static
> inline int intel_guc_send(struct intel_guc *guc, const u32 *action, u32 len)
> {
> - return intel_guc_ct_send(>ct, action, len, NULL, 0);
> + return intel_guc_ct_send(>ct, action, len, NULL, 0, 0);
> +}
> +
> +static
> +inline int intel_guc_send_nb(struct intel_guc *guc, const u32 *action, u32
> len)
> +{
> + return intel_guc_ct_send(>ct, action, len, NULL, 0,
> + INTEL_GUC_SEND_NB);
> }
>
> static inline int
> @@ -82,7 +89,7 @@ intel_guc_send_and_receive(struct intel_guc *guc, const u32
> *action, u32
Re: [Intel-gfx] [PATCH] drm/i915/display/dg1: Correctly map DPLLs during state readout
On Wed, Jun 30, 2021 at 02:05:22PM -0700, Jose Souza wrote:
_DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
bit for phy C and D.
Reusing _cnl_ddi_get_pll() don't take that into cosideration returing
DPLL 0 and 1 for phy C and D.
That is a regression introduced in the refactor done in commit
c9fdceaa64dc ("drm/i915: Move DDI clock readout to encoder->get_config()").
While at it also dropping the macros previously used, not reusing it
to improve readability.
BSpec: 50286
Fixes: c9fdceaa64dc ("drm/i915: Move DDI clock readout to
encoder->get_config()")
Cc: Lucas De Marchi
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
Reviewed-by: Lucas De Marchi
thanks
Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
drivers/gpu/drm/i915/i915_reg.h | 3 ---
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 91fd85bee1d27..26a3aa73fcc43 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1738,10 +1738,23 @@ static struct intel_shared_dpll *dg1_ddi_get_pll(struct
intel_encoder *encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
+ enum intel_dpll_id id;
+ u32 val;
- return _cnl_ddi_get_pll(i915, DG1_DPCLKA_CFGCR0(phy),
- DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy),
- DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy));
+ val = intel_de_read(i915, DG1_DPCLKA_CFGCR0(phy));
+ val &= DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ val >>= DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ id = val;
+
+ /*
+* _DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
+* and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
+* bit for phy C and D.
+*/
+ if (phy >= PHY_C)
+ id += DPLL_ID_DG1_DPLL2;
+
+ return intel_get_shared_dpll_by_id(i915, id);
}
static void icl_ddi_combo_enable_clock(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65c155b141899..16a19239d86dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10525,7 +10525,6 @@ enum skl_power_gate {
#define _DG1_DPCLKA1_CFGCR0 0x16C280
#define _DG1_DPCLKA_PHY_IDX(phy)((phy) % 2)
#define _DG1_DPCLKA_PLL_IDX(pll)((pll) % 2)
-#define _DG1_PHY_DPLL_MAP(phy) ((phy) >= PHY_C ?
DPLL_ID_DG1_DPLL2 : DPLL_ID_DG1_DPLL0)
#define DG1_DPCLKA_CFGCR0(phy) _MMIO_PHY((phy) / 2, \
_DG1_DPCLKA_CFGCR0, \
_DG1_DPCLKA1_CFGCR0)
@@ -10533,8 +10532,6 @@ enum skl_power_gate {
#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy)
(_DG1_DPCLKA_PHY_IDX(phy) * 2)
#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL(pll, phy) (_DG1_DPCLKA_PLL_IDX(pll)
<< DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy) (0x3 <<
DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
-#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_DPLL_MAP(clk_sel, phy) \
- (((clk_sel) >> DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy)) +
_DG1_PHY_DPLL_MAP(phy))
/* ADLS Clocks */
#define _ADLS_DPCLKA_CFGCR0 0x164280
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/dg1: Correctly map DPLLs during state readout
== Series Details == Series: drm/i915/display/dg1: Correctly map DPLLs during state readout URL : https://patchwork.freedesktop.org/series/92086/ State : success == Summary == CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20499 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/index.html Known issues Here are the changes found in Patchwork_20499 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-cfl-8109u: [PASS][1] -> [INCOMPLETE][2] ([i915#155]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/fi-cfl-8109u/igt@gem_exec_susp...@basic-s0.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#1372]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#155]: https://gitlab.freedesktop.org/drm/intel/issues/155 Participating hosts (39 -> 35) -- Missing(4): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_10295 -> Patchwork_20499 CI-20190529: 20190529 CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20499: 5fce8912a42d082b6732b961c94fa6197d36b977 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5fce8912a42d drm/i915/display/dg1: Correctly map DPLLs during state readout == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dg1: Correctly map DPLLs during state readout
== Series Details ==
Series: drm/i915/display/dg1: Correctly map DPLLs during state readout
URL : https://patchwork.freedesktop.org/series/92086/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5fce8912a42d drm/i915/display/dg1: Correctly map DPLLs during state readout
-:23: WARNING:UNKNOWN_COMMIT_ID: Unknown commit id 'c9fdceaa64dc', maybe
rebased or not pulled?
#23:
Fixes: c9fdceaa64dc ("drm/i915: Move DDI clock readout to
encoder->get_config()")
total: 0 errors, 1 warnings, 0 checks, 41 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/display/dg1: Correctly map DPLLs during state readout
_DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
bit for phy C and D.
Reusing _cnl_ddi_get_pll() don't take that into cosideration returing
DPLL 0 and 1 for phy C and D.
That is a regression introduced in the refactor done in commit
c9fdceaa64dc ("drm/i915: Move DDI clock readout to encoder->get_config()").
While at it also dropping the macros previously used, not reusing it
to improve readability.
BSpec: 50286
Fixes: c9fdceaa64dc ("drm/i915: Move DDI clock readout to
encoder->get_config()")
Cc: Lucas De Marchi
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
drivers/gpu/drm/i915/i915_reg.h | 3 ---
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 91fd85bee1d27..26a3aa73fcc43 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1738,10 +1738,23 @@ static struct intel_shared_dpll *dg1_ddi_get_pll(struct
intel_encoder *encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum phy phy = intel_port_to_phy(i915, encoder->port);
+ enum intel_dpll_id id;
+ u32 val;
- return _cnl_ddi_get_pll(i915, DG1_DPCLKA_CFGCR0(phy),
- DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy),
- DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy));
+ val = intel_de_read(i915, DG1_DPCLKA_CFGCR0(phy));
+ val &= DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ val >>= DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ id = val;
+
+ /*
+* _DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
+* and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
+* bit for phy C and D.
+*/
+ if (phy >= PHY_C)
+ id += DPLL_ID_DG1_DPLL2;
+
+ return intel_get_shared_dpll_by_id(i915, id);
}
static void icl_ddi_combo_enable_clock(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 65c155b141899..16a19239d86dd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10525,7 +10525,6 @@ enum skl_power_gate {
#define _DG1_DPCLKA1_CFGCR00x16C280
#define _DG1_DPCLKA_PHY_IDX(phy) ((phy) % 2)
#define _DG1_DPCLKA_PLL_IDX(pll) ((pll) % 2)
-#define _DG1_PHY_DPLL_MAP(phy) ((phy) >= PHY_C ?
DPLL_ID_DG1_DPLL2 : DPLL_ID_DG1_DPLL0)
#define DG1_DPCLKA_CFGCR0(phy) _MMIO_PHY((phy) / 2, \
_DG1_DPCLKA_CFGCR0, \
_DG1_DPCLKA1_CFGCR0)
@@ -10533,8 +10532,6 @@ enum skl_power_gate {
#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy)
(_DG1_DPCLKA_PHY_IDX(phy) * 2)
#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL(pll, phy)
(_DG1_DPCLKA_PLL_IDX(pll) << DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy) (0x3 <<
DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
-#define DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_DPLL_MAP(clk_sel, phy) \
- (((clk_sel) >> DG1_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy)) +
_DG1_PHY_DPLL_MAP(phy))
/* ADLS Clocks */
#define _ADLS_DPCLKA_CFGCR00x164280
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Update to new HuC for TGL+ and enable GuC/HuC on ADL-P (rev2)
== Series Details ==
Series: Update to new HuC for TGL+ and enable GuC/HuC on ADL-P (rev2)
URL : https://patchwork.freedesktop.org/series/91932/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20498
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20498:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_20498 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([i915#1372])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][5] ([i915#1602] / [i915#2029])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/fi-bdw-5557u/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
Participating hosts (39 -> 35)
--
Missing(4): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus fi-bsw-n3050
Build changes
-
* Linux: CI_DRM_10295 -> Patchwork_20498
CI-20190529: 20190529
CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20498: 9c6ae7d51f0f99568a74703a9f8653057881dc56 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9c6ae7d51f0f drm/i915/adlp: Add ADL-P GuC/HuC firmware files
0759a6a770f5 drm/i915/huc: Update TGL and friends to HuC 7.9.3
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20498/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Fix -EDEADLK handling regression
== Series Details == Series: drm/i915/gt: Fix -EDEADLK handling regression URL : https://patchwork.freedesktop.org/series/92082/ State : success == Summary == CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20497 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/index.html Known issues Here are the changes found in Patchwork_20497 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@nop-compute0: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/fi-kbl-soraka/igt@amdgpu/amd_cs_...@nop-compute0.html * igt@i915_module_load@reload: - fi-kbl-soraka: [PASS][2] -> [DMESG-WARN][3] ([i915#1982]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-soraka/igt@i915_module_l...@reload.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/fi-kbl-soraka/igt@i915_module_l...@reload.html * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][4] ([i915#1602] / [i915#2029]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/fi-bdw-5557u/igt@run...@aborted.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029 Participating hosts (39 -> 36) -- Missing(3): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_10295 -> Patchwork_20497 CI-20190529: 20190529 CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20497: 222d1bd6e1e767781b7db298e0ff45379f78a61d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 222d1bd6e1e7 drm/i915/gt: Fix -EDEADLK handling regression == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20497/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for New uAPI drm properties for color management (rev3)
== Series Details ==
Series: New uAPI drm properties for color management (rev3)
URL : https://patchwork.freedesktop.org/series/91523/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20496
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20496:
### CI changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* boot:
- {fi-tgl-dsi}: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-tgl-dsi/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/fi-tgl-dsi/boot.html
Known issues
Here are the changes found in Patchwork_20496 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-bsw-nick:[PASS][3] -> [INCOMPLETE][4] ([i915#2539])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bsw-nick/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/fi-bsw-nick/igt@gem_exec_susp...@basic-s0.html
- fi-bsw-kefka: [PASS][5] -> [INCOMPLETE][6] ([i915#2539])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/fi-bsw-kefka/igt@gem_exec_susp...@basic-s0.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([i915#1372])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#2539]: https://gitlab.freedesktop.org/drm/intel/issues/2539
Participating hosts (39 -> 25)
--
Missing(14): fi-ilk-m540 fi-bxt-dsi fi-bsw-n3050 fi-glk-dsi fi-bsw-cyan
fi-bwr-2160 fi-snb-2520m fi-ilk-650 fi-hsw-4770 fi-ivb-3770 fi-elk-e7500
fi-pnv-d510 fi-bdw-samus fi-snb-2600
Build changes
-
* Linux: CI_DRM_10295 -> Patchwork_20496
CI-20190529: 20190529
CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20496: f1f5fc6be615238b6a54d0181acd8a08b5231f0c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f1f5fc6be615 drm/amd/display: Add handling for new "Broadcast RGB" property
5f414124d4e6 drm/i915/display: Use the general "Broadcast RGB" implementation
20d6a32d4c22 drm/uAPI: Move "Broadcast RGB" property from driver specific to
general context
204cfad3307a drm/i915/display: Add handling for new "preferred color format"
property
c49700e94fa3 drm/amd/display: Add handling for new "preferred color format"
property
6e2c78d00f47 drm/uAPI: Add "preferred color format" drm property as setting for
userspace
60c647d72801 drm/i915/display: Add handling for new "active color range"
property
7aaeb8fe964a drm/amd/display: Add handling for new "active color range" property
dea414d4c1f5 drm/uAPI: Add "active color range" drm property as feedback for
userspace
27a08747a4e0 drm/i915/display: Add handling for new "active color format"
property
b992c4fb2b09 drm/amd/display: Add handling for new "active color format"
property
c7e6abbdeea8 drm/uAPI: Add "active color format" drm property as feedback for
userspace
3e6ebc8ddc1c drm/i915/display: Add handling for new "active bpc" property
3ac175acf116 drm/amd/display: Add handling for new "active bpc" property
a3501a1254e9 drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm
property
acbc1fa10104 drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
de5b09605b88 drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20496/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote: > On Tue, 29 Jun 2021, Rodrigo Vivi wrote: > > Hi Dave and Daniel, > > > > Here goes drm-intel-next-fixes-2021-06-29: > > > > The biggest fix is the restoration of mmap ioctl for gen12 integrated parts > > which lack was breaking ADL-P with media stack. > > Besides that a small selftest fix and a theoretical overflow on > > i915->pipe_to_crtc_mapping. > > My last fixes pull for v5.13 fell between the cracks [1]. There was one > stable worthy fix, but since it was still in drm-intel-fixes when you > ran dim cherry-pick-next-fixes, it was skipped for drm-intel-next-fixes. > > I've now dropped the commit and pushed v5.13 to drm-intel-fixes, as > we're past that point. Subsequent dim cherry-pick-next-fixes should pick > it up now. it didn't, probably because the Fixes hash not being part of the drm-next yet?! I can cherry-pick that directly. Please let me know the commit id. Thanks, Rodrigo. > > Please do another next fixes pull request with that. (It's okay to pull > this one already though, doesn't make a difference.) > > > BR, > Jani. > > > [1] https://lore.kernel.org/r/87czsbu15r@intel.com > > > > > > > Thanks, > > Rodrigo. > > > > The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2: > > > > Merge tag 'exynos-drm-next-for-v5.14' of > > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into > > drm-next (2021-06-11 14:19:12 +1000) > > > > are available in the Git repository at: > > > > git://anongit.freedesktop.org/drm/drm-intel > > tags/drm-intel-next-fixes-2021-06-29 > > > > for you to fetch changes up to c90c4c6574f3feaf2203b5671db1907a1e15c653: > > > > drm/i915: Reinstate the mmap ioctl for some platforms (2021-06-28 > > 07:43:56 -0400) > > > > > > The biggest fix is the restoration of mmap ioctl for gen12 integrated parts > > which lack was breaking ADL-P with media stack. > > Besides that a small selftest fix and a theoretical overflow on > > i915->pipe_to_crtc_mapping. > > > > > > Chris Wilson (1): > > drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable > > > > Jani Nikula (1): > > drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary crtc > > > > Thomas Hellström (1): > > drm/i915: Reinstate the mmap ioctl for some platforms > > > > drivers/gpu/drm/i915/display/intel_display.c | 7 ++- > > drivers/gpu/drm/i915/display/intel_display_types.h | 8 > > drivers/gpu/drm/i915/display/intel_vdsc.c | 40 +++- > > drivers/gpu/drm/i915/display/intel_vdsc.h | 1 + > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +-- > > drivers/gpu/drm/i915/gt/selftest_execlists.c | 55 > > +- > > 6 files changed, 76 insertions(+), 42 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
4 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index fae01dc8e1b9..77981788204f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -54,6 +54,7 @@ struct intel_guc {
struct ida guc_ids;
struct list_head guc_id_list;
+ bool submission_supported;
bool submission_selected;
struct i915_vma *ads_vma;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a427336ce916..405339202280 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2042,6 +2042,13 @@ void intel_guc_submission_disable(struct
intel_guc *guc)
/* Note: By the time we're here, GuC may have already been
reset */
}
+static bool __guc_submission_supported(struct intel_guc *guc)
+{
+ /* GuC submission is unavailable for pre-Gen11 */
+ return intel_guc_is_supported(guc) &&
+ INTEL_GEN(guc_to_gt(guc)->i915) >= 11;
+}
+
static bool __guc_submission_selected(struct intel_guc *guc)
{
struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
@@ -2054,6 +2061,7 @@ static bool __guc_submission_selected(struct
intel_guc *guc)
void intel_guc_submission_init_early(struct intel_guc *guc)
{
+ guc->submission_supported = __guc_submission_supported(guc);
guc->submission_selected = __guc_submission_selected(guc);
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index a2a3fad72be1..be767eb6ff71 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -37,8 +37,7 @@ int intel_guc_wait_for_pending_msg(struct intel_guc
*guc,
static inline bool intel_guc_submission_is_supported(struct
intel_guc *guc)
{
- /* XXX: GuC submission is unavailable for now */
- return false;
+ return guc->submission_supported;
}
static inline bool intel_guc_submission_is_wanted(struct
intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7a69c3c027e9..61be0aa81492 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
intel_uc *uc)
return;
}
- /* Default: enable HuC authentication only */
- i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ /* Intermediate platforms are HuC authentication only */
+ if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+ drm_dbg(>drm, "Disabling GuC only due to old
platform\n");
This comment does not seem accurate, given that DG1 is barely out, and
ADL is not out yet. How about:
"Disabling GuC on untested platforms"?
Just because something is not in the shops yet does not mean it is new.
Technology is always obsolete by the time it goes on sale.
And the issue is not a lack of testing, it is a question of whether we
are allowed to change the default on something that has already started
being used by customers or not (including pre-release beta customers).
I.e. it is basically a political decision not an engineering decision.
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ return;
+ }
+
+ /* Default: enable HuC authentication and GuC submission */
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC |
ENABLE_GUC_SUBMISSION;
This seems to be in contradiction with the GuC submission plan which
states:
"Not enabled by default on any current platforms but can be enabled
via modparam enable_guc".
All current platforms have already been explicitly tested for above.
This is setting the default on newer platforms - ADL-P and later. For
which the official expectation is to have GuC enabled.
When you rework the patch, could you please add a warning when the
user force-enables the GuC Command Submission?
There already is one. If you set the module parameter then the kernel is
tainted. That means 'here be dragons' - you have done something
officially not supported to your kernel so all bets are off, if it blows
up it is your own problem.
Something like:
"WARNING: The user force-enabled the experimental GuC command
submission backend using i915.enable_guc. Please disable it if
experiencing
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for New uAPI drm properties for color management (rev3)
== Series Details == Series: New uAPI drm properties for color management (rev3) URL : https://patchwork.freedesktop.org/series/91523/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB"
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for New uAPI drm properties for color management (rev3)
== Series Details ==
Series: New uAPI drm properties for color management (rev3)
URL : https://patchwork.freedesktop.org/series/91523/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
de5b09605b88 drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
-:32: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the
previous line
#32: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:5331:
if (drm_mode_is_420_only(info, mode_in)
+ || (drm_mode_is_420_also(info, mode_in) &&
aconnector->force_yuv420_output))
total: 0 errors, 0 warnings, 1 checks, 11 lines checked
acbc1fa10104 drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
a3501a1254e9 drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm
property
3ac175acf116 drm/amd/display: Add handling for new "active bpc" property
-:43: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#43: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9113:
+ drm_connector_set_active_bpc_property(connector,
+ stream->timing.flags.DSC ?
-:45: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#45: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9115:
+ convert_dc_color_depth_into_bpc(
-:47: CHECK:BRACES: Unbalanced braces around else statement
#47: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9117:
+ } else
total: 0 errors, 0 warnings, 3 checks, 47 lines checked
3e6ebc8ddc1c drm/i915/display: Add handling for new "active bpc" property
-:33: CHECK:BRACES: braces {} should be used on all arms of this statement
#33: FILE: drivers/gpu/drm/i915/display/intel_display.c:10927:
+ if (crtc) {
[...]
+ } else
[...]
-:38: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#38: FILE: drivers/gpu/drm/i915/display/intel_display.c:10932:
+ drm_connector_set_active_bpc_property(connector,
+ new_crtc_state->dsc.compression_enable ?
-:41: CHECK:BRACES: Unbalanced braces around else statement
#41: FILE: drivers/gpu/drm/i915/display/intel_display.c:10935:
+ } else
total: 0 errors, 0 warnings, 3 checks, 68 lines checked
c7e6abbdeea8 drm/uAPI: Add "active color format" drm property as feedback for
userspace
b992c4fb2b09 drm/amd/display: Add handling for new "active color format"
property
-:20: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#20: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:6725:
+static int convert_dc_pixel_encoding_into_drm_color_format(
-:62: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#62: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9137:
+
drm_connector_set_active_color_format_property(connector,
+
convert_dc_pixel_encoding_into_drm_color_format(
-:62: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#62: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9137:
+
convert_dc_pixel_encoding_into_drm_color_format(
total: 0 errors, 0 warnings, 3 checks, 63 lines checked
27a08747a4e0 drm/i915/display: Add handling for new "active color format"
property
-:44: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#44: FILE: drivers/gpu/drm/i915/display/intel_display.c:10951:
+
drm_connector_set_active_color_format_property(connector,
+
convert_intel_output_format_into_drm_color_format(
-:44: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#44: FILE: drivers/gpu/drm/i915/display/intel_display.c:10951:
+
convert_intel_output_format_into_drm_color_format(
total: 0 errors, 0 warnings, 2 checks, 64 lines checked
dea414d4c1f5 drm/uAPI: Add "active color range" drm property as feedback for
userspace
7aaeb8fe964a drm/amd/display: Add handling for new "active color range" property
-:63: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#63: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9168:
+
drm_connector_set_active_color_range_property(connector,
+
convert_dc_color_space_into_drm_mode_color_range(
-:63: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#63: FILE: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:9168:
+
convert_dc_color_space_into_drm_mode_color_range(
total: 0 errors, 0 warnings, 2 checks, 65 lines checked
60c647d72801 drm/i915/display: Add handling for new "active color range"
property
-:21: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#21: FILE: drivers/gpu/drm/i915/display/intel_display.c:10954:
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: address potential UAF bugs with drm_master ptrs
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92076/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20495
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20495:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-dg1-1}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-dg1-1/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_20495 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-cml-s: [PASS][2] -> [DMESG-WARN][3] ([i915#3660])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-cml-s/igt@debugfs_test@read_all_entries.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-cml-s/igt@debugfs_test@read_all_entries.html
- fi-elk-e7500: [PASS][4] -> [DMESG-WARN][5] ([i915#3660])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-elk-e7500/igt@debugfs_test@read_all_entries.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-elk-e7500/igt@debugfs_test@read_all_entries.html
- fi-glk-dsi: [PASS][6] -> [DMESG-WARN][7] ([i915#3660])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-glk-dsi/igt@debugfs_test@read_all_entries.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-glk-dsi/igt@debugfs_test@read_all_entries.html
- fi-ivb-3770:[PASS][8] -> [DMESG-WARN][9] ([i915#3660])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-ivb-3770/igt@debugfs_test@read_all_entries.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-ivb-3770/igt@debugfs_test@read_all_entries.html
- fi-snb-2600:[PASS][10] -> [DMESG-WARN][11] ([i915#3660])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-snb-2600/igt@debugfs_test@read_all_entries.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-snb-2600/igt@debugfs_test@read_all_entries.html
- fi-kbl-guc: [PASS][12] -> [DMESG-WARN][13] ([i915#262] /
[i915#3660])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
- fi-bdw-gvtdvm: [PASS][14] -> [DMESG-WARN][15] ([i915#3660])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bdw-gvtdvm/igt@debugfs_test@read_all_entries.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-bdw-gvtdvm/igt@debugfs_test@read_all_entries.html
- fi-bsw-kefka: [PASS][16] -> [DMESG-WARN][17] ([i915#3660])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bsw-kefka/igt@debugfs_test@read_all_entries.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-bsw-kefka/igt@debugfs_test@read_all_entries.html
- fi-kbl-7500u: [PASS][18] -> [DMESG-WARN][19] ([i915#262] /
[i915#3660])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
- fi-bwr-2160:[PASS][20] -> [DMESG-WARN][21] ([i915#3660])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bwr-2160/igt@debugfs_test@read_all_entries.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-bwr-2160/igt@debugfs_test@read_all_entries.html
- fi-bdw-5557u: [PASS][22] -> [DMESG-WARN][23] ([i915#3660])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bdw-5557u/igt@debugfs_test@read_all_entries.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-bdw-5557u/igt@debugfs_test@read_all_entries.html
- fi-kbl-r: [PASS][24] -> [DMESG-WARN][25] ([i915#262] /
[i915#3660])
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-r/igt@debugfs_test@read_all_entries.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20495/fi-kbl-r/igt@debugfs_test@read_all_entries.html
- fi-kbl-7567u: [PASS][26] -> [DMESG-WARN][27] ([i915#262] /
[i915#3660])
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html
[27]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: address potential UAF bugs with drm_master ptrs
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92076/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
13940bd0a105 drm: avoid circular locks in drm_mode_getconnector
dbd6d7ef5160 drm: avoid circular locks in __drm_mode_object_find
-:37: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#37: FILE: drivers/gpu/drm/drm_mode_object.c:156:
+ if (obj && drm_mode_object_lease_required(obj->type) &&
+ !_drm_lease_held(file_priv, obj->id)) {
total: 0 errors, 0 warnings, 1 checks, 22 lines checked
21e2781892f6 drm: add a locked version of drm_is_current_master
057ea9e5fa3c drm: protect drm_master pointers in drm_lease.c
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: dma-buf fixes for migration
== Series Details == Series: drm/i915/gem: dma-buf fixes for migration URL : https://patchwork.freedesktop.org/series/92070/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20494 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20494 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20494, 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_20494/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20494: ### IGT changes ### Possible regressions * igt@i915_selftest@live@dmabuf: - fi-cfl-8700k: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-cfl-8700k/igt@i915_selftest@l...@dmabuf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-cfl-8700k/igt@i915_selftest@l...@dmabuf.html - fi-kbl-8809g: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-8809g/igt@i915_selftest@l...@dmabuf.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-kbl-8809g/igt@i915_selftest@l...@dmabuf.html - fi-glk-dsi: [PASS][5] -> [DMESG-FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-glk-dsi/igt@i915_selftest@l...@dmabuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-glk-dsi/igt@i915_selftest@l...@dmabuf.html - fi-snb-2520m: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-snb-2520m/igt@i915_selftest@l...@dmabuf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-snb-2520m/igt@i915_selftest@l...@dmabuf.html - fi-bsw-kefka: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bsw-kefka/igt@i915_selftest@l...@dmabuf.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-bsw-kefka/igt@i915_selftest@l...@dmabuf.html - fi-cfl-guc: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-cfl-guc/igt@i915_selftest@l...@dmabuf.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-cfl-guc/igt@i915_selftest@l...@dmabuf.html - fi-skl-6600u: [PASS][13] -> [DMESG-FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-skl-6600u/igt@i915_selftest@l...@dmabuf.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-skl-6600u/igt@i915_selftest@l...@dmabuf.html - fi-cml-s: [PASS][15] -> [DMESG-FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-cml-s/igt@i915_selftest@l...@dmabuf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-cml-s/igt@i915_selftest@l...@dmabuf.html - fi-pnv-d510:[PASS][17] -> [DMESG-FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-pnv-d510/igt@i915_selftest@l...@dmabuf.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-pnv-d510/igt@i915_selftest@l...@dmabuf.html - fi-kbl-7567u: [PASS][19] -> [DMESG-FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-7567u/igt@i915_selftest@l...@dmabuf.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-kbl-7567u/igt@i915_selftest@l...@dmabuf.html - fi-icl-y: [PASS][21] -> [DMESG-FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-icl-y/igt@i915_selftest@l...@dmabuf.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-icl-y/igt@i915_selftest@l...@dmabuf.html - fi-ilk-650: [PASS][23] -> [DMESG-FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-ilk-650/igt@i915_selftest@l...@dmabuf.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-ilk-650/igt@i915_selftest@l...@dmabuf.html - fi-ivb-3770:[PASS][25] -> [DMESG-FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-ivb-3770/igt@i915_selftest@l...@dmabuf.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-ivb-3770/igt@i915_selftest@l...@dmabuf.html - fi-skl-6700k2: [PASS][27] -> [DMESG-FAIL][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-skl-6700k2/igt@i915_selftest@l...@dmabuf.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20494/fi-skl-6700k2/igt@i915_selftest@l...@dmabuf.html - fi-elk-e7500: [PASS][29] -> [DMESG-FAIL][30] [29]:
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote:
>
>
> On 24/06/2021 10:05, Matthew Brost wrote:
> > From: Daniele Ceraolo Spurio
> >
> > Unblock GuC submission on Gen11+ platforms.
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 3 +--
> > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
> > 4 files changed, 19 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index fae01dc8e1b9..77981788204f 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -54,6 +54,7 @@ struct intel_guc {
> > struct ida guc_ids;
> > struct list_head guc_id_list;
> > + bool submission_supported;
> > bool submission_selected;
> > struct i915_vma *ads_vma;
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index a427336ce916..405339202280 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -2042,6 +2042,13 @@ void intel_guc_submission_disable(struct intel_guc
> > *guc)
> > /* Note: By the time we're here, GuC may have already been reset */
> > }
> > +static bool __guc_submission_supported(struct intel_guc *guc)
> > +{
> > + /* GuC submission is unavailable for pre-Gen11 */
> > + return intel_guc_is_supported(guc) &&
> > + INTEL_GEN(guc_to_gt(guc)->i915) >= 11;
> > +}
> > +
> > static bool __guc_submission_selected(struct intel_guc *guc)
> > {
> > struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
> > @@ -2054,6 +2061,7 @@ static bool __guc_submission_selected(struct
> > intel_guc *guc)
> > void intel_guc_submission_init_early(struct intel_guc *guc)
> > {
> > + guc->submission_supported = __guc_submission_supported(guc);
> > guc->submission_selected = __guc_submission_selected(guc);
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
> > index a2a3fad72be1..be767eb6ff71 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
> > @@ -37,8 +37,7 @@ int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
> > static inline bool intel_guc_submission_is_supported(struct intel_guc
> > *guc)
> > {
> > - /* XXX: GuC submission is unavailable for now */
> > - return false;
> > + return guc->submission_supported;
> > }
> > static inline bool intel_guc_submission_is_wanted(struct intel_guc *guc)
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > index 7a69c3c027e9..61be0aa81492 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > @@ -34,8 +34,15 @@ static void uc_expand_default_options(struct intel_uc
> > *uc)
> > return;
> > }
> > - /* Default: enable HuC authentication only */
> > - i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> > + /* Intermediate platforms are HuC authentication only */
> > + if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> > + drm_dbg(>drm, "Disabling GuC only due to old platform\n");
>
> This comment does not seem accurate, given that DG1 is barely out, and ADL
> is not out yet. How about:
>
> "Disabling GuC on untested platforms"?
This isn't my comment but it seems right to me. AFAIK this describes the
current PR but it is subject to change (i.e. we may enable GuC on DG1 by
default at some point).
>
> > + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> > + return;
> > + }
> > +
> > + /* Default: enable HuC authentication and GuC submission */
> > + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC | ENABLE_GUC_SUBMISSION;
>
> This seems to be in contradiction with the GuC submission plan which states:
>
> "Not enabled by default on any current platforms but can be enabled via
> modparam enable_guc".
>
I don't believe any current platform gets this point where GuC
submission would be enabled by default. The first would be ADL-P which
isn't out yet.
> When you rework the patch, could you please add a warning when the user
> force-enables the GuC Command Submission? Something like:
>
> "WARNING: The user force-enabled the experimental GuC command submission
> backend using i915.enable_guc. Please disable it if experiencing stability
> issues. No bug reports will be accepted on this backend".
>
> This should allow you to work on the backend, while communicating clearly to
> users that it is not ready just yet. Once it has
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: dma-buf fixes for migration
== Series Details == Series: drm/i915/gem: dma-buf fixes for migration URL : https://patchwork.freedesktop.org/series/92070/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3b50433924c8 drm/i915/gem: Make our dma-buf exporter dynamic -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: declare the exporter dynamic by providing pin() and unpin() implementations. total: 0 errors, 1 warnings, 0 checks, 202 lines checked bde352ace7ae drm/i915/gem: Migrate to system at dma-buf map time ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/vgem: Use 256B aligned pitch
== Series Details == Series: drm/vgem: Use 256B aligned pitch URL : https://patchwork.freedesktop.org/series/92067/ State : success == Summary == CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20492 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/index.html Known issues Here are the changes found in Patchwork_20492 that come from known issues: ### IGT changes ### Possible fixes * igt@prime_vgem@basic-fence-flip: - fi-bsw-kefka: [SKIP][1] ([fdo#109271]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/fi-bsw-kefka/igt@prime_v...@basic-fence-flip.html - fi-snb-2520m: [SKIP][3] ([fdo#109271]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-snb-2520m/igt@prime_v...@basic-fence-flip.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/fi-snb-2520m/igt@prime_v...@basic-fence-flip.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 Participating hosts (39 -> 36) -- Missing(3): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus Build changes - * Linux: CI_DRM_10295 -> Patchwork_20492 CI-20190529: 20190529 CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20492: fe15f53952c2cec06e3088b55450f758aa56a7e6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fe15f53952c2 drm/vgem: Use 256B aligned pitch == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20492/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: address potential UAF bugs with drm_master ptrs (rev3)
== Series Details == Series: drm: address potential UAF bugs with drm_master ptrs (rev3) URL : https://patchwork.freedesktop.org/series/91969/ State : failure == Summary == Applying: drm: avoid circular locks in drm_mode_getconnector Applying: drm: add a locked version of drm_is_current_master Applying: drm: protect drm_master pointers in drm_lease.c error: git diff header lacks filename information when removing 1 leading pathname component (line 2) error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm: protect drm_master pointers in drm_lease.c When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
On Wed, Jun 30, 2021 at 4:01 PM Daniel Vetter wrote:
> On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
> > If our exported dma-bufs are imported by another instance of our driver,
> > that instance will typically have the imported dma-bufs locked during
> > dma_buf_map_attachment(). But the exporter also locks the same reservation
> > object in the map_dma_buf() callback, which leads to recursive locking.
> >
> > Add a live selftest to exercise both dynamic and non-dynamic exports,
> > and as a workaround until we fully support dynamic import and export,
> > declare the exporter dynamic by providing pin() and unpin() implementations.
> > For dynamic importers, make sure we keep the pinning also in map_dma_buf(),
> > to ensure we never need to call dma_buf_move_notify().
> > Calling dma_buf_move_notify() is at the discretion of the exporter.
> >
> > v2:
> > - Extend the selftest with a fake dynamic importer.
> > - Provide real pin and unpin callbacks to not abuse the interface.
> >
> > Reported-by: Michael J. Ruhl
> > Signed-off-by: Thomas Hellström
>
> I'm not happy with this, because i915 is currently violating the dma-resv
> fencing rules for dynamic dma-buf.
>
> Yes since this is just the exporter we can probably get away with yolo'ing
> things, but Christian and me just spend a lot of angry typing figuring out
> what the rules actually are, so I really don't like bending them even more
> just because it's less typing.
To clarify what I meant here: I think the code is correct in the sense
that it's not breaking any other existing code upstream in a
functional or security relevant way.
What I meant with yolo merging is that if we land some dynamic dma-buf
exporter support just to fix a bug which with slightly more lines can
be fixed without resorting to quickly enabling dynamic dma-buf
exporting while a) we know i915 is breaking dma-resv rules already and
b) there was just a few weeks of rather angry discussions on this
topic.
That's just a recipe to piss people off, at least if I'd be in
Christian's shoes and see this land I'd get furious. So yolo on the
collaboration and people side of things, not so much technically
incorrect.
Plus with the sketch I described below we can fix the underlying issue
we're seeing in a clean way, by essentially aligning what i915 does to
what all other non-dynamic dma-buf ttm driver implementations do in
drm_prime.c. Defacto that's the only way that works, and it is the
contract for non-dynamic dma-buf for a driver using dma_resv_lock. The
only reason we could get away without lockdep splats with our current
dma-buf code in i915 of attempting to handle dma-buf more dynamic was
because we used our completely independent locking design (and also
never shared with another i915 instance). That illusion falls apart
with i915 using dma-resv and with now multiple i915 instances being
possible.
tldr; Using this way we can cleanly untangle solving the locking issue
at hand from the fairly bigger topic of how we are going to support
dynamic dma-buf and p2p and all that in i915.
I hope this explains a bit better why I have my take here like that.
-Daniel
> All we need for a quick interim fix is to not take the dma_resv_lock from
> our map/unamp callbacks. Pinning our backing storage from attach/detach
> callbacks (which are also called under dma_resv_lock) would also achieve
> that, without mudding any waters. So essentially just moving the
> pin/unpin_pages_unlocked and we should be good, which is almost as little
> typing.
>
> Michael, since Thomas is on vacations now, care to type that up? The
> selftest is imo solid.
>
> This is also consistent with what all other ttm based drivers do (aside
> from amdgpu, which is fully dynamic), see drm_gem_map_attach in
> drm_prime.c
>
> Adding Christian as fyi.
> -Daniel
>
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 -
> > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 116 +-
> > 2 files changed, 143 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > index 616c3a2f1baf..918c19df7b66 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> > @@ -12,6 +12,8 @@
> > #include "i915_gem_object.h"
> > #include "i915_scatterlist.h"
> >
> > +I915_SELFTEST_DECLARE(static bool force_different_devices;)
> > +
> > static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> > {
> > return to_intel_bo(buf->priv);
> > @@ -25,7 +27,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> > dma_buf_attachment *attachme
> > struct scatterlist *src, *dst;
> > int ret, i;
> >
> > - ret = i915_gem_object_pin_pages_unlocked(obj);
> > + assert_object_held(obj);
> > +
> > + /*
> > + * Note. In the dynamic importer case, the object is not yet pinned.
> > + * Let's pin it here to avoid
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: IRQ fixes (rev2)
== Series Details ==
Series: drm/i915: IRQ fixes (rev2)
URL : https://patchwork.freedesktop.org/series/92053/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20491
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20491:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_selftest@live@gem_migrate}:
- {fi-dg1-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-dg1-1/igt@i915_selftest@live@gem_migrate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-dg1-1/igt@i915_selftest@live@gem_migrate.html
* igt@i915_selftest@live@gt_heartbeat:
- {fi-ehl-2}: [PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-ehl-2/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-ehl-2/igt@i915_selftest@live@gt_heartbeat.html
* igt@runner@aborted:
- {fi-dg1-1}: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-dg1-1/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_20491 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: [PASS][6] -> [INCOMPLETE][7] ([i915#2782])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#2122])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10295/fi-bsw-kefka/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-bsw-kefka/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][10] ([i915#1602] / [i915#2029])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka: NOTRUN -> [FAIL][11] ([i915#1436] / [i915#3363])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/fi-kbl-soraka/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
Participating hosts (39 -> 36)
--
Missing(3): fi-ilk-m540 fi-bsw-cyan fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10295 -> Patchwork_20491
CI-20190529: 20190529
CI_DRM_10295: 683b7f160eb6993ccfc19e67e3c7111f12946bea @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6124: 357d5477c93f2bdd3354afe91b89ccfd4ee4fd56 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20491: c59dbcab463129aebc932254b2d1ba366629118d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c59dbcab4631 drm/i915: Drop all references to DRM IRQ midlayer
2d086f7fab68 drm/i915: Use the correct IRQ during resume
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20491/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Use the correct IRQ during resume
On Wed, Jun 30, 2021 at 4:18 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.06.21 um 12:49 schrieb Daniel Vetter:
> > On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
> >> The code in xcs_resume() probably didn't work as intended. It uses
> >> struct drm_device.irq, which is allocated to 0, but never initialized
> >> by i915 to the device's interrupt number.
> >>
> >> v3:
> >> * also use intel_synchronize_hardirq() at another callsite
> >> v2:
> >> * wrap irq code in intel_synchronize_hardirq() (Ville)
> >>
> >> Signed-off-by: Thomas Zimmermann
> >> Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume,
> >> again")
> >> Cc: Chris Wilson
> >> Cc: Mika Kuoppala
> >> Cc: Daniel Vetter
> >> Cc: Rodrigo Vivi
> >> Cc: Joonas Lahtinen
> >> Cc: Maarten Lankhorst
> >> Cc: Lucas De Marchi
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> >> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
> >> drivers/gpu/drm/i915/i915_irq.c | 5 +
> >> drivers/gpu/drm/i915/i915_irq.h | 1 +
> >> 4 files changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> index 88694822716a..5ca3d1664335 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> >> @@ -1229,7 +1229,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> >> *engine)
> >> return true;
> >>
> >> /* Waiting to drain ELSP? */
> >> -synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
> >> +intel_synchronize_hardirq(engine->i915);
> >> intel_engine_flush_submission(engine);
> >>
> >> /* ELSP is empty, but there are ready requests? E.g. after reset */
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> >> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> >> index 5d42a12ef3d6..1b5a22a83db6 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> >> @@ -185,7 +185,7 @@ static int xcs_resume(struct intel_engine_cs *engine)
> >> ring->head, ring->tail);
> >>
> >> /* Double check the ring is empty & disabled before we resume */
> >> -synchronize_hardirq(engine->i915->drm.irq);
> >> +intel_synchronize_hardirq(engine->i915);
> >> if (!stop_ring(engine))
> >> goto err;
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> >> b/drivers/gpu/drm/i915/i915_irq.c
> >> index 7d0ce8b9f8ed..2203dca19895 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.c
> >> +++ b/drivers/gpu/drm/i915/i915_irq.c
> >> @@ -4575,3 +4575,8 @@ void intel_synchronize_irq(struct drm_i915_private
> >> *i915)
> >> {
> >> synchronize_irq(to_pci_dev(i915->drm.dev)->irq);
> >> }
> >> +
> >> +void intel_synchronize_hardirq(struct drm_i915_private *i915)
> >> +{
> >> +synchronize_hardirq(to_pci_dev(i915->drm.dev)->irq);
> >
> > I honestly think the hardirq here is about as much cargo-culted as using
> > the wrong irq number.
> >
> > I'd just use intel_synchronize_irq in both places and see whether CI
> > complains, then go with that.
>
> Well, ok. I don't think I have Sandybridge HW available. Would the Intel
> CI infrastructure catch any problems with such a change?
If there's anything obvious busted with it it should catch it (like if
we end up calling synchronize_irq from softirq context, where only
synchronize_hardirq is allowed, but I don't think that's the case).
And if I'm wrong we know what kind of comment to put there to explain
why things are different.
-Daniel
> Best regards
> Thomas
>
> > -Daniel
> >
> >> +}
> >> diff --git a/drivers/gpu/drm/i915/i915_irq.h
> >> b/drivers/gpu/drm/i915/i915_irq.h
> >> index db34d5dbe402..e43b6734f21b 100644
> >> --- a/drivers/gpu/drm/i915/i915_irq.h
> >> +++ b/drivers/gpu/drm/i915/i915_irq.h
> >> @@ -94,6 +94,7 @@ void intel_runtime_pm_disable_interrupts(struct
> >> drm_i915_private *dev_priv);
> >> void intel_runtime_pm_enable_interrupts(struct drm_i915_private
> >> *dev_priv);
> >> bool intel_irqs_enabled(struct drm_i915_private *dev_priv);
> >> void intel_synchronize_irq(struct drm_i915_private *i915);
> >> +void intel_synchronize_hardirq(struct drm_i915_private *i915);
> >>
> >> int intel_get_crtc_scanline(struct intel_crtc *crtc);
> >> void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> >> --
> >> 2.32.0
> >>
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ttm: Reorganize the ttm move code somewhat
On Wed, Jun 30, 2021 at 6:54 PM Matthew Auld
wrote:
>
> On Wed, 30 Jun 2021 at 16:27, Thomas Hellström
> wrote:
> >
> > On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> > > On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> > > wrote:
> > > >
> > > > In order to make the code a bit more readable and to facilitate
> > > > async memcpy moves, reorganize the move code a little. Determine
> > > > at an early stage whether to copy or to clear.
> > > >
> > > > Signed-off-by: Thomas Hellström
> > > > ---
> > > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++---
> > > >
> > > > 1 file changed, 40 insertions(+), 30 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > index c39d982c4fa6..4e529adcdfc7 100644
> > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > > @@ -431,6 +431,7 @@ i915_ttm_resource_get_st(struct
> > > > drm_i915_gem_object *obj,
> > > > }
> > > >
> > > > static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
> > > > + bool clear,
> > > >struct ttm_resource *dst_mem,
> > > >struct sg_table *dst_st)
> > > > {
> > > > @@ -449,13 +450,10 @@ static int i915_ttm_accel_move(struct
> > > > ttm_buffer_object *bo,
> > > > return -EINVAL;
> > > >
> > > > dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
> > > > - if (!ttm || !ttm_tt_is_populated(ttm)) {
> > > > + if (clear) {
> > > > if (bo->type == ttm_bo_type_kernel)
> > > > return -EINVAL;
> > >
> > > Was that meant to be:
> > > return 0:
> > >
> > > ?
> > >
> > > Also does that mean we are incorrectly falling back to memset, for
> > > non-userspace objects, instead of making it a noop?
> >
> > No, we're deliberately falling back to memset for non-userspace
> > objects, but the logic only memsets in the BO_ALLOC_CPU_CLEAR case if
> > everything is implemented correctly.
> >
> > >
> > > >
> > > > - if (ttm && !(ttm->page_flags &
> > > > TTM_PAGE_FLAG_ZERO_ALLOC))
> > > > - return 0;
> > > > -
> > > > intel_engine_pm_get(i915->gt.migrate.context-
> > > > >engine);
> > > > ret = intel_context_migrate_clear(i915-
> > > > >gt.migrate.context, NULL,
> > > > dst_st->sgl,
> > > > dst_level,
> > > > @@ -489,27 +487,53 @@ static int i915_ttm_accel_move(struct
> > > > ttm_buffer_object *bo,
> > > > return ret;
> > > > }
> > > >
> > > > -static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
> > > > -struct ttm_operation_ctx *ctx,
> > > > -struct ttm_resource *dst_mem,
> > > > -struct ttm_place *hop)
> > > > +static void __i915_ttm_move(struct ttm_buffer_object *bo, bool
> > > > clear,
> > > > + struct ttm_resource *dst_mem,
> > > > + struct sg_table *dst_st)
> > > > {
> > > > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> > > > - struct ttm_resource_manager *dst_man =
> > > > - ttm_manager_type(bo->bdev, dst_mem->mem_type);
> > > > struct intel_memory_region *dst_reg, *src_reg;
> > > > union {
> > > > struct ttm_kmap_iter_tt tt;
> > > > struct ttm_kmap_iter_iomap io;
> > > > } _dst_iter, _src_iter;
> > > > struct ttm_kmap_iter *dst_iter, *src_iter;
> > > > - struct sg_table *dst_st;
> > > > int ret;
> > > >
> > > > dst_reg = i915_ttm_region(bo->bdev, dst_mem->mem_type);
> > > > src_reg = i915_ttm_region(bo->bdev, bo->resource-
> > > > >mem_type);
> > > > GEM_BUG_ON(!dst_reg || !src_reg);
> > > >
> > > > + ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
> > > > + if (ret) {
> > >
> > > One future consideration is flat CCS where I don't think we can
> > > easily
> > > fall back to memcpy for userspace objects. Maybe we can make this
> > > fallback conditional on DG1 or !ALLOC_USER for now, or just add a
> > > TODO?
> >
> > Ugh. Is that true for both clearing and copying, or is it only copying?
>
> With clearing I think we are required to nuke the aux CCS state using
> some special blitter command.
>
> For copying/moving I think it's a similar story, where special care
> might be needed for the aux state, which likely requires the blitter.
> Although tbh I don't really remember all the details.
There's more than just flat CCS, for dg2 we'll also support resizeable
BAR with the goal to make the non-mappable lmem available too. Afaik
there's no fallback way to access that memory without a copy engine.
I think on those platforms we simply have to go back to wedging the
driver if reset of the copy
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ttm: Reorganize the ttm move code somewhat
On Wed, 30 Jun 2021 at 16:27, Thomas Hellström
wrote:
>
> On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> > On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> > wrote:
> > >
> > > In order to make the code a bit more readable and to facilitate
> > > async memcpy moves, reorganize the move code a little. Determine
> > > at an early stage whether to copy or to clear.
> > >
> > > Signed-off-by: Thomas Hellström
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++---
> > >
> > > 1 file changed, 40 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > index c39d982c4fa6..4e529adcdfc7 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > > @@ -431,6 +431,7 @@ i915_ttm_resource_get_st(struct
> > > drm_i915_gem_object *obj,
> > > }
> > >
> > > static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
> > > + bool clear,
> > >struct ttm_resource *dst_mem,
> > >struct sg_table *dst_st)
> > > {
> > > @@ -449,13 +450,10 @@ static int i915_ttm_accel_move(struct
> > > ttm_buffer_object *bo,
> > > return -EINVAL;
> > >
> > > dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
> > > - if (!ttm || !ttm_tt_is_populated(ttm)) {
> > > + if (clear) {
> > > if (bo->type == ttm_bo_type_kernel)
> > > return -EINVAL;
> >
> > Was that meant to be:
> > return 0:
> >
> > ?
> >
> > Also does that mean we are incorrectly falling back to memset, for
> > non-userspace objects, instead of making it a noop?
>
> No, we're deliberately falling back to memset for non-userspace
> objects, but the logic only memsets in the BO_ALLOC_CPU_CLEAR case if
> everything is implemented correctly.
>
> >
> > >
> > > - if (ttm && !(ttm->page_flags &
> > > TTM_PAGE_FLAG_ZERO_ALLOC))
> > > - return 0;
> > > -
> > > intel_engine_pm_get(i915->gt.migrate.context-
> > > >engine);
> > > ret = intel_context_migrate_clear(i915-
> > > >gt.migrate.context, NULL,
> > > dst_st->sgl,
> > > dst_level,
> > > @@ -489,27 +487,53 @@ static int i915_ttm_accel_move(struct
> > > ttm_buffer_object *bo,
> > > return ret;
> > > }
> > >
> > > -static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
> > > -struct ttm_operation_ctx *ctx,
> > > -struct ttm_resource *dst_mem,
> > > -struct ttm_place *hop)
> > > +static void __i915_ttm_move(struct ttm_buffer_object *bo, bool
> > > clear,
> > > + struct ttm_resource *dst_mem,
> > > + struct sg_table *dst_st)
> > > {
> > > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> > > - struct ttm_resource_manager *dst_man =
> > > - ttm_manager_type(bo->bdev, dst_mem->mem_type);
> > > struct intel_memory_region *dst_reg, *src_reg;
> > > union {
> > > struct ttm_kmap_iter_tt tt;
> > > struct ttm_kmap_iter_iomap io;
> > > } _dst_iter, _src_iter;
> > > struct ttm_kmap_iter *dst_iter, *src_iter;
> > > - struct sg_table *dst_st;
> > > int ret;
> > >
> > > dst_reg = i915_ttm_region(bo->bdev, dst_mem->mem_type);
> > > src_reg = i915_ttm_region(bo->bdev, bo->resource-
> > > >mem_type);
> > > GEM_BUG_ON(!dst_reg || !src_reg);
> > >
> > > + ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
> > > + if (ret) {
> >
> > One future consideration is flat CCS where I don't think we can
> > easily
> > fall back to memcpy for userspace objects. Maybe we can make this
> > fallback conditional on DG1 or !ALLOC_USER for now, or just add a
> > TODO?
>
> Ugh. Is that true for both clearing and copying, or is it only copying?
With clearing I think we are required to nuke the aux CCS state using
some special blitter command.
For copying/moving I think it's a similar story, where special care
might be needed for the aux state, which likely requires the blitter.
Although tbh I don't really remember all the details.
>
> Problem is if we hit an engine reset and fence error during initial
> clearing / swapin, the plan moving forward is to intercept that and
> resort to cpu clearing / copying for security reasons. In the worst
> case we at least need to be able to clear.
>
> /Thomas
>
>
> >
> > > + dst_iter = !cpu_maps_iomem(dst_mem) ?
> > > + ttm_kmap_iter_tt_init(&_dst_iter.tt, bo-
> > > >ttm) :
> > > + ttm_kmap_iter_iomap_init(&_dst_iter.io,
> > > _reg->iomap,
> > > +dst_st, dst_reg-
> >
[Intel-gfx] [PATCH] drm/i915/gt: Fix -EDEADLK handling regression
From: Ville Syrjälä
The conversion to ww mutexes failed to address the fence code which
already returns -EDEADLK when we run out of fences. Ww mutexes on
the other hand treat -EDEADLK as an internal errno value indicating
a need to restart the operation due to a deadlock. So now when the
fence code returns -EDEADLK the higher level code erroneously
restarts everything instead of returning the error to userspace
as is expected.
To remedy this let's switch the fence code to use a different errno
value for this. -ENOBUFS seems like a semi-reasonable unique choice.
Apart from igt the only user of this I could find is sna, and even
there all we do is dump the current fence registers from debugfs
into the X server log. So no user visible functionality is affected.
If we really cared about preserving this we could of course convert
back to -EDEADLK higher up, but doesn't seem like that's worth
the hassle here.
Not quite sure which commit specifically broke this, but I'll
just attribute it to the general gem ww mutex work.
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Thomas Hellström
Testcase: igt/gem_pread/exhaustion
Testcase: igt/gem_pwrite/basic-exhaustion
Testcase: igt/gem_fenced_exec_thrash/too-many-fences
Fixes: 80f0b679d6f0 ("drm/i915: Add an implementation for i915_gem_ww_ctx
locking, v2.")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
index cac7f3f44642..f8948de72036 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c
@@ -348,7 +348,7 @@ static struct i915_fence_reg *fence_find(struct i915_ggtt
*ggtt)
if (intel_has_pending_fb_unpin(ggtt->vm.i915))
return ERR_PTR(-EAGAIN);
- return ERR_PTR(-EDEADLK);
+ return ERR_PTR(-ENOBUFS);
}
int __i915_vma_pin_fence(struct i915_vma *vma)
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: IRQ fixes (rev2)
== Series Details == Series: drm/i915: IRQ fixes (rev2) URL : https://patchwork.freedesktop.org/series/92053/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ttm: Reorganize the ttm move code somewhat
On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> wrote:
> >
> > In order to make the code a bit more readable and to facilitate
> > async memcpy moves, reorganize the move code a little. Determine
> > at an early stage whether to copy or to clear.
> >
> > Signed-off-by: Thomas Hellström
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++---
> >
> > 1 file changed, 40 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > index c39d982c4fa6..4e529adcdfc7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> > @@ -431,6 +431,7 @@ i915_ttm_resource_get_st(struct
> > drm_i915_gem_object *obj,
> > }
> >
> > static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
> > + bool clear,
> > struct ttm_resource *dst_mem,
> > struct sg_table *dst_st)
> > {
> > @@ -449,13 +450,10 @@ static int i915_ttm_accel_move(struct
> > ttm_buffer_object *bo,
> > return -EINVAL;
> >
> > dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
> > - if (!ttm || !ttm_tt_is_populated(ttm)) {
> > + if (clear) {
> > if (bo->type == ttm_bo_type_kernel)
> > return -EINVAL;
>
> Was that meant to be:
> return 0:
>
> ?
>
> Also does that mean we are incorrectly falling back to memset, for
> non-userspace objects, instead of making it a noop?
No, we're deliberately falling back to memset for non-userspace
objects, but the logic only memsets in the BO_ALLOC_CPU_CLEAR case if
everything is implemented correctly.
>
> >
> > - if (ttm && !(ttm->page_flags &
> > TTM_PAGE_FLAG_ZERO_ALLOC))
> > - return 0;
> > -
> > intel_engine_pm_get(i915->gt.migrate.context-
> > >engine);
> > ret = intel_context_migrate_clear(i915-
> > >gt.migrate.context, NULL,
> > dst_st->sgl,
> > dst_level,
> > @@ -489,27 +487,53 @@ static int i915_ttm_accel_move(struct
> > ttm_buffer_object *bo,
> > return ret;
> > }
> >
> > -static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
> > - struct ttm_operation_ctx *ctx,
> > - struct ttm_resource *dst_mem,
> > - struct ttm_place *hop)
> > +static void __i915_ttm_move(struct ttm_buffer_object *bo, bool
> > clear,
> > + struct ttm_resource *dst_mem,
> > + struct sg_table *dst_st)
> > {
> > struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> > - struct ttm_resource_manager *dst_man =
> > - ttm_manager_type(bo->bdev, dst_mem->mem_type);
> > struct intel_memory_region *dst_reg, *src_reg;
> > union {
> > struct ttm_kmap_iter_tt tt;
> > struct ttm_kmap_iter_iomap io;
> > } _dst_iter, _src_iter;
> > struct ttm_kmap_iter *dst_iter, *src_iter;
> > - struct sg_table *dst_st;
> > int ret;
> >
> > dst_reg = i915_ttm_region(bo->bdev, dst_mem->mem_type);
> > src_reg = i915_ttm_region(bo->bdev, bo->resource-
> > >mem_type);
> > GEM_BUG_ON(!dst_reg || !src_reg);
> >
> > + ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
> > + if (ret) {
>
> One future consideration is flat CCS where I don't think we can
> easily
> fall back to memcpy for userspace objects. Maybe we can make this
> fallback conditional on DG1 or !ALLOC_USER for now, or just add a
> TODO?
Ugh. Is that true for both clearing and copying, or is it only copying?
Problem is if we hit an engine reset and fence error during initial
clearing / swapin, the plan moving forward is to intercept that and
resort to cpu clearing / copying for security reasons. In the worst
case we at least need to be able to clear.
/Thomas
>
> > + dst_iter = !cpu_maps_iomem(dst_mem) ?
> > + ttm_kmap_iter_tt_init(&_dst_iter.tt, bo-
> > >ttm) :
> > + ttm_kmap_iter_iomap_init(&_dst_iter.io,
> > _reg->iomap,
> > + dst_st, dst_reg-
> > >region.start);
> > +
> > + src_iter = !cpu_maps_iomem(bo->resource) ?
> > + ttm_kmap_iter_tt_init(&_src_iter.tt, bo-
> > >ttm) :
> > + ttm_kmap_iter_iomap_init(&_src_iter.io,
> > _reg->iomap,
> > + obj-
> > >ttm.cached_io_st,
> > + src_reg-
> > >region.start);
> > +
> > + ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter,
> > src_iter);
> > + }
> > +}
> > +
> > +static int i915_ttm_move(struct
[Intel-gfx] [PATCH v5 15/17] drm/uAPI: Move "Broadcast RGB" property from driver specific to general context
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.
Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detection.
Possible options are:
- Automatic (default/current behaviour)
- Full
- Limited 16:235
In theory the driver should be able to automatically detect the monitors
capabilities, but because of flawed standard implementations in Monitors,
this might fail. In this case a manual overwrite is required to not have
washed out colors or lose details in very dark or bright scenes.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 46 +
include/drm/drm_connector.h | 16 ++
4 files changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 90d62f305257..0c89d32efbd0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -691,6 +691,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->preferred_color_format !=
new_connector_state->preferred_color_format)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->preferred_color_range !=
+ new_connector_state->preferred_color_range)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c536f5e22016..c589bb1a8163 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -798,6 +798,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->max_requested_bpc = val;
} else if (property == connector->preferred_color_format_property) {
state->preferred_color_format = val;
+ } else if (property == connector->preferred_color_range_property) {
+ state->preferred_color_range = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -877,6 +879,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->max_requested_bpc;
} else if (property == connector->preferred_color_format_property) {
*val = state->preferred_color_format;
+ } else if (property == connector->preferred_color_range_property) {
+ *val = state->preferred_color_range;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 67dd59b12258..20ae2e6d907b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -905,6 +905,12 @@ static const struct drm_prop_enum_list
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
};
+static const struct drm_prop_enum_list drm_preferred_color_range_enum_list[] =
{
+ { DRM_MODE_COLOR_RANGE_UNSET, "Automatic" },
+ { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+ { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
{ DRM_MODE_COLOR_RANGE_UNSET, "Not Applicable" },
{ DRM_MODE_COLOR_RANGE_FULL, "Full" },
@@ -1246,6 +1252,15 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* property. Possible values are "not applicable", "rgb", "ycbcr444",
* "ycbcr422", and "ycbcr420".
*
+ * Broadcast RGB:
+ * This property is used by userspace to change the used color range. This
+ * property affects the RGB color format as well as the Y'CbCr color
+ * formats, if the driver supports both full and limited Y'CbCr. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization. Possible values are "Automatic", "Full", and "Limited
+ * 16:235".
+ *
* active color range:
* This read-only property tells userspace the color range actually used by
* the hardware display engine "on the cable" on a connector. The chosen
@@ -2331,6 +2346,37 @@ void
drm_connector_set_active_color_format_property(struct drm_connector *connec
}
[Intel-gfx] [PATCH v5 11/17] drm/i915/display: Add handling for new "active color range" property
This commit implements the "active color range" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c| 1 +
4 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index be38f7148285..b0bcb42a97fc 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10940,9 +10940,16 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_connector_set_active_color_format_property(connector,
convert_intel_output_format_into_drm_color_format(
new_crtc_state->output_format));
+ drm_connector_set_active_color_range_property(connector,
+ new_crtc_state->limited_color_range ||
+ new_crtc_state->output_format !=
INTEL_OUTPUT_FORMAT_RGB ?
+ DRM_MODE_COLOR_RANGE_LIMITED_16_235 :
+ DRM_MODE_COLOR_RANGE_FULL);
} else {
drm_connector_set_active_bpc_property(connector, 0);
drm_connector_set_active_color_format_property(connector, 0);
+ drm_connector_set_active_color_range_property(connector,
+
DRM_MODE_COLOR_RANGE_UNSET);
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6b85bcdeb238..fd33f753244d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,6 +4688,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ drm_connector_attach_active_color_range_property(connector);
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 3e4237df3360..cb876175258f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -861,6 +861,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(connector);
+ connector->active_color_range_property =
+ intel_dp->attached_connector->base.active_color_range_property;
+ if (connector->active_color_range_property)
+ drm_connector_attach_active_color_range_property(connector);
+
return connector;
err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 367aba57b55f..3ee25e0cc3b9 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2505,6 +2505,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ drm_connector_attach_active_color_range_property(connector);
intel_attach_aspect_ratio_property(connector);
intel_attach_hdmi_colorspace_property(connector);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 16/17] drm/i915/display: Use the general "Broadcast RGB" implementation
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.
This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_atomic.c | 8 --
.../gpu/drm/i915/display/intel_connector.c| 28 ---
.../gpu/drm/i915/display/intel_connector.h| 1 -
.../drm/i915/display/intel_display_types.h| 8 --
drivers/gpu/drm/i915/display/intel_dp.c | 9 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 8 ++
drivers/gpu/drm/i915/display/intel_sdvo.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 -
9 files changed, 12 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index b4e7ac51aa31..f8d5a0e287b0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -63,8 +63,6 @@ int intel_digital_connector_atomic_get_property(struct
drm_connector *connector,
if (property == dev_priv->force_audio_property)
*val = intel_conn_state->force_audio;
- else if (property == dev_priv->broadcast_rgb_property)
- *val = intel_conn_state->broadcast_rgb;
else {
drm_dbg_atomic(_priv->drm,
"Unknown property [PROP:%d:%s]\n",
@@ -99,11 +97,6 @@ int intel_digital_connector_atomic_set_property(struct
drm_connector *connector,
return 0;
}
- if (property == dev_priv->broadcast_rgb_property) {
- intel_conn_state->broadcast_rgb = val;
- return 0;
- }
-
drm_dbg_atomic(_priv->drm, "Unknown property [PROP:%d:%s]\n",
property->base.id, property->name);
return -EINVAL;
@@ -134,7 +127,6 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
* up in a modeset.
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
- new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
b/drivers/gpu/drm/i915/display/intel_connector.c
index 9bed1ccecea0..89f0edf19182 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.c
+++ b/drivers/gpu/drm/i915/display/intel_connector.c
@@ -241,34 +241,6 @@ intel_attach_force_audio_property(struct drm_connector
*connector)
drm_object_attach_property(>base, prop, 0);
}
-static const struct drm_prop_enum_list broadcast_rgb_names[] = {
- { INTEL_BROADCAST_RGB_AUTO, "Automatic" },
- { INTEL_BROADCAST_RGB_FULL, "Full" },
- { INTEL_BROADCAST_RGB_LIMITED, "Limited 16:235" },
-};
-
-void
-intel_attach_broadcast_rgb_property(struct drm_connector *connector)
-{
- struct drm_device *dev = connector->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_property *prop;
-
- prop = dev_priv->broadcast_rgb_property;
- if (prop == NULL) {
- prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
- "Broadcast RGB",
- broadcast_rgb_names,
- ARRAY_SIZE(broadcast_rgb_names));
- if (prop == NULL)
- return;
-
- dev_priv->broadcast_rgb_property = prop;
- }
-
- drm_object_attach_property(>base, prop, 0);
-}
-
void
intel_attach_aspect_ratio_property(struct drm_connector *connector)
{
diff --git a/drivers/gpu/drm/i915/display/intel_connector.h
b/drivers/gpu/drm/i915/display/intel_connector.h
index 661a37a3c6d8..f3058a035476 100644
--- a/drivers/gpu/drm/i915/display/intel_connector.h
+++ b/drivers/gpu/drm/i915/display/intel_connector.h
@@ -28,7 +28,6 @@ int intel_connector_update_modes(struct drm_connector
*connector,
struct edid *edid);
int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
void intel_attach_force_audio_property(struct drm_connector *connector);
-void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
void intel_attach_hdmi_colorspace_property(struct drm_connector *connector);
void intel_attach_dp_colorspace_property(struct drm_connector *connector);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
[Intel-gfx] [PATCH v5 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr420
In theory the auto option should choose the best available option for the
current setup, but because of bad internal conversion some monitors look
better with rgb and some with ycbcr444.
Also, because of bad shielded connectors and/or cables, it might be
preferable to use the less bandwidth heavy ycbcr422 and ycbcr420 formats
for a signal that is less deceptible to interference.
In the future, automatic color calibration for screens might also depend on
this option being available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +++
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 50 -
include/drm/drm_connector.h | 17 ++
4 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index bc3487964fb5..90d62f305257 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -687,6 +687,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->max_requested_bpc !=
new_connector_state->max_requested_bpc)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->preferred_color_format !=
+ new_connector_state->preferred_color_format)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 438e9585b225..c536f5e22016 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -796,6 +796,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+ } else if (property == connector->preferred_color_format_property) {
+ state->preferred_color_format = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -873,6 +875,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == connector->preferred_color_format_property) {
+ *val = state->preferred_color_format;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ebfdd17a7f59..67dd59b12258 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
};
+static const struct drm_prop_enum_list drm_preferred_color_format_enum_list[]
= {
+ { 0, "auto" },
+ { DRM_COLOR_FORMAT_RGB444, "rgb" },
+ { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+ { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+ { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
{ 0, "not applicable" },
{ DRM_COLOR_FORMAT_RGB444, "rgb" },
@@ -1220,11 +1228,20 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* Drivers shall use drm_connector_attach_active_bpc_property() to install
* this property. A value of 0 means "not applicable".
*
+ * preferred color format:
+ * This property is used by userspace to change the used color format. When
+ * used the driver will use the selected format if valid for the hardware,
+ * sink, and current resolution and refresh rate combination. Drivers to
+ * use the function drm_connector_attach_preferred_color_format_property()
+ * to create and attach the property to the connector during
+ * initialization. Possible values are "auto", "rgb", "ycbcr444",
+ * "ycbcr422", and "ycbcr420".
+ *
* active color format:
* This read-only property tells userspace the color format actually used
* by the hardware display engine "on the cable" on a connector. The chosen
*
[Intel-gfx] [PATCH v5 13/17] drm/amd/display: Add handling for new "preferred color format" property
This commit implements the "preferred color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b4acedac1ac9..02a5809d4993 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5346,15 +5346,32 @@ static void
fill_stream_properties_from_drm_display_mode(
timing_out->h_border_right = 0;
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
- /* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- || (drm_mode_is_420_also(info, mode_in) &&
aconnector->force_yuv420_output))
+
+ if (connector_state
+ && (connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCRCB420
+ || aconnector->force_yuv420_output) &&
drm_mode_is_420(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if ((connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCRCB444)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+ else if (connector_state
+ && connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCRCB444
+ && connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCRCB444)
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
- else
+ else if (connector_state
+ && connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_RGB444
+ && !drm_mode_is_420_only(info, mode_in))
timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
+ else
+ /*
+* connector_state->preferred_color_format not possible
+* || connector_state->preferred_color_format == 0 (auto)
+* || connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCRCB422
+*/
+ if (drm_mode_is_420_only(info, mode_in))
+ timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
+ else if ((connector->display_info.color_formats &
DRM_COLOR_FORMAT_YCRCB444)
+ && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
+ timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
+ else
+ timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
timing_out->timing_3d_format = TIMING_3D_FORMAT_NONE;
timing_out->display_color_depth = convert_color_depth_from_display_info(
@@ -7756,6 +7773,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8,
16);
+
drm_connector_attach_preferred_color_format_property(>base);
drm_connector_attach_active_color_format_property(>base);
drm_connector_attach_active_color_range_property(>base);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index b5d57bbbdd20..2563788ba95a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8,
16);
+ connector->preferred_color_format_property =
master->base.preferred_color_format_property;
+ if (connector->preferred_color_format_property)
+
drm_connector_attach_preferred_color_format_property(>base);
+
connector->active_color_format_property =
master->base.active_color_format_property;
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(>base);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 04/17] drm/amd/display: Add handling for new "active bpc" property
This commit implements the "active bpc" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f4abb5f215d1..d984de82ae63 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7708,8 +7708,10 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
- if (!aconnector->mst_port)
+ if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+ drm_connector_attach_active_bpc_property(>base, 8,
16);
+ }
/* This defaults to the max in the range, but we want 8bpc for non-edp.
*/
aconnector->base.state->max_bpc = (connector_type ==
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -9078,6 +9080,26 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ struct dc_stream_state *stream;
+
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ stream = dm_new_crtc_state->stream;
+
+ if (stream)
+ drm_connector_set_active_bpc_property(connector,
+ stream->timing.flags.DSC ?
+
stream->timing.dsc_cfg.bits_per_pixel / 16 / 3 :
+ convert_dc_color_depth_into_bpc(
+
stream->timing.display_color_depth));
+ } else
+ drm_connector_set_active_bpc_property(connector, 0);
+ }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 5568d4e518e6..0cf38743ec47 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -409,6 +409,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 8, 16);
+ connector->active_bpc_property = master->base.active_bpc_property;
+ if (connector->active_bpc_property)
+ drm_connector_attach_active_bpc_property(>base, 8,
16);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 17/17] drm/amd/display: Add handling for new "Broadcast RGB" property
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 02a5809d4993..80d5a11fb0c5 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5247,7 +5247,8 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
}
static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+ enum drm_mode_color_range preferred_color_range)
{
enum dc_color_space color_space = COLOR_SPACE_SRGB;
@@ -5278,7 +5279,10 @@ get_output_color_space(const struct dc_crtc_timing
*dc_crtc_timing)
}
break;
case PIXEL_ENCODING_RGB:
- color_space = COLOR_SPACE_SRGB;
+ if (preferred_color_range ==
DRM_MODE_COLOR_RANGE_LIMITED_16_235)
+ color_space = COLOR_SPACE_SRGB_LIMITED;
+ else
+ color_space = COLOR_SPACE_SRGB;
break;
default:
@@ -5424,7 +5428,10 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
- stream->output_color_space = get_output_color_space(timing_out);
+ stream->output_color_space = get_output_color_space(timing_out,
+ connector_state ?
+
connector_state->preferred_color_range :
+
DRM_MODE_COLOR_RANGE_UNSET);
stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
@@ -7775,6 +7782,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
drm_connector_attach_active_bpc_property(>base, 8,
16);
drm_connector_attach_preferred_color_format_property(>base);
drm_connector_attach_active_color_format_property(>base);
+
drm_connector_attach_preferred_color_range_property(>base);
drm_connector_attach_active_color_range_property(>base);
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 2563788ba95a..80e1389fd0ec 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -421,6 +421,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(>base);
+ connector->preferred_color_range_property =
master->base.preferred_color_range_property;
+ if (connector->preferred_color_range_property)
+
drm_connector_attach_preferred_color_range_property(>base);
+
connector->active_color_range_property =
master->base.active_color_range_property;
if (connector->active_color_range_property)
drm_connector_attach_active_color_range_property(>base);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 14/17] drm/i915/display: Add handling for new "preferred color format" property
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
3 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fd33f753244d..29bb181ec4be 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -616,9 +616,12 @@ intel_dp_output_format(struct drm_connector *connector,
{
struct intel_dp *intel_dp =
intel_attached_dp(to_intel_connector(connector));
const struct drm_display_info *info = >display_info;
+ const struct drm_connector_state *connector_state = connector->state;
if (!connector->ycbcr_420_allowed ||
- !drm_mode_is_420_only(info, mode))
+ !(drm_mode_is_420_only(info, mode) ||
+ (drm_mode_is_420_also(info, mode) && connector_state &&
+ connector_state->preferred_color_format ==
DRM_COLOR_FORMAT_YCRCB420)))
return INTEL_OUTPUT_FORMAT_RGB;
if (intel_dp->dfp.rgb_to_ycbcr &&
@@ -4692,10 +4695,12 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+ drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+ drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index cb876175258f..67f0fb649876 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
+ connector->preferred_color_format_property =
+
intel_dp->attached_connector->base.preferred_color_format_property;
+ if (connector->preferred_color_format_property)
+ drm_connector_attach_preferred_color_format_property(connector);
+
connector->active_color_format_property =
intel_dp->attached_connector->base.active_color_format_property;
if (connector->active_color_format_property)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 3ee25e0cc3b9..a7b85cd13227 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2153,6 +2153,11 @@ static int intel_hdmi_compute_output_format(struct
intel_encoder *encoder,
crtc_state->output_format = INTEL_OUTPUT_FORMAT_RGB;
}
+ if (connector->ycbcr_420_allowed &&
+ conn_state->preferred_color_format == DRM_COLOR_FORMAT_YCRCB420 &&
+ drm_mode_is_420_also(>display_info, adjusted_mode))
+ crtc_state->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
+
ret = intel_hdmi_compute_clock(encoder, crtc_state);
if (ret) {
if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_YCBCR420 &&
@@ -2517,6 +2522,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+ drm_connector_attach_preferred_color_format_property(connector);
drm_connector_attach_active_color_format_property(connector);
}
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 08/17] drm/i915/display: Add handling for new "active color format" property
This commit implements the "active color format" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c| 1 +
4 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1b63d1404d06..be38f7148285 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10609,6 +10609,21 @@ static void
intel_atomic_prepare_plane_clear_colors(struct intel_atomic_state *s
}
}
+static int convert_intel_output_format_into_drm_color_format(enum
intel_output_format output_format)
+{
+ switch (output_format) {
+ case INTEL_OUTPUT_FORMAT_RGB:
+ return DRM_COLOR_FORMAT_RGB444;
+ case INTEL_OUTPUT_FORMAT_YCBCR420:
+ return DRM_COLOR_FORMAT_YCRCB420;
+ case INTEL_OUTPUT_FORMAT_YCBCR444:
+ return DRM_COLOR_FORMAT_YCRCB444;
+ default:
+ break;
+ }
+ return 0;
+}
+
static void intel_atomic_commit_tail(struct intel_atomic_state *state)
{
struct drm_device *dev = state->base.dev;
@@ -10922,8 +10937,13 @@ static int intel_atomic_commit(struct drm_device *dev,
new_crtc_state->dsc.compression_enable ?
new_crtc_state->dsc.compressed_bpp / 3 :
new_crtc_state->pipe_bpp / 3);
- } else
+
drm_connector_set_active_color_format_property(connector,
+
convert_intel_output_format_into_drm_color_format(
+ new_crtc_state->output_format));
+ } else {
drm_connector_set_active_bpc_property(connector, 0);
+
drm_connector_set_active_color_format_property(connector, 0);
+ }
}
drm_atomic_state_get(>base);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 815bc313b954..6b85bcdeb238 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4691,9 +4691,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
drm_connector_attach_active_bpc_property(connector, 6, 10);
+ drm_connector_attach_active_color_format_property(connector);
} else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
drm_connector_attach_active_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_color_format_property(connector);
}
/* Register HDMI colorspace for case of lspcon */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 16bfc59570a5..3e4237df3360 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -856,6 +856,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(connector, 6, 12);
+ connector->active_color_format_property =
+ intel_dp->attached_connector->base.active_color_format_property;
+ if (connector->active_color_format_property)
+ drm_connector_attach_active_color_format_property(connector);
+
return connector;
err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 9160e21ac9d6..367aba57b55f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2516,6 +2516,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
drm_connector_attach_active_bpc_property(connector, 8, 12);
+ drm_connector_attach_active_color_format_property(connector);
}
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 10/17] drm/amd/display: Add handling for new "active color range" property
This commit implements the "active color range" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 098f3d53e681..b4acedac1ac9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6728,6 +6728,33 @@ static int
convert_dc_pixel_encoding_into_drm_color_format(
return 0;
}
+static int convert_dc_color_space_into_drm_mode_color_range(enum
dc_color_space color_space)
+{
+ if (color_space == COLOR_SPACE_SRGB ||
+ color_space == COLOR_SPACE_XR_RGB ||
+ color_space == COLOR_SPACE_MSREF_SCRGB ||
+ color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
+ color_space == COLOR_SPACE_ADOBERGB ||
+ color_space == COLOR_SPACE_DCIP3 ||
+ color_space == COLOR_SPACE_DOLBYVISION ||
+ color_space == COLOR_SPACE_YCBCR601 ||
+ color_space == COLOR_SPACE_XV_YCC_601 ||
+ color_space == COLOR_SPACE_YCBCR709 ||
+ color_space == COLOR_SPACE_XV_YCC_709 ||
+ color_space == COLOR_SPACE_2020_YCBCR ||
+ color_space == COLOR_SPACE_YCBCR709_BLACK ||
+ color_space == COLOR_SPACE_DISPLAYNATIVE ||
+ color_space == COLOR_SPACE_APPCTRL ||
+ color_space == COLOR_SPACE_CUSTOMPOINTS)
+ return DRM_MODE_COLOR_RANGE_FULL;
+ if (color_space == COLOR_SPACE_SRGB_LIMITED ||
+ color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
+ color_space == COLOR_SPACE_YCBCR601_LIMITED ||
+ color_space == COLOR_SPACE_YCBCR709_LIMITED)
+ return DRM_MODE_COLOR_RANGE_LIMITED_16_235;
+ return DRM_MODE_COLOR_RANGE_UNSET;
+}
+
static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state
*conn_state)
@@ -7730,6 +7757,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8,
16);
drm_connector_attach_active_color_format_property(>base);
+
drm_connector_attach_active_color_range_property(>base);
}
/* This defaults to the max in the range, but we want 8bpc for non-edp.
*/
@@ -9118,10 +9146,15 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
drm_connector_set_active_color_format_property(connector,
convert_dc_pixel_encoding_into_drm_color_format(
dm_new_crtc_state->stream->timing.pixel_encoding));
+
drm_connector_set_active_color_range_property(connector,
+
convert_dc_color_space_into_drm_mode_color_range(
+
dm_new_crtc_state->stream->output_color_space));
}
} else {
drm_connector_set_active_bpc_property(connector, 0);
drm_connector_set_active_color_format_property(connector, 0);
+ drm_connector_set_active_color_range_property(connector,
+
DRM_MODE_COLOR_RANGE_UNSET);
}
}
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 13151d13aa73..b5d57bbbdd20 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -417,6 +417,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->active_color_format_property)
drm_connector_attach_active_color_format_property(>base);
+ connector->active_color_range_property =
master->base.active_color_range_property;
+ if (connector->active_color_range_property)
+
drm_connector_attach_active_color_range_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 09/17] drm/uAPI: Add "active color range" drm property as feedback for userspace
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor and what the default behaviour of the used driver is. This
property helps eliminating the guessing at this point.
In the future, automatic color calibration for screens might also depend on
this information being available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_connector.c | 61 +
include/drm/drm_connector.h | 27 +++
2 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 075bdc08d5c3..ebfdd17a7f59 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -897,6 +897,12 @@ static const struct drm_prop_enum_list
drm_active_color_format_enum_list[] = {
{ DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
};
+static const struct drm_prop_enum_list drm_active_color_range_enum_list[] = {
+ { DRM_MODE_COLOR_RANGE_UNSET, "Not Applicable" },
+ { DRM_MODE_COLOR_RANGE_FULL, "Full" },
+ { DRM_MODE_COLOR_RANGE_LIMITED_16_235, "Limited 16:235" },
+};
+
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
drm_dp_subconnector_enum_list)
@@ -1223,6 +1229,15 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* property. Possible values are "not applicable", "rgb", "ycbcr444",
* "ycbcr422", and "ycbcr420".
*
+ * active color range:
+ * This read-only property tells userspace the color range actually used by
+ * the hardware display engine "on the cable" on a connector. The chosen
+ * value depends on hardware capabilities of the monitor and the used color
+ * format. Drivers shall use
+ * drm_connector_attach_active_color_range_property() to install this
+ * property. Possible values are "Not Applicable", "Full", and "Limited
+ * 16:235".
+ *
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -2268,6 +2283,52 @@ void
drm_connector_set_active_color_format_property(struct drm_connector *connec
}
EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+/**
+ * drm_connector_attach_active_color_range_property - attach "active color
range" property
+ * @connector: connector to attach active color range property on.
+ *
+ * This is used to check the applied color range on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_range_property(struct drm_connector
*connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ if (!connector->active_color_range_property) {
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"active color range",
+
drm_active_color_range_enum_list,
+
ARRAY_SIZE(drm_active_color_range_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ connector->active_color_range_property = prop;
+ }
+
+ drm_object_attach_property(>base, prop,
DRM_MODE_COLOR_RANGE_UNSET);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_range_property);
+
+/**
+ * drm_connector_set_active_color_range_property - sets the active color range
property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_range: color range for the connector currently active "on the
cable"
+ *
+ * Should be used by atomic drivers to update the active color range over a
connector.
+ */
+void drm_connector_set_active_color_range_property(struct drm_connector
*connector,
+ enum drm_mode_color_range
active_color_range)
+{
+ drm_object_property_set_value(>base,
connector->active_color_range_property,
+ active_color_range);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_range_property);
+
/**
* drm_connector_attach_hdr_output_metadata_property - attach
"HDR_OUTPUT_METADA" property
* @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8a5197f14e87..5ef4bb270f71 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -648,6 +648,24 @@ struct drm_tv_connector_state {
unsigned int hue;
};
+/**
+ * enum drm_mode_color_range - color_range info for _connector
+ *
+ * This enum is used to represent full or limited color range on the display
+ * connector signal.
+ *
+ * @DRM_MODE_COLOR_RANGE_UNSET: Color range is
unspecified/default.
+ * @DRM_MODE_COLOR_RANGE_FULL: Color range is full range, 0-255 for
+ *
[Intel-gfx] [PATCH v5 06/17] drm/uAPI: Add "active color format" drm property as feedback for userspace
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor, the GPU, and the connection used and what the default
behaviour of the used driver is (e.g. amdgpu prefers YCbCr 4:4:4 while i915
prefers RGB). This property helps eliminating the guessing on this point.
In the future, automatic color calibration for screens might also depend on
this information being available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_connector.c | 63 +
include/drm/drm_connector.h | 9 +
2 files changed, 72 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 6461d00e8e49..075bdc08d5c3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -889,6 +889,14 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
};
+static const struct drm_prop_enum_list drm_active_color_format_enum_list[] = {
+ { 0, "not applicable" },
+ { DRM_COLOR_FORMAT_RGB444, "rgb" },
+ { DRM_COLOR_FORMAT_YCRCB444, "ycbcr444" },
+ { DRM_COLOR_FORMAT_YCRCB422, "ycbcr422" },
+ { DRM_COLOR_FORMAT_YCRCB420, "ycbcr420" },
+};
+
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
drm_dp_subconnector_enum_list)
@@ -1206,6 +1214,15 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* Drivers shall use drm_connector_attach_active_bpc_property() to install
* this property. A value of 0 means "not applicable".
*
+ * active color format:
+ * This read-only property tells userspace the color format actually used
+ * by the hardware display engine "on the cable" on a connector. The chosen
+ * value depends on hardware capabilities, both display engine and
+ * connected monitor. Drivers shall use
+ * drm_connector_attach_active_color_format_property() to install this
+ * property. Possible values are "not applicable", "rgb", "ycbcr444",
+ * "ycbcr422", and "ycbcr420".
+ *
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -2205,6 +,52 @@ void drm_connector_set_active_bpc_property(struct
drm_connector *connector, int
}
EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+/**
+ * drm_connector_attach_active_color_format_property - attach "active color
format" property
+ * @connector: connector to attach active color format property on.
+ *
+ * This is used to check the applied color format on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_color_format_property(struct drm_connector
*connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ if (!connector->active_color_format_property) {
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_IMMUTABLE,
"active color format",
+
drm_active_color_format_enum_list,
+
ARRAY_SIZE(drm_active_color_format_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ connector->active_color_format_property = prop;
+ }
+
+ drm_object_attach_property(>base, prop, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_color_format_property);
+
+/**
+ * drm_connector_set_active_color_format_property - sets the active color
format property for a
+ * connector
+ * @connector: drm connector
+ * @active_color_format: color format for the connector currently active "on
the cable"
+ *
+ * Should be used by atomic drivers to update the active color format over a
connector.
+ */
+void drm_connector_set_active_color_format_property(struct drm_connector
*connector,
+ u32 active_color_format)
+{
+ drm_object_property_set_value(>base,
connector->active_color_format_property,
+ active_color_format);
+}
+EXPORT_SYMBOL(drm_connector_set_active_color_format_property);
+
/**
* drm_connector_attach_hdr_output_metadata_property - attach
"HDR_OUTPUT_METADA" property
* @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index eee86de62a5f..8a5197f14e87 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1386,6 +1386,12 @@ struct drm_connector {
*/
struct drm_property *active_bpc_property;
+ /**
+* @active_color_format_property: Default connector property for the
+* active color format to be driven out of the connector.
+*/
+
[Intel-gfx] [PATCH v5 05/17] drm/i915/display: Add handling for new "active bpc" property
This commit implements the "active bpc" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
drivers/gpu/drm/i915/display/intel_dp.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c| 4 +++-
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6be1b31af07b..1b63d1404d06 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10839,6 +10839,9 @@ static int intel_atomic_commit(struct drm_device *dev,
{
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
+ int i;
int ret = 0;
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
@@ -10907,6 +10910,22 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(>base, connector,
new_conn_state, i) {
+ struct intel_crtc *crtc = to_intel_crtc(new_conn_state->crtc);
+
+ if (crtc) {
+ struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+
+ drm_connector_set_active_bpc_property(connector,
+ new_crtc_state->dsc.compression_enable ?
+ new_crtc_state->dsc.compressed_bpp / 3 :
+ new_crtc_state->pipe_bpp / 3);
+ } else
+ drm_connector_set_active_bpc_property(connector, 0);
+ }
+
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 6cc03b9e4321..815bc313b954 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4688,10 +4688,13 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
- if (HAS_GMCH(dev_priv))
+ if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
- else if (DISPLAY_VER(dev_priv) >= 5)
+ drm_connector_attach_active_bpc_property(connector, 6, 10);
+ } else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_bpc_property(connector, 6, 12);
+ }
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index b170e272bdee..16bfc59570a5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -851,6 +851,11 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (connector->max_bpc_property)
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ connector->active_bpc_property =
+ intel_dp->attached_connector->base.active_bpc_property;
+ if (connector->active_bpc_property)
+ drm_connector_attach_active_bpc_property(connector, 6, 12);
+
return connector;
err:
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 7e51c98c475e..9160e21ac9d6 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2513,8 +2513,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
if (DISPLAY_VER(dev_priv) >= 10)
drm_connector_attach_hdr_output_metadata_property(connector);
- if (!HAS_GMCH(dev_priv))
+ if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+ drm_connector_attach_active_bpc_property(connector, 8, 12);
+ }
}
/*
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel color back to userspace.
While "max bpc" can be used to change the color depth, there was no way to
check which one actually got used. While in theory the driver chooses the
best/highest color depth within the max bpc setting a user might not be
fully aware what his hardware is or isn't capable off. This is meant as a
quick way to double check the setup.
In the future, automatic color calibration for screens might also depend on
this information being available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_connector.c | 53 +
include/drm/drm_connector.h | 8 +
2 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..6461d00e8e49 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1197,6 +1197,15 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* drm_connector_attach_max_bpc_property() to create and attach the
* property to the connector during initialization.
*
+ * active bpc:
+ * This read-only range property tells userspace the pixel color bit depth
+ * actually used by the hardware display engine "on the cable" on a
+ * connector. This means after display stream compression and dithering
+ * done by the GPU. The chosen value depends on hardware capabilities, both
+ * display engine and connected monitor, and the "max bpc" property.
+ * Drivers shall use drm_connector_attach_active_bpc_property() to install
+ * this property. A value of 0 means "not applicable".
+ *
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -2152,6 +2161,50 @@ int drm_connector_attach_max_bpc_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
+/**
+ * drm_connector_attach_active_bpc_property - attach "active bpc" property
+ * @connector: connector to attach active bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to check the applied bit depth on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
int min, int max)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ if (!connector->active_bpc_property) {
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
"active bpc",
+min, max);
+ if (!prop)
+ return -ENOMEM;
+
+ connector->active_bpc_property = prop;
+ }
+
+ drm_object_attach_property(>base, prop, 0);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
+/**
+ * drm_connector_set_active_bpc_property - sets the active bits per color
property for a connector
+ * @connector: drm connector
+ * @active_bpc: bits per color for the connector currently active "on the
cable"
+ *
+ * Should be used by atomic drivers to update the active bits per color over a
connector.
+ */
+void drm_connector_set_active_bpc_property(struct drm_connector *connector,
int active_bpc)
+{
+ drm_object_property_set_value(>base,
connector->active_bpc_property, active_bpc);
+}
+EXPORT_SYMBOL(drm_connector_set_active_bpc_property);
+
/**
* drm_connector_attach_hdr_output_metadata_property - attach
"HDR_OUTPUT_METADA" property
* @connector: connector to attach the property on.
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..eee86de62a5f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1380,6 +1380,12 @@ struct drm_connector {
*/
struct drm_property *max_bpc_property;
+ /**
+* @active_bpc_property: Default connector property for the active bpc
+* to be driven out of the connector.
+*/
+ struct drm_property *active_bpc_property;
+
#define DRM_CONNECTOR_POLL_HPD (1 << 0)
#define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
#define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1702,6 +1708,8 @@ int drm_connector_set_panel_orientation_with_quirk(
int width, int height);
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
int min, int max);
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
int min, int max);
+void drm_connector_set_active_bpc_property(struct drm_connector *connector,
int active_bpc);
/**
* struct drm_tile_group - Tile group metadata
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH v5 01/17] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() && force_yuv420_output case. Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI, there is no reason to use RGB when the display reports drm_mode_is_420_only() even on a non HDMI connection. This patch also moves both checks in the same if-case. This eliminates an extra else-if-case. Signed-off-by: Werner Sembach --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 10f878910e55..e081dd3ffb5f 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -5348,10 +5348,7 @@ static void fill_stream_properties_from_drm_display_mode( timing_out->v_border_bottom = 0; /* TODO: un-hardcode */ if (drm_mode_is_420_only(info, mode_in) - && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) - timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; - else if (drm_mode_is_420_also(info, mode_in) - && aconnector->force_yuv420_output) + || (drm_mode_is_420_also(info, mode_in) && aconnector->force_yuv420_output)) timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420; else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCRCB444) && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 07/17] drm/amd/display: Add handling for new "active color format" property
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d984de82ae63..098f3d53e681 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6710,6 +6710,24 @@ static int convert_dc_color_depth_into_bpc (enum
dc_color_depth display_color_de
return 0;
}
+static int convert_dc_pixel_encoding_into_drm_color_format(
+ enum dc_pixel_encoding display_pixel_encoding)
+{
+ switch (display_pixel_encoding) {
+ case PIXEL_ENCODING_RGB:
+ return DRM_COLOR_FORMAT_RGB444;
+ case PIXEL_ENCODING_YCBCR422:
+ return DRM_COLOR_FORMAT_YCRCB422;
+ case PIXEL_ENCODING_YCBCR444:
+ return DRM_COLOR_FORMAT_YCRCB444;
+ case PIXEL_ENCODING_YCBCR420:
+ return DRM_COLOR_FORMAT_YCRCB420;
+ default:
+ break;
+ }
+ return 0;
+}
+
static int dm_encoder_helper_atomic_check(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state
*conn_state)
@@ -7711,6 +7729,7 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
drm_connector_attach_active_bpc_property(>base, 8,
16);
+
drm_connector_attach_active_color_format_property(>base);
}
/* This defaults to the max in the range, but we want 8bpc for non-edp.
*/
@@ -9090,14 +9109,20 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
stream = dm_new_crtc_state->stream;
- if (stream)
+ if (stream) {
drm_connector_set_active_bpc_property(connector,
stream->timing.flags.DSC ?
stream->timing.dsc_cfg.bits_per_pixel / 16 / 3 :
convert_dc_color_depth_into_bpc(
stream->timing.display_color_depth));
- } else
+
drm_connector_set_active_color_format_property(connector,
+
convert_dc_pixel_encoding_into_drm_color_format(
+
dm_new_crtc_state->stream->timing.pixel_encoding));
+ }
+ } else {
drm_connector_set_active_bpc_property(connector, 0);
+
drm_connector_set_active_color_format_property(connector, 0);
+ }
}
/* Count number of newly disabled CRTCs for dropping PM refs later. */
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 0cf38743ec47..13151d13aa73 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -413,6 +413,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
if (connector->active_bpc_property)
drm_connector_attach_active_bpc_property(>base, 8,
16);
+ connector->active_color_format_property =
master->base.active_color_format_property;
+ if (connector->active_color_format_property)
+
drm_connector_attach_active_color_format_property(>base);
+
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
drm_connector_attach_vrr_capable_property(connector);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 00/17] New uAPI drm properties for color management
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete albeit not fully tested. I have now corrected the DSC behavior, but still no wait to test it. Exact dithering behavior remains a mistery so in case dithering is active it's not 100% clear what "active bpc" means, or where the "max bpc" limit is applied. I have no DP MST splitter at hand. I tried my best to not break anything, but if one who has one could test it would be very helpful. Things on my TODO list: - add "min bpc" property - rewrite "preferred color format" to "force color format" - make "Broadcast RGB" only affect RGB on AMD too - remove unreachable enums of "active/preferred/force color format" ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 02/17] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing. Signed-off-by: Werner Sembach --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index e081dd3ffb5f..f4abb5f215d1 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6700,6 +6700,10 @@ static int convert_dc_color_depth_into_bpc (enum dc_color_depth display_color_de return 14; case COLOR_DEPTH_161616: return 16; + case COLOR_DEPTH_999: + return 9; + case COLOR_DEPTH_11: + return 11; default: break; } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 1/4] drm: avoid circular locks in drm_mode_getconnector
In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by >mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to avoid this lock dependency produces the following lockdep
splat:
==
WARNING: possible circular locking dependency detected
5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted
--
kms_frontbuffer/1087 is trying to acquire lock:
88810dcd01a8 (>master_mutex){+.+.}-{3:3}, at:
drm_is_current_master+0x1b/0x40
but task is already holding lock:
88810dcd0488 (>mode_config.mutex){+.+.}-{3:3}, at:
drm_mode_getconnector+0x1c6/0x4a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>mode_config.mutex){+.+.}-{3:3}:
__mutex_lock+0xab/0x970
drm_client_modeset_probe+0x22e/0xca0
__drm_fb_helper_initial_config_and_unlock+0x42/0x540
intel_fbdev_initial_config+0xf/0x20 [i915]
async_run_entry_fn+0x28/0x130
process_one_work+0x26d/0x5c0
worker_thread+0x37/0x380
kthread+0x144/0x170
ret_from_fork+0x1f/0x30
-> #1 (>modeset_mutex){+.+.}-{3:3}:
__mutex_lock+0xab/0x970
drm_client_modeset_commit_locked+0x1c/0x180
drm_client_modeset_commit+0x1c/0x40
__drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
drm_fb_helper_set_par+0x34/0x40
intel_fbdev_set_par+0x11/0x40 [i915]
fbcon_init+0x270/0x4f0
visual_init+0xc6/0x130
do_bind_con_driver+0x1e5/0x2d0
do_take_over_console+0x10e/0x180
do_fbcon_takeover+0x53/0xb0
register_framebuffer+0x22d/0x310
__drm_fb_helper_initial_config_and_unlock+0x36c/0x540
intel_fbdev_initial_config+0xf/0x20 [i915]
async_run_entry_fn+0x28/0x130
process_one_work+0x26d/0x5c0
worker_thread+0x37/0x380
kthread+0x144/0x170
ret_from_fork+0x1f/0x30
-> #0 (>master_mutex){+.+.}-{3:3}:
__lock_acquire+0x151e/0x2590
lock_acquire+0xd1/0x3d0
__mutex_lock+0xab/0x970
drm_is_current_master+0x1b/0x40
drm_mode_getconnector+0x37e/0x4a0
drm_ioctl_kernel+0xa8/0xf0
drm_ioctl+0x1e8/0x390
__x64_sys_ioctl+0x6a/0xa0
do_syscall_64+0x39/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Chain exists of: >master_mutex --> >modeset_mutex -->
>mode_config.mutex
Possible unsafe locking scenario:
CPU0CPU1
lock(>mode_config.mutex);
lock(>modeset_mutex);
lock(>mode_config.mutex);
lock(>master_mutex);
*** DEADLOCK ***
1 lock held by kms_frontbuffer/1087:
#0: 88810dcd0488 (>mode_config.mutex){+.+.}-{3:3}, at:
drm_mode_getconnector+0x1c6/0x4a0
stack backtrace:
CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+
#1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM
PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
Call Trace:
dump_stack+0x7f/0xad
check_noncircular+0x12e/0x150
__lock_acquire+0x151e/0x2590
lock_acquire+0xd1/0x3d0
__mutex_lock+0xab/0x970
drm_is_current_master+0x1b/0x40
drm_mode_getconnector+0x37e/0x4a0
drm_ioctl_kernel+0xa8/0xf0
drm_ioctl+0x1e8/0x390
__x64_sys_ioctl+0x6a/0xa0
do_syscall_64+0x39/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/drm_connector.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..2ba257b1ae20 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2414,6 +2414,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
+ bool is_current_master;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -2444,9 +2445,11 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp->connector_type = connector->connector_type;
out_resp->connector_type_id = connector->connector_type_id;
+ is_current_master = drm_is_current_master(file_priv);
+
mutex_lock(>mode_config.mutex);
if (out_resp->count_modes == 0) {
- if (drm_is_current_master(file_priv))
+ if (is_current_master)
connector->funcs->fill_modes(connector,
dev->mode_config.max_width,
[Intel-gfx] [PATCH v6 0/4] drm: address potential UAF bugs with drm_master ptrs
This patch series addresses potential use-after-free errors when dereferencing pointers to struct drm_master. These were identified after one such bug was caught by Syzbot in drm_getunique(): https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 The series is broken up into four patches: 1. Move a call to drm_is_current_master() out from a section locked by >mode_config.mutex in drm_mode_getconnector(). This patch does not apply to stable. 2. Move a call to _drm_lease_held() out from the section locked by >mode_config.idr_mutex in __drm_mode_object_find(). 3. Implement a locked version of drm_is_current_master() function that's used within drm_auth.c. 4. Identify areas in drm_lease.c where pointers to struct drm_master are dereferenced, and ensure that the master pointers are not freed during use. Changes in v5 -> v6: - Patch 2: Add patch 2 to the series. This patch moves the call to _drm_lease_held out from the section locked by >mode_config.idr_mutex in __drm_mode_object_find. - Patch 4: Clarify the kerneldoc for dereferencing drm_file.master, as suggested by Daniel Vetter. Refactor error paths with goto labels so that each function only has a single drm_master_put(), as suggested by Emil Velikov. Modify comparison to NULL into "!master", as suggested by the intel-gfx CI. Changes in v4 -> v5: - Patch 1: Add patch 1 to the series. The changes in patch 1 do not apply to stable because they apply to new changes in the drm-misc-next branch. This patch moves the call to drm_is_current_master in drm_mode_getconnector out from the section locked by >mode_config.mutex. Additionally, added a missing semicolon to the patch, caught by the intel-gfx CI. - Patch 3: Move changes to drm_connector.c into patch 1. Changes in v3 -> v4: - Patch 3: Move the call to drm_is_current_master in drm_mode_getconnector out from the section locked by >mode_config.mutex. As suggested by Daniel Vetter. This avoids a circular lock lock dependency as reported here https://patchwork.freedesktop.org/patch/440406/ Additionally, inside drm_is_current_master, instead of grabbing >master->dev->master_mutex, we grab >minor->dev->master_mutex to avoid dereferencing a null ptr if fpriv->master is not set. - Patch 4: Modify kerneldoc formatting. Additionally, add a file_priv->master NULL check inside drm_file_get_master, and handle the NULL result accordingly in drm_lease.c. As suggested by Daniel Vetter. Changes in v2 -> v3: - Patch 3: Move the definition of drm_is_current_master and the _locked version higher up in drm_auth.c to avoid needing a forward declaration of drm_is_current_master_locked. As suggested by Daniel Vetter. - Patch 4: Instead of leaking drm_device.master_mutex into drm_lease.c to protect drm_master pointers, add a new drm_file_get_master() function that returns drm_file->master while increasing its reference count, to prevent drm_file->master from being freed. As suggested by Daniel Vetter. Changes in v1 -> v2: - Patch 4: Move the lock and assignment before the DRM_DEBUG_LEASE in drm_mode_get_lease_ioctl, as suggested by Emil Velikov. Desmond Cheong Zhi Xi (4): drm: avoid circular locks in drm_mode_getconnector drm: avoid circular locks in __drm_mode_object_find drm: add a locked version of drm_is_current_master drm: protect drm_master pointers in drm_lease.c drivers/gpu/drm/drm_auth.c| 76 + drivers/gpu/drm/drm_connector.c | 5 +- drivers/gpu/drm/drm_lease.c | 81 +++ drivers/gpu/drm/drm_mode_object.c | 10 ++-- include/drm/drm_auth.h| 1 + include/drm/drm_file.h| 15 -- 6 files changed, 141 insertions(+), 47 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 3/4] drm: add a locked version of drm_is_current_master
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer is subsequently
dereferenced in drm_lease_owner().
The callers of drm_is_current_master() from drm_auth.c hold the
device's master mutex, but external callers do not. Hence, we implement
drm_is_current_master_locked() to be used within drm_auth.c, and
modify drm_is_current_master() to grab the device's master mutex
before checking the master status.
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/drm_auth.c | 51 --
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index f00e5abdbbf4..ab1863c5a5a0 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -61,6 +61,35 @@
* trusted clients.
*/
+static bool drm_is_current_master_locked(struct drm_file *fpriv)
+{
+ lockdep_assert_held_once(>minor->dev->master_mutex);
+
+ return fpriv->is_master && drm_lease_owner(fpriv->master) ==
fpriv->minor->dev->master;
+}
+
+/**
+ * drm_is_current_master - checks whether @priv is the current master
+ * @fpriv: DRM file private
+ *
+ * Checks whether @fpriv is current master on its device. This decides whether
a
+ * client is allowed to run DRM_MASTER IOCTLs.
+ *
+ * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
+ * - the current master is assumed to own the non-shareable display hardware.
+ */
+bool drm_is_current_master(struct drm_file *fpriv)
+{
+ bool ret;
+
+ mutex_lock(>minor->dev->master_mutex);
+ ret = drm_is_current_master_locked(fpriv);
+ mutex_unlock(>minor->dev->master_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_is_current_master);
+
int drm_getmagic(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
struct drm_auth *auth = data;
@@ -223,7 +252,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
if (ret)
goto out_unlock;
- if (drm_is_current_master(file_priv))
+ if (drm_is_current_master_locked(file_priv))
goto out_unlock;
if (dev->master) {
@@ -272,7 +301,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
if (ret)
goto out_unlock;
- if (!drm_is_current_master(file_priv)) {
+ if (!drm_is_current_master_locked(file_priv)) {
ret = -EINVAL;
goto out_unlock;
}
@@ -321,7 +350,7 @@ void drm_master_release(struct drm_file *file_priv)
if (file_priv->magic)
idr_remove(_priv->master->magic_map, file_priv->magic);
- if (!drm_is_current_master(file_priv))
+ if (!drm_is_current_master_locked(file_priv))
goto out;
drm_legacy_lock_master_cleanup(dev, master);
@@ -342,22 +371,6 @@ void drm_master_release(struct drm_file *file_priv)
mutex_unlock(>master_mutex);
}
-/**
- * drm_is_current_master - checks whether @priv is the current master
- * @fpriv: DRM file private
- *
- * Checks whether @fpriv is current master on its device. This decides whether
a
- * client is allowed to run DRM_MASTER IOCTLs.
- *
- * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
- * - the current master is assumed to own the non-shareable display hardware.
- */
-bool drm_is_current_master(struct drm_file *fpriv)
-{
- return fpriv->is_master && drm_lease_owner(fpriv->master) ==
fpriv->minor->dev->master;
-}
-EXPORT_SYMBOL(drm_is_current_master);
-
/**
* drm_master_get - reference a master pointer
* @master: drm_master
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 4/4] drm: protect drm_master pointers in drm_lease.c
Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to drm_setmaster_ioctl will
invoke drm_new_set_master, which then allocates a new master for
drm_file and puts the old master.
Thus, without holding drm_device.master_mutex, the old value of
drm_file->master could be freed while it is being used by another
concurrent process.
In drm_lease.c, there are multiple instances where drm_file->master is
accessed and dereferenced while drm_device.master_mutex is not
held. This makes drm_lease.c vulnerable to use-after-free bugs.
We address this issue in 3 ways:
1. Clarify in the kerneldoc that drm_file->master is protected by
drm_device.master_mutex.
2. Add a new drm_file_get_master() function that calls drm_master_get
on drm_file->master while holding on to drm_device.master_mutex. Since
drm_master_get increments the reference count of master, this
prevents master from being freed until we unreference it with
drm_master_put.
3. In each case where drm_file->master is directly accessed and
eventually dereferenced in drm_lease.c, we wrap the access in a call
to the new drm_file_get_master function, then unreference the master
pointer once we are done using it.
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/drm_auth.c | 25
drivers/gpu/drm/drm_lease.c | 81 -
include/drm/drm_auth.h | 1 +
include/drm/drm_file.h | 15 +--
4 files changed, 99 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index ab1863c5a5a0..c36a0b72be26 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -384,6 +384,31 @@ struct drm_master *drm_master_get(struct drm_master
*master)
}
EXPORT_SYMBOL(drm_master_get);
+/**
+ * drm_file_get_master - reference _file.master of @file_priv
+ * @file_priv: DRM file private
+ *
+ * Increments the reference count of @file_priv's _file.master and returns
+ * the _file.master. If @file_priv has no _file.master, returns NULL.
+ *
+ * Master pointers returned from this function should be unreferenced using
+ * drm_master_put().
+ */
+struct drm_master *drm_file_get_master(struct drm_file *file_priv)
+{
+ struct drm_master *master = NULL;
+
+ mutex_lock(_priv->minor->dev->master_mutex);
+ if (!file_priv->master)
+ goto unlock;
+ master = drm_master_get(file_priv->master);
+
+unlock:
+ mutex_unlock(_priv->minor->dev->master_mutex);
+ return master;
+}
+EXPORT_SYMBOL(drm_file_get_master);
+
static void drm_master_destroy(struct kref *kref)
{
struct drm_master *master = container_of(kref, struct drm_master,
refcount);
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 00fb433bcef1..92eac73d9001 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -106,10 +106,19 @@ static bool _drm_has_leased(struct drm_master *master,
int id)
*/
bool _drm_lease_held(struct drm_file *file_priv, int id)
{
- if (!file_priv || !file_priv->master)
+ bool ret;
+ struct drm_master *master;
+
+ if (!file_priv)
return true;
- return _drm_lease_held_master(file_priv->master, id);
+ master = drm_file_get_master(file_priv);
+ if (!master)
+ return true;
+ ret = _drm_lease_held_master(master, id);
+ drm_master_put();
+
+ return ret;
}
/**
@@ -128,13 +137,22 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return true;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (!master)
+ return true;
+ if (!master->lessor) {
+ ret = true;
+ goto out;
+ }
mutex_lock(>dev->mode_config.idr_mutex);
ret = _drm_lease_held_master(master, id);
mutex_unlock(>dev->mode_config.idr_mutex);
+
+out:
+ drm_master_put();
return ret;
}
@@ -154,10 +172,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file
*file_priv, uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return crtcs_in;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (!master)
+ return crtcs_in;
+ if (!master->lessor) {
+ crtcs_out = crtcs_in;
+ goto out;
+ }
dev =
[Intel-gfx] [PATCH v6 2/4] drm: avoid circular locks in __drm_mode_object_find
In a future patch, _drm_lease_held will dereference drm_file->master
only after making a call to drm_file_get_master which increments the
reference count of drm_file->master while holding a lock on
drm_device.master_mutex.
In preparation for this, the call to _drm_lease_held should be moved
out from the section locked by >mode_config.idr_mutex. This
avoids inverting the lock hierarchy for
>master_mutex --> >mode_config.idr_mutex
Signed-off-by: Desmond Cheong Zhi Xi
---
drivers/gpu/drm/drm_mode_object.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index b26588b52795..63d35f1f98dd 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -146,16 +146,18 @@ struct drm_mode_object *__drm_mode_object_find(struct
drm_device *dev,
if (obj && obj->id != id)
obj = NULL;
- if (obj && drm_mode_object_lease_required(obj->type) &&
- !_drm_lease_held(file_priv, obj->id))
- obj = NULL;
-
if (obj && obj->free_cb) {
if (!kref_get_unless_zero(>refcount))
obj = NULL;
}
mutex_unlock(>mode_config.idr_mutex);
+ if (obj && drm_mode_object_lease_required(obj->type) &&
+ !_drm_lease_held(file_priv, obj->id)) {
+ drm_mode_object_put(obj);
+ obj = NULL;
+ }
+
return obj;
}
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/ttm, drm/i915: Update ttm_move_memcpy for async use
On Thu, 24 Jun 2021 at 20:31, Thomas Hellström wrote: > > The buffer object argument to ttm_move_memcpy was only used to > determine whether the destination memory should be cleared only > or whether we should copy data. Replace it with a "clear" bool, and > update the callers. > > The intention here is to be able to use ttm_move_memcpy() async under > a dma-fence as a fallback if an accelerated blit fails in a security- > critical path where data might leak if the blit is not properly > performed. For that purpose the bo is an unsuitable argument since > its relevant members might already have changed at call time. > > Finally, update the ttm_move_memcpy kerneldoc that seems to have > ended up with a stale version. > > Signed-off-by: Thomas Hellström Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ttm: Reorganize the ttm move code somewhat
On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
wrote:
>
> In order to make the code a bit more readable and to facilitate
> async memcpy moves, reorganize the move code a little. Determine
> at an early stage whether to copy or to clear.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 70 ++---
> 1 file changed, 40 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index c39d982c4fa6..4e529adcdfc7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -431,6 +431,7 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
> }
>
> static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
> + bool clear,
>struct ttm_resource *dst_mem,
>struct sg_table *dst_st)
> {
> @@ -449,13 +450,10 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
> *bo,
> return -EINVAL;
>
> dst_level = i915_ttm_cache_level(i915, dst_mem, ttm);
> - if (!ttm || !ttm_tt_is_populated(ttm)) {
> + if (clear) {
> if (bo->type == ttm_bo_type_kernel)
> return -EINVAL;
Was that meant to be:
return 0:
?
Also does that mean we are incorrectly falling back to memset, for
non-userspace objects, instead of making it a noop?
>
> - if (ttm && !(ttm->page_flags & TTM_PAGE_FLAG_ZERO_ALLOC))
> - return 0;
> -
> intel_engine_pm_get(i915->gt.migrate.context->engine);
> ret = intel_context_migrate_clear(i915->gt.migrate.context,
> NULL,
> dst_st->sgl, dst_level,
> @@ -489,27 +487,53 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
> *bo,
> return ret;
> }
>
> -static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
> -struct ttm_operation_ctx *ctx,
> -struct ttm_resource *dst_mem,
> -struct ttm_place *hop)
> +static void __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
> + struct ttm_resource *dst_mem,
> + struct sg_table *dst_st)
> {
> struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> - struct ttm_resource_manager *dst_man =
> - ttm_manager_type(bo->bdev, dst_mem->mem_type);
> struct intel_memory_region *dst_reg, *src_reg;
> union {
> struct ttm_kmap_iter_tt tt;
> struct ttm_kmap_iter_iomap io;
> } _dst_iter, _src_iter;
> struct ttm_kmap_iter *dst_iter, *src_iter;
> - struct sg_table *dst_st;
> int ret;
>
> dst_reg = i915_ttm_region(bo->bdev, dst_mem->mem_type);
> src_reg = i915_ttm_region(bo->bdev, bo->resource->mem_type);
> GEM_BUG_ON(!dst_reg || !src_reg);
>
> + ret = i915_ttm_accel_move(bo, clear, dst_mem, dst_st);
> + if (ret) {
One future consideration is flat CCS where I don't think we can easily
fall back to memcpy for userspace objects. Maybe we can make this
fallback conditional on DG1 or !ALLOC_USER for now, or just add a
TODO?
> + dst_iter = !cpu_maps_iomem(dst_mem) ?
> + ttm_kmap_iter_tt_init(&_dst_iter.tt, bo->ttm) :
> + ttm_kmap_iter_iomap_init(&_dst_iter.io,
> _reg->iomap,
> +dst_st,
> dst_reg->region.start);
> +
> + src_iter = !cpu_maps_iomem(bo->resource) ?
> + ttm_kmap_iter_tt_init(&_src_iter.tt, bo->ttm) :
> + ttm_kmap_iter_iomap_init(&_src_iter.io,
> _reg->iomap,
> +obj->ttm.cached_io_st,
> +src_reg->region.start);
> +
> + ttm_move_memcpy(bo, dst_mem->num_pages, dst_iter, src_iter);
> + }
> +}
> +
> +static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
> +struct ttm_operation_ctx *ctx,
> +struct ttm_resource *dst_mem,
> +struct ttm_place *hop)
> +{
> + struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> + struct ttm_resource_manager *dst_man =
> + ttm_manager_type(bo->bdev, dst_mem->mem_type);
> + struct ttm_tt *ttm = bo->ttm;
> + struct sg_table *dst_st;
> + bool clear;
> + int ret;
> +
> /* Sync for now. We could do the actual copy async. */
> ret = ttm_bo_wait_ctx(bo, ctx);
> if (ret)
> @@ -526,9 +550,8 @@ static int i915_ttm_move(struct ttm_buffer_object *bo,
> bool evict,
> }
>
> /* Populate ttm with pages if needed. Typically system memory. */
> - if (bo->ttm
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Use the correct IRQ during resume
Hi
Am 30.06.21 um 12:49 schrieb Daniel Vetter:
On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
v3:
* also use intel_synchronize_hardirq() at another callsite
v2:
* wrap irq code in intel_synchronize_hardirq() (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 5 +
drivers/gpu/drm/i915/i915_irq.h | 1 +
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 88694822716a..5ca3d1664335 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1229,7 +1229,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return true;
/* Waiting to drain ELSP? */
- synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
+ intel_synchronize_hardirq(engine->i915);
intel_engine_flush_submission(engine);
/* ELSP is empty, but there are ready requests? E.g. after reset */
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..1b5a22a83db6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -185,7 +185,7 @@ static int xcs_resume(struct intel_engine_cs *engine)
ring->head, ring->tail);
/* Double check the ring is empty & disabled before we resume */
- synchronize_hardirq(engine->i915->drm.irq);
+ intel_synchronize_hardirq(engine->i915);
if (!stop_ring(engine))
goto err;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7d0ce8b9f8ed..2203dca19895 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4575,3 +4575,8 @@ void intel_synchronize_irq(struct drm_i915_private *i915)
{
synchronize_irq(to_pci_dev(i915->drm.dev)->irq);
}
+
+void intel_synchronize_hardirq(struct drm_i915_private *i915)
+{
+ synchronize_hardirq(to_pci_dev(i915->drm.dev)->irq);
I honestly think the hardirq here is about as much cargo-culted as using
the wrong irq number.
I'd just use intel_synchronize_irq in both places and see whether CI
complains, then go with that.
Well, ok. I don't think I have Sandybridge HW available. Would the Intel
CI infrastructure catch any problems with such a change?
Best regards
Thomas
-Daniel
+}
diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
index db34d5dbe402..e43b6734f21b 100644
--- a/drivers/gpu/drm/i915/i915_irq.h
+++ b/drivers/gpu/drm/i915/i915_irq.h
@@ -94,6 +94,7 @@ void intel_runtime_pm_disable_interrupts(struct
drm_i915_private *dev_priv);
void intel_runtime_pm_enable_interrupts(struct drm_i915_private *dev_priv);
bool intel_irqs_enabled(struct drm_i915_private *dev_priv);
void intel_synchronize_irq(struct drm_i915_private *i915);
+void intel_synchronize_hardirq(struct drm_i915_private *i915);
int intel_get_crtc_scanline(struct intel_crtc *crtc);
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
--
2.32.0
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
>-Original Message-
>From: Daniel Vetter
>Sent: Wednesday, June 30, 2021 10:02 AM
>To: Thomas Hellström ; Christian König
>
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Auld,
>Matthew ; maarten.lankho...@linux.intel.com;
>dan...@ffwll.ch; Ruhl, Michael J
>Subject: Re: [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
>
>On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
>> If our exported dma-bufs are imported by another instance of our driver,
>> that instance will typically have the imported dma-bufs locked during
>> dma_buf_map_attachment(). But the exporter also locks the same
>reservation
>> object in the map_dma_buf() callback, which leads to recursive locking.
>>
>> Add a live selftest to exercise both dynamic and non-dynamic exports,
>> and as a workaround until we fully support dynamic import and export,
>> declare the exporter dynamic by providing pin() and unpin()
>implementations.
>> For dynamic importers, make sure we keep the pinning also in
>map_dma_buf(),
>> to ensure we never need to call dma_buf_move_notify().
>> Calling dma_buf_move_notify() is at the discretion of the exporter.
>>
>> v2:
>> - Extend the selftest with a fake dynamic importer.
>> - Provide real pin and unpin callbacks to not abuse the interface.
>>
>> Reported-by: Michael J. Ruhl
>> Signed-off-by: Thomas Hellström
>
>I'm not happy with this, because i915 is currently violating the dma-resv
>fencing rules for dynamic dma-buf.
>
>Yes since this is just the exporter we can probably get away with yolo'ing
>things, but Christian and me just spend a lot of angry typing figuring out
>what the rules actually are, so I really don't like bending them even more
>just because it's less typing.
>
>All we need for a quick interim fix is to not take the dma_resv_lock from
>our map/unamp callbacks. Pinning our backing storage from attach/detach
>callbacks (which are also called under dma_resv_lock) would also achieve
>that, without mudding any waters. So essentially just moving the
>pin/unpin_pages_unlocked and we should be good, which is almost as little
>typing.
>
>Michael, since Thomas is on vacations now, care to type that up? The
>selftest is imo solid.
Yes, I will get that done.
Mike
>This is also consistent with what all other ttm based drivers do (aside
>from amdgpu, which is fully dynamic), see drm_gem_map_attach in
>drm_prime.c
>
>Adding Christian as fyi.
>-Daniel
>
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 -
>> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 116
>+-
>> 2 files changed, 143 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index 616c3a2f1baf..918c19df7b66 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -12,6 +12,8 @@
>> #include "i915_gem_object.h"
>> #include "i915_scatterlist.h"
>>
>> +I915_SELFTEST_DECLARE(static bool force_different_devices;)
>> +
>> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf
>*buf)
>> {
>> return to_intel_bo(buf->priv);
>> @@ -25,7 +27,14 @@ static struct sg_table
>*i915_gem_map_dma_buf(struct dma_buf_attachment *attachme
>> struct scatterlist *src, *dst;
>> int ret, i;
>>
>> -ret = i915_gem_object_pin_pages_unlocked(obj);
>> +assert_object_held(obj);
>> +
>> +/*
>> + * Note. In the dynamic importer case, the object is not yet pinned.
>> + * Let's pin it here to avoid having to call the move_notify
>> + * callback, The call of which is not yet implemented.
>> + */
>> +ret = i915_gem_object_pin_pages(obj);
>> if (ret)
>> goto err;
>>
>> @@ -168,6 +177,21 @@ static int i915_gem_end_cpu_access(struct
>dma_buf *dma_buf, enum dma_data_direct
>> return err;
>> }
>>
>> +static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
>> +{
>> +struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>> +
>> +assert_object_held(obj);
>> +return i915_gem_object_pin_pages(obj);
>> +}
>> +
>> +static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
>> +{
>> +struct drm_i915_gem_object *obj = dma_buf_to_obj(attach-
>>dmabuf);
>> +
>> +i915_gem_object_unpin_pages(obj);
>> +}
>> +
>> static const struct dma_buf_ops i915_dmabuf_ops = {
>> .map_dma_buf = i915_gem_map_dma_buf,
>> .unmap_dma_buf = i915_gem_unmap_dma_buf,
>> @@ -177,6 +201,8 @@ static const struct dma_buf_ops i915_dmabuf_ops =
>{
>> .vunmap = i915_gem_dmabuf_vunmap,
>> .begin_cpu_access = i915_gem_begin_cpu_access,
>> .end_cpu_access = i915_gem_end_cpu_access,
>> +.pin = i915_gem_dmabuf_pin,
>> +.unpin = i915_gem_dmabuf_unpin,
>> };
>>
>> struct dma_buf *i915_gem_prime_export(struct drm_gem_object
>*gem_obj, int flags)
>> @@ -241,7 +267,8 @@ struct drm_gem_object
>*i915_gem_prime_import(struct
Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch
On Wed, Jun 30, 2021 at 12:46:27PM +, Surendrakumar Upadhyay, TejaskumarX wrote: > > > > -Original Message- > > From: Daniel Vetter > > Sent: 30 June 2021 17:52 > > To: Surendrakumar Upadhyay, TejaskumarX > > > > Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; > > ch...@chris-wilson.co.uk > > Subject: Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch > > > > On Wed, Jun 30, 2021 at 05:32:15PM +0530, Tejas Upadhyay wrote: > > > Having different alignment requirement by different drivers, 256B > > > aligned should work for all drm drivers. > > > > What. > > > > Like yes vgem abuses dumb_create, but it's not a kms driver. Pitch is > > meaningless, and that's why we align it minimally to 1 byte (bpp = bits per > > pixel here). > > > > Maybe start with explaining what you're trying to do here. > > -Daniel > > > > > Igt tool tests which are trying to exercise tests through VGEM are getting > failure (if not 64B aligned) on Intel platforms in creating framebuffer as > they need them to be 64B aligned. Then 64B alignment is not > A requirement for all drm drivers. Fix the tests. We're not going to encode alignment constraints for all kms drivers in vgem, that's not what vgem is for. Really what we should have done is just give vgem an ioctl to allocate a buffer, with the size specified in bytes. Not this "abuse dumb_create" business we're doing. But that's a past mistake, can't really fix that. -Daniel > > Thanks, > Tejas > > > > Signed-off-by: Tejas Upadhyay > > > > > > --- > > > drivers/gpu/drm/vgem/vgem_drv.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c > > > b/drivers/gpu/drm/vgem/vgem_drv.c index bf38a7e319d1..1da6df5e256a > > > 100644 > > > --- a/drivers/gpu/drm/vgem/vgem_drv.c > > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > > > @@ -215,7 +215,7 @@ static int vgem_gem_dumb_create(struct drm_file > > *file, struct drm_device *dev, > > > struct drm_gem_object *gem_object; > > > u64 pitch, size; > > > > > > - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > > > + pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 256); > > > size = args->height * pitch; > > > if (size == 0) > > > return -EINVAL; > > > -- > > > 2.31.1 > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
> If our exported dma-bufs are imported by another instance of our driver,
> that instance will typically have the imported dma-bufs locked during
> dma_buf_map_attachment(). But the exporter also locks the same reservation
> object in the map_dma_buf() callback, which leads to recursive locking.
>
> Add a live selftest to exercise both dynamic and non-dynamic exports,
> and as a workaround until we fully support dynamic import and export,
> declare the exporter dynamic by providing pin() and unpin() implementations.
> For dynamic importers, make sure we keep the pinning also in map_dma_buf(),
> to ensure we never need to call dma_buf_move_notify().
> Calling dma_buf_move_notify() is at the discretion of the exporter.
>
> v2:
> - Extend the selftest with a fake dynamic importer.
> - Provide real pin and unpin callbacks to not abuse the interface.
>
> Reported-by: Michael J. Ruhl
> Signed-off-by: Thomas Hellström
I'm not happy with this, because i915 is currently violating the dma-resv
fencing rules for dynamic dma-buf.
Yes since this is just the exporter we can probably get away with yolo'ing
things, but Christian and me just spend a lot of angry typing figuring out
what the rules actually are, so I really don't like bending them even more
just because it's less typing.
All we need for a quick interim fix is to not take the dma_resv_lock from
our map/unamp callbacks. Pinning our backing storage from attach/detach
callbacks (which are also called under dma_resv_lock) would also achieve
that, without mudding any waters. So essentially just moving the
pin/unpin_pages_unlocked and we should be good, which is almost as little
typing.
Michael, since Thomas is on vacations now, care to type that up? The
selftest is imo solid.
This is also consistent with what all other ttm based drivers do (aside
from amdgpu, which is fully dynamic), see drm_gem_map_attach in
drm_prime.c
Adding Christian as fyi.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 -
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 116 +-
> 2 files changed, 143 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 616c3a2f1baf..918c19df7b66 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -12,6 +12,8 @@
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
>
> +I915_SELFTEST_DECLARE(static bool force_different_devices;)
> +
> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> {
> return to_intel_bo(buf->priv);
> @@ -25,7 +27,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> dma_buf_attachment *attachme
> struct scatterlist *src, *dst;
> int ret, i;
>
> - ret = i915_gem_object_pin_pages_unlocked(obj);
> + assert_object_held(obj);
> +
> + /*
> + * Note. In the dynamic importer case, the object is not yet pinned.
> + * Let's pin it here to avoid having to call the move_notify
> + * callback, The call of which is not yet implemented.
> + */
> + ret = i915_gem_object_pin_pages(obj);
> if (ret)
> goto err;
>
> @@ -168,6 +177,21 @@ static int i915_gem_end_cpu_access(struct dma_buf
> *dma_buf, enum dma_data_direct
> return err;
> }
>
> +static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
> +{
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
> +
> + assert_object_held(obj);
> + return i915_gem_object_pin_pages(obj);
> +}
> +
> +static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
> +{
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
> +
> + i915_gem_object_unpin_pages(obj);
> +}
> +
> static const struct dma_buf_ops i915_dmabuf_ops = {
> .map_dma_buf = i915_gem_map_dma_buf,
> .unmap_dma_buf = i915_gem_unmap_dma_buf,
> @@ -177,6 +201,8 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
> .vunmap = i915_gem_dmabuf_vunmap,
> .begin_cpu_access = i915_gem_begin_cpu_access,
> .end_cpu_access = i915_gem_end_cpu_access,
> + .pin = i915_gem_dmabuf_pin,
> + .unpin = i915_gem_dmabuf_unpin,
> };
>
> struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int
> flags)
> @@ -241,7 +267,8 @@ struct drm_gem_object *i915_gem_prime_import(struct
> drm_device *dev,
> if (dma_buf->ops == _dmabuf_ops) {
> obj = dma_buf_to_obj(dma_buf);
> /* is it from our device? */
> - if (obj->base.dev == dev) {
> + if (obj->base.dev == dev &&
> + !I915_SELFTEST_ONLY(force_different_devices)) {
> /*
>* Importing dmabuf exported from out own gem increases
>* refcount on gem itself instead of
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
> -Original Message-
> From: Patnana, Venkata Sai
> Sent: Wednesday, June 30, 2021 11:59 AM
> To: Jani Nikula ;
> intel-gfx@lists.freedesktop.org;
> Navare, Manasi D ; Kulkarni, Vandita
>
> Subject: RE: [Intel-gfx] [PATCH v2 1/2] drm/i915/display/dsc: Add Per
> connector
> debugfs node for DSC BPP enable
>
> > From: Jani Nikula
> > Sent: Tuesday, June 29, 2021 8:06 PM
> > To: Patnana, Venkata Sai ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/display/dsc: Add Per
> > connector debugfs node for DSC BPP enable
> >
> > On Tue, 29 Jun 2021, venkata.sai.patn...@intel.com wrote:
> > > From: Anusha Srivatsa
> > >
> > > DSC can be supported per DP connector. This patch creates a per
> > > connector debugfs node to expose the Input and Compressed BPP.
> > >
> > > The same node can be used from userspace to force DSC to a certain
> > > BPP.
> > >
> > > force_dsc_bpp is written through this debugfs node to force DSC BPP
> > > to all accepted values
> >
> > This commit message only describes the "what". It's nice and helpful
> > to summarize the code changes.
I ll update commit message with below details.
> >
> > But the key question the commit message must answer is "why". Why are
> > you doing this? Why do we need this?
We want to test all the possible compression bpp's otherwise else we can verify
limited bpp's
> >
> > This looks like it complicates code that is already complicated to add a
> debugfs.
> > There needs to be a justification if it isn't obvious.
> >
> > A couple of comments inline.
> >
> > >
> > > Cc: Vandita Kulkarni
> > > Cc: Navare Manasi D
> > > Signed-off-by: Anusha Srivatsa
> > > Signed-off-by: Patnana Venkata Sai
> > > ---
> > > .../drm/i915/display/intel_display_debugfs.c | 103 +-
> > > .../drm/i915/display/intel_display_types.h| 1 +
> > > 2 files changed, 103 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > index af9e58619667d..6dc223227eeaa 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> > > @@ -2389,6 +2389,100 @@ static const struct file_operations
> > i915_dsc_fec_support_fops = {
> > > .write = i915_dsc_fec_support_write };
> > >
> > > +static int i915_dsc_bpp_support_show(struct seq_file *m, void
> > > +*data) {
> > > + struct drm_connector *connector = m->private;
> > > + struct drm_device *dev = connector->dev;
> > > + struct drm_crtc *crtc;
> > > + struct intel_dp *intel_dp;
> > > + struct drm_modeset_acquire_ctx ctx;
> > > + struct intel_crtc_state *crtc_state = NULL;
> > > + int ret = 0;
> > > + bool try_again = false;
> > > +
> > > + drm_modeset_acquire_init(,
> > DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> > > +
> > > + do {
> > > + try_again = false;
> > > + ret = drm_modeset_lock(
> > >mode_config.connection_mutex,
> > > +);
> > > + if (ret) {
> > > + ret = -EINTR;
> > > + break;
> > > + }
> > > + crtc = connector->state->crtc;
> > > + if (connector->status != connector_status_connected || !crtc) {
> > > + ret = -ENODEV;
> > > + break;
> > > + }
> > > + ret = drm_modeset_lock(>mutex, );
> > > + if (ret == -EDEADLK) {
> > > + ret = drm_modeset_backoff();
> > > + if (!ret) {
> > > + try_again = true;
> > > + continue;
> > > + }
> > > + break;
> > > + } else if (ret) {
> > > + break;
> > > + }
> > > + intel_dp = intel_attached_dp(to_intel_connector(connector));
> > > + crtc_state = to_intel_crtc_state(crtc->state);
> > > + seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
> > > + seq_printf(m, "Compressed_BPP: %d\n",
> > > + crtc_state->dsc.compressed_bpp);
> > > + } while (try_again);
> > > +
> > > + drm_modeset_drop_locks();
> > > + drm_modeset_acquire_fini();
> > > +
> > > + return ret;
> >
> > Looks like copy-paste from i915_dsc_fec_support_show() which already
> > makes me cringe. We can't keep accumulating this kind of code in debugfs.
> @Navare, Manasi D, @Kulkarni, Vandita any thoughts ?
I ll create new file each entry, so that it become simple.
>
> >
> > > +}
> > > +
> > > +static ssize_t i915_dsc_bpp_support_write(struct file *file,
> > > + const char __user *ubuf,
> > > + size_t len, loff_t *offp)
> > > +{
> > > + int dsc_bpp = 0;
> > > + int ret;
> > > + struct drm_connector *connector =
> > > + ((struct seq_file *)file->private_data)->private;
> > > + struct intel_encoder *encoder =
> >
[Intel-gfx] [PATCH 1/2] drm/i915/gem: Make our dma-buf exporter dynamic
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a live selftest to exercise both dynamic and non-dynamic exports,
and as a workaround until we fully support dynamic import and export,
declare the exporter dynamic by providing pin() and unpin() implementations.
For dynamic importers, make sure we keep the pinning also in map_dma_buf(),
to ensure we never need to call dma_buf_move_notify().
Calling dma_buf_move_notify() is at the discretion of the exporter.
v2:
- Extend the selftest with a fake dynamic importer.
- Provide real pin and unpin callbacks to not abuse the interface.
Reported-by: Michael J. Ruhl
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 -
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 116 +-
2 files changed, 143 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 616c3a2f1baf..918c19df7b66 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,8 @@
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
+I915_SELFTEST_DECLARE(static bool force_different_devices;)
+
static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
{
return to_intel_bo(buf->priv);
@@ -25,7 +27,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
struct scatterlist *src, *dst;
int ret, i;
- ret = i915_gem_object_pin_pages_unlocked(obj);
+ assert_object_held(obj);
+
+ /*
+* Note. In the dynamic importer case, the object is not yet pinned.
+* Let's pin it here to avoid having to call the move_notify
+* callback, The call of which is not yet implemented.
+*/
+ ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err;
@@ -168,6 +177,21 @@ static int i915_gem_end_cpu_access(struct dma_buf
*dma_buf, enum dma_data_direct
return err;
}
+static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
+{
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
+
+ assert_object_held(obj);
+ return i915_gem_object_pin_pages(obj);
+}
+
+static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
+{
+ struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
+
+ i915_gem_object_unpin_pages(obj);
+}
+
static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
@@ -177,6 +201,8 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
.vunmap = i915_gem_dmabuf_vunmap,
.begin_cpu_access = i915_gem_begin_cpu_access,
.end_cpu_access = i915_gem_end_cpu_access,
+ .pin = i915_gem_dmabuf_pin,
+ .unpin = i915_gem_dmabuf_unpin,
};
struct dma_buf *i915_gem_prime_export(struct drm_gem_object *gem_obj, int
flags)
@@ -241,7 +267,8 @@ struct drm_gem_object *i915_gem_prime_import(struct
drm_device *dev,
if (dma_buf->ops == _dmabuf_ops) {
obj = dma_buf_to_obj(dma_buf);
/* is it from our device? */
- if (obj->base.dev == dev) {
+ if (obj->base.dev == dev &&
+ !I915_SELFTEST_ONLY(force_different_devices)) {
/*
* Importing dmabuf exported from out own gem increases
* refcount on gem itself instead of f_count of dmabuf.
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index dd74bc09ec88..868b3469ecbd 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -35,7 +35,7 @@ static int igt_dmabuf_export(void *arg)
static int igt_dmabuf_import_self(void *arg)
{
struct drm_i915_private *i915 = arg;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj, *import_obj;
struct drm_gem_object *import;
struct dma_buf *dmabuf;
int err;
@@ -65,14 +65,125 @@ static int igt_dmabuf_import_self(void *arg)
err = -EINVAL;
goto out_import;
}
+ import_obj = to_intel_bo(import);
+
+ i915_gem_object_lock(import_obj, NULL);
+ err = i915_gem_object_get_pages(import_obj);
+ i915_gem_object_unlock(import_obj);
+ if (err) {
+ pr_err("Same object dma-buf get_pages failed!\n");
+ goto out_import;
+ }
err = 0;
out_import:
- i915_gem_object_put(to_intel_bo(import));
+
[Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf map time
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf map time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() callback.
Signed-off-by: Thomas Hellström
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 21 +--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 4 +++-
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 918c19df7b66..13312d89c2ed 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -34,7 +34,14 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
* Let's pin it here to avoid having to call the move_notify
* callback, The call of which is not yet implemented.
*/
- ret = i915_gem_object_pin_pages(obj);
+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM))
+ return ERR_PTR(-EOPNOTSUPP);
+
+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM);
+ if (!ret)
+ ret = i915_gem_object_wait_migration(obj, 0);
+ if (!ret)
+ ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err;
@@ -180,9 +187,19 @@ static int i915_gem_end_cpu_access(struct dma_buf
*dma_buf, enum dma_data_direct
static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(attach->dmabuf);
+ int ret;
assert_object_held(obj);
- return i915_gem_object_pin_pages(obj);
+
+ if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM))
+ return -EOPNOTSUPP;
+ ret = i915_gem_object_migrate(obj, NULL, INTEL_REGION_SMEM);
+ if (!ret)
+ ret = i915_gem_object_wait_migration(obj, 0);
+ if (!ret)
+ ret = i915_gem_object_pin_pages(obj);
+
+ return ret;
}
static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index 868b3469ecbd..b1e87ec08741 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -106,7 +106,9 @@ static int igt_dmabuf_import_same_driver(void *arg)
int err;
force_different_devices = true;
- obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
+ obj = i915_gem_object_create_lmem(i915, PAGE_SIZE, 0);
+ if (IS_ERR(obj))
+ obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
if (IS_ERR(obj))
goto out_ret;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm/i915/gem: dma-buf fixes for migration
Our dma-buf code is currently completely broken unless the importer is dynamic in which case the sg_list caching saves the day. In particular, the case where another instance of our driver tries to import a dma-buf exported by our driver ends up in a recursive lock. Since the recent TTM migration work spec specifies to fix up the dma-buf code with migration and there's no point in doing so when it's completely broken, take a first step to make at least the exporter obey the dma-buf locking rules the dma-buf core enforces for a dynamic exporter: - Implement and act on pin- and unpin. - Call move_notify if migrating. (we opt not to migrate while dma-buf_mapped). - map_dma_buf() is unconditionally called locked. Add a selftest that ensures that it works with both our own and a fake dynamic importer. Also implement migration in the second patch before pinning in pin() and map_dma_buf(). Note that the importer remains broken for other non-dynamic exporters, but at least not for the same-driver-separate-instances case. Regardless whether we want to fix this now with this series, or in an unspecified future, the selftest may come in handy. Thomas Hellström (2): drm/i915/gem: Make our dma-buf exporter dynamic drm/i915/gem: Migrate to system at dma-buf map time drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 48 ++- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 118 +- 2 files changed, 162 insertions(+), 4 deletions(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch
> -Original Message- > From: Daniel Vetter > Sent: 30 June 2021 17:52 > To: Surendrakumar Upadhyay, TejaskumarX > > Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; > ch...@chris-wilson.co.uk > Subject: Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch > > On Wed, Jun 30, 2021 at 05:32:15PM +0530, Tejas Upadhyay wrote: > > Having different alignment requirement by different drivers, 256B > > aligned should work for all drm drivers. > > What. > > Like yes vgem abuses dumb_create, but it's not a kms driver. Pitch is > meaningless, and that's why we align it minimally to 1 byte (bpp = bits per > pixel here). > > Maybe start with explaining what you're trying to do here. > -Daniel > > Igt tool tests which are trying to exercise tests through VGEM are getting failure (if not 64B aligned) on Intel platforms in creating framebuffer as they need them to be 64B aligned. Then 64B alignment is not A requirement for all drm drivers. Thanks, Tejas > > Signed-off-by: Tejas Upadhyay > > > > --- > > drivers/gpu/drm/vgem/vgem_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c > > b/drivers/gpu/drm/vgem/vgem_drv.c index bf38a7e319d1..1da6df5e256a > > 100644 > > --- a/drivers/gpu/drm/vgem/vgem_drv.c > > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > > @@ -215,7 +215,7 @@ static int vgem_gem_dumb_create(struct drm_file > *file, struct drm_device *dev, > > struct drm_gem_object *gem_object; > > u64 pitch, size; > > > > - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > > + pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 256); > > size = args->height * pitch; > > if (size == 0) > > return -EINVAL; > > -- > > 2.31.1 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/3] drm: protect drm_master pointers in drm_lease.c
On 30/6/21 4:02 pm, Daniel Vetter wrote:
On Wed, Jun 30, 2021 at 9:18 AM Desmond Cheong Zhi Xi
wrote:
On 30/6/21 12:07 am, Daniel Vetter wrote:
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to drm_setmaster_ioctl will
invoke drm_new_set_master, which then allocates a new master for
drm_file and puts the old master.
Thus, without holding drm_device.master_mutex, the old value of
drm_file->master could be freed while it is being used by another
concurrent process.
In drm_lease.c, there are multiple instances where drm_file->master is
accessed and dereferenced while drm_device.master_mutex is not
held. This makes drm_lease.c vulnerable to use-after-free bugs.
We address this issue in 3 ways:
1. Clarify in the kerneldoc that drm_file->master is protected by
drm_device.master_mutex.
2. Add a new drm_file_get_master() function that calls drm_master_get
on drm_file->master while holding on to drm_device.master_mutex. Since
drm_master_get increments the reference count of master, this
prevents master from being freed until we unreference it with
drm_master_put.
3. In each case where drm_file->master is directly accessed and
eventually dereferenced in drm_lease.c, we wrap the access in a call
to the new drm_file_get_master function, then unreference the master
pointer once we are done using it.
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
Series looks very nice, let's see what intel-gfx-ci says. You should get a
mail, but results are also here:
https://patchwork.freedesktop.org/series/91969/#rev2
One tiny comment below.
---
drivers/gpu/drm/drm_auth.c | 25
drivers/gpu/drm/drm_lease.c | 77 +++--
include/drm/drm_auth.h | 1 +
include/drm/drm_file.h | 15 ++--
4 files changed, 95 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index ab1863c5a5a0..c36a0b72be26 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -384,6 +384,31 @@ struct drm_master *drm_master_get(struct drm_master
*master)
}
EXPORT_SYMBOL(drm_master_get);
+/**
+ * drm_file_get_master - reference _file.master of @file_priv
+ * @file_priv: DRM file private
+ *
+ * Increments the reference count of @file_priv's _file.master and returns
+ * the _file.master. If @file_priv has no _file.master, returns NULL.
+ *
+ * Master pointers returned from this function should be unreferenced using
+ * drm_master_put().
+ */
+struct drm_master *drm_file_get_master(struct drm_file *file_priv)
+{
+struct drm_master *master = NULL;
+
+mutex_lock(_priv->minor->dev->master_mutex);
+if (!file_priv->master)
+goto unlock;
+master = drm_master_get(file_priv->master);
+
+unlock:
+mutex_unlock(_priv->minor->dev->master_mutex);
+return master;
+}
+EXPORT_SYMBOL(drm_file_get_master);
+
static void drm_master_destroy(struct kref *kref)
{
struct drm_master *master = container_of(kref, struct drm_master,
refcount);
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 00fb433bcef1..cdcc87fa9685 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -106,10 +106,19 @@ static bool _drm_has_leased(struct drm_master *master,
int id)
*/
bool _drm_lease_held(struct drm_file *file_priv, int id)
{
-if (!file_priv || !file_priv->master)
+bool ret;
+struct drm_master *master;
+
+if (!file_priv)
return true;
-return _drm_lease_held_master(file_priv->master, id);
+master = drm_file_get_master(file_priv);
+if (master == NULL)
+return true;
+ret = _drm_lease_held_master(master, id);
+drm_master_put();
+
+return ret;
}
/**
@@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
-if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+if (!file_priv)
return true;
-master = file_priv->master;
+master = drm_file_get_master(file_priv);
+if (master == NULL)
+return true;
+if (!master->lessor) {
+drm_master_put();
+return true;
+}
mutex_lock(>dev->mode_config.idr_mutex);
ret = _drm_lease_held_master(master, id);
mutex_unlock(>dev->mode_config.idr_mutex);
+drm_master_put();
return ret;
}
@@ -154,10 +170,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file
*file_priv, uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
-if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+if
Re: [Intel-gfx] [PATCH v5 3/3] drm: protect drm_master pointers in drm_lease.c
On 30/6/21 12:07 am, Daniel Vetter wrote:
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to drm_setmaster_ioctl will
invoke drm_new_set_master, which then allocates a new master for
drm_file and puts the old master.
Thus, without holding drm_device.master_mutex, the old value of
drm_file->master could be freed while it is being used by another
concurrent process.
In drm_lease.c, there are multiple instances where drm_file->master is
accessed and dereferenced while drm_device.master_mutex is not
held. This makes drm_lease.c vulnerable to use-after-free bugs.
We address this issue in 3 ways:
1. Clarify in the kerneldoc that drm_file->master is protected by
drm_device.master_mutex.
2. Add a new drm_file_get_master() function that calls drm_master_get
on drm_file->master while holding on to drm_device.master_mutex. Since
drm_master_get increments the reference count of master, this
prevents master from being freed until we unreference it with
drm_master_put.
3. In each case where drm_file->master is directly accessed and
eventually dereferenced in drm_lease.c, we wrap the access in a call
to the new drm_file_get_master function, then unreference the master
pointer once we are done using it.
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
Series looks very nice, let's see what intel-gfx-ci says. You should get a
mail, but results are also here:
https://patchwork.freedesktop.org/series/91969/#rev2
One tiny comment below.
---
drivers/gpu/drm/drm_auth.c | 25
drivers/gpu/drm/drm_lease.c | 77 +++--
include/drm/drm_auth.h | 1 +
include/drm/drm_file.h | 15 ++--
4 files changed, 95 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index ab1863c5a5a0..c36a0b72be26 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -384,6 +384,31 @@ struct drm_master *drm_master_get(struct drm_master
*master)
}
EXPORT_SYMBOL(drm_master_get);
+/**
+ * drm_file_get_master - reference _file.master of @file_priv
+ * @file_priv: DRM file private
+ *
+ * Increments the reference count of @file_priv's _file.master and returns
+ * the _file.master. If @file_priv has no _file.master, returns NULL.
+ *
+ * Master pointers returned from this function should be unreferenced using
+ * drm_master_put().
+ */
+struct drm_master *drm_file_get_master(struct drm_file *file_priv)
+{
+ struct drm_master *master = NULL;
+
+ mutex_lock(_priv->minor->dev->master_mutex);
+ if (!file_priv->master)
+ goto unlock;
+ master = drm_master_get(file_priv->master);
+
+unlock:
+ mutex_unlock(_priv->minor->dev->master_mutex);
+ return master;
+}
+EXPORT_SYMBOL(drm_file_get_master);
+
static void drm_master_destroy(struct kref *kref)
{
struct drm_master *master = container_of(kref, struct drm_master,
refcount);
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 00fb433bcef1..cdcc87fa9685 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -106,10 +106,19 @@ static bool _drm_has_leased(struct drm_master *master,
int id)
*/
bool _drm_lease_held(struct drm_file *file_priv, int id)
{
- if (!file_priv || !file_priv->master)
+ bool ret;
+ struct drm_master *master;
+
+ if (!file_priv)
return true;
- return _drm_lease_held_master(file_priv->master, id);
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return true;
+ ret = _drm_lease_held_master(master, id);
+ drm_master_put();
+
+ return ret;
}
/**
@@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return true;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return true;
+ if (!master->lessor) {
+ drm_master_put();
+ return true;
+ }
mutex_lock(>dev->mode_config.idr_mutex);
ret = _drm_lease_held_master(master, id);
mutex_unlock(>dev->mode_config.idr_mutex);
+ drm_master_put();
return ret;
}
@@ -154,10 +170,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file *file_priv, uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if
Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> On Wed, Jun 30, 2021 at 9:43 AM Nathan Chancellor wrote:
> >
> > On Thu, Jun 24, 2021 at 11:55:20PM +0800, Claire Chang wrote:
> > > Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
> > > use it to determine whether to bounce the data or not. This will be
> > > useful later to allow for different pools.
> > >
> > > Signed-off-by: Claire Chang
> > > Reviewed-by: Christoph Hellwig
> > > Tested-by: Stefano Stabellini
> > > Tested-by: Will Deacon
> > > Acked-by: Stefano Stabellini
> >
> > This patch as commit af452ec1b1a3 ("swiotlb: Use is_swiotlb_force_bounce
> > for swiotlb data bouncing") causes my Ryzen 3 4300G system to fail to
> > get to an X session consistently (although not every single time),
> > presumably due to a crash in the AMDGPU driver that I see in dmesg.
> >
> > I have attached logs at af452ec1b1a3 and f127c9556a8e and I am happy
> > to provide any further information, debug, or test patches as necessary.
>
> Are you using swiotlb=force? or the swiotlb_map is called because of
> !dma_capable?
> (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/dma/direct.h#n93)
The command line is in the dmesg:
| Kernel command line: initrd=\amd-ucode.img
initrd=\initramfs-linux-next-llvm.img
root=PARTUUID=8680aa0c-cf09-4a69-8cf3-970478040ee7 rw intel_pstate=no_hwp
irqpoll
but I worry that this looks _very_ similar to the issue reported by Qian
Cai which we thought we had fixed. Nathan -- is the failure deterministic?
> `BUG: unable to handle page fault for address: 003a8290` and
> the fact it crashed at `_raw_spin_lock_irqsave` look like the memory
> (maybe dev->dma_io_tlb_mem) was corrupted?
> The dev->dma_io_tlb_mem should be set here
> (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pci/probe.c#n2528)
> through device_initialize.
I'm less sure about this. 'dma_io_tlb_mem' should be pointing at
'io_tlb_default_mem', which is a page-aligned allocation from memblock.
The spinlock is at offset 0x24 in that structure, and looking at the
register dump from the crash:
Jun 29 18:28:42 hp-4300G kernel: RSP: 0018:adb4013db9e8 EFLAGS: 00010006
Jun 29 18:28:42 hp-4300G kernel: RAX: 003a8290 RBX:
RCX: 8900572ad580
Jun 29 18:28:42 hp-4300G kernel: RDX: 89005653f024 RSI: 000c
RDI: 1d17
Jun 29 18:28:42 hp-4300G kernel: RBP: 0a20d000 R08: 000c
R09:
Jun 29 18:28:42 hp-4300G kernel: R10: 0a20d000 R11: 89005653f000
R12: 0212
Jun 29 18:28:42 hp-4300G kernel: R13: 1000 R14: 0002
R15: 0020
Jun 29 18:28:42 hp-4300G kernel: FS: 7f1f8898ea40()
GS:89005728() knlGS:
Jun 29 18:28:42 hp-4300G kernel: CS: 0010 DS: ES: CR0:
80050033
Jun 29 18:28:42 hp-4300G kernel: CR2: 003a8290 CR3: 0001020d
CR4: 00350ee0
Jun 29 18:28:42 hp-4300G kernel: Call Trace:
Jun 29 18:28:42 hp-4300G kernel: _raw_spin_lock_irqsave+0x39/0x50
Jun 29 18:28:42 hp-4300G kernel: swiotlb_tbl_map_single+0x12b/0x4c0
Then that correlates with R11 holding the 'dma_io_tlb_mem' pointer and
RDX pointing at the spinlock. Yet RAX is holding junk :/
I agree that enabling KASAN would be a good idea, but I also think we
probably need to get some more information out of swiotlb_tbl_map_single()
to see see what exactly is going wrong in there.
Will
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/3] drm: protect drm_master pointers in drm_lease.c
On 30/6/21 8:16 am, Emil Velikov wrote:
Hi Desmond,
Couple of small suggestions, with those the series is:
Reviewed-by: Emil Velikov
On Tue, 29 Jun 2021 at 04:38, Desmond Cheong Zhi Xi
wrote:
@@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return true;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return true;
+ if (!master->lessor) {
+ drm_master_put();
+ return true;
Let's add a "ret = true; goto unlock;" here, so we can have a single
drm_master_put() in the function.
Nearly all code paths touched by this patch already follow this approach.
@@ -154,10 +170,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file
*file_priv, uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return crtcs_in;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return crtcs_in;
+ if (!master->lessor) {
+ drm_master_put();
+ return crtcs_in;
Ditto
Thanks
Emil
Sounds good to me, I'll revise these functions. Thanks for the review
and suggestions, Emil.
Best wishes,
Desmond
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch
On Wed, Jun 30, 2021 at 05:32:15PM +0530, Tejas Upadhyay wrote: > Having different alignment requirement by different drivers, > 256B aligned should work for all drm drivers. What. Like yes vgem abuses dumb_create, but it's not a kms driver. Pitch is meaningless, and that's why we align it minimally to 1 byte (bpp = bits per pixel here). Maybe start with explaining what you're trying to do here. -Daniel > > Signed-off-by: Tejas Upadhyay > --- > drivers/gpu/drm/vgem/vgem_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c > index bf38a7e319d1..1da6df5e256a 100644 > --- a/drivers/gpu/drm/vgem/vgem_drv.c > +++ b/drivers/gpu/drm/vgem/vgem_drv.c > @@ -215,7 +215,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, > struct drm_device *dev, > struct drm_gem_object *gem_object; > u64 pitch, size; > > - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); > + pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 256); > size = args->height * pitch; > if (size == 0) > return -EINVAL; > -- > 2.31.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2] drm/i915: Tweaked Wa_14010685332 for all PCHs
On 2021-06-30 at 19:19:04 +0800, acelan@canonical.com wrote:
> > dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
> > despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
> > state.
> >
> > The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked
> > Wa_14010685332 sequence for every PCH since PCH_CNP.
> >
> > v2:
> > - removed RKL from comment and simplified condition. [Rodrigo]
> >
> > Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on
> > gen11 platforms") Cc: Matt Roper
> > Cc: Rodrigo Vivi
> > Cc: Imre Deak
> > Signed-off-by: Anshuman Gupta
> > ---
> >
> > .../drm/i915/display/intel_display_power.c| 16 +++---
> > drivers/gpu/drm/i915/i915_irq.c | 21 ---
> > 2 files changed, 8 insertions(+), 29 deletions(-)
> Hi,
>
> I didn't see this patch shown in mainline kernel tree, nor in drm-tip,
> May I know what the patch's status now?
We have observed that this patch does not fix the issue on all platforms.
That is the reason patch is not merged yet.
Br,
Anshuman Gupta.
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch
Having different alignment requirement by different drivers, 256B aligned should work for all drm drivers. Signed-off-by: Tejas Upadhyay --- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c index bf38a7e319d1..1da6df5e256a 100644 --- a/drivers/gpu/drm/vgem/vgem_drv.c +++ b/drivers/gpu/drm/vgem/vgem_drv.c @@ -215,7 +215,7 @@ static int vgem_gem_dumb_create(struct drm_file *file, struct drm_device *dev, struct drm_gem_object *gem_object; u64 pitch, size; - pitch = args->width * DIV_ROUND_UP(args->bpp, 8); + pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 256); size = args->height * pitch; if (size == 0) return -EINVAL; -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Drop all references to DRM IRQ midlayer
Hi
Am 30.06.21 um 12:06 schrieb Greg KH:
On Wed, Jun 30, 2021 at 11:52:28AM +0200, Thomas Zimmermann wrote:
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v5.4+
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_irq.c | 5 -
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 850b499c71c8..73de45472f60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2203dca19895..1d4c683c9de9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -33,7 +33,6 @@
#include
#include
-#include
#include "display/intel_de.h"
#include "display/intel_display_types.h"
@@ -4564,10 +4563,6 @@ void intel_runtime_pm_enable_interrupts(struct
drm_i915_private *dev_priv)
bool intel_irqs_enabled(struct drm_i915_private *dev_priv)
{
- /*
-* We only use drm_irq_uninstall() at unload and VT switch, so
-* this is the only thing we need to check.
-*/
return dev_priv->runtime_pm.irqs_enabled;
}
--
2.32.0
How is this a stable-kernel-related fix?
Sorry, it isn't. I forgot to remove the rsp Cc tag.
Best regards
Thomas
thanks,
greg k-h
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
OpenPGP_signature
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2] drm/i915: Tweaked Wa_14010685332 for all PCHs
> -Original Message-
> From: AceLan Kao On Behalf Of
> acelan@canonical.com
> Sent: Wednesday, June 30, 2021 4:49 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [v2] drm/i915: Tweaked Wa_14010685332 for all PCHs
>
> > dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H
> > platform despite Wa_14010685332 original sequence, thus blocks entry
> > to deeper s0ix state.
> >
> > The Tweaked Wa_14010685332 sequence fixes this issue, therefore use
> > tweaked
> > Wa_14010685332 sequence for every PCH since PCH_CNP.
> >
> > v2:
> > - removed RKL from comment and simplified condition. [Rodrigo]
> >
> > Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used
> > on
> > gen11 platforms") Cc: Matt Roper
> > Cc: Rodrigo Vivi
> > Cc: Imre Deak
> > Signed-off-by: Anshuman Gupta
> > ---
> >
> > .../drm/i915/display/intel_display_power.c| 16 +++---
> > drivers/gpu/drm/i915/i915_irq.c | 21 ---
> > 2 files changed, 8 insertions(+), 29 deletions(-)
> Hi,
>
> I didn't see this patch shown in mainline kernel tree, nor in drm-tip, May I
> know
> what the patch's status now?
We have observed that this patch does not fix the issue on some platforms.
That is the reason patch is not merged yet.
Br,
Anshuman Gupta.
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v3 1/2] drm/i915/dg1: Adjust the AUDIO power domain
> -Original Message- > From: Deak, Imre > Sent: Monday, June 28, 2021 11:12 PM > To: Gupta, Anshuman > Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä > ; > Kai Vehmanen ; Shankar, Uma > > Subject: Re: [RFC v3 1/2] drm/i915/dg1: Adjust the AUDIO power domain > > On Tue, Jun 01, 2021 at 03:32:27PM +0530, Anshuman Gupta wrote: > > DG1 and XE_PLD platforms has Audio MMIO/VERBS lies in PG0 power well. > > Adjusting the power domain accordingly to POWER_DOMAIN_AUDIO_VERBS > for > > audio detection and POWER_DOMAIN_AUDIO for audio playback. > > > > Cc: Ville Syrjälä > > Cc: Kai Vehmanen > > Cc: Uma Shankar > > Cc: Imre Deak > > Signed-off-by: Anshuman Gupta > > --- > > .../drm/i915/display/intel_display_power.c| 382 +- > > .../drm/i915/display/intel_display_power.h| 1 + > > 2 files changed, 382 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > > b/drivers/gpu/drm/i915/display/intel_display_power.c > > index 2f7d1664c473..da5894138e8b 100644 > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > > @@ -106,6 +106,8 @@ intel_display_power_domain_str(enum > intel_display_power_domain domain) > > return "PORT_OTHER"; > > case POWER_DOMAIN_VGA: > > return "VGA"; > > + case POWER_DOMAIN_AUDIO_VERBS: > > + return "AUDIO_VERBS"; > > Maybe better named AUDIO_MMIO, as VERBS are a subset of that imo. > > > case POWER_DOMAIN_AUDIO: > > return "AUDIO"; > > Let's also rename this to AUDIO_PLAYBACK for clarity. > > > case POWER_DOMAIN_AUX_A: > > @@ -2499,6 +2501,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_PORT_DSI) |\ > > BIT_ULL(POWER_DOMAIN_PORT_CRT) |\ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_AUX_B) | \ > > BIT_ULL(POWER_DOMAIN_AUX_C) | \ > > @@ -2549,6 +2552,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\ > > BIT_ULL(POWER_DOMAIN_PORT_DSI) |\ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_AUX_B) | \ > > BIT_ULL(POWER_DOMAIN_AUX_C) | \ > > @@ -2582,6 +2586,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\ > > BIT_ULL(POWER_DOMAIN_PORT_CRT) | /* DDI E */\ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_INIT)) > > > > @@ -2598,6 +2603,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\ > > BIT_ULL(POWER_DOMAIN_PORT_CRT) | /* DDI E */\ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_INIT)) > > > > @@ -2616,6 +2622,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_AUX_B) | \ > > BIT_ULL(POWER_DOMAIN_AUX_C) | \ > > BIT_ULL(POWER_DOMAIN_AUX_D) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > > BIT_ULL(POWER_DOMAIN_INIT)) > > @@ -2651,6 +2658,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\ > > BIT_ULL(POWER_DOMAIN_AUX_B) | \ > > BIT_ULL(POWER_DOMAIN_AUX_C) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > > BIT_ULL(POWER_DOMAIN_INIT)) > > @@ -2684,6 +2692,7 @@ intel_display_power_put_mask_in_set(struct > drm_i915_private *i915, > > BIT_ULL(POWER_DOMAIN_PORT_DDI_C_LANES) |\ > > BIT_ULL(POWER_DOMAIN_AUX_B) | \ > > BIT_ULL(POWER_DOMAIN_AUX_C) | \ > > + BIT_ULL(POWER_DOMAIN_AUDIO_VERBS) | \ > > BIT_ULL(POWER_DOMAIN_AUDIO) | \ > > BIT_ULL(POWER_DOMAIN_VGA) | \ > >
Re: [Intel-gfx] [PATCH 04/21] drm/i915/xelpd: Define Degamma Lut range struct for HDR planes
> -Original Message-
> From: dri-devel On Behalf Of Harry
> Wentland
> Sent: Monday, June 28, 2021 8:45 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash
> Subject: Re: [PATCH 04/21] drm/i915/xelpd: Define Degamma Lut range struct for
> HDR planes
>
> On 2021-06-01 6:52 a.m., Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective structure
> > for the HDR planes.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_color.c | 52
> > ++
> > 1 file changed, 52 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> > b/drivers/gpu/drm/i915/display/intel_color.c
> > index dab892d2251b..c735d06a6b54 100644
> > --- a/drivers/gpu/drm/i915/display/intel_color.c
> > +++ b/drivers/gpu/drm/i915/display/intel_color.c
> > @@ -2093,6 +2093,58 @@ static void icl_read_luts(struct intel_crtc_state
> *crtc_state)
> > }
> > }
> >
> > + /* FIXME input bpc? */
> > +__maybe_unused
> > +static const struct drm_color_lut_range d13_degamma_hdr[] = {
> > + /* segment 1 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
>
> Why are these using DRM_MODE_LUT_GAMMA and not
> DRM_MODE_LUT_DEGAMMA when the lut_type for this LUT is
> LUT_TYPE_DEGAMMA?
Thanks Harry for the comments.
Yeah this is an oversight, will fix this.
>
>
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 128,
> > + .input_bpc = 24, .output_bpc = 16,
>
> Why do we need more than 16 bpc for LUT? FP16 is enough to represent HDR in
> linear space. Wouldn't 16 bpc be enough?
Pipe sometimes works internally on higher precision (just to take care of
rounding etc.), later the
extra data gets dropped at the end of the pipe. So from source side you are
right, 16bpc is enough
but the lut precision can go higher.
>
> > + .start = 0, .end = (1 << 24) - 1,
> > + .min = 0, .max = (1 << 24) - 1,
> > + },
> > + /* segment 2 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = (1 << 24) - 1, .end = 1 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
>
> How can max be 1 << 27 if input_bpc is 24?
This is to take care of > 1.0 section. 1.0 to 3.0 and 3.0 to 7.0.
So we have 3.24 format for Lut to take care of this.
Also, I have an action to update the series with UAPI doc and new naming for
the property.
My apologies for being late on that one. Will update and send that out soon.
Thanks & Regards,
Uma Shankar
>
> Harry
>
> > + },
> > + /* Segment 3 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 1 << 24, .end = 3 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > + /* Segment 4 */
> > + {
> > + .flags = (DRM_MODE_LUT_GAMMA |
> > + DRM_MODE_LUT_REFLECT_NEGATIVE |
> > + DRM_MODE_LUT_INTERPOLATE |
> > + DRM_MODE_LUT_REUSE_LAST |
> > + DRM_MODE_LUT_NON_DECREASING),
> > + .count = 1,
> > + .input_bpc = 24, .output_bpc = 16,
> > + .start = 3 << 24, .end = 7 << 24,
> > + .min = 0, .max = (1 << 27) - 1,
> > + },
> > +};
> > +
> > void intel_color_init(struct intel_crtc *crtc)
> > {
> > struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2] drm/i915: Tweaked Wa_14010685332 for all PCHs
> dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
> despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
> state.
>
> The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked
> Wa_14010685332 sequence for every PCH since PCH_CNP.
>
> v2:
> - removed RKL from comment and simplified condition. [Rodrigo]
>
> Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on
> gen11 platforms") Cc: Matt Roper
> Cc: Rodrigo Vivi
> Cc: Imre Deak
> Signed-off-by: Anshuman Gupta
> ---
>
> .../drm/i915/display/intel_display_power.c| 16 +++---
> drivers/gpu/drm/i915/i915_irq.c | 21 ---
> 2 files changed, 8 insertions(+), 29 deletions(-)
Hi,
I didn't see this patch shown in mainline kernel tree, nor in drm-tip,
May I know what the patch's status now?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Use the correct IRQ during resume
On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
> The code in xcs_resume() probably didn't work as intended. It uses
> struct drm_device.irq, which is allocated to 0, but never initialized
> by i915 to the device's interrupt number.
>
> v3:
> * also use intel_synchronize_hardirq() at another callsite
> v2:
> * wrap irq code in intel_synchronize_hardirq() (Ville)
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Joonas Lahtinen
> Cc: Maarten Lankhorst
> Cc: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 5 +
> drivers/gpu/drm/i915/i915_irq.h | 1 +
> 4 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 88694822716a..5ca3d1664335 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1229,7 +1229,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> *engine)
> return true;
>
> /* Waiting to drain ELSP? */
> - synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
> + intel_synchronize_hardirq(engine->i915);
> intel_engine_flush_submission(engine);
>
> /* ELSP is empty, but there are ready requests? E.g. after reset */
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 5d42a12ef3d6..1b5a22a83db6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -185,7 +185,7 @@ static int xcs_resume(struct intel_engine_cs *engine)
>ring->head, ring->tail);
>
> /* Double check the ring is empty & disabled before we resume */
> - synchronize_hardirq(engine->i915->drm.irq);
> + intel_synchronize_hardirq(engine->i915);
> if (!stop_ring(engine))
> goto err;
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 7d0ce8b9f8ed..2203dca19895 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4575,3 +4575,8 @@ void intel_synchronize_irq(struct drm_i915_private
> *i915)
> {
> synchronize_irq(to_pci_dev(i915->drm.dev)->irq);
> }
> +
> +void intel_synchronize_hardirq(struct drm_i915_private *i915)
> +{
> + synchronize_hardirq(to_pci_dev(i915->drm.dev)->irq);
I honestly think the hardirq here is about as much cargo-culted as using
the wrong irq number.
I'd just use intel_synchronize_irq in both places and see whether CI
complains, then go with that.
-Daniel
> +}
> diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
> index db34d5dbe402..e43b6734f21b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.h
> +++ b/drivers/gpu/drm/i915/i915_irq.h
> @@ -94,6 +94,7 @@ void intel_runtime_pm_disable_interrupts(struct
> drm_i915_private *dev_priv);
> void intel_runtime_pm_enable_interrupts(struct drm_i915_private *dev_priv);
> bool intel_irqs_enabled(struct drm_i915_private *dev_priv);
> void intel_synchronize_irq(struct drm_i915_private *i915);
> +void intel_synchronize_hardirq(struct drm_i915_private *i915);
>
> int intel_get_crtc_scanline(struct intel_crtc *crtc);
> void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Drop all references to DRM IRQ midlayer
On Wed, Jun 30, 2021 at 11:52:28AM +0200, Thomas Zimmermann wrote:
> Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
> functions directly.
>
> v2:
> * also remove an outdated comment
> * move IRQ fix into separate patch
> * update Fixes tag (Daniel)
>
> Signed-off-by: Thomas Zimmermann
> Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
> Cc: Ville Syrjälä
> Cc: Chris Wilson
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v5.4+
> ---
> drivers/gpu/drm/i915/i915_drv.c | 1 -
> drivers/gpu/drm/i915/i915_irq.c | 5 -
> 2 files changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 850b499c71c8..73de45472f60 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -42,7 +42,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 2203dca19895..1d4c683c9de9 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -33,7 +33,6 @@
> #include
>
> #include
> -#include
>
> #include "display/intel_de.h"
> #include "display/intel_display_types.h"
> @@ -4564,10 +4563,6 @@ void intel_runtime_pm_enable_interrupts(struct
> drm_i915_private *dev_priv)
>
> bool intel_irqs_enabled(struct drm_i915_private *dev_priv)
> {
> - /*
> - * We only use drm_irq_uninstall() at unload and VT switch, so
> - * this is the only thing we need to check.
> - */
> return dev_priv->runtime_pm.irqs_enabled;
> }
>
> --
> 2.32.0
>
How is this a stable-kernel-related fix?
thanks,
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
On Tue, 29 Jun 2021, Rodrigo Vivi wrote: > Hi Dave and Daniel, > > Here goes drm-intel-next-fixes-2021-06-29: > > The biggest fix is the restoration of mmap ioctl for gen12 integrated parts > which lack was breaking ADL-P with media stack. > Besides that a small selftest fix and a theoretical overflow on > i915->pipe_to_crtc_mapping. My last fixes pull for v5.13 fell between the cracks [1]. There was one stable worthy fix, but since it was still in drm-intel-fixes when you ran dim cherry-pick-next-fixes, it was skipped for drm-intel-next-fixes. I've now dropped the commit and pushed v5.13 to drm-intel-fixes, as we're past that point. Subsequent dim cherry-pick-next-fixes should pick it up now. Please do another next fixes pull request with that. (It's okay to pull this one already though, doesn't make a difference.) BR, Jani. [1] https://lore.kernel.org/r/87czsbu15r@intel.com > > Thanks, > Rodrigo. > > The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2: > > Merge tag 'exynos-drm-next-for-v5.14' of > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into > drm-next (2021-06-11 14:19:12 +1000) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel > tags/drm-intel-next-fixes-2021-06-29 > > for you to fetch changes up to c90c4c6574f3feaf2203b5671db1907a1e15c653: > > drm/i915: Reinstate the mmap ioctl for some platforms (2021-06-28 07:43:56 > -0400) > > > The biggest fix is the restoration of mmap ioctl for gen12 integrated parts > which lack was breaking ADL-P with media stack. > Besides that a small selftest fix and a theoretical overflow on > i915->pipe_to_crtc_mapping. > > > Chris Wilson (1): > drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable > > Jani Nikula (1): > drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary crtc > > Thomas Hellström (1): > drm/i915: Reinstate the mmap ioctl for some platforms > > drivers/gpu/drm/i915/display/intel_display.c | 7 ++- > drivers/gpu/drm/i915/display/intel_display_types.h | 8 > drivers/gpu/drm/i915/display/intel_vdsc.c | 40 +++- > drivers/gpu/drm/i915/display/intel_vdsc.h | 1 + > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +-- > drivers/gpu/drm/i915/gt/selftest_execlists.c | 55 > +- > 6 files changed, 76 insertions(+), 42 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915: Use the correct IRQ during resume
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
v3:
* also use intel_synchronize_hardirq() at another callsite
v2:
* wrap irq code in intel_synchronize_hardirq() (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 5 +
drivers/gpu/drm/i915/i915_irq.h | 1 +
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 88694822716a..5ca3d1664335 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1229,7 +1229,7 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
return true;
/* Waiting to drain ELSP? */
- synchronize_hardirq(to_pci_dev(engine->i915->drm.dev)->irq);
+ intel_synchronize_hardirq(engine->i915);
intel_engine_flush_submission(engine);
/* ELSP is empty, but there are ready requests? E.g. after reset */
diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index 5d42a12ef3d6..1b5a22a83db6 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -185,7 +185,7 @@ static int xcs_resume(struct intel_engine_cs *engine)
ring->head, ring->tail);
/* Double check the ring is empty & disabled before we resume */
- synchronize_hardirq(engine->i915->drm.irq);
+ intel_synchronize_hardirq(engine->i915);
if (!stop_ring(engine))
goto err;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7d0ce8b9f8ed..2203dca19895 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4575,3 +4575,8 @@ void intel_synchronize_irq(struct drm_i915_private *i915)
{
synchronize_irq(to_pci_dev(i915->drm.dev)->irq);
}
+
+void intel_synchronize_hardirq(struct drm_i915_private *i915)
+{
+ synchronize_hardirq(to_pci_dev(i915->drm.dev)->irq);
+}
diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h
index db34d5dbe402..e43b6734f21b 100644
--- a/drivers/gpu/drm/i915/i915_irq.h
+++ b/drivers/gpu/drm/i915/i915_irq.h
@@ -94,6 +94,7 @@ void intel_runtime_pm_disable_interrupts(struct
drm_i915_private *dev_priv);
void intel_runtime_pm_enable_interrupts(struct drm_i915_private *dev_priv);
bool intel_irqs_enabled(struct drm_i915_private *dev_priv);
void intel_synchronize_irq(struct drm_i915_private *i915);
+void intel_synchronize_hardirq(struct drm_i915_private *i915);
int intel_get_crtc_scanline(struct intel_crtc *crtc);
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915: Drop all references to DRM IRQ midlayer
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs")
Cc: Ville Syrjälä
Cc: Chris Wilson
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: # v5.4+
---
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_irq.c | 5 -
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 850b499c71c8..73de45472f60 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -42,7 +42,6 @@
#include
#include
#include
-#include
#include
#include
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2203dca19895..1d4c683c9de9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -33,7 +33,6 @@
#include
#include
-#include
#include "display/intel_de.h"
#include "display/intel_display_types.h"
@@ -4564,10 +4563,6 @@ void intel_runtime_pm_enable_interrupts(struct
drm_i915_private *dev_priv)
bool intel_irqs_enabled(struct drm_i915_private *dev_priv)
{
- /*
-* We only use drm_irq_uninstall() at unload and VT switch, so
-* this is the only thing we need to check.
-*/
return dev_priv->runtime_pm.irqs_enabled;
}
--
2.32.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/2] drm/i915: IRQ fixes
Fix a bug in the usage of IRQs and cleanup references to the DRM IRQ midlayer. Preferably this patchset would be merged through drm-misc-next. v3: * also use intel_synchronize_hardirq() from other callsite v2: * split patch * also fix comment * add intel_synchronize_hardirq() (Ville) * update Fixes tag (Daniel) Thomas Zimmermann (2): drm/i915: Use the correct IRQ during resume drm/i915: Drop all references to DRM IRQ midlayer drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 1 - drivers/gpu/drm/i915/i915_irq.c | 10 +- drivers/gpu/drm/i915/i915_irq.h | 1 + 5 files changed, 8 insertions(+), 8 deletions(-) base-commit: 67f5a18128770817e4218a9e496d2bf5047c51e8 -- 2.32.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
