Re: [Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory
* Rodrigo Vivi wrote: > > Cc: Thomas Gleixner > > > > > Cc: Ingo Molnar > > > > > Cc: H. Peter Anvin > > > > > Cc: x...@kernel.org > > > > guys, could we push this through drm-intel? ack? > > nack? comments? > > Is there any concern with this patch? > any ack for push this through drm-intel? > or any nack with explanations please? > > I'd like to push this for 4.19 because this is > one of the patches that blocks us on using drm-tip > on ICL. Sorry - no objections, and I suppose it will be all tested properly before going upstream: Acked-by: Ingo Molnar Thanks, Ingo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for lib/ratelimit: Lockless ratelimiting (rev2)
== Series Details == Series: lib/ratelimit: Lockless ratelimiting (rev2) URL : https://patchwork.freedesktop.org/series/45416/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9516_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9516_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9516_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_9516_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +1 igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9516_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@gem_ctx_switch@basic-all-light: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105189) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9516 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9516: 74f5587b4c50742d179adb0fab3bae77017b5564 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9516/shards.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/gvt: declare gvt as i915's soft dependency
== Series Details == Series: drm/i915/gvt: declare gvt as i915's soft dependency URL : https://patchwork.freedesktop.org/series/45875/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4424 -> Patchwork_9517 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45875/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9517 that come from known issues: === IGT changes === Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 == Participating hosts (45 -> 41) == Additional (1): fi-byt-j1900 Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4424 -> Patchwork_9517 CI_DRM_4424: 657e14c8ced17f6c7de56bf25506e64562bddd25 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4534: aeb3f4143572b81a907921ad9442858aafe1931e @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9517: a60d9909939e10da3cc5bb0c75a771b8bc63f9d5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a60d9909939e drm/i915/gvt: declare gvt as i915's soft dependency == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9517/issues.html ___ 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: Fix assert_plane() warning on bootup with external display (rev6)
== Series Details == Series: drm/i915: Fix assert_plane() warning on bootup with external display (rev6) URL : https://patchwork.freedesktop.org/series/44909/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9515_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9515_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9515_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_9515_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP +4 == Known issues == Here are the changes found in Patchwork_9515_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-hsw: PASS -> FAIL (fdo#106886) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) igt@perf@blocking: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9515 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9515: cb60effe2a3f8432831dccd3e4ef76c3245c8e5f @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9515/shards.html ___ 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/glk: Add Quirk for GLK NUC HDMI port issues. (rev4)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev4) URL : https://patchwork.freedesktop.org/series/6/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9514_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9514_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9514_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_9514_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +1 igt@perf_pmu@rc6: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9514_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) igt@kms_atomic_transition@plane-all-modeset-transition-fencing: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +1 Possible fixes igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> FAIL (fdo#105347) fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9514 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9514: 5f7ac64538c16db5cfd2371bfdad1b9d7e1564f8 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9514/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/gvt: declare gvt as i915's soft dependency
From: Hang Yuan
This helps initramfs builder and other tools to know the full dependencies
of i915 and have gvt module loaded with i915.
v2: add condition and change to pre-dependency (Chris)
v3: move declaration to gvt.c. (Chris)
Signed-off-by: Hang Yuan
---
drivers/gpu/drm/i915/gvt/gvt.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 4e65266..00f487e9 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -468,3 +468,10 @@ int intel_gvt_init_device(struct drm_i915_private
*dev_priv)
kfree(gvt);
return ret;
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
+MODULE_SOFTDEP("pre: kvmgt");
+#elif IS_ENABLED(CONFIG_DRM_I915_GVT_XENGT)
+MODULE_SOFTDEP("pre: xengt");
+#endif
+
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: declare gvt as i915's soft dependency
On 07/03/2018 06:27 PM, Chris Wilson wrote:
Quoting hang.y...@linux.intel.com (2018-07-03 11:12:51)
From: Hang Yuan
This helps initramfs builder and other tools to know the full dependencies
of i915 and have gvt module loaded with i915.
v2: add condition and change to pre-dependency (Chris)
Signed-off-by: Hang Yuan
---
drivers/gpu/drm/i915/i915_pci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 55543f1..904f0bf 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -770,6 +770,12 @@ static void __exit i915_exit(void)
module_init(i915_init);
module_exit(i915_exit);
+#if IS_ENABLED(CONFIG_DRM_I915_GVT_KVMGT)
+MODULE_SOFTDEP("pre: kvmgt");
+#elif IS_ENABLED(CONFIG_DRM_I915_GVT_XENGT)
+MODULE_SOFTDEP("pre: xengt");
+#endif
Why not in drivers/gpu/drm/i915/gvt/gvt.c?
-Chris
Henry: I will move it to gvt.c. Thanks.
___
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: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45848/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9513_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9513_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9513_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_9513_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +1 igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP +4 == Known issues == Here are the changes found in Patchwork_9513_full that come from known issues: === IGT changes === Issues hit igt@gem_eio@reset-stress: shard-glk: PASS -> FAIL (fdo#105957) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9513 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9513: 5b9c5070474f9f74644659bd4a73bb358ce5ecc2 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9513/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU
>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Tuesday, July 3, 2018 10:08 PM >To: Zhao, Yakui ; Daniel Vetter >Cc: intel-gfx@lists.freedesktop.org >Subject: RE: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on >VGPU > >Quoting Zhao, Yakui (2018-07-03 14:58:31) >> >-Original Message- >> >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >> >Sent: Tuesday, July 3, 2018 9:25 PM >> >To: Zhao, Yakui ; Daniel Vetter >> > >> >Cc: intel-gfx@lists.freedesktop.org >> >Subject: RE: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg >> >only once on VGPU >> > >> >Quoting Zhao, Yakui (2018-07-03 13:47:46) >> >> >> >> >-Original Message- >> >> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of >> >> >Daniel Vetter >> >> >Sent: Tuesday, July 3, 2018 5:52 PM >> >> >To: Chris Wilson >> >> >Cc: Daniel Vetter ; Zhao, Yakui >> >> >; intel-gfx@lists.freedesktop.org >> >> >Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg >> >> >only once on VGPU >> >> > >> >> >On Tue, Jul 03, 2018 at 10:05:28AM +0100, Chris Wilson wrote: >> >> >> Quoting Daniel Vetter (2018-07-03 09:51:03) >> >> >> > On Tue, Jul 03, 2018 at 10:56:17AM +0800, Zhao Yakui wrote: >> >> >> > > On VGPU scenario the read/write operation of fence_reg will >> >> >> > > be trapped by the GVT-g. And then gvt-g follows the HW spec >> >> >> > > to write the >> >> >fence_reg. >> >> >> > > So it is unnecessary to read/write fence reg several times. >> >> >> > > This will help to reduce the unnecessary trap of fence_reg >> >> >> > > mmio >> >operation. >> >> >> > > >> >> >> > > V1->V2: Fix one typo error of parameter when calling >> >> >> > > V1->intel_vgpu_active >> >> >> > > >> >> >> > > Signed-off-by: Zhao Yakui >> >> >> > >> >> >> > Ok this makes more sense. Except you need to put the 64bit >> >> >> > entirely into the vpgu block, with a comment explaining why >> >> >> > this is safe (since the vpgu will take care of updating fences >> >> >> > correctly). >> >> >> >> >> >> Except, who cares? Are fence registers being rewritten that >> >> >> frequently that special casing vgpu is worth the hassle. Part of >> >> >> that is that you need to leave a hint behind in the code that >> >> >> (a) explains why it is safe after having the "here be dragons" >> >> >> and (b) why we >> >care. >> >> >> >> >> >> On a more pragmatic level if fencing doesn't plateau out to >> >> >> steady state, that is a worrying amount of contention -- the >> >> >> actual fence write itself would be the least of my worries. >> >> > >> >> >I can easily imagine that with the few per-client fences vgpu >> >> >hands out rewrites are much more common. But yeah some real data >> >> >would be >> >good. >> >> >And more reasons to get mesa off of the gtt mmaps. >> >> >> >> Hi, Daniel/Chris >> >> >> >> Thanks for your comments. >> >> The fence reg is used to assure the access of Tiled surface >> >> through aperature window. When fence is needed, the driver helps to >> >> find one available fence reg and then configure it. After it is not >> >> used, the >> >fence will be turned off and then be allocated for next usage. It >> >doesn't rely on the state of fence reg. In such case we don't need >> >to worry about the unsteady state. >> >> >> >> For the VGPU operation: The op of fence reg is trapped. Then >> >> the gvt-g >> >will follow the trapped value to program the fence_reg. >> >> (It will turn off and then write the expected value for any trapped >> >> write op >> >of fence reg). The trapped op in GVT-g is safe. >> >> >> >> Based on the current logic, it needs the five traps when one >> >> fence reg is >> >configured under VGPU mode.(Three writes, two reads). >> >> If it is programmed in one 64-bit op under VGPU mode, only one trap >> >> is >> >needed. And the GVT-g still can configure the expected fence_value. >> >> As the trap is quite heavy for VGPU, the trap time can be saved. >> > >> >But the argument is can we avoid it entirely by never changing the >> >fence. You say this is used for mapping through the aperture (GTT), >> >we say userspace shouldn't be doing that for performance reasons :) A >> >slow trap on top of a slow operation that is already causing >> >contention seems more sensible to fix at source. (Albeit so long as >> >the maintenance burden is considered and found to be reasonable, >> >adding special cases with their rationale is acceptable.) So you have >> >to sell why this mmio is worthy of special attention and curtail any future >questions. >> >> If the userspace driver/app can take care of the buffer allocation >> especially for the tiled surface, maybe it can reduce the ratio of >> changing the fence. But this can't be avoided if the tiled buffer is >> needed and allocated. This also depends on the userspace driver. And it is >beyond the responsibility of the kernel driver. > >We own the stack. If userspace is not behaving as well as it might, we n
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation
== Series Details == Series: series starting with [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation URL : https://patchwork.freedesktop.org/series/45842/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9512_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9512_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9512_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_9512_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +1 igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9512_full that come from known issues: === IGT changes === Issues hit igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) +1 igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-glk: FAIL (fdo#104873) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS +2 igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9512 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9512: 84bc29fb9b4a7d759b32f750b47d299b16803bcc @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9512/shards.html ___ 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/selftests: Drop struct_mutex around lowlevel pggtt allocation (rev2)
== Series Details == Series: drm/i915/selftests: Drop struct_mutex around lowlevel pggtt allocation (rev2) URL : https://patchwork.freedesktop.org/series/45819/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9511_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9511_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9511_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_9511_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS +1 igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9511_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-xtiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_rotation_crc@primary-rotation-180: shard-kbl: PASS -> FAIL (fdo#103925, fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (k.org#198133, fdo#103359) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9511 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9511: 4a7a99672e4ddc5e11654cdaa681fc5ea8d4c5f4 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9511/shards.html ___ 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: Use 64-bit write to optimize writing fence_reg on VGPU
== Series Details == Series: drm/i915: Use 64-bit write to optimize writing fence_reg on VGPU URL : https://patchwork.freedesktop.org/series/45841/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9510_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9510_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9510_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_9510_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_9510_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@kms_flip@2x-wf_vblank-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-kbl: PASS -> INCOMPLETE (fdo#103665) Possible fixes igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_flip_tiling@flip-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS +1 igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9510 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9510: 8f3afb60f04c05b46289401cc19d38451fbf2c70 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9510/shards.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 lib/ratelimit: Lockless ratelimiting (rev2)
== Series Details ==
Series: lib/ratelimit: Lockless ratelimiting (rev2)
URL : https://patchwork.freedesktop.org/series/45416/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9516 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/45416/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_9516 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103)
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9516
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9516: 74f5587b4c50742d179adb0fab3bae77017b5564 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
74f5587b4c50 lib/ratelimit: Lockless ratelimiting
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9516/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv3] lib/ratelimit: Lockless ratelimiting
Currently ratelimit_state is protected with spin_lock. If the .lock is
taken at the moment of ___ratelimit() call, the message is suppressed to
make ratelimiting robust.
That results in the following issue issue:
CPU0 CPU1
-- --
printk_ratelimit() printk_ratelimit()
| |
try_spin_lock() try_spin_lock()
| |
time_is_before_jiffies() return 0; // suppress
So, concurrent call of ___ratelimit() results in silently suppressing
one of the messages, regardless if the limit is reached or not.
And rc->missed is not increased in such case so the issue is covered
from user.
Convert ratelimiting to use atomic counters and drop spin_lock.
Note: That might be unexpected, but with the first interval of messages
storm one can print up to burst*2 messages. So, it doesn't guarantee
that in *any* interval amount of messages is lesser than burst.
But, that differs lightly from previous behavior where one can start
burst=5 interval and print 4 messages on the last milliseconds of
interval + new 5 messages from new interval (totally 9 messages in
lesser than interval value):
msg0 msg1-msg4 msg0-msg4
| | |
| | |
|--o-o-|-o|--> (t)
<--->
Lesser than burst
Dropped dev/random patch since v1 version:
lkml.kernel.org/r/<20180510125211.12583-1-d...@arista.com>
Dropped `name' in as it's unused in RATELIMIT_STATE_INIT()
Cc: Andy Shevchenko
Cc: Arnd Bergmann
Cc: David Airlie
Cc: Greg Kroah-Hartman
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: "Theodore Ts'o"
Cc: Thomas Gleixner
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dmitry Safonov
---
drivers/char/random.c| 28 ---
drivers/gpu/drm/i915/i915_perf.c | 8 --
fs/btrfs/super.c | 16 +--
fs/xfs/scrub/scrub.c | 2 +-
include/linux/ratelimit.h| 31 -
kernel/user.c| 2 +-
lib/ratelimit.c | 59 +++-
7 files changed, 73 insertions(+), 73 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..0be31b3eadab 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -439,10 +439,8 @@ static void _crng_backtrack_protect(struct crng_state
*crng,
static void process_random_ready_list(void);
static void _get_random_bytes(void *buf, int nbytes);
-static struct ratelimit_state unseeded_warning =
- RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3);
-static struct ratelimit_state urandom_warning =
- RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
+static struct ratelimit_state unseeded_warning = RATELIMIT_STATE_INIT(HZ, 3);
+static struct ratelimit_state urandom_warning = RATELIMIT_STATE_INIT(HZ, 3);
static int ratelimit_disable __read_mostly;
@@ -937,24 +935,22 @@ static void crng_reseed(struct crng_state *crng, struct
entropy_store *r)
crng->init_time = jiffies;
spin_unlock_irqrestore(&crng->lock, flags);
if (crng == &primary_crng && crng_init < 2) {
+ unsigned int unseeded_miss, urandom_miss;
+
invalidate_batched_entropy();
numa_crng_init();
crng_init = 2;
process_random_ready_list();
wake_up_interruptible(&crng_init_wait);
pr_notice("random: crng init done\n");
- if (unseeded_warning.missed) {
- pr_notice("random: %d get_random_xx warning(s) missed "
- "due to ratelimiting\n",
- unseeded_warning.missed);
- unseeded_warning.missed = 0;
- }
- if (urandom_warning.missed) {
- pr_notice("random: %d urandom warning(s) missed "
- "due to ratelimiting\n",
- urandom_warning.missed);
- urandom_warning.missed = 0;
- }
+ unseeded_miss = atomic_xchg(&unseeded_warning.missed, 0);
+ if (unseeded_miss)
+ pr_notice("random: %u get_random_xx warning(s) missed "
+ "due to ratelimiting\n", unseeded_miss);
+ urandom_miss = atomic_xchg(&urandom_warning.missed, 0);
+ if (urandom_miss)
+ pr_notice("random: %u urandom warning(s) missed "
+ "due to ratelimiting\n", urandom_miss);
}
}
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 019bd2d073ad..dcfba3023
[Intel-gfx] ✓ Fi.CI.IGT: success for ICELAKE DSI DRIVER (rev2)
== Series Details == Series: ICELAKE DSI DRIVER (rev2) URL : https://patchwork.freedesktop.org/series/44823/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4423_full -> Patchwork_9509_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9509_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9509_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_9509_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-render: shard-kbl: SKIP -> PASS igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: shard-kbl: PASS -> SKIP +2 == Known issues == Here are the changes found in Patchwork_9509_full that come from known issues: === IGT changes === Issues hit igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) +2 Possible fixes igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_vblank@pipe-a-ts-continuation-suspend: shard-hsw: FAIL (fdo#104894) -> PASS igt@perf@polling: shard-hsw: FAIL (fdo#102252) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104894 https://bugs.freedesktop.org/show_bug.cgi?id=104894 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4423 -> Patchwork_9509 CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9509: cd40dd3bd2598cdfec11b40ea20f131ac7744690 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9509/shards.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: Fix assert_plane() warning on bootup with external display (rev6)
== Series Details ==
Series: drm/i915: Fix assert_plane() warning on bootup with external display
(rev6)
URL : https://patchwork.freedesktop.org/series/44909/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9515 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/44909/revisions/6/mbox/
== Known issues ==
Here are the changes found in Patchwork_9515 that come from known issues:
=== IGT changes ===
Issues hit
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: PASS -> FAIL (fdo#104008)
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9515
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9515: cb60effe2a3f8432831dccd3e4ef76c3245c8e5f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cb60effe2a3f drm/i915: Fix assert_plane() warning on bootup with external
display
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9515/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv2] lib/ratelimit: Lockless ratelimiting
On Tue, 2018-06-26 at 21:41 +0300, Andy Shevchenko wrote:
> > > > @@ -42,9 +41,10 @@ static inline void
> > > > ratelimit_state_init(struct
> > > > ratelimit_state *rs,
> > > > {
> > > > memset(rs, 0, sizeof(*rs));
> > > >
> > > > - raw_spin_lock_init(&rs->lock);
> > > > rs->interval= interval;
> > > > rs->burst = burst;
> > > > + atomic_set(&rs->printed, 0);
> > > > + atomic_set(&rs->missed, 0);
> > >
> > > Can it be
> > >
> > > *rs = RATELIMIT_STATE_INIT(interval, burst);
> > >
> > > ?
> > >
> > > (Yes, the '(struct ratelimit_state)' has to be added to macro to
> > > allow this)
> >
> > Sure.
>
> This part, by the way, potentially can be split into preparatory
> patch. Please, double check if it possible to do this way.
Hmm, I tried this way:
:#define RATELIMIT_STATE_INIT(name, interval_init, burst_init) ({ \
: struct ratelimit_state name = { \
: .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
: .interval = interval_init, \
: .burst = burst_init, \
: };\
: name; \
: })
but the expression becomes non-constant, so it fails to compile in
definitions of globals.
I think I'll change it to
struct ratelimit_state tmp = RATELIMIT_STATE_INIT(...);
*rs = tmp;
Not perfect, but we did memset() and set elements after, so it's kinda
the same.
--
Thanks,
Dmitry
___
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/glk: Add Quirk for GLK NUC HDMI port issues. (rev4)
== Series Details ==
Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev4)
URL : https://patchwork.freedesktop.org/series/6/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9514 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/6/revisions/4/mbox/
== Known issues ==
Here are the changes found in Patchwork_9514 that come from known issues:
=== IGT changes ===
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9514
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9514: 5f7ac64538c16db5cfd2371bfdad1b9d7e1564f8 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5f7ac64538c1 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9514/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Track vma activity per fence.context, not per engine
Quoting Tvrtko Ursulin (2018-07-03 18:28:31)
>
> On 29/06/2018 23:54, Chris Wilson wrote:
> > In the next patch, we will want to be able to use more flexible request
> > timelines that can hop between engines. From the vma pov, we can then
> > not rely on the binding of this request to an engine and so can not
> > ensure that different requests are ordered through a per-engine
> > timeline, and so we must track activity of all timelines. (We track
> > activity on the vma itself to prevent unbinding from HW before the HW
> > has finished accessing it.)
> >
> > v2: Switch to a rbtree for 32b safety (since using u64 as a radixtree
> > index is fraught with aliasing of unsigned longs).
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 3 -
> > drivers/gpu/drm/i915/i915_gpu_error.c | 14 +---
> > drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
> > drivers/gpu/drm/i915/i915_request.h | 1 +
> > drivers/gpu/drm/i915/i915_vma.c | 112 +++---
> > drivers/gpu/drm/i915/i915_vma.h | 46 +++
> > 6 files changed, 98 insertions(+), 80 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index c6aa761ca085..50fcf74248f2 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -1996,7 +1996,6 @@ static struct i915_vma *pd_vma_create(struct
> > gen6_hw_ppgtt *ppgtt, int size)
> > struct drm_i915_private *i915 = ppgtt->base.vm.i915;
> > struct i915_ggtt *ggtt = &i915->ggtt;
> > struct i915_vma *vma;
> > - int i;
> >
> > GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
> > GEM_BUG_ON(size > ggtt->vm.total);
> > @@ -2005,8 +2004,6 @@ static struct i915_vma *pd_vma_create(struct
> > gen6_hw_ppgtt *ppgtt, int size)
> > if (!vma)
> > return ERR_PTR(-ENOMEM);
> >
> > - for (i = 0; i < ARRAY_SIZE(vma->last_read); i++)
> > - init_request_active(&vma->last_read[i], NULL);
>
> At first I thought you need to initialize the rb tree but figured out
> access to it is guarded by the active_count.
Or just NULL initialised. Oversight / rebase errors, it should have been
vma-active = RB_ROOT, looks like I skipped the radixtree init in earlier
versions.
> > init_request_active(&vma->last_fence, NULL);
> >
> > vma->vm = &ggtt->vm;
> > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> > b/drivers/gpu/drm/i915/i915_gpu_error.c
> > index df524c9cad40..8c81cf3aa182 100644
> > --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> > @@ -335,21 +335,16 @@ static void print_error_buffers(struct
> > drm_i915_error_state_buf *m,
> > struct drm_i915_error_buffer *err,
> > int count)
> > {
> > - int i;
> > -
> > err_printf(m, "%s [%d]:\n", name, count);
> >
> > while (count--) {
> > - err_printf(m, "%08x_%08x %8u %02x %02x [ ",
> > + err_printf(m, "%08x_%08x %8u %02x %02x %02x",
> > upper_32_bits(err->gtt_offset),
> > lower_32_bits(err->gtt_offset),
> > err->size,
> > err->read_domains,
> > -err->write_domain);
> > - for (i = 0; i < I915_NUM_ENGINES; i++)
> > - err_printf(m, "%02x ", err->rseqno[i]);
> > -
> > - err_printf(m, "] %02x", err->wseqno);
> > +err->write_domain,
> > +err->wseqno);
> > err_puts(m, tiling_flag(err->tiling));
> > err_puts(m, dirty_flag(err->dirty));
> > err_puts(m, purgeable_flag(err->purgeable));
> > @@ -1021,13 +1016,10 @@ static void capture_bo(struct drm_i915_error_buffer
> > *err,
> > struct i915_vma *vma)
> > {
> > struct drm_i915_gem_object *obj = vma->obj;
> > - int i;
> >
> > err->size = obj->base.size;
> > err->name = obj->base.name;
> >
> > - for (i = 0; i < I915_NUM_ENGINES; i++)
> > - err->rseqno[i] = __active_get_seqno(&vma->last_read[i]);
>
> We could still flatten the tree and capture the list of
> fence.context:seqno here, to be included in the error state. Or you
> think it is not useful?
I haven't looked at it for a long time, it's just noise to me at the
moment. Yes, we could flatten the tree, but to be honest I just took the
opportunity to kill it. (Who wants to add an variable array to our
unstuctured output, along with trying to say what those timelines are
the vma are active on.)
What I use the vma for in the error state is for working out what
buffers are active, and if the batch buffer tallies. (Severe errors
where userspace lied, it's anybody's guess.) The active seqno isn't
useful in this regard, since it almost always
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev4)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev4) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3665:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev4)
== Series Details == Series: drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. (rev4) URL : https://patchwork.freedesktop.org/series/6/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5f7ac64538c1 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. -:32: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #32: FILE: drivers/gpu/drm/i915/i915_drv.h:653: +#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7) ^ total: 0 errors, 0 warnings, 1 checks, 84 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
On 06/29/2018 02:09 AM, Imre Deak wrote:
On Thu, Jun 28, 2018 at 11:14:30AM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
On GLK NUC platforms the HDMI retiming buffer needs additional disabled
time to correctly sync to a faster incoming signal.
When measured on a scope the highspeed lines of the HDMI clock turn off
for ~400uS during a normal resolution change. The HDMI retimer on the
GLK NUC appears to require at least a full frame of quiet time before a
new faster clock can be correctly sync'd. Wait 100ms due to msleep
inaccuracies while waiting for a completed frame. Add a quirk to the
driver for GLK boards that use ITE66317 HDMI retimers.
V2: Add more devices to the quirk list
V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
Cc: Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 16 ++--
drivers/gpu/drm/i915/intel_display.c | 21 -
drivers/gpu/drm/i915/intel_drv.h | 3 +--
4 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b684f4..6c5a679 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ enum intel_sbi_destination {
#define QUIRK_BACKLIGHT_PRESENT (1<<3)
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
+#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0319825..89bb5ce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1807,15 +1807,27 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
}
-void intel_ddi_disable_transcoder_func(struct drm_i915_private *dev_priv,
- enum transcoder cpu_transcoder)
+/* Quirk time at 100ms for reliable operation */
+#define DDI_DISABLED_QUIRK_TIME 100
+
+void intel_ddi_disable_transcoder_func(const struct intel_crtc_state
*crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
Extra w/s.
i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
uint32_t val = I915_READ(reg);
val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK | TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
val |= TRANS_DDI_PORT_NONE;
I915_WRITE(reg, val);
+
+ if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
+ intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
+ msleep(DDI_DISABLED_QUIRK_TIME);
+ DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
+ }
I still think the macro is redundant, but I'd put here your comment
about the worst case mode and delay. The debug print should come before
the wait.
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eaa0663..ff42268 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5837,7 +5837,7 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
+ intel_ddi_disable_transcoder_func(old_crtc_state);
if (INTEL_GEN(dev_priv) >= 9)
skylake_scaler_disable(intel_crtc);
@@ -14852,6 +14852,17 @@ static void quirk_increase_t12_delay(struct drm_device
*dev)
DRM_INFO("Applying T12 delay quirk\n");
}
+/* GeminiLake NUC HDMI outputs require additional off time
+ * this allows the onboard retimer to correctly sync to signal
+ */
+static void quirk_increase_ddi_disabled_time(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->quirks |= QUIRK_INCREASE_DDI_DISABLED_TIME;
+ DRM_INFO("Applying Increase DDI Disabled quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14938,6 +14949,14 @@ static int intel_dmi_reverse_brightness(const struct
dmi_system_id *id)
/* Toshiba Satellite P50-C-18C */
{ 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
+
+ /* GeminiLake NUC */
+ { 0x3185, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ /* ASRock ITX*/
+ { 0x3185, 0x1849, 0x2212, quirk_inc
[Intel-gfx] [PATCH v6] drm/i915: Fix assert_plane() warning on bootup with external display
On KBL, WHL RVPs, booting up with an external display connected, triggers
below warning, when the BiOS brings up the external display too.
This warning is not seen during hotplug.
[3.615226] [ cut here ]
[3.619829] plane 1A assertion failure (expected on, current off)
[3.632039] WARNING: CPU: 2 PID: 354 at
drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
[3.633920] iwlwifi :00:14.3: loaded firmware version 38.c0e03d94.0
op_mode iwlmvm
[3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm btintel
bluetooth ecdh_generic
[3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted
4.17.0-rc7-50176-g655af12d39c2 #3
[3.647165] Hardware name: Intel Corporation CoffeeLake Client
Platform/WhiskeyLake U DDR4 ERB, BIOS CNLSFWR1.R00.X140.B00.1804040304
04/04/2018
[3.684509] RIP: 0010:assert_plane+0x71/0xbb
[3.764451] Call Trace:
[3.766888] intel_atomic_commit_tail+0xa97/0xb77
[3.771569] intel_atomic_commit+0x26a/0x279
[3.771572] drm_atomic_helper_set_config+0x5c/0x76
[3.780670] __drm_mode_set_config_internal+0x66/0x109
[3.780672] drm_mode_setcrtc+0x4c9/0x5cc
[3.780674] ? drm_mode_getcrtc+0x162/0x162
[3.789774] ? drm_mode_getcrtc+0x162/0x162
[3.798108] drm_ioctl_kernel+0x8d/0xe4
[3.801926] drm_ioctl+0x27d/0x368
[3.805311] ? drm_mode_getcrtc+0x162/0x162
[3.805314] ? selinux_file_ioctl+0x14e/0x199
[3.805317] vfs_ioctl+0x21/0x2f
[3.813812] do_vfs_ioctl+0x491/0x4b4
[3.813813] ? security_file_ioctl+0x37/0x4b
[3.813816] ksys_ioctl+0x55/0x75
[3.820672] __x64_sys_ioctl+0x1a/0x1e
[3.820674] do_syscall_64+0x51/0x5f
[3.820678] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[3.828221] RIP: 0033:0x7b5e04953967
[3.835504] RSP: 002b:7fff2eafb6f8 EFLAGS: 0246 ORIG_RAX:
0010
[3.835505] RAX: ffda RBX: 0002 RCX: 7b5e04953967
[3.835505] RDX: 7fff2eafb730 RSI: c06864a2 RDI: 000f
[3.835506] RBP: 7fff2eafb720 R08: R09:
[3.835507] R10: 0070 R11: 0246 R12: 000f
[3.879988] R13: 56bc9dd7d210 R14: 7fff2eafb730 R15: c06864a2
[3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 89 f9
48 0f 44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff <0f> 0b
eb 2b 48 c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48
[3.905845] WARNING: CPU: 2 PID: 354 at
drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
[3.920964] ---[ end trace dac692f4ac46391a ]---
The warning is seen when mode_setcrtc() is called for pipeB
during bootup and before we get a mode_setcrtc() for pipeA,
while doing update_crtcs() in intel_atomic_commit_tail().
Now since, plane1A is still active after commit, update_crtcs()
is done for pipeA and eventually update_plane() for plane1A.
intel_plane_state->ctl for plane1A is not updated since set_modecrtc() is
called for pipeB. So intel_plane_state->ctl for plane 1A will be 0x0.
So doing an update_plane() for plane1A, will result in clearing
PLANE_CTL_ENABLE bit, and hence the warning.
To fix this warning, force all active planes to recompute their states
in probe.
Changes in v6:
- Handle EDEADLK for drm_atomic_get_crtc_state() and
drm_atomic_add_affected_planes()
- Remove optimization of calling intel_initial_commit()
only when there is more than one active pipe in probe.
- Avoid using intel_ types.
Changes in v5:
- Drop drm_modeset_lock_all_ctx() since locks will be taken later.
Changes in v4:
- Handle locking in intel_initial_commit()
- Move the for loop inside intel_initial_commit() so that
drm_atomic_commit() is called only once
- Call intel_initial_commit() only for more than one active crtc on boot.
- Save the return value of intel_initial_commit() and print a message in
case of an error
Changes in v3:
- Add comments
Changes in v2:
- Force all planes to recompute their states.(Ville Syrjälä)
- Update the commit message
Signed-off-by: Azhar Shaikh
---
drivers/gpu/drm/i915/intel_display.c | 61 ++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 56818a45181c..d27b63fe2fc0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15092,12 +15092,61 @@ static void intel_update_fdi_pll_freq(struct
drm_i915_private *dev_priv)
DRM_DEBUG_DRIVER("FDI PLL freq=%d\n", dev_priv->fdi_pll_freq);
}
+static int intel_initial_commit(struct drm_device *dev)
+{
+ struct drm_atomic_state *state = NULL;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ int ret = 0;
+
+ state = drm_atomic_state_alloc(dev);
+ if (!state)
+ return -ENOMEM;
+
+
[Intel-gfx] [PATCH v4] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
From: Clint Taylor
On GLK NUC platforms the HDMI retiming buffer needs additional disabled
time to correctly sync to a faster incoming signal.
When measured on a scope the highspeed lines of the HDMI clock turn off
for ~400uS during a normal resolution change. The HDMI retimer on the
GLK NUC appears to require at least a full frame of quiet time before a
new faster clock can be correctly sync'd. Wait 100ms due to msleep
inaccuracies while waiting for a completed frame. Add a quirk to the
driver for GLK boards that use ITE66317 HDMI retimers.
V2: Add more devices to the quirk list
V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
V4: crtc type check extended to include _DDI and whitespace fixes
Cc: Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 18 +++---
drivers/gpu/drm/i915/intel_display.c | 20 +++-
drivers/gpu/drm/i915/intel_drv.h | 3 +--
4 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2cefe4c..c1526ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -650,6 +650,7 @@ enum intel_sbi_destination {
#define QUIRK_BACKLIGHT_PRESENT (1<<3)
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
#define QUIRK_INCREASE_T12_DELAY (1<<6)
+#define QUIRK_INCREASE_DDI_DISABLED_TIME (1<<7)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0319825..6d33010 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1807,15 +1807,27 @@ void intel_ddi_enable_transcoder_func(const struct
intel_crtc_state *crtc_state)
I915_WRITE(TRANS_DDI_FUNC_CTL(cpu_transcoder), temp);
}
-void intel_ddi_disable_transcoder_func(struct drm_i915_private *dev_priv,
- enum transcoder cpu_transcoder)
+/* Quirk time at 100ms for reliable operation */
+#define DDI_DISABLED_QUIRK_TIME 100
+
+void intel_ddi_disable_transcoder_func(const struct intel_crtc_state
*crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+
i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder);
uint32_t val = I915_READ(reg);
-
val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK |
TRANS_DDI_DP_VC_PAYLOAD_ALLOC);
val |= TRANS_DDI_PORT_NONE;
I915_WRITE(reg, val);
+
+ if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME &&
+ (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) ||
+intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DDI))) {
+ DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n");
+ msleep(DDI_DISABLED_QUIRK_TIME);
+ }
}
int intel_ddi_toggle_hdcp_signalling(struct intel_encoder *intel_encoder,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 681e071..8d31ff3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5837,7 +5837,7 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_ddi_set_vc_payload_alloc(old_crtc_state, false);
if (!transcoder_is_dsi(cpu_transcoder))
- intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
+ intel_ddi_disable_transcoder_func(old_crtc_state);
if (INTEL_GEN(dev_priv) >= 9)
skylake_scaler_disable(intel_crtc);
@@ -14847,6 +14847,17 @@ static void quirk_increase_t12_delay(struct drm_device
*dev)
DRM_INFO("Applying T12 delay quirk\n");
}
+/* GeminiLake NUC HDMI outputs require additional off time
+ * this allows the onboard retimer to correctly sync to signal
+ */
+static void quirk_increase_ddi_disabled_time(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->quirks |= QUIRK_INCREASE_DDI_DISABLED_TIME;
+ DRM_INFO("Applying Increase DDI Disabled quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14933,6 +14944,13 @@ static int intel_dmi_reverse_brightness(const struct
dmi_system_id *id)
/* Toshiba Satellite P50-C-18C */
{ 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
+
+ /* GeminiLake NUC */
+ { 0x3185, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x8086, 0x2072, quirk_increase_ddi_disabled_time },
+ /* ASRock ITX*/
+ { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+ { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
};
static void intel_init_quirks(struct drm_device *dev)
diff --gi
Re: [Intel-gfx] [PATCH 1/2] x86/gpu: reserve ICL's graphics stolen memory
On Mon, Jun 18, 2018 at 10:47:21AM -0700, Rodrigo Vivi wrote:
> On Fri, Jun 01, 2018 at 02:44:51PM -0700, Paulo Zanoni wrote:
> > Em Seg, 2018-05-07 às 11:46 +0300, Joonas Lahtinen escreveu:
> > > Ingo, do you prefer to merge through our tree with your ack?
> >
> > Ping?
> >
> > >
> > > Quoting Paulo Zanoni (2018-05-04 23:32:51)
> > > > ICL changes the registers and addresses to 64 bits.
> > > >
> > > > I also briefly looked at implementing an u64 version of the PCI
> > > > config
> > > > read functions, but I concluded this wouldn't be trivial, so it's
> > > > not
> > > > worth doing it for a single user that can't have any racing
> > > > problems
> > > > while reading the register in two separate operations.
> > > >
> > > > v2:
> > > > - Scrub the development (non-public) changelog (Joonas).
> > > > - Remove the i915.ko bits so this can be easily backported in
> > > > order
> > > >to properly avoid stolen memory even on machines without i915.ko
> > > >(Joonas).
> > > > - CC stable for the reasons above.
> > > >
> > > > Issue: VIZ-9250
> > >
> > > Fixes: 412310019a20 ("drm/i915/icl: Add initial Icelake
> > > definitions.")
> > >
> > > > CC: sta...@vger.kernel.org
> > >
> > > This should not be needed, it was introduced in v4.17-rc1 only.
> > >
> > > Reviewed-by: Joonas Lahtinen
> > >
> > > Regards, Joonas
> > >
>
> Cc: Thomas Gleixner
> > > > Cc: Ingo Molnar
> > > > Cc: H. Peter Anvin
> > > > Cc: x...@kernel.org
>
> guys, could we push this through drm-intel? ack?
> nack? comments?
Is there any concern with this patch?
any ack for push this through drm-intel?
or any nack with explanations please?
I'd like to push this for 4.19 because this is
one of the patches that blocks us on using drm-tip
on ICL.
Thanks in advance,
Rodrigo.
>
> > > > Cc: Daniele Ceraolo Spurio
> > > > Cc: Joonas Lahtinen
> > > > Signed-off-by: Paulo Zanoni
> > > > ---
> > > > arch/x86/kernel/early-quirks.c | 18 ++
> > > > include/drm/i915_drm.h | 4 +++-
> > > > 2 files changed, 21 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/x86/kernel/early-quirks.c
> > > > b/arch/x86/kernel/early-quirks.c
> > > > index bae0d32e327b..72c2cf961d44 100644
> > > > --- a/arch/x86/kernel/early-quirks.c
> > > > +++ b/arch/x86/kernel/early-quirks.c
> > > > @@ -340,6 +340,18 @@ static resource_size_t __init
> > > > gen3_stolen_base(int num, int slot, int func,
> > > > return bsm & INTEL_BSM_MASK;
> > > > }
> > > >
> > > > +static resource_size_t __init gen11_stolen_base(int num, int slot,
> > > > int func,
> > > > + resource_size_t
> > > > stolen_size)
> > > > +{
> > > > + u64 bsm;
> > > > +
> > > > + bsm = read_pci_config(num, slot, func,
> > > > INTEL_GEN11_BSM_DW0);
> > > > + bsm &= INTEL_BSM_MASK;
> > > > + bsm |= (u64)read_pci_config(num, slot, func,
> > > > INTEL_GEN11_BSM_DW1) << 32;
> > > > +
> > > > + return bsm;
> > > > +}
> > > > +
> > > > static resource_size_t __init i830_stolen_size(int num, int slot,
> > > > int func)
> > > > {
> > > > u16 gmch_ctrl;
> > > > @@ -500,6 +512,11 @@ static const struct intel_early_ops
> > > > chv_early_ops __initconst = {
> > > > .stolen_size = chv_stolen_size,
> > > > };
> > > >
> > > > +static const struct intel_early_ops gen11_early_ops __initconst =
> > > > {
> > > > + .stolen_base = gen11_stolen_base,
> > > > + .stolen_size = gen9_stolen_size,
> > > > +};
> > > > +
> > > > static const struct pci_device_id intel_early_ids[] __initconst =
> > > > {
> > > > INTEL_I830_IDS(&i830_early_ops),
> > > > INTEL_I845G_IDS(&i845_early_ops),
> > > > @@ -531,6 +548,7 @@ static const struct pci_device_id
> > > > intel_early_ids[] __initconst = {
> > > > INTEL_CFL_IDS(&gen9_early_ops),
> > > > INTEL_GLK_IDS(&gen9_early_ops),
> > > > INTEL_CNL_IDS(&gen9_early_ops),
> > > > + INTEL_ICL_11_IDS(&gen11_early_ops),
> > > > };
> > > >
> > > > struct resource intel_graphics_stolen_res __ro_after_init =
> > > > DEFINE_RES_MEM(0, 0);
> > > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > > > index c9e5a6621b95..c44703f471b3 100644
> > > > --- a/include/drm/i915_drm.h
> > > > +++ b/include/drm/i915_drm.h
> > > > @@ -95,7 +95,9 @@ extern struct resource intel_graphics_stolen_res;
> > > > #defineI845_TSEG_SIZE_512K (2 << 1)
> > > > #defineI845_TSEG_SIZE_1M (3 << 1)
> > > >
> > > > -#define INTEL_BSM 0x5c
> > > > +#define INTEL_BSM 0x5c
> > > > +#define INTEL_GEN11_BSM_DW00xc0
> > > > +#define INTEL_GEN11_BSM_DW10xc4
> > > > #define INTEL_BSM_MASK (-(1u << 20))
> > > >
> > > > #endif /* _I915_DRM_H_ */
> > > > --
> > > > 2.14.3
> > > >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/i
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Manasi Navare
>Sent: Thursday, June 28, 2018 3:36 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Zanoni, Paulo R
>Subject: [Intel-gfx] [PATCH v2 1/2] drm/i915/icl: Add remaining registers and
>bitfields for MG PHY DDI
>
>This patch adds the remaining register definitions and bit fields required for
>MG
>PHy DDI buffer initializations and voltage swing programming for MG PHy DDI
>ports.
>
>While at it this patch also fixes the naming for previously defined MG PHY
>registers in original commit id (c92f47b5ec977a "drm/i915/icl:
>Add register defs for voltage swing sequences for MG PHY DDI").
>Since the MG PHY registers are first defined in ICL platform, there is no need
>for
>_ICL prefix.
>
>v2:
>* Change the MG_TX_DRVCTL registers names to match the spec (Anusha)
>
>Signed-off-by: Manasi Navare
>Cc: Paulo Zanoni
>Cc: James Ausmus
Sending review again since it didn’t hit patchwork the last time.
Compared the register definitions with the BSpec.
Looks good.
Reviewed-by: Anusha Srivatsa
>---
> drivers/gpu/drm/i915/i915_reg.h | 246 +++
>-
> 1 file changed, 145 insertions(+), 101 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>index c30cfcd..6119acc 100644
>--- a/drivers/gpu/drm/i915/i915_reg.h
>+++ b/drivers/gpu/drm/i915/i915_reg.h
>@@ -1872,121 +1872,165 @@ enum i915_power_well_id {
> #define N_SCALAR(x) ((x) << 24)
> #define N_SCALAR_MASK (0x7F << 24)
>
>-#define _ICL_MG_PHY_PORT_LN(port, ln, ln0p1, ln0p2, ln1p1) \
>+#define MG_PHY_PORT_LN(port, ln, ln0p1, ln0p2, ln1p1) \
> _MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - (ln0p1)))
>
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT1 0x16812C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT1 0x16852C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT2 0x16912C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT2 0x16952C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT3 0x16A12C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT3 0x16A52C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT4 0x16B12C
>-#define _ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT4 0x16B52C
>-#define ICL_PORT_MG_TX1_LINK_PARAMS(port, ln) \
>- _ICL_MG_PHY_PORT_LN(port, ln,
>_ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
>-
>_ICL_MG_TX_LINK_PARAMS_TX1LN0_PORT2, \
>-
>_ICL_MG_TX_LINK_PARAMS_TX1LN1_PORT1)
>-
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT1 0x1680AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT1 0x1684AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT2 0x1690AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT2 0x1694AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT3 0x16A0AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT3 0x16A4AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT4 0x16B0AC
>-#define _ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT4 0x16B4AC
>-#define ICL_PORT_MG_TX2_LINK_PARAMS(port, ln) \
>- _ICL_MG_PHY_PORT_LN(port, ln,
>_ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
>-
>_ICL_MG_TX_LINK_PARAMS_TX2LN0_PORT2, \
>-
>_ICL_MG_TX_LINK_PARAMS_TX2LN1_PORT1)
>+#define MG_TX_LINK_PARAMS_TX1LN0_PORT10x16812C
>+#define MG_TX_LINK_PARAMS_TX1LN1_PORT10x16852C
>+#define MG_TX_LINK_PARAMS_TX1LN0_PORT20x16912C
>+#define MG_TX_LINK_PARAMS_TX1LN1_PORT20x16952C
>+#define MG_TX_LINK_PARAMS_TX1LN0_PORT30x16A12C
>+#define MG_TX_LINK_PARAMS_TX1LN1_PORT30x16A52C
>+#define MG_TX_LINK_PARAMS_TX1LN0_PORT40x16B12C
>+#define _MG_TX_LINK_PARAMS_TX1LN1_PORT4 0x16B52C
>+#define MG_TX1_LINK_PARAMS(port, ln) \
>+ MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
>+ MG_TX_LINK_PARAMS_TX1LN0_PORT2, \
>+ MG_TX_LINK_PARAMS_TX1LN1_PORT1)
>+
>+#define MG_TX_LINK_PARAMS_TX2LN0_PORT10x1680AC
>+#define MG_TX_LINK_PARAMS_TX2LN1_PORT10x1684AC
>+#define MG_TX_LINK_PARAMS_TX2LN0_PORT20x1690AC
>+#define MG_TX_LINK_PARAMS_TX2LN1_PORT20x1694AC
>+#define MG_TX_LINK_PARAMS_TX2LN0_PORT30x16A0AC
>+#define MG_TX_LINK_PARAMS_TX2LN1_PORT30x16A4AC
>+#define MG_TX_LINK_PARAMS_TX2LN0_PORT40x16B0AC
>+#define MG_TX_LINK_PARAMS_TX2LN1_PORT40x16B4AC
>+#define MG_TX2_LINK_PARAMS(port, ln) \
>+ MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
>+ MG_TX_LINK_PARAMS_TX2LN0_PORT2, \
>+ MG_TX_LINK_PARAMS_TX2LN1_PORT1)
> #define CRI_USE_FS32 (1 << 5)
>
>-#define _ICL_MG_TX_PISO_READLOAD_TX1LN0_PORT1 0x16814C
>-#define _ICL_MG_TX_PISO_READLOAD_TX1LN1_PORT1 0x16854C
>-#define
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Track the last-active inside the i915_vma
On 29/06/2018 23:54, Chris Wilson wrote:
Using a VMA on more than one timeline concurrently is the exception
rather than the rule (using it concurrently on multiple engines). As we
expect to only use one active tracker, store the most recently used
tracker inside the i915_vma itself and only fallback to the radixtree if
Is a rbtree now.
we need a second or more concurrent active trackers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 36 +++--
drivers/gpu/drm/i915/i915_vma.h | 1 +
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 2faad2a1d00e..9b69d24c5cf1 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -119,6 +119,12 @@ i915_vma_retire(struct i915_gem_active *base, struct
i915_request *rq)
__i915_vma_retire(active->vma, rq);
}
+static void
+i915_vma_last_retire(struct i915_gem_active *base, struct i915_request *rq)
+{
+ __i915_vma_retire(container_of(base, struct i915_vma, last_active), rq);
+}
+
static struct i915_vma *
vma_create(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
@@ -136,6 +142,7 @@ vma_create(struct drm_i915_gem_object *obj,
vma->active = RB_ROOT;
+ init_request_active(&vma->last_active, i915_vma_last_retire);
init_request_active(&vma->last_fence, NULL);
vma->vm = vm;
vma->ops = &vm->vma_ops;
@@ -895,6 +902,15 @@ static struct i915_gem_active *lookup_active(struct
i915_vma *vma, u64 idx)
{
struct i915_vma_active *active;
struct rb_node **p, *parent;
+ struct i915_request *old;
+
+ old = i915_gem_active_raw(&vma->last_active,
+ &vma->vm->i915->drm.struct_mutex);
+ if (!old || old->fence.context == idx)
+ goto out;
Put a comment for this block explaining the caching optimization.
+
+ /* Move the currently active fence into the rbtree */
+ idx = old->fence.context;
I find "currently active fence" a bit confusing. It is just the "last
accessed/cached fence", no?
parent = NULL;
p = &vma->active.rb_node;
@@ -903,7 +919,7 @@ static struct i915_gem_active *lookup_active(struct
i915_vma *vma, u64 idx)
active = rb_entry(parent, struct i915_vma_active, node);
if (active->timeline == idx)
- return &active->base;
+ goto replace;
if (active->timeline < idx)
p = &parent->rb_right;
@@ -922,7 +938,18 @@ static struct i915_gem_active *lookup_active(struct
i915_vma *vma, u64 idx)
rb_link_node(&active->node, parent, p);
rb_insert_color(&active->node, &vma->active);
- return &active->base;
+replace:
+ if (i915_gem_active_isset(&active->base)) {
+ __list_del_entry(&active->base.link);
+ vma->active_count--;
+ GEM_BUG_ON(!vma->active_count);
+ }
When does this trigger? Please put a comment for this block.
+ GEM_BUG_ON(list_empty(&vma->last_active.link));
+ list_replace_init(&vma->last_active.link, &active->base.link);
+ active->base.request = fetch_and_zero(&vma->last_active.request);
+
+out:
+ return &vma->last_active;
}
int i915_vma_move_to_active(struct i915_vma *vma,
@@ -1002,6 +1029,11 @@ int i915_vma_unbind(struct i915_vma *vma)
*/
__i915_vma_pin(vma);
+ ret = i915_gem_active_retire(&vma->last_active,
+&vma->vm->i915->drm.struct_mutex);
Dang.. there goes my idea to loop/iterate purely over the tree..
+ if (ret)
+ goto unpin;
+
rbtree_postorder_for_each_entry_safe(active, n,
&vma->active, node) {
ret = i915_gem_active_retire(&active->base,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index c297b0a0dc47..f06d66377107 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -97,6 +97,7 @@ struct i915_vma {
unsigned int active_count;
struct rb_root active;
+ struct i915_gem_active last_active;
struct i915_gem_active last_fence;
/**
Okay I get the idea and it is a good optimisation for the common case.
Regards,
Tvrtko
___
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/selftests: Touch the NMI watchdog inside a GTT pass
== Series Details == Series: drm/i915/selftests: Touch the NMI watchdog inside a GTT pass URL : https://patchwork.freedesktop.org/series/45823/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4421_full -> Patchwork_9508_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9508_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9508_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_9508_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: SKIP -> PASS igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_9508_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) igt@drv_suspend@shrink: shard-snb: PASS -> FAIL (fdo#106886) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887) igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-modeset-vs-vblank-race: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: shard-kbl: INCOMPLETE (fdo#103665) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> INCOMPLETE (k.org#198133, fdo#103359) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4421 -> Patchwork_9508 CI_DRM_4421: 91ca31bcf59d078fbddb0ac8d8e206dfd77a3d3e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9508: 7417f9612e944b21d5179d7aa8fc34706f71931d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9508/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Track vma activity per fence.context, not per engine
On 29/06/2018 23:54, Chris Wilson wrote:
In the next patch, we will want to be able to use more flexible request
timelines that can hop between engines. From the vma pov, we can then
not rely on the binding of this request to an engine and so can not
ensure that different requests are ordered through a per-engine
timeline, and so we must track activity of all timelines. (We track
activity on the vma itself to prevent unbinding from HW before the HW
has finished accessing it.)
v2: Switch to a rbtree for 32b safety (since using u64 as a radixtree
index is fraught with aliasing of unsigned longs).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 -
drivers/gpu/drm/i915/i915_gpu_error.c | 14 +---
drivers/gpu/drm/i915/i915_gpu_error.h | 2 +-
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 112 +++---
drivers/gpu/drm/i915/i915_vma.h | 46 +++
6 files changed, 98 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c6aa761ca085..50fcf74248f2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1996,7 +1996,6 @@ static struct i915_vma *pd_vma_create(struct
gen6_hw_ppgtt *ppgtt, int size)
struct drm_i915_private *i915 = ppgtt->base.vm.i915;
struct i915_ggtt *ggtt = &i915->ggtt;
struct i915_vma *vma;
- int i;
GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE));
GEM_BUG_ON(size > ggtt->vm.total);
@@ -2005,8 +2004,6 @@ static struct i915_vma *pd_vma_create(struct
gen6_hw_ppgtt *ppgtt, int size)
if (!vma)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < ARRAY_SIZE(vma->last_read); i++)
- init_request_active(&vma->last_read[i], NULL);
At first I thought you need to initialize the rb tree but figured out
access to it is guarded by the active_count.
init_request_active(&vma->last_fence, NULL);
vma->vm = &ggtt->vm;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index df524c9cad40..8c81cf3aa182 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -335,21 +335,16 @@ static void print_error_buffers(struct
drm_i915_error_state_buf *m,
struct drm_i915_error_buffer *err,
int count)
{
- int i;
-
err_printf(m, "%s [%d]:\n", name, count);
while (count--) {
- err_printf(m, "%08x_%08x %8u %02x %02x [ ",
+ err_printf(m, "%08x_%08x %8u %02x %02x %02x",
upper_32_bits(err->gtt_offset),
lower_32_bits(err->gtt_offset),
err->size,
err->read_domains,
- err->write_domain);
- for (i = 0; i < I915_NUM_ENGINES; i++)
- err_printf(m, "%02x ", err->rseqno[i]);
-
- err_printf(m, "] %02x", err->wseqno);
+ err->write_domain,
+ err->wseqno);
err_puts(m, tiling_flag(err->tiling));
err_puts(m, dirty_flag(err->dirty));
err_puts(m, purgeable_flag(err->purgeable));
@@ -1021,13 +1016,10 @@ static void capture_bo(struct drm_i915_error_buffer
*err,
struct i915_vma *vma)
{
struct drm_i915_gem_object *obj = vma->obj;
- int i;
err->size = obj->base.size;
err->name = obj->base.name;
- for (i = 0; i < I915_NUM_ENGINES; i++)
- err->rseqno[i] = __active_get_seqno(&vma->last_read[i]);
We could still flatten the tree and capture the list of
fence.context:seqno here, to be included in the error state. Or you
think it is not useful?
err->wseqno = __active_get_seqno(&obj->frontbuffer_write);
err->engine = __active_get_engine_id(&obj->frontbuffer_write);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h
index 58910f1dc67c..f893a4e8b783 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -177,7 +177,7 @@ struct i915_gpu_state {
struct drm_i915_error_buffer {
u32 size;
u32 name;
- u32 rseqno[I915_NUM_ENGINES], wseqno;
+ u32 wseqno;
u64 gtt_offset;
u32 read_domains;
u32 write_domain;
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index a355a081485f..e1c9365dfefb 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -380,6 +380,7 @@ static inline void
init_request_active(struct i915_gem_active *active,
i915_gem_retire_fn retire)
{
+ RCU_INIT_POINTER(activ
Re: [Intel-gfx] [PATCH] usb/icl: Work around ACPI boottime crash
Em Seg, 2018-07-02 às 16:57 +0300, Imre Deak escreveu: > Work around the following boot time crash: I worked around a very similar boot time crash by disabling CONFIG_SLAB_FREELIST_HARDENED. Can you please verify if this helps? Reference is LCK-5401. > > [ 10.456056] CPU: 1 PID: 220 Comm: systemd-udevd Tainted: > GW 4.17.0-rc7-CI-CI_DRM_4040+ #182 > [ 10.465828] Hardware name: Intel Corporation Ice Lake Client > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS > +ICLSFWR1.R00.2204.A00.1805172221 05/17/2018 > [ 10.479168] RIP: 0010:acpi_ps_complete_this_op+0xa7/0x22a > [ 10.484627] RSP: 0018:c93a7578 EFLAGS: 00010202 > [ 10.489881] RAX: 6b6b6b6b6b6b6b6b RBX: 8804abeda9c8 RCX: > 0020 > [ 10.497045] RDX: RSI: 88049e604a68 RDI: > > [ 10.504213] RBP: R08: 8804abeda9c8 R09: > > [ 10.511376] R10: R11: R12: > 000e > [ 10.518542] R13: 88049e604a68 R14: 88049e604a68 R15: > a00263c2 > [ 10.525713] FS: 7ff6d85f18c0() GS:8804be88() > knlGS: > [ 10.533839] CS: 0010 DS: ES: CR0: 80050033 > [ 10.539616] CR2: 7ff6d73cff40 CR3: 00049f794001 CR4: > 00760ee0 > [ 10.546783] DR0: DR1: DR2: > > [ 10.553949] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 10.561112] PKRU: 5554 > [ 10.563849] Call Trace: > [ 10.566323] acpi_ps_complete_op+0x49/0x3f1 > [ 10.570537] acpi_ps_parse_loop+0x94c/0x9bb > [ 10.574754] ? acpi_ds_delete_walk_state+0x113/0x131 > [ 10.579750] acpi_ps_parse_aml+0x1a2/0x4af > [ 10.583875] acpi_ps_execute_method+0x1e9/0x2a5 > [ 10.588435] acpi_ns_evaluate+0x2e4/0x42c > [ 10.592473] acpi_evaluate_object+0x1fd/0x3a8 > [ 10.596873] usb_acpi_find_companion+0xee/0x1f0 [usbcore] > [ 10.602319] acpi_platform_notify+0x33/0xa0 > [ 10.606532] device_add+0x197/0x600 > [ 10.610048] ? __init_waitqueue_head+0x36/0x50 > [ 10.614529] usb_hub_create_port_device+0x11d/0x340 [usbcore] > [ 10.620314] hub_probe+0x9a5/0x1010 [usbcore] > [ 10.624701] ? _raw_spin_unlock_irqrestore+0x51/0x60 > [ 10.629730] usb_probe_interface+0x13f/0x300 [usbcore] > [ 10.634900] driver_probe_device+0x302/0x470 > [ 10.639198] ? __driver_attach+0xe0/0xe0 > [ 10.643147] bus_for_each_drv+0x59/0x90 > [ 10.647013] __device_attach+0xb7/0x130 > [ 10.650878] bus_probe_device+0x9c/0xb0 > [ 10.654745] device_add+0x3c5/0x600 > [ 10.658270] usb_set_configuration+0x540/0x880 [usbcore] > [ 10.663621] generic_probe+0x28/0x80 [usbcore] > [ 10.668097] driver_probe_device+0x302/0x470 > [ 10.672393] ? __driver_attach+0xe0/0xe0 > [ 10.676346] bus_for_each_drv+0x59/0x90 > [ 10.680211] __device_attach+0xb7/0x130 > [ 10.684076] bus_probe_device+0x9c/0xb0 > [ 10.687940] device_add+0x3c5/0x600 > [ 10.691464] usb_new_device+0x269/0x490 [usbcore] > [ 10.696206] usb_add_hcd+0x558/0x850 [usbcore] > [ 10.700682] xhci_pci_probe+0x13d/0x240 [xhci_pci] > [ 10.705534] pci_device_probe+0xa1/0x130 > [ 10.709484] driver_probe_device+0x302/0x470 > [ 10.713784] __driver_attach+0xb9/0xe0 > [ 10.717562] ? driver_probe_device+0x470/0x470 > [ 10.722033] ? driver_probe_device+0x470/0x470 > [ 10.726505] bus_for_each_dev+0x64/0x90 > [ 10.730370] ? preempt_count_sub+0x92/0xd0 > [ 10.734495] bus_add_driver+0x164/0x260 > [ 10.738362] ? 0xa004e000 > [ 10.741704] driver_register+0x57/0xc0 > [ 10.745482] ? 0xa004e000 > [ 10.748824] do_one_initcall+0x4a/0x350 > [ 10.752690] ? do_init_module+0x22/0x20a > [ 10.756643] ? rcu_read_lock_sched_held+0x74/0x80 > [ 10.761377] ? kmem_cache_alloc_trace+0x284/0x2e0 > [ 10.766114] do_init_module+0x5b/0x20a > [ 10.769895] load_module+0x250d/0x2b20 > [ 10.773678] ? kernel_read+0x2c/0x40 > [ 10.777285] ? __se_sys_finit_module+0xaa/0xc0 > [ 10.781759] __se_sys_finit_module+0xaa/0xc0 > [ 10.786061] do_syscall_64+0x54/0x190 > [ 10.789752] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 10.794831] RIP: 0033:0x7ff6d74664d9 > [ 10.798430] RSP: 002b:7ffd91e7dd78 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 10.806033] RAX: ffda RBX: 560519bfae20 RCX: > 7ff6d74664d9 > [ 10.813195] RDX: RSI: 7ff6d795ce23 RDI: > 000e > [ 10.820360] RBP: 7ff6d795ce23 R08: R09: > > [ 10.827523] R10: 000e R11: 0246 R12: > > [ 10.834690] R13: 560519bf9a30 R14: 0002 R15: > 0aba9500 > [ 10.841862] Code: c2 10 5f ea 81 48 c7 c6 f0 5e ea 81 bf 7c 00 00 > 00 e8 0d 7c 00 00 31 ed e9 88 01 00 00 48 8b 03 31 ed 48 85 c0 > +0f 84 e9 00 00 00 <4c> 8b 60 28 4d 85 e4 0f 84 dc 00 00 00 0f b7 78 > 0a e8 62 fe ff > [
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Drop struct_mutex around lowlevel pggtt allocation
On 03/07/2018 14:53, Chris Wilson wrote:
For a ppgtt that we are constructing, there is no struct_mutex
dependence so skip it. In the process, also ping the scheduler
frequently to try and avoid the NMI watchdog.
v2: gen6 requires struct_mutex to clean up (currently)
Suggested-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=107094
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index a28ee0cc6a63..4393b6d992e0 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -142,12 +142,9 @@ static int igt_ppgtt_alloc(void *arg)
if (!USES_PPGTT(dev_priv))
return 0;
- mutex_lock(&dev_priv->drm.struct_mutex);
ppgtt = __hw_ppgtt_create(dev_priv);
- if (IS_ERR(ppgtt)) {
- err = PTR_ERR(ppgtt);
- goto err_unlock;
- }
+ if (IS_ERR(ppgtt))
+ return PTR_ERR(ppgtt);
if (!ppgtt->vm.allocate_va_range)
goto err_ppgtt_cleanup;
@@ -166,6 +163,8 @@ static int igt_ppgtt_alloc(void *arg)
goto err_ppgtt_cleanup;
}
+ cond_resched();
+
ppgtt->vm.clear_range(&ppgtt->vm, 0, size);
}
@@ -183,13 +182,15 @@ static int igt_ppgtt_alloc(void *arg)
}
goto err_ppgtt_cleanup;
}
+
+ cond_resched();
}
err_ppgtt_cleanup:
+ mutex_lock(&dev_priv->drm.struct_mutex);
ppgtt->vm.cleanup(&ppgtt->vm);
- kfree(ppgtt);
-err_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
+ kfree(ppgtt);
return err;
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Add generic fbdev emulation
== Series Details ==
Series: drm: Add generic fbdev emulation
URL : https://patchwork.freedesktop.org/series/45848/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9513 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/45848/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9513:
=== IGT changes ===
Possible regressions
igt@kms_flip@basic-flip-vs-dpms:
{fi-cfl-8109u}: NOTRUN -> DMESG-WARN
igt@kms_flip@basic-flip-vs-modeset:
{fi-cfl-8109u}: NOTRUN -> INCOMPLETE
== Known issues ==
Here are the changes found in Patchwork_9513 that come from known issues:
=== IGT changes ===
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9513
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9513: 5b9c5070474f9f74644659bd4a73bb358ce5ecc2 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5b9c5070474f drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
41a2c1ca0b18 drm/tinydrm: Use drm_fbdev_generic_setup()
c62fda127952 drm/fb-helper: Finish the generic fbdev emulation
a5580869f41f drm/debugfs: Add internal client debugfs file
da8e3c4bb5c4 drm/cma-helper: Use the generic fbdev emulation
05745c28977b drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
781f36c686a2 drm/fb-helper: Add generic fbdev emulation .fb_probe function
ad434a5a0dae drm: Begin an API for in-kernel clients
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9513/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45848/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Begin an API for in-kernel clients Okay! Commit: drm/fb-helper: Add generic fbdev emulation .fb_probe function +drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) Commit: drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap Okay! Commit: drm/cma-helper: Use the generic fbdev emulation Okay! Commit: drm/debugfs: Add internal client debugfs file Okay! Commit: drm/fb-helper: Finish the generic fbdev emulation Okay! Commit: drm/tinydrm: Use drm_fbdev_generic_setup() Okay! Commit: drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45848/ State : warning == Summary == $ dim checkpatch origin/drm-tip ad434a5a0dae drm: Begin an API for in-kernel clients -:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #27: new file mode 100644 -:32: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #32: FILE: Documentation/gpu/drm-client.rst:1: += total: 0 errors, 2 warnings, 0 checks, 651 lines checked 781f36c686a2 drm/fb-helper: Add generic fbdev emulation .fb_probe function 05745c28977b drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap da8e3c4bb5c4 drm/cma-helper: Use the generic fbdev emulation -:359: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #359: FILE: drivers/gpu/drm/drm_fb_cma_helper.c:172: +struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev, + unsigned int preferred_bpp, unsigned int max_conn_count) total: 0 errors, 0 warnings, 1 checks, 425 lines checked a5580869f41f drm/debugfs: Add internal client debugfs file c62fda127952 drm/fb-helper: Finish the generic fbdev emulation 41a2c1ca0b18 drm/tinydrm: Use drm_fbdev_generic_setup() 5b9c5070474f drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Heads up: Xorg repository moves
Hey, if you haven't been following xorg-devel@, we're planning to move our repository hosting to freedesktop's gitlab instance. This is basically transparent from the client side, your git urls won't change, but you get continuous integration hooks for free if you want them. Longer term, we'd like to move from a bugzilla/mailing list model to tracking issues and merge requests in gitlab as well, but we're leaving that optional and per-component. I'd hoped to also take this opportunity to merge several of the X- related projects under the Xorg namespace and (gitlab) group, in particular openchrome nouveau and xcb. Individual subproject ACLs are much easier to manage in gitlab, so this is also something of a formality. But I understand if people would prefer to keep their own top-level project identity, and if this is your project, please do speak up. There are also some questions about which repos are worth migrating/archiving or moving to other namespaces. For details please see the freedesktop gitlab ticket: https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 We would like to complete the majority of the move by Monday, July 9, but can defer any given component as long as needed. Please raise any issues or suggestions on the ticket. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/rendercopy: Use gen8_wm_kernel__affine
On Tue, Jul 03, 2018 at 04:41:35PM +0100, Chris Wilson wrote:
> The shaders/blit.g7a has weird artefacts (random pixel kill) when
> drawing with to an odd destination coordinate. Rather than debug the
> issue with the assembler, replace the kernel with the one used by SNA
> for simple copies.
>
> Reported-by: Ville Syrjälä
> Signed-off-by: Chris Wilson
Yep, works on my chv and skl.
Tested-by: Ville Syrjälä
I can see the obvious pln(8) -> pln(16) change from the hex, but
didn't bother reading through the assembly to try and figure out
what the rest of the differences amount to. So I'll just toss in
an ack.
Acked-by: Ville Syrjälä
> ---
> lib/rendercopy_gen8.c | 10 --
> lib/rendercopy_gen9.c | 10 --
> 2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
> index 2b5d9b52e..2e590e391 100644
> --- a/lib/rendercopy_gen8.c
> +++ b/lib/rendercopy_gen8.c
> @@ -51,12 +51,10 @@ struct {
> /* see shaders/ps/blit.g7a */
> static const uint32_t ps_kernel[][4] = {
> #if 1
> - { 0x0060005a, 0x21403ae8, 0x3ac0, 0x008d0040 },
> - { 0x0060005a, 0x21603ae8, 0x3ac0, 0x008d0080 },
> - { 0x0060005a, 0x21803ae8, 0x3ad0, 0x008d0040 },
> - { 0x0060005a, 0x21a03ae8, 0x3ad0, 0x008d0080 },
> - { 0x02800031, 0x2e0022e8, 0x0e000140, 0x08840001 },
> - { 0x05800031, 0x200022e0, 0x0e000e00, 0x90031000 },
> + { 0x0080005a, 0x2f403ae8, 0x3ac0, 0x008d0040 },
> + { 0x0080005a, 0x2f803ae8, 0x3ad0, 0x008d0040 },
> + { 0x02800031, 0x2e203a48, 0x0e8d0f40, 0x08840001 },
> + { 0x05800031, 0x20003a40, 0x0e8d0e20, 0x90031000 },
> #else
> /* Write all -1 */
> { 0x0061, 0x2e000608, 0x, 0x3f80 },
> diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
> index 0157ced9c..79e312409 100644
> --- a/lib/rendercopy_gen9.c
> +++ b/lib/rendercopy_gen9.c
> @@ -52,12 +52,10 @@ struct {
> /* see shaders/ps/blit.g7a */
> static const uint32_t ps_kernel[][4] = {
> #if 1
> - { 0x0060005a, 0x21403ae8, 0x3ac0, 0x008d0040 },
> - { 0x0060005a, 0x21603ae8, 0x3ac0, 0x008d0080 },
> - { 0x0060005a, 0x21803ae8, 0x3ad0, 0x008d0040 },
> - { 0x0060005a, 0x21a03ae8, 0x3ad0, 0x008d0080 },
> - { 0x02800031, 0x2e0022e8, 0x0e000140, 0x08840001 },
> - { 0x05800031, 0x200022e0, 0x0e000e00, 0x90031000 },
> + { 0x0080005a, 0x2f403ae8, 0x3ac0, 0x008d0040 },
> + { 0x0080005a, 0x2f803ae8, 0x3ad0, 0x008d0040 },
> + { 0x02800031, 0x2e203a48, 0x0e8d0f40, 0x08840001 },
> + { 0x05800031, 0x20003a40, 0x0e8d0e20, 0x90031000 },
> #else
> /* Write all -1 */
> { 0x0061, 0x2e000608, 0x, 0x3f80 },
> --
> 2.18.0
>
> ___
> 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 4/8] drm/cma-helper: Use the generic fbdev emulation
This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.
There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini
This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().
tinydrm uses drm_fb_cma_fbdev_init_with_funcs().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_cma_helper.c | 360 +---
include/drm/drm_fb_cma_helper.h | 3 -
2 files changed, 42 insertions(+), 321 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..718c7f961d8a 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,6 +18,7 @@
*/
#include
+#include
#include
#include
#include
@@ -26,11 +27,8 @@
#include
#include
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
- const struct drm_framebuffer_funcs *fb_funcs;
};
/**
@@ -44,36 +42,6 @@ struct drm_fbdev_cma {
*
* An fbdev framebuffer backed by cma is also available by calling
* drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
- * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be
- * set up automatically. &drm_framebuffer_funcs.dirty is called by
- * drm_fb_helper_deferred_io() in process context (&struct delayed_work).
- *
- * Example fbdev deferred io code::
- *
- * static int driver_fb_dirty(struct drm_framebuffer *fb,
- *struct drm_file *file_priv,
- *unsigned flags, unsigned color,
- *struct drm_clip_rect *clips,
- *unsigned num_clips)
- * {
- * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
- * ... push changes ...
- * return 0;
- * }
- *
- * static struct drm_framebuffer_funcs driver_fb_funcs = {
- * .destroy = drm_gem_fb_destroy,
- * .create_handle = drm_gem_fb_create_handle,
- * .dirty = driver_fb_dirty,
- * };
- *
- * Initialize::
- *
- * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16,
- * dev->mode_config.num_crtc,
- * dev->mode_config.num_connector,
- * &driver_fb_funcs);
- *
*/
static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
@@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
- return dma_mmap_writecombine(info->device, vma, info->screen_base,
-info->fix.smem_start, info->fix.smem_len);
-}
-
-static struct fb_ops drm_fbdev_cma_ops = {
- .owner = THIS_MODULE,
- DRM_FB_HELPER_DEFAULT_OPS,
- .fb_fillrect= drm_fb_helper_sys_fillrect,
- .fb_copyarea= drm_fb_helper_sys_copyarea,
- .fb_imageblit = drm_fb_helper_sys_imageblit,
- .fb_mmap= drm_fb_cma_mmap,
-};
-
-static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
- struct vm_area_struct *vma)
-{
- fb_deferred_io_mmap(info, vma);
- vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-
- return 0;
-}
-
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
- struct drm_gem_cma_object *cma_obj)
-{
- struct fb_deferred_io *fbdefio;
- struct fb_ops *fbops;
-
- /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
- fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
- fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
- if (!fbdefio || !fbops) {
- kfree(fbdefio);
- kfree(fbops);
- return -ENOMEM;
- }
-
- /* can't be offset from vaddr since dirty() uses cma_obj */
- fbi->screen_buffer = cma_obj->vaddr;
- /* fb_deferred_io_fault() needs a physical address */
- fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
- *fbops = *fbi->fbops;
- fbi->fbops = fbops;
-
- fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
- fbdefio->deferred_io = drm_fb_helper_deferred_io;
- fbi->fbdef
[Intel-gfx] [PATCH v5 6/8] drm/fb-helper: Finish the generic fbdev emulation
This adds a drm_fbdev_generic_setup() function that sets up generic
fbdev emulation with client callbacks for restore, hotplug and
unregister.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 117
include/drm/drm_fb_helper.h | 7 +++
2 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bea3a0cb324a..e2f0db1432aa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -67,6 +67,9 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
* helper functions used by many drivers to implement the kernel mode setting
* interfaces.
*
+ * Drivers that support a dumb buffer with a virtual address and mmap support,
+ * should try out the generic fbdev emulation using drm_fbdev_generic_setup().
+ *
* Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
* down by calling drm_fb_helper_fbdev_teardown().
*
@@ -3118,6 +3121,120 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper
*fb_helper,
}
EXPORT_SYMBOL(drm_fb_helper_generic_probe);
+static const struct drm_fb_helper_funcs drm_fb_helper_generic_funcs = {
+ .fb_probe = drm_fb_helper_generic_probe,
+};
+
+static void drm_fbdev_client_unregister(struct drm_client_dev *client)
+{
+ struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+ if (fb_helper->fbdev) {
+ drm_fb_helper_unregister_fbi(fb_helper);
+ /* drm_fbdev_fb_destroy() takes care of cleanup */
+ return;
+ }
+
+ /* Did drm_fb_helper_fbdev_setup() run? */
+ if (fb_helper->dev)
+ drm_fb_helper_fini(fb_helper);
+
+ drm_client_release(client);
+ kfree(fb_helper);
+}
+
+static int drm_fbdev_client_restore(struct drm_client_dev *client)
+{
+ struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+ drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+
+ return 0;
+}
+
+static int drm_fbdev_client_hotplug(struct drm_client_dev *client)
+{
+ struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+ struct drm_device *dev = client->dev;
+ int ret;
+
+ /* If drm_fb_helper_fbdev_setup() failed, we only try once */
+ if (!fb_helper->dev && fb_helper->funcs)
+ return 0;
+
+ if (dev->fb_helper)
+ return drm_fb_helper_hotplug_event(dev->fb_helper);
+
+ if (!dev->mode_config.num_connector)
+ return 0;
+
+ ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
&drm_fb_helper_generic_funcs,
+ fb_helper->preferred_bpp, 0);
+ if (ret) {
+ fb_helper->dev = NULL;
+ fb_helper->fbdev = NULL;
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct drm_client_funcs drm_fbdev_client_funcs = {
+ .owner = THIS_MODULE,
+ .unregister = drm_fbdev_client_unregister,
+ .restore= drm_fbdev_client_restore,
+ .hotplug= drm_fbdev_client_hotplug,
+};
+
+/**
+ * drm_fb_helper_generic_fbdev_setup() - Setup generic fbdev emulation
+ * @dev: DRM device
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ *
+ * This function sets up generic fbdev emulation for drivers that supports
+ * dumb buffers with a virtual address and that can be mmap'ed.
+ *
+ * Restore, hotplug events and teardown are all taken care of. Drivers that do
+ * suspend/resume need to call drm_fb_helper_set_suspend_unlocked() themselves.
+ * Simple drivers might use drm_mode_config_helper_suspend().
+ *
+ * Drivers that set the dirty callback on their framebuffer will get a shadow
+ * fbdev buffer that is blitted onto the real buffer. This is done in order to
+ * make deferred I/O work with all kinds of buffers.
+ *
+ * This function is safe to call even when there are no connectors present.
+ * Setup will be retried on the next hotplug event.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
+{
+ struct drm_fb_helper *fb_helper;
+ int ret;
+
+ if (!drm_fbdev_emulation)
+ return 0;
+
+ fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
+ if (!fb_helper)
+ return -ENOMEM;
+
+ ret = drm_client_new(dev, &fb_helper->client, "fbdev",
&drm_fbdev_client_funcs);
+ if (ret) {
+ kfree(fb_helper);
+ return ret;
+ }
+
+ fb_helper->preferred_bpp = preferred_bpp;
+
+ drm_fbdev_client_hotplug(&fb_helper->client);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_fbdev_generic_setup);
+
/* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT)
* but the module does
[Intel-gfx] [PATCH v5 8/8] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Reviewed-by: David Lechner
---
drivers/gpu/drm/drm_fb_cma_helper.c | 21 -
include/drm/drm_fb_cma_helper.h | 3 ---
2 files changed, 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 718c7f961d8a..9da36a6271d3 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -99,27 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-/**
- * drm_fb_cma_fbdev_init_with_funcs() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- * @dev->mode_config.num_connector is used if this is zero.
- * @funcs: Framebuffer functions, in particular a custom dirty() callback.
- * Can be NULL.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count,
- const struct drm_framebuffer_funcs *funcs)
-{
- return drm_fb_cma_fbdev_init(dev, preferred_bpp, max_conn_count);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init_with_funcs);
-
/**
* drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
* @dev: DRM device
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index a0546c3451f9..96e26e3b9a0c 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -16,9 +16,6 @@ struct drm_mode_fb_cmd2;
struct drm_plane;
struct drm_plane_state;
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count,
- const struct drm_framebuffer_funcs *funcs);
int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
unsigned int max_conn_count);
void drm_fb_cma_fbdev_fini(struct drm_device *dev);
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/8] drm/fb-helper: Add generic fbdev emulation .fb_probe function
This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 199 +++-
include/drm/drm_fb_helper.h | 31 +++
2 files changed, 229 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cab14f253384..bea3a0cb324a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,6 +30,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include
+#include
#include
#include
#include
@@ -738,6 +739,24 @@ static void drm_fb_helper_resume_worker(struct work_struct
*work)
console_unlock();
}
+static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
+ struct drm_clip_rect *clip)
+{
+ struct drm_framebuffer *fb = fb_helper->fb;
+ unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+ size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
+ void *src = fb_helper->fbdev->screen_buffer + offset;
+ void *dst = fb_helper->buffer->vaddr + offset;
+ size_t len = (clip->x2 - clip->x1) * cpp;
+ unsigned int y;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ memcpy(dst, src, len);
+ src += fb->pitches[0];
+ dst += fb->pitches[0];
+ }
+}
+
static void drm_fb_helper_dirty_work(struct work_struct *work)
{
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
@@ -753,8 +772,12 @@ static void drm_fb_helper_dirty_work(struct work_struct
*work)
spin_unlock_irqrestore(&helper->dirty_lock, flags);
/* call dirty callback only when it has been really touched */
- if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
+ if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
+ /* Generic fbdev uses a shadow buffer */
+ if (helper->buffer)
+ drm_fb_helper_dirty_blit_real(helper, &clip_copy);
helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+ }
}
/**
@@ -2921,6 +2944,180 @@ void drm_fb_helper_output_poll_changed(struct
drm_device *dev)
}
EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
+/* @user: 1=userspace, 0=fbcon */
+static int drm_fbdev_fb_open(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ if (!try_module_get(fb_helper->dev->driver->fops->owner))
+ return -ENODEV;
+
+ return 0;
+}
+
+static int drm_fbdev_fb_release(struct fb_info *info, int user)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ module_put(fb_helper->dev->driver->fops->owner);
+
+ return 0;
+}
+
+/*
+ * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
+ * unregister_framebuffer() or fb_release().
+ */
+static void drm_fbdev_fb_destroy(struct fb_info *info)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct fb_info *fbi = fb_helper->fbdev;
+ struct fb_ops *fbops = NULL;
+ void *shadow = NULL;
+
+ if (fbi->fbdefio) {
+ fb_deferred_io_cleanup(fbi);
+ shadow = fbi->screen_buffer;
+ fbops = fbi->fbops;
+ }
+
+ drm_fb_helper_fini(fb_helper);
+
+ if (shadow) {
+ vfree(shadow);
+ kfree(fbops);
+ }
+
+ drm_client_framebuffer_delete(fb_helper->buffer);
+ /*
+* FIXME:
+* Remove conditional when all CMA drivers have been moved over to using
+* drm_fbdev_generic_setup().
+*/
+ if (fb_helper->client.funcs) {
+ drm_client_release(&fb_helper->client);
+ kfree(fb_helper);
+ }
+}
+
+static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+
+ if (fb_helper->dev->driver->gem_prime_mmap)
+ return
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
+ else
+ return -ENODEV;
+}
+
+static struct fb_ops drm_fbdev_fb_ops = {
+ .owner = THIS_MODULE,
+ DRM_FB_HELPER_DEFAULT_OPS,
+ .fb_open= drm_fbdev_fb_open,
+ .fb_release = drm_fbdev_fb_release,
+ .fb_destroy = drm_fbdev_fb_destroy,
+ .fb_mmap= drm_fbdev_fb_mmap,
+ .fb_read= drm_fb_helper_sys_read,
+ .fb_write = drm_fb_helper_sys_write,
+ .fb_fillrect= drm_fb_helper_sys_fillrect,
+ .fb_copyarea= drm_fb_helper_sys_copyarea,
+ .fb_imageblit = drm_fb_helper_sys_imageblit,
+};
+
+static struct fb_deferred_io drm_fbdev_defio = {
+ .delay = HZ / 20,
+
[Intel-gfx] [PATCH v5 5/8] drm/debugfs: Add internal client debugfs file
Print the names of the internal clients currently attached.
Reviewed-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 28
drivers/gpu/drm/drm_debugfs.c | 7 +++
include/drm/drm_client.h | 3 +++
3 files changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 743495f7f833..4039a4d103a8 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -385,3 +385,31 @@ void drm_client_framebuffer_delete(struct
drm_client_buffer *buffer)
drm_client_buffer_delete(buffer);
}
EXPORT_SYMBOL(drm_client_framebuffer_delete);
+
+#ifdef CONFIG_DEBUG_FS
+static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_printer p = drm_seq_file_printer(m);
+ struct drm_client_dev *client;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry(client, &dev->clientlist, list)
+ drm_printf(&p, "%s\n", client->name);
+ mutex_unlock(&dev->clientlist_mutex);
+
+ return 0;
+}
+
+static const struct drm_info_list drm_client_debugfs_list[] = {
+ { "internal_clients", drm_client_debugfs_internal_clients, 0 },
+};
+
+int drm_client_debugfs_init(struct drm_minor *minor)
+{
+ return drm_debugfs_create_files(drm_client_debugfs_list,
+ ARRAY_SIZE(drm_client_debugfs_list),
+ minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b2482818fee8..50a20bfc07ea 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
DRM_ERROR("Failed to create framebuffer debugfs
file\n");
return ret;
}
+
+ ret = drm_client_debugfs_init(minor);
+ if (ret) {
+ DRM_ERROR("Failed to create client debugfs file\n");
+ return ret;
+ }
}
if (dev->driver->debugfs_init) {
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 671052d80e38..989f8e52864d 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -10,6 +10,7 @@ struct drm_device;
struct drm_file;
struct drm_framebuffer;
struct drm_gem_object;
+struct drm_minor;
struct module;
/**
@@ -133,4 +134,6 @@ struct drm_client_buffer *
drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32
height, u32 format);
void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
+int drm_client_debugfs_init(struct drm_minor *minor);
+
#endif
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 7/8] drm/tinydrm: Use drm_fbdev_generic_setup()
Make full use of the generic fbdev client.
Cc: David Lechner
Signed-off-by: Noralf Trønnes
Reviewed-by: David Lechner
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +--
drivers/gpu/drm/tinydrm/ili9225.c | 1 -
drivers/gpu/drm/tinydrm/ili9341.c | 1 -
drivers/gpu/drm/tinydrm/mi0283qt.c | 1 -
drivers/gpu/drm/tinydrm/st7586.c| 1 -
drivers/gpu/drm/tinydrm/st7735r.c | 1 -
6 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 24a33bf862fa..19c7f70adfa5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -204,7 +204,7 @@ static int tinydrm_register(struct tinydrm_device *tdev)
if (ret)
return ret;
- ret = drm_fb_cma_fbdev_init_with_funcs(drm, 0, 0, tdev->fb_funcs);
+ ret = drm_fbdev_generic_setup(drm, 0);
if (ret)
DRM_ERROR("Failed to initialize fbdev: %d\n", ret);
@@ -214,7 +214,6 @@ static int tinydrm_register(struct tinydrm_device *tdev)
static void tinydrm_unregister(struct tinydrm_device *tdev)
{
drm_atomic_helper_shutdown(tdev->drm);
- drm_fb_cma_fbdev_fini(tdev->drm);
drm_dev_unregister(tdev->drm);
}
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index 841c69aba059..455fefe012f5 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -368,7 +368,6 @@ static struct drm_driver ili9225_driver = {
DRIVER_ATOMIC,
.fops = &ili9225_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.name = "ili9225",
.desc = "Ilitek ILI9225",
.date = "20171106",
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c
b/drivers/gpu/drm/tinydrm/ili9341.c
index 8864dcde6edc..6701037749a7 100644
--- a/drivers/gpu/drm/tinydrm/ili9341.c
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -145,7 +145,6 @@ static struct drm_driver ili9341_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
DRIVER_ATOMIC,
.fops = &ili9341_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "ili9341",
.desc = "Ilitek ILI9341",
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 015d03f2acba..d7bb4c5e6657 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -154,7 +154,6 @@ static struct drm_driver mi0283qt_driver = {
DRIVER_ATOMIC,
.fops = &mi0283qt_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "mi0283qt",
.desc = "Multi-Inno MI0283QT",
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 5c29e3803ecb..2fcbc3067d71 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -304,7 +304,6 @@ static struct drm_driver st7586_driver = {
DRIVER_ATOMIC,
.fops = &st7586_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "st7586",
.desc = "Sitronix ST7586",
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c
b/drivers/gpu/drm/tinydrm/st7735r.c
index 6c7b15c9da4f..3081bc57c116 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -120,7 +120,6 @@ static struct drm_driver st7735r_driver = {
DRIVER_ATOMIC,
.fops = &st7735r_fops,
TINYDRM_GEM_DRIVER_OPS,
- .lastclose = drm_fb_helper_lastclose,
.debugfs_init = mipi_dbi_debugfs_init,
.name = "st7735r",
.desc = "Sitronix ST7735R",
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/8] drm: Add generic fbdev emulation
This patchset adds generic fbdev emulation for drivers that supports GEM based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An API is begun to support in-kernel clients in general. I've squashed the client patches to ease review. All patches have ack's and rb's so I'll apply this next week unless something more comes up. It's taken me 6 months to get this done so I look forward to getting it applied. Thanks a lot Daniel for helping me make this happen! Noralf. Changes since version 4: - Squash the two client patches to ease review. - Remove drm_client_put() doc references. - Remove drm_client_funcs->release, it's use went away in version 3. - Add drm_client_dev_hotplug() doc Changes since version 3: - drm/cma-helper: Use the generic fbdev emulation: Fix error path - Remove setting .lastclose in new tinydrm driver ili9341 Changes since version 2: - Applied first 3 patches to drm-misc-next - Drop client reference counting and only allow the driver to release clients. Noralf Trønnes (8): drm: Begin an API for in-kernel clients drm/fb-helper: Add generic fbdev emulation .fb_probe function drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap drm/cma-helper: Use the generic fbdev emulation drm/debugfs: Add internal client debugfs file drm/fb-helper: Finish the generic fbdev emulation drm/tinydrm: Use drm_fbdev_generic_setup() drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() Documentation/gpu/drm-client.rst| 12 + Documentation/gpu/index.rst | 1 + drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_client.c| 415 drivers/gpu/drm/drm_debugfs.c | 7 + drivers/gpu/drm/drm_drv.c | 8 + drivers/gpu/drm/drm_fb_cma_helper.c | 379 +++-- drivers/gpu/drm/drm_fb_helper.c | 316 - drivers/gpu/drm/drm_file.c | 3 + drivers/gpu/drm/drm_probe_helper.c | 3 + drivers/gpu/drm/pl111/pl111_drv.c | 2 + drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +- drivers/gpu/drm/tinydrm/ili9225.c | 1 - drivers/gpu/drm/tinydrm/ili9341.c | 1 - drivers/gpu/drm/tinydrm/mi0283qt.c | 1 - drivers/gpu/drm/tinydrm/st7586.c| 1 - drivers/gpu/drm/tinydrm/st7735r.c | 1 - include/drm/drm_client.h| 139 ++ include/drm/drm_device.h| 21 ++ include/drm/drm_fb_cma_helper.h | 6 - include/drm/drm_fb_helper.h | 38 +++ 21 files changed, 1007 insertions(+), 353 deletions(-) create mode 100644 Documentation/gpu/drm-client.rst create mode 100644 drivers/gpu/drm/drm_client.c create mode 100644 include/drm/drm_client.h -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/8] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
These are needed for pl111 to use the generic fbdev emulation.
Cc: Eric Anholt
Signed-off-by: Noralf Trønnes
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/pl111/pl111_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 054b93689d94..17a38e85ba7d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -250,6 +250,8 @@ static struct drm_driver pl111_drm_driver = {
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ .gem_prime_vmap = drm_gem_cma_prime_vmap,
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = pl111_debugfs_init,
--
2.15.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/8] drm: Begin an API for in-kernel clients
This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.
Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
Documentation/gpu/drm-client.rst | 12 ++
Documentation/gpu/index.rst| 1 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_client.c | 387 +
drivers/gpu/drm/drm_drv.c | 8 +
drivers/gpu/drm/drm_file.c | 3 +
drivers/gpu/drm/drm_probe_helper.c | 3 +
include/drm/drm_client.h | 136 +
include/drm/drm_device.h | 21 ++
9 files changed, 572 insertions(+), 1 deletion(-)
create mode 100644 Documentation/gpu/drm-client.rst
create mode 100644 drivers/gpu/drm/drm_client.c
create mode 100644 include/drm/drm_client.h
diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst
new file mode 100644
index ..7e672063e7eb
--- /dev/null
+++ b/Documentation/gpu/drm-client.rst
@@ -0,0 +1,12 @@
+=
+Kernel clients
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_client.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+ :export:
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index 00288f34c5a6..1fcf8e851e15 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
drm-kms
drm-kms-helpers
drm-uapi
+ drm-client
drivers
vga-switcheroo
vgaarbiter
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 69c13517ea3a..d6657a61d037 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
- drm_syncobj.o drm_lease.o drm_writeback.o
+ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
new file mode 100644
index ..743495f7f833
--- /dev/null
+++ b/drivers/gpu/drm/drm_client.c
@@ -0,0 +1,387 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
+
+/**
+ * DOC: overview
+ *
+ * This library provides support for clients running in the kernel like fbdev
and bootsplash.
+ * Currently it's only partially implemented, just enough to support fbdev.
+ *
+ * GEM drivers which provide a GEM based dumb buffer with a virtual address
are supported.
+ */
+
+static int drm_client_open(struct drm_client_dev *client)
+{
+ struct drm_device *dev = client->dev;
+ struct drm_file *file;
+
+ file = drm_file_alloc(dev->primary);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(&dev->filelist_mutex);
+ list_add(&file->lhead, &dev->filelist_internal);
+ mutex_unlock(&dev->filelist_mutex);
+
+ client->file = file;
+
+ return 0;
+}
+
+static void drm_client_close(struct drm_client_dev *client)
+{
+ struct drm_device *dev = client->dev;
+
+ mutex_lock(&dev->filelist_mutex);
+ list_del(&client->file->lhead);
+ mutex_unlock(&dev->filelist_mutex);
+
+ drm_file_free(client->file);
+}
+EXPORT_SYMBOL(drm_client_close);
+
+/**
+ * drm_client_new - Create a DRM client
+ * @dev: DRM device
+ * @client: DRM client
+ * @name: Client name
+ * @funcs: DRM client functions (optional)
+ *
+ * The caller needs to hold a reference on @dev before calling this function.
+ * The client is freed when the &drm_device is unregistered. See
drm_client_release().
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_new(struct drm_device *dev, struct drm_client_dev *client,
+ const char *name, const struct drm_client_funcs *funcs)
+{
+
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Let other struct_mutex users have their gpu time (rev2)
== Series Details == Series: drm/i915/selftests: Let other struct_mutex users have their gpu time (rev2) URL : https://patchwork.freedesktop.org/series/45810/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4420_full -> Patchwork_9507_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9507_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9507_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_9507_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9507_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_big: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> PASS igt@drv_suspend@shrink: shard-kbl: FAIL (fdo#106886) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4420 -> Patchwork_9507 CI_DRM_4420: d9596d1a02b553958c684ef2ea0d3e64e8f68efe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9507: d88f3379db8f08decce3f51c9737e41221f3debc @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9507/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib/rendercopy: Use gen8_wm_kernel__affine
The shaders/blit.g7a has weird artefacts (random pixel kill) when
drawing with to an odd destination coordinate. Rather than debug the
issue with the assembler, replace the kernel with the one used by SNA
for simple copies.
Reported-by: Ville Syrjälä
Signed-off-by: Chris Wilson
---
lib/rendercopy_gen8.c | 10 --
lib/rendercopy_gen9.c | 10 --
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index 2b5d9b52e..2e590e391 100644
--- a/lib/rendercopy_gen8.c
+++ b/lib/rendercopy_gen8.c
@@ -51,12 +51,10 @@ struct {
/* see shaders/ps/blit.g7a */
static const uint32_t ps_kernel[][4] = {
#if 1
- { 0x0060005a, 0x21403ae8, 0x3ac0, 0x008d0040 },
- { 0x0060005a, 0x21603ae8, 0x3ac0, 0x008d0080 },
- { 0x0060005a, 0x21803ae8, 0x3ad0, 0x008d0040 },
- { 0x0060005a, 0x21a03ae8, 0x3ad0, 0x008d0080 },
- { 0x02800031, 0x2e0022e8, 0x0e000140, 0x08840001 },
- { 0x05800031, 0x200022e0, 0x0e000e00, 0x90031000 },
+ { 0x0080005a, 0x2f403ae8, 0x3ac0, 0x008d0040 },
+ { 0x0080005a, 0x2f803ae8, 0x3ad0, 0x008d0040 },
+ { 0x02800031, 0x2e203a48, 0x0e8d0f40, 0x08840001 },
+ { 0x05800031, 0x20003a40, 0x0e8d0e20, 0x90031000 },
#else
/* Write all -1 */
{ 0x0061, 0x2e000608, 0x, 0x3f80 },
diff --git a/lib/rendercopy_gen9.c b/lib/rendercopy_gen9.c
index 0157ced9c..79e312409 100644
--- a/lib/rendercopy_gen9.c
+++ b/lib/rendercopy_gen9.c
@@ -52,12 +52,10 @@ struct {
/* see shaders/ps/blit.g7a */
static const uint32_t ps_kernel[][4] = {
#if 1
- { 0x0060005a, 0x21403ae8, 0x3ac0, 0x008d0040 },
- { 0x0060005a, 0x21603ae8, 0x3ac0, 0x008d0080 },
- { 0x0060005a, 0x21803ae8, 0x3ad0, 0x008d0040 },
- { 0x0060005a, 0x21a03ae8, 0x3ad0, 0x008d0080 },
- { 0x02800031, 0x2e0022e8, 0x0e000140, 0x08840001 },
- { 0x05800031, 0x200022e0, 0x0e000e00, 0x90031000 },
+ { 0x0080005a, 0x2f403ae8, 0x3ac0, 0x008d0040 },
+ { 0x0080005a, 0x2f803ae8, 0x3ad0, 0x008d0040 },
+ { 0x02800031, 0x2e203a48, 0x0e8d0f40, 0x08840001 },
+ { 0x05800031, 0x20003a40, 0x0e8d0e20, 0x90031000 },
#else
/* Write all -1 */
{ 0x0061, 0x2e000608, 0x, 0x3f80 },
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dsi: rename the current DSI
files based on generation
URL : https://patchwork.freedesktop.org/series/45842/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9512 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/45842/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9512 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9512
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9512: 84bc29fb9b4a7d759b32f750b47d299b16803bcc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
84bc29fb9b4a drm/i915/dsi: use gen7 prefix for the global DSI functions
2f2fffcc177c drm/i915/dsi: rename the current DSI files based on generation
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9512/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation
== Series Details == Series: series starting with [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation URL : https://patchwork.freedesktop.org/series/45842/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/dsi: rename the current DSI files based on generation +drivers/gpu/drm/i915/gen7_dsi.c:113:33: warning: expression using sizeof(void) +drivers/gpu/drm/i915/gen7_dsi.c:97:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gen7_dsi.c:113:33: warning: expression using sizeof(void) -drivers/gpu/drm/i915/gen7_dsi.c:97:33: warning: expression using sizeof(void) Commit: drm/i915/dsi: use gen7 prefix for the global DSI functions Okay! ___ 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 [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation
== Series Details == Series: series starting with [v2,1/2] drm/i915/dsi: rename the current DSI files based on generation URL : https://patchwork.freedesktop.org/series/45842/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2f2fffcc177c drm/i915/dsi: rename the current DSI files based on generation -:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #45: rename from drivers/gpu/drm/i915/intel_dsi.c total: 0 errors, 1 warnings, 0 checks, 38 lines checked 84bc29fb9b4a drm/i915/dsi: use gen7 prefix for the global DSI functions ___ 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/selftests: Drop struct_mutex around lowlevel pggtt allocation (rev2)
== Series Details ==
Series: drm/i915/selftests: Drop struct_mutex around lowlevel pggtt allocation
(rev2)
URL : https://patchwork.freedesktop.org/series/45819/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9511 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/45819/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_9511 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-glk-dsi: PASS -> FAIL (fdo#100368)
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-skl-6700k2: PASS -> FAIL (fdo#103191, fdo#104724)
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9511
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9511: 4a7a99672e4ddc5e11654cdaa681fc5ea8d4c5f4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4a7a99672e4d drm/i915/selftests: Drop struct_mutex around lowlevel pggtt
allocation
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9511/issues.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: Use 64-bit write to optimize writing fence_reg on VGPU
== Series Details ==
Series: drm/i915: Use 64-bit write to optimize writing fence_reg on VGPU
URL : https://patchwork.freedesktop.org/series/45841/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9510 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/45841/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_9510 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
== Participating hosts (45 -> 40) ==
Additional (1): fi-bxt-dsi
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9510
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9510: 8f3afb60f04c05b46289401cc19d38451fbf2c70 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8f3afb60f04c drm/i915: Use 64-bit write to optimize writing fence_reg on VGPU
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9510/issues.html
___
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: declare gvt as i915's soft dependency
== Series Details == Series: drm/i915: declare gvt as i915's soft dependency URL : https://patchwork.freedesktop.org/series/45821/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4420_full -> Patchwork_9506_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9506_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9506_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_9506_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-blt: shard-kbl: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9506_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#106509, fdo#105454) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-kbl: FAIL (fdo#106886) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS Warnings igt@drv_selftest@live_gtt: shard-kbl: INCOMPLETE (fdo#103665) -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4420 -> Patchwork_9506 CI_DRM_4420: d9596d1a02b553958c684ef2ea0d3e64e8f68efe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9506: b9b4a8fdf1a3d9a70bf63caec84facdc49dac638 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9506/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dsi: rename the current DSI files based on generation
On Tue, Jul 03, 2018 at 04:53:28PM +0300, Jani Nikula wrote:
> Starting from ICL or gen 11 we have a new DSI block which requires
> completely different programming from the current implementation. Having
> them in the same file would be confusing. Rename the current DSI and DSI
> PLL implementation files as gen7_dsi.c and gen7_dsi_pll.c.
gen7 is a rather odd name for this. vlv would seem more
appropriate, though not particularly good either.
>
> No functional changes.
>
> References: https://patchwork.freedesktop.org/series/44823/
> Cc: Madhav Chauhan
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Makefile| 4 ++--
> drivers/gpu/drm/i915/{intel_dsi.c => gen7_dsi.c} | 0
> drivers/gpu/drm/i915/{intel_dsi_pll.c => gen7_dsi_pll.c} | 0
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_dsi.h | 4 ++--
> 5 files changed, 5 insertions(+), 5 deletions(-)
> rename drivers/gpu/drm/i915/{intel_dsi.c => gen7_dsi.c} (100%)
> rename drivers/gpu/drm/i915/{intel_dsi_pll.c => gen7_dsi_pll.c} (100%)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 4c6adae23e18..a1cfb3a3926b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -135,15 +135,15 @@ i915-y += dvo_ch7017.o \
> dvo_ns2501.o \
> dvo_sil164.o \
> dvo_tfp410.o \
> + gen7_dsi.o \
> + gen7_dsi_pll.o \
> intel_crt.o \
> intel_ddi.o \
> intel_dp_aux_backlight.o \
> intel_dp_link_training.o \
> intel_dp_mst.o \
> intel_dp.o \
> - intel_dsi.o \
> intel_dsi_dcs_backlight.o \
> - intel_dsi_pll.o \
> intel_dsi_vbt.o \
> intel_dvo.o \
> intel_hdmi.o \
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/gen7_dsi.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_dsi.c
> rename to drivers/gpu/drm/i915/gen7_dsi.c
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/gen7_dsi_pll.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_dsi_pll.c
> rename to drivers/gpu/drm/i915/gen7_dsi_pll.c
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b9b70321c054..888a85dc3856 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1730,7 +1730,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector);
> /* intel_dp_mst.c */
> int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
> conn_id);
> void intel_dp_mst_encoder_cleanup(struct intel_digital_port *intel_dig_port);
> -/* intel_dsi.c */
> +/* gen7_dsi.c */
> void intel_dsi_init(struct drm_i915_private *dev_priv);
>
> /* intel_dsi_dcs_backlight.c */
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 7afeb9580f41..1b5c2c167472 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -129,11 +129,11 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
> drm_encoder *encoder)
> return container_of(encoder, struct intel_dsi, base.base);
> }
>
> -/* intel_dsi.c */
> +/* gen7_dsi.c */
> void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port);
> enum mipi_dsi_pixel_format pixel_format_from_register_bits(u32 fmt);
>
> -/* intel_dsi_pll.c */
> +/* gen7_dsi_pll.c */
> bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
> int intel_compute_dsi_pll(struct intel_encoder *encoder,
> struct intel_crtc_state *config);
> --
> 2.11.0
>
> ___
> 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] ✓ Fi.CI.BAT: success for ICELAKE DSI DRIVER (rev2)
== Series Details ==
Series: ICELAKE DSI DRIVER (rev2)
URL : https://patchwork.freedesktop.org/series/44823/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4423 -> Patchwork_9509 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/44823/revisions/2/mbox/
== Known issues ==
Here are the changes found in Patchwork_9509 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)
Possible fixes
igt@gem_exec_suspend@basic-s3:
{fi-cfl-8109u}: INCOMPLETE -> PASS
igt@kms_chamelium@dp-edid-read:
fi-kbl-7500u: FAIL (fdo#103841) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
== Participating hosts (45 -> 41) ==
Additional (1): fi-bxt-dsi
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4423 -> Patchwork_9509
CI_DRM_4423: 9b9b45349fe3a36d41586992426d03a238396531 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4533: 199220052af977598033d3810ffb4cc32d377522 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9509: cd40dd3bd2598cdfec11b40ea20f131ac7744690 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cd40dd3bd259 drm/i915/icl: Configure DSI transcoders
114939859df1 drm/i915/icl: Define TRANS_DSI_FUNC_CONF register
9ef3b3bf6808 drm/i915/icl: Add macros for MMIO of DSI transcoder registers
c7b18a81b3c5 drm/i915/icl: Get DSI transcoder for a given port
4760909d3125 drm/i915/icl: Program TA_TIMING_PARAM registers
a9e9217a3bd3 drm/i915/icl: Define TA_TIMING_PARAM registers
17de6721e0a6 drm/i915/icl: Program DSI clock and data lane timing params
a3ec308da955 drm/i915/icl: Define data/clock lanes dphy timing registers
8f2580e74e6e drm/i915/icl: Program T_INIT_MASTER registers
bcc53825cc97 drm/i915/icl: Define T_INIT_MASTER registers
3dda606aeffa drm/i915/icl: Enable DDI Buffer
4e884239f1e1 drm/i915/icl: DSI vswing programming sequence
9f6dbc7b8083 drm/i915/icl: Configure lane sequencing of combo phy transmitter
3338fcea233b drm/i915/icl: Define AUX lane registers for Port A/B
c03cde1bb29b drm/i915/icl: Power down unused DSI lanes
a5a0e7ef8798 drm/i915/icl: Define PORT_CL_DW_10 register
f42b0a7ec096 drm/i915/icl: Enable DSI IO power
bd698aa15977 drm/i915/icl: Define DSI mode ctl register
5d1f14446c69 drm/i915/icl: Program DSI Escape clock Divider
2fb3a21077c4 drm/i915/icl: Define register for DSI PLL
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9509/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dsi: rename the current DSI files based on generation
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, July 3, 2018 7:23 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Chauhan, Madhav
> ; Daniel Vetter ; Chris
> Wilson
> Subject: [PATCH v2 1/2] drm/i915/dsi: rename the current DSI files based on
> generation
>
> Starting from ICL or gen 11 we have a new DSI block which requires
> completely different programming from the current implementation. Having
> them in the same file would be confusing. Rename the current DSI and DSI
> PLL implementation files as gen7_dsi.c and gen7_dsi_pll.c.
>
> No functional changes.
This looks fine to me,
Reviewed-by: Madhav Chauhan
Regards,
Madhav
>
> References: https://patchwork.freedesktop.org/series/44823/
> Cc: Madhav Chauhan
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Makefile| 4 ++--
> drivers/gpu/drm/i915/{intel_dsi.c => gen7_dsi.c} | 0
> drivers/gpu/drm/i915/{intel_dsi_pll.c => gen7_dsi_pll.c} | 0
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_dsi.h | 4 ++--
> 5 files changed, 5 insertions(+), 5 deletions(-) rename
> drivers/gpu/drm/i915/{intel_dsi.c => gen7_dsi.c} (100%) rename
> drivers/gpu/drm/i915/{intel_dsi_pll.c => gen7_dsi_pll.c} (100%)
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 4c6adae23e18..a1cfb3a3926b 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -135,15 +135,15 @@ i915-y += dvo_ch7017.o \
> dvo_ns2501.o \
> dvo_sil164.o \
> dvo_tfp410.o \
> + gen7_dsi.o \
> + gen7_dsi_pll.o \
> intel_crt.o \
> intel_ddi.o \
> intel_dp_aux_backlight.o \
> intel_dp_link_training.o \
> intel_dp_mst.o \
> intel_dp.o \
> - intel_dsi.o \
> intel_dsi_dcs_backlight.o \
> - intel_dsi_pll.o \
> intel_dsi_vbt.o \
> intel_dvo.o \
> intel_hdmi.o \
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/gen7_dsi.c similarity index 100% rename from
> drivers/gpu/drm/i915/intel_dsi.c rename to
> drivers/gpu/drm/i915/gen7_dsi.c diff --git
> a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/gen7_dsi_pll.c
> similarity index 100%
> rename from drivers/gpu/drm/i915/intel_dsi_pll.c
> rename to drivers/gpu/drm/i915/gen7_dsi_pll.c
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b9b70321c054..888a85dc3856 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1730,7 +1730,7 @@ int intel_dp_aux_init_backlight_funcs(struct
> intel_connector *intel_connector);
> /* intel_dp_mst.c */
> int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
> conn_id); void intel_dp_mst_encoder_cleanup(struct intel_digital_port
> *intel_dig_port);
> -/* intel_dsi.c */
> +/* gen7_dsi.c */
> void intel_dsi_init(struct drm_i915_private *dev_priv);
>
> /* intel_dsi_dcs_backlight.c */
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 7afeb9580f41..1b5c2c167472 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -129,11 +129,11 @@ static inline struct intel_dsi
> *enc_to_intel_dsi(struct drm_encoder *encoder)
> return container_of(encoder, struct intel_dsi, base.base); }
>
> -/* intel_dsi.c */
> +/* gen7_dsi.c */
> void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port);
> enum mipi_dsi_pixel_format pixel_format_from_register_bits(u32 fmt);
>
> -/* intel_dsi_pll.c */
> +/* gen7_dsi_pll.c */
> bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv); int
> intel_compute_dsi_pll(struct intel_encoder *encoder,
> struct intel_crtc_state *config);
> --
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU
Quoting Zhao, Yakui (2018-07-03 14:58:31) > >-Original Message- > >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > >Sent: Tuesday, July 3, 2018 9:25 PM > >To: Zhao, Yakui ; Daniel Vetter > >Cc: intel-gfx@lists.freedesktop.org > >Subject: RE: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once > >on > >VGPU > > > >Quoting Zhao, Yakui (2018-07-03 13:47:46) > >> > >> >-Original Message- > >> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of > >> >Daniel Vetter > >> >Sent: Tuesday, July 3, 2018 5:52 PM > >> >To: Chris Wilson > >> >Cc: Daniel Vetter ; Zhao, Yakui > >> >; intel-gfx@lists.freedesktop.org > >> >Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg > >> >only once on VGPU > >> > > >> >On Tue, Jul 03, 2018 at 10:05:28AM +0100, Chris Wilson wrote: > >> >> Quoting Daniel Vetter (2018-07-03 09:51:03) > >> >> > On Tue, Jul 03, 2018 at 10:56:17AM +0800, Zhao Yakui wrote: > >> >> > > On VGPU scenario the read/write operation of fence_reg will be > >> >> > > trapped by the GVT-g. And then gvt-g follows the HW spec to > >> >> > > write the > >> >fence_reg. > >> >> > > So it is unnecessary to read/write fence reg several times. > >> >> > > This will help to reduce the unnecessary trap of fence_reg mmio > >operation. > >> >> > > > >> >> > > V1->V2: Fix one typo error of parameter when calling > >> >> > > V1->intel_vgpu_active > >> >> > > > >> >> > > Signed-off-by: Zhao Yakui > >> >> > > >> >> > Ok this makes more sense. Except you need to put the 64bit > >> >> > entirely into the vpgu block, with a comment explaining why this > >> >> > is safe (since the vpgu will take care of updating fences correctly). > >> >> > >> >> Except, who cares? Are fence registers being rewritten that > >> >> frequently that special casing vgpu is worth the hassle. Part of > >> >> that is that you need to leave a hint behind in the code that (a) > >> >> explains why it is safe after having the "here be dragons" and (b) why > >> >> we > >care. > >> >> > >> >> On a more pragmatic level if fencing doesn't plateau out to steady > >> >> state, that is a worrying amount of contention -- the actual fence > >> >> write itself would be the least of my worries. > >> > > >> >I can easily imagine that with the few per-client fences vgpu hands > >> >out rewrites are much more common. But yeah some real data would be > >good. > >> >And more reasons to get mesa off of the gtt mmaps. > >> > >> Hi, Daniel/Chris > >> > >> Thanks for your comments. > >> The fence reg is used to assure the access of Tiled surface > >> through aperature window. When fence is needed, the driver helps to > >> find one available fence reg and then configure it. After it is not used, > >> the > >fence will be turned off and then be allocated for next usage. It doesn't > >rely on > >the state of fence reg. In such case we don't need to worry about the > >unsteady state. > >> > >> For the VGPU operation: The op of fence reg is trapped. Then the > >> gvt-g > >will follow the trapped value to program the fence_reg. > >> (It will turn off and then write the expected value for any trapped write > >> op > >of fence reg). The trapped op in GVT-g is safe. > >> > >> Based on the current logic, it needs the five traps when one fence > >> reg is > >configured under VGPU mode.(Three writes, two reads). > >> If it is programmed in one 64-bit op under VGPU mode, only one trap is > >needed. And the GVT-g still can configure the expected fence_value. > >> As the trap is quite heavy for VGPU, the trap time can be saved. > > > >But the argument is can we avoid it entirely by never changing the fence. You > >say this is used for mapping through the aperture (GTT), we say userspace > >shouldn't be doing that for performance reasons :) A slow trap on top of a > >slow operation that is already causing contention seems more sensible to fix > >at source. (Albeit so long as the maintenance burden is considered and found > >to be reasonable, adding special cases with their rationale is acceptable.) > >So > >you have to sell why this mmio is worthy of special attention and curtail any > >future questions. > > If the userspace driver/app can take care of the buffer allocation especially > for the tiled > surface, maybe it can reduce the ratio of changing the fence. But this can't > be avoided if the tiled > buffer is needed and allocated. This also depends on the userspace driver. > And it is beyond the > responsibility of the kernel driver. We own the stack. If userspace is not behaving as well as it might, we need to let them know. Improving algorithms is several orders more beneficial than micro-optimising the implementation. (Speaking as one who sadly does do much of the latter.) But you are asking us to maintain this path with neither any CI coverage nor any indication of the userspace impact. > If it is configured in non-VGPU mode, the several writes of fence_reg doesn't > matter. But un
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for ICELAKE DSI DRIVER (rev2)
== Series Details == Series: ICELAKE DSI DRIVER (rev2) URL : https://patchwork.freedesktop.org/series/44823/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/icl: Define register for DSI PLL Okay! Commit: drm/i915/icl: Program DSI Escape clock Divider Okay! Commit: drm/i915/icl: Define DSI mode ctl register Okay! Commit: drm/i915/icl: Enable DSI IO power Okay! Commit: drm/i915/icl: Define PORT_CL_DW_10 register Okay! Commit: drm/i915/icl: Power down unused DSI lanes Okay! Commit: drm/i915/icl: Define AUX lane registers for Port A/B Okay! Commit: drm/i915/icl: Configure lane sequencing of combo phy transmitter Okay! Commit: drm/i915/icl: DSI vswing programming sequence Okay! Commit: drm/i915/icl: Enable DDI Buffer Okay! Commit: drm/i915/icl: Define T_INIT_MASTER registers Okay! Commit: drm/i915/icl: Program T_INIT_MASTER registers Okay! Commit: drm/i915/icl: Define data/clock lanes dphy timing registers Okay! Commit: drm/i915/icl: Program DSI clock and data lane timing params -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:644:26: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:644:26: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:686:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:686:25: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:718:37: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_dsi_vbt.c:718:37: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:629:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:629:25: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:630:26: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:630:26: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:802:37: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_dsi_vbt.c:802:37: warning: expression using sizeof(void) Commit: drm/i915/icl: Define TA_TIMING_PARAM registers Okay! Commit: drm/i915/icl: Program TA_TIMING_PARAM registers Okay! Commit: drm/i915/icl: Get DSI transcoder for a given port Okay! Commit: drm/i915/icl: Add macros for MMIO of DSI transcoder registers Okay! Commit: drm/i915/icl: Define TRANS_DSI_FUNC_CONF register Okay! Commit: drm/i915/icl: Configure DSI transcoders Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU
>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Tuesday, July 3, 2018 9:25 PM >To: Zhao, Yakui ; Daniel Vetter >Cc: intel-gfx@lists.freedesktop.org >Subject: RE: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on >VGPU > >Quoting Zhao, Yakui (2018-07-03 13:47:46) >> >> >-Original Message- >> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of >> >Daniel Vetter >> >Sent: Tuesday, July 3, 2018 5:52 PM >> >To: Chris Wilson >> >Cc: Daniel Vetter ; Zhao, Yakui >> >; intel-gfx@lists.freedesktop.org >> >Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg >> >only once on VGPU >> > >> >On Tue, Jul 03, 2018 at 10:05:28AM +0100, Chris Wilson wrote: >> >> Quoting Daniel Vetter (2018-07-03 09:51:03) >> >> > On Tue, Jul 03, 2018 at 10:56:17AM +0800, Zhao Yakui wrote: >> >> > > On VGPU scenario the read/write operation of fence_reg will be >> >> > > trapped by the GVT-g. And then gvt-g follows the HW spec to >> >> > > write the >> >fence_reg. >> >> > > So it is unnecessary to read/write fence reg several times. >> >> > > This will help to reduce the unnecessary trap of fence_reg mmio >operation. >> >> > > >> >> > > V1->V2: Fix one typo error of parameter when calling >> >> > > V1->intel_vgpu_active >> >> > > >> >> > > Signed-off-by: Zhao Yakui >> >> > >> >> > Ok this makes more sense. Except you need to put the 64bit >> >> > entirely into the vpgu block, with a comment explaining why this >> >> > is safe (since the vpgu will take care of updating fences correctly). >> >> >> >> Except, who cares? Are fence registers being rewritten that >> >> frequently that special casing vgpu is worth the hassle. Part of >> >> that is that you need to leave a hint behind in the code that (a) >> >> explains why it is safe after having the "here be dragons" and (b) why we >care. >> >> >> >> On a more pragmatic level if fencing doesn't plateau out to steady >> >> state, that is a worrying amount of contention -- the actual fence >> >> write itself would be the least of my worries. >> > >> >I can easily imagine that with the few per-client fences vgpu hands >> >out rewrites are much more common. But yeah some real data would be >good. >> >And more reasons to get mesa off of the gtt mmaps. >> >> Hi, Daniel/Chris >> >> Thanks for your comments. >> The fence reg is used to assure the access of Tiled surface >> through aperature window. When fence is needed, the driver helps to >> find one available fence reg and then configure it. After it is not used, the >fence will be turned off and then be allocated for next usage. It doesn't rely >on >the state of fence reg. In such case we don't need to worry about the >unsteady state. >> >> For the VGPU operation: The op of fence reg is trapped. Then the gvt-g >will follow the trapped value to program the fence_reg. >> (It will turn off and then write the expected value for any trapped write op >of fence reg). The trapped op in GVT-g is safe. >> >> Based on the current logic, it needs the five traps when one fence >> reg is >configured under VGPU mode.(Three writes, two reads). >> If it is programmed in one 64-bit op under VGPU mode, only one trap is >needed. And the GVT-g still can configure the expected fence_value. >> As the trap is quite heavy for VGPU, the trap time can be saved. > >But the argument is can we avoid it entirely by never changing the fence. You >say this is used for mapping through the aperture (GTT), we say userspace >shouldn't be doing that for performance reasons :) A slow trap on top of a >slow operation that is already causing contention seems more sensible to fix >at source. (Albeit so long as the maintenance burden is considered and found >to be reasonable, adding special cases with their rationale is acceptable.) So >you have to sell why this mmio is worthy of special attention and curtail any >future questions. If the userspace driver/app can take care of the buffer allocation especially for the tiled surface, maybe it can reduce the ratio of changing the fence. But this can't be avoided if the tiled buffer is needed and allocated. This also depends on the userspace driver. And it is beyond the responsibility of the kernel driver. If it is configured in non-VGPU mode, the several writes of fence_reg doesn't matter. But under the VGPU mode, the trap of fence_reg will cause that it exits the mode of Virtual machine. After the trap emulation is finished, it can return to the guest OS and then resume the following sequence(For example: On KVMGT it will exit to the Linux host from the guest OS.). The exit of guest OS is quite costing. (For example: It needs to check the exit reason and check who/how to do the trap emulation). As it is mentioned in the previous email, the current sequence on VGPU needs five traps when one fence reg Is programmed.(Three writes, two reads). If only one trap is needed while it can configure the fence reg correctl
[Intel-gfx] [PATCH v2] drm/i915/selftests: Drop struct_mutex around lowlevel pggtt allocation
For a ppgtt that we are constructing, there is no struct_mutex
dependence so skip it. In the process, also ping the scheduler
frequently to try and avoid the NMI watchdog.
v2: gen6 requires struct_mutex to clean up (currently)
Suggested-by: Tvrtko Ursulin
References: https://bugs.freedesktop.org/show_bug.cgi?id=107094
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index a28ee0cc6a63..4393b6d992e0 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -142,12 +142,9 @@ static int igt_ppgtt_alloc(void *arg)
if (!USES_PPGTT(dev_priv))
return 0;
- mutex_lock(&dev_priv->drm.struct_mutex);
ppgtt = __hw_ppgtt_create(dev_priv);
- if (IS_ERR(ppgtt)) {
- err = PTR_ERR(ppgtt);
- goto err_unlock;
- }
+ if (IS_ERR(ppgtt))
+ return PTR_ERR(ppgtt);
if (!ppgtt->vm.allocate_va_range)
goto err_ppgtt_cleanup;
@@ -166,6 +163,8 @@ static int igt_ppgtt_alloc(void *arg)
goto err_ppgtt_cleanup;
}
+ cond_resched();
+
ppgtt->vm.clear_range(&ppgtt->vm, 0, size);
}
@@ -183,13 +182,15 @@ static int igt_ppgtt_alloc(void *arg)
}
goto err_ppgtt_cleanup;
}
+
+ cond_resched();
}
err_ppgtt_cleanup:
+ mutex_lock(&dev_priv->drm.struct_mutex);
ppgtt->vm.cleanup(&ppgtt->vm);
- kfree(ppgtt);
-err_unlock:
mutex_unlock(&dev_priv->drm.struct_mutex);
+ kfree(ppgtt);
return err;
}
--
2.18.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/dsi: rename the current DSI files based on generation
Starting from ICL or gen 11 we have a new DSI block which requires
completely different programming from the current implementation. Having
them in the same file would be confusing. Rename the current DSI and DSI
PLL implementation files as gen7_dsi.c and gen7_dsi_pll.c.
No functional changes.
References: https://patchwork.freedesktop.org/series/44823/
Cc: Madhav Chauhan
Cc: Daniel Vetter
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile| 4 ++--
drivers/gpu/drm/i915/{intel_dsi.c => gen7_dsi.c} | 0
drivers/gpu/drm/i915/{intel_dsi_pll.c => gen7_dsi_pll.c} | 0
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dsi.h | 4 ++--
5 files changed, 5 insertions(+), 5 deletions(-)
rename drivers/gpu/drm/i915/{intel_dsi.c => gen7_dsi.c} (100%)
rename drivers/gpu/drm/i915/{intel_dsi_pll.c => gen7_dsi_pll.c} (100%)
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4c6adae23e18..a1cfb3a3926b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -135,15 +135,15 @@ i915-y += dvo_ch7017.o \
dvo_ns2501.o \
dvo_sil164.o \
dvo_tfp410.o \
+ gen7_dsi.o \
+ gen7_dsi_pll.o \
intel_crt.o \
intel_ddi.o \
intel_dp_aux_backlight.o \
intel_dp_link_training.o \
intel_dp_mst.o \
intel_dp.o \
- intel_dsi.o \
intel_dsi_dcs_backlight.o \
- intel_dsi_pll.o \
intel_dsi_vbt.o \
intel_dvo.o \
intel_hdmi.o \
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/gen7_dsi.c
similarity index 100%
rename from drivers/gpu/drm/i915/intel_dsi.c
rename to drivers/gpu/drm/i915/gen7_dsi.c
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/gen7_dsi_pll.c
similarity index 100%
rename from drivers/gpu/drm/i915/intel_dsi_pll.c
rename to drivers/gpu/drm/i915/gen7_dsi_pll.c
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b9b70321c054..888a85dc3856 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1730,7 +1730,7 @@ int intel_dp_aux_init_backlight_funcs(struct
intel_connector *intel_connector);
/* intel_dp_mst.c */
int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int
conn_id);
void intel_dp_mst_encoder_cleanup(struct intel_digital_port *intel_dig_port);
-/* intel_dsi.c */
+/* gen7_dsi.c */
void intel_dsi_init(struct drm_i915_private *dev_priv);
/* intel_dsi_dcs_backlight.c */
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 7afeb9580f41..1b5c2c167472 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -129,11 +129,11 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
}
-/* intel_dsi.c */
+/* gen7_dsi.c */
void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port);
enum mipi_dsi_pixel_format pixel_format_from_register_bits(u32 fmt);
-/* intel_dsi_pll.c */
+/* gen7_dsi_pll.c */
bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
int intel_compute_dsi_pll(struct intel_encoder *encoder,
struct intel_crtc_state *config);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915/dsi: use gen7 prefix for the global DSI functions
Avoid confusion with the functions to be added for the new gen 11 DSI
implementation by renaming the current DSI functions. While at it,
permutate the words in the function names to make them all start with
"gen7_dsi" or "gen7_dsi_pll".
Leave the static functions as-is for now; they could be renamed later if
needed.
No functional changes.
References: https://patchwork.freedesktop.org/series/44823/
Cc: Madhav Chauhan
Cc: Daniel Vetter
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gen7_dsi.c | 21 ++---
drivers/gpu/drm/i915/gen7_dsi_pll.c | 18 +-
drivers/gpu/drm/i915/intel_display.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dsi.h | 21 ++---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 2 +-
6 files changed, 34 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gen7_dsi.c b/drivers/gpu/drm/i915/gen7_dsi.c
index 3b7acb5a70b3..6dd5e9988221 100644
--- a/drivers/gpu/drm/i915/gen7_dsi.c
+++ b/drivers/gpu/drm/i915/gen7_dsi.c
@@ -69,7 +69,7 @@ enum mipi_dsi_pixel_format
pixel_format_from_register_bits(u32 fmt)
}
}
-void wait_for_dsi_fifo_empty(struct intel_dsi *intel_dsi, enum port port)
+void gen7_dsi_wait_for_fifo_empty(struct intel_dsi *intel_dsi, enum port port)
{
struct drm_encoder *encoder = &intel_dsi->base.base;
struct drm_device *dev = encoder->dev;
@@ -344,7 +344,7 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
pipe_config->cpu_transcoder = TRANSCODER_DSI_A;
}
- ret = intel_compute_dsi_pll(encoder, pipe_config);
+ ret = gen7_dsi_pll_compute(encoder, pipe_config);
if (ret)
return false;
@@ -810,8 +810,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder,
* The BIOS may leave the PLL in a wonky state where it doesn't
* lock. It needs to be fully powered down to fix it.
*/
- intel_disable_dsi_pll(encoder);
- intel_enable_dsi_pll(encoder, pipe_config);
+ gen7_dsi_pll_disable(encoder);
+ gen7_dsi_pll_enable(encoder, pipe_config);
if (IS_BROXTON(dev_priv)) {
/* Add MIPI IO reset programming for modeset */
@@ -949,7 +949,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
if (is_vid_mode(intel_dsi)) {
for_each_dsi_port(port, intel_dsi->ports)
- wait_for_dsi_fifo_empty(intel_dsi, port);
+ gen7_dsi_wait_for_fifo_empty(intel_dsi, port);
intel_dsi_port_disable(encoder);
usleep_range(2000, 5000);
@@ -979,7 +979,7 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder,
val & ~MIPIO_RST_CTRL);
}
- intel_disable_dsi_pll(encoder);
+ gen7_dsi_pll_disable(encoder);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
u32 val;
@@ -1024,7 +1024,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
* configuration, otherwise accessing DSI registers will hang the
* machine. See BSpec North Display Engine registers/MIPI[BXT].
*/
- if (IS_GEN9_LP(dev_priv) && !intel_dsi_pll_is_enabled(dev_priv))
+ if (IS_GEN9_LP(dev_priv) && !gen7_dsi_pll_is_enabled(dev_priv))
goto out_put_power;
/* XXX: this only works for one DSI output */
@@ -1250,8 +1250,7 @@ static void intel_dsi_get_config(struct intel_encoder
*encoder,
if (IS_GEN9_LP(dev_priv))
bxt_dsi_get_pipe_config(encoder, pipe_config);
- pclk = intel_dsi_get_pclk(encoder, pipe_config->pipe_bpp,
- pipe_config);
+ pclk = gen7_dsi_get_pclk(encoder, pipe_config->pipe_bpp, pipe_config);
if (!pclk)
return;
@@ -1590,7 +1589,7 @@ static void intel_dsi_unprepare(struct intel_encoder
*encoder)
/* Panel commands can be sent when clock is in LP11 */
I915_WRITE(MIPI_DEVICE_READY(port), 0x0);
- intel_dsi_reset_clocks(encoder, port);
+ gen7_dsi_reset_clocks(encoder, port);
I915_WRITE(MIPI_EOT_DISABLE(port), CLOCKSTOP);
val = I915_READ(MIPI_DSI_FUNC_PRG(port));
@@ -1713,7 +1712,7 @@ static void intel_dsi_add_properties(struct
intel_connector *connector)
}
}
-void intel_dsi_init(struct drm_i915_private *dev_priv)
+void gen7_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
struct intel_dsi *intel_dsi;
diff --git a/drivers/gpu/drm/i915/gen7_dsi_pll.c
b/drivers/gpu/drm/i915/gen7_dsi_pll.c
index 2ff2ee7f3b78..bb46996a5843 100644
--- a/drivers/gpu/drm/i915/gen7_dsi_pll.c
+++ b/drivers/gpu/drm/i915/gen7_dsi_pll.c
@@ -357,8 +357,8 @@ static u32 bx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for ICELAKE DSI DRIVER (rev2)
== Series Details ==
Series: ICELAKE DSI DRIVER (rev2)
URL : https://patchwork.freedesktop.org/series/44823/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2fb3a21077c4 drm/i915/icl: Define register for DSI PLL
5d1f14446c69 drm/i915/icl: Program DSI Escape clock Divider
-:40: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#40:
new file mode 100644
-:45: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#45: FILE: drivers/gpu/drm/i915/intel_dsi_new.c:1:
+/*
-:90: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#90: FILE: drivers/gpu/drm/i915/intel_dsi_new.c:46:
+ I915_WRITE(ICL_DSI_ESC_CLK_DIV(port),
+ esc_clk_div_m & ICL_ESC_CLK_DIV_MASK);
-:96: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#96: FILE: drivers/gpu/drm/i915/intel_dsi_new.c:52:
+ I915_WRITE(ICL_DPHY_ESC_CLK_DIV(port),
+ esc_clk_div_m & ICL_ESC_CLK_DIV_MASK);
-:103: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#103: FILE: drivers/gpu/drm/i915/intel_dsi_new.c:59:
+gen11_dsi_pre_enable(struct intel_encoder *encoder,
+ const struct intel_crtc_state *pipe_config,
total: 0 errors, 2 warnings, 3 checks, 78 lines checked
bd698aa15977 drm/i915/icl: Define DSI mode ctl register
f42b0a7ec096 drm/i915/icl: Enable DSI IO power
a5a0e7ef8798 drm/i915/icl: Define PORT_CL_DW_10 register
c03cde1bb29b drm/i915/icl: Power down unused DSI lanes
3338fcea233b drm/i915/icl: Define AUX lane registers for Port A/B
9f6dbc7b8083 drm/i915/icl: Configure lane sequencing of combo phy transmitter
4e884239f1e1 drm/i915/icl: DSI vswing programming sequence
-:33: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#33: FILE: drivers/gpu/drm/i915/intel_dsi_new.c:39:
+ for_each_dsi_port(port, intel_dsi->ports) {
+
total: 0 errors, 0 warnings, 1 checks, 132 lines checked
3dda606aeffa drm/i915/icl: Enable DDI Buffer
bcc53825cc97 drm/i915/icl: Define T_INIT_MASTER registers
8f2580e74e6e drm/i915/icl: Program T_INIT_MASTER registers
a3ec308da955 drm/i915/icl: Define data/clock lanes dphy timing registers
-:31: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#31: FILE: drivers/gpu/drm/i915/i915_reg.h:10089:
+#define CLK_PREP_TIME(x) (x << 28)
-:33: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#33: FILE: drivers/gpu/drm/i915/i915_reg.h:10091:
+#define CLK_ZERO_TIME(x) (x << 20)
-:35: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#35: FILE: drivers/gpu/drm/i915/i915_reg.h:10093:
+#define CLK_PRE_TIME(x) (x << 16)
-:37: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#37: FILE: drivers/gpu/drm/i915/i915_reg.h:10095:
+#define CLK_POST_TIME(x) (x << 8)
-:39: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#39: FILE: drivers/gpu/drm/i915/i915_reg.h:10097:
+#define CLK_TRAIL_TIME(x) (x << 0)
-:52: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#52: FILE: drivers/gpu/drm/i915/i915_reg.h:10110:
+#define HS_PREP_TIME(x) (x << 24)
-:54: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#54: FILE: drivers/gpu/drm/i915/i915_reg.h:10112:
+#define HS_ZERO_TIME(x) (x << 16)
-:56: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#56: FILE: drivers/gpu/drm/i915/i915_reg.h:10114:
+#define HS_TRAIL_TIME(x) (x << 8)
-:58: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#58: FILE: drivers/gpu/drm/i915/i915_reg.h:10116:
+#define HS_EXIT_TIME(x) (x << 0)
total: 0 errors, 0 warnings, 9 checks, 46 lines checked
17de6721e0a6 drm/i915/icl: Program DSI clock and data lane timing params
-:80: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#80: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:631:
+ ths_prepare_ns = max(mipi_config->ths_prepare,
+ mipi_config->tclk_prepare);
-:114: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#114: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:655:
+ clk_zero_cnt = DIV_ROUND_UP(
-:128: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#128: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:669:
+ hs_zero_cnt = DIV_ROUND_UP(
-:190: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#190: FILE: drivers/gpu/drm/i915/intel_dsi_vbt.c:727:
+ prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den,
+
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Drop struct_mutex around lowlevel pggtt allocation
== Series Details == Series: drm/i915/selftests: Drop struct_mutex around lowlevel pggtt allocation URL : https://patchwork.freedesktop.org/series/45819/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4420_full -> Patchwork_9505_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9505_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9505_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_9505_full: === IGT changes === Possible regressions igt@drv_selftest@live_gtt: shard-snb: PASS -> DMESG-WARN shard-hsw: PASS -> DMESG-WARN igt@kms_universal_plane@cursor-fb-leak-pipe-c: shard-apl: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9505_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@gem_ctx_switch@basic-all-light: shard-hsw: PASS -> INCOMPLETE (fdo#103540) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: PASS -> FAIL (fdo#105454, fdo#106509) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105189) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-kbl: FAIL (fdo#106886) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-atomic-transitions-varying-size: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4420 -> Patchwork_9505 CI_DRM_4420: d9596d1a02b553958c684ef2ea0d3e64e8f68efe @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9505: fe0932abd5dd4b3ad24cbdaed10351ed8e279b4e @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9505/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Use 64-bit write to optimize writing fence_reg on VGPU
Quoting Zhao Yakui (2018-07-03 14:27:47)
> On VGPU scenario the read/write operation of fence_reg will be trapped
> by the GVT-g. Then gvt-g follows the HW spec to program the fence_reg.
> And the gvt-g takes care of updating the fence reg correctly for any
> trapped value of fence reg.
>
> So it is unnecessary to read/write fence reg several times. It is enough
> that the fence reg is written only value in 64-bit mdoe. This will help
> to reduce the redundantt trap of fence_reg mmio operation.
>
> V1->V2: Fix one typo error of parameter when calling intel_vgpu_active.
> V2->V3: Follow Chris Wilson and Daniel Vetter to add more descriptions.
>
> Signed-off-by: Zhao Yakui
> ---
> drivers/gpu/drm/i915/i915_gem_fence_reg.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> index d548ac0..7b10bf9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> @@ -63,6 +63,7 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg
> *fence,
> i915_reg_t fence_reg_lo, fence_reg_hi;
> int fence_pitch_shift;
> u64 val;
> + struct drm_i915_private *dev_priv = fence->i915;
>
> if (INTEL_GEN(fence->i915) >= 6) {
> fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
> @@ -92,9 +93,17 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg
> *fence,
> val |= I965_FENCE_REG_VALID;
> }
>
> - if (!pipelined) {
> - struct drm_i915_private *dev_priv = fence->i915;
Ahem.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2
Am 03.07.2018 um 15:11 schrieb Daniel Vetter:
On Tue, Jul 03, 2018 at 03:02:11PM +0200, Christian König wrote:
Am 03.07.2018 um 14:52 schrieb Daniel Vetter:
On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:
Am 25.06.2018 um 11:12 schrieb Daniel Vetter:
On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:
On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Ok I did review drivers a bit, but apparently not well enough by far. i915
CI is unhappy:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html
So yeah inserting that lock in there isn't the most trivial thing :-/
I kinda assume that other drivers will have similar issues, e.g. omapdrm's
use of dev->struct_mutex also very much looks like it'll result in a new
locking inversion.
Ah, crap. Already feared that this wouldn't be easy, but yeah that it is as
bad as this is rather disappointing.
Thanks for the info, going to keep thinking about how to solve those issues.
Side note: We want to make sure that drivers don't get the reservation_obj
locking hierarchy wrong in other places (using dev->struct_mutex is kinda
a pre-existing mis-use that we can't wish away retroactively
unfortunately). One really important thing is that shrinker vs resv_obj
must work with trylocks in the shrinker, so that you can allocate memory
while holding reservation objects.
One neat trick to teach lockdep about this would be to have a dummy
if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
ww_mutex_lock(dma_buf->resv_obj);
fs_reclaim_acquire(GFP_KERNEL);
fs_reclaim_release(GFP_KERNEL);
ww_mutex_unlock(dma_buf->resv_obj);
}
in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
successfully to improve our igt test coverage for i915.ko in other areas.
Totally unrelated to dev->struct_mutex, but thoughts? Well for
dev->struct_mutex we could at least decide on one true way to nest
resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
much that would help.
I don't think that would help. As far as I can see we only have two choices:
1. Either have a big patch which fixes all DMA-buf implementations to allow
the reservation lock to be held during map/unmap (unrealistic).
2. Add a flag to at least in the mid term tell the DMA-buf helper functions
what to do. E.g. create the mapping without the reservation lock held.
How about moving the SGL caching from the DRM layer into the DMA-buf layer
and add a flag if the exporter wants/needs this caching?
Then only the implementations which can deal with dynamic invalidation
disable SGL caching and with it enable creating the sgl with the reservation
object locked.
This way we can kill two birds with one stone by both avoiding the SGL
caching in the DRM layer as well as having a sane handling for the locking.
Thoughts?
I don't see how the SGL stuff factors into neither the dev->struct_mutex
nor into the need to do allocations while holding resv_obj. Neither
changes by moving that piece around. At least as far as I can see it SGL
caching is fully orthogonal to any kind of locking fun.
Why do you see a connection here?
When the exporter's map_dma_buf() callback can't be called with the
reservation lock held we must call it before taking the lock.
Now importers able to deal with dynamic invalidation always want to call
the callback with the reservation lock held. Otherwise they would have
two different code paths, one for the dynamic invalidation and one for
the pinning.
One possibility to solve that problem is to call map_dma_buf() during
the attach phase and cache the resulting sg_table in the attach object.
Only when the exporter says: Ok I can deal with the reservation lock
held during the map_dma_buf() callback we disable the caching.
The only possible drawback I can see is that we now always cache the
sg_table in the DMA-buf handling, while previously we have done it in
the DRM midlayer.
Christian.
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Use 64-bit write to optimize writing fence_reg on VGPU
On VGPU scenario the read/write operation of fence_reg will be trapped
by the GVT-g. Then gvt-g follows the HW spec to program the fence_reg.
And the gvt-g takes care of updating the fence reg correctly for any
trapped value of fence reg.
So it is unnecessary to read/write fence reg several times. It is enough
that the fence reg is written only value in 64-bit mdoe. This will help
to reduce the redundantt trap of fence_reg mmio operation.
V1->V2: Fix one typo error of parameter when calling intel_vgpu_active.
V2->V3: Follow Chris Wilson and Daniel Vetter to add more descriptions.
Signed-off-by: Zhao Yakui
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index d548ac0..7b10bf9 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -63,6 +63,7 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg
*fence,
i915_reg_t fence_reg_lo, fence_reg_hi;
int fence_pitch_shift;
u64 val;
+ struct drm_i915_private *dev_priv = fence->i915;
if (INTEL_GEN(fence->i915) >= 6) {
fence_reg_lo = FENCE_REG_GEN6_LO(fence->id);
@@ -92,9 +93,17 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg
*fence,
val |= I965_FENCE_REG_VALID;
}
- if (!pipelined) {
- struct drm_i915_private *dev_priv = fence->i915;
-
+ if (intel_vgpu_active(dev_priv)) {
+ /* Use the 64-bit RW to write fence reg on VGPU mode.
+* The GVT-g can trap the written val of VGPU to program the
+* fence reg. And the fence write in gvt-g follows the
+* sequence of off/read/double-write/read. This assures that
+* the fence reg is configured correctly.
+* At the same time the 64-bit op can help to reduce the num
+* of VGPU trap for the fence reg.
+*/
+ I915_WRITE64_FW(fence_reg_lo, val);
+ } else {
/* To w/a incoherency with non-atomic 64-bit register updates,
* we split the 64-bit update into two 32-bit writes. In order
* for a partial fence not to be evaluated between writes, we
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU
Quoting Zhao, Yakui (2018-07-03 13:47:46) > > >-Original Message- > >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > >Vetter > >Sent: Tuesday, July 3, 2018 5:52 PM > >To: Chris Wilson > >Cc: Daniel Vetter ; Zhao, Yakui ; > >intel-gfx@lists.freedesktop.org > >Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once > >on > >VGPU > > > >On Tue, Jul 03, 2018 at 10:05:28AM +0100, Chris Wilson wrote: > >> Quoting Daniel Vetter (2018-07-03 09:51:03) > >> > On Tue, Jul 03, 2018 at 10:56:17AM +0800, Zhao Yakui wrote: > >> > > On VGPU scenario the read/write operation of fence_reg will be > >> > > trapped by the GVT-g. And then gvt-g follows the HW spec to write the > >fence_reg. > >> > > So it is unnecessary to read/write fence reg several times. This > >> > > will help to reduce the unnecessary trap of fence_reg mmio operation. > >> > > > >> > > V1->V2: Fix one typo error of parameter when calling > >> > > V1->intel_vgpu_active > >> > > > >> > > Signed-off-by: Zhao Yakui > >> > > >> > Ok this makes more sense. Except you need to put the 64bit entirely > >> > into the vpgu block, with a comment explaining why this is safe > >> > (since the vpgu will take care of updating fences correctly). > >> > >> Except, who cares? Are fence registers being rewritten that frequently > >> that special casing vgpu is worth the hassle. Part of that is that you > >> need to leave a hint behind in the code that (a) explains why it is > >> safe after having the "here be dragons" and (b) why we care. > >> > >> On a more pragmatic level if fencing doesn't plateau out to steady > >> state, that is a worrying amount of contention -- the actual fence > >> write itself would be the least of my worries. > > > >I can easily imagine that with the few per-client fences vgpu hands out > >rewrites are much more common. But yeah some real data would be good. > >And more reasons to get mesa off of the gtt mmaps. > > Hi, Daniel/Chris > > Thanks for your comments. > The fence reg is used to assure the access of Tiled surface through > aperature window. When fence is needed, the driver > helps to find one available fence reg and then configure it. After it is not > used, the fence will be turned off and then be allocated > for next usage. It doesn't rely on the state of fence reg. In such case we > don't need to worry about the unsteady state. > > For the VGPU operation: The op of fence reg is trapped. Then the gvt-g > will follow the trapped value to program the fence_reg. > (It will turn off and then write the expected value for any trapped write op > of fence reg). The trapped op in GVT-g is safe. > > Based on the current logic, it needs the five traps when one fence reg > is configured under VGPU mode.(Three writes, two reads). > If it is programmed in one 64-bit op under VGPU mode, only one trap is > needed. And the GVT-g still can configure the expected fence_value. > As the trap is quite heavy for VGPU, the trap time can be saved. But the argument is can we avoid it entirely by never changing the fence. You say this is used for mapping through the aperture (GTT), we say userspace shouldn't be doing that for performance reasons :) A slow trap on top of a slow operation that is already causing contention seems more sensible to fix at source. (Albeit so long as the maintenance burden is considered and found to be reasonable, adding special cases with their rationale is acceptable.) So you have to sell why this mmio is worthy of special attention and curtail any future questions. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 5/9] drm/client: Add client callbacks
On Tue, Jul 03, 2018 at 03:07:50PM +0200, Noralf Trønnes wrote:
>
> Den 03.07.2018 09.46, skrev Daniel Vetter:
> > On Mon, Jul 02, 2018 at 03:54:29PM +0200, Noralf Trønnes wrote:
> > > Add client callbacks and hook them up.
> > > Add a list of clients per drm_device.
> > >
> > > Signed-off-by: Noralf Trønnes
> > btw for reviewing it'd be simpler if you merge the 2 patches that add the
> > client library, avoids me having to jump back&forth ..
> >
> > Bunch of comments below still.
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/drm_client.c| 92
> > > -
> > > drivers/gpu/drm/drm_drv.c | 7 +++
> > > drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
> > > drivers/gpu/drm/drm_fb_helper.c | 11 -
> > > drivers/gpu/drm/drm_file.c | 3 ++
> > > drivers/gpu/drm/drm_probe_helper.c | 3 ++
> > > include/drm/drm_client.h| 75 +-
> > > include/drm/drm_device.h| 14 ++
> > > 8 files changed, 201 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > > index 9c9b8ac7aea3..f05ee98bd10c 100644
> > > --- a/drivers/gpu/drm/drm_client.c
> > > +++ b/drivers/gpu/drm/drm_client.c
> > > @@ -4,6 +4,7 @@
> > >*/
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -66,6 +67,7 @@ EXPORT_SYMBOL(drm_client_close);
> > >* @dev: DRM device
> > >* @client: DRM client
> > >* @name: Client name
> > > + * @funcs: DRM client functions (optional)
> > >*
> > >* Use drm_client_put() to free the client.
> > >*
> > > @@ -73,24 +75,47 @@ EXPORT_SYMBOL(drm_client_close);
> > >* Zero on success or negative error code on failure.
> > >*/
> > > int drm_client_new(struct drm_device *dev, struct drm_client_dev
> > > *client,
> > > -const char *name)
> > > +const char *name, const struct drm_client_funcs *funcs)
> > > {
> > > + bool registered;
> > > int ret;
> > > if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> > > !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
> > > return -ENOTSUPP;
> > > + if (funcs && !try_module_get(funcs->owner))
> > > + return -ENODEV;
> > > +
> > > client->dev = dev;
> > > client->name = name;
> > > + client->funcs = funcs;
> > > ret = drm_client_open(client);
> > > if (ret)
> > > - return ret;
> > > + goto err_put_module;
> > > +
> > > + mutex_lock(&dev->clientlist_mutex);
> > > + registered = dev->registered;
> > > + if (registered)
> > > + list_add(&client->list, &dev->clientlist);
> > > + mutex_unlock(&dev->clientlist_mutex);
> > > + if (!registered) {
> > > + ret = -ENODEV;
> > > + goto err_close;
> > > + }
> > > drm_dev_get(dev);
> > This only works if the caller holds a reference for us on dev already, or
> > has some other guarantee that it won't disappear. Would be good to mention
> > this in the kerneldoc.
> >
> > > return 0;
> > > +
> > > +err_close:
> > > + drm_client_close(client);
> > > +err_put_module:
> > > + if (funcs)
> > > + module_put(funcs->owner);
> > > +
> > > + return ret;
> > > }
> > > EXPORT_SYMBOL(drm_client_new);
> > > @@ -116,9 +141,72 @@ void drm_client_release(struct drm_client_dev
> > > *client)
> > > drm_client_close(client);
> > > drm_dev_put(dev);
> > > + if (client->funcs)
> > > + module_put(client->funcs->owner);
> > > }
> > > EXPORT_SYMBOL(drm_client_release);
> > > +void drm_client_dev_unregister(struct drm_device *dev)
> > > +{
> > > + struct drm_client_dev *client, *tmp;
> > > +
> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > + return;
> > > +
> > > + mutex_lock(&dev->clientlist_mutex);
> > > + list_for_each_entry_safe(client, tmp, &dev->clientlist, list) {
> > > + list_del(&client->list);
> > > + if (client->funcs && client->funcs->unregister) {
> > > + client->funcs->unregister(client);
> > Hm, not ->unregister is called while holding the lock. I thought that
> > blows up for you?
>
> It is fine now that we decided that the client can't remove itself.
> Only the driver can do it on drm_dev_unregister().
I was more wondering about creating an unecessary locking hierarchy
complication. But through the ->hotplug and ->restore callbacks we already
require that all client locks (which will also include anything related to
fbdev and fbcon, hence also console_lock) must nest within
dev->clientlist_mutex. That's the part I was worried about, but that's not
a good concern really.
So all fine for me on 2nd thought.
>
> > > + } else {
> > > + drm_client_release(client);
> > > + kfree(client);
> > > + }
> > > + }
> > > + mutex_unlock(&dev->clientlist_mutex);
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Touch the NMI watchdog inside a GTT pass
Quoting Tvrtko Ursulin (2018-07-03 13:54:01) > > On 03/07/2018 12:07, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-07-03 12:00:13) > >> > >> On 03/07/2018 11:25, Chris Wilson wrote: > >>> We want to do a complete pass before checking the timeout, but just in > >>> case the pass is quite slow, touch the NMI watchdog to prevent a > >>> false positive. > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Tvrtko Ursulin > >>> --- > >>>drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 8 > >>>1 file changed, 8 insertions(+) > >>> > >>> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > >>> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > >>> index eefcf7b84054..71c0654b4b4d 100644 > >>> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > >>> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > >>> @@ -23,6 +23,7 @@ > >>> */ > >>> > >>>#include > >>> +#include > >>>#include > >>> > >>>#include "../i915_selftest.h" > >>> @@ -686,6 +687,13 @@ static int pot_hole(struct drm_i915_private *i915, > >>>i915_vma_unpin(vma); > >>>err = i915_vma_unbind(vma); > >>>GEM_BUG_ON(err); > >>> + > >>> + /* > >>> + * Do a complete pass before timing out, but just > >>> + * in case we are running too slow, ping the NMI > >>> + * watchdog. > >>> + */ > >>> + touch_nmi_watchdog(); > >>>} > >>> > >>>if (igt_timeout(end_time, > >>> > >> > >> Why only in pot_hole, is this the slowest test? > > > > It's the only test of this style where we don't have the igt_timeout > > (cond_resched) inside the innermost loop. > > So.. the obvious question.. :) Why not move igt_timeout to the innermost > loop and avoid low-level hackery? In looking at it, I felt this case it was more interesting^W important to test each boundary before checking the timeout. I was concerned about declaring the pass a success too early. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2
On Tue, Jul 03, 2018 at 03:02:11PM +0200, Christian König wrote:
> Am 03.07.2018 um 14:52 schrieb Daniel Vetter:
> > On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:
> > > Am 25.06.2018 um 11:12 schrieb Daniel Vetter:
> > > > On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:
> > > > > On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:
> > > > > > First step towards unpinned DMA buf operation.
> > > > > >
> > > > > > I've checked the DRM drivers to potential locking of the reservation
> > > > > > object, but essentially we need to audit all implementations of the
> > > > > > dma_buf _ops for this to work.
> > > > > >
> > > > > > v2: reordered
> > > > > >
> > > > > > Signed-off-by: Christian König
> > > > > Reviewed-by: Daniel Vetter
> > > > Ok I did review drivers a bit, but apparently not well enough by far.
> > > > i915
> > > > CI is unhappy:
> > > >
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html
> > > >
> > > > So yeah inserting that lock in there isn't the most trivial thing :-/
> > > >
> > > > I kinda assume that other drivers will have similar issues, e.g.
> > > > omapdrm's
> > > > use of dev->struct_mutex also very much looks like it'll result in a new
> > > > locking inversion.
> > > Ah, crap. Already feared that this wouldn't be easy, but yeah that it is
> > > as
> > > bad as this is rather disappointing.
> > >
> > > Thanks for the info, going to keep thinking about how to solve those
> > > issues.
> > Side note: We want to make sure that drivers don't get the reservation_obj
> > locking hierarchy wrong in other places (using dev->struct_mutex is kinda
> > a pre-existing mis-use that we can't wish away retroactively
> > unfortunately). One really important thing is that shrinker vs resv_obj
> > must work with trylocks in the shrinker, so that you can allocate memory
> > while holding reservation objects.
> >
> > One neat trick to teach lockdep about this would be to have a dummy
> >
> > if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
> > ww_mutex_lock(dma_buf->resv_obj);
> > fs_reclaim_acquire(GFP_KERNEL);
> > fs_reclaim_release(GFP_KERNEL);
> > ww_mutex_unlock(dma_buf->resv_obj);
> > }
> >
> > in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
> > successfully to improve our igt test coverage for i915.ko in other areas.
> >
> > Totally unrelated to dev->struct_mutex, but thoughts? Well for
> > dev->struct_mutex we could at least decide on one true way to nest
> > resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
> > much that would help.
>
> I don't think that would help. As far as I can see we only have two choices:
>
> 1. Either have a big patch which fixes all DMA-buf implementations to allow
> the reservation lock to be held during map/unmap (unrealistic).
>
> 2. Add a flag to at least in the mid term tell the DMA-buf helper functions
> what to do. E.g. create the mapping without the reservation lock held.
>
>
> How about moving the SGL caching from the DRM layer into the DMA-buf layer
> and add a flag if the exporter wants/needs this caching?
>
> Then only the implementations which can deal with dynamic invalidation
> disable SGL caching and with it enable creating the sgl with the reservation
> object locked.
>
> This way we can kill two birds with one stone by both avoiding the SGL
> caching in the DRM layer as well as having a sane handling for the locking.
>
> Thoughts?
I don't see how the SGL stuff factors into neither the dev->struct_mutex
nor into the need to do allocations while holding resv_obj. Neither
changes by moving that piece around. At least as far as I can see it SGL
caching is fully orthogonal to any kind of locking fun.
Why do you see a connection here?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 5/9] drm/client: Add client callbacks
Den 03.07.2018 09.46, skrev Daniel Vetter:
On Mon, Jul 02, 2018 at 03:54:29PM +0200, Noralf Trønnes wrote:
Add client callbacks and hook them up.
Add a list of clients per drm_device.
Signed-off-by: Noralf Trønnes
btw for reviewing it'd be simpler if you merge the 2 patches that add the
client library, avoids me having to jump back&forth ..
Bunch of comments below still.
-Daniel
---
drivers/gpu/drm/drm_client.c| 92 -
drivers/gpu/drm/drm_drv.c | 7 +++
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
drivers/gpu/drm/drm_fb_helper.c | 11 -
drivers/gpu/drm/drm_file.c | 3 ++
drivers/gpu/drm/drm_probe_helper.c | 3 ++
include/drm/drm_client.h| 75 +-
include/drm/drm_device.h| 14 ++
8 files changed, 201 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9c9b8ac7aea3..f05ee98bd10c 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -66,6 +67,7 @@ EXPORT_SYMBOL(drm_client_close);
* @dev: DRM device
* @client: DRM client
* @name: Client name
+ * @funcs: DRM client functions (optional)
*
* Use drm_client_put() to free the client.
*
@@ -73,24 +75,47 @@ EXPORT_SYMBOL(drm_client_close);
* Zero on success or negative error code on failure.
*/
int drm_client_new(struct drm_device *dev, struct drm_client_dev *client,
- const char *name)
+ const char *name, const struct drm_client_funcs *funcs)
{
+ bool registered;
int ret;
if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
!dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
return -ENOTSUPP;
+ if (funcs && !try_module_get(funcs->owner))
+ return -ENODEV;
+
client->dev = dev;
client->name = name;
+ client->funcs = funcs;
ret = drm_client_open(client);
if (ret)
- return ret;
+ goto err_put_module;
+
+ mutex_lock(&dev->clientlist_mutex);
+ registered = dev->registered;
+ if (registered)
+ list_add(&client->list, &dev->clientlist);
+ mutex_unlock(&dev->clientlist_mutex);
+ if (!registered) {
+ ret = -ENODEV;
+ goto err_close;
+ }
drm_dev_get(dev);
This only works if the caller holds a reference for us on dev already, or
has some other guarantee that it won't disappear. Would be good to mention
this in the kerneldoc.
return 0;
+
+err_close:
+ drm_client_close(client);
+err_put_module:
+ if (funcs)
+ module_put(funcs->owner);
+
+ return ret;
}
EXPORT_SYMBOL(drm_client_new);
@@ -116,9 +141,72 @@ void drm_client_release(struct drm_client_dev *client)
drm_client_close(client);
drm_dev_put(dev);
+ if (client->funcs)
+ module_put(client->funcs->owner);
}
EXPORT_SYMBOL(drm_client_release);
+void drm_client_dev_unregister(struct drm_device *dev)
+{
+ struct drm_client_dev *client, *tmp;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry_safe(client, tmp, &dev->clientlist, list) {
+ list_del(&client->list);
+ if (client->funcs && client->funcs->unregister) {
+ client->funcs->unregister(client);
Hm, not ->unregister is called while holding the lock. I thought that
blows up for you?
It is fine now that we decided that the client can't remove itself.
Only the driver can do it on drm_dev_unregister().
+ } else {
+ drm_client_release(client);
+ kfree(client);
+ }
+ }
+ mutex_unlock(&dev->clientlist_mutex);
+}
+
Needs a bit of kerneldoc here since exported function. Drivers might also
want to call this from their own hotplug handling.
drm_client_dev_hotplug() is only called by drm_kms_helper_hotplug_event().
The reason it's exported is because the helper can be built as a module.
Noralf.
+void drm_client_dev_hotplug(struct drm_device *dev)
+{
+ struct drm_client_dev *client;
+ int ret;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return;
+
+ mutex_lock(&dev->clientlist_mutex);
+ list_for_each_entry(client, &dev->clientlist, list) {
+ if (!client->funcs || !client->funcs->hotplug)
+ continue;
+
+ ret = client->funcs->hotplug(client);
+ DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret);
+ }
+ mutex_unlock(&dev->clientlist_mutex);
+}
+EXPORT_SYMBOL(drm_client_dev_hotplug);
+
+void drm_client_dev_restore(struct d
Re: [Intel-gfx] [PATCH 08/10] drm/crc: Cleanup crtc_crc_open function
On 2018-07-02 07:07 AM, Mahesh Kumar wrote:
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 3 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 4 +-
drivers/gpu/drm/drm_debugfs_crc.c | 52 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_pipe_crc.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 5 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 6 +--
include/drm/drm_crtc.h | 3 +-
8 files changed, 30 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index e43ed064dc46..54056d180003 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -258,8 +258,7 @@ amdgpu_dm_remove_sink_from_freesync_module(struct
drm_connector *connector);
/* amdgpu_dm_crc.c */
#ifdef CONFIG_DEBUG_FS
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt);
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name);
int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
const char *src_name,
size_t *values_cnt);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index dfcca594d52a..e7ad528f5853 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -62,8 +62,7 @@ amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const
char *src_name,
return 0;
}
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt)
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
{
struct dm_crtc_state *crtc_state = to_dm_crtc_state(crtc->state);
struct dc_stream_state *stream_state = crtc_state->stream;
@@ -99,7 +98,6 @@ int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc,
const char *src_name,
return -EINVAL;
}
- *values_cnt = 3;
/* Reset crc_skipped on dm state */
crtc_state->crc_skip_count = 0;
return 0;
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
b/drivers/gpu/drm/drm_debugfs_crc.c
index f4d76528d24c..739a813b4b09 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -124,11 +124,9 @@ static ssize_t crc_control_write(struct file *file, const
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
+ if (ret)
+ return ret;
spin_lock_irq(&crc->lock);
@@ -193,12 +191,15 @@ static int crtc_crc_open(struct inode *inode, struct file *filep)
return ret;
}
- if (crtc->funcs->verify_crc_source) {
- ret = crtc->funcs->verify_crc_source(crtc, crc->source,
-&values_cnt);
- if (ret)
- return ret;
- }
+ ret = crtc->funcs->verify_crc_source(crtc, crc->source, &values_cnt);
+ if (ret)
+ return ret;
+
+ if (WARN_ON(values_cnt > DRM_MAX_CRC_NR))
+ return -EINVAL;
+
+ if (WARN_ON(values_cnt == 0))
+ return -EINVAL;
spin_lock_irq(&crc->lock);
if (!crc->opened)
@@ -210,30 +211,22 @@ static int crtc_crc_open(struct inode *inode, struct file
*filep)
if (ret)
return ret;
- ret = crtc->funcs->set_crc_source(crtc, crc->source, &values_cnt);
- if (ret)
- goto err;
-
- if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
- if (WARN_ON(values_cnt == 0)) {
- ret = -EINVAL;
- goto err_disable;
- }
-
entries = kcalloc(DRM_CRC_ENTRIES_NR, sizeof(*entries), GFP_KERNEL);
if (!entries) {
ret = -ENOMEM;
- goto err_disable;
+
Re: [Intel-gfx] [PATCH 04/10] drm/amdgpu_dm/crc: Implement verify_crc_source callback
On 2018-07-03 06:19 AM, Maarten Lankhorst wrote:
Op 02-07-18 om 13:07 schreef Mahesh Kumar:
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 66bd3cc3e387..dd97cbca0527 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2563,6 +2563,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs =
{
.atomic_duplicate_state = dm_crtc_duplicate_state,
.atomic_destroy_state = dm_crtc_destroy_state,
.set_crc_source = amdgpu_dm_crtc_set_crc_source,
+ .verify_crc_source = amdgpu_dm_crtc_verify_crc_source,
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
};
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index a29dc35954c9..e43ed064dc46 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -260,9 +260,13 @@ amdgpu_dm_remove_sink_from_freesync_module(struct
drm_connector *connector);
#ifdef CONFIG_DEBUG_FS
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
size_t *values_cnt);
+int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *src_name,
+size_t *values_cnt);
void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc);
#else
#define amdgpu_dm_crtc_set_crc_source NULL
+#define amdgpu_dm_crtc_verify_crc_source NULL
#define amdgpu_dm_crtc_handle_crc_irq(x)
#endif
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 52f2c01349e3..dfcca594d52a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -46,6 +46,22 @@ static enum amdgpu_dm_pipe_crc_source
dm_parse_crc_source(const char *source)
return AMDGPU_DM_PIPE_CRC_SOURCE_INVALID;
}
+int
+amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src_name,
+size_t *values_cnt)
+{
+ enum amdgpu_dm_pipe_crc_source source = dm_parse_crc_source(src_name);
+
+ if (source < 0) {
+ DRM_DEBUG_DRIVER("Unknown CRC source %s for CRTC%d\n",
+src_name, crtc->index);
+ return -EINVAL;
+ }
+
+ *values_cnt = 3;
+ return 0;
+}
+
int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
size_t *values_cnt)
{
Ack for merging this and 8/10 through drm-misc?
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2
Am 03.07.2018 um 14:52 schrieb Daniel Vetter:
On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:
Am 25.06.2018 um 11:12 schrieb Daniel Vetter:
On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:
On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
v2: reordered
Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
Ok I did review drivers a bit, but apparently not well enough by far. i915
CI is unhappy:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html
So yeah inserting that lock in there isn't the most trivial thing :-/
I kinda assume that other drivers will have similar issues, e.g. omapdrm's
use of dev->struct_mutex also very much looks like it'll result in a new
locking inversion.
Ah, crap. Already feared that this wouldn't be easy, but yeah that it is as
bad as this is rather disappointing.
Thanks for the info, going to keep thinking about how to solve those issues.
Side note: We want to make sure that drivers don't get the reservation_obj
locking hierarchy wrong in other places (using dev->struct_mutex is kinda
a pre-existing mis-use that we can't wish away retroactively
unfortunately). One really important thing is that shrinker vs resv_obj
must work with trylocks in the shrinker, so that you can allocate memory
while holding reservation objects.
One neat trick to teach lockdep about this would be to have a dummy
if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
ww_mutex_lock(dma_buf->resv_obj);
fs_reclaim_acquire(GFP_KERNEL);
fs_reclaim_release(GFP_KERNEL);
ww_mutex_unlock(dma_buf->resv_obj);
}
in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
successfully to improve our igt test coverage for i915.ko in other areas.
Totally unrelated to dev->struct_mutex, but thoughts? Well for
dev->struct_mutex we could at least decide on one true way to nest
resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
much that would help.
I don't think that would help. As far as I can see we only have two choices:
1. Either have a big patch which fixes all DMA-buf implementations to
allow the reservation lock to be held during map/unmap (unrealistic).
2. Add a flag to at least in the mid term tell the DMA-buf helper
functions what to do. E.g. create the mapping without the reservation
lock held.
How about moving the SGL caching from the DRM layer into the DMA-buf
layer and add a flag if the exporter wants/needs this caching?
Then only the implementations which can deal with dynamic invalidation
disable SGL caching and with it enable creating the sgl with the
reservation object locked.
This way we can kill two birds with one stone by both avoiding the SGL
caching in the DRM layer as well as having a sane handling for the locking.
Thoughts?
Christian.
-Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 20/20] drm/i915/icl: Configure DSI transcoders
This patch programs DSI operation mode, pixel format,
BGR info, link calibration etc for the DSI transcoder.
This patch also extract BGR info of the DSI panel from
VBT and save it inside struct intel_dsi which used for
configuring DSI transcoder.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.h | 3 ++
drivers/gpu/drm/i915/intel_dsi_new.c | 87 +++-
drivers/gpu/drm/i915/intel_dsi_vbt.c | 1 +
3 files changed, 89 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 16964c2..fdde724 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -81,6 +81,9 @@ struct intel_dsi {
u16 dcs_backlight_ports;
u16 dcs_cabc_ports;
+ /* RGB or BGR */
+ unsigned int bgr_enabled;
+
u8 pixel_overlap;
u32 port_bits;
u32 bw_timer;
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 97b9b1e..9b4743e 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -27,8 +27,7 @@
#include "intel_dsi.h"
-static enum transcoder __attribute__((unused)) dsi_port_to_transcoder(
- enum port port)
+static enum transcoder dsi_port_to_transcoder(enum port port)
{
if (port == PORT_A)
return TRANSCODER_DSI_0;
@@ -334,6 +333,87 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_configure_transcoder(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ u32 tmp;
+ enum port port;
+ enum transcoder dsi_trans;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ dsi_trans = dsi_port_to_transcoder(port);
+ tmp = I915_READ(DSI_TRANS_FUNC_CONF(dsi_trans));
+
+ if (intel_dsi->eotp_pkt == 0)
+ tmp |= EOTP_DISABLED;
+ else
+ tmp &= ~EOTP_DISABLED;
+
+ /* enable link calibration if freq > 1.5Gbps */
+ if (intel_dsi->bitrate_khz >= (1500 * 1000)) {
+ tmp &= ~LINK_CALIBRATION_MASK;
+ tmp |= LINK_CALIBRATION(
+ CALIBRATION_ENABLED_INITIAL_ONLY);
+ }
+
+ /* configure continuous clock */
+ tmp &= ~CONTINUOUS_CLK_MASK;
+ if (intel_dsi->clock_stop)
+ tmp |= CONTINUOUS_CLK(CLK_ENTER_LP_AFTER_DATA);
+ else
+ tmp |= CONTINUOUS_CLK(CLK_HS_CONTINUOUS);
+
+ /* configure buffer threshold limit to minimum */
+ tmp &= ~PIX_BUF_THRESHOLD_MASK;
+ tmp |= PIX_BUF_THRESHOLD(PIX_BUF_THRESHOLD_1_4);
+
+ /* set virtual channel to '0' */
+ tmp &= ~PIX_VIRT_CHAN_MASK;
+ tmp |= PIX_VIRT_CHAN(0x0);
+
+ /* program BGR transmission */
+ if (intel_dsi->bgr_enabled)
+ tmp |= BGR_TRANSMISSION;
+
+ /* select pixel format */
+ tmp &= ~PIX_FMT_MASK;
+
+ switch (intel_dsi->pixel_format) {
+ case MIPI_DSI_FMT_RGB888:
+ tmp |= PIX_FMT(PIX_FMT_RGB888);
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ tmp |= PIX_FMT(PIX_FMT_RGB666_LOOSE);
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ tmp |= PIX_FMT(PIX_FMT_RGB666_PACKED);
+ break;
+ case MIPI_DSI_FMT_RGB565:
+ tmp |= PIX_FMT(PIX_FMT_RGB565);
+ break;
+ default:
+ DRM_ERROR("DSI pixel format unsupported\n");
+ }
+
+ /* program DSI operation mode */
+ if (intel_dsi->operation_mode == INTEL_DSI_VIDEO_MODE) {
+ tmp &= ~OP_MODE_MASK;
+ if (intel_dsi->video_mode_format ==
+ VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE) {
+ tmp |= OP_MODE(VIDEO_MODE_SYNC_PULSE);
+ } else if (intel_dsi->video_mode_format ==
+ VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS) {
+ tmp |= OP_MODE(VIDEO_MODE_SYNC_EVENT);
+ } else {
+ DRM_ERROR("DSI Video Mode unsupported\n");
+ }
+ }
+
+ I915_WRITE(DSI_TRANS_FUNC_CONF(dsi_trans), tmp);
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
[Intel-gfx] [PATCH v2 17/20] drm/i915/icl: Get DSI transcoder for a given port
This patch adds a helper function to retrieve DSI
transcoder for a given DSI port using newly defined
enum names for DSI transcoders.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_display.h | 6 --
drivers/gpu/drm/i915/intel_dsi_new.c | 9 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index a77dd29..8104c410 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -43,8 +43,10 @@ enum transcoder {
TRANSCODER_B,
TRANSCODER_C,
TRANSCODER_EDP,
- TRANSCODER_DSI_A,
- TRANSCODER_DSI_C,
+ TRANSCODER_DSI_0,
+ TRANSCODER_DSI_1,
+ TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
+ TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
I915_MAX_TRANSCODERS
};
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 54077f8..97b9b1e 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -27,6 +27,15 @@
#include "intel_dsi.h"
+static enum transcoder __attribute__((unused)) dsi_port_to_transcoder(
+ enum port port)
+{
+ if (port == PORT_A)
+ return TRANSCODER_DSI_0;
+ else
+ return TRANSCODER_DSI_1;
+}
+
static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 16/20] drm/i915/icl: Program TA_TIMING_PARAM registers
This patch programs D-PHY timing parameters for the
bus turn around flow(in escape clocks) only if dsi link
frequency <=800 MHz using DPHY_TA_TIMING_PARAM and its
identical register DSI_TA_TIMING_PARAM (inside DSI
Controller within the Display Core).
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_new.c | 21 +
drivers/gpu/drm/i915/intel_dsi_vbt.c | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 12a8154..16964c2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -101,6 +101,7 @@ struct intel_dsi {
u16 init_count;
u32 pclk;
+ u32 bitrate_khz;
u16 burst_mode_ratio;
/* all delays in ms */
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index ffc17d1..54077f8 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -302,6 +302,27 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
I915_WRITE(DSI_DATA_TIMING_PARAM(port),
intel_dsi->dphy_data_lane_reg);
}
+
+ /*
+* If DSI link operating at or below an 800 MHz,
+* TA_SURE should be override and programmed to
+* a value '0' inside TA_PARAM_REGISTERS otherwise
+* leave all fields at HW default values.
+*/
+ if (intel_dsi->bitrate_khz <= KHz(800)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(DPHY_TA_TIMING_PARAM(port));
+ tmp &= ~TA_SURE_TIME_MASK;
+ tmp |= (TA_SURE_OVERRIDE | TA_SURE_TIME(0));
+ I915_WRITE(DPHY_TA_TIMING_PARAM(port), tmp);
+
+ /* shadow register inside display core */
+ tmp = I915_READ(DSI_TA_TIMING_PARAM(port));
+ tmp &= ~TA_SURE_TIME_MASK;
+ tmp |= (TA_SURE_OVERRIDE | TA_SURE_TIME(0));
+ I915_WRITE(DSI_TA_TIMING_PARAM(port), tmp);
+ }
+ }
}
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 5cc3dd0..a3d71fb 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -589,6 +589,7 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
intel_dsi->pclk = pclk;
bitrate = (pclk * bpp) / intel_dsi->lane_count;
+ intel_dsi->bitrate_khz = bitrate;
switch (intel_dsi->escape_clk_div) {
case 0:
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 18/20] drm/i915/icl: Add macros for MMIO of DSI transcoder registers
This patch adds _MMIO_DSI and _DSI_TRANS macros for accessing
DSI transcoder registers.
Credits-to: Jani N
Cc: Jani Nikula
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2d9ffae..0171b09 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9559,6 +9559,11 @@ enum skl_power_gate {
#define _MIPI_PORT(port, a, c) (((port) == PORT_A) ? a : c)/* ports A and
C only */
#define _MMIO_MIPI(port, a, c) _MMIO(_MIPI_PORT(port, a, c))
+/* gen11 DSI */
+#define _DSI_TRANS(tc, dsi0, dsi1) (((tc) == TRANSCODER_DSI_0) ? \
+(dsi0) : (dsi1))
+#define _MMIO_DSI(tc, dsi0, dsi1) _MMIO(_DSI_TRANS(tc, dsi0, dsi1))
+
#define MIPIO_TXESC_CLK_DIV1 _MMIO(0x160004)
#define GLK_TX_ESC_CLK_DIV1_MASK 0x3FF
#define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/20] drm/i915/icl: Enable DDI Buffer
This patch enables DDI buffer by writing to DDI_BUF_CTL
register and wait for DDI status to be *not idle* for a
port.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_new.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 45420f2..0f481af 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -251,6 +251,25 @@ static void gen11_dsi_voltage_swing_program_seq(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_enable_ddi_buffer(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ u32 tmp;
+ enum port port;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(DDI_BUF_CTL(port));
+ tmp |= DDI_BUF_CTL_ENABLE;
+ I915_WRITE(DDI_BUF_CTL(port), tmp);
+
+ if (wait_for_us(!(I915_READ(DDI_BUF_CTL(port)) &
+ DDI_BUF_IS_IDLE),
+ 500))
+ DRM_ERROR("DDI port:%c buffer idle\n", port_name(port));
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
@@ -261,6 +280,9 @@ static void gen11_dsi_enable_port_and_phy(struct
intel_encoder *encoder)
/* step 4c: configure voltage swing and skew */
gen11_dsi_voltage_swing_program_seq(encoder);
+
+ /* step 4d: enable DDI buffer */
+ gen11_dsi_enable_ddi_buffer(encoder);
}
static void __attribute__((unused))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 03/20] drm/i915/icl: Define DSI mode ctl register
This patch defines DSI IO mode control register and it's bits
used while enabling IO power for DSI.
Signed-off-by: Madhav Chauhan
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 414579f..dfd603c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9672,6 +9672,14 @@ enum skl_power_gate {
#define _BXT_MIPIC_PORT_CTRL 0x6B8C0
#define BXT_MIPI_PORT_CTRL(tc) _MMIO_MIPI(tc, _BXT_MIPIA_PORT_CTRL,
_BXT_MIPIC_PORT_CTRL)
+/* ICL DSI MODE control */
+#define _ICL_DSI_IO_MODECTL_0 0x6B094
+#define _ICL_DSI_IO_MODECTL_1 0x6B894
+#define ICL_DSI_IO_MODECTL(port) _MMIO_PORT(port,\
+ _ICL_DSI_IO_MODECTL_0, \
+ _ICL_DSI_IO_MODECTL_1)
+#define COMBO_PHY_MODE_DSI(1 << 0)
+
#define BXT_P_DSI_REGULATOR_CFG_MMIO(0x160020)
#define STAP_SELECT (1 << 0)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/20] ICELAKE DSI DRIVER
From ICELAKE platform onwards, new MIPI DSI IP controller is integrated to GPU/Display Engine and same could be extended for future Intel platforms as well. DSI IP controller supports MIPI DSI 1.3 and DPHY 1.2 specification. So, a new DSI driver has been added inside I915. Given below patches are the part of new DSI driver which implements BSPEC sequence till transcoder configuration. Rest of the patches (~45) will be published to GITHUB and will share the GITHUB link so that complete implementation can be looked at by reviewers. v2: Addressed review comments from Jani N for Patches 1-6 and rebase for some other few patches. Madhav Chauhan (20): drm/i915/icl: Define register for DSI PLL drm/i915/icl: Program DSI Escape clock Divider drm/i915/icl: Define DSI mode ctl register drm/i915/icl: Enable DSI IO power drm/i915/icl: Define PORT_CL_DW_10 register drm/i915/icl: Power down unused DSI lanes drm/i915/icl: Define AUX lane registers for Port A/B drm/i915/icl: Configure lane sequencing of combo phy transmitter drm/i915/icl: DSI vswing programming sequence drm/i915/icl: Enable DDI Buffer drm/i915/icl: Define T_INIT_MASTER registers drm/i915/icl: Program T_INIT_MASTER registers drm/i915/icl: Define data/clock lanes dphy timing registers drm/i915/icl: Program DSI clock and data lane timing params drm/i915/icl: Define TA_TIMING_PARAM registers drm/i915/icl: Program TA_TIMING_PARAM registers drm/i915/icl: Get DSI transcoder for a given port drm/i915/icl: Add macros for MMIO of DSI transcoder registers drm/i915/icl: Define TRANS_DSI_FUNC_CONF register drm/i915/icl: Configure DSI transcoders drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_reg.h | 178 ++ drivers/gpu/drm/i915/intel_display.h | 6 +- drivers/gpu/drm/i915/intel_dsi.h | 7 + drivers/gpu/drm/i915/intel_dsi_new.c | 451 +++ drivers/gpu/drm/i915/intel_dsi_vbt.c | 202 +++- 6 files changed, 787 insertions(+), 58 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dsi_new.c -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 14/20] drm/i915/icl: Program DSI clock and data lane timing params
This patch programs D-PHY timing parameters for the
clock and data lane (in escape clocks) of DSI
controller (DSI port 0 and 1).
These programmed timings would be used by DSI Controller
to calculate link transition latencies of the data and
clock lanes.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.h | 3 +
drivers/gpu/drm/i915/intel_dsi_new.c | 18
drivers/gpu/drm/i915/intel_dsi_vbt.c | 200 +--
3 files changed, 165 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 7afeb95..12a8154 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -85,6 +85,9 @@ struct intel_dsi {
u32 port_bits;
u32 bw_timer;
u32 dphy_reg;
+
+ /* data lanes dphy timing */
+ u32 dphy_data_lane_reg;
u32 video_frmt_cfg_bits;
u16 lp_byte_clk;
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index db65633..ffc17d1 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -284,6 +284,24 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
tmp |= intel_dsi->init_count;
I915_WRITE(ICL_DSI_T_INIT_MASTER(port), tmp);
}
+
+ /* Program DPHY clock lanes timings */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ I915_WRITE(DPHY_CLK_TIMING_PARAM(port), intel_dsi->dphy_reg);
+
+ /* shadow register inside display core */
+ I915_WRITE(DSI_CLK_TIMING_PARAM(port), intel_dsi->dphy_reg);
+ }
+
+ /* Program DPHY data lanes timings */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ I915_WRITE(DPHY_DATA_TIMING_PARAM(port),
+ intel_dsi->dphy_data_lane_reg);
+
+ /* shadow register inside display core */
+ I915_WRITE(DSI_DATA_TIMING_PARAM(port),
+ intel_dsi->dphy_data_lane_reg);
+ }
}
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 4d6ffa7..5cc3dd0 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -509,7 +509,9 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
u32 bpp;
u32 tlpx_ns, extra_byte_count, bitrate, tlpx_ui;
u32 ui_num, ui_den;
- u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt;
+ u32 prepare_cnt, exit_zero_cnt, clk_zero_cnt, trail_cnt, hs_zero_cnt;
+ u32 tclk_pre_cnt, tclk_post_cnt;
+ u32 tclk_pre_ns, tclk_post_ns;
u32 ths_prepare_ns, tclk_trail_ns;
u32 tclk_prepare_clkzero, ths_prepare_hszero;
u32 lp_to_hs_switch, hs_to_lp_switch;
@@ -624,76 +626,157 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16
panel_id)
tclk_prepare_clkzero = mipi_config->tclk_prepare_clkzero;
ths_prepare_hszero = mipi_config->ths_prepare_hszero;
-
+ tclk_trail_ns = max(mipi_config->tclk_trail, mipi_config->ths_trail);
+ ths_prepare_ns = max(mipi_config->ths_prepare,
+ mipi_config->tclk_prepare);
/*
* B060
* LP byte clock = TLPX/ (8UI)
*/
intel_dsi->lp_byte_clk = DIV_ROUND_UP(tlpx_ns * ui_den, 8 * ui_num);
- /* DDR clock period = 2 * UI
-* UI(sec) = 1/(bitrate * 10^3) (bitrate is in KHZ)
-* UI(nsec) = 10^6 / bitrate
-* DDR clock period (nsec) = 2 * UI = (2 * 10^6)/ bitrate
-* DDR clock count = ns_value / DDR clock period
-*
+ /*
* For GEMINILAKE dphy_param_reg will be programmed in terms of
* HS byte clock count for other platform in HS ddr clock count
*/
mul = IS_GEMINILAKE(dev_priv) ? 8 : 2;
- ths_prepare_ns = max(mipi_config->ths_prepare,
-mipi_config->tclk_prepare);
- /* prepare count */
- prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * ui_den, ui_num * mul);
+ if (IS_ICELAKE(dev_priv)) {
+ /*
+* prepare cnt in escape clocks
+* this field represents a hexadecimal value with a precision
+* of 1.2 – i.e. the most significant bit is the integer
+* and the least significant 2 bits are fraction bits.
+* so, the field can represent a range of 0.25 to 1.75
+*/
+ prepare_cnt = DIV_ROUND_UP(ths_prepare_ns * 4, tlpx_ns);
+
+ /* clk zero count in escape clocks */
+ clk_zero_cnt = DIV_ROUND_UP(
+ (tclk_prepare_clkzero - ths_prepare_ns),
+ tlpx_ns);
+
+ /* trail cnt in escape clocks*/
+ trail_cnt
[Intel-gfx] [PATCH v2 11/20] drm/i915/icl: Define T_INIT_MASTER registers
This patch defines DSI_T_INIT_MASTER register for DSI ports
0/1 which will be used in dphy programming.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d3ce1a9..d6acd42 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10052,6 +10052,12 @@ enum skl_power_gate {
#define PREPARE_COUNT_SHIFT 0
#define PREPARE_COUNT_MASK(0x3f << 0)
+#define _ICL_DSI_T_INIT_MASTER_0 0x6b088
+#define _ICL_DSI_T_INIT_MASTER_1 0x6b888
+#define ICL_DSI_T_INIT_MASTER(port)_MMIO_PORT(port,\
+ _ICL_DSI_T_INIT_MASTER_0,\
+ _ICL_DSI_T_INIT_MASTER_1)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 19/20] drm/i915/icl: Define TRANS_DSI_FUNC_CONF register
This patch defines transcoder function configuration
registers and its bitfields for both DSI ports.
Used while programming/enabling DSI transcoder.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 47 +
1 file changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0171b09..b44a9a8d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10117,6 +10117,53 @@ enum skl_power_gate {
#define TA_SURE_TIME(x) (x << 16)
#define TA_SURE_TIME_MASK (0x1f << 16)
+/* DSI transcoder configuration */
+#define _DSI_TRANS_FUNC_CONF_0 0x6b030
+#define _DSI_TRANS_FUNC_CONF_1 0x6b830
+#define DSI_TRANS_FUNC_CONF(tc)_MMIO_DSI(tc, \
+ _DSI_TRANS_FUNC_CONF_0,\
+ _DSI_TRANS_FUNC_CONF_1)
+#define OP_MODE(x)(x << 28)
+#define OP_MODE_MASK (0x3 << 28)
+#define CMD_MODE_NO_GATE 0x0
+#define CMD_MODE_TE_GATE 0x1
+#define VIDEO_MODE_SYNC_EVENT 0x2
+#define VIDEO_MODE_SYNC_PULSE 0x3
+#define LINK_READY(1 << 20)
+#define PIX_FMT(x)(x << 16)
+#define PIX_FMT_MASK (0x3 << 16)
+#define PIX_FMT_RGB5650x0
+#define PIX_FMT_RGB666_PACKED 0x1
+#define PIX_FMT_RGB666_LOOSE 0x2
+#define PIX_FMT_RGB8880x3
+#define PIX_FMT_RGB101010 0x4
+#define PIX_FMT_RGB121212 0x5
+#define PIX_FMT_COMPRESSED0x6
+#define BGR_TRANSMISSION (1 << 15)
+#define PIX_VIRT_CHAN(x) (x << 12)
+#define PIX_VIRT_CHAN_MASK(0x3 << 12)
+#define PIX_BUF_THRESHOLD(x) ((x & 0x3) << 10)
+#define PIX_BUF_THRESHOLD_MASK(0x3 << 10)
+#define PIX_BUF_THRESHOLD_1_4 0x0
+#define PIX_BUF_THRESHOLD_1_2 0x1
+#define PIX_BUF_THRESHOLD_3_4 0x2
+#define PIX_BUF_THRESHOLD_FULL0x3
+#define CONTINUOUS_CLK(x) (x << 8)
+#define CONTINUOUS_CLK_MASK (0x3 << 8)
+#define CLK_ENTER_LP_AFTER_DATA 0x0
+#define CLK_HS_OR_LP 0x2
+#define CLK_HS_CONTINUOUS 0x3
+#define LINK_CALIBRATION(x) (x << 4)
+#define LINK_CALIBRATION_MASK (0x3 << 4)
+#define CALIBRATION_DISABLED 0x0
+#define CALIBRATION_ENABLED_INITIAL_ONLY 0x2
+#define CALIBRATION_ENABLED_INITIAL_PERIODIC 0x3
+#define S3D_ORIENTATION(x)(x << 1)
+#define S3D_ORIENTATION_MASK (0x1 << 1)
+#define S3D_ORIENTATION_PORTRAIT 0x0
+#define S3D_ORIENTATION_LANDSCAPE 0x1
+#define EOTP_DISABLED (1 << 0)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/20] drm/i915/icl: Program T_INIT_MASTER registers
This patch programs the time (in escape clocks) to drive
the link in the initialization (i.e. LP-11) state.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_new.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 0f481af..db65633 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -270,6 +270,22 @@ static void gen11_dsi_enable_ddi_buffer(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_setup_dphy_timings(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ u32 tmp;
+ enum port port;
+
+ /* Program T-INIT master registers */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_DSI_T_INIT_MASTER(port));
+ tmp &= ~MASTER_INIT_TIMER_MASK;
+ tmp |= intel_dsi->init_count;
+ I915_WRITE(ICL_DSI_T_INIT_MASTER(port), tmp);
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
@@ -283,6 +299,9 @@ static void gen11_dsi_enable_port_and_phy(struct
intel_encoder *encoder)
/* step 4d: enable DDI buffer */
gen11_dsi_enable_ddi_buffer(encoder);
+
+ /* step 4e: setup D-PHY timings */
+ gen11_dsi_setup_dphy_timings(encoder);
}
static void __attribute__((unused))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/20] drm/i915/icl: Power down unused DSI lanes
To save power, unused lanes should be powered
down using the bitfield of PORT_CL_DW10.
v2: Review comments from Jani N
- Put default label next to case 4
- Include the shifts in the macros
Signed-off-by: Madhav Chauhan
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_new.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 64f97c7..9262e3f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -74,6 +74,43 @@ static void gen11_dsi_enable_io_power(struct intel_encoder
*encoder)
}
}
+static void gen11_dsi_power_up_lanes(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 tmp;
+ u32 lane_mask;
+
+ switch (intel_dsi->lane_count) {
+ case 1:
+ lane_mask = PWR_DOWN_LN_3_1_0;
+ break;
+ case 2:
+ lane_mask = PWR_DOWN_LN_3_1;
+ break;
+ case 3:
+ lane_mask = PWR_DOWN_LN_3;
+ break;
+ case 4:
+ default:
+ lane_mask = PWR_UP_ALL_LANES;
+ break;
+ }
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_CL_DW10(port));
+ tmp &= ~PWR_DOWN_LN_MASK;
+ I915_WRITE(ICL_PORT_CL_DW10(port), tmp | lane_mask);
+ }
+}
+
+static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
+{
+ /* step 4a: power up all lanes of the DDI used by DSI */
+ gen11_dsi_power_up_lanes(encoder);
+}
+
static void __attribute__((unused))
gen11_dsi_pre_enable(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config,
@@ -84,4 +121,7 @@ gen11_dsi_pre_enable(struct intel_encoder *encoder,
/* step3: enable DSI PLL */
gen11_dsi_program_esc_clk_div(encoder);
+
+ /* step4: enable DSI port and DPHY */
+ gen11_dsi_enable_port_and_phy(encoder);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 09/20] drm/i915/icl: DSI vswing programming sequence
This patch setup voltage swing before enabling
combo PHY DDI (shared with DSI).
Note that DSI voltage swing programming is for
high speed data buffers. HW automatically handles
the voltage swing for the low power data buffers.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_new.c | 114 +++
1 file changed, 114 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 3192450..45420f2 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -27,6 +27,65 @@
#include "intel_dsi.h"
+static void dsi_program_swing_and_deemphasis(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 tmp;
+ int lane;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+
+ /* Bspec: set scaling mode to 0x6 */
+ tmp = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ tmp |= SCALING_MODE_SEL(6);
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_AUX(port));
+ tmp |= SCALING_MODE_SEL(6);
+ I915_WRITE(ICL_PORT_TX_DW5_AUX(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ tmp |= TAP2_DISABLE | TAP3_DISABLE;
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_AUX(port));
+ tmp |= TAP2_DISABLE | TAP3_DISABLE;
+ I915_WRITE(ICL_PORT_TX_DW5_AUX(port), tmp);
+
+ /*
+* swing and scaling values are taken from DSI
+* table under vswing programming sequence for
+* combo phy ddi in BSPEC.
+* program swing values
+*/
+ tmp = I915_READ(ICL_PORT_TX_DW2_LN0(port));
+ tmp |= SWING_SEL_UPPER(0x2);
+ tmp |= SWING_SEL_LOWER(0x2);
+ tmp |= RCOMP_SCALAR(0x98);
+ I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW2_AUX(port));
+ tmp |= SWING_SEL_UPPER(0x2);
+ tmp |= SWING_SEL_LOWER(0x2);
+ tmp |= RCOMP_SCALAR(0x98);
+ I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp);
+
+ /* program scaling values */
+ tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port));
+ tmp |= POST_CURSOR_1(0x0);
+ tmp |= POST_CURSOR_2(0x0);
+ tmp |= CURSOR_COEFF(0x18);
+ I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
+
+ for (lane = 0; lane <= 3; lane++) {
+ /* Bspec: must not use GRP register for write */
+ tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
+ tmp |= POST_CURSOR_1(0x0);
+ tmp |= POST_CURSOR_2(0x0);
+ tmp |= CURSOR_COEFF(0x18);
+ I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
+ }
+ }
+}
+
static void gen11_dsi_program_esc_clk_div(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -140,6 +199,58 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_voltage_swing_program_seq(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ u32 tmp;
+ enum port port;
+
+ /* Step C.1:clear common keeper enable bit */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_PCS_DW1_LN0(port));
+ tmp &= ~COMMON_KEEPER_EN;
+ I915_WRITE(ICL_PORT_PCS_DW1_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_PCS_DW1_AUX(port));
+ tmp &= ~COMMON_KEEPER_EN;
+ I915_WRITE(ICL_PORT_PCS_DW1_AUX(port), tmp);
+ }
+
+ /*
+* Step C.3: Set SUS Clock Config bitfield to 11b
+* Note: Step C.2 (loadgen select program) is done
+* as part of lane phy sequence configuration
+*/
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_CL_DW5(port));
+ tmp |= SUS_CLOCK_CONFIG;
+ I915_WRITE(ICL_PORT_CL_DW5(port), tmp);
+ }
+
+ /* Step C.4: Clear training enable to change swing values */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ tmp &= ~TX_TRAINING_EN;
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW5_AUX(port));
+ tmp &= ~TX_TRAINING_EN;
+
[Intel-gfx] [PATCH v2 01/20] drm/i915/icl: Define register for DSI PLL
This patch adds the new registers and corresponding bit definitions
which will be used for programming/enable DSI PLL.
v2: Review comments from Jani N
- Fix spaces while defining ICL_ESC_CLK_DIV_MASK
- Define shift and mask for bitfields.
Signed-off-by: Madhav Chauhan
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_reg.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c30cfcd..d414940 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9522,6 +9522,21 @@ enum skl_power_gate {
#define MIPIO_TXESC_CLK_DIV2 _MMIO(0x160008)
#define GLK_TX_ESC_CLK_DIV2_MASK 0x3FF
+#define _ICL_DSI_ESC_CLK_DIV0 0x6b090
+#define _ICL_DSI_ESC_CLK_DIV1 0x6b890
+#define ICL_DSI_ESC_CLK_DIV(port) _MMIO_PORT((port), \
+ _ICL_DSI_ESC_CLK_DIV0, \
+ _ICL_DSI_ESC_CLK_DIV1)
+#define _ICL_DPHY_ESC_CLK_DIV0 0x162190
+#define _ICL_DPHY_ESC_CLK_DIV1 0x6C190
+#define ICL_DPHY_ESC_CLK_DIV(port) _MMIO_PORT((port), \
+ _ICL_DPHY_ESC_CLK_DIV0, \
+ _ICL_DPHY_ESC_CLK_DIV1)
+#define ICL_BYTE_CLK_PER_ESC_CLK_MASK (0x1f << 16)
+#define ICL_BYTE_CLK_PER_ESC_CLK_SHIFT16
+#define ICL_ESC_CLK_DIV_MASK 0x1ff
+#define ICL_ESC_CLK_DIV_SHIFT 0
+
/* Gen4+ Timestamp and Pipe Frame time stamp registers */
#define GEN4_TIMESTAMP _MMIO(0x2358)
#define ILK_TIMESTAMP_HI _MMIO(0x70070)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/20] drm/i915/icl: Configure lane sequencing of combo phy transmitter
This patch set the loadgen select and latency optimization for
aux and transmit lanes of combo phy transmitters. It will be
used for MIPI DSI HS operations.
v2: Rebase
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_new.c | 38
1 file changed, 38 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index 9262e3f..3192450 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -105,10 +105,48 @@ static void gen11_dsi_power_up_lanes(struct intel_encoder
*encoder)
}
}
+static void gen11_dsi_config_phy_lanes_sequence(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 tmp;
+ int lane;
+
+ /* Step 4b(i) set loadgen select for transmit and aux lanes */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_TX_DW4_AUX(port));
+ tmp &= ~LOADGEN_SELECT;
+ I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
+ for (lane = 0; lane <= 3; lane++) {
+ tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
+ tmp &= ~LOADGEN_SELECT;
+ if (lane != 2)
+ tmp |= LOADGEN_SELECT;
+ I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
+ }
+ }
+
+ /* Step 4b(ii) set latency optimization for transmit and aux lanes */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_PORT_TX_DW2_AUX(port));
+ tmp &= ~FRC_LATENCY_OPTIM_MASK;
+ tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
+ I915_WRITE(ICL_PORT_TX_DW2_AUX(port), tmp);
+ tmp = I915_READ(ICL_PORT_TX_DW2_LN0(port));
+ tmp &= ~FRC_LATENCY_OPTIM_MASK;
+ tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
+ I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
+ }
+}
+
static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder)
{
/* step 4a: power up all lanes of the DDI used by DSI */
gen11_dsi_power_up_lanes(encoder);
+
+ /* step 4b: configure lane sequencing of the Combo-PHY transmitters */
+ gen11_dsi_config_phy_lanes_sequence(encoder);
}
static void __attribute__((unused))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/20] drm/i915/icl: Define PORT_CL_DW_10 register
This register used to power down individual lanes for
DDI/DSI ports. Bitfields to power up/down various
combinations of lanes are also added in this patch.
v2: Review comments from Jani N
- Use override instead of "override" for bitfields
- Define mask for override bitfield
- Define PWR_DOWN_LN* macros shifted in place
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dfd603c..3fa8f02 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1704,6 +1704,26 @@ enum i915_power_well_id {
#define ICL_PORT_CL_DW5(port) _MMIO_PORT(port, _ICL_PORT_CL_DW5_A, \
_ICL_PORT_CL_DW5_B)
+#define _CNL_PORT_CL_DW10_A0x162028
+#define _ICL_PORT_CL_DW10_B0x6c028
+#define ICL_PORT_CL_DW10(port) _MMIO_PORT(port,\
+ _CNL_PORT_CL_DW10_A, \
+ _ICL_PORT_CL_DW10_B)
+#define PG_SEQ_DELAY_OVERRIDE_MASK(3 << 25)
+#define PG_SEQ_DELAY_OVERRIDE_SHIFT 25
+#define PG_SEQ_DELAY_OVERRIDE_ENABLE (1 << 24)
+#define PWR_UP_ALL_LANES (0x0 << 4)
+#define PWR_DOWN_LN_3_2_1 (0xe << 4)
+#define PWR_DOWN_LN_3_2 (0xc << 4)
+#define PWR_DOWN_LN_3 (0x8 << 4)
+#define PWR_DOWN_LN_2_1_0 (0x7 << 4)
+#define PWR_DOWN_LN_1_0 (0x3 << 4)
+#define PWR_DOWN_LN_1 (0x2 << 4)
+#define PWR_DOWN_LN_3_1 (0xa << 4)
+#define PWR_DOWN_LN_3_1_0 (0xb << 4)
+#define PWR_DOWN_LN_MASK (0xf0 << 4)
+#define PWR_DOWN_LN_SHIFT 4
+
#define _PORT_CL1CM_DW9_A 0x162024
#define _PORT_CL1CM_DW9_BC 0x6C024
#define IREF0RC_OFFSET_SHIFT 8
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 15/20] drm/i915/icl: Define TA_TIMING_PARAM registers
This patch defines DSI_TA_TIMING_PARAM and
DPHY_TA_TIMING_PARAM registers used in
dphy programming.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c5d8c1..2d9ffae 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10098,6 +10098,20 @@ enum skl_power_gate {
#define HS_EXIT_OVERRIDE (1 << 7)
#define HS_EXIT_TIME(x) (x << 0)
+#define _DPHY_TA_TIMING_PARAM_00x162188
+#define _DPHY_TA_TIMING_PARAM_10x6c188
+#define DPHY_TA_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DPHY_TA_TIMING_PARAM_0,\
+ _DPHY_TA_TIMING_PARAM_1)
+#define _DSI_TA_TIMING_PARAM_0 0x6b098
+#define _DSI_TA_TIMING_PARAM_1 0x6b898
+#define DSI_TA_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DSI_TA_TIMING_PARAM_0,\
+ _DSI_TA_TIMING_PARAM_1)
+#define TA_SURE_OVERRIDE (1 << 31)
+#define TA_SURE_TIME(x) (x << 16)
+#define TA_SURE_TIME_MASK (0x1f << 16)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/20] drm/i915/icl: Define data/clock lanes dphy timing registers
This patch defines DSI_CLK_TIMING_PARAM, DPHY_CLK_TIMING_PARAM,
DSI_DATA_TIMING_PARAM, DPHY_DATA_TIMING_PARAM register used in
dphy programming.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d6acd42..9c5d8c1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10058,6 +10058,46 @@ enum skl_power_gate {
_ICL_DSI_T_INIT_MASTER_0,\
_ICL_DSI_T_INIT_MASTER_1)
+#define _DPHY_CLK_TIMING_PARAM_0 0x162180
+#define _DPHY_CLK_TIMING_PARAM_1 0x6c180
+#define DPHY_CLK_TIMING_PARAM(port)_MMIO_PORT(port,\
+ _DPHY_CLK_TIMING_PARAM_0,\
+ _DPHY_CLK_TIMING_PARAM_1)
+#define _DSI_CLK_TIMING_PARAM_00x6b080
+#define _DSI_CLK_TIMING_PARAM_10x6b880
+#define DSI_CLK_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DSI_CLK_TIMING_PARAM_0,\
+ _DSI_CLK_TIMING_PARAM_1)
+#define CLK_PREP_OVERRIDE (1 << 31)
+#define CLK_PREP_TIME(x) (x << 28)
+#define CLK_ZERO_OVERRIDE (1 << 27)
+#define CLK_ZERO_TIME(x) (x << 20)
+#define CLK_PRE_OVERRIDE (1 << 19)
+#define CLK_PRE_TIME(x) (x << 16)
+#define CLK_POST_OVERRIDE (1 << 15)
+#define CLK_POST_TIME(x) (x << 8)
+#define CLK_TRAIL_OVERRIDE(1 << 7)
+#define CLK_TRAIL_TIME(x) (x << 0)
+
+#define _DPHY_DATA_TIMING_PARAM_0 0x162184
+#define _DPHY_DATA_TIMING_PARAM_1 0x6c184
+#define DPHY_DATA_TIMING_PARAM(port) _MMIO_PORT(port,\
+ _DPHY_DATA_TIMING_PARAM_0,\
+ _DPHY_DATA_TIMING_PARAM_1)
+#define _DSI_DATA_TIMING_PARAM_0 0x6B084
+#define _DSI_DATA_TIMING_PARAM_1 0x6B884
+#define DSI_DATA_TIMING_PARAM(port)_MMIO_PORT(port,\
+ _DSI_DATA_TIMING_PARAM_0,\
+ _DSI_DATA_TIMING_PARAM_1)
+#define HS_PREP_OVERRIDE (1 << 31)
+#define HS_PREP_TIME(x) (x << 24)
+#define HS_ZERO_OVERRIDE (1 << 23)
+#define HS_ZERO_TIME(x) (x << 16)
+#define HS_TRAIL_OVERRIDE (1 << 15)
+#define HS_TRAIL_TIME(x) (x << 8)
+#define HS_EXIT_OVERRIDE (1 << 7)
+#define HS_EXIT_TIME(x) (x << 0)
+
/* bits 31:0 */
#define _MIPIA_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb084)
#define _MIPIC_DBI_BW_CTRL (dev_priv->mipi_mmio_base + 0xb884)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/20] drm/i915/icl: Define AUX lane registers for Port A/B
This patch defines AUX lane registers for PORT_PCS_DW1,
PORT_TX_DW2, PORT_TX_DW4, PORT_TX_DW5 used during
dsi enabling.
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3fa8f02..d3ce1a9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1780,16 +1780,21 @@ enum i915_power_well_id {
_CNL_PORT_PCS_DW1_LN0_D, \
_CNL_PORT_PCS_DW1_LN0_AE, \
_CNL_PORT_PCS_DW1_LN0_F))
+
#define _ICL_PORT_PCS_DW1_GRP_A0x162604
#define _ICL_PORT_PCS_DW1_GRP_B0x6C604
#define _ICL_PORT_PCS_DW1_LN0_A0x162804
#define _ICL_PORT_PCS_DW1_LN0_B0x6C804
+#define _ICL_PORT_PCS_DW1_AUX_B0x6c304
#define ICL_PORT_PCS_DW1_GRP(port) _MMIO_PORT(port,\
_ICL_PORT_PCS_DW1_GRP_A, \
_ICL_PORT_PCS_DW1_GRP_B)
#define ICL_PORT_PCS_DW1_LN0(port) _MMIO_PORT(port, \
_ICL_PORT_PCS_DW1_LN0_A, \
_ICL_PORT_PCS_DW1_LN0_B)
+#define ICL_PORT_PCS_DW1_AUX(port) _MMIO_PORT(port, \
+ _CNL_PORT_PCS_DW1_GRP_AE, \
+ _ICL_PORT_PCS_DW1_AUX_B)
#define COMMON_KEEPER_EN (1 << 26)
/* CNL Port TX registers */
@@ -1826,16 +1831,23 @@ enum i915_power_well_id {
#define _ICL_PORT_TX_DW2_GRP_B 0x6C688
#define _ICL_PORT_TX_DW2_LN0_A 0x162888
#define _ICL_PORT_TX_DW2_LN0_B 0x6C888
+#define _ICL_PORT_TX_DW2_AUX_A 0x162388
+#define _ICL_PORT_TX_DW2_AUX_B 0x6c388
#define ICL_PORT_TX_DW2_GRP(port) _MMIO_PORT(port, \
_ICL_PORT_TX_DW2_GRP_A, \
_ICL_PORT_TX_DW2_GRP_B)
#define ICL_PORT_TX_DW2_LN0(port) _MMIO_PORT(port, \
_ICL_PORT_TX_DW2_LN0_A, \
_ICL_PORT_TX_DW2_LN0_B)
+#define ICL_PORT_TX_DW2_AUX(port) _MMIO_PORT(port, \
+ _ICL_PORT_TX_DW2_AUX_A, \
+ _ICL_PORT_TX_DW2_AUX_B)
#define SWING_SEL_UPPER(x) (((x) >> 3) << 15)
#define SWING_SEL_UPPER_MASK (1 << 15)
#define SWING_SEL_LOWER(x) (((x) & 0x7) << 11)
#define SWING_SEL_LOWER_MASK (0x7 << 11)
+#define FRC_LATENCY_OPTIM_MASK(0x7 << 8)
+#define FRC_LATENCY_OPTIM_VAL(x) ((x) << 8)
#define RCOMP_SCALAR(x) ((x) << 0)
#define RCOMP_SCALAR_MASK(0xFF << 0)
@@ -1851,6 +1863,8 @@ enum i915_power_well_id {
#define _ICL_PORT_TX_DW4_LN0_A 0x162890
#define _ICL_PORT_TX_DW4_LN1_A 0x162990
#define _ICL_PORT_TX_DW4_LN0_B 0x6C890
+#define _ICL_PORT_TX_DW4_AUX_A 0x162390
+#define _ICL_PORT_TX_DW4_AUX_B 0x6c390
#define ICL_PORT_TX_DW4_GRP(port) _MMIO_PORT(port, \
_ICL_PORT_TX_DW4_GRP_A, \
_ICL_PORT_TX_DW4_GRP_B)
@@ -1859,6 +1873,9 @@ enum i915_power_well_id {
_ICL_PORT_TX_DW4_LN0_B) + \
((ln) * (_ICL_PORT_TX_DW4_LN1_A - \
_ICL_PORT_TX_DW4_LN0_A)))
+#define ICL_PORT_TX_DW4_AUX(port) _MMIO_PORT(port, \
+ _ICL_PORT_TX_DW4_AUX_A, \
+ _ICL_PORT_TX_DW4_AUX_B)
#define LOADGEN_SELECT (1 << 31)
#define POST_CURSOR_1(x) ((x) << 12)
#define POST_CURSOR_1_MASK (0x3F << 12)
@@ -1873,12 +1890,17 @@ enum i915_power_well_id {
#define _ICL_PORT_TX_DW5_GRP_B 0x6C694
#define _ICL_PORT_TX_DW5_LN0_A 0x162894
#define _ICL_PORT_TX_DW5_LN0_B 0x6C894
+#define _ICL_PORT_TX_DW5_AUX_A 0x162394
+#define _ICL_PORT_TX_DW5_AUX_B 0x6c394
#define ICL_PORT_TX_DW5_GRP(port) _MMIO_PORT(port, \
_ICL_PORT_TX_DW5_GRP_A, \
_ICL_PORT_TX_DW5_GRP_B)
#define ICL_PORT_TX_DW5_LN0(port) _MMIO_PORT(port, \
_ICL_PORT_TX_DW5_LN0_A, \
_ICL_PORT_TX_DW5_LN0_B)
+#define ICL_PORT_TX_DW5_AUX(port) _MMIO_PO
[Intel-gfx] [PATCH v2 02/20] drm/i915/icl: Program DSI Escape clock Divider
Escape Clock is used for LP communication across the DSI
Link. To achieve the constant frequency of the escape clock
from the variable DPLL frequency output, a variable divider(M)
is needed. This patch programs the same.
v2: (Jani N) Don't end line with "(".
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dsi_new.c | 64
3 files changed, 66 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_new.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 4c6adae..a5f60c8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -142,6 +142,7 @@ i915-y += dvo_ch7017.o \
intel_dp_mst.o \
intel_dp.o \
intel_dsi.o \
+ intel_dsi_new.o \
intel_dsi_dcs_backlight.o \
intel_dsi_pll.o \
intel_dsi_vbt.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d414940..414579f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9536,6 +9536,7 @@ enum skl_power_gate {
#define ICL_BYTE_CLK_PER_ESC_CLK_SHIFT16
#define ICL_ESC_CLK_DIV_MASK 0x1ff
#define ICL_ESC_CLK_DIV_SHIFT 0
+#define DSI_MAX_ESC_CLK2 /* in KHz */
/* Gen4+ Timestamp and Pipe Frame time stamp registers */
#define GEN4_TIMESTAMP _MMIO(0x2358)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
new file mode 100644
index 000..a890b36
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -0,0 +1,64 @@
+/*
+ * Copyright © 2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Madhav Chauhan
+ * Jani Nikula
+ */
+
+#include "intel_dsi.h"
+
+static void gen11_dsi_program_esc_clk_div(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
+ u32 afe_clk_khz; /* 8X Clock */
+ u32 esc_clk_div_m;
+
+ afe_clk_khz = DIV_ROUND_CLOSEST(intel_dsi->pclk * bpp,
+ intel_dsi->lane_count);
+
+ esc_clk_div_m = DIV_ROUND_UP(afe_clk_khz, DSI_MAX_ESC_CLK);
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ I915_WRITE(ICL_DSI_ESC_CLK_DIV(port),
+ esc_clk_div_m & ICL_ESC_CLK_DIV_MASK);
+ POSTING_READ(ICL_DSI_ESC_CLK_DIV(port));
+ }
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ I915_WRITE(ICL_DPHY_ESC_CLK_DIV(port),
+ esc_clk_div_m & ICL_ESC_CLK_DIV_MASK);
+ POSTING_READ(ICL_DPHY_ESC_CLK_DIV(port));
+ }
+}
+
+static void __attribute__((unused))
+gen11_dsi_pre_enable(struct intel_encoder *encoder,
+ const struct intel_crtc_state *pipe_config,
+ const struct drm_connector_state *conn_state)
+{
+ /* step3: enable DSI PLL */
+ gen11_dsi_program_esc_clk_div(encoder);
+}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/20] drm/i915/icl: Enable DSI IO power
This patch configures mode of operation for DSI
and enable DDI IO power by configuring power well.
v2: Use for_each_dsi_port() for power get (Jani N)
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi_new.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
b/drivers/gpu/drm/i915/intel_dsi_new.c
index a890b36..64f97c7 100644
--- a/drivers/gpu/drm/i915/intel_dsi_new.c
+++ b/drivers/gpu/drm/i915/intel_dsi_new.c
@@ -54,11 +54,34 @@ static void gen11_dsi_program_esc_clk_div(struct
intel_encoder *encoder)
}
}
+static void gen11_dsi_enable_io_power(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ enum port port;
+ u32 tmp;
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_DSI_IO_MODECTL(port));
+ tmp |= COMBO_PHY_MODE_DSI;
+ I915_WRITE(ICL_DSI_IO_MODECTL(port), tmp);
+ }
+
+ for_each_dsi_port(port, intel_dsi->ports) {
+ intel_display_power_get(dev_priv, port == PORT_A ?
+ POWER_DOMAIN_PORT_DDI_A_IO :
+ POWER_DOMAIN_PORT_DDI_B_IO);
+ }
+}
+
static void __attribute__((unused))
gen11_dsi_pre_enable(struct intel_encoder *encoder,
const struct intel_crtc_state *pipe_config,
const struct drm_connector_state *conn_state)
{
+ /* step2: enable IO power */
+ gen11_dsi_enable_io_power(encoder);
+
/* step3: enable DSI PLL */
gen11_dsi_program_esc_clk_div(encoder);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Touch the NMI watchdog inside a GTT pass
On 03/07/2018 12:07, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-07-03 12:00:13) On 03/07/2018 11:25, Chris Wilson wrote: We want to do a complete pass before checking the timeout, but just in case the pass is quite slow, touch the NMI watchdog to prevent a false positive. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index eefcf7b84054..71c0654b4b4d 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -23,6 +23,7 @@ */ #include +#include #include #include "../i915_selftest.h" @@ -686,6 +687,13 @@ static int pot_hole(struct drm_i915_private *i915, i915_vma_unpin(vma); err = i915_vma_unbind(vma); GEM_BUG_ON(err); + + /* + * Do a complete pass before timing out, but just + * in case we are running too slow, ping the NMI + * watchdog. + */ + touch_nmi_watchdog(); } if (igt_timeout(end_time, Why only in pot_hole, is this the slowest test? It's the only test of this style where we don't have the igt_timeout (cond_resched) inside the innermost loop. So.. the obvious question.. :) Why not move igt_timeout to the innermost loop and avoid low-level hackery? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2
On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:
> Am 25.06.2018 um 11:12 schrieb Daniel Vetter:
> > On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:
> > > > First step towards unpinned DMA buf operation.
> > > >
> > > > I've checked the DRM drivers to potential locking of the reservation
> > > > object, but essentially we need to audit all implementations of the
> > > > dma_buf _ops for this to work.
> > > >
> > > > v2: reordered
> > > >
> > > > Signed-off-by: Christian König
> > > Reviewed-by: Daniel Vetter
> > Ok I did review drivers a bit, but apparently not well enough by far. i915
> > CI is unhappy:
> >
> > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html
> >
> > So yeah inserting that lock in there isn't the most trivial thing :-/
> >
> > I kinda assume that other drivers will have similar issues, e.g. omapdrm's
> > use of dev->struct_mutex also very much looks like it'll result in a new
> > locking inversion.
>
> Ah, crap. Already feared that this wouldn't be easy, but yeah that it is as
> bad as this is rather disappointing.
>
> Thanks for the info, going to keep thinking about how to solve those issues.
Side note: We want to make sure that drivers don't get the reservation_obj
locking hierarchy wrong in other places (using dev->struct_mutex is kinda
a pre-existing mis-use that we can't wish away retroactively
unfortunately). One really important thing is that shrinker vs resv_obj
must work with trylocks in the shrinker, so that you can allocate memory
while holding reservation objects.
One neat trick to teach lockdep about this would be to have a dummy
if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
ww_mutex_lock(dma_buf->resv_obj);
fs_reclaim_acquire(GFP_KERNEL);
fs_reclaim_release(GFP_KERNEL);
ww_mutex_unlock(dma_buf->resv_obj);
}
in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
successfully to improve our igt test coverage for i915.ko in other areas.
Totally unrelated to dev->struct_mutex, but thoughts? Well for
dev->struct_mutex we could at least decide on one true way to nest
resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
much that would help.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > > ---
> > > > drivers/dma-buf/dma-buf.c | 9 ++---
> > > > include/linux/dma-buf.h | 4
> > > > 2 files changed, 10 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> > > > index dc94e76e2e2a..49f23b791eb8 100644
> > > > --- a/drivers/dma-buf/dma-buf.c
> > > > +++ b/drivers/dma-buf/dma-buf.c
> > > > @@ -665,7 +665,9 @@ struct sg_table *dma_buf_map_attachment(struct
> > > > dma_buf_attachment *attach,
> > > > if (WARN_ON(!attach || !attach->dmabuf))
> > > > return ERR_PTR(-EINVAL);
> > > > - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> > > > + reservation_object_lock(attach->dmabuf->resv, NULL);
> > > > + sg_table = dma_buf_map_attachment_locked(attach, direction);
> > > > + reservation_object_unlock(attach->dmabuf->resv);
> > > > if (!sg_table)
> > > > sg_table = ERR_PTR(-ENOMEM);
> > > > @@ -715,8 +717,9 @@ void dma_buf_unmap_attachment(struct
> > > > dma_buf_attachment *attach,
> > > > if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
> > > > return;
> > > > - attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> > > > - direction);
> > > > + reservation_object_lock(attach->dmabuf->resv, NULL);
> > > > + dma_buf_unmap_attachment_locked(attach, sg_table, direction);
> > > > + reservation_object_unlock(attach->dmabuf->resv);
> > > > }
> > > > EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> > > > diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> > > > index a25e754ae2f7..024658d1f22e 100644
> > > > --- a/include/linux/dma-buf.h
> > > > +++ b/include/linux/dma-buf.h
> > > > @@ -118,6 +118,8 @@ struct dma_buf_ops {
> > > > * any other kind of sharing that the exporter might wish to
> > > > make
> > > > * available to buffer-users.
> > > > *
> > > > +* This is called with the dmabuf->resv object locked.
> > > > +*
> > > > * Returns:
> > > > *
> > > > * A &sg_table scatter list of or the backing storage of the
> > > > DMA buffer,
> > > > @@ -138,6 +140,8 @@ struct dma_buf_ops {
> > > > * It should also unpin the backing storage if this is the last
> > > > mapping
> > > > * of the DMA buffer, it the exporter supports backing storage
> > > > * migration.
> > > > +*
> > > > +* This is called with the dmabuf->resv object locked.
> > > > */
> > > >
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU
>-Original Message- >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter >Sent: Tuesday, July 3, 2018 5:52 PM >To: Chris Wilson >Cc: Daniel Vetter ; Zhao, Yakui ; >intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on >VGPU > >On Tue, Jul 03, 2018 at 10:05:28AM +0100, Chris Wilson wrote: >> Quoting Daniel Vetter (2018-07-03 09:51:03) >> > On Tue, Jul 03, 2018 at 10:56:17AM +0800, Zhao Yakui wrote: >> > > On VGPU scenario the read/write operation of fence_reg will be >> > > trapped by the GVT-g. And then gvt-g follows the HW spec to write the >fence_reg. >> > > So it is unnecessary to read/write fence reg several times. This >> > > will help to reduce the unnecessary trap of fence_reg mmio operation. >> > > >> > > V1->V2: Fix one typo error of parameter when calling >> > > V1->intel_vgpu_active >> > > >> > > Signed-off-by: Zhao Yakui >> > >> > Ok this makes more sense. Except you need to put the 64bit entirely >> > into the vpgu block, with a comment explaining why this is safe >> > (since the vpgu will take care of updating fences correctly). >> >> Except, who cares? Are fence registers being rewritten that frequently >> that special casing vgpu is worth the hassle. Part of that is that you >> need to leave a hint behind in the code that (a) explains why it is >> safe after having the "here be dragons" and (b) why we care. >> >> On a more pragmatic level if fencing doesn't plateau out to steady >> state, that is a worrying amount of contention -- the actual fence >> write itself would be the least of my worries. > >I can easily imagine that with the few per-client fences vgpu hands out >rewrites are much more common. But yeah some real data would be good. >And more reasons to get mesa off of the gtt mmaps. Hi, Daniel/Chris Thanks for your comments. The fence reg is used to assure the access of Tiled surface through aperature window. When fence is needed, the driver helps to find one available fence reg and then configure it. After it is not used, the fence will be turned off and then be allocated for next usage. It doesn't rely on the state of fence reg. In such case we don't need to worry about the unsteady state. For the VGPU operation: The op of fence reg is trapped. Then the gvt-g will follow the trapped value to program the fence_reg. (It will turn off and then write the expected value for any trapped write op of fence reg). The trapped op in GVT-g is safe. Based on the current logic, it needs the five traps when one fence reg is configured under VGPU mode.(Three writes, two reads). If it is programmed in one 64-bit op under VGPU mode, only one trap is needed. And the GVT-g still can configure the expected fence_value. As the trap is quite heavy for VGPU, the trap time can be saved. I will put some description in the code and commit log in next version. >-Daniel >-- >Daniel Vetter >Software Engineer, Intel Corporation >http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/vmwgfx: Use drm_plane_mask() & co.
On Mon, Jul 02, 2018 at 10:00:35AM -0700, Sinclair Yeh wrote:
> Reviewed-by: Sinclair Yeh
>
> I assume you'll upstream this as part of your series?
Already pushed actually. In my haste I failed to realize I was
still missing an ack/rb for vmwgfx. Sorry about that.
>
> On Tue, Jun 26, 2018 at 10:47:16PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Use drm_{plane,connector}_mask() where appropriate.
> >
> > Cc: VMware Graphics
> > Cc: Sinclair Yeh
> > Cc: Thomas Hellstrom
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > index ef96ba7432ad..17e01423ead1 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > @@ -535,9 +535,9 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
> > struct drm_crtc_state *new_state)
> > {
> > struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
> > - int connector_mask = 1 << drm_connector_index(&du->connector);
> > + int connector_mask = drm_connector_mask(&du->connector);
> > bool has_primary = new_state->plane_mask &
> > - BIT(drm_plane_index(crtc->primary));
> > + drm_plane_mask(crtc->primary);
> >
> > /* We always want to have an active plane with an active CRTC */
> > if (has_primary != new_state->enable)
> > --
> > 2.16.4
> >
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
