[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dsi: Dont forget to clean up the connector on error
== Series Details ==
Series: drm/i915/dsi: Dont forget to clean up the connector on error
URL : https://patchwork.freedesktop.org/series/77011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8439_full -> Patchwork_17596_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17596_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_params@invalid-bsd-ring:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-iclb1/igt@gem_exec_par...@invalid-bsd-ring.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-iclb6/igt@gem_exec_par...@invalid-bsd-ring.html
* igt@gem_workarounds@suspend-resume:
- shard-glk: [PASS][3] -> [INCOMPLETE][4] ([i915#58] /
[k.org#198133])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-glk9/igt@gem_workarou...@suspend-resume.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-glk1/igt@gem_workarou...@suspend-resume.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-iclb6/igt@i915_pm...@dc6-psr.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-iclb2/igt@i915_pm...@dc6-psr.html
* igt@kms_cursor_legacy@pipe-c-torture-bo:
- shard-iclb: [PASS][7] -> [DMESG-WARN][8] ([i915#128])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-iclb5/igt@kms_cursor_leg...@pipe-c-torture-bo.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-iclb5/igt@kms_cursor_leg...@pipe-c-torture-bo.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +1 similar
issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-kbl2/igt@kms_...@bpc-switch-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-kbl1/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265])
+1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@suspend:
- shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-skl5/igt@kms_...@suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-skl7/igt@kms_...@suspend.html
Possible fixes
* igt@i915_pm_dc@dc6-psr:
- shard-skl: [FAIL][15] ([i915#454]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-skl7/igt@i915_pm...@dc6-psr.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-skl8/igt@i915_pm...@dc6-psr.html
* igt@i915_pm_rpm@system-suspend:
- shard-skl: [INCOMPLETE][17] ([i915#151] / [i915#69]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-skl2/igt@i915_pm_...@system-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-skl9/igt@i915_pm_...@system-suspend.html
* igt@kms_cursor_crc@pipe-a-cursor-64x64-random:
- shard-apl: [FAIL][19] ([i915#54]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html
* {igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2}:
- shard-glk: [FAIL][21] ([i915#79]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-glk2/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
* {igt@kms_flip@flip-vs-suspend-interruptible@b-dp1}:
- shard-apl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/shard-apl8/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@b-dp1.html
* {igt@kms_flip@flip-vs-suspend-interruptible@c-edp1}:
- shard-skl: [INCOMPLETE][25] ([i915#198]) -> [PASS][26]
[25]:
[Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
WARNING: modpost: missing MODULE_LICENSE() in
drivers/gpu/drm/panel/panel-visionox-rm69299.o
see include/linux/module.h for more information
Introduced by commit
c7f66d32dd43 ("drm/panel: add support for rm69299 visionox panel")
--
Cheers,
Stephen Rothwell
pgpGRz0YJkcys.pgp
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 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Hi Mika, > -Original Message- > From: Mika Kuoppala > Sent: Thursday, May 7, 2020 12:53 AM > To: intel-gfx@lists.freedesktop.org > Cc: Mika Kuoppala ; Chris Wilson > ; Liu, Chuansheng ; > Antognolli, Rafael ; Shi, Yang A > > Subject: [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly > > Aux table invalidation can fail on update. So > next access may cause memory access to be into stale entry. > > Proposed workaround is to invalidate entries between > all batchbuffers. Thanks for cooking this patch for RCS engine. Similar way applies to all the engines. Expecting more patches. VD0_CCS_AUX_NV 04218h VD1_CCS_AUX_NV 04228h VE0_CCS_AUX_NV 04238h VD2_CCS_AUX_NV 04298h VD3_CCS_AUX_NV 042A8h VE1_CCS_AUX_NV 042B8h COMPCS0_CCS_AUX_NV 042C8h GFX_CCS_AUX_NV 04208h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/display/intel_fbc.c
between commit:
82152d424b6c ("Make the "Reducing compressed framebufer size" message be
DRM_INFO_ONCE()")
from the drm-intel-fixes tree and commit:
97ed48b5c8b1 ("drm/i915/fbc: convert to drm_device based logging macros.")
from the drm tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/display/intel_fbc.c
index c125ca9ab9b3,56bcd6c52a02..
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@@ -485,7 -485,9 +485,8 @@@ static int intel_fbc_alloc_cfb(struct d
if (!ret)
goto err_llb;
else if (ret > 1) {
- DRM_INFO_ONCE("Reducing the compressed framebuffer size. This
may lead to less power savings than a non-reduced-size. Try to increase stolen
memory size if available in BIOS.\n");
- drm_info(_priv->drm,
++ drm_info_once(_priv->drm,
+"Reducing the compressed framebuffer size. This may
lead to less power savings than a non-reduced-size. Try to increase stolen
memory size if available in BIOS.\n");
-
}
fbc->threshold = ret;
pgpQpR7_xmp2C.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce Rocket Lake (rev5)
== Series Details ==
Series: Introduce Rocket Lake (rev5)
URL : https://patchwork.freedesktop.org/series/76826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8438_full -> Patchwork_17595_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17595_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-kbl7/igt@gem_workarou...@suspend-resume-fd.html
* igt@gen9_exec_parse@allowed-all:
- shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] /
[i915#716])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-kbl4/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-kbl4/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#300])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-skl9/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html
* igt@kms_cursor_edge_walk@pipe-a-256x256-top-edge:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#70] / [i915#93] /
[i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-kbl3/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-kbl1/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw: [PASS][11] -> [FAIL][12] ([i915#57])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-hsw2/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html
* igt@kms_frontbuffer_tracking@fbc-suspend:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180] /
[i915#93] / [i915#95]) +1 similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#1188])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-skl1/igt@kms_...@bpc-switch-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-skl8/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-iclb2/igt@kms_psr2...@frontbuffer.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-iclb3/igt@kms_psr2...@frontbuffer.html
* igt@kms_psr@psr2_primary_mmap_cpu:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-iclb2/igt@kms_psr@psr2_primary_mmap_cpu.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-iclb4/igt@kms_psr@psr2_primary_mmap_cpu.html
Possible fixes
* igt@kms_cursor_legacy@pipe-c-torture-move:
- shard-hsw: [DMESG-WARN][23] ([i915#128]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-hsw1/igt@kms_cursor_leg...@pipe-c-torture-move.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/shard-hsw7/igt@kms_cursor_leg...@pipe-c-torture-move.html
* {igt@kms_flip@flip-vs-suspend@b-hdmi-a1}:
- shard-hsw: [INCOMPLETE][25] ([i915#61]) -> [PASS][26]
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: Dont forget to clean up the connector on error
== Series Details == Series: drm/i915/dsi: Dont forget to clean up the connector on error URL : https://patchwork.freedesktop.org/series/77011/ State : success == Summary == CI Bug Log - changes from CI_DRM_8439 -> Patchwork_17596 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/index.html Known issues Here are the changes found in Patchwork_17596 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [PASS][1] -> [FAIL][2] ([i915#262]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8439/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8439 -> Patchwork_17596 CI-20190529: 20190529 CI_DRM_8439: d9cb80101890e2d5a63e10456b53363ca460bb98 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5636: d5b673234f37b578a798d75f59be9d4afa1fb436 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17596: 4f32ecc78aec392a168dfdce910fa030b9a1ef10 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4f32ecc78aec drm/i915/dsi: Dont forget to clean up the connector on error == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17596/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 series starting with [01/15] drm/i915: Mark concurrent submissions with a weak-dependency
== Series Details ==
Series: series starting with [01/15] drm/i915: Mark concurrent submissions with
a weak-dependency
URL : https://patchwork.freedesktop.org/series/77008/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8438_full -> Patchwork_17594_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17594_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17594_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_17594_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_whisper@basic-queues-forked-all:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-iclb3/igt@gem_exec_whis...@basic-queues-forked-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-iclb8/igt@gem_exec_whis...@basic-queues-forked-all.html
* igt@i915_pm_rpm@drm-resources-equal:
- shard-hsw: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-hsw7/igt@i915_pm_...@drm-resources-equal.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-hsw7/igt@i915_pm_...@drm-resources-equal.html
* igt@perf@oa-exponents:
- shard-apl: [PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-apl1/igt@p...@oa-exponents.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-apl8/igt@p...@oa-exponents.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_fence@syncobj-invalid-wait}:
- shard-snb: [PASS][7] -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-snb1/igt@gem_exec_fe...@syncobj-invalid-wait.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-snb2/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-tglb: [PASS][9] -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-tglb1/igt@gem_exec_fe...@syncobj-invalid-wait.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-tglb7/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-skl: [PASS][11] -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-skl4/igt@gem_exec_fe...@syncobj-invalid-wait.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-skl4/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-glk: [PASS][13] -> [FAIL][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-glk2/igt@gem_exec_fe...@syncobj-invalid-wait.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-glk4/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-apl: [PASS][15] -> [FAIL][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-apl1/igt@gem_exec_fe...@syncobj-invalid-wait.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-apl1/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-kbl: [PASS][17] -> [FAIL][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-kbl7/igt@gem_exec_fe...@syncobj-invalid-wait.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-kbl6/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-iclb: [PASS][19] -> [FAIL][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-iclb6/igt@gem_exec_fe...@syncobj-invalid-wait.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-iclb1/igt@gem_exec_fe...@syncobj-invalid-wait.html
- shard-hsw: [PASS][21] -> [FAIL][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-hsw6/igt@gem_exec_fe...@syncobj-invalid-wait.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/shard-hsw1/igt@gem_exec_fe...@syncobj-invalid-wait.html
New tests
-
New tests have been introduced between CI_DRM_8438_full and
Patchwork_17594_full:
### New IGT tests (1) ###
* igt@dmabuf@all@dma_fence_proxy:
- Statuses : 8 pass(s)
- Exec time: [0.03, 0.10] s
Known issues
Here are the changes found in Patchwork_17594_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_softpin@noreloc-s3:
- shard-kbl: [PASS][23] -> [DMESG-WARN][24] ([i915#180])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/shard-kbl4/igt@gem_soft...@noreloc-s3.html
[24]:
[Intel-gfx] [PATCH] drm/i915/dsi: Dont forget to clean up the connector on error
During the DSI initialization setup, after instantiating the relevant drm connector and encoder objects, the connector also needs to be cleaned up along with the encoder if an error is encountered. The error can happen due to a missing mode in the VBT or for other reasons. Signed-off-by: Vivek Kasireddy --- drivers/gpu/drm/i915/display/icl_dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c b/drivers/gpu/drm/i915/display/icl_dsi.c index 4fec5bd64920..f93f72463df5 100644 --- a/drivers/gpu/drm/i915/display/icl_dsi.c +++ b/drivers/gpu/drm/i915/display/icl_dsi.c @@ -1954,6 +1954,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv) return; err: + drm_connector_cleanup(connector); drm_encoder_cleanup(>base); kfree(intel_dsi); kfree(intel_connector); -- 2.21.1 ___ 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: Mark concurrent submissions with a weak-dependency
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
across submit fences").
The bot has tested the following trees: v5.6.10.
v5.6.10: Failed to apply! Possible dependencies:
8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children on
unhold")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Mark concurrent submissions with a weak-dependency
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags
across submit fences").
The bot has tested the following trees: v5.6.10.
v5.6.10: Failed to apply! Possible dependencies:
8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children on
unhold")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" (rev3)
== Series Details == Series: series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" (rev3) URL : https://patchwork.freedesktop.org/series/77000/ State : success == Summary == CI Bug Log - changes from CI_DRM_8437_full -> Patchwork_17592_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17592_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-skl5/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-kbl3/igt@i915_susp...@fence-restore-tiled2untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-kbl2/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_edge_walk@pipe-a-256x256-top-edge: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#70] / [i915#93] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-kbl6/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-kbl4/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][7] -> [FAIL][8] ([i915#96]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109349]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@fill-fb: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-apl2/igt@kms_draw_...@fill-fb.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-apl3/igt@kms_draw_...@fill-fb.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#69]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-skl3/igt@kms_fbcon_...@psr-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-skl9/igt@kms_fbcon_...@psr-suspend.html * igt@kms_hdr@bpc-switch-dpms: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#1188]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-skl3/igt@kms_...@bpc-switch-dpms.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-skl5/igt@kms_...@bpc-switch-dpms.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180] / [i915#93] / [i915#95]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [i915#265]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_cursor_plane_move: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-iclb8/igt@kms_psr@psr2_cursor_plane_move.html * igt@kms_setmode@basic: - shard-kbl: [PASS][23] -> [FAIL][24] ([i915#31]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/shard-kbl6/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/shard-kbl4/igt@kms_setm...@basic.html Possible fixes * igt@i915_suspend@sysfs-reader: - shard-apl:
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce Rocket Lake (rev5)
== Series Details == Series: Introduce Rocket Lake (rev5) URL : https://patchwork.freedesktop.org/series/76826/ State : success == Summary == CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17595 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/index.html Known issues Here are the changes found in Patchwork_17595 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [SKIP][1] ([fdo#109271]) -> [FAIL][2] ([i915#579]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 Participating hosts (51 -> 44) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8438 -> Patchwork_17595 CI-20190529: 20190529 CI_DRM_8438: 9463611ee93f4b254044b8b2467a1e81f942ad01 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5635: e83abfca61d407d12eee4d25bb0e8686337a7791 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17595: a956d64b89965d60f21052c98e2383108c95d17f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a956d64b8996 drm/i915/rkl: Add initial workarounds b71b6be89206 drm/i915/rkl: Disable PSR2 a31143c0e350 drm/i915/rkl: Handle HTI 0728f1c7d53c drm/i915/rkl: Add DPLL4 support f53b5ed86243 drm/i915/rkl: Handle comp master/slave relationships for PHYs 01eeaee24e99 drm/i915/rkl: Don't try to read out DSI transcoders 907417b5599f drm/i915/rkl: Don't try to access transcoder D 06afd0a313fb drm/i915/rkl: Add DDC pin mapping c3f23b36db92 drm/i915/rkl: provide port/phy mapping for vbt aa69de72e7ad drm/i915/rkl: Setup ports/phys ffcedfb908db drm/i915/rkl: Check proper SDEISR bits for TC1 and TC2 outputs cbc732494a17 drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout c601db6a20fd drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B 58ad52c714dd drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2 d2f8442de5ae drm/i915/rkl: Add power well support baec83a0ef12 drm/i915/rkl: Limit number of universal planes to 5 79d1afd4876a drm/i915/rkl: Update memory bandwidth parameters a828a46df1e1 drm/i915/rkl: Add PCH support 5077d28b310e drm/i915/rkl: Load DMC firmware for Rocket Lake 294ed2fa7047 drm/i915/rkl: Re-use TGL GuC/HuC firmware 15e40d80e929 x86/gpu: add RKL stolen memory support 992fe0e5bf6f drm/i915/rkl: Add RKL platform info and PCI ids == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17595/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 4/6] drm/i915/gt: Switch to manual evaluation of RPS
On Wed, May 06, 2020 at 06:17:28PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2020-05-06 16:55:07)
> > Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> > > Btw, there are other patches on the list of failed cherry-picks:
> > >
> > > 614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
> > > unbind")
> >
> > We need that to fix a deadlock.
> >
> > > c4e8ba739034 ("drm/i915/gt: Yield the timeslice if caught waiting on a
> > > user semaphore")
> >
> > That to behave nicely with VkEvents.
> >
> > > a95f3ac21d64 ("drm/i915/gem: Remove object_is_locked assertion from
> > > unpin_from_display_plane")
> >
> > And that's a potential bug in 5.7, so needs fixing.
> >
> > > 2632f174a2e1 ("drm/i915/execlists: Avoid reusing the same logical CCID")
> > > 5c4a53e3b1cb ("drm/i915/execlists: Track inflight CCID")
> >
> > We probably need these based on our presumption of how the HW might
> > work.
> > >
> > > do you have any updated ickle/dif branch available?
> >
> > Will do.
>
> To ssh://people.freedesktop.org/~ickle/linux-2.6
> + f98e2df61ab3...134711240307 dif -> dif (forced update)
Thanks a lot for all the details and the ports.
Pushed to dif
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce Rocket Lake (rev5)
== Series Details ==
Series: Introduce Rocket Lake (rev5)
URL : https://patchwork.freedesktop.org/series/76826/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
992fe0e5bf6f drm/i915/rkl: Add RKL platform info and PCI ids
-:35: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible side-effects?
#35: FILE: drivers/gpu/drm/i915/i915_drv.h:1522:
+#define IS_RKL_REVID(p, since, until) \
+ (IS_ROCKETLAKE(p) && IS_REVID(p, since, until))
-:102: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#102: FILE: include/drm/i915_pciids.h:609:
+#define INTEL_RKL_IDS(info) \
+ INTEL_VGA_DEVICE(0x4C80, info), \
+ INTEL_VGA_DEVICE(0x4C8A, info), \
+ INTEL_VGA_DEVICE(0x4C8B, info), \
+ INTEL_VGA_DEVICE(0x4C8C, info), \
+ INTEL_VGA_DEVICE(0x4C90, info), \
+ INTEL_VGA_DEVICE(0x4C9A, info)
-:102: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'info' - possible
side-effects?
#102: FILE: include/drm/i915_pciids.h:609:
+#define INTEL_RKL_IDS(info) \
+ INTEL_VGA_DEVICE(0x4C80, info), \
+ INTEL_VGA_DEVICE(0x4C8A, info), \
+ INTEL_VGA_DEVICE(0x4C8B, info), \
+ INTEL_VGA_DEVICE(0x4C8C, info), \
+ INTEL_VGA_DEVICE(0x4C90, info), \
+ INTEL_VGA_DEVICE(0x4C9A, info)
total: 1 errors, 0 warnings, 2 checks, 69 lines checked
15e40d80e929 x86/gpu: add RKL stolen memory support
294ed2fa7047 drm/i915/rkl: Re-use TGL GuC/HuC firmware
5077d28b310e drm/i915/rkl: Load DMC firmware for Rocket Lake
a828a46df1e1 drm/i915/rkl: Add PCH support
79d1afd4876a drm/i915/rkl: Update memory bandwidth parameters
baec83a0ef12 drm/i915/rkl: Limit number of universal planes to 5
d2f8442de5ae drm/i915/rkl: Add power well support
58ad52c714dd drm/i915/rkl: Program BW_BUDDY0 registers instead of BW_BUDDY1/2
-:36: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#36: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:5261:
+ min_buddy = max_buddy = 0;
total: 0 errors, 0 warnings, 1 checks, 84 lines checked
c601db6a20fd drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B
cbc732494a17 drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
ffcedfb908db drm/i915/rkl: Check proper SDEISR bits for TC1 and TC2 outputs
aa69de72e7ad drm/i915/rkl: Setup ports/phys
c3f23b36db92 drm/i915/rkl: provide port/phy mapping for vbt
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
[drm:intel_dp_init_connector [i915]] Adding DP connector on [ENCODER:275:DDI A]
total: 0 errors, 1 warnings, 0 checks, 104 lines checked
06afd0a313fb drm/i915/rkl: Add DDC pin mapping
907417b5599f drm/i915/rkl: Don't try to access transcoder D
01eeaee24e99 drm/i915/rkl: Don't try to read out DSI transcoders
f53b5ed86243 drm/i915/rkl: Handle comp master/slave relationships for PHYs
0728f1c7d53c drm/i915/rkl: Add DPLL4 support
a31143c0e350 drm/i915/rkl: Handle HTI
-:92: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#92: FILE: drivers/gpu/drm/i915/display/intel_dpll_mgr.c:274:
+{
+
-:154: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#154: FILE: drivers/gpu/drm/i915/i915_reg.h:2903:
+#define HDPORT_PHY_USED_DP(phy) REG_BIT(2*phy + 2)
^
-:154: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'phy' may be better as
'(phy)' to avoid precedence issues
#154: FILE: drivers/gpu/drm/i915/i915_reg.h:2903:
+#define HDPORT_PHY_USED_DP(phy) REG_BIT(2*phy + 2)
-:155: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#155: FILE: drivers/gpu/drm/i915/i915_reg.h:2904:
+#define HDPORT_PHY_USED_HDMI(phy)REG_BIT(2*phy + 1)
^
-:155: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'phy' may be better as
'(phy)' to avoid precedence issues
#155: FILE: drivers/gpu/drm/i915/i915_reg.h:2904:
+#define HDPORT_PHY_USED_HDMI(phy)REG_BIT(2*phy + 1)
total: 0 errors, 0 warnings, 5 checks, 116 lines checked
b71b6be89206 drm/i915/rkl: Disable PSR2
a956d64b8996 drm/i915/rkl: Add initial workarounds
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/15] drm/i915: Mark concurrent submissions with a weak-dependency
== Series Details == Series: series starting with [01/15] drm/i915: Mark concurrent submissions with a weak-dependency URL : https://patchwork.freedesktop.org/series/77008/ State : success == Summary == CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17594 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/index.html New tests - New tests have been introduced between CI_DRM_8438 and Patchwork_17594: ### New IGT tests (1) ### * igt@dmabuf@all@dma_fence_proxy: - Statuses : 41 pass(s) - Exec time: [0.03, 0.11] s Changes --- No changes found Participating hosts (51 -> 44) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8438 -> Patchwork_17594 CI-20190529: 20190529 CI_DRM_8438: 9463611ee93f4b254044b8b2467a1e81f942ad01 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5635: e83abfca61d407d12eee4d25bb0e8686337a7791 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17594: 910c4873269efb99a9f1acb0b0973ef8e1f99b55 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 910c4873269e drm/i915/selftests: Always call the provided engine->emit_init_breadcrumb f6a254c43951 drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT 46923cb2289b drm/i915: Drop I915_RESET_TIMEOUT and friends 1ff0bbcd9c06 drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT 4033c2787147 drm/i915/gt: Declare when we enabled timeslicing b4a7c0a0af97 drm/i915/gem: Allow combining submit-fences with syncobj f990eeccd3d6 drm/i915/gem: Teach execbuf how to wait on future syncobj b11795efb1d4 drm/syncobj: Allow use of dma-fence-proxy 801bf6c793e9 dma-buf: Proxy fence, an unsignaled fence placeholder 85414af39de2 drm/i915: Tidy awaiting on dma-fences 64e092f0d4cc drm/i915: Prevent using semaphores to chain up to external fences 671848e2a77e drm/i915: Pull waiting on an external dma-fence into its routine 35107d053a86 drm/i915: Ignore submit-fences on the same timeline 7f4c2d9c8b7f drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing e532b66dff06 drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17594/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 series starting with [01/15] drm/i915: Mark concurrent submissions with a weak-dependency
== Series Details == Series: series starting with [01/15] drm/i915: Mark concurrent submissions with a weak-dependency URL : https://patchwork.freedesktop.org/series/77008/ State : warning == Summary == $ dim checkpatch origin/drm-tip e532b66dff06 drm/i915: Mark concurrent submissions with a weak-dependency 7f4c2d9c8b7f drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing 35107d053a86 drm/i915: Ignore submit-fences on the same timeline 671848e2a77e drm/i915: Pull waiting on an external dma-fence into its routine 64e092f0d4cc drm/i915: Prevent using semaphores to chain up to external fences 85414af39de2 drm/i915: Tidy awaiting on dma-fences 801bf6c793e9 dma-buf: Proxy fence, an unsignaled fence placeholder -:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #45: new file mode 100644 -:380: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #380: FILE: drivers/dma-buf/st-dma-fence-proxy.c:20: + spinlock_t lock; -:540: WARNING:MEMORY_BARRIER: memory barrier without comment #540: FILE: drivers/dma-buf/st-dma-fence-proxy.c:180: + smp_store_mb(container_of(cb, struct simple_cb, cb)->seen, true); total: 0 errors, 2 warnings, 1 checks, 1043 lines checked b11795efb1d4 drm/syncobj: Allow use of dma-fence-proxy f990eeccd3d6 drm/i915/gem: Teach execbuf how to wait on future syncobj b4a7c0a0af97 drm/i915/gem: Allow combining submit-fences with syncobj 4033c2787147 drm/i915/gt: Declare when we enabled timeslicing 1ff0bbcd9c06 drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT -:111: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #111: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 125 lines checked 46923cb2289b drm/i915: Drop I915_RESET_TIMEOUT and friends f6a254c43951 drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT 910c4873269e drm/i915/selftests: Always call the provided engine->emit_init_breadcrumb ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency
== Series Details == Series: series starting with [1/3] drm/i915: Mark concurrent submissions with a weak-dependency URL : https://patchwork.freedesktop.org/series/77007/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8438 -> Patchwork_17593 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17593 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17593, 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_17593/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17593: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/fi-cml-u2/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17593/fi-cml-u2/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_17593 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@active: - fi-bsw-n3050: [PASS][3] -> [DMESG-FAIL][4] ([i915#541]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8438/fi-bsw-n3050/igt@i915_selftest@l...@active.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17593/fi-bsw-n3050/igt@i915_selftest@l...@active.html [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8438 -> Patchwork_17593 CI-20190529: 20190529 CI_DRM_8438: 9463611ee93f4b254044b8b2467a1e81f942ad01 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5635: e83abfca61d407d12eee4d25bb0e8686337a7791 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17593: 8b7fb9e587b1d18572b099bb9f8d3bd82d291a00 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8b7fb9e587b1 drm/i915: Ignore submit-fences on the same timeline 05aa6d42d52e drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing 517fb2175f2a drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17593/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dgfx: avoid opregion calls and messages
Some Cc to try to get it reviewed.
Lucas De Marchi
On Fri, Mar 6, 2020 at 5:26 PM Lucas De Marchi wrote:
>
> This avoids the annoying message
> "Failed to get panel details from OpRegion (-19)" while initializing.
> On DGFX there is no access to OpRegion, so just avoid any calls related
> to it.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_opregion.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index cc6b00959586..daadad046810 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -1006,6 +1006,10 @@ intel_opregion_get_panel_type(struct drm_i915_private
> *dev_priv)
> u32 panel_details;
> int ret;
>
> + /* No access to OpRegion */
> + if (IS_DGFX(dev_priv))
> + return -ENODEV;
> +
> ret = swsci(dev_priv, SWSCI_GBDA_PANEL_DETAILS, 0x0, _details);
> if (ret) {
> drm_dbg_kms(_priv->drm,
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Lucas De Marchi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 16/22] drm/i915/rkl: Don't try to access transcoder D
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
v2: Move one transcoder check that wound up in the wrong function after
conflict resolution. It belongs in bdw_get_trans_port_sync_config
rather than bxt_get_dsi_transcoder_state.
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0ab03282c397..f93bc0661d00 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4131,6 +4131,9 @@ static void bdw_get_trans_port_sync_config(struct
intel_crtc_state *crtc_state)
enum intel_display_power_domain power_domain;
intel_wakeref_t trans_wakeref;
+ if (!HAS_TRANSCODER(dev_priv, cpu_transcoder))
+ continue;
+
power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
trans_wakeref = intel_display_power_get_if_enabled(dev_priv,
power_domain);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3c3fb9d9df62..297d4cacfb6a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2849,6 +2849,9 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
enum intel_display_power_domain domain;
+ if (!HAS_TRANSCODER(dev_priv, trans))
+ continue;
+
domain = POWER_DOMAIN_TRANSCODER(trans);
if (!intel_display_power_is_enabled(dev_priv, domain))
continue;
@@ -3397,6 +3400,9 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
enum intel_display_power_domain domain;
+ if (!HAS_TRANSCODER(dev_priv, trans))
+ continue;
+
domain = POWER_DOMAIN_TRANSCODER(trans);
if (!intel_display_power_is_enabled(dev_priv, domain))
continue;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 16/22] drm/i915/rkl: Don't try to access transcoder D
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
v2: Move one transcoder check that wound up in the wrong function after
conflict resolution. It belongs in bdw_get_trans_port_sync_config
rather than bxt_get_dsi_transcoder_state.
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
drivers/gpu/drm/i915/i915_irq.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 0ab03282c397..f93bc0661d00 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4131,6 +4131,9 @@ static void bdw_get_trans_port_sync_config(struct
intel_crtc_state *crtc_state)
enum intel_display_power_domain power_domain;
intel_wakeref_t trans_wakeref;
+ if (!HAS_TRANSCODER(dev_priv, cpu_transcoder))
+ continue;
+
power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
trans_wakeref = intel_display_power_get_if_enabled(dev_priv,
power_domain);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3c3fb9d9df62..297d4cacfb6a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2849,6 +2849,9 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
enum intel_display_power_domain domain;
+ if (!HAS_TRANSCODER(dev_priv, trans))
+ continue;
+
domain = POWER_DOMAIN_TRANSCODER(trans);
if (!intel_display_power_is_enabled(dev_priv, domain))
continue;
@@ -3397,6 +3400,9 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
enum intel_display_power_domain domain;
+ if (!HAS_TRANSCODER(dev_priv, trans))
+ continue;
+
domain = POWER_DOMAIN_TRANSCODER(trans);
if (!intel_display_power_is_enabled(dev_priv, domain))
continue;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] drm/i915/gem: Teach execbuf how to wait on future syncobj
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +
drivers/gpu/drm/i915/i915_request.c | 135 ++
drivers/gpu/drm/i915/i915_scheduler.c | 41 ++
drivers/gpu/drm/i915/i915_scheduler.h | 3 +
5 files changed, 201 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 966523a8503f..7abb96505a31 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -2524,8 +2525,24 @@ await_fence_array(struct i915_execbuffer *eb,
continue;
fence = drm_syncobj_fence_get(syncobj);
- if (!fence)
- return -EINVAL;
+ if (!fence) {
+ struct dma_fence *old;
+
+ fence = dma_fence_create_proxy();
+ if (!fence)
+ return -ENOMEM;
+
+ spin_lock(>lock);
+ old = rcu_dereference_protected(syncobj->fence, true);
+ if (unlikely(old)) {
+ dma_fence_put(fence);
+ fence = dma_fence_get(old);
+ } else {
+ rcu_assign_pointer(syncobj->fence,
+ dma_fence_get(fence));
+ }
+ spin_unlock(>lock);
+ }
err = i915_request_await_dma_fence(eb->request, fence);
dma_fence_put(fence);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3606a7946707..81e8f238f5e1 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3506,6 +3506,9 @@ static int gen8_emit_init_breadcrumb(struct i915_request
*rq)
{
u32 *cs;
+ /* Seal the semaphore section -- we are ready to begin */
+ rq->sched.semaphores |= ALL_ENGINES;
+
if (!i915_request_timeline(rq)->has_initial_breadcrumb)
return 0;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 1feb416975e1..ad3b1c3597f4 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include
#include
@@ -378,6 +379,7 @@ static bool fatal_error(int error)
case 0: /* not an error! */
case -EAGAIN: /* innocent victim of a GT reset (__i915_request_reset) */
case -ETIMEDOUT: /* waiting for Godot (timer_i915_sw_fence_wake) */
+ case -EDEADLK: /* cyclic fence lockup (await_proxy) */
return false;
default:
return true;
@@ -1101,6 +1103,137 @@ i915_request_await_external(struct i915_request *rq,
struct dma_fence *fence)
I915_FENCE_GFP);
}
+struct await_proxy {
+ struct wait_queue_entry base;
+ struct i915_request *request;
+ struct dma_fence *fence;
+ struct timer_list timer;
+ struct work_struct work;
+ int (*attach)(struct await_proxy *ap);
+ void *data;
+};
+
+static void await_proxy_work(struct work_struct *work)
+{
+ struct await_proxy *ap = container_of(work, typeof(*ap), work);
+ struct i915_request *rq = ap->request;
+
+ del_timer_sync(>timer);
+
+ if (ap->fence) {
+ int err = 0;
+
+ /*
+* If the fence is external, we impose a 10s timeout.
+* However, if the fence is internal, we skip a timeout in
+* the belief that all fences are in-order (DAG, no cycles)
+* and we can enforce forward progress by reset the GPU if
+* necessary. A future fence, provided userspace, can trivially
+* generate a cycle in the dependency graph, and so cause
+* that entire cycle to become deadlocked and for no forward
+* progress to either be made, and the driver being kept
+* eternally awake.
+*/
+ if (dma_fence_is_i915(ap->fence) &&
+ !i915_sched_node_verify_dag(>sched,
+ _request(ap->fence)->sched))
+ err = -EDEADLK;
+
+ if (!err) {
+
[Intel-gfx] [PATCH 14/15] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT
This timeout is only used in one place, to provide a tiny bit of grace
for slow igt to cleanup after themselves. If we are a bit stricter and
opt to kill outstanding requsts rather than wait, we can speed up igt by
not waiting for 200ms after a hang.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h | 2 --
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 8e98df6a3045..649acf1fc33d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1463,12 +1463,13 @@ gt_drop_caches(struct intel_gt *gt, u64 val)
{
int ret;
- if (val & DROP_RESET_ACTIVE &&
- wait_for(intel_engines_are_idle(gt), I915_IDLE_ENGINES_TIMEOUT))
- intel_gt_set_wedged(gt);
+ if (val & (DROP_RETIRE | DROP_RESET_ACTIVE))
+ intel_gt_wait_for_idle(gt, 1);
- if (val & DROP_RETIRE)
- intel_gt_retire_requests(gt);
+ if (val & DROP_RESET_ACTIVE && intel_gt_pm_get_if_awake(gt)) {
+ intel_gt_set_wedged(gt);
+ intel_gt_pm_put(gt);
+ }
if (val & (DROP_IDLE | DROP_ACTIVE)) {
ret = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad287e5d6ded..97687ea53c3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -612,8 +612,6 @@ struct i915_gem_mm {
u32 shrink_count;
};
-#define I915_IDLE_ENGINES_TIMEOUT (200) /* in ms */
-
unsigned long i915_fence_context_timeout(const struct drm_i915_private *i915,
u64 context);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915: Replace the hardcoded I915_FENCE_TIMEOUT
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig
option, primarily to allow brave systems to disable the timeout and
solely rely on correct signaling.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/Kconfig.profile | 12
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
drivers/gpu/drm/i915/gem/i915_gem_clflush.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 +--
drivers/gpu/drm/i915/gem/i915_gem_fence.c | 4 ++--
drivers/gpu/drm/i915/i915_config.c | 15 +++
drivers/gpu/drm/i915/i915_drv.h| 10 +-
drivers/gpu/drm/i915/i915_request.c| 9 ++---
9 files changed, 50 insertions(+), 11 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_config.c
diff --git a/drivers/gpu/drm/i915/Kconfig.profile
b/drivers/gpu/drm/i915/Kconfig.profile
index 0bfd276c19fe..3925be65d314 100644
--- a/drivers/gpu/drm/i915/Kconfig.profile
+++ b/drivers/gpu/drm/i915/Kconfig.profile
@@ -1,3 +1,15 @@
+config DRM_I915_FENCE_TIMEOUT
+ int "Timeout for unsignaled foreign fences"
+ default 1 # milliseconds
+ help
+ When listening to a foreign fence, we install a supplementary timer
+ to ensure that we are always signaled and our userspace is able to
+ make forward progress. This value specifies the timeout used for an
+ unsignaled foreign fence.
+
+ May be 0 to disable the timeout, and rely on the foreign fence being
+ eventually signaled.
+
config DRM_I915_USERFAULT_AUTOSUSPEND
int "Runtime autosuspend delay for userspace GGTT mmaps (ms)"
default 250 # milliseconds
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5359c736c789..b0da6ea6e3f1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -35,6 +35,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
# core driver code
i915-y += i915_drv.o \
+ i915_config.o \
i915_irq.o \
i915_getparam.o \
i915_params.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fd6d63b03489..432b4eeaf9f6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15814,7 +15814,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
if (new_plane_state->uapi.fence) { /* explicit fencing */
ret = i915_sw_fence_await_dma_fence(>commit_ready,
new_plane_state->uapi.fence,
- I915_FENCE_TIMEOUT,
+
i915_fence_timeout(dev_priv),
GFP_KERNEL);
if (ret < 0)
return ret;
@@ -15841,7 +15841,8 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
ret = i915_sw_fence_await_reservation(>commit_ready,
obj->base.resv, NULL,
- false, I915_FENCE_TIMEOUT,
+ false,
+
i915_fence_timeout(dev_priv),
GFP_KERNEL);
if (ret < 0)
goto unpin_fb;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index 34be4c0ee7c5..bc0223716906 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -108,7 +108,7 @@ bool i915_gem_clflush_object(struct drm_i915_gem_object
*obj,
if (clflush) {
i915_sw_fence_await_reservation(>base.chain,
obj->base.resv, NULL, true,
- I915_FENCE_TIMEOUT,
+
i915_fence_timeout(to_i915(obj->base.dev)),
I915_FENCE_GFP);
dma_resv_add_excl_fence(obj->base.resv, >base.dma);
dma_fence_work_commit(>base);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 3a146aa2593b..d3a86a4d5c04 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -288,8 +288,7 @@ int i915_gem_schedule_fill_pages_blt(struct
drm_i915_gem_object *obj,
i915_gem_object_lock(obj);
err = i915_sw_fence_await_reservation(>wait,
- obj->base.resv, NULL,
- true, I915_FENCE_TIMEOUT,
+
[Intel-gfx] [PATCH 04/15] drm/i915: Pull waiting on an external dma-fence into its routine
As a means for a small code consolidation, but primarily to start
thinking more carefully about internal-vs-external linkage, pull the
pair of i915_sw_fence_await_dma_fence() calls into a common routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 51b9e820ffe8..a185d0300df2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1067,6 +1067,14 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
return 0;
}
+static int
+i915_request_await_external(struct i915_request *rq, struct dma_fence *fence)
+{
+ return i915_sw_fence_await_dma_fence(>submit, fence,
+fence->context ?
I915_FENCE_TIMEOUT : 0,
+I915_FENCE_GFP);
+}
+
int
i915_request_await_dma_fence(struct i915_request *rq, struct dma_fence *fence)
{
@@ -1114,9 +1122,7 @@ i915_request_await_dma_fence(struct i915_request *rq,
struct dma_fence *fence)
if (dma_fence_is_i915(fence))
ret = i915_request_await_request(rq, to_request(fence));
else
- ret = i915_sw_fence_await_dma_fence(>submit, fence,
- fence->context ?
I915_FENCE_TIMEOUT : 0,
- I915_FENCE_GFP);
+ ret = i915_request_await_external(rq, fence);
if (ret < 0)
return ret;
@@ -1255,9 +1261,7 @@ i915_request_await_execution(struct i915_request *rq,
to_request(fence),
hook);
else
- ret = i915_sw_fence_await_dma_fence(>submit, fence,
- I915_FENCE_TIMEOUT,
- GFP_KERNEL);
+ ret = i915_request_await_external(rq, fence);
if (ret < 0)
return ret;
} while (--nchild);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915/gt: Declare when we enabled timeslicing
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3802
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 848decee9066..8415511f1465 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private *i915)
MAP(HAS_PREEMPTION, PREEMPTION),
MAP(HAS_SEMAPHORES, SEMAPHORES),
MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
+ MAP(HAS_TIMESLICES, TIMESLICING),
#undef MAP
};
struct intel_engine_cs *engine;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 704dd0e3bc1d..1ee227b5131a 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -523,6 +523,7 @@ typedef struct drm_i915_irq_wait {
#define I915_SCHEDULER_CAP_PREEMPTION(1ul << 2)
#define I915_SCHEDULER_CAP_SEMAPHORES(1ul << 3)
#define I915_SCHEDULER_CAP_ENGINE_BUSY_STATS (1ul << 4)
+#define I915_SCHEDULER_CAP_TIMESLICING (1ul << 5)
#define I915_PARAM_HUC_STATUS 42
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915/selftests: Always call the provided engine->emit_init_breadcrumb
While this does not appear to fix any issues, the backend itself knows
when it wants to emit a breadcrumb, so let it make the final call.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_perf.c | 3 +--
drivers/gpu/drm/i915/selftests/igt_spinner.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_perf.c
b/drivers/gpu/drm/i915/selftests/i915_perf.c
index 5608fab98d5d..ca0c9dbab713 100644
--- a/drivers/gpu/drm/i915/selftests/i915_perf.c
+++ b/drivers/gpu/drm/i915/selftests/i915_perf.c
@@ -221,8 +221,7 @@ static int live_noa_delay(void *arg)
goto out;
}
- if (rq->engine->emit_init_breadcrumb &&
- i915_request_timeline(rq)->has_initial_breadcrumb) {
+ if (rq->engine->emit_init_breadcrumb) {
err = rq->engine->emit_init_breadcrumb(rq);
if (err) {
i915_request_add(rq);
diff --git a/drivers/gpu/drm/i915/selftests/igt_spinner.c
b/drivers/gpu/drm/i915/selftests/igt_spinner.c
index 9ad4ab088466..e35ba5f9e73f 100644
--- a/drivers/gpu/drm/i915/selftests/igt_spinner.c
+++ b/drivers/gpu/drm/i915/selftests/igt_spinner.c
@@ -169,8 +169,7 @@ igt_spinner_create_request(struct igt_spinner *spin,
intel_gt_chipset_flush(engine->gt);
- if (engine->emit_init_breadcrumb &&
- i915_request_timeline(rq)->has_initial_breadcrumb) {
+ if (engine->emit_init_breadcrumb) {
err = engine->emit_init_breadcrumb(rq);
if (err)
goto cancel_rq;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] dma-buf: Proxy fence, an unsignaled fence placeholder
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real fence completes, and any future listeners will instead be
attach directly to the real fence avoiding any indirection overhead.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/dma-buf/Makefile | 13 +-
drivers/dma-buf/dma-fence-private.h | 20 +
drivers/dma-buf/dma-fence-proxy.c| 248 ++
drivers/dma-buf/dma-fence.c | 4 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-proxy.c | 699 +++
include/linux/dma-fence-proxy.h | 34 ++
7 files changed, 1015 insertions(+), 4 deletions(-)
create mode 100644 drivers/dma-buf/dma-fence-private.h
create mode 100644 drivers/dma-buf/dma-fence-proxy.c
create mode 100644 drivers/dma-buf/st-dma-fence-proxy.c
create mode 100644 include/linux/dma-fence-proxy.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 995e05f609ff..afaf6dadd9a3 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
-dma-resv.o seqno-fence.o
+obj-y := \
+ dma-buf.o \
+ dma-fence.o \
+ dma-fence-array.o \
+ dma-fence-chain.o \
+ dma-fence-proxy.o \
+ dma-resv.o \
+ seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
@@ -10,6 +16,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
- st-dma-fence-chain.o
+ st-dma-fence-chain.o \
+ st-dma-fence-proxy.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/dma-fence-private.h
b/drivers/dma-buf/dma-fence-private.h
new file mode 100644
index ..6924d28af0fa
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-private.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Fence mechanism for dma-buf and to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Canonical Ltd
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ */
+
+#ifndef DMA_FENCE_PRIVATE_H
+#define DMA_FENCE_PRIAVTE_H
+
+struct dma_fence;
+
+bool __dma_fence_enable_signaling(struct dma_fence *fence);
+
+#endif /* DMA_FENCE_PRIAVTE_H */
diff --git a/drivers/dma-buf/dma-fence-proxy.c
b/drivers/dma-buf/dma-fence-proxy.c
new file mode 100644
index ..f0cd89b966e0
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-proxy.c
@@ -0,0 +1,248 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * dma-fence-proxy: placeholder unsignaled fence
+ *
+ * Copyright (C) 2017-2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "dma-fence-private.h"
+
+struct dma_fence_proxy {
+ struct dma_fence base;
+
+ struct dma_fence *real;
+ struct dma_fence_cb cb;
+ struct irq_work work;
+
+ wait_queue_head_t wq;
+};
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#define same_lockclass(A, B) (A)->dep_map.key == (B)->dep_map.key
+#else
+#define same_lockclass(A, B) 0
+#endif
+
+static const char *proxy_get_driver_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_driver_name(real) : "proxy";
+}
+
+static const char *proxy_get_timeline_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_timeline_name(real) : "unset";
+}
+
+static void proxy_irq_work(struct irq_work *work)
+{
+ struct dma_fence_proxy *p = container_of(work, typeof(*p), work);
+
+ dma_fence_signal(>base);
+ dma_fence_put(>base);
+}
+
+static void proxy_callback(struct dma_fence *real, struct dma_fence_cb *cb)
+{
+ struct dma_fence_proxy *p = container_of(cb, typeof(*p), cb);
+
+ if (real->error)
+ dma_fence_set_error(>base, real->error);
+
+ /* Lower the height of the proxy chain -> single stack frame */
+ irq_work_queue(>work);
+}
+
+static bool proxy_enable_signaling(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+ bool ret = true;
+
+ if (real) {
+ spin_lock_nested(real->lock,
+same_lockclass(>wq.lock, real->lock));
+ ret = __dma_fence_enable_signaling(real);
[Intel-gfx] [PATCH 10/15] drm/i915/gem: Allow combining submit-fences with syncobj
We allow exported sync_file fences to be used as submit fences, but they
are not the only source of user fences. We also accept an array of
syncobj, and as with sync_file these are dma_fences underneath and so
feature the same set of controls. The submit-fence allows for a request
to be scheduled at the same time as the signaler, rather than as normal
after. Userspace can combine submit-fence with its own semaphores for
intra-batch scheduling.
Not exposing submit-fences to syncobj was at the time just a matter of
pragmatic expediency.
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4854
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 14 +++
drivers/gpu/drm/i915/i915_request.c | 24 +++
include/uapi/drm/i915_drm.h | 7 +++---
3 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 7abb96505a31..ec16ace50acf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2432,7 +2432,7 @@ static void
__free_fence_array(struct drm_syncobj **fences, unsigned int n)
{
while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ drm_syncobj_put(ptr_mask_bits(fences[n], 3));
kvfree(fences);
}
@@ -2489,7 +2489,7 @@ get_fence_array(struct drm_i915_gem_execbuffer2 *args,
BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
- fences[n] = ptr_pack_bits(syncobj, fence.flags, 2);
+ fences[n] = ptr_pack_bits(syncobj, fence.flags, 3);
}
return fences;
@@ -2520,7 +2520,7 @@ await_fence_array(struct i915_execbuffer *eb,
struct dma_fence *fence;
unsigned int flags;
- syncobj = ptr_unpack_bits(fences[n], , 2);
+ syncobj = ptr_unpack_bits(fences[n], , 3);
if (!(flags & I915_EXEC_FENCE_WAIT))
continue;
@@ -2544,7 +2544,11 @@ await_fence_array(struct i915_execbuffer *eb,
spin_unlock(>lock);
}
- err = i915_request_await_dma_fence(eb->request, fence);
+ if (flags & I915_EXEC_FENCE_WAIT_SUBMIT)
+ err = i915_request_await_execution(eb->request, fence,
+
eb->engine->bond_execute);
+ else
+ err = i915_request_await_dma_fence(eb->request, fence);
dma_fence_put(fence);
if (err < 0)
return err;
@@ -2565,7 +2569,7 @@ signal_fence_array(struct i915_execbuffer *eb,
struct drm_syncobj *syncobj;
unsigned int flags;
- syncobj = ptr_unpack_bits(fences[n], , 2);
+ syncobj = ptr_unpack_bits(fences[n], , 3);
if (!(flags & I915_EXEC_FENCE_SIGNAL))
continue;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index ad3b1c3597f4..fcf995e7d10c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1382,6 +1382,26 @@ __i915_request_await_execution(struct i915_request *to,
>fence);
}
+static int execution_proxy(struct await_proxy *ap)
+{
+ return i915_request_await_execution(ap->request, ap->fence, ap->data);
+}
+
+static int
+i915_request_await_proxy_execution(struct i915_request *rq,
+ struct dma_fence *fence,
+ void (*hook)(struct i915_request *rq,
+ struct dma_fence *signal))
+{
+ /*
+* We have to wait until the real request is known in order to
+* be able to hook into its execution, as opposed to waiting for
+* its completion.
+*/
+ return __i915_request_await_proxy(rq, fence, I915_FENCE_TIMEOUT,
+ execution_proxy, hook);
+}
+
int
i915_request_await_execution(struct i915_request *rq,
struct dma_fence *fence,
@@ -1421,6 +1441,10 @@ i915_request_await_execution(struct i915_request *rq,
ret = __i915_request_await_execution(rq,
to_request(fence),
hook);
+ else if (dma_fence_is_proxy(fence))
+ ret = i915_request_await_proxy_execution(rq,
+fence,
[Intel-gfx] [PATCH 03/15] drm/i915: Ignore submit-fences on the same timeline
While we ordinarily do not skip submit-fences due to the accompanying hook that we want to callback on execution, a submit-fence on the same timeline is meaningless. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 3c38d61c90f8..51b9e820ffe8 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1242,6 +1242,9 @@ i915_request_await_execution(struct i915_request *rq, continue; } + if (fence->context == rq->fence.context) + continue; + /* * We don't squash repeated fence dependencies here as we * want to run our callback in all cases. -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/syncobj: Allow use of dma-fence-proxy
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 42d46414f767..e141db0e1eb6 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -184,6 +184,7 @@
*/
#include
+#include
#include
#include
#include
@@ -324,14 +325,9 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
struct dma_fence *old_fence;
struct syncobj_wait_entry *cur, *tmp;
- if (fence)
- dma_fence_get(fence);
-
spin_lock(>lock);
- old_fence = rcu_dereference_protected(syncobj->fence,
- lockdep_is_held(>lock));
- rcu_assign_pointer(syncobj->fence, fence);
+ old_fence = dma_fence_replace_proxy(>fence, fence);
if (fence != old_fence) {
list_for_each_entry_safe(cur, tmp, >cb_list, node)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: Mark concurrent submissions with a weak-dependency
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across
submit fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dc3f2ee7136d..10109f661bcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2726,6 +2729,9 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2850,6 +2856,9 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Propagate any change in error status */
if (rq->fence.error)
i915_request_set_error_once(w, rq->fence.error);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4d18f808fda2..3c38d61c90f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1040,7 +1040,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
}
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1202,7 +1204,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
local_bh_disable();
if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_EXTERNAL |
-
[Intel-gfx] [PATCH 06/15] drm/i915: Tidy awaiting on dma-fences
Just tidy up the return handling for completed dma-fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 7daf81f55c90..295b9829e2da 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -546,13 +546,11 @@ int __i915_sw_fence_await_dma_fence(struct i915_sw_fence
*fence,
cb->fence = fence;
i915_sw_fence_await(fence);
- ret = dma_fence_add_callback(dma, >base, __dma_i915_sw_fence_wake);
- if (ret == 0) {
- ret = 1;
- } else {
+ ret = 1;
+ if (dma_fence_add_callback(dma, >base, __dma_i915_sw_fence_wake)) {
+ /* fence already signaled */
__dma_i915_sw_fence_wake(dma, >base);
- if (ret == -ENOENT) /* fence already signaled */
- ret = 0;
+ ret = 0;
}
return ret;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/i915: Prevent using semaphores to chain up to external fences
The downside of using semaphores is that we lose metadata passing
along the signaling chain. This is particularly nasty when we
need to pass along a fatal error such as EFAULT or EDEADLK. For
fatal errors we want to scrub the request before it is executed,
which means that we cannot preload the request onto HW and have
it wait upon a semaphore.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 26 +
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a185d0300df2..1feb416975e1 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1002,6 +1002,15 @@ emit_semaphore_wait(struct i915_request *to,
if (!rcu_access_pointer(from->hwsp_cacheline))
goto await_fence;
+ /*
+* If this or its dependents are waiting on an external fence
+* that may fail catastrophically, then we want to avoid using
+* sempahores as they bypass the fence signaling metadata, and we
+* lose the fence->error propagation.
+*/
+ if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN)
+ goto await_fence;
+
/* Just emit the first semaphore we see as request space is limited. */
if (already_busywaiting(to) & mask)
goto await_fence;
@@ -1064,12 +1073,29 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
return ret;
}
+ if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN)
+ to->sched.flags |= I915_SCHED_HAS_EXTERNAL_CHAIN;
+
return 0;
}
+static void mark_external(struct i915_request *rq)
+{
+ /*
+* The downside of using semaphores is that we lose metadata passing
+* along the signaling chain. This is particularly nasty when we
+* need to pass along a fatal error such as EFAULT or EDEADLK. For
+* fatal errors we want to scrub the request before it is executed,
+* which means that we cannot preload the request onto HW and have
+* it wait upon a semaphore.
+*/
+ rq->sched.flags |= I915_SCHED_HAS_EXTERNAL_CHAIN;
+}
+
static int
i915_request_await_external(struct i915_request *rq, struct dma_fence *fence)
{
+ mark_external(rq);
return i915_sw_fence_await_dma_fence(>submit, fence,
fence->context ?
I915_FENCE_TIMEOUT : 0,
I915_FENCE_GFP);
diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
b/drivers/gpu/drm/i915/i915_scheduler_types.h
index 7186875088a0..6ab2c5289bed 100644
--- a/drivers/gpu/drm/i915/i915_scheduler_types.h
+++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
@@ -66,6 +66,7 @@ struct i915_sched_node {
struct i915_sched_attr attr;
unsigned int flags;
#define I915_SCHED_HAS_SEMAPHORE_CHAIN BIT(0)
+#define I915_SCHED_HAS_EXTERNAL_CHAIN BIT(1)
intel_engine_mask_t semaphores;
};
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915: Drop I915_RESET_TIMEOUT and friends
These were used to set various timeouts for the reset procedure (deciding when the engine was dead, and even if the reset itself was not making forward progress). No longer used. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2e3b5c4d0759..ad287e5d6ded 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -623,13 +623,6 @@ i915_fence_timeout(const struct drm_i915_private *i915) return i915_fence_context_timeout(i915, U64_MAX); } -#define I915_RESET_TIMEOUT (10 * HZ) /* 10s */ - -#define I915_ENGINE_DEAD_TIMEOUT (4 * HZ) /* Seqno, head and subunits dead */ -#define I915_SEQNO_DEAD_TIMEOUT (12 * HZ) /* Seqno dead with active head */ - -#define I915_ENGINE_WEDGED_TIMEOUT (60 * HZ) /* Reset but no recovery? */ - /* Amount of SAGV/QGV points, BSpec precisely defines this */ #define I915_NUM_QGV_POINTS 8 -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the soft-hint. However, if we apply it to all those we
unwind, then the two equivalent levels may be reordered, and since the
dependencies will be replayed in order, we will not change the order of
dependencies.
There is a small issue with the lack of cross-engine priority bumping on
unwind, leaving the total graph slightly unordered; but that will not
result in any misordering of rendering on remote machines as any
signalers will also be live. Though there may be a danger that this will
upset our sanitychecks.
Why keep the I915_PRIORITY_WAIT soft-hint, I hear Tvrtko ask? Despite
the many hairy tricks we play to have the hint and then ignore it, I
still like the concept of codel and the promise that it gives for low
latency of independent queues!
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 10109f661bcb..3606a7946707 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -414,6 +414,12 @@ static inline int rq_prio(const struct i915_request *rq)
return READ_ONCE(rq->sched.attr.priority);
}
+static int __effective_prio(int prio)
+{
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
+ return prio | __NO_PREEMPTION;
+}
+
static int effective_prio(const struct i915_request *rq)
{
int prio = rq_prio(rq);
@@ -439,8 +445,7 @@ static int effective_prio(const struct i915_request *rq)
prio |= I915_PRIORITY_NOSEMAPHORE;
/* Restrict mere WAIT boosts from triggering preemption */
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- return prio | __NO_PREEMPTION;
+ return __effective_prio(prio);
}
static int queue_prio(const struct intel_engine_execlists *execlists)
@@ -1126,6 +1131,7 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
continue; /* XXX */
__i915_request_unsubmit(rq);
+ rq->sched.attr.priority |= __NO_PREEMPTION;
/*
* Push the request back into the queue for later resubmission.
@@ -1930,7 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
- return hint >= effective_prio(rq);
+ return __effective_prio(hint) >= effective_prio(rq);
}
static bool
@@ -1965,7 +1971,7 @@ switch_prio(struct intel_engine_cs *engine, const struct
i915_request *rq)
if (list_is_last(>sched.link, >active.requests))
return INT_MIN;
- return rq_prio(list_next_entry(rq, sched.link));
+ return __effective_prio(rq_prio(list_next_entry(rq, sched.link)));
}
static inline unsigned long
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the soft-hint. However, if we apply it to all those we
unwind, then the two equivalent levels may be reordered, and since the
dependencies will be replayed in order, we will not change the order of
dependencies.
There is a small issue with the lack of cross-engine priority bumping on
unwind, leaving the total graph slightly unordered; but that will not
result in any misordering of rendering on remote machines as any
signalers will also be live. Though there may be a danger that this will
upset our sanitychecks.
Why keep the I915_PRIORITY_WAIT soft-hint, I hear Tvrtko ask? Despite
the many hairy tricks we play to have the hint and then ignore it, I
still like the concept of codel and the promise that it gives for low
latency of independent queues!
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 10109f661bcb..3606a7946707 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -414,6 +414,12 @@ static inline int rq_prio(const struct i915_request *rq)
return READ_ONCE(rq->sched.attr.priority);
}
+static int __effective_prio(int prio)
+{
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
+ return prio | __NO_PREEMPTION;
+}
+
static int effective_prio(const struct i915_request *rq)
{
int prio = rq_prio(rq);
@@ -439,8 +445,7 @@ static int effective_prio(const struct i915_request *rq)
prio |= I915_PRIORITY_NOSEMAPHORE;
/* Restrict mere WAIT boosts from triggering preemption */
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- return prio | __NO_PREEMPTION;
+ return __effective_prio(prio);
}
static int queue_prio(const struct intel_engine_execlists *execlists)
@@ -1126,6 +1131,7 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
continue; /* XXX */
__i915_request_unsubmit(rq);
+ rq->sched.attr.priority |= __NO_PREEMPTION;
/*
* Push the request back into the queue for later resubmission.
@@ -1930,7 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
- return hint >= effective_prio(rq);
+ return __effective_prio(hint) >= effective_prio(rq);
}
static bool
@@ -1965,7 +1971,7 @@ switch_prio(struct intel_engine_cs *engine, const struct
i915_request *rq)
if (list_is_last(>sched.link, >active.requests))
return INT_MIN;
- return rq_prio(list_next_entry(rq, sched.link));
+ return __effective_prio(rq_prio(list_next_entry(rq, sched.link)));
}
static inline unsigned long
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Ignore submit-fences on the same timeline
While we ordinarily do not skip submit-fences due to the accompanying hook that we want to callback on execution, a submit-fence on the same timeline is meaningless. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 3c38d61c90f8..51b9e820ffe8 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1242,6 +1242,9 @@ i915_request_await_execution(struct i915_request *rq, continue; } + if (fence->context == rq->fence.context) + continue; + /* * We don't squash repeated fence dependencies here as we * want to run our callback in all cases. -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Mark concurrent submissions with a weak-dependency
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across
submit fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dc3f2ee7136d..10109f661bcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2726,6 +2729,9 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2850,6 +2856,9 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Propagate any change in error status */
if (rq->fence.error)
i915_request_set_error_once(w, rq->fence.error);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 4d18f808fda2..3c38d61c90f8 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1040,7 +1040,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
}
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1202,7 +1204,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
local_bh_disable();
if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_EXTERNAL |
-
Re: [Intel-gfx] [PATCH v2 16/22] drm/i915/rkl: Don't try to access transcoder D
On Mon, May 04, 2020 at 03:52:21PM -0700, Matt Roper wrote:
> There are a couple places in our driver that loop over transcoders A..D
> for gen11+; since RKL only has three pipes/transcoders, this can lead to
> unclaimed register reads/writes. We should add checks for transcoder
> existence where appropriate.
>
> Cc: Aditya Swarup
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 3 +++
> drivers/gpu/drm/i915/i915_irq.c | 6 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index fcfc3812ef28..2eeafda82188 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11007,6 +11007,9 @@ static bool bxt_get_dsi_transcoder_state(struct
> intel_crtc *crtc,
> else
> cpu_transcoder = TRANSCODER_DSI_C;
>
> + if (!HAS_TRANSCODER(dev_priv, cpu_transcoder))
> + continue;
> +
It looks like this hunk wound up in the wrong function after a conflict
resolution. It was supposed to be in icl_get_trans_port_sync_config()
instead (this BXT function doesn't execute on gen >= 11).
Matt
> power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> drm_WARN_ON(dev, *power_domain_mask & BIT_ULL(power_domain));
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 622986759ec6..1381cb530c2f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2849,6 +2849,9 @@ static void gen11_display_irq_reset(struct
> drm_i915_private *dev_priv)
> for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
> enum intel_display_power_domain domain;
>
> + if (!HAS_TRANSCODER(dev_priv, trans))
> + continue;
> +
> domain = POWER_DOMAIN_TRANSCODER(trans);
> if (!intel_display_power_is_enabled(dev_priv, domain))
> continue;
> @@ -3399,6 +3402,9 @@ static void gen8_de_irq_postinstall(struct
> drm_i915_private *dev_priv)
> for (trans = TRANSCODER_A; trans <= TRANSCODER_D; trans++) {
> enum intel_display_power_domain domain;
>
> + if (!HAS_TRANSCODER(dev_priv, trans))
> + continue;
> +
> domain = POWER_DOMAIN_TRANSCODER(trans);
> if (!intel_display_power_is_enabled(dev_priv, domain))
> continue;
> --
> 2.24.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Propagate error from completed fences
== Series Details ==
Series: drm/i915: Propagate error from completed fences
URL : https://patchwork.freedesktop.org/series/77003/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8434_full -> Patchwork_17591_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17591_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process@vcs0:
- shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-skl6/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-skl1/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
* igt@gem_exec_suspend@basic-s3:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-apl1/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-apl1/igt@gem_exec_susp...@basic-s3.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-skl3/igt@i915_susp...@sysfs-reader.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-skl9/igt@i915_susp...@sysfs-reader.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#300])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-skl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_edge_walk@pipe-a-256x256-top-edge:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#70] / [i915#93] /
[i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-kbl1/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-kbl4/igt@kms_cursor_edge_w...@pipe-a-256x256-top-edge.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#1188])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-skl6/igt@kms_...@bpc-switch.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-skl1/igt@kms_...@bpc-switch.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#180] /
[i915#95])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-apl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
- shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#648] /
[i915#69])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-skl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-skl5/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-iclb4/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +4
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-kbl3/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-kbl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
Possible fixes
* igt@gem_ctx_persistence@engines-mixed-process@bcs0:
- shard-glk: [FAIL][23] ([i915#1528]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/shard-glk4/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/shard-glk7/igt@gem_ctx_persistence@engines-mixed-proc...@bcs0.html
* {igt@gem_exec_fence@parallel@bcs0}:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" (rev3)
== Series Details == Series: series starting with [1/4] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" (rev3) URL : https://patchwork.freedesktop.org/series/77000/ State : success == Summary == CI Bug Log - changes from CI_DRM_8437 -> Patchwork_17592 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/index.html Known issues Here are the changes found in Patchwork_17592 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [SKIP][1] ([fdo#109271]) -> [FAIL][2] ([i915#579]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/fi-kbl-guc/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][3] ([fdo#109271]) -> [FAIL][4] ([i915#62]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8437/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (51 -> 44) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8437 -> Patchwork_17592 CI-20190529: 20190529 CI_DRM_8437: f721984e59fc8e56b7811b1c9229e94136742a74 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5635: e83abfca61d407d12eee4d25bb0e8686337a7791 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17592: b823a90e110bdff605705b2046f7c079da6b4c5f @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b823a90e110b drm/i915/gen12: Invalidate aux table entries forcibly 737484f26b6b drm/i915/gen12: Flush L3 98fa7c89748d drm/i915/gen12: Fix HDC pipeline flush d39f76775f88 Revert "drm/i915/tgl: Include ro parts of l3 to invalidate" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17592/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: Propagate error from completed fences
== Series Details == Series: drm/i915: Propagate error from completed fences URL : https://patchwork.freedesktop.org/series/77003/ State : success == Summary == CI Bug Log - changes from CI_DRM_8434 -> Patchwork_17591 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/index.html Changes --- No changes found Participating hosts (50 -> 42) -- Additional (1): fi-kbl-7560u Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-skl-lmem fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8434 -> Patchwork_17591 CI-20190529: 20190529 CI_DRM_8434: 2951bac393beb4f095468de8b7cc53c8e3a092c2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5635: e83abfca61d407d12eee4d25bb0e8686337a7791 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17591: 4cd4b288e019782a0e7b4114668bca8d6437c5be @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4cd4b288e019 drm/i915: Propagate error from completed fences == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17591/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/gen12: Flush L3
Quoting Mika Kuoppala (2020-05-06 15:47:33) > Flush TDL,L3 and EUs > > Signed-off-by: Mika Kuoppala I bow to your interpretation of the docs, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 4/6] drm/i915/gt: Switch to manual evaluation of RPS
Quoting Chris Wilson (2020-05-06 16:55:07)
> Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> > Btw, there are other patches on the list of failed cherry-picks:
> >
> > 614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
> > unbind")
>
> We need that to fix a deadlock.
>
> > c4e8ba739034 ("drm/i915/gt: Yield the timeslice if caught waiting on a user
> > semaphore")
>
> That to behave nicely with VkEvents.
>
> > a95f3ac21d64 ("drm/i915/gem: Remove object_is_locked assertion from
> > unpin_from_display_plane")
>
> And that's a potential bug in 5.7, so needs fixing.
>
> > 2632f174a2e1 ("drm/i915/execlists: Avoid reusing the same logical CCID")
> > 5c4a53e3b1cb ("drm/i915/execlists: Track inflight CCID")
>
> We probably need these based on our presumption of how the HW might
> work.
> >
> > do you have any updated ickle/dif branch available?
>
> Will do.
To ssh://people.freedesktop.org/~ickle/linux-2.6
+ f98e2df61ab3...134711240307 dif -> dif (forced update)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Mark concurrent submissions with a weak-dependency
== Series Details == Series: series starting with [1/2] drm/i915: Mark concurrent submissions with a weak-dependency URL : https://patchwork.freedesktop.org/series/76999/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8434 -> Patchwork_17590 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17590 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17590, 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_17590/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17590: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-skl-lmem:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/fi-skl-lmem/igt@i915_selftest@l...@execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17590/fi-skl-lmem/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_lrc: - fi-skl-6700k2: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8434/fi-skl-6700k2/igt@i915_selftest@live@gt_lrc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17590/fi-skl-6700k2/igt@i915_selftest@live@gt_lrc.html Participating hosts (50 -> 43) -- Additional (1): fi-kbl-7560u Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-bwr-2160 fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8434 -> Patchwork_17590 CI-20190529: 20190529 CI_DRM_8434: 2951bac393beb4f095468de8b7cc53c8e3a092c2 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5635: e83abfca61d407d12eee4d25bb0e8686337a7791 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17590: 2833b6c29cc99422bd7fee78c8c51237c86a7787 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2833b6c29cc9 drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing e39457734fee drm/i915: Mark concurrent submissions with a weak-dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17590/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
v2: correct register address (Yang)
v3: respect the order (Chris)
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael Antognolli
Cc: Yang A Shi
Signed-off-by: Mika Kuoppala
Acked-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +++-
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e1235d504837..bbdb0e2a4571 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4539,6 +4539,17 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static u32 *
+gen12_emit_aux_table_inv(struct i915_request *rq, u32 *cs)
+{
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(GEN12_GFX_CCS_AUX_NV);
+ *cs++ = AUX_INV;
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
static int gen12_emit_flush_render(struct i915_request *request,
u32 mode)
{
@@ -4587,7 +4598,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_CS_STALL;
- cs = intel_ring_begin(request, 8);
+ cs = intel_ring_begin(request, 8 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -4600,6 +4611,9 @@ static int gen12_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
+ /* hsdes: 1809175790 */
+ cs = gen12_emit_aux_table_inv(request, cs);
+
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fde54b86ea20..dc5952200a07 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2557,6 +2557,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN10_PAT_INDEX(index) _MMIO(0x40e0 + (index) * 4)
#define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
#define BSD_HWS_PGA_GEN7 _MMIO(0x04180)
+#define GEN12_GFX_CCS_AUX_NV _MMIO(0x4208)
+#define AUX_INV REG_BIT(0)
#define BLT_HWS_PGA_GEN7 _MMIO(0x04280)
#define VEBOX_HWS_PGA_GEN7 _MMIO(0x04380)
#define RING_ACTHD(base) _MMIO((base) + 0x74)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B
On Wed, May 06, 2020 at 06:49:06AM -0700, Srivatsa, Anusha wrote:
>
>
> > -Original Message- From: Intel-gfx
> > On Behalf Of Matt Roper
> > Sent: Tuesday, May 5, 2020 4:22 AM To:
> > intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [PATCH v2
> > 10/22] drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B
> >
> > Since the number of platforms with this restriction are growing,
> > let's separate out the platform logic into a has_phy_misc()
> > function.
> >
> > Bspec: 50107 Signed-off-by: Matt Roper
> > --- .../gpu/drm/i915/display/intel_combo_phy.c| 30
> > +++ 1 file changed, 17 insertions(+), 13
> > deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > b/drivers/gpu/drm/i915/display/intel_combo_phy.c index
> > 9ff05ec12115..43d8784f6fa0 100644 ---
> > a/drivers/gpu/drm/i915/display/intel_combo_phy.c +++
> > b/drivers/gpu/drm/i915/display/intel_combo_phy.c @@ -181,11 +181,25
> > @@ static void cnl_combo_phys_uninit(struct drm_i915_private
> > *dev_priv) intel_de_write(dev_priv, CHICKEN_MISC_2, val); }
> >
> > +static bool has_phy_misc(struct drm_i915_private *i915, enum phy
> > phy) { +/* + * Some platforms only expect PHY_MISC to be
> > programmed for PHY-A and + * PHY-B and may not even have instances
> > of the register for the +* other combo PHY's. + */ + if
> > (IS_ELKHARTLAKE(i915) || + IS_ROCKETLAKE(i915)) + return phy <
> > PHY_C;
> According BSpec 50107, there is an instance of this for combo PHY C as
> well.
>
Yeah, there's technically an instance of the register, but the only
field in it that our driver programs has a RKL programming note that
says "This register field need only be programmed for port A and B."
Matt
> Anusha
> > +
> > + return true;
> > +}
> > +
> > static bool icl_combo_phy_enabled(struct drm_i915_private *dev_priv,
> > enum phy phy)
> > {
> > /* The PHY C added by EHL has no PHY_MISC register */
> > - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> > + if (!has_phy_misc(dev_priv, phy))
> > return intel_de_read(dev_priv, ICL_PORT_COMP_DW0(phy))
> > & COMP_INIT;
> > else
> > return !(intel_de_read(dev_priv, ICL_PHY_MISC(phy)) & @@ -
> > 317,12 +331,7 @@ static void icl_combo_phys_init(struct drm_i915_private
> > *dev_priv)
> > continue;
> > }
> >
> > - /*
> > -* Although EHL adds a combo PHY C, there's no PHY_MISC
> > -* register for it and no need to program the
> > -* DE_IO_COMP_PWR_DOWN setting on PHY C.
> > -*/
> > - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> > + if (!has_phy_misc(dev_priv, phy))
> > goto skip_phy_misc;
> >
> > /*
> > @@ -376,12 +385,7 @@ static void icl_combo_phys_uninit(struct
> > drm_i915_private *dev_priv)
> > "Combo PHY %c HW state changed
> > unexpectedly\n",
> > phy_name(phy));
> >
> > - /*
> > -* Although EHL adds a combo PHY C, there's no PHY_MISC
> > -* register for it and no need to program the
> > -* DE_IO_COMP_PWR_DOWN setting on PHY C.
> > -*/
> > - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> > + if (!has_phy_misc(dev_priv, phy))
> > goto skip_phy_misc;
> >
> > val = intel_de_read(dev_priv, ICL_PHY_MISC(phy));
> > --
> > 2.24.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Quoting Mika Kuoppala (2020-05-06 16:58:55) > Aux table invalidation can fail on update. So > next access may cause memory access to be into stale entry. > > Proposed workaround is to invalidate entries between > all batchbuffers. > > v2: correct register address (Yang) > > References bspec#43904, hsdes#1809175790 > Cc: Chris Wilson > Cc: Chuansheng Liu > Cc: Rafael Antognolli > Cc: Yang A Shi > Signed-off-by: Mika Kuoppala I only hear good things about v3, so Acked-by: Chris Wilson > @@ -2526,6 +2526,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > #define HSW_GTT_CACHE_EN _MMIO(0x4024) > #define GTT_CACHE_EN_ALL 0xF0007FFF > #define GEN7_WR_WATERMARK _MMIO(0x4028) > +#define GEN12_GFX_CCS_AUX_NV _MMIO(0x4208) > +#define AUX_INV REG_BIT(0) > #define GEN7_GFX_PRIO_CTRL _MMIO(0x402C) > #define ARB_MODE _MMIO(0x4030) > #define ARB_MODE_SWIZZLE_SNB (1 << 4) 4024, 4028, 4208, 402C, 4030. Something seems not quite right. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915: Use stashed away hpd isr bits in intel_digital_port_connected()
On Wed, Mar 11, 2020 at 05:54:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of several platform specific variants of
> intel_digital_port_connected() and just use the ISR bits we've
> stashed away.
>
> v2: Duplicate stuff to avoid exposing platform specific
> functions across files (Jani)
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 88 +++-
> drivers/gpu/drm/i915/display/intel_dp.c | 59 ++--
> drivers/gpu/drm/i915/display/intel_tc.c | 4 +-
> 3 files changed, 17 insertions(+), 134 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index c8ceb08f8d05..d64fcc18ae4d 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4346,41 +4346,7 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
> static bool lpt_digital_port_connected(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - u32 bit;
> -
> - switch (encoder->hpd_pin) {
> - case HPD_PORT_B:
> - bit = SDE_PORTB_HOTPLUG_CPT;
> - break;
> - case HPD_PORT_C:
> - bit = SDE_PORTC_HOTPLUG_CPT;
> - break;
> - case HPD_PORT_D:
> - bit = SDE_PORTD_HOTPLUG_CPT;
> - break;
> - default:
> - MISSING_CASE(encoder->hpd_pin);
> - return false;
> - }
> -
> - return intel_de_read(dev_priv, SDEISR) & bit;
> -}
> -
> -static bool spt_digital_port_connected(struct intel_encoder *encoder)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - u32 bit;
> -
> - switch (encoder->hpd_pin) {
> - case HPD_PORT_A:
> - bit = SDE_PORTA_HOTPLUG_SPT;
> - break;
> - case HPD_PORT_E:
> - bit = SDE_PORTE_HOTPLUG_SPT;
> - break;
> - default:
> - return lpt_digital_port_connected(encoder);
> - }
> + u32 bit = dev_priv->hotplug.pch_hpd[encoder->hpd_pin];
>
> return intel_de_read(dev_priv, SDEISR) & bit;
> }
> @@ -4388,51 +4354,19 @@ static bool spt_digital_port_connected(struct
> intel_encoder *encoder)
> static bool hsw_digital_port_connected(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u32 bit = dev_priv->hotplug.hpd[encoder->hpd_pin];
>
> - return intel_de_read(dev_priv, DEISR) & DE_DP_A_HOTPLUG_IVB;
> + return intel_de_read(dev_priv, DEISR) & bit;
> }
>
> static bool bdw_digital_port_connected(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> -
> - return intel_de_read(dev_priv, GEN8_DE_PORT_ISR) &
> GEN8_PORT_DP_A_HOTPLUG;
> -}
> -
> -static bool bxt_digital_port_connected(struct intel_encoder *encoder)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - u32 bit;
> -
> - switch (encoder->hpd_pin) {
> - case HPD_PORT_A:
> - bit = BXT_DE_PORT_HP_DDIA;
> - break;
> - case HPD_PORT_B:
> - bit = BXT_DE_PORT_HP_DDIB;
> - break;
> - case HPD_PORT_C:
> - bit = BXT_DE_PORT_HP_DDIC;
> - break;
> - default:
> - MISSING_CASE(encoder->hpd_pin);
> - return false;
> - }
> + u32 bit = dev_priv->hotplug.hpd[encoder->hpd_pin];
>
> return intel_de_read(dev_priv, GEN8_DE_PORT_ISR) & bit;
> }
>
> -static bool icp_digital_port_connected(struct intel_encoder *encoder)
> -{
> - struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> - enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> -
> - if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
> - return intel_de_read(dev_priv, SDEISR) &
> SDE_TC_HOTPLUG_ICP(PORT_TC1);
> -
> - return intel_de_read(dev_priv, SDEISR) & SDE_DDI_HOTPLUG_ICP(phy);
> -}
> -
> static struct intel_connector *
> intel_ddi_init_hdmi_connector(struct intel_digital_port *intel_dig_port)
> {
> @@ -4628,17 +4562,15 @@ void intel_ddi_init(struct drm_i915_private
> *dev_priv, enum port port)
> if (intel_phy_is_tc(dev_priv, phy))
> intel_dig_port->connected = intel_tc_port_connected;
> else
> - intel_dig_port->connected = icp_digital_port_connected;
> - } else if (IS_GEN9_LP(dev_priv)) {
> - intel_dig_port->connected = bxt_digital_port_connected;
> - } else if (port == PORT_A) {
> - if (INTEL_GEN(dev_priv) >= 8)
> + intel_dig_port->connected = lpt_digital_port_connected;
> + } else if (INTEL_GEN(dev_priv) >= 8) {
> + if (port == PORT_A || IS_GEN9_LP(dev_priv))
> intel_dig_port->connected = bdw_digital_port_connected;
>
[Intel-gfx] [CI] drm/i915: Propagate error from completed fences
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 22635bbabf06..4d18f808fda2 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1034,8 +1034,10 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
GEM_BUG_ON(to == from);
GEM_BUG_ON(to->timeline == from->timeline);
- if (i915_request_completed(from))
+ if (i915_request_completed(from)) {
+ i915_sw_fence_set_error_once(>submit, from->fence.error);
return 0;
+ }
if (to->engine->schedule) {
ret = i915_sched_node_add_dependency(>sched, >sched);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915: Stash hpd status bits under dev_priv
On Wed, Mar 11, 2020 at 05:54:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Instead of constnantly having to figure out which hpd status bit
> array to use let's store them under dev_priv.
>
> Should perhaps take this further and stash even more stuff to
> make the hpd handling more abstract yet.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_irq.c | 198 ++--
> 2 files changed, 111 insertions(+), 89 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 19195bde4921..b5afbabf4c3b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -149,6 +149,8 @@ enum hpd_pin {
> struct i915_hotplug {
> struct delayed_work hotplug_work;
>
> + const u32 *hpd, *pch_hpd;
> +
> struct {
> unsigned long last_jiffies;
> int count;
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 9f0653cf0510..b95d952bd47d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -124,7 +124,6 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
> [HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS,
> };
>
> -/* BXT hpd list */
> static const u32 hpd_bxt[HPD_NUM_PINS] = {
> [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> @@ -168,6 +167,44 @@ static const u32 hpd_tgp[HPD_NUM_PINS] = {
> [HPD_PORT_I] = SDE_TC_HOTPLUG_ICP(PORT_TC6),
> };
>
> +static void intel_hpd_init_pins(struct drm_i915_private *dev_priv)
> +{
> + struct i915_hotplug *hpd = _priv->hotplug;
> +
> + if (HAS_GMCH(dev_priv)) {
> + if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
> + IS_CHERRYVIEW(dev_priv))
> + hpd->hpd = hpd_status_g4x;
> + else
> + hpd->hpd = hpd_status_i915;
> + return;
> + }
> +
> + if (INTEL_GEN(dev_priv) >= 12)
> + hpd->hpd = hpd_gen12;
> + else if (INTEL_GEN(dev_priv) >= 11)
> + hpd->hpd = hpd_gen11;
> + else if (IS_GEN9_LP(dev_priv))
> + hpd->hpd = hpd_bxt;
> + else if (INTEL_GEN(dev_priv) >= 8)
> + hpd->hpd = hpd_bdw;
> + else if (INTEL_GEN(dev_priv) >= 7)
> + hpd->hpd = hpd_ivb;
> + else
> + hpd->hpd = hpd_ilk;
> +
> + if (HAS_PCH_TGP(dev_priv) || HAS_PCH_JSP(dev_priv))
> + hpd->pch_hpd = hpd_tgp;
> + else if (HAS_PCH_ICP(dev_priv) || HAS_PCH_MCC(dev_priv))
> + hpd->pch_hpd = hpd_icp;
> + else if (HAS_PCH_SPT(dev_priv))
What about CNP?
> + hpd->pch_hpd = hpd_spt;
> + else if (HAS_PCH_LPT(dev_priv) || HAS_PCH_CPT(dev_priv))
> + hpd->pch_hpd = hpd_cpt;
> + else if (HAS_PCH_IBX(dev_priv))
> + hpd->pch_hpd = hpd_ibx;
Can we add MISSING_CASE for PCH platforms?
> +}
> +
> static void
> intel_handle_vblank(struct drm_i915_private *dev_priv, enum pipe pipe)
> {
> @@ -1504,33 +1541,27 @@ static void i9xx_hpd_irq_handler(struct
> drm_i915_private *dev_priv,
>u32 hotplug_status)
> {
> u32 pin_mask = 0, long_mask = 0;
> + u32 hotplug_trigger;
>
> - if (IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
> - IS_CHERRYVIEW(dev_priv)) {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> + if (IS_G4X(dev_priv) ||
> + IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_G4X;
> + else
> + hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
>
> - if (hotplug_trigger) {
> - intel_get_hpd_pins(dev_priv, _mask, _mask,
> -hotplug_trigger, hotplug_trigger,
> -hpd_status_g4x,
> -i9xx_port_hotplug_long_detect);
> + if (hotplug_trigger) {
> + intel_get_hpd_pins(dev_priv, _mask, _mask,
> +hotplug_trigger, hotplug_trigger,
> +dev_priv->hotplug.hpd,
> +i9xx_port_hotplug_long_detect);
>
> - intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
> - }
> -
> - if (hotplug_status & DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)
> - dp_aux_irq_handler(dev_priv);
> - } else {
> - u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
> -
> - if (hotplug_trigger) {
> - intel_get_hpd_pins(dev_priv, _mask, _mask,
> -hotplug_trigger, hotplug_trigger,
> -hpd_status_i915,
> -
[Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
v2: correct register address (Yang)
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael Antognolli
Cc: Yang A Shi
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +++-
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e1235d504837..bbdb0e2a4571 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4539,6 +4539,17 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static u32 *
+gen12_emit_aux_table_inv(struct i915_request *rq, u32 *cs)
+{
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(GEN12_GFX_CCS_AUX_NV);
+ *cs++ = AUX_INV;
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
static int gen12_emit_flush_render(struct i915_request *request,
u32 mode)
{
@@ -4587,7 +4598,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_CS_STALL;
- cs = intel_ring_begin(request, 8);
+ cs = intel_ring_begin(request, 8 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -4600,6 +4611,9 @@ static int gen12_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
+ /* hsdes: 1809175790 */
+ cs = gen12_emit_aux_table_inv(request, cs);
+
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fde54b86ea20..5168cde0596f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2526,6 +2526,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define HSW_GTT_CACHE_EN _MMIO(0x4024)
#define GTT_CACHE_EN_ALL 0xF0007FFF
#define GEN7_WR_WATERMARK _MMIO(0x4028)
+#define GEN12_GFX_CCS_AUX_NV _MMIO(0x4208)
+#define AUX_INV REG_BIT(0)
#define GEN7_GFX_PRIO_CTRL _MMIO(0x402C)
#define ARB_MODE _MMIO(0x4030)
#define ARB_MODE_SWIZZLE_SNB (1 << 4)
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 4/6] drm/i915/gt: Switch to manual evaluation of RPS
Quoting Rodrigo Vivi (2020-05-06 15:44:48)
> On Wed, Apr 29, 2020 at 09:54:44PM +0100, Chris Wilson wrote:
> > As with the realisation for soft-rc6, we respond to idling the engines
> > within microseconds, far faster than the response times for HW RC6 and
> > RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
> > running for many desktop workloads, as the RPS evaluation intervals are
> > on the order of tens of milliseconds, but the typical workload is just a
> > couple of milliseconds, but yet we still need to determine the best
> > frequency for user latency versus power.
> >
> > Recognising that the HW evaluation intervals are a poor fit, and that
> > they were deprecated [in bspec at least] from gen10, start to wean
> > ourselves off them and replace the EI with a timer and our accurate
> > busy-stats. The principle benefit of manually evaluating RPS intervals
> > is that we can be more responsive for better performance and powersaving
> > for both spiky workloads and steady-state.
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1698
> > Fixes: 98479ada421a ("drm/i915/gt: Treat idling as a RPS downclock event")
>
> Hi Chris,
>
> this one failed to apply on drm-intel-fixes and it looks critical
> to me... I attempted some cherry-pick and backport of other patches
> on this series, but they took me to other dependencies and many
> apparently non-trivial fixes.
It's the entire series. It's a UX regression rather than power, so it
could slip, and I would err on the side of caution as it is quite a
dramatic change to throw in late into a 5.7-rc. There's going to be no
user feedback on it until it is in the rc, by which point we have no
time to fix it.
> So, do we have a solution for this that we could apply for 5.7?
> Or the faith of 5.7 is also the part faster solution?
>
> Btw, there are other patches on the list of failed cherry-picks:
>
> 614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
> unbind")
We need that to fix a deadlock.
> c4e8ba739034 ("drm/i915/gt: Yield the timeslice if caught waiting on a user
> semaphore")
That to behave nicely with VkEvents.
> a95f3ac21d64 ("drm/i915/gem: Remove object_is_locked assertion from
> unpin_from_display_plane")
And that's a potential bug in 5.7, so needs fixing.
> 2632f174a2e1 ("drm/i915/execlists: Avoid reusing the same logical CCID")
> 5c4a53e3b1cb ("drm/i915/execlists: Track inflight CCID")
We probably need these based on our presumption of how the HW might
work.
>
> do you have any updated ickle/dif branch available?
Will do.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Propagate error from completed fences
On 05/05/2020 22:52, Chris Wilson wrote:
We need to preserve fatal errors from fences that are being terminated
as we hook them up.
Fixes: ef4688497512 ("drm/i915: Propagate fence errors")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Matthew Auld
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 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Quoting Mika Kuoppala (2020-05-06 16:20:22) > Chris Wilson writes: > > > Quoting Mika Kuoppala (2020-05-06 15:47:34) > >> Aux table invalidation can fail on update. So > >> next access may cause memory access to be into stale entry. > >> > >> Proposed workaround is to invalidate entries between > >> all batchbuffers. > > > > This sounds like it should have a sunset clause. Do we anticipate being > > able to drop this w/a in future? > > Rafael kindly pointed out that Mesa already does this: > https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/drivers/iris/iris_state.c#L5131 > So I would say we can drop this patch. Is the false hit self-contained? Is it caused by PTE update of the address or by a 3D state change i.e. is it a potential isolation issue? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Chris Wilson writes: > Quoting Mika Kuoppala (2020-05-06 15:47:34) >> Aux table invalidation can fail on update. So >> next access may cause memory access to be into stale entry. >> >> Proposed workaround is to invalidate entries between >> all batchbuffers. > > This sounds like it should have a sunset clause. Do we anticipate being > able to drop this w/a in future? Rafael kindly pointed out that Mesa already does this: https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/gallium/drivers/iris/iris_state.c#L5131 So I would say we can drop this patch. But it makes me wonder that is that LRI dropped for not being whitelisted. -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: Turn intel_digital_port_connected() in a vfunc
On Wed, Mar 11, 2020 at 05:54:20PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's get rid of the platform if ladders in
> intel_digital_port_connected() and make it a vfunc. Now the if
> ladders are at the encoder initialization which makes them a bit
> less convoluted.
>
> v2: Add forward decl for intel_encoder in intel_tc.h
> v3: Duplicate stuff to avoid exposing platform specific
> functions across files (Jani)
>
> Signed-off-by: Ville Syrjälä
Nice to see the CPU and PCH handlers in their own vfunc:
Reviewed-by: Imre Deak
nit: Looks like you could've also added mcc_digital_port_connected() for
PHY_C.
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 109 +
> .../drm/i915/display/intel_display_types.h| 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 147 +++---
> drivers/gpu/drm/i915/display/intel_tc.c | 3 +-
> drivers/gpu/drm/i915/display/intel_tc.h | 3 +-
> 5 files changed, 135 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 73d0f4648c06..c8ceb08f8d05 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -4343,6 +4343,96 @@ intel_ddi_hotplug(struct intel_encoder *encoder,
> return state;
> }
>
> +static bool lpt_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u32 bit;
> +
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_B:
> + bit = SDE_PORTB_HOTPLUG_CPT;
> + break;
> + case HPD_PORT_C:
> + bit = SDE_PORTC_HOTPLUG_CPT;
> + break;
> + case HPD_PORT_D:
> + bit = SDE_PORTD_HOTPLUG_CPT;
> + break;
> + default:
> + MISSING_CASE(encoder->hpd_pin);
> + return false;
> + }
> +
> + return intel_de_read(dev_priv, SDEISR) & bit;
> +}
> +
> +static bool spt_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u32 bit;
> +
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_A:
> + bit = SDE_PORTA_HOTPLUG_SPT;
> + break;
> + case HPD_PORT_E:
> + bit = SDE_PORTE_HOTPLUG_SPT;
> + break;
> + default:
> + return lpt_digital_port_connected(encoder);
> + }
> +
> + return intel_de_read(dev_priv, SDEISR) & bit;
> +}
> +
> +static bool hsw_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + return intel_de_read(dev_priv, DEISR) & DE_DP_A_HOTPLUG_IVB;
> +}
> +
> +static bool bdw_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> +
> + return intel_de_read(dev_priv, GEN8_DE_PORT_ISR) &
> GEN8_PORT_DP_A_HOTPLUG;
> +}
> +
> +static bool bxt_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + u32 bit;
> +
> + switch (encoder->hpd_pin) {
> + case HPD_PORT_A:
> + bit = BXT_DE_PORT_HP_DDIA;
> + break;
> + case HPD_PORT_B:
> + bit = BXT_DE_PORT_HP_DDIB;
> + break;
> + case HPD_PORT_C:
> + bit = BXT_DE_PORT_HP_DDIC;
> + break;
> + default:
> + MISSING_CASE(encoder->hpd_pin);
> + return false;
> + }
> +
> + return intel_de_read(dev_priv, GEN8_DE_PORT_ISR) & bit;
> +}
> +
> +static bool icp_digital_port_connected(struct intel_encoder *encoder)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> +
> + if (HAS_PCH_MCC(dev_priv) && phy == PHY_C)
> + return intel_de_read(dev_priv, SDEISR) &
> SDE_TC_HOTPLUG_ICP(PORT_TC1);
> +
> + return intel_de_read(dev_priv, SDEISR) & SDE_DDI_HOTPLUG_ICP(phy);
> +}
> +
> static struct intel_connector *
> intel_ddi_init_hdmi_connector(struct intel_digital_port *intel_dig_port)
> {
> @@ -4534,6 +4624,25 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
> enum port port)
> port_name(port));
> }
>
> + if (INTEL_GEN(dev_priv) >= 11) {
> + if (intel_phy_is_tc(dev_priv, phy))
> + intel_dig_port->connected = intel_tc_port_connected;
> + else
> + intel_dig_port->connected = icp_digital_port_connected;
> + } else if (IS_GEN9_LP(dev_priv)) {
> + intel_dig_port->connected = bxt_digital_port_connected;
> + } else if (port == PORT_A) {
> + if (INTEL_GEN(dev_priv) >= 8)
> + intel_dig_port->connected = bdw_digital_port_connected;
> +
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
URL : https://patchwork.freedesktop.org/series/73036/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17589_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17589_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17589_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_17589_full:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-tglb8/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb7/igt@i915_module_l...@reload.html
* igt@runner@aborted:
- shard-tglb: NOTRUN -> ([FAIL][3], [FAIL][4], [FAIL][5],
[FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12])
([i915#1764] / [k.org#204565] / [k.org#205379])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb2/igt@run...@aborted.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb7/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb1/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb3/igt@run...@aborted.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb2/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb6/igt@run...@aborted.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb1/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb6/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb8/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb7/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@perf_pmu@module-unload}:
- shard-tglb: [PASS][13] -> [INCOMPLETE][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-tglb1/igt@perf_...@module-unload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb3/igt@perf_...@module-unload.html
Known issues
Here are the changes found in Patchwork_17589_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#716])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-glk6/igt@gen9_exec_pa...@allowed-all.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-glk5/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_color@pipe-b-gamma:
- shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#1149]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-tglb6/igt@kms_co...@pipe-b-gamma.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb7/igt@kms_co...@pipe-b-gamma.html
* igt@kms_color@pipe-d-ctm-max:
- shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([i915#1149]) +9
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-tglb7/igt@kms_co...@pipe-d-ctm-max.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-tglb7/igt@kms_co...@pipe-d-ctm-max.html
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-kbl: [PASS][21] -> [FAIL][22] ([i915#699] / [i915#93] /
[i915#95])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-kbl4/igt@kms_flip_til...@flip-changes-tiling.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-kbl3/igt@kms_flip_til...@flip-changes-tiling.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu:
- shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) +2 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-snb1/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/shard-snb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][25] -> [FAIL][26] ([i915#1188]) +1
Re: [Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Quoting Mika Kuoppala (2020-05-06 15:47:34) > Aux table invalidation can fail on update. So > next access may cause memory access to be into stale entry. > > Proposed workaround is to invalidate entries between > all batchbuffers. This sounds like it should have a sunset clause. Do we anticipate being able to drop this w/a in future? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] Revert "drm/i915/tgl: Include ro parts of l3 to invalidate"
This reverts commit 62037229b7d94f1db5ef8d2e2ec819832ef3. L3 ro cache invalidation is part of the dword0 of pipe control. Also it is not relevant to this gen. Signed-off-by: Mika Kuoppala Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 - drivers/gpu/drm/i915/gt/intel_lrc.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index ee10122a511e..b3cf09657fb2 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -236,7 +236,6 @@ #define PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH (1<<12) /* gen6+ */ #define PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */ #define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE(1<<10) /* GM45+ only */ -#define PIPE_CONTROL_L3_RO_CACHE_INVALIDATE REG_BIT(10) /* gen12 */ #define PIPE_CONTROL_INDIRECT_STATE_DISABLE (1<<9) #define PIPE_CONTROL_HDC_PIPELINE_FLUSH REG_BIT(9) /* gen12 */ #define PIPE_CONTROL_NOTIFY (1<<8) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index dc3f2ee7136d..feba021ca572 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4579,7 +4579,6 @@ static int gen12_emit_flush_render(struct i915_request *request, flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE; flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; - flags |= PIPE_CONTROL_L3_RO_CACHE_INVALIDATE; flags |= PIPE_CONTROL_STORE_DATA_INDEX; flags |= PIPE_CONTROL_QW_WRITE; -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/gen12: Fix HDC pipeline flush
HDC pipeline flush is bit on the first dword of
the PIPE_CONTROL, not the second. Make it so.
v2: function naming (Chris)
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine.h | 34
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 29 +
3 files changed, 44 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 19d0b8830905..cb789c8bf06b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -241,19 +241,29 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine);
void intel_engine_print_breadcrumbs(struct intel_engine_cs *engine,
struct drm_printer *p);
-static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+static inline u32 *__gen8_emit_pipe_control(u32 *batch, u32 flags0, u32
flags1, u32 offset)
{
memset(batch, 0, 6 * sizeof(u32));
- batch[0] = GFX_OP_PIPE_CONTROL(6);
- batch[1] = flags;
+ batch[0] = GFX_OP_PIPE_CONTROL(6) | flags0;
+ batch[1] = flags1;
batch[2] = offset;
return batch + 6;
}
+static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset)
+{
+ return __gen8_emit_pipe_control(batch, 0, flags, offset);
+}
+
+static inline u32 *gen12_emit_pipe_control(u32 *batch, u32 flags0, u32 flags1,
u32 offset)
+{
+ return __gen8_emit_pipe_control(batch, flags0, flags1, offset);
+}
+
static inline u32 *
-gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
+__gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags0, u32
flags1)
{
/* We're using qword write, offset should be aligned to 8 bytes. */
GEM_BUG_ON(!IS_ALIGNED(gtt_offset, 8));
@@ -262,8 +272,8 @@ gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32
gtt_offset, u32 flags)
* need a prior CS_STALL, which is emitted by the flush
* following the batch.
*/
- *cs++ = GFX_OP_PIPE_CONTROL(6);
- *cs++ = flags | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_GLOBAL_GTT_IVB;
+ *cs++ = GFX_OP_PIPE_CONTROL(6) | flags0;
+ *cs++ = flags1 | PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_GLOBAL_GTT_IVB;
*cs++ = gtt_offset;
*cs++ = 0;
*cs++ = value;
@@ -273,6 +283,18 @@ gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32
gtt_offset, u32 flags)
return cs;
}
+static inline u32*
+gen8_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
+{
+ return __gen8_emit_ggtt_write_rcs(cs, value, gtt_offset, 0, flags);
+}
+
+static inline u32*
+gen12_emit_ggtt_write_rcs(u32 *cs, u32 value, u32 gtt_offset, u32 flags0, u32
flags1)
+{
+ return __gen8_emit_ggtt_write_rcs(cs, value, gtt_offset, flags0,
flags1);
+}
+
static inline u32 *
gen8_emit_ggtt_write(u32 *cs, u32 value, u32 gtt_offset, u32 flags)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index b3cf09657fb2..534e435f20bc 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -237,7 +237,7 @@
#define PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE(1<<11) /* MBZ on ILK */
#define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE(1<<10) /*
GM45+ only */
#define PIPE_CONTROL_INDIRECT_STATE_DISABLE (1<<9)
-#define PIPE_CONTROL_HDC_PIPELINE_FLUSH REG_BIT(9) /* gen12 */
+#define PIPE_CONTROL0_HDC_PIPELINE_FLUSH REG_BIT(9) /* gen12 */
#define PIPE_CONTROL_NOTIFY (1<<8)
#define PIPE_CONTROL_FLUSH_ENABLE(1<<7) /* gen7+ */
#define PIPE_CONTROL_DC_FLUSH_ENABLE (1<<5)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index feba021ca572..78f879ed4aa7 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4553,7 +4553,6 @@ static int gen12_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_DEPTH_STALL;
flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
flags |= PIPE_CONTROL_FLUSH_ENABLE;
- flags |= PIPE_CONTROL_HDC_PIPELINE_FLUSH;
flags |= PIPE_CONTROL_STORE_DATA_INDEX;
flags |= PIPE_CONTROL_QW_WRITE;
@@ -4564,7 +4563,9 @@ static int gen12_emit_flush_render(struct i915_request
*request,
if (IS_ERR(cs))
return PTR_ERR(cs);
- cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
+ cs = gen12_emit_pipe_control(cs,
+PIPE_CONTROL0_HDC_PIPELINE_FLUSH,
+flags, LRC_PPHWSP_SCRATCH_ADDR);
[Intel-gfx] [PATCH 3/4] drm/i915/gen12: Flush L3
Flush TDL,L3 and EUs Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_lrc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 78f879ed4aa7..e1235d504837 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -4547,6 +4547,7 @@ static int gen12_emit_flush_render(struct i915_request *request, u32 *cs; flags |= PIPE_CONTROL_TILE_CACHE_FLUSH; + flags |= PIPE_CONTROL_FLUSH_L3; flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; /* Wa_1409600907:tgl */ @@ -4758,6 +4759,7 @@ gen12_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) PIPE_CONTROL0_HDC_PIPELINE_FLUSH, PIPE_CONTROL_CS_STALL | PIPE_CONTROL_TILE_CACHE_FLUSH | + PIPE_CONTROL_FLUSH_L3 | PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | PIPE_CONTROL_DEPTH_CACHE_FLUSH | /* Wa_1409600907:tgl */ -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/gen12: Invalidate aux table entries forcibly
Aux table invalidation can fail on update. So
next access may cause memory access to be into stale entry.
Proposed workaround is to invalidate entries between
all batchbuffers.
References bspec#43904, hsdes#1809175790
Cc: Chris Wilson
Cc: Chuansheng Liu
Cc: Rafael ANtognolli
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +++-
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index e1235d504837..bbdb0e2a4571 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4539,6 +4539,17 @@ static u32 preparser_disable(bool state)
return MI_ARB_CHECK | 1 << 8 | state;
}
+static u32 *
+gen12_emit_aux_table_inv(struct i915_request *rq, u32 *cs)
+{
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(GEN12_GFX_CCS_AUX_NV);
+ *cs++ = AUX_INV;
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
static int gen12_emit_flush_render(struct i915_request *request,
u32 mode)
{
@@ -4587,7 +4598,7 @@ static int gen12_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_CS_STALL;
- cs = intel_ring_begin(request, 8);
+ cs = intel_ring_begin(request, 8 + 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -4600,6 +4611,9 @@ static int gen12_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
+ /* hsdes: 1809175790 */
+ cs = gen12_emit_aux_table_inv(request, cs);
+
*cs++ = preparser_disable(false);
intel_ring_advance(request, cs);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fde54b86ea20..07e702bd16b5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2526,6 +2526,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define HSW_GTT_CACHE_EN _MMIO(0x4024)
#define GTT_CACHE_EN_ALL 0xF0007FFF
#define GEN7_WR_WATERMARK _MMIO(0x4028)
+#define GEN12_GFX_CCS_AUX_NV _MMIO(0x4028)
+#define AUX_INV REG_BIT(0)
#define GEN7_GFX_PRIO_CTRL _MMIO(0x402C)
#define ARB_MODE _MMIO(0x4030)
#define ARB_MODE_SWIZZLE_SNB (1 << 4)
--
2.17.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/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing
Quoting Chris Wilson (2020-05-06 15:36:16) > Make sure we ignore the I915_PRIORITY_WAIT hint when looking at > timeslicing, as we do not treat it as a preemption request but as a soft > ordering hint. If we apply the hint, then when we recompute the ordering > after unwinding for the timeslice, we will often leave the order > unchanged due to the soft-hint. However, if we apply it to all those we > unwind, then the two equivalent levels may be reordered, and since the > dependencies will be replayed in order, we will not change the order of > dependencies. > > There is a small issue with the lack of cross-engine priority bumping on > unwind, leaving the total graph slightly unordered; but that will not > result in any misordering of rendering on remote machines as any > signalers will also be live. Though there may be a danger that this will > upset our sanitychecks. > > Why keep the I915_PRIORITY_WAIT soft-hint, I hear Tvrtko ask? Despite > the many hairy tricks we play to have the hint and then ignore it, I > still like the concept of codel and the promise that it gives for low > latency of independent queues! Tvrtko is warned not to ask when we replace strict priorities with isoschronous and psuedo-deadline scheduling. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI 4/6] drm/i915/gt: Switch to manual evaluation of RPS
On Wed, Apr 29, 2020 at 09:54:44PM +0100, Chris Wilson wrote:
> As with the realisation for soft-rc6, we respond to idling the engines
> within microseconds, far faster than the response times for HW RC6 and
> RPS. Furthermore, our fast parking upon idle, prevents HW RPS from
> running for many desktop workloads, as the RPS evaluation intervals are
> on the order of tens of milliseconds, but the typical workload is just a
> couple of milliseconds, but yet we still need to determine the best
> frequency for user latency versus power.
>
> Recognising that the HW evaluation intervals are a poor fit, and that
> they were deprecated [in bspec at least] from gen10, start to wean
> ourselves off them and replace the EI with a timer and our accurate
> busy-stats. The principle benefit of manually evaluating RPS intervals
> is that we can be more responsive for better performance and powersaving
> for both spiky workloads and steady-state.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1698
> Fixes: 98479ada421a ("drm/i915/gt: Treat idling as a RPS downclock event")
Hi Chris,
this one failed to apply on drm-intel-fixes and it looks critical
to me... I attempted some cherry-pick and backport of other patches
on this series, but they took me to other dependencies and many
apparently non-trivial fixes.
So, do we have a solution for this that we could apply for 5.7?
Or the faith of 5.7 is also the part faster solution?
Btw, there are other patches on the list of failed cherry-picks:
614654abe847 ("drm/i915: Check current i915_vma.pin_count status first on
unbind")
c4e8ba739034 ("drm/i915/gt: Yield the timeslice if caught waiting on a user
semaphore")
a95f3ac21d64 ("drm/i915/gem: Remove object_is_locked assertion from
unpin_from_display_plane")
2632f174a2e1 ("drm/i915/execlists: Avoid reusing the same logical CCID")
5c4a53e3b1cb ("drm/i915/execlists: Track inflight CCID")
do you have any updated ickle/dif branch available?
Thanks,
Rodrigo.
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Andi Shyti
> Reviewed-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 +
> drivers/gpu/drm/i915/gt/intel_rps.c | 138 ---
> drivers/gpu/drm/i915/gt/intel_rps.h | 15 ++
> drivers/gpu/drm/i915/gt/intel_rps_types.h| 5 +
> 4 files changed, 147 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 83b1f95ebf12..f760e2ef285b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -555,6 +555,11 @@ struct intel_engine_cs {
>* Idle is defined as active == 0, active is active > 0.
>*/
> ktime_t start;
> +
> + /**
> + * @rps: Utilisation at last RPS sampling.
> + */
> + ktime_t rps;
> } stats;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
> b/drivers/gpu/drm/i915/gt/intel_rps.c
> index 52151001d7ab..8b2991de1c97 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> @@ -15,6 +15,8 @@
> #include "intel_sideband.h"
> #include "../../../platform/x86/intel_ips.h"
>
> +#define BUSY_MAX_EI 20u /* ms */
> +
> /*
> * Lock protecting IPS related data structures
> */
> @@ -45,6 +47,100 @@ static inline void set(struct intel_uncore *uncore,
> i915_reg_t reg, u32 val)
> intel_uncore_write_fw(uncore, reg, val);
> }
>
> +static void rps_timer(struct timer_list *t)
> +{
> + struct intel_rps *rps = from_timer(rps, t, timer);
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + s64 max_busy[3] = {};
> + ktime_t dt, last;
> +
> + for_each_engine(engine, rps_to_gt(rps), id) {
> + s64 busy;
> + int i;
> +
> + dt = intel_engine_get_busy_time(engine);
> + last = engine->stats.rps;
> + engine->stats.rps = dt;
> +
> + busy = ktime_to_ns(ktime_sub(dt, last));
> + for (i = 0; i < ARRAY_SIZE(max_busy); i++) {
> + if (busy > max_busy[i])
> + swap(busy, max_busy[i]);
> + }
> + }
> +
> + dt = ktime_get();
> + last = rps->pm_timestamp;
> + rps->pm_timestamp = dt;
> +
> + if (intel_rps_is_active(rps)) {
> + s64 busy;
> + int i;
> +
> + dt = ktime_sub(dt, last);
> +
> + /*
> + * Our goal is to evaluate each engine independently, so we run
> + * at the lowest clocks required to sustain the heaviest
> + * workload. However, a task may be split into sequential
> + * dependent operations across a set of engines, such that
> + * the independent contributions do not account for high load,
> + * but overall
Re: [Intel-gfx] [PATCH v4 00/11] Rebased Big Joiner patch series for 8K 2p1p
Hey, I've been testing on re-tgl1-display, but series fails. The 8k mode is rejected because of htotal exceeding limits. When testing 5120x3200@120 Hz, I get: [18352.624231] i915 :00:02.0: [drm:intel_crtc_compute_min_cdclk [i915]] required cdclk (1056740 kHz) exceeds max (652800 kHz) Latter makes any further testing impossible. I've copied 8k and 5k@120 edids to re-tgl1-display edids for testing DP. ~Maarten Op 01-05-2020 om 01:09 schreef Manasi Navare: > This rebases the big joiner patch series from February: > https://patchwork.freedesktop.org/series/73014/ > or from Maarten's internal tree: > https://patchwork.freedesktop.org/series/73014/ > > This especially needs a thorough review on Patch 10/11 due to > all the refactoring around commit_modeset_enables > > Maarten Lankhorst (11): > HAX to make DSC work on the icelake test system > drm/i915: Remove hw.mode > drm/i915: Add hw.pipe_mode to allow bigjoiner pipe/transcoder split > drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. > drm/i915: Try to make bigjoiner work in atomic check > drm/i915: Enable big joiner support in enable and disable sequences. > drm/i915: Make hardware readout work on i915. > drm/i915: Link planes in a bigjoiner configuration, v3. > drm/i915: Add bigjoiner aware plane clipping checks > drm/i915: Add intel_update_bigjoiner handling. > drm/i915: Add debugfs dumping for bigjoiner, v3. > > drivers/gpu/drm/drm_dp_helper.c |4 +- > drivers/gpu/drm/i915/display/icl_dsi.c|2 - > drivers/gpu/drm/i915/display/intel_atomic.c |9 +- > drivers/gpu/drm/i915/display/intel_atomic.h |3 +- > .../gpu/drm/i915/display/intel_atomic_plane.c | 112 +- > .../gpu/drm/i915/display/intel_atomic_plane.h |7 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 81 +- > drivers/gpu/drm/i915/display/intel_display.c | 1070 + > drivers/gpu/drm/i915/display/intel_display.h | 20 +- > .../drm/i915/display/intel_display_debugfs.c | 29 +- > .../drm/i915/display/intel_display_types.h| 32 +- > drivers/gpu/drm/i915/display/intel_dp.c | 141 ++- > drivers/gpu/drm/i915/display/intel_dvo.c |2 +- > drivers/gpu/drm/i915/display/intel_sdvo.c | 16 +- > drivers/gpu/drm/i915/display/intel_sprite.c | 46 +- > drivers/gpu/drm/i915/display/intel_sprite.h |3 +- > drivers/gpu/drm/i915/display/intel_vdsc.c | 199 +-- > drivers/gpu/drm/i915/display/intel_vdsc.h |7 +- > drivers/gpu/drm/i915/intel_pm.c | 92 +- > include/drm/drm_dp_helper.h |1 + > 20 files changed, 1390 insertions(+), 486 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Suppress internal I915_PRIORITY_WAIT for timeslicing
Make sure we ignore the I915_PRIORITY_WAIT hint when looking at
timeslicing, as we do not treat it as a preemption request but as a soft
ordering hint. If we apply the hint, then when we recompute the ordering
after unwinding for the timeslice, we will often leave the order
unchanged due to the soft-hint. However, if we apply it to all those we
unwind, then the two equivalent levels may be reordered, and since the
dependencies will be replayed in order, we will not change the order of
dependencies.
There is a small issue with the lack of cross-engine priority bumping on
unwind, leaving the total graph slightly unordered; but that will not
result in any misordering of rendering on remote machines as any
signalers will also be live. Though there may be a danger that this will
upset our sanitychecks.
Why keep the I915_PRIORITY_WAIT soft-hint, I hear Tvrtko ask? Despite
the many hairy tricks we play to have the hint and then ignore it, I
still like the concept of codel and the promise that it gives for low
latency of independent queues!
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 10109f661bcb..3606a7946707 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -414,6 +414,12 @@ static inline int rq_prio(const struct i915_request *rq)
return READ_ONCE(rq->sched.attr.priority);
}
+static int __effective_prio(int prio)
+{
+ BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
+ return prio | __NO_PREEMPTION;
+}
+
static int effective_prio(const struct i915_request *rq)
{
int prio = rq_prio(rq);
@@ -439,8 +445,7 @@ static int effective_prio(const struct i915_request *rq)
prio |= I915_PRIORITY_NOSEMAPHORE;
/* Restrict mere WAIT boosts from triggering preemption */
- BUILD_BUG_ON(__NO_PREEMPTION & ~I915_PRIORITY_MASK); /* only internal */
- return prio | __NO_PREEMPTION;
+ return __effective_prio(prio);
}
static int queue_prio(const struct intel_engine_execlists *execlists)
@@ -1126,6 +1131,7 @@ __unwind_incomplete_requests(struct intel_engine_cs
*engine)
continue; /* XXX */
__i915_request_unsubmit(rq);
+ rq->sched.attr.priority |= __NO_PREEMPTION;
/*
* Push the request back into the queue for later resubmission.
@@ -1930,7 +1936,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(>sched.link, >active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
- return hint >= effective_prio(rq);
+ return __effective_prio(hint) >= effective_prio(rq);
}
static bool
@@ -1965,7 +1971,7 @@ switch_prio(struct intel_engine_cs *engine, const struct
i915_request *rq)
if (list_is_last(>sched.link, >active.requests))
return INT_MIN;
- return rq_prio(list_next_entry(rq, sched.link));
+ return __effective_prio(rq_prio(list_next_entry(rq, sched.link)));
}
static inline unsigned long
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Mark concurrent submissions with a weak-dependency
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could
correctly perform priority inheritance from the parallel branches to the
common trunk. However, for the purpose of timeslicing and reset
handling, the dependency is weak -- as we the pair of requests are
allowed to run in parallel and not in strict succession. So for example
we do need to suspend one if the other hangs.
The real significance though is that this allows us to rearrange
groups of WAIT_FOR_SUBMIT linked requests along the single engine, and
so can resolve user level inter-batch scheduling dependencies from user
semaphores.
Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across
submit fences")
Testcase: igt/gem_exec_fence/submit
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: # v5.6+
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
drivers/gpu/drm/i915/i915_request.c | 8 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 6 +++---
drivers/gpu/drm/i915/i915_scheduler.h | 3 ++-
drivers/gpu/drm/i915/i915_scheduler_types.h | 1 +
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index dc3f2ee7136d..10109f661bcb 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1880,6 +1880,9 @@ static void defer_request(struct i915_request *rq, struct
list_head * const pl)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2726,6 +2729,9 @@ static void __execlists_hold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Leave semaphores spinning on the other engines */
if (w->engine != rq->engine)
continue;
@@ -2850,6 +2856,9 @@ static void __execlists_unhold(struct i915_request *rq)
struct i915_request *w =
container_of(p->waiter, typeof(*w), sched);
+ if (p->flags & I915_DEPENDENCY_WEAK)
+ continue;
+
/* Propagate any change in error status */
if (rq->fence.error)
i915_request_set_error_once(w, rq->fence.error);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 22635bbabf06..02a5644ae105 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1038,7 +1038,9 @@ i915_request_await_request(struct i915_request *to,
struct i915_request *from)
return 0;
if (to->engine->schedule) {
- ret = i915_sched_node_add_dependency(>sched, >sched);
+ ret = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_EXTERNAL);
if (ret < 0)
return ret;
}
@@ -1200,7 +1202,9 @@ __i915_request_await_execution(struct i915_request *to,
/* Couple the dependency tree for PI on this exposed to->fence */
if (to->engine->schedule) {
- err = i915_sched_node_add_dependency(>sched, >sched);
+ err = i915_sched_node_add_dependency(>sched,
+>sched,
+I915_DEPENDENCY_WEAK);
if (err < 0)
return err;
}
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 37cfcf5b321b..6e2d4190099f 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -462,7 +462,8 @@ bool __i915_sched_node_add_dependency(struct
i915_sched_node *node,
}
int i915_sched_node_add_dependency(struct i915_sched_node *node,
- struct i915_sched_node *signal)
+ struct i915_sched_node *signal,
+ unsigned long flags)
{
struct i915_dependency *dep;
@@ -473,8 +474,7 @@ int i915_sched_node_add_dependency(struct i915_sched_node
*node,
local_bh_disable();
if (!__i915_sched_node_add_dependency(node, signal, dep,
- I915_DEPENDENCY_EXTERNAL |
-
[Intel-gfx] [PATCH i-g-t 1/2] i915/gem_exec_schedule: Exercise timeslicing along an engine
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 107 +
1 file changed, 107 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 7274ffbf3..a1523277b 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -418,6 +418,110 @@ static void smoketest(int fd, unsigned ring, unsigned
timeout)
}
}
+static uint32_t timeslicing_batches(int i915, uint32_t *offset)
+{
+uint32_t handle = gem_create(i915, 4096);
+uint32_t cs[256];
+
+ *offset += 4000;
+ for (int pair = 0; pair <= 1; pair++) {
+ int x = 1;
+ int i = 0;
+
+ for (int step = 0; step < 8; step++) {
+ if (pair) {
+ cs[i++] =
+ MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD |
+ (4 - 2);
+ cs[i++] = x++;
+ cs[i++] = *offset;
+ cs[i++] = 0;
+ }
+
+ cs[i++] = MI_STORE_DWORD_IMM;
+ cs[i++] = *offset;
+ cs[i++] = 0;
+ cs[i++] = x++;
+
+ if (!pair) {
+ cs[i++] =
+ MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD |
+ (4 - 2);
+ cs[i++] = x++;
+ cs[i++] = *offset;
+ cs[i++] = 0;
+ }
+ }
+
+ cs[i++] = MI_BATCH_BUFFER_END;
+ igt_assert(i < ARRAY_SIZE(cs));
+ gem_write(i915, handle, pair * sizeof(cs), cs, sizeof(cs));
+ }
+
+ *offset = sizeof(cs);
+return handle;
+}
+
+static void semaphore_timeslice(int i915, unsigned int engine)
+{
+ unsigned int offset = 24 << 20;
+ struct drm_i915_gem_exec_object2 obj = {
+ .offset = offset,
+ .flags = EXEC_OBJECT_PINNED,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ uint32_t result;
+ int out;
+
+ /*
+* Create a pair of interlocking batches, that ping pong
+* between each other, and only advance one step at a time.
+* We require the kernel to preempt at each semaphore and
+* switch to the other batch in order to advance.
+*/
+
+ igt_require(gem_scheduler_has_semaphores(i915));
+ igt_require(gem_scheduler_has_preemption(i915));
+ igt_require(intel_gen(intel_get_drm_devid(i915)) >= 8);
+
+ obj.handle = timeslicing_batches(i915, );
+
+ execbuf.flags = engine | I915_EXEC_FENCE_OUT;
+ execbuf.batch_start_offset = 0;
+ gem_execbuf_wr(i915, );
+
+ /* No coupling between requests; free to timeslice */
+
+ execbuf.rsvd1 = gem_context_clone_with_engines(i915, 0);
+ execbuf.rsvd2 >>= 32;
+ execbuf.flags = engine | I915_EXEC_FENCE_OUT;
+ execbuf.batch_start_offset = offset;
+ gem_execbuf_wr(i915, );
+ gem_context_destroy(i915, execbuf.rsvd1);
+
+ gem_sync(i915, obj.handle);
+
+ /* no hangs! */
+ out = execbuf.rsvd2;
+ igt_assert_eq(sync_fence_status(out), 1);
+ close(out);
+
+ out = execbuf.rsvd2 >> 32;
+ igt_assert_eq(sync_fence_status(out), 1);
+ close(out);
+
+ gem_read(i915, obj.handle, 4000, , sizeof(result));
+ igt_assert_eq(result, 16);
+ gem_close(i915, obj.handle);
+}
+
static uint32_t __batch_create(int i915, uint32_t offset)
{
const uint32_t bbe = MI_BATCH_BUFFER_END;
@@ -2128,6 +2232,9 @@ igt_main
igt_require(gem_scheduler_has_ctx_priority(fd));
}
+ test_each_engine("timeslicing", fd, e)
+ semaphore_timeslice(fd, e->flags);
+
igt_subtest("semaphore-user")
semaphore_userlock(fd);
igt_subtest("semaphore-codependency")
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] i915/gem_exec_fence: Exercise timeslicing on submit-fence
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_fence.c | 124
1 file changed, 124 insertions(+)
diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
index 4b0d87e4d..a75188c9c 100644
--- a/tests/i915/gem_exec_fence.c
+++ b/tests/i915/gem_exec_fence.c
@@ -46,6 +46,15 @@ struct sync_merge_data {
#define SYNC_IOC_MERGE _IOWR(SYNC_IOC_MAGIC, 3, struct sync_merge_data)
#endif
+#define MI_SEMAPHORE_WAIT (0x1c << 23)
+#define MI_SEMAPHORE_POLL (1 << 15)
+#define MI_SEMAPHORE_SAD_GT_SDD (0 << 12)
+#define MI_SEMAPHORE_SAD_GTE_SDD (1 << 12)
+#define MI_SEMAPHORE_SAD_LT_SDD (2 << 12)
+#define MI_SEMAPHORE_SAD_LTE_SDD (3 << 12)
+#define MI_SEMAPHORE_SAD_EQ_SDD (4 << 12)
+#define MI_SEMAPHORE_SAD_NEQ_SDD (5 << 12)
+
static void store(int fd, const struct intel_execution_engine2 *e,
int fence, uint32_t target, unsigned offset_value)
{
@@ -376,6 +385,109 @@ static void test_fence_await(int fd, const struct
intel_execution_engine2 *e,
gem_close(fd, scratch);
}
+static uint32_t timeslicing_batches(int i915, uint32_t *offset)
+{
+uint32_t handle = gem_create(i915, 4096);
+uint32_t cs[256];
+
+ *offset += 4000;
+ for (int pair = 0; pair <= 1; pair++) {
+ int x = 1;
+ int i = 0;
+
+ for (int step = 0; step < 8; step++) {
+ if (pair) {
+ cs[i++] =
+ MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD |
+ (4 - 2);
+ cs[i++] = x++;
+ cs[i++] = *offset;
+ cs[i++] = 0;
+ }
+
+ cs[i++] = MI_STORE_DWORD_IMM;
+ cs[i++] = *offset;
+ cs[i++] = 0;
+ cs[i++] = x++;
+
+ if (!pair) {
+ cs[i++] =
+ MI_SEMAPHORE_WAIT |
+ MI_SEMAPHORE_POLL |
+ MI_SEMAPHORE_SAD_EQ_SDD |
+ (4 - 2);
+ cs[i++] = x++;
+ cs[i++] = *offset;
+ cs[i++] = 0;
+ }
+ }
+
+ cs[i++] = MI_BATCH_BUFFER_END;
+ igt_assert(i < ARRAY_SIZE(cs));
+ gem_write(i915, handle, pair * sizeof(cs), cs, sizeof(cs));
+ }
+
+ *offset = sizeof(cs);
+return handle;
+}
+
+static void test_submit_fence(int i915, unsigned int engine)
+{
+ const struct intel_execution_engine2 *e;
+
+ /*
+* Create a pair of interlocking batches, that ping pong
+* between each other, and only advance one step at a time.
+* We require the kernel to preempt at each semaphore and
+* switch to the other batch in order to advance.
+*/
+
+ __for_each_physical_engine(i915, e) {
+ unsigned int offset = 24 << 20;
+ struct drm_i915_gem_exec_object2 obj = {
+ .offset = offset,
+ .flags = EXEC_OBJECT_PINNED,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ };
+ uint32_t result;
+ int out;
+
+ obj.handle = timeslicing_batches(i915, );
+
+ execbuf.flags = engine | I915_EXEC_FENCE_OUT;
+ execbuf.batch_start_offset = 0;
+ gem_execbuf_wr(i915, );
+
+ execbuf.rsvd1 = gem_context_clone_with_engines(i915, 0);
+ execbuf.rsvd2 >>= 32;
+ execbuf.flags = e->flags;
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT | I915_EXEC_FENCE_OUT;
+ execbuf.batch_start_offset = offset;
+ gem_execbuf_wr(i915, );
+ gem_context_destroy(i915, execbuf.rsvd1);
+
+ gem_sync(i915, obj.handle);
+
+ /* no hangs! */
+ out = execbuf.rsvd2;
+ igt_assert_eq(sync_fence_status(out), 1);
+ close(out);
+
+ out = execbuf.rsvd2 >> 32;
+ igt_assert_eq(sync_fence_status(out), 1);
+ close(out);
+
+ gem_read(i915, obj.handle, 4000, , sizeof(result));
+ igt_assert_eq(result, 16);
+ gem_close(i915, obj.handle);
+ }
+}
+
static void resubmit(int fd, uint32_t handle,
const struct intel_execution_engine2 *e, int count)
{
@@
Re: [Intel-gfx] [PATCH v6 03/16] drm/i915: WARN if HDCP signalling is enabled upon disable
On 2020-04-29 at 15:54:49 -0400, Sean Paul wrote: > From: Sean Paul > > HDCP signalling should not be left on, WARN if it is > > Cc: Ville Syrjälä > Cc: Daniel Vetter > Reviewed-by: Ramalingam C Just reconfirming the R-b. -Ram > Signed-off-by: Sean Paul > Link: > https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run > #v2 > Link: > https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-4-s...@poorly.run > #v3 > Link: > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-4-s...@poorly.run > #v4 > Link: > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-4-s...@poorly.run > #v5 > > Changes in v2: > -Added to the set in lieu of just clearing the bit > Changes in v3: > -None > Changes in v4: > -None > Changes in v5: > -Change WARN_ON to drm_WARN_ON > Changes in v6: > -None > --- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > b/drivers/gpu/drm/i915/display/intel_ddi.c > index 5601673c3f30..08844ba9dcb5 100644 > --- a/drivers/gpu/drm/i915/display/intel_ddi.c > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > @@ -1663,6 +1663,8 @@ void intel_ddi_disable_transcoder_func(const struct > intel_crtc_state *crtc_state > > ctl = intel_de_read(dev_priv, TRANS_DDI_FUNC_CTL(cpu_transcoder)); > > + drm_WARN_ON(crtc->base.dev, ctl & TRANS_DDI_HDCP_SIGNALLING); > + > ctl &= ~TRANS_DDI_FUNC_ENABLE; > > if (IS_GEN_RANGE(dev_priv, 8, 10)) > -- > Sean Paul, Software Engineer, Google / Chromium OS > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 04/16] drm/i915: Intercept Aksv writes in the aux hooks
On 2020-04-29 at 15:54:50 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
> aux messages and add the aksv flag in the aux transfer hook.
>
> IIRC, this was the original implementation and folks wanted this hack to
> be isolated to the hdcp code, which makes sense.
>
> However in testing an LG monitor on my desk, I noticed it was passing
> back a DEFER reply. This wasn't handled in our hand-rolled code and HDCP
> auth was failing as a result. Instead of copy/pasting all of the retry
> logic and delays from drm dp helpers, let's just use the helpers and hide
> the aksv select as best as we can.
>
> Reviewed-by: Ville Syrjälä
> Reviewed-by: Ramalingam C
Just reconfirming my R-b here. LGTM
Reviewed-by: Ramalingam C
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-3-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-5-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-5-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-5-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-5-s...@poorly.run
> #v5
>
> Changes in v2:
> -Remove 'generate' in intel_dp_aux_generate_xfer_flags, make arg const (Ville)
> -Bundle Aksv if statement together (Ville)
> -Rename 'txbuf' to 'aksv' (Ville)
> Changes in v3:
> -None
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -None
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 63 -
> 1 file changed, 29 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 6952b0295096..f33b3e273e05 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1550,12 +1550,27 @@ intel_dp_aux_header(u8 txbuf[HEADER_SIZE],
> txbuf[3] = msg->size - 1;
> }
>
> +static u32 intel_dp_aux_xfer_flags(const struct drm_dp_aux_msg *msg)
> +{
> + /*
> + * If we're trying to send the HDCP Aksv, we need to set a the Aksv
> + * select bit to inform the hardware to send the Aksv after our header
> + * since we can't access that data from software.
> + */
> + if ((msg->request & ~DP_AUX_I2C_MOT) == DP_AUX_NATIVE_WRITE &&
> + msg->address == DP_AUX_HDCP_AKSV)
> + return DP_AUX_CH_CTL_AUX_AKSV_SELECT;
> +
> + return 0;
> +}
> +
> static ssize_t
> intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> {
> struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
> u8 txbuf[20], rxbuf[20];
> size_t txsize, rxsize;
> + u32 flags = intel_dp_aux_xfer_flags(msg);
> int ret;
>
> intel_dp_aux_header(txbuf, msg);
> @@ -1576,7 +1591,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> memcpy(txbuf + HEADER_SIZE, msg->buffer, msg->size);
>
> ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
> - rxbuf, rxsize, 0);
> + rxbuf, rxsize, flags);
> if (ret > 0) {
> msg->reply = rxbuf[0] >> 4;
>
> @@ -1599,7 +1614,7 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct
> drm_dp_aux_msg *msg)
> return -E2BIG;
>
> ret = intel_dp_aux_xfer(intel_dp, txbuf, txsize,
> - rxbuf, rxsize, 0);
> + rxbuf, rxsize, flags);
> if (ret > 0) {
> msg->reply = rxbuf[0] >> 4;
> /*
> @@ -6553,17 +6568,9 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> u8 *an)
> {
> struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> - struct intel_dp *intel_dp =
> enc_to_intel_dp(to_intel_encoder(_dig_port->base.base));
> - static const struct drm_dp_aux_msg msg = {
> - .request = DP_AUX_NATIVE_WRITE,
> - .address = DP_AUX_HDCP_AKSV,
> - .size = DRM_HDCP_KSV_LEN,
> - };
> - u8 txbuf[HEADER_SIZE + DRM_HDCP_KSV_LEN] = {}, rxbuf[2], reply = 0;
> + u8 aksv[DRM_HDCP_KSV_LEN] = {};
> ssize_t dpcd_ret;
> - int ret;
>
> - /* Output An first, that's easy */
> dpcd_ret = drm_dp_dpcd_write(_dig_port->dp.aux, DP_AUX_HDCP_AN,
>an, DRM_HDCP_AN_LEN);
> if (dpcd_ret != DRM_HDCP_AN_LEN) {
> @@ -6574,31 +6581,19 @@ int intel_dp_hdcp_write_an_aksv(struct
> intel_digital_port *intel_dig_port,
> }
>
> /*
> - * Since Aksv is Oh-So-Secret, we can't access it in software. So in
> - *
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer (rev4)
URL : https://patchwork.freedesktop.org/series/73036/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433 -> Patchwork_17589
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17589:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/fi-tgl-dsi/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/fi-tgl-dsi/igt@i915_module_l...@reload.html
- {fi-tgl-u}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/fi-tgl-u/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/fi-tgl-u/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_17589 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@perf:
- fi-bwr-2160:[PASS][5] -> [INCOMPLETE][6] ([i915#489])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/fi-bwr-2160/igt@i915_selftest@l...@perf.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/fi-bwr-2160/igt@i915_selftest@l...@perf.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489
Participating hosts (51 -> 43)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8433 -> Patchwork_17589
CI-20190529: 20190529
CI_DRM_8433: db68fed086f2ddcdc30e0d9ca5faaba5e55d0d01 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5633: c8c2e5ed5cd8e4b7a69a903f3f1653612086abcc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17589: 6353a74d2b4ce9736369c905a92f0d2ec45651e6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
6353a74d2b4c drm/i915/dsb: Pre allocate and late cleanup of cmd buffer
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17589/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 02/16] drm/i915: Clear the repeater bit on HDCP disable
On 2020-04-29 at 15:54:48 -0400, Sean Paul wrote:
> From: Sean Paul
>
> On HDCP disable, clear the repeater bit. This ensures if we connect a
> non-repeater sink after a repeater, the bit is in the state we expect.
>
> Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
> Cc: Chris Wilson
> Cc: Ramalingam C
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v4.17+
> Reviewed-by: Ramalingam C
Just reconfirming my R-b here.
Reviewed-by: Ramalingam C
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-3-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-3-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-3-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-3-s...@poorly.run
> #v5
>
> Changes in v2:
> -Added to the set
> Changes in v3:
> -None
> I had previously agreed that clearing the rep_ctl bits on enable would
> also be a good idea. However when I committed that idea to code, it
> didn't look right. So let's rely on enables and disables being paired
> and everything outside of that will be considered a bug
> Changes in v4:
> -s/I915_(READ|WRITE)/intel_de_(read|write)/
> Changes in v5:
> -None
> Changes in v6:
> -None
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 525658fd201f..20175a53643d 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -795,6 +795,7 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> struct intel_hdcp *hdcp = >hdcp;
> enum port port = intel_dig_port->base.port;
> enum transcoder cpu_transcoder = hdcp->cpu_transcoder;
> + u32 repeater_ctl;
> int ret;
>
> drm_dbg_kms(_priv->drm, "[%s:%d] HDCP is being disabled...\n",
> @@ -810,6 +811,11 @@ static int _intel_hdcp_disable(struct intel_connector
> *connector)
> return -ETIMEDOUT;
> }
>
> + repeater_ctl = intel_hdcp_get_repeater_ctl(dev_priv, cpu_transcoder,
> +port);
> + intel_de_write(dev_priv, HDCP_REP_CTL,
> +intel_de_read(dev_priv, HDCP_REP_CTL) & ~repeater_ctl);
> +
> ret = hdcp->shim->toggle_signalling(intel_dig_port, false);
> if (ret) {
> drm_err(_priv->drm, "Failed to disable HDCP signalling\n");
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 01/16] drm/i915: Fix sha_text population code
On 2020-04-29 at 15:54:47 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch fixes a few bugs:
>
> 1- We weren't taking into account sha_leftovers when adding multiple
>ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
>the beginning of ksv[j]
>
> 2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
>being placed on the wrong half of sha_text, overlapping the leftover
>ksv value
>
> 3- In the sha_leftovers == 2 case, we need to manually terminate the
>byte stream with 0x80 since the hardware doesn't have enough room to
>add it after writing M0
>
> The upside is that all of the HDCP supported HDMI repeaters I could
> find on Amazon just strip HDCP anyways, so it turns out to be _really_
> hard to hit any of these cases without an MST hub, which is not (yet)
> supported. Oh, and the sha_leftovers == 1 case works perfectly!
>
> Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
> Cc: Chris Wilson
> Cc: Ramalingam C
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v4.17+
> Reviewed-by: Ramalingam C
Just reconfirming my R-b here.
Reviewed-by: Ramalingam C
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-2-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-2-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-2-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-2-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-2-s...@poorly.run
> #v5
>
> Changes in v2:
> -None
> Changes in v3:
> -None
> Changes in v4:
> -Rebased on intel_de_write changes
> Changes in v5:
> -None
> Changes in v6:
> -None
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 26 +--
> include/drm/drm_hdcp.h| 3 +++
> 2 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 2cbc4619b4ce..525658fd201f 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -336,8 +336,10 @@ int intel_hdcp_validate_v_prime(struct intel_connector
> *connector,
>
> /* Fill up the empty slots in sha_text and write it out */
> sha_empty = sizeof(sha_text) - sha_leftovers;
> - for (j = 0; j < sha_empty; j++)
> - sha_text |= ksv[j] << ((sizeof(sha_text) - j - 1) * 8);
> + for (j = 0; j < sha_empty; j++) {
> + u8 off = ((sizeof(sha_text) - j - 1 - sha_leftovers) *
> 8);
> + sha_text |= ksv[j] << off;
> + }
>
> ret = intel_write_sha_text(dev_priv, sha_text);
> if (ret < 0)
> @@ -435,7 +437,7 @@ int intel_hdcp_validate_v_prime(struct intel_connector
> *connector,
> /* Write 32 bits of text */
> intel_de_write(dev_priv, HDCP_REP_CTL,
> rep_ctl | HDCP_SHA1_TEXT_32);
> - sha_text |= bstatus[0] << 24 | bstatus[1] << 16;
> + sha_text |= bstatus[0] << 8 | bstatus[1];
> ret = intel_write_sha_text(dev_priv, sha_text);
> if (ret < 0)
> return ret;
> @@ -450,17 +452,29 @@ int intel_hdcp_validate_v_prime(struct intel_connector
> *connector,
> return ret;
> sha_idx += sizeof(sha_text);
> }
> +
> + /*
> + * Terminate the SHA-1 stream by hand. For the other leftover
> + * cases this is appended by the hardware.
> + */
> + intel_de_write(dev_priv, HDCP_REP_CTL,
> +rep_ctl | HDCP_SHA1_TEXT_32);
> + sha_text = DRM_HDCP_SHA1_TERMINATOR << 24;
> + ret = intel_write_sha_text(dev_priv, sha_text);
> + if (ret < 0)
> + return ret;
> + sha_idx += sizeof(sha_text);
> } else if (sha_leftovers == 3) {
> - /* Write 32 bits of text */
> + /* Write 32 bits of text (filled from LSB) */
> intel_de_write(dev_priv, HDCP_REP_CTL,
> rep_ctl | HDCP_SHA1_TEXT_32);
> - sha_text |= bstatus[0] << 24;
> + sha_text |= bstatus[0];
> ret = intel_write_sha_text(dev_priv, sha_text);
> if (ret < 0)
> return ret;
> sha_idx += sizeof(sha_text);
>
> - /* Write 8 bits of text, 24 bits of M0 */
> + /* Write 8 bits of text (filled from LSB), 24 bits of M0 */
>
Re: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC for PHY's A and B
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 10/22] drm/i915/rkl: RKL only uses PHY_MISC for
> PHY's A and B
>
> Since the number of platforms with this restriction are growing, let's
> separate
> out the platform logic into a has_phy_misc() function.
>
> Bspec: 50107
> Signed-off-by: Matt Roper
> ---
> .../gpu/drm/i915/display/intel_combo_phy.c| 30 +++
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 9ff05ec12115..43d8784f6fa0 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -181,11 +181,25 @@ static void cnl_combo_phys_uninit(struct
> drm_i915_private *dev_priv)
> intel_de_write(dev_priv, CHICKEN_MISC_2, val); }
>
> +static bool has_phy_misc(struct drm_i915_private *i915, enum phy phy) {
> + /*
> + * Some platforms only expect PHY_MISC to be programmed for PHY-A
> and
> + * PHY-B and may not even have instances of the register for the
> + * other combo PHY's.
> + */
> + if (IS_ELKHARTLAKE(i915) ||
> + IS_ROCKETLAKE(i915))
> + return phy < PHY_C;
According BSpec 50107, there is an instance of this for combo PHY C as well.
Anusha
> +
> + return true;
> +}
> +
> static bool icl_combo_phy_enabled(struct drm_i915_private *dev_priv,
> enum phy phy)
> {
> /* The PHY C added by EHL has no PHY_MISC register */
> - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> + if (!has_phy_misc(dev_priv, phy))
> return intel_de_read(dev_priv, ICL_PORT_COMP_DW0(phy))
> & COMP_INIT;
> else
> return !(intel_de_read(dev_priv, ICL_PHY_MISC(phy)) & @@ -
> 317,12 +331,7 @@ static void icl_combo_phys_init(struct drm_i915_private
> *dev_priv)
> continue;
> }
>
> - /*
> - * Although EHL adds a combo PHY C, there's no PHY_MISC
> - * register for it and no need to program the
> - * DE_IO_COMP_PWR_DOWN setting on PHY C.
> - */
> - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> + if (!has_phy_misc(dev_priv, phy))
> goto skip_phy_misc;
>
> /*
> @@ -376,12 +385,7 @@ static void icl_combo_phys_uninit(struct
> drm_i915_private *dev_priv)
>"Combo PHY %c HW state changed
> unexpectedly\n",
>phy_name(phy));
>
> - /*
> - * Although EHL adds a combo PHY C, there's no PHY_MISC
> - * register for it and no need to program the
> - * DE_IO_COMP_PWR_DOWN setting on PHY C.
> - */
> - if (IS_ELKHARTLAKE(dev_priv) && phy == PHY_C)
> + if (!has_phy_misc(dev_priv, phy))
> goto skip_phy_misc;
>
> val = intel_de_read(dev_priv, ICL_PHY_MISC(phy));
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Plumb crtc state to link training code (rev2)
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev2)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433_full -> Patchwork_17588_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17588_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process@vcs0:
- shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-skl4/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@vcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#716])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-glk6/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-glk8/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_cursor_crc@pipe-b-cursor-suspend:
- shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-kbl4/igt@kms_cursor_...@pipe-b-cursor-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-suspend.html
* igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl: [PASS][7] -> [FAIL][8] ([IGT#5])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-skl5/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-legacy.html
* igt@kms_flip_tiling@flip-changes-tiling:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#699] / [i915#93] /
[i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-kbl4/igt@kms_flip_til...@flip-changes-tiling.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-kbl4/igt@kms_flip_til...@flip-changes-tiling.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#1188]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-skl1/igt@kms_...@bpc-switch-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-skl9/igt@kms_...@bpc-switch-dpms.html
* igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +3 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-iclb3/igt@kms_psr@psr2_cursor_plane_onoff.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-apl3/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-apl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-c-accuracy-idle:
- shard-skl: [PASS][17] -> [FAIL][18] ([i915#43])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-skl3/igt@kms_vbl...@pipe-c-accuracy-idle.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-skl1/igt@kms_vbl...@pipe-c-accuracy-idle.html
Possible fixes
* igt@gem_ctx_persistence@engines-mixed-process@vecs0:
- shard-skl: [FAIL][19] ([i915#1528]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-skl4/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-skl10/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html
* {igt@kms_flip@flip-vs-suspend-interruptible@a-dp1}:
- shard-kbl: [DMESG-WARN][21] ([i915#180]) -> [PASS][22] +3
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-kbl1/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-kbl3/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html
* {igt@kms_flip@flip-vs-suspend-interruptible@c-dp1}:
- shard-apl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2
similar issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/shard-apl1/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html
*
Re: [Intel-gfx] [PATCH v27 3/6] drm/i915: Add TGL+ SAGV support
On Wed, May 06, 2020 at 04:16:36PM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 03:12:10PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> > > On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > > > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > > > On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > > > > > Starting from TGL we need to have a separate wm0
> > > > > > values for SAGV and non-SAGV which affects
> > > > > > how calculations are done.
> > > > > >
> > > > > > v2: Remove long lines
> > > > > > v3: Removed COLOR_PLANE enum references
> > > > > > v4, v5, v6: Fixed rebase conflict
> > > > > >
> > > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/display/intel_display.c | 8 +-
> > > > > > .../drm/i915/display/intel_display_types.h| 3 +
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 128
> > > > > > +-
> > > > > > 3 files changed, 130 insertions(+), 9 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > index fd6d63b03489..be5741cb7595 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > @@ -13961,7 +13961,9 @@ static void verify_wm_state(struct
> > > > > > intel_crtc *crtc,
> > > > > > /* Watermarks */
> > > > > > for (level = 0; level <= max_level; level++) {
> > > > > > if (skl_wm_level_equals(_plane_wm->wm[level],
> > > > > > -
> > > > > > _plane_wm->wm[level]))
> > > > > > +
> > > > > > _plane_wm->wm[level]) ||
> > > > > > + (level == 0 &&
> > > > > > skl_wm_level_equals(_plane_wm->wm[level],
> > > > > > +
> > > > > > _plane_wm->sagv_wm0)))
> > > > > > continue;
> > > > > >
> > > > > > drm_err(_priv->drm,
> > > > > > @@ -14016,7 +14018,9 @@ static void verify_wm_state(struct
> > > > > > intel_crtc *crtc,
> > > > > > /* Watermarks */
> > > > > > for (level = 0; level <= max_level; level++) {
> > > > > > if (skl_wm_level_equals(_plane_wm->wm[level],
> > > > > > -
> > > > > > _plane_wm->wm[level]))
> > > > > > +
> > > > > > _plane_wm->wm[level]) ||
> > > > > > + (level == 0 &&
> > > > > > skl_wm_level_equals(_plane_wm->wm[level],
> > > > > > +
> > > > > > _plane_wm->sagv_wm0)))
> > > > > > continue;
> > > > > >
> > > > > > drm_err(_priv->drm,
> > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > index 9488449e4b94..32cbbf7dddc6 100644
> > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > > @@ -688,11 +688,14 @@ struct skl_plane_wm {
> > > > > > struct skl_wm_level wm[8];
> > > > > > struct skl_wm_level uv_wm[8];
> > > > > > struct skl_wm_level trans_wm;
> > > > > > + struct skl_wm_level sagv_wm0;
> > > > > > + struct skl_wm_level uv_sagv_wm0;
> > > > >
> > > > > As mentioned before uv_wm is not a thing on icl+, so nuke this.
> > > >
> > > > This is used in skl_plane_wm_level accessor, which is used for all
> > > > platforms, not just icl+. I remember we had agreed that for all
> > > > platforms
> > > > before tgl I simply copy sagv_wm0 values from regular wm0, so that this
> > > > behaviour is unified(remember that your comment about memcpy which I
> > > > changed
> > > > to assignment, see skl_compute_sagv_wm).
> > >
> > > I think having that duplicated is just making things more confusing.
> > > Also uv_wm is never used by the hardware even on pre-icl, so having
> > > the accessor thing use it for the hw programming just doesn't make
> > > any sense.
> >
> > Problem is that we use it in skl_allocate_pipe_ddb in a few places:
> >
> > blocks += wm_level->min_ddb_alloc;
> > blocks += wm_uv_level->min_ddb_alloc;
>
> I don't think we should need any accessor in there. If we do
> what I suggested earlier, which I think was something like
> (can't find the mail anymore unfortunately):
>
> for reverse wm levels {
> blocks = sum(wm[level] blocks for all planes) +
> sum(uv_wm[level] blocks for all planes)
> ...
> if (block <= alloc_size)
> break;
> }
>
> if (level < 0)
> fail;
>
> blocks_sagv = sum(sagv_wm
Re: [Intel-gfx] [PATCH v4 04/11] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3.
Op 01-05-2020 om 01:09 schreef Manasi Navare: > From: Maarten Lankhorst > > Small changes to intel_dp_mode_valid(), allow listing modes that > can only be supported in the bigjoiner configuration, which is > not supported yet. > > eDP does not support bigjoiner, so do not expose bigjoiner only > modes on the eDP port. > > Changes since v1: > - Disallow bigjoiner on eDP. > Changes since v2: > - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, > and split off the downstream and source checking to its own function. > (Ville) > v3: > * Rebase (Manasi) > > Signed-off-by: Manasi Navare > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/i915/display/intel_dp.c | 117 ++-- > 1 file changed, 89 insertions(+), 28 deletions(-) Hey, With this patch, the 8k mode is still rejected because h limits are not increased on DP: [ 3762.916623] i915 :00:02.0: [drm:intel_dp_dsc_get_output_bpp [i915]] Max link bpp: 12 [ 3762.916663] i915 :00:02.0: [drm:intel_dp_dsc_get_output_bpp [i915]] Max small joiner bpp: 16 [ 3762.916702] [drm:intel_dp_dsc_get_output_bpp [i915]] Max big joiner bpp: 14 [ 3762.916706] [drm:drm_mode_debug_printmodeline] Modeline "7680x4320": 60 2068660 7680 7688 7720 7760 4320 4429 4437 4443 0x48 0x9 [ 3762.916709] [drm:drm_mode_prune_invalid] Not using 7680x4320 mode: H_ILLEGAL I would suggest tweaking intel_mode_valid_max_plane_size to make this work. :) ~Maarten ___ 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: Fix glk watermark calculations
On Wed, May 06, 2020 at 04:17:20PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Apr 30, 2020 at 03:58:21PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > GLK wants the +1 adjustement for the "blocks per line" value
> > for x-tile/y-tile, just like cnl+.
> >
> > Also the x-tile and linear cases are almost identical. The only
> > difference is this +1 which is always done for glk+, and only
> > done for linear on skl/bxt. Let's unify it to a single branch
> > with a special case for the +1, just like we do for y-tile.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index bfb180fe8047..65a3236ce277 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -4810,7 +4810,7 @@ skl_wm_method1(const struct drm_i915_private
> > *dev_priv, u32 pixel_rate,
> > wm_intermediate_val = latency * pixel_rate * cpp;
> > ret = div_fixed16(wm_intermediate_val, 1000 * dbuf_block_size);
> >
> > - if (INTEL_GEN(dev_priv) >= 10)
> > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > ret = add_fixed16_u32(ret, 1);
> >
> > return ret;
> > @@ -4945,18 +4945,19 @@ skl_compute_wm_params(const struct intel_crtc_state
> > *crtc_state,
> >wp->y_min_scanlines,
> >wp->dbuf_block_size);
> >
> > - if (INTEL_GEN(dev_priv) >= 10)
> > + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > interm_pbpl++;
> >
> > wp->plane_blocks_per_line = div_fixed16(interm_pbpl,
> > wp->y_min_scanlines);
> > - } else if (wp->x_tiled && IS_GEN(dev_priv, 9)) {
> > - interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
> > - wp->dbuf_block_size);
> > - wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
> > } else {
> > interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
> > - wp->dbuf_block_size) + 1;
> > + wp->dbuf_block_size);
> > +
> > + if (!wp->x_tiled ||
> > + INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> > + interm_pbpl++;
> > +
>
> Is it so that we want +1 here only for x-tile,y-tile for GLK?
> Because I guess if you have linear mapping and GLK, this will do +1 as well.
glk+ always wants the +1.
pre-glk wants +1 only for linear.
>
> With this clarified,
>
> Reviewed-by: Stanislav Lisovskiy
>
> > wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
> > }
> >
> > --
> > 2.24.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915/dsb: Pre allocate and late cleanup of cmd buffer
Pre-allocate command buffer in atomic_commit using intel_dsb_prepare
function which also includes pinning and map in cpu domain.
No change is dsb write/commit functions.
Now dsb get/put function is refactored and currently used only for
reference counting. Below dsb api added to do respective job
mentioned below.
intel_dsb_prepare - Allocate, pin and map the buffer.
intel_dsb_cleanup - Unpin and release the gem object.
RFC: Initial patch for design review.
v2: included _init() part in _prepare(). [Daniel, Ville]
v3: dsb_cleanup called after cleanup_planes. [Daniel]
v4: dsb structure is moved to intel_crtc_state from intel_crtc. [Maarten]
v5: dsb get/put/ref-count mechanism removed. [Maarten]
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Daniel Vetter
Acked-by: Daniel Vetter
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_color.c| 27 ++-
drivers/gpu/drm/i915/display/intel_display.c | 60 -
.../drm/i915/display/intel_display_types.h| 6 +-
drivers/gpu/drm/i915/display/intel_dsb.c | 207 +-
drivers/gpu/drm/i915/display/intel_dsb.h | 8 +-
5 files changed, 178 insertions(+), 130 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 98ece9cd7cdd..dba820136106 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -717,7 +717,8 @@ static void bdw_load_lut_10(struct intel_crtc *crtc,
static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_dsb *dsb = intel_dsb_get(crtc);
+ struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
+ struct intel_dsb *dsb = (struct intel_dsb *)_state->dsb;
enum pipe pipe = crtc->pipe;
/* Program the max register to clamp values > 1.0. */
@@ -738,8 +739,6 @@ static void ivb_load_lut_ext_max(struct intel_crtc *crtc)
intel_dsb_reg_write(dsb, PREC_PAL_EXT2_GC_MAX(pipe, 2),
1 << 16);
}
-
- intel_dsb_put(dsb);
}
static void ivb_load_luts(const struct intel_crtc_state *crtc_state)
@@ -900,14 +899,13 @@ icl_load_gcmax(const struct intel_crtc_state *crtc_state,
const struct drm_color_lut *color)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- struct intel_dsb *dsb = intel_dsb_get(crtc);
+ struct intel_dsb *dsb = (struct intel_dsb *)_state->dsb;
enum pipe pipe = crtc->pipe;
/* FIXME LUT entries are 16 bit only, so we can prog 0x max */
intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 0), color->red);
intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 1), color->green);
intel_dsb_reg_write(dsb, PREC_PAL_GC_MAX(pipe, 2), color->blue);
- intel_dsb_put(dsb);
}
static void
@@ -916,7 +914,7 @@ icl_program_gamma_superfine_segment(const struct
intel_crtc_state *crtc_state)
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct drm_property_blob *blob = crtc_state->hw.gamma_lut;
const struct drm_color_lut *lut = blob->data;
- struct intel_dsb *dsb = intel_dsb_get(crtc);
+ struct intel_dsb *dsb = (struct intel_dsb *)_state->dsb;
enum pipe pipe = crtc->pipe;
int i;
@@ -938,8 +936,6 @@ icl_program_gamma_superfine_segment(const struct
intel_crtc_state *crtc_state)
intel_dsb_indexed_reg_write(dsb, PREC_PAL_MULTI_SEG_DATA(pipe),
ilk_lut_12p4_udw(entry));
}
-
- intel_dsb_put(dsb);
}
static void
@@ -949,7 +945,7 @@ icl_program_gamma_multi_segment(const struct
intel_crtc_state *crtc_state)
const struct drm_property_blob *blob = crtc_state->hw.gamma_lut;
const struct drm_color_lut *lut = blob->data;
const struct drm_color_lut *entry;
- struct intel_dsb *dsb = intel_dsb_get(crtc);
+ struct intel_dsb *dsb = (struct intel_dsb *)_state->dsb;
enum pipe pipe = crtc->pipe;
int i;
@@ -996,14 +992,22 @@ icl_program_gamma_multi_segment(const struct
intel_crtc_state *crtc_state)
entry = [256 * 8 * 128];
icl_load_gcmax(crtc_state, entry);
ivb_load_lut_ext_max(crtc);
- intel_dsb_put(dsb);
}
static void icl_load_luts(const struct intel_crtc_state *crtc_state)
{
const struct drm_property_blob *gamma_lut = crtc_state->hw.gamma_lut;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- struct intel_dsb *dsb = intel_dsb_get(crtc);
+ struct intel_dsb *dsb = (struct intel_dsb *)_state->dsb;
+
+ /*
+* TODO: Currently dsb buffer filling is done in load_lut() which
+* can be done much earlier, like initial stage of atomic_commit().
+* As currently replacing the mmio-write with dsb-write so the
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix glk watermark calculations
On Thu, Apr 30, 2020 at 03:58:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> GLK wants the +1 adjustement for the "blocks per line" value
> for x-tile/y-tile, just like cnl+.
>
> Also the x-tile and linear cases are almost identical. The only
> difference is this +1 which is always done for glk+, and only
> done for linear on skl/bxt. Let's unify it to a single branch
> with a special case for the +1, just like we do for y-tile.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index bfb180fe8047..65a3236ce277 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4810,7 +4810,7 @@ skl_wm_method1(const struct drm_i915_private *dev_priv,
> u32 pixel_rate,
> wm_intermediate_val = latency * pixel_rate * cpp;
> ret = div_fixed16(wm_intermediate_val, 1000 * dbuf_block_size);
>
> - if (INTEL_GEN(dev_priv) >= 10)
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> ret = add_fixed16_u32(ret, 1);
>
> return ret;
> @@ -4945,18 +4945,19 @@ skl_compute_wm_params(const struct intel_crtc_state
> *crtc_state,
> wp->y_min_scanlines,
> wp->dbuf_block_size);
>
> - if (INTEL_GEN(dev_priv) >= 10)
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> interm_pbpl++;
>
> wp->plane_blocks_per_line = div_fixed16(interm_pbpl,
> wp->y_min_scanlines);
> - } else if (wp->x_tiled && IS_GEN(dev_priv, 9)) {
> - interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
> -wp->dbuf_block_size);
> - wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
> } else {
> interm_pbpl = DIV_ROUND_UP(wp->plane_bytes_per_line,
> -wp->dbuf_block_size) + 1;
> +wp->dbuf_block_size);
> +
> + if (!wp->x_tiled ||
> + INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + interm_pbpl++;
> +
Is it so that we want +1 here only for x-tile,y-tile for GLK?
Because I guess if you have linear mapping and GLK, this will do +1 as well.
With this clarified,
Reviewed-by: Stanislav Lisovskiy
> wp->plane_blocks_per_line = u32_to_fixed16(interm_pbpl);
> }
>
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v27 3/6] drm/i915: Add TGL+ SAGV support
On Wed, May 06, 2020 at 03:12:10PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> > On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > > On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > > > > Starting from TGL we need to have a separate wm0
> > > > > values for SAGV and non-SAGV which affects
> > > > > how calculations are done.
> > > > >
> > > > > v2: Remove long lines
> > > > > v3: Removed COLOR_PLANE enum references
> > > > > v4, v5, v6: Fixed rebase conflict
> > > > >
> > > > > Signed-off-by: Stanislav Lisovskiy
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 8 +-
> > > > > .../drm/i915/display/intel_display_types.h| 3 +
> > > > > drivers/gpu/drm/i915/intel_pm.c | 128
> > > > > +-
> > > > > 3 files changed, 130 insertions(+), 9 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index fd6d63b03489..be5741cb7595 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -13961,7 +13961,9 @@ static void verify_wm_state(struct intel_crtc
> > > > > *crtc,
> > > > > /* Watermarks */
> > > > > for (level = 0; level <= max_level; level++) {
> > > > > if (skl_wm_level_equals(_plane_wm->wm[level],
> > > > > -
> > > > > _plane_wm->wm[level]))
> > > > > +
> > > > > _plane_wm->wm[level]) ||
> > > > > + (level == 0 &&
> > > > > skl_wm_level_equals(_plane_wm->wm[level],
> > > > > +
> > > > > _plane_wm->sagv_wm0)))
> > > > > continue;
> > > > >
> > > > > drm_err(_priv->drm,
> > > > > @@ -14016,7 +14018,9 @@ static void verify_wm_state(struct intel_crtc
> > > > > *crtc,
> > > > > /* Watermarks */
> > > > > for (level = 0; level <= max_level; level++) {
> > > > > if (skl_wm_level_equals(_plane_wm->wm[level],
> > > > > -
> > > > > _plane_wm->wm[level]))
> > > > > +
> > > > > _plane_wm->wm[level]) ||
> > > > > + (level == 0 &&
> > > > > skl_wm_level_equals(_plane_wm->wm[level],
> > > > > +
> > > > > _plane_wm->sagv_wm0)))
> > > > > continue;
> > > > >
> > > > > drm_err(_priv->drm,
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > index 9488449e4b94..32cbbf7dddc6 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > > @@ -688,11 +688,14 @@ struct skl_plane_wm {
> > > > > struct skl_wm_level wm[8];
> > > > > struct skl_wm_level uv_wm[8];
> > > > > struct skl_wm_level trans_wm;
> > > > > + struct skl_wm_level sagv_wm0;
> > > > > + struct skl_wm_level uv_sagv_wm0;
> > > >
> > > > As mentioned before uv_wm is not a thing on icl+, so nuke this.
> > >
> > > This is used in skl_plane_wm_level accessor, which is used for all
> > > platforms, not just icl+. I remember we had agreed that for all platforms
> > > before tgl I simply copy sagv_wm0 values from regular wm0, so that this
> > > behaviour is unified(remember that your comment about memcpy which I
> > > changed
> > > to assignment, see skl_compute_sagv_wm).
> >
> > I think having that duplicated is just making things more confusing.
> > Also uv_wm is never used by the hardware even on pre-icl, so having
> > the accessor thing use it for the hw programming just doesn't make
> > any sense.
>
> Problem is that we use it in skl_allocate_pipe_ddb in a few places:
>
> blocks += wm_level->min_ddb_alloc;
> blocks += wm_uv_level->min_ddb_alloc;
I don't think we should need any accessor in there. If we do
what I suggested earlier, which I think was something like
(can't find the mail anymore unfortunately):
for reverse wm levels {
blocks = sum(wm[level] blocks for all planes) +
sum(uv_wm[level] blocks for all planes)
...
if (block <= alloc_size)
break;
}
if (level < 0)
fail;
blocks_sagv = sum(sagv_wm blocks for all planes)
if (blocks_sagv > blocks && blocks_sagv <= alloc_size) {
blocks = blocks_sagv;
use_sagv_wm = true;
} else {
use_sagv_wm = false;
}
alloc_size -= blocks;
for_each_plane_id() {
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Plumb crtc state to link training code (rev2)
== Series Details ==
Series: drm/i915: Plumb crtc state to link training code (rev2)
URL : https://patchwork.freedesktop.org/series/76993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8433 -> Patchwork_17588
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/index.html
Known issues
Here are the changes found in Patchwork_17588 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@reset:
- fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] ([i915#489])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8433/fi-bwr-2160/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/fi-bwr-2160/igt@i915_selftest@l...@reset.html
[i915#489]: https://gitlab.freedesktop.org/drm/intel/issues/489
Participating hosts (51 -> 43)
--
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_8433 -> Patchwork_17588
CI-20190529: 20190529
CI_DRM_8433: db68fed086f2ddcdc30e0d9ca5faaba5e55d0d01 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5633: c8c2e5ed5cd8e4b7a69a903f3f1653612086abcc @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17588: 8ec6f4b1e7f06bdfd404ecfdf54337e9f645261f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8ec6f4b1e7f0 drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl, status}
fa64a8214369 drm/i915: Plumb crtc_state to link training
2cb6124763bb drm/i915: Replace some hand rolled max()s
35e76930c74d drm/i915: Fix DP_TRAIN_MAX_{PRE_EMPHASIS, SWING}_REACHED handling
1e68b2953b0e drm/i915: Reverse preemph vs. voltage swing preference
3949c1110159 drm/i915: Add {preemph, voltage}_max() vfuncs
d80fba24e659 drm/i915: Fix ivb cpu edp vswing
18c9808e0356 drm/i915: Fix ibx max vswing/preemph
d43ebfb8437f drm/i915: Fix cpt/ppt max pre-emphasis
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17588/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 08/22] drm/i915/rkl: Add power well support
On 2020-05-05 at 19:09:54 +0300, Imre Deak wrote:
> On Tue, May 05, 2020 at 07:39:04AM -0700, Matt Roper wrote:
> > On Tue, May 05, 2020 at 10:20:58AM +0530, Anshuman Gupta wrote:
> > > On 2020-05-04 at 15:52:13 -0700, Matt Roper wrote:
> > > > RKL power wells are similar to TGL power wells, but have some important
> > > > differences:
> > > >
> > > > * PG1 now has pipe A's VDSC (rather than sticking it in PG2)
> > > > * PG2 no longer exists
> > > > * DDI-C (aka TC-1) moves from PG1 -> PG3
> > > > * PG5 no longer exists due to the lack of a fourth pipe
> > > >
> > > > Also note that what we refer to as 'DDI-C' and 'DDI-D' need to actually
> > > > be programmed as TC-1 and TC-2 even though this platform doesn't have TC
> > > > outputs.
Looks good to me.
Reviewed-by: Anshuman Gupta
> > > >
> > > > Bspec: 49234
> > > > Cc: Imre Deak
> > > > Cc: Lucas De Marchi
> > > > Cc: Anshuman Gupta
> > > > Signed-off-by: Matt Roper
> > > > ---
> > > > .../drm/i915/display/intel_display_power.c| 185 +-
> > > > drivers/gpu/drm/i915/display/intel_vdsc.c | 4 +-
> > > > 2 files changed, 186 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > index 49998906cc61..71691919d101 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > > @@ -2913,6 +2913,53 @@ void intel_display_power_put(struct
> > > > drm_i915_private *dev_priv,
> > > > BIT_ULL(POWER_DOMAIN_AUX_I_TBT) | \
> > > > BIT_ULL(POWER_DOMAIN_TC_COLD_OFF))
> > > >
> > > > +#define RKL_PW_4_POWER_DOMAINS ( \
> > > > + BIT_ULL(POWER_DOMAIN_PIPE_C) | \
> > > > + BIT_ULL(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
> > > > + BIT_ULL(POWER_DOMAIN_TRANSCODER_C) |\
> > > > + BIT_ULL(POWER_DOMAIN_INIT))
> > > > +
> > > > +#define RKL_PW_3_POWER_DOMAINS ( \
> > > > + RKL_PW_4_POWER_DOMAINS |\
> > > > + BIT_ULL(POWER_DOMAIN_PIPE_B) | \
> > > > + BIT_ULL(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
> > > > + BIT_ULL(POWER_DOMAIN_AUDIO) | \
> > > > + BIT_ULL(POWER_DOMAIN_VGA) | \
> > > > + BIT_ULL(POWER_DOMAIN_TRANSCODER_B) |\
> > > > + BIT_ULL(POWER_DOMAIN_PORT_DDI_D_LANES) |\
> > > > + BIT_ULL(POWER_DOMAIN_PORT_DDI_E_LANES) |\
> > > > + BIT_ULL(POWER_DOMAIN_AUX_D) | \
> > > > + BIT_ULL(POWER_DOMAIN_AUX_E) | \
> > > > + BIT_ULL(POWER_DOMAIN_INIT))
> > > > +
> > > > +/*
> > > > + * There is no PW_2/PG_2 on RKL.
> > > > + *
> > > > + * RKL PW_1/PG_1 domains (under HW/DMC control):
> > > > + * - DBUF function (note: registers are in PW0)
> > > > + * - PIPE_A and its planes and VDSC/joining, except VGA
> > > > + * - transcoder A
> > > > + * - DDI_A and DDI_B
> > > > + * - FBC
> > > > + *
> > > > + * RKL PW_0/PG_0 domains (under HW/DMC control):
> > > > + * - PCI
> > > > + * - clocks except port PLL
> > > > + * - shared functions:
> > > > + * * interrupts except pipe interrupts
> > > > + * * MBus except PIPE_MBUS_DBOX_CTL
> > > > + * * DBUF registers
> > > > + * - central power except FBC
> > > > + * - top-level GTC (DDI-level GTC is in the well associated with the
> > > > DDI)
> > > > + */
> > > > +
> > > > +#define RKL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > > > + RKL_PW_3_POWER_DOMAINS |\
> > > > + BIT_ULL(POWER_DOMAIN_MODESET) | \
> > > > + BIT_ULL(POWER_DOMAIN_AUX_A) | \
> > > > + BIT_ULL(POWER_DOMAIN_AUX_B) | \
> > > > + BIT_ULL(POWER_DOMAIN_INIT))
> > > > +
> > > > static const struct i915_power_well_ops i9xx_always_on_power_well_ops
> > > > = {
> > > > .sync_hw = i9xx_power_well_sync_hw_noop,
> > > > .enable = i9xx_always_on_power_well_noop,
> > > > @@ -4283,6 +4330,140 @@ static const struct i915_power_well_desc
> > > > tgl_power_wells[] = {
> > > > },
> > > > };
> > > >
> > > > +static const struct i915_power_well_desc rkl_power_wells[] = {
> > > > + {
> > > > + .name = "always-on",
> > > > + .always_on = true,
> > > > + .domains = POWER_DOMAIN_MASK,
> > > > + .ops = _always_on_power_well_ops,
> > > > + .id = DISP_PW_ID_NONE,
> > > > + },
> > > > + {
> > > > + .name = "power well 1",
> > > > + /* Handled by the DMC firmware */
> > > > + .always_on = true,
> > > > + .domains = 0,
> > > > + .ops = _power_well_ops,
> > > > + .id = SKL_DISP_PW_1,
> > > > + {
> > > > +
Re: [Intel-gfx] [PATCH v27 3/6] drm/i915: Add TGL+ SAGV support
On Wed, May 06, 2020 at 12:12:28PM +0300, Ville Syrjälä wrote:
> On Wed, May 06, 2020 at 11:31:05AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 05, 2020 at 01:59:11PM +0300, Ville Syrjälä wrote:
> > > On Tue, May 05, 2020 at 01:22:44PM +0300, Stanislav Lisovskiy wrote:
> > > > Starting from TGL we need to have a separate wm0
> > > > values for SAGV and non-SAGV which affects
> > > > how calculations are done.
> > > >
> > > > v2: Remove long lines
> > > > v3: Removed COLOR_PLANE enum references
> > > > v4, v5, v6: Fixed rebase conflict
> > > >
> > > > Signed-off-by: Stanislav Lisovskiy
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_display.c | 8 +-
> > > > .../drm/i915/display/intel_display_types.h| 3 +
> > > > drivers/gpu/drm/i915/intel_pm.c | 128 +-
> > > > 3 files changed, 130 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > index fd6d63b03489..be5741cb7595 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > @@ -13961,7 +13961,9 @@ static void verify_wm_state(struct intel_crtc
> > > > *crtc,
> > > > /* Watermarks */
> > > > for (level = 0; level <= max_level; level++) {
> > > > if (skl_wm_level_equals(_plane_wm->wm[level],
> > > > -
> > > > _plane_wm->wm[level]))
> > > > +
> > > > _plane_wm->wm[level]) ||
> > > > + (level == 0 &&
> > > > skl_wm_level_equals(_plane_wm->wm[level],
> > > > +
> > > > _plane_wm->sagv_wm0)))
> > > > continue;
> > > >
> > > > drm_err(_priv->drm,
> > > > @@ -14016,7 +14018,9 @@ static void verify_wm_state(struct intel_crtc
> > > > *crtc,
> > > > /* Watermarks */
> > > > for (level = 0; level <= max_level; level++) {
> > > > if (skl_wm_level_equals(_plane_wm->wm[level],
> > > > -
> > > > _plane_wm->wm[level]))
> > > > +
> > > > _plane_wm->wm[level]) ||
> > > > + (level == 0 &&
> > > > skl_wm_level_equals(_plane_wm->wm[level],
> > > > +
> > > > _plane_wm->sagv_wm0)))
> > > > continue;
> > > >
> > > > drm_err(_priv->drm,
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > index 9488449e4b94..32cbbf7dddc6 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > > > @@ -688,11 +688,14 @@ struct skl_plane_wm {
> > > > struct skl_wm_level wm[8];
> > > > struct skl_wm_level uv_wm[8];
> > > > struct skl_wm_level trans_wm;
> > > > + struct skl_wm_level sagv_wm0;
> > > > + struct skl_wm_level uv_sagv_wm0;
> > >
> > > As mentioned before uv_wm is not a thing on icl+, so nuke this.
> >
> > This is used in skl_plane_wm_level accessor, which is used for all
> > platforms, not just icl+. I remember we had agreed that for all platforms
> > before tgl I simply copy sagv_wm0 values from regular wm0, so that this
> > behaviour is unified(remember that your comment about memcpy which I changed
> > to assignment, see skl_compute_sagv_wm).
>
> I think having that duplicated is just making things more confusing.
> Also uv_wm is never used by the hardware even on pre-icl, so having
> the accessor thing use it for the hw programming just doesn't make
> any sense.
Problem is that we use it in skl_allocate_pipe_ddb in a few places:
blocks += wm_level->min_ddb_alloc;
blocks += wm_uv_level->min_ddb_alloc;
then those plane data rates:
rate = plane_data_rate[plane_id];
extra = min_t(u16, alloc_size,
DIV64_U64_ROUND_UP(alloc_size * rate, total_data_rate));
total[plane_id] = wm_level->min_ddb_alloc + extra;
alloc_size -= extra;
total_data_rate -= rate;
if (total_data_rate == 0)
break;
rate = uv_plane_data_rate[plane_id];
extra = min_t(u16, alloc_size,
DIV64_U64_ROUND_UP(alloc_size * rate, total_data_rate));
uv_total[plane_id] = wm_uv_level->min_ddb_alloc + extra;
So if I remove this wm_uv from skl_plane_wm_level accessor,
the logic in skl_allocate_pipe_ddb will obvisouly change?
Stan
>
> For the compute side I think all we should really need is
> something like:
>
> tgl_compute_sagv_wm()
> {
> skl_compute_wm_level(sagv_wm0, latency + whatever);
> }
>
> skl_build_plane_wm_single()
> {
> ...
>
Re: [Intel-gfx] [PATCH v12 4/4] drm/i915/perf: enable filtering on multiple contexts
Quoting Lionel Landwerlin (2020-05-06 13:04:57) > On 04/05/2020 14:23, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2020-05-04 12:12:49) > >> Add 2 new properties to the i915-perf open ioctl to specify an array > >> of GEM context handles as well as the length of the array. > >> > >> This can be used by drivers using multiple GEM contexts to implement a > >> single GL context. > >> > >> Signed-off-by: Lionel Landwerlin > >> Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4464 > > >From what I recall of the tests, the API extension looked reasonable. > > Reviewed-by: Chris Wilson > > -Chris > > Is that Rb for the whole series? I believe they are all tagged, and if not, then make it so. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 8/9] drm/i915: Plumb crtc_state to link training
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
the short hpd handler.
The PHY test code seems to have started to build some kind of NIH
modeset code right into intel_dp.c. That's not how we should do
things, and instead we should just go through the normal modeset
machinery for that (meaning it all needs to move into the hotplug
work as well, just like we've already done for normal link retraining).
For now just neuter that code and toss in a FIXME.
v2: Add intel_crtc_state forward declaration
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 334 +-
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 17 +-
drivers/gpu/drm/i915/display/intel_dp.c | 138 +---
drivers/gpu/drm/i915/display/intel_dp.h | 11 +-
.../drm/i915/display/intel_dp_link_training.c | 102 +++---
.../drm/i915/display/intel_dp_link_training.h | 8 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 23 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.h | 2 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
10 files changed, 350 insertions(+), 298 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 409b8a68570f..77d2021d0bcd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -953,68 +953,75 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
int *n_entries)
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+icl_get_combo_buf_trans(const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI) {
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
*n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
return icl_combo_phy_ddi_translations_hdmi;
- } else if (rate > 54 && type == INTEL_OUTPUT_EDP) {
+ } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
+ crtc_state->port_clock > 54) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
return icl_combo_phy_ddi_translations_edp_hbr3;
- } else if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
+ } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
+ dev_priv->vbt.edp.low_vswing) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
return icl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
}
-
- *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
- return icl_combo_phy_ddi_translations_dp_hbr2;
}
static const struct icl_mg_phy_ddi_buf_trans *
-icl_get_mg_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+icl_get_mg_buf_trans(const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI) {
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hdmi);
return icl_mg_phy_ddi_translations_hdmi;
- } else if (rate > 27) {
+ } else if (crtc_state->port_clock > 27) {
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hbr2_hbr3);
return icl_mg_phy_ddi_translations_hbr2_hbr3;
+ } else {
+ *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
+ return icl_mg_phy_ddi_translations_rbr_hbr;
}
-
- *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
- return icl_mg_phy_ddi_translations_rbr_hbr;
}
static const struct cnl_ddi_buf_trans *
-ehl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+ehl_get_combo_buf_trans(const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP) {
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP)) {
*n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
return ehl_combo_phy_ddi_translations_dp;
+ } else {
+ return icl_get_combo_buf_trans(crtc_state, n_entries);
}
-
- return
Re: [Intel-gfx] [PATCH v12 4/4] drm/i915/perf: enable filtering on multiple contexts
On 06/05/2020 15:04, Lionel Landwerlin wrote: On 04/05/2020 14:23, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-05-04 12:12:49) Add 2 new properties to the i915-perf open ioctl to specify an array of GEM context handles as well as the length of the array. This can be used by drivers using multiple GEM contexts to implement a single GL context. Signed-off-by: Lionel Landwerlin Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4464 >From what I recall of the tests, the API extension looked reasonable. Reviewed-by: Chris Wilson -Chris Is that Rb for the whole series? The meat of the change to enable this being in the previous commit. Thanks, -Lionel Oops... Missed one of your mail. Same question about the tests ;) -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v12 4/4] drm/i915/perf: enable filtering on multiple contexts
On 04/05/2020 14:23, Chris Wilson wrote: Quoting Lionel Landwerlin (2020-05-04 12:12:49) Add 2 new properties to the i915-perf open ioctl to specify an array of GEM context handles as well as the length of the array. This can be used by drivers using multiple GEM contexts to implement a single GL context. Signed-off-by: Lionel Landwerlin Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4464 >From what I recall of the tests, the API extension looked reasonable. Reviewed-by: Chris Wilson -Chris Is that Rb for the whole series? The meat of the change to enable this being in the previous commit. Thanks, -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/22] x86/gpu: add RKL stolen memory support
> -Original Message-
> From: Intel-gfx On Behalf Of Matt
> Roper
> Sent: Tuesday, May 5, 2020 4:22 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas
> Subject: [Intel-gfx] [PATCH v2 02/22] x86/gpu: add RKL stolen memory support
>
> RKL re-uses the same stolen memory registers as TGL and ICL.
>
> Bspec: 52055
> Bspec: 49589
> Bspec: 49636
> Cc: Lucas De Marchi
> Signed-off-by: Matt Roper
Confirmed with Spec.
Reviewed-by: Anusha Srivatsa
> ---
> arch/x86/kernel/early-quirks.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
> index 2f9ec14be3b1..a4b5af03dcc1 100644
> --- a/arch/x86/kernel/early-quirks.c
> +++ b/arch/x86/kernel/early-quirks.c
> @@ -550,6 +550,7 @@ static const struct pci_device_id intel_early_ids[]
> __initconst = {
> INTEL_ICL_11_IDS(_early_ops),
> INTEL_EHL_IDS(_early_ops),
> INTEL_TGL_12_IDS(_early_ops),
> + INTEL_RKL_IDS(_early_ops),
> };
>
> struct resource intel_graphics_stolen_res __ro_after_init =
> DEFINE_RES_MEM(0, 0);
> --
> 2.24.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
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/i915: Plumb crtc state to link training code
== Series Details == Series: drm/i915: Plumb crtc state to link training code URL : https://patchwork.freedesktop.org/series/76993/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h HDRTEST drivers/gpu/drm/i915/display/intel_dp_link_training.h In file included from :0:0: ./drivers/gpu/drm/i915/display/intel_dp_link_training.h:14:24: error: ‘struct intel_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] const struct intel_crtc_state *crtc_state, ^~~~ ./drivers/gpu/drm/i915/display/intel_dp_link_training.h:17:24: error: ‘struct intel_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] const struct intel_crtc_state *crtc_state); ^~~~ ./drivers/gpu/drm/i915/display/intel_dp_link_training.h:19:23: error: ‘struct intel_crtc_state’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] const struct intel_crtc_state *crtc_state); ^~~~ cc1: all warnings being treated as errors drivers/gpu/drm/i915/Makefile:299: recipe for target 'drivers/gpu/drm/i915/display/intel_dp_link_training.hdrtest' failed make[4]: *** [drivers/gpu/drm/i915/display/intel_dp_link_training.hdrtest] Error 1 scripts/Makefile.build:488: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:488: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:488: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1722: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: Plumb crtc_state to link training
From: Ville Syrjälä
Get rid of mode crtc->config usage, and some ad-hoc intel_dp state
usage by plumbing the crtc state all the way down to the link training
code.
Unfortunately we do have to keep some cached state in intel_dp so
that we can do the "does the link need retraining?" checks from
the short hpd handler.
The PHY test code seems to have started to build some kind of NIH
modeset code right into intel_dp.c. That's not how we should do
things, and instead we should just go through the normal modeset
machinery for that (meaning it all needs to move into the hotplug
work as well, just like we've already done for normal link retraining).
For now just neuter that code and toss in a FIXME.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 334 +-
drivers/gpu/drm/i915/display/intel_ddi.h | 6 +-
.../drm/i915/display/intel_display_types.h| 17 +-
drivers/gpu/drm/i915/display/intel_dp.c | 138 +---
drivers/gpu/drm/i915/display/intel_dp.h | 11 +-
.../drm/i915/display/intel_dp_link_training.c | 102 +++---
.../drm/i915/display/intel_dp_link_training.h | 7 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 23 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.h | 2 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
10 files changed, 349 insertions(+), 298 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 409b8a68570f..77d2021d0bcd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -953,68 +953,75 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
int *n_entries)
}
static const struct cnl_ddi_buf_trans *
-icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+icl_get_combo_buf_trans(const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI) {
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
+
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
*n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_hdmi);
return icl_combo_phy_ddi_translations_hdmi;
- } else if (rate > 54 && type == INTEL_OUTPUT_EDP) {
+ } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
+ crtc_state->port_clock > 54) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr3);
return icl_combo_phy_ddi_translations_edp_hbr3;
- } else if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
+ } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
+ dev_priv->vbt.edp.low_vswing) {
*n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_hbr2);
return icl_combo_phy_ddi_translations_edp_hbr2;
+ } else {
+ *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
+ return icl_combo_phy_ddi_translations_dp_hbr2;
}
-
- *n_entries = ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hbr2);
- return icl_combo_phy_ddi_translations_dp_hbr2;
}
static const struct icl_mg_phy_ddi_buf_trans *
-icl_get_mg_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+icl_get_mg_buf_trans(const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type == INTEL_OUTPUT_HDMI) {
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hdmi);
return icl_mg_phy_ddi_translations_hdmi;
- } else if (rate > 27) {
+ } else if (crtc_state->port_clock > 27) {
*n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_hbr2_hbr3);
return icl_mg_phy_ddi_translations_hbr2_hbr3;
+ } else {
+ *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
+ return icl_mg_phy_ddi_translations_rbr_hbr;
}
-
- *n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations_rbr_hbr);
- return icl_mg_phy_ddi_translations_rbr_hbr;
}
static const struct cnl_ddi_buf_trans *
-ehl_get_combo_buf_trans(struct drm_i915_private *dev_priv, int type, int rate,
+ehl_get_combo_buf_trans(const struct intel_crtc_state *crtc_state,
int *n_entries)
{
- if (type != INTEL_OUTPUT_HDMI && type != INTEL_OUTPUT_EDP) {
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) &&
+ !intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP)) {
*n_entries = ARRAY_SIZE(ehl_combo_phy_ddi_translations_dp);
return ehl_combo_phy_ddi_translations_dp;
+ } else {
+ return icl_get_combo_buf_trans(crtc_state, n_entries);
}
-
- return icl_get_combo_buf_trans(dev_priv, type, rate,
[Intel-gfx] [PATCH 6/9] drm/i915: Fix DP_TRAIN_MAX_{PRE_EMPHASIS, SWING}_REACHED handling
From: Ville Syrjälä The DP spec says: "The transmitter shall support at least three levels of voltage swing (Levels 0, 1, and 2). If only three levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 10 (Level 2)), this bit shall be set to 1, and cleared in all other cases. If all four levels of voltage swing are supported (VOLTAGE SWING SET field (bits 1:0) are programmed to 11 (Level 3)), this bit shall be set to 1,and cleared in all other cases." Let's follow that exactly instead of the current apporach where we can set those also for vswing/preemph levels 0 or 1 (or 2 when the platform max is 3). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 573f93779449..aa7af531bcb8 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -72,8 +72,9 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp, if (p >= preemph_max) p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED; - voltage_max = min(intel_dp->voltage_max(intel_dp), - dp_voltage_max(p)); + v = min(v, dp_voltage_max(p)); + + voltage_max = intel_dp->voltage_max(intel_dp); if (v >= voltage_max) v = voltage_max | DP_TRAIN_MAX_SWING_REACHED; -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl, status}
From: Ville Syrjälä
Now that we've plumbed the crtc state all the way down we can
eliminate the DP_TP_{CTL,STATUS} register offsets from intel_dp,
and instead we derive them directly from the crtc state.
And thus we can get rid of the nasty hack in intel_ddi_get_config()
which mutates intel_dp during the readout.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 103 ++
drivers/gpu/drm/i915/display/intel_ddi.h | 5 +
.../drm/i915/display/intel_display_types.h| 8 --
drivers/gpu/drm/i915/display/intel_dp.c | 2 -
drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +-
5 files changed, 68 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 77d2021d0bcd..8e7caf78ea09 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3029,6 +3029,37 @@ icl_program_mg_dp_mode(struct intel_digital_port
*intel_dig_port,
}
}
+static enum transcoder
+tgl_dp_tp_transcoder(const struct intel_crtc_state *crtc_state)
+{
+ if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
+ return crtc_state->mst_master_transcoder;
+ else
+ return crtc_state->cpu_transcoder;
+}
+
+i915_reg_t dp_tp_ctl_reg(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ return TGL_DP_TP_CTL(tgl_dp_tp_transcoder(crtc_state));
+ else
+ return DP_TP_CTL(encoder->port);
+}
+
+i915_reg_t dp_tp_status_reg(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ return TGL_DP_TP_STATUS(tgl_dp_tp_transcoder(crtc_state));
+ else
+ return DP_TP_STATUS(encoder->port);
+}
+
static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state)
{
@@ -3053,11 +3084,12 @@ static void intel_ddi_enable_fec(struct intel_encoder
*encoder,
return;
intel_dp = enc_to_intel_dp(encoder);
- val = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
val |= DP_TP_CTL_FEC_ENABLE;
- intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, val);
+ intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
- if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
+ if (intel_de_wait_for_set(dev_priv,
+ dp_tp_status_reg(encoder, crtc_state),
DP_TP_STATUS_FEC_ENABLE_LIVE, 1))
drm_err(_priv->drm,
"Timed out waiting for FEC Enable Status\n");
@@ -3074,10 +3106,10 @@ static void intel_ddi_disable_fec_state(struct
intel_encoder *encoder,
return;
intel_dp = enc_to_intel_dp(encoder);
- val = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
val &= ~DP_TP_CTL_FEC_ENABLE;
- intel_de_write(dev_priv, intel_dp->regs.dp_tp_ctl, val);
- intel_de_posting_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
+ intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
}
static void tgl_ddi_pre_enable_dp(struct intel_atomic_state *state,
@@ -3091,15 +3123,11 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
int level = intel_ddi_dp_level(intel_dp);
- enum transcoder transcoder = crtc_state->cpu_transcoder;
intel_dp_set_link_params(intel_dp,
crtc_state->port_clock,
crtc_state->lane_count);
- intel_dp->regs.dp_tp_ctl = TGL_DP_TP_CTL(transcoder);
- intel_dp->regs.dp_tp_status = TGL_DP_TP_STATUS(transcoder);
-
/*
* 1. Enable Power Wells
*
@@ -3418,12 +3446,10 @@ static void intel_disable_ddi_buf(struct intel_encoder
*encoder,
}
if (intel_crtc_has_dp_encoder(crtc_state)) {
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
- val = intel_de_read(dev_priv, intel_dp->regs.dp_tp_ctl);
+ val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder,
crtc_state));
val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
val |=
[Intel-gfx] [PATCH 4/9] drm/i915: Add {preemph, voltage}_max() vfuncs
From: Ville Syrjälä
Different platforms have different max vswing/preemph settings.
Turn that into a pair vfuncs so we can decouple intel_dp.c and
intel_ddi.c further.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 21 ++
drivers/gpu/drm/i915/display/intel_ddi.h | 3 -
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/display/intel_dp.c | 67 ++-
drivers/gpu/drm/i915/display/intel_dp.h | 4 --
.../drm/i915/display/intel_dp_link_training.c | 20 +-
6 files changed, 49 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 5601673c3f30..409b8a68570f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2095,10 +2095,10 @@ static void bxt_ddi_vswing_sequence(struct
intel_encoder *encoder,
ddi_translations[level].deemphasis);
}
-u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder)
+static u8 intel_ddi_dp_voltage_max(struct intel_dp *intel_dp)
{
+ struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
enum port port = encoder->port;
enum phy phy = intel_port_to_phy(dev_priv, port);
int n_entries;
@@ -2151,19 +2151,9 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
*encoder)
* used on all DDI platforms. Should that change we need to
* rethink this code.
*/
-u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder, u8
voltage_swing)
+static u8 intel_ddi_dp_preemph_max(struct intel_dp *intel_dp)
{
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_3;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
- default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- }
+ return DP_TRAIN_PRE_EMPH_LEVEL_3;
}
static void cnl_ddi_vswing_program(struct intel_encoder *encoder,
@@ -4510,6 +4500,9 @@ intel_ddi_init_dp_connector(struct intel_digital_port
*intel_dig_port)
else
intel_dig_port->dp.set_signal_levels = hsw_set_signal_levels;
+ intel_dig_port->dp.voltage_max = intel_ddi_dp_voltage_max;
+ intel_dig_port->dp.preemph_max = intel_ddi_dp_preemph_max;
+
if (INTEL_GEN(dev_priv) < 12) {
intel_dig_port->dp.regs.dp_tp_ctl = DP_TP_CTL(port);
intel_dig_port->dp.regs.dp_tp_status = DP_TP_STATUS(port);
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.h
b/drivers/gpu/drm/i915/display/intel_ddi.h
index fbdf8ddde486..077e9dbbe367 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.h
+++ b/drivers/gpu/drm/i915/display/intel_ddi.h
@@ -42,9 +42,6 @@ void intel_ddi_compute_min_voltage_level(struct
drm_i915_private *dev_priv,
struct intel_crtc_state *crtc_state);
u32 bxt_signal_levels(struct intel_dp *intel_dp);
u32 ddi_signal_levels(struct intel_dp *intel_dp);
-u8 intel_ddi_dp_voltage_max(struct intel_encoder *encoder);
-u8 intel_ddi_dp_pre_emphasis_max(struct intel_encoder *encoder,
-u8 voltage_swing);
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
bool enable);
void icl_sanitize_encoder_pll_mapping(struct intel_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9488449e4b94..e0384af489c2 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1371,6 +1371,9 @@ struct intel_dp {
void (*set_idle_link_train)(struct intel_dp *intel_dp);
void (*set_signal_levels)(struct intel_dp *intel_dp);
+ u8 (*preemph_max)(struct intel_dp *intel_dp);
+ u8 (*voltage_max)(struct intel_dp *intel_dp);
+
/* Displayport compliance testing */
struct intel_dp_compliance compliance;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index a52f01c48644..1b786d5af383 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3947,58 +3947,24 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, u8
link_status[DP_LINK_STATU
DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
}
-/* These are source-specific values. */
-u8
-intel_dp_voltage_max(struct intel_dp *intel_dp)
+static u8 intel_dp_voltage_max_2(struct intel_dp *intel_dp)
{
- struct
[Intel-gfx] [PATCH 7/9] drm/i915: Replace some hand rolled max()s
From: Ville Syrjälä
Use max() instead of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index aa7af531bcb8..2493142a70e9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -59,13 +59,8 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
u8 preemph_max;
for (lane = 0; lane < intel_dp->lane_count; lane++) {
- u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
lane);
- u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
lane);
-
- if (this_v > v)
- v = this_v;
- if (this_p > p)
- p = this_p;
+ v = max(v, drm_dp_get_adjust_request_voltage(link_status,
lane));
+ p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status,
lane));
}
preemph_max = intel_dp->preemph_max(intel_dp);
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/9] drm/i915: Fix ivb cpu edp vswing
From: Ville Syrjälä
According to the DP spec supporting vswing 1 + preemph 2 is
mandatory. We don't have the hw settings for that though. In
order to pretend to follow the DP spec let's just select
vswing 0 + preemph 2 in this case (the DP spec says to use
the requested preemph in preference to the vswing when the
requested values aren't supported).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 91f26f7b758b..a52f01c48644 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3960,8 +3960,6 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv) ||
(HAS_PCH_SPLIT(dev_priv) && port != PORT_A))
return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
- else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A)
- return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
else
return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
}
@@ -3988,16 +3986,6 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, u8
voltage_swing)
default:
return DP_TRAIN_PRE_EMPH_LEVEL_0;
}
- } else if (IS_IVYBRIDGE(dev_priv) && port == PORT_A) {
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
- }
} else {
switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
@@ -4293,6 +4281,7 @@ static u32 ivb_cpu_edp_signal_levels(u8 train_set)
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_1:
return EDP_LINK_TRAIN_400MV_3_5DB_IVB;
case DP_TRAIN_VOLTAGE_SWING_LEVEL_0 | DP_TRAIN_PRE_EMPH_LEVEL_2:
+ case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_2:
return EDP_LINK_TRAIN_400MV_6DB_IVB;
case DP_TRAIN_VOLTAGE_SWING_LEVEL_1 | DP_TRAIN_PRE_EMPH_LEVEL_0:
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/9] drm/i915: Reverse preemph vs. voltage swing preference
From: Ville Syrjälä
The DP spec says:
"When the combination of the requested pre-emphasis level and
voltage swing exceeds the capability of a DPTX, the DPTX shall
set the pre-emphasis level according to the request and use the
highest voltage swing it can output with the given pre-emphasis level."
and
"When a DPTX reads a request beyond the limits of this Standard,
the DPTX shall set the pre-emphasis level according to the request
and set the highest voltage swing level it can output with the
given pre-emphasis level. If a DPTX is requested for 9.5dB of
pre-emphasis level (may be supported for a DPTX) and cannot support
that level, it shall set the pre-emphasis level to the next
highest level, 6dB."
Ie. we should first validate the pre-emphasis, and then select
the appropriate vswing for it.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 32 +--
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 171d9e842fc0..573f93779449 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,18 +34,18 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
-static u8 dp_pre_emphasis_max(u8 voltage_swing)
+static u8 dp_voltage_max(u8 preemph)
{
- switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
- return DP_TRAIN_PRE_EMPH_LEVEL_3;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
- return DP_TRAIN_PRE_EMPH_LEVEL_2;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
- return DP_TRAIN_PRE_EMPH_LEVEL_1;
- case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
+ switch (preemph & DP_TRAIN_PRE_EMPHASIS_MASK) {
+ case DP_TRAIN_PRE_EMPH_LEVEL_0:
+ return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
+ case DP_TRAIN_PRE_EMPH_LEVEL_1:
+ return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
+ case DP_TRAIN_PRE_EMPH_LEVEL_2:
+ return DP_TRAIN_VOLTAGE_SWING_LEVEL_1;
+ case DP_TRAIN_PRE_EMPH_LEVEL_3:
default:
- return DP_TRAIN_PRE_EMPH_LEVEL_0;
+ return DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
}
}
@@ -68,15 +68,15 @@ void intel_dp_get_adjust_train(struct intel_dp *intel_dp,
p = this_p;
}
- voltage_max = intel_dp->voltage_max(intel_dp);
- if (v >= voltage_max)
- v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
-
- preemph_max = min(intel_dp->preemph_max(intel_dp),
- dp_pre_emphasis_max(v));
+ preemph_max = intel_dp->preemph_max(intel_dp);
if (p >= preemph_max)
p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
+ voltage_max = min(intel_dp->voltage_max(intel_dp),
+ dp_voltage_max(p));
+ if (v >= voltage_max)
+ v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
+
for (lane = 0; lane < 4; lane++)
intel_dp->train_set[lane] = v | p;
}
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] drm/i915: Plumb crtc state to link training code
From: Ville Syrjälä
Final pieces for plumbing the crtc state all the way down to the guts of
the link trainign code. Allows us to eliminate a bunch of adhoc state
from intel_dp, and nukes some of the remaining crtc->config usages.
I'm also fixing the DP spec violations around the vswing/pre-emphasis
selection. Someone pointed that issue out a while ago but there was
never any followup to that discussion AFAICS.
I had to neuter the phy test code since it has snuck in some duplicated
low level modeset code straight into the short hpd handler in intel_dp.c,
which is definitely not the way we want to do things. So that stuff
needs a real redesign at some point.
Ville Syrjälä (9):
drm/i915: Fix cpt/ppt max pre-emphasis
drm/i915: Fix ibx max vswing/preemph
drm/i915: Fix ivb cpu edp vswing
drm/i915: Add {preemph,voltage}_max() vfuncs
drm/i915: Reverse preemph vs. voltage swing preference
drm/i915: Fix DP_TRAIN_MAX_{PRE_EMPHASIS,SWING}_REACHED handling
drm/i915: Replace some hand rolled max()s
drm/i915: Plumb crtc_state to link training
drm/i915: Eliminate intel_dp.regs.dp_tp_{ctl,status}
drivers/gpu/drm/i915/display/intel_ddi.c | 454 +-
drivers/gpu/drm/i915/display/intel_ddi.h | 14 +-
.../drm/i915/display/intel_display_types.h| 26 +-
drivers/gpu/drm/i915/display/intel_dp.c | 216 +
drivers/gpu/drm/i915/display/intel_dp.h | 15 +-
.../drm/i915/display/intel_dp_link_training.c | 136 +++---
.../drm/i915/display/intel_dp_link_training.h | 7 +-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.c | 23 +-
drivers/gpu/drm/i915/display/intel_dpio_phy.h | 2 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 7 +-
11 files changed, 467 insertions(+), 443 deletions(-)
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
