[Intel-gfx] ✓ Fi.CI.BAT: success for Remaining RKL patches (rev4)
== Series Details ==
Series: Remaining RKL patches (rev4)
URL : https://patchwork.freedesktop.org/series/77971/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8618 -> Patchwork_17933
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_17933 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17933, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17933:
### IGT changes ###
Warnings
* igt@i915_selftest@live@gt_pm:
- fi-tgl-u2: [DMESG-FAIL][1] ([i915#1754]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-tgl-u2/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_17933 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar
issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][5] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) ->
[DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17933/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1754]: https://gitlab.freedesktop.org/drm/intel/issues/1754
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 43)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8618 -> Patchwork_17933
CI-20190529: 20190529
CI_DRM_8618: 88841e30e7f8c60ff464be277e5b8fef49ebaea0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5703: c33471b4aa0a0ae9dd42202048e7037a661e0574 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17933: c71cca7b9a9f9b18d2511d9fbff97ba523730f8a @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c71cca7b9a9f drm/i915/rkl: Add initial workarounds
a604ad13c2ad drm/i915/rkl: Handle HTI
1d4ceec6f24a drm/i915/rkl: Add DPLL4 support
1a63a32519fb drm/i915
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Remaining RKL patches (rev4)
== Series Details == Series: Remaining RKL patches (rev4) URL : https://patchwork.freedesktop.org/series/77971/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read64' - different lock contexts
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote: > > Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: > > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: > >>> I still have my doubts about allowing fence waiting from within shrinkers. > >>> IMO ideally they should use a trywait approach, in order to allow memory > >>> allocation during command submission for drivers that > >>> publish fences before command submission. (Since early reservation object > >>> release requires that). > >> Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up > >> with a mempool to make sure it can handle it's allocations. > >> > >>> But since drivers are already waiting from within shrinkers and I take > >>> your > >>> word for HMM requiring this, > >> Yeah the big trouble is HMM and mmu notifiers. That's the really awkward > >> one, the shrinker one is a lot less established. > > I really question if HW that needs something like DMA fence should > > even be using mmu notifiers - the best use is HW that can fence the > > DMA directly without having to get involved with some command stream > > processing. > > > > Or at the very least it should not be a generic DMA fence but a > > narrowed completion tied only into the same GPU driver's command > > completion processing which should be able to progress without > > blocking. > > > > The intent of notifiers was never to endlessly block while vast > > amounts of SW does work. > > > > Going around and switching everything in a GPU to GFP_ATOMIC seems > > like bad idea. > > > >> I've pinged a bunch of armsoc gpu driver people and ask them how much this > >> hurts, so that we have a clear answer. On x86 I don't think we have much > >> of a choice on this, with userptr in amd and i915 and hmm work in nouveau > >> (but nouveau I think doesn't use dma_fence in there). > > Soon nouveau will get company. We're working on a recoverable page fault > implementation for HMM in amdgpu where we'll need to update page tables > using the GPUs SDMA engine and wait for corresponding fences in MMU > notifiers. Well amdgpu already has dma_fence waits in the hmm callbacks, so nothing new. But since you start using these in amdkfd ... perfect opportunity to annotate the amdkfd paths for fence signalling critical sections? Especially the preempt-ctx fence should be an interesting case to annotate and see whether lockdep finds anything. Not sure what else there is. -Daniel > > Regards, > Felix > > > > Right, nor will RDMA ODP. > > > > Jason > > ___ > > amd-gfx mailing list > > amd-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
[Intel-gfx] ✗ Fi.CI.BAT: failure for Remaining RKL patches (rev3)
== Series Details == Series: Remaining RKL patches (rev3) URL : https://patchwork.freedesktop.org/series/77971/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8618 -> Patchwork_17932 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17932 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17932, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17932: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-bdw-5557u/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17932 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-tgl-u2: [PASS][2] -> [FAIL][3] ([i915#1888]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][4] -> [DMESG-WARN][5] ([i915#402]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@i915_module_l...@reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-byt-j1900: [PASS][6] -> [DMESG-WARN][7] ([i915#1982]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html - fi-bsw-kefka: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@module-reload: - fi-cml-s: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-cml-s/igt@i915_pm_...@module-reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-cml-s/igt@i915_pm_...@module-reload.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-j1900: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-bsw-kefka: [DMESG-WARN][14] ([i915#1982]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [DMESG-WARN][16] ([i915#402]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][18] ([i915#62] / [i915#92]) -> [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][21] ([i915#62] / [i915#92]) +4 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17932/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Remaining RKL patches (rev3)
== Series Details == Series: Remaining RKL patches (rev3) URL : https://patchwork.freedesktop.org/series/77971/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1223:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1226:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1229:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1232:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read64' - different lock contexts
[Intel-gfx] [PATCH v5 4/4] drm/i915/rkl: Add initial workarounds
RKL and TGL share some general gen12 workarounds, but each platform also
has its own platform-specific workarounds.
Cc: Matt Atwood
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_sprite.c | 5 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
2 files changed, 59 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 3cd461bf9131..63ac79f88fa2 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -2842,8 +2842,9 @@ static bool skl_plane_format_mod_supported(struct
drm_plane *_plane,
static bool gen12_plane_supports_mc_ccs(struct drm_i915_private *dev_priv,
enum plane_id plane_id)
{
- /* Wa_14010477008:tgl[a0..c0] */
- if (IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
+ /* Wa_14010477008:tgl[a0..c0],rkl[all] */
+ if (IS_ROCKETLAKE(dev_priv) ||
+ IS_TGL_REVID(dev_priv, TGL_REVID_A0, TGL_REVID_C0))
return false;
return plane_id < PLANE_SPRITE4;
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 2da366821dda..f2136f417896 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -596,8 +596,8 @@ static void icl_ctx_workarounds_init(struct intel_engine_cs
*engine,
wa_masked_en(wal, GEN9_ROW_CHICKEN4, GEN11_DIS_PICK_2ND_EU);
}
-static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
-struct i915_wa_list *wal)
+static void gen12_ctx_workarounds_init(struct intel_engine_cs *engine,
+ struct i915_wa_list *wal)
{
/*
* Wa_1409142259:tgl
@@ -607,12 +607,28 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
* Wa_1409207793:tgl
* Wa_1409178076:tgl
* Wa_1408979724:tgl
+* Wa_14010443199:rkl
+* Wa_14010698770:rkl
*/
WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
+ /* WaDisableGPGPUMidThreadPreemption:gen12 */
+ WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
+ GEN9_PREEMPT_GPGPU_LEVEL_MASK,
+ GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
+}
+
+static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
+struct i915_wa_list *wal)
+{
+ gen12_ctx_workarounds_init(engine, wal);
+
/*
-* Wa_1604555607:gen12 and Wa_1608008084:gen12
+* Wa_1604555607:tgl
+*
+* Note that the implementation of this workaround is further modified
+* according to the FF_MODE2 guidance given by Wa_1608008084:gen12.
* FF_MODE2 register will return the wrong value when read. The default
* value for this register is zero for all fields and there are no bit
* masks. So instead of doing a RMW we should just write the GS Timer
@@ -623,11 +639,6 @@ static void tgl_ctx_workarounds_init(struct
intel_engine_cs *engine,
FF_MODE2_GS_TIMER_MASK | FF_MODE2_TDS_TIMER_MASK,
FF_MODE2_GS_TIMER_224 | FF_MODE2_TDS_TIMER_128,
0);
-
- /* WaDisableGPGPUMidThreadPreemption:tgl */
- WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
- GEN9_PREEMPT_GPGPU_LEVEL_MASK,
- GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
}
static void
@@ -642,8 +653,10 @@ __intel_engine_init_ctx_wa(struct intel_engine_cs *engine,
wa_init_start(wal, name, engine->name);
- if (IS_GEN(i915, 12))
+ if (IS_TIGERLAKE(i915))
tgl_ctx_workarounds_init(engine, wal);
+ else if (IS_GEN(i915, 12))
+ gen12_ctx_workarounds_init(engine, wal);
else if (IS_GEN(i915, 11))
icl_ctx_workarounds_init(engine, wal);
else if (IS_CANNONLAKE(i915))
@@ -1176,9 +1189,16 @@ icl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
}
static void
-tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+gen12_gt_workarounds_init(struct drm_i915_private *i915,
+ struct i915_wa_list *wal)
{
wa_init_mcr(i915, wal);
+}
+
+static void
+tgl_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ gen12_gt_workarounds_init(i915, wal);
/* Wa_1409420604:tgl */
if (IS_TGL_REVID(i915, TGL_REVID_A0, TGL_REVID_A0))
@@ -1196,8 +1216,10 @@ tgl_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
static void
gt_init_workarounds(struct drm_i915_private *i915, struct i915_wa_list *wal)
{
- if (IS_GEN(i915, 12))
+ if (IS_TIGERLAKE(i915))
tgl_gt_worka
[Intel-gfx] [PATCH v5 1/4] drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
v2:
- Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
- Checkpatch style fixes
Bspec: 50287
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++---
drivers/gpu/drm/i915/display/intel_display.c | 15 ---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index d1acc39cdc11..a8c44ea2a4a2 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2770,7 +2770,9 @@ hsw_set_signal_levels(struct intel_dp *intel_dp)
static u32 icl_dpclka_cfgcr0_clk_off(struct drm_i915_private *dev_priv,
enum phy phy)
{
- if (intel_phy_is_combo(dev_priv, phy)) {
+ if (IS_ROCKETLAKE(dev_priv)) {
+ return RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
+ } else if (intel_phy_is_combo(dev_priv, phy)) {
return ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy);
} else if (intel_phy_is_tc(dev_priv, phy)) {
enum tc_port tc_port = intel_port_to_tc(dev_priv,
@@ -2797,6 +2799,16 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
(val & icl_dpclka_cfgcr0_clk_off(dev_priv, phy)) == 0);
if (intel_phy_is_combo(dev_priv, phy)) {
+ u32 mask, sel;
+
+ if (IS_ROCKETLAKE(dev_priv)) {
+ mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ sel = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ } else {
+ mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ sel = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ }
+
/*
* Even though this register references DDIs, note that we
* want to pass the PHY rather than the port (DDI). For
@@ -2807,8 +2819,8 @@ static void icl_map_plls_to_ports(struct intel_encoder
*encoder,
* Clock Select chooses the PLL for both DDIA and DDID and
* drives port A in all cases."
*/
- val &= ~ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- val |= ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll->info->id, phy);
+ val &= ~mask;
+ val |= sel;
intel_de_write(dev_priv, ICL_DPCLKA_CFGCR0, val);
intel_de_posting_read(dev_priv, ICL_DPCLKA_CFGCR0);
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7457813ef273..6c2bb3354b86 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10785,9 +10785,18 @@ static void icl_get_ddi_pll(struct drm_i915_private
*dev_priv, enum port port,
u32 temp;
if (intel_phy_is_combo(dev_priv, phy)) {
- temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) &
- ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
- id = temp >> ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ u32 mask, shift;
+
+ if (IS_ROCKETLAKE(dev_priv)) {
+ mask = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ shift = RKL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ } else {
+ mask = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy);
+ shift = ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy);
+ }
+
+ temp = intel_de_read(dev_priv, ICL_DPCLKA_CFGCR0) & mask;
+ id = temp >> shift;
port_dpll_id = ICL_PORT_DPLL_DEFAULT;
} else if (intel_phy_is_tc(dev_priv, phy)) {
u32 clk_sel = intel_de_read(dev_priv, DDI_CLK_SEL(port)) &
DDI_CLK_SEL_MASK;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 19e1fed198c3..ca46ca8c80ec 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10195,12 +10195,18 @@ enum skl_power_gate {
#define ICL_DPCLKA_CFGCR0 _MMIO(0x164280)
#define ICL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)(1 << _PICK(phy, 10, 11, 24))
+#define RKL_DPCLKA_CFGCR0_DDI_CLK_OFF(phy)REG_BIT((phy) + 10)
#define ICL_DPCLKA_CFGCR0_TC_CLK_OFF(tc_port) (1 << ((tc_port) < PORT_TC4 ? \
(tc_port) + 12 : \
(tc_port) - PORT_TC4 +
21))
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy) ((phy) * 2)
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(phy) (3 <<
ICL_DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(phy))
#define ICL_DPCLKA_CFGCR0_DDI_CLK_SEL(pll, phy) ((pll) <<
ICL_DPCLKA_CFGCR0_DDI_CLK_SEL
[Intel-gfx] [PATCH v5 0/4] Remaining RKL patches
Most of the Rocket Lake enablement patches have landed on drm-tip now, but there are still a few left awaiting reviews. Rebasing and resending the ones that still need attention. Matt Roper (4): drm/i915/rkl: Handle new DPCLKA_CFGCR0 layout drm/i915/rkl: Add DPLL4 support drm/i915/rkl: Handle HTI drm/i915/rkl: Add initial workarounds drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++- drivers/gpu/drm/i915/display/intel_display.c | 45 -- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 50 ++- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 + drivers/gpu/drm/i915/display/intel_sprite.c | 5 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 --- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 12 +++ 8 files changed, 175 insertions(+), 47 deletions(-) -- 2.24.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/4] drm/i915/rkl: Add DPLL4 support
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display. Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1. And despite its name, the DPLL4 registers
are offset as if it were DPLL2, so no extra offset handling is needed
either.
v2:
- Add new .update_ref_clks() hook.
Bspec: 49202
Bspec: 49443
Bspec: 50288
Bspec: 50289
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 29 +--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b45185b80bec..b5f4d4cef682 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -3506,13 +3506,19 @@ static bool icl_get_combo_phy_dpll(struct
intel_atomic_state *state,
return false;
}
- if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A)
+ if (IS_ROCKETLAKE(dev_priv)) {
dpll_mask =
BIT(DPLL_ID_EHL_DPLL4) |
BIT(DPLL_ID_ICL_DPLL1) |
BIT(DPLL_ID_ICL_DPLL0);
- else
+ } else if (IS_ELKHARTLAKE(dev_priv) && port != PORT_A) {
+ dpll_mask =
+ BIT(DPLL_ID_EHL_DPLL4) |
+ BIT(DPLL_ID_ICL_DPLL1) |
+ BIT(DPLL_ID_ICL_DPLL0);
+ } else {
dpll_mask = BIT(DPLL_ID_ICL_DPLL1) | BIT(DPLL_ID_ICL_DPLL0);
+ }
port_dpll->pll = intel_find_shared_dpll(state, crtc,
&port_dpll->hw_state,
@@ -4275,6 +4281,21 @@ static const struct intel_dpll_mgr tgl_pll_mgr = {
.dump_hw_state = icl_dump_hw_state,
};
+static const struct dpll_info rkl_plls[] = {
+ { "DPLL 0", &combo_pll_funcs, DPLL_ID_ICL_DPLL0, 0 },
+ { "DPLL 1", &combo_pll_funcs, DPLL_ID_ICL_DPLL1, 0 },
+ { "DPLL 4", &combo_pll_funcs, DPLL_ID_EHL_DPLL4, 0 },
+ { },
+};
+
+static const struct intel_dpll_mgr rkl_pll_mgr = {
+ .dpll_info = rkl_plls,
+ .get_dplls = icl_get_dplls,
+ .put_dplls = icl_put_dplls,
+ .update_ref_clks = icl_update_dpll_ref_clks,
+ .dump_hw_state = icl_dump_hw_state,
+};
+
/**
* intel_shared_dpll_init - Initialize shared DPLLs
* @dev: drm device
@@ -4288,7 +4309,9 @@ void intel_shared_dpll_init(struct drm_device *dev)
const struct dpll_info *dpll_info;
int i;
- if (INTEL_GEN(dev_priv) >= 12)
+ if (IS_ROCKETLAKE(dev_priv))
+ dpll_mgr = &rkl_pll_mgr;
+ else if (INTEL_GEN(dev_priv) >= 12)
dpll_mgr = &tgl_pll_mgr;
else if (IS_ELKHARTLAKE(dev_priv))
dpll_mgr = &ehl_pll_mgr;
--
2.24.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/4] drm/i915/rkl: Handle HTI
If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage. Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.
v2:
- Fix minor checkpatch warnings
Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 30 ---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 21 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 +
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 6
5 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 6c2bb3354b86..f16512eddc58 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -46,6 +46,7 @@
#include "display/intel_ddi.h"
#include "display/intel_dp.h"
#include "display/intel_dp_mst.h"
+#include "display/intel_dpll_mgr.h"
#include "display/intel_dsi.h"
#include "display/intel_dvo.h"
#include "display/intel_gmbus.h"
@@ -16814,6 +16815,13 @@ static void intel_pps_init(struct drm_i915_private
*dev_priv)
intel_pps_unlock_regs_wa(dev_priv);
}
+static bool hti_uses_phy(u32 hdport_state, enum phy phy)
+{
+ return hdport_state & HDPORT_ENABLED &&
+ (hdport_state & HDPORT_PHY_USED_DP(phy) ||
+hdport_state & HDPORT_PHY_USED_HDMI(phy));
+}
+
static void intel_setup_outputs(struct drm_i915_private *dev_priv)
{
struct intel_encoder *encoder;
@@ -16825,10 +16833,22 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
return;
if (IS_ROCKETLAKE(dev_priv)) {
- intel_ddi_init(dev_priv, PORT_A);
- intel_ddi_init(dev_priv, PORT_B);
- intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
- intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
+ /*
+* If HTI (aka HDPORT) is enabled at boot, it may have taken
+* over some of the PHYs and made them unavailable to the
+* driver. In that case we should skip initializing the
+* corresponding outputs.
+*/
+ u32 hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
+
+ if (!hti_uses_phy(hdport_state, PHY_A))
+ intel_ddi_init(dev_priv, PORT_A);
+ if (!hti_uses_phy(hdport_state, PHY_B))
+ intel_ddi_init(dev_priv, PORT_B);
+ if (!hti_uses_phy(hdport_state, PHY_C))
+ intel_ddi_init(dev_priv, PORT_D); /* DDI TC1 */
+ if (!hti_uses_phy(hdport_state, PHY_D))
+ intel_ddi_init(dev_priv, PORT_E); /* DDI TC2 */
} else if (INTEL_GEN(dev_priv) >= 12) {
intel_ddi_init(dev_priv, PORT_A);
intel_ddi_init(dev_priv, PORT_B);
@@ -18376,6 +18396,8 @@ static void intel_modeset_readout_hw_state(struct
drm_device *dev)
intel_dpll_readout_hw_state(dev_priv);
+ dev_priv->hti_pll_mask = intel_get_hti_plls(dev_priv);
+
for_each_intel_encoder(dev, encoder) {
pipe = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
index b5f4d4cef682..6f59f9ec453b 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
@@ -265,6 +265,24 @@ void intel_disable_shared_dpll(const struct
intel_crtc_state *crtc_state)
mutex_unlock(&dev_priv->dpll.lock);
}
+/*
+ * HTI (aka HDPORT) may be using some of the platform's PLL's, making them
+ * unavailable for use.
+ */
+u32 intel_get_hti_plls(struct drm_i915_private *dev_priv)
+{
+ u32 hdport_state;
+
+ if (!IS_ROCKETLAKE(dev_priv))
+ return 0;
+
+ hdport_state = intel_de_read(dev_priv, HDPORT_STATE);
+ if (!(hdport_state & HDPORT_ENABLED))
+ return 0;
+
+ return REG_FIELD_GET(HDPORT_DPLL_USED_MASK, hdport_state);
+}
+
static struct intel_shared_dpll *
intel_find_shared_dpll(struct intel_atomic_state *state,
const struct intel_crtc *crtc,
@@ -280,6 +298,9 @@ intel_find_shared_dpll(struct intel_atomic_state *state,
drm_WARN_ON(&dev_priv->drm, dpll_mask & ~(BIT(I915_NUM_PLLS) - 1));
+ /* Eliminate DPLLs from consideration if reserved by HTI */
+ dpll_mask &= ~dev_priv->hti_pll_mask;
+
for_each_set_bit(i, &dpll_mask, I915_NUM_PLLS) {
pll = &dev_priv->dpll.shared_dplls[i];
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index 5d9a2bc371e7..ac2238646fe7 100644
--- a/drivers/gpu/drm/i915/display/in
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Leave vma intact as they are discarded
== Series Details == Series: drm/i915: Leave vma intact as they are discarded URL : https://patchwork.freedesktop.org/series/78233/ State : success == Summary == CI Bug Log - changes from CI_DRM_8618_full -> Patchwork_17930_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17930_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl6/igt@gem_ctx_isolation@preservation...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-kbl3/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_eio@wait-wedge-10ms: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#95]) +28 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl3/igt@gem_...@wait-wedge-10ms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-apl4/igt@gem_...@wait-wedge-10ms.html * igt@gem_mmap_wc@write-cpu-read-wc: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl7/igt@gem_mmap...@write-cpu-read-wc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-kbl3/igt@gem_mmap...@write-cpu-read-wc.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-iclb1/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-iclb2/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#151] / [i915#69]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl9/igt@i915_pm_...@system-suspend-execbuf.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-skl4/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_crc@pipe-c-cursor-128x42-onscreen: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#54]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl9/igt@kms_cursor_...@pipe-c-cursor-128x42-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-skl4/igt@kms_cursor_...@pipe-c-cursor-128x42-onscreen.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +12 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl8/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-skl5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#1928]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate-interrupti...@ab-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-suspend-interruptible@a-dp1: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl4/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@a-dp1.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-tglb5/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-mmap-gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-tglb1/igt@kms_frontbuffer_track...@psr-1p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([i915#69]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/shard-skl8/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [i915#265]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.htm
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Implement WA_1406941453
== Series Details == Series: drm/i915/gt: Implement WA_1406941453 URL : https://patchwork.freedesktop.org/series/78243/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8618 -> Patchwork_17931 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17931 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17931, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17931: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-bdw-5557u: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-bdw-5557u/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17931 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - fi-tgl-u2: [PASS][2] -> [FAIL][3] ([i915#1888]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html * igt@gem_sync@basic-all: - fi-icl-guc: [PASS][4] -> [DMESG-WARN][5] ([i915#1982]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-icl-guc/igt@gem_s...@basic-all.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-icl-guc/igt@gem_s...@basic-all.html * igt@i915_module_load@reload: - fi-tgl-u2: [PASS][6] -> [DMESG-WARN][7] ([i915#1982]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@i915_module_l...@reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-tgl-u2/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-bsw-kefka: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][10] -> [DMESG-WARN][11] ([i915#1982]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Possible fixes * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-j1900: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-tgl-u2: [DMESG-WARN][14] ([i915#402]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html Warnings * igt@gem_exec_suspend@basic-s0: - fi-kbl-x1275: [DMESG-WARN][16] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][17] ([i915#62] / [i915#92]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][18] ([i915#62] / [i915#92]) -> [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95]) +4 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17931/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888 [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participa
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only discard simple GGTT vma
== Series Details == Series: drm/i915: Only discard simple GGTT vma URL : https://patchwork.freedesktop.org/series/78232/ State : success == Summary == CI Bug Log - changes from CI_DRM_8618_full -> Patchwork_17929_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17929_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_wc@write-cpu-read-wc: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) +22 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl2/igt@gem_mmap...@write-cpu-read-wc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-apl6/igt@gem_mmap...@write-cpu-read-wc.html - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / [i915#95]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl7/igt@gem_mmap...@write-cpu-read-wc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-kbl2/igt@gem_mmap...@write-cpu-read-wc.html * igt@kms_big_fb@x-tiled-8bpp-rotate-180: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl2/igt@kms_big...@x-tiled-8bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-kbl6/igt@kms_big...@x-tiled-8bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([i915#300]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-skl8/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-onscreen: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-snb1/igt@kms_cursor_...@pipe-b-cursor-256x256-onscreen.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-snb4/igt@kms_cursor_...@pipe-b-cursor-256x256-onscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@pipe-b-torture-move: - shard-iclb: [PASS][13] -> [DMESG-WARN][14] ([i915#128]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-iclb7/igt@kms_cursor_leg...@pipe-b-torture-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-iclb4/igt@kms_cursor_leg...@pipe-b-torture-move.html * igt@kms_flip@flip-vs-expired-vblank@b-edp1: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#46]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl7/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-skl4/igt@kms_flip@flip-vs-expired-vbl...@b-edp1.html * igt@kms_flip@flip-vs-fences@a-edp1: - shard-skl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl3/igt@kms_flip@flip-vs-fen...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-skl3/igt@kms_flip@flip-vs-fen...@a-edp1.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_multiple@atomic-pipe-c-tiling-none: - shard-tglb: [PASS][23] -> [DMESG-WARN][24] ([i915#402]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-tglb5/igt@kms_plane_multi...@atomic-pipe-c-tiling-none.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/shard-tglb6/igt@kms_plane_multi...@atomic-pipe-c-tiling-none.html * igt@kms_psr@psr2_sprite_ren
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe: > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote: >>> I still have my doubts about allowing fence waiting from within shrinkers. >>> IMO ideally they should use a trywait approach, in order to allow memory >>> allocation during command submission for drivers that >>> publish fences before command submission. (Since early reservation object >>> release requires that). >> Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up >> with a mempool to make sure it can handle it's allocations. >> >>> But since drivers are already waiting from within shrinkers and I take your >>> word for HMM requiring this, >> Yeah the big trouble is HMM and mmu notifiers. That's the really awkward >> one, the shrinker one is a lot less established. > I really question if HW that needs something like DMA fence should > even be using mmu notifiers - the best use is HW that can fence the > DMA directly without having to get involved with some command stream > processing. > > Or at the very least it should not be a generic DMA fence but a > narrowed completion tied only into the same GPU driver's command > completion processing which should be able to progress without > blocking. > > The intent of notifiers was never to endlessly block while vast > amounts of SW does work. > > Going around and switching everything in a GPU to GFP_ATOMIC seems > like bad idea. > >> I've pinged a bunch of armsoc gpu driver people and ask them how much this >> hurts, so that we have a clear answer. On x86 I don't think we have much >> of a choice on this, with userptr in amd and i915 and hmm work in nouveau >> (but nouveau I think doesn't use dma_fence in there). Soon nouveau will get company. We're working on a recoverable page fault implementation for HMM in amdgpu where we'll need to update page tables using the GPUs SDMA engine and wait for corresponding fences in MMU notifiers. Regards, Felix > Right, nor will RDMA ODP. > > Jason > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Implement WA_1406941453
From: Clint Taylor
Enable HW Default flip for small PL.
bspec: 52890
bspec: 53508
bspec: 53273
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 2da366821dda..0b9091c05e06 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -628,6 +628,9 @@ static void tgl_ctx_workarounds_init(struct intel_engine_cs
*engine,
WA_SET_FIELD_MASKED(GEN8_CS_CHICKEN1,
GEN9_PREEMPT_GPGPU_LEVEL_MASK,
GEN9_PREEMPT_GPGPU_THREAD_GROUP_LEVEL);
+
+ /* Wa_1406941453:gen12 */
+ WA_SET_BIT_MASKED(GEN10_SAMPLER_MODE, ENABLE_SMALLPL);
}
static void
@@ -1500,6 +1503,9 @@ static void icl_whitelist_build(struct intel_engine_cs
*engine)
whitelist_reg_ext(w, PS_INVOCATION_COUNT,
RING_FORCE_TO_NONPRIV_ACCESS_RD |
RING_FORCE_TO_NONPRIV_RANGE_4);
+
+ /* Wa_1406941453:gen12 */
+ whitelist_reg(w, GEN10_SAMPLER_MODE);
break;
case VIDEO_DECODE_CLASS:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 19e1fed198c3..fbb095a94b3a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9223,6 +9223,7 @@ enum {
#define GEN11_LSN_UNSLCVC_GAFS_HALF_SF_MAXALLOC (1 << 7)
#define GEN10_SAMPLER_MODE _MMIO(0xE18C)
+#define ENABLE_SMALLPL REG_BIT(15)
#define GEN11_SAMPLER_ENABLE_HEADLESS_MSGREG_BIT(5)
/* IVYBRIDGE DPF */
--
2.26.0
___
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/gt: Flush gen3 relocs harder, again
== Series Details == Series: drm/i915/gt: Flush gen3 relocs harder, again URL : https://patchwork.freedesktop.org/series/78230/ State : success == Summary == CI Bug Log - changes from CI_DRM_8618_full -> Patchwork_17928_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17928_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_whisper@basic-fds-forked-all: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-glk1/igt@gem_exec_whis...@basic-fds-forked-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-glk8/igt@gem_exec_whis...@basic-fds-forked-all.html * igt@gem_mmap_wc@write-cpu-read-wc: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#95]) +21 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl2/igt@gem_mmap...@write-cpu-read-wc.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-apl1/igt@gem_mmap...@write-cpu-read-wc.html - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl7/igt@gem_mmap...@write-cpu-read-wc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-kbl4/igt@gem_mmap...@write-cpu-read-wc.html * igt@kms_big_fb@x-tiled-64bpp-rotate-0: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-glk1/igt@kms_big...@x-tiled-64bpp-rotate-0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-0.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl3/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-apl4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-apl7/igt@kms_fbcon_...@fbc-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-apl4/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#79]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-edp1.html * igt@kms_flip@flip-vs-fences@a-edp1: - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl3/igt@kms_flip@flip-vs-fen...@a-edp1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-skl1/igt@kms_flip@flip-vs-fen...@a-edp1.html * igt@kms_flip@flip-vs-suspend@a-dp1: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl6/igt@kms_flip@flip-vs-susp...@a-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-kbl7/igt@kms_flip@flip-vs-susp...@a-dp1.html * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1: - shard-skl: [PASS][19] -> [DMESG-FAIL][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl2/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-skl8/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html * igt@kms_flip_tiling@flip-yf-tiled: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-kbl2/igt@kms_flip_til...@flip-yf-tiled.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-kbl7/igt@kms_flip_til...@flip-yf-tiled.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-mmap-gtt: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#49]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/shard-skl5/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/shard-skl9/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-mmap-gtt.html * igt@kms_
[Intel-gfx] [PATCH i-g-t] i915/gem_ctx_isolation: Verify BB_OFFSET protection
BB_OFFSET is used for relative batch buffer jumps, so prime the register
and do a jump, but only after a context switch or two.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
tests/i915/gem_ctx_isolation.c | 139 +
1 file changed, 139 insertions(+)
diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
index 9fdf78bb8..b689d37dd 100644
--- a/tests/i915/gem_ctx_isolation.c
+++ b/tests/i915/gem_ctx_isolation.c
@@ -24,6 +24,7 @@
#include "i915/gem.h"
#include "igt.h"
#include "igt_dummyload.h"
+#include "sw_sync.h"
#define MAX_REG 0x20
#define NUM_REGS (MAX_REG / sizeof(uint32_t))
@@ -874,6 +875,124 @@ static void preservation(int fd,
gem_context_destroy(fd, ctx[num_values]);
}
+static int sync_fence_wait_status(int fence, int timeout)
+{
+ int err;
+
+ err = sync_fence_wait(fence, timeout);
+ if (err)
+ return err;
+
+ return sync_fence_status(fence);
+}
+
+static int write_register(int i915, uint32_t ctx, unsigned int engine,
+ uint32_t reg, uint32_t value)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = gem_create(i915, 4096),
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .rsvd1 = ctx,
+ .flags = engine | I915_EXEC_FENCE_OUT,
+ };
+ uint32_t *cs, *map;
+
+ map = gem_mmap__device_coherent(i915, obj.handle, 0, 4096, PROT_WRITE);
+
+ cs = map;
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = reg;
+ *cs++ = value;
+ *cs++ = MI_BATCH_BUFFER_END;
+ munmap(map, 4096);
+
+ gem_execbuf_wr(i915, &execbuf);
+ gem_close(i915, obj.handle);
+
+ return execbuf.rsvd2 >> 32;
+}
+
+static void bb_offset(int i915,
+ const struct intel_execution_engine2 *e,
+ unsigned int flags)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = gem_create(i915, 4096 * 3),
+ .flags = EXEC_OBJECT_PINNED
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .rsvd1 = gem_context_create_for_engine(i915, e->class,
e->instance),
+ };
+ const uint32_t mmio_base = gem_engine_mmio_base(i915, e->name);
+ uint32_t *cs, *map;
+ igt_spin_t *spin;
+
+ igt_require(gem_class_has_mutable_submission(i915, e->class)); /* XXX */
+ igt_require(mmio_base);
+
+ gem_quiescent_gpu(i915);
+
+ map = gem_mmap__device_coherent(i915, obj.handle, 0, 4096 * 3,
PROT_WRITE);
+ memset(map, 0xff, 4096 * 3);
+
+ cs = map + 2 * 1024 + 256;
+ *cs++ = MI_LOAD_REGISTER_IMM;
+ *cs++ = mmio_base + 0x158; /* BB_OFFSET */
+ *cs++ = 4096;
+ *cs++ = MI_BATCH_BUFFER_END;
+
+ cs = map + 2 * 1024 + 128;
+ *cs++ = MI_BATCH_BUFFER_START | 1 << 16 | 1 << 8 | 1; /* reljmp */
+ *cs++ = 0; /* + BB_OFFSET */
+ *cs++ = 0;
+
+ cs = map + 1024;
+ *cs++ = MI_BATCH_BUFFER_END;
+ munmap(map, 3 * 4096);
+
+ execbuf.batch_start_offset = 2 * 4096 + 1024;
+ gem_execbuf(i915, &execbuf); /* prime BB_OFFSET */
+
+ spin = igt_spin_new(i915,
+ .ctx = execbuf.rsvd1,
+ .flags = IGT_SPIN_POLL_RUN);
+ igt_spin_busywait_until_started(spin);
+
+ if (flags & DIRTY1) {
+ uint32_t ctx;
+ int fence;
+
+ ctx = gem_context_create_for_engine(i915, e->class,
e->instance);
+ gem_context_set_priority(i915, ctx, 1023);
+
+ fence = write_register(i915, ctx, 0,
+ mmio_base + 0x158, 0xdeadbeef);
+
+ gem_context_destroy(i915, ctx);
+
+ igt_assert_eq(sync_fence_wait_status(fence, 500), 1);
+ close(fence);
+ }
+
+ if (flags & RESET)
+ inject_reset_context(i915, e);
+
+ execbuf.batch_start_offset = 2 * 4096 + 512;
+ execbuf.flags |= I915_EXEC_FENCE_OUT;
+ gem_execbuf_wr(i915, &execbuf); /* relative jump */
+
+ igt_spin_free(i915, spin);
+ igt_assert_eq(sync_fence_wait_status(execbuf.rsvd2 >> 32, 500), 1);
+ close(execbuf.rsvd2);
+
+ gem_context_destroy(i915, execbuf.rsvd1);
+}
+
static unsigned int __has_context_isolation(int fd)
{
struct drm_i915_getparam gp;
@@ -963,6 +1082,16 @@ igt_main
preservation(i915, e, S4);
}
+ igt_subtest_with_dynamic("bb-offset-clean") {
+ test_each_engine(e, i915, has_context_isolation)
+ bb_offset(i915, e, 0);
+ }
+ igt_subtest_with_dynamic("bb-offset-switch") {
+ igt_require(gem_scheduler_has_preemption(i915));
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Leave vma intact as they are discarded
== Series Details ==
Series: drm/i915: Leave vma intact as they are discarded
URL : https://patchwork.freedesktop.org/series/78233/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8618 -> Patchwork_17930
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/index.html
Known issues
Here are the changes found in Patchwork_17930 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#402])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-tgl-u2/igt@i915_module_l...@reload.html
- fi-byt-n2820: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-n2820/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-byt-n2820/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-guc: [PASS][5] -> [FAIL][6] ([i915#579])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@requests:
- fi-apl-guc: [PASS][7] -> [INCOMPLETE][8] ([i915#337])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-apl-guc/igt@i915_selftest@l...@requests.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-apl-guc/igt@i915_selftest@l...@requests.html
Possible fixes
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- {fi-tgl-dsi}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-tgl-dsi/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Warnings
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) ->
[DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17930/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#337]: https://gitlab.freedesktop.org/drm/intel/issues/337
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 42)
--
Missing(8): fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only discard simple GGTT vma
== Series Details == Series: drm/i915: Only discard simple GGTT vma URL : https://patchwork.freedesktop.org/series/78232/ State : success == Summary == CI Bug Log - changes from CI_DRM_8618 -> Patchwork_17929 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/index.html Known issues Here are the changes found in Patchwork_17929 that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-cml-u2: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - fi-icl-guc: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-icl-guc/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1: - fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@b-edp1.html Possible fixes * igt@kms_busy@basic@flip: - fi-kbl-x1275: [DMESG-WARN][7] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_busy@ba...@flip.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-kbl-x1275/igt@kms_busy@ba...@flip.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-byt-j1900: [DMESG-WARN][9] ([i915#1982]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html - fi-bsw-kefka: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Warnings * igt@kms_flip@basic-flip-vs-modeset@a-dp1: - fi-kbl-x1275: [DMESG-WARN][13] ([i915#62] / [i915#92]) -> [DMESG-WARN][14] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html * igt@kms_force_connector_basic@force-edid: - fi-kbl-x1275: [DMESG-WARN][15] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][16] ([i915#62] / [i915#92]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8618 -> Patchwork_17929 CI-20190529: 20190529 CI_DRM_8618: 88841e30e7f8c60ff464be277e5b8fef49ebaea0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5703: c33471b4aa0a0ae9dd42202048e7037a661e0574 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17929: 17a2d9b0a055cf3cc4e5c93f7ffc7cffb3ec0f6b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 17a2d9b0a055 drm/i915: Only discard simple GGTT vma == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17929/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Leave vma intact as they are discarded
If we find ourselves trying to reuse a misplaced but active vma, we
currently try to discard it to avoid having to wait to unbind it
(upsetting the current user fo the vma). An alternative to marking it as
a dicarded vma and keeping it in both the obj->vma.list and
obj->vma.tree, is to simply remove it from the lookup rbtree.
While it remains in the list of vma, it will be unbound under eviction
pressure and freed along with the object. We will never reuse it again
for new instances. As before, with no pruning, the list may continually
grow, but eventually we will have the most constrained version of the
ggtt view that meets all requirements -- so the list of vma should not
grow without bound.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2012
Fixes: 9bdcaa5e3a2f ("drm/i915: Discard a misplaced GGTT vma")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 38 +
drivers/gpu/drm/i915/i915_vma.c | 3 ++-
2 files changed, 7 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41553e9e57a9..9aa3066cb75d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -933,44 +933,16 @@ void i915_gem_runtime_suspend(struct drm_i915_private
*i915)
}
}
-static bool
-discard_ggtt_vma(struct i915_vma *vma, const struct i915_ggtt_view *view)
+static void discard_ggtt_vma(struct i915_vma *vma)
{
- const struct i915_ggtt_view discard = {
- .type = I915_GGTT_VIEW_PARTIAL,
- };
struct drm_i915_gem_object *obj = vma->obj;
spin_lock(&obj->vma.lock);
- if (i915_vma_compare(vma, vma->vm, &discard)) {
- struct rb_node *rb, **p;
-
+ if (!RB_EMPTY_NODE(&vma->obj_node)) {
rb_erase(&vma->obj_node, &obj->vma.tree);
- vma->ggtt_view = discard;
- GEM_BUG_ON(i915_vma_compare(vma, vma->vm, &discard));
- GEM_BUG_ON(i915_vma_compare(vma, vma->vm, view) == 0);
-
- rb = NULL;
- p = &obj->vma.tree.rb_node;
- while (*p) {
- struct i915_vma *pos;
- long cmp;
-
- rb = *p;
- pos = rb_entry(rb, struct i915_vma, obj_node);
-
- cmp = i915_vma_compare(pos, vma->vm, &discard);
- if (cmp < 0)
- p = &rb->rb_right;
- else
- p = &rb->rb_left;
- }
- rb_link_node(&vma->obj_node, rb, p);
- rb_insert_color(&vma->obj_node, &obj->vma.tree);
+ RB_CLEAR_NODE(&vma->obj_node);
}
spin_unlock(&obj->vma.lock);
-
- return i915_vma_compare(vma, vma->vm, view);
}
struct i915_vma *
@@ -1035,8 +1007,8 @@ i915_gem_object_ggtt_pin(struct drm_i915_gem_object *obj,
}
if (i915_vma_is_pinned(vma) || i915_vma_is_active(vma)) {
- if (discard_ggtt_vma(vma, view))
- goto new_vma;
+ discard_ggtt_vma(vma);
+ goto new_vma;
}
ret = i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 9b30ddc49e4b..1f63c4a1f055 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1087,7 +1087,8 @@ void i915_vma_release(struct kref *ref)
spin_lock(&obj->vma.lock);
list_del(&vma->obj_link);
- rb_erase(&vma->obj_node, &obj->vma.tree);
+ if (!RB_EMPTY_NODE(&vma->obj_node))
+ rb_erase(&vma->obj_node, &obj->vma.tree);
spin_unlock(&obj->vma.lock);
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/vblank: Estimate sample time (rev2)
== Series Details == Series: series starting with [v2] drm/vblank: Estimate sample time (rev2) URL : https://patchwork.freedesktop.org/series/78223/ State : success == Summary == CI Bug Log - changes from CI_DRM_8617_full -> Patchwork_17927_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17927_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-wc-cpu-active: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) +20 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-apl2/igt@gem_exec_re...@basic-wc-cpu-active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-apl4/igt@gem_exec_re...@basic-wc-cpu-active.html * igt@gem_exec_whisper@basic-fds-priority: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-glk9/igt@gem_exec_whis...@basic-fds-priority.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-glk5/igt@gem_exec_whis...@basic-fds-priority.html * igt@gem_softpin@overlap: - shard-skl: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +14 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-skl3/igt@gem_soft...@overlap.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-skl7/igt@gem_soft...@overlap.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-apl1/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_big_fb@linear-8bpp-rotate-180: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-apl6/igt@kms_big...@linear-8bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-apl7/igt@kms_big...@linear-8bpp-rotate-180.html - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-kbl7/igt@kms_big...@linear-8bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-kbl3/igt@kms_big...@linear-8bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#402]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-tglb8/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-tglb8/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#93] / [i915#95]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-kbl2/igt@kms_frontbuffer_track...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_hdr@bpc-switch-suspend: - shard-skl: [PASS][19] -> [FAIL][20] ([i915#1188]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-skl6/igt@kms_...@bpc-switch-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-skl2/igt@kms_...@bpc-switch-suspend.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-iclb5/igt@kms_psr@psr2_cursor_render.html Possible fixes * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-apl: [FAIL][23] ([i915#1528]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/shard-apl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/shard-apl2/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [DMESG-WARN][25] ([i915#402]
[Intel-gfx] [PATCH] drm/i915: Only discard simple GGTT vma
Be careful that we do not discard the irregular information used for
remapping the planes, and when discarding preserve the partial offset so
that the existing users can continue to interpret the old vma correctly.
An underlying issue here is that we opting to discard a vma while it is
in the process of being bound, because at the time it is not known
whether it will be bound suitable for our use. If we didn't discard, we
would then try to unbind it even if it were suitable after serialising
with the binder.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2012
Fixes: 9bdcaa5e3a2f ("drm/i915: Discard a misplaced GGTT vma")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 41553e9e57a9..cd5aeeb96ca4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -938,9 +938,13 @@ discard_ggtt_vma(struct i915_vma *vma, const struct
i915_ggtt_view *view)
{
const struct i915_ggtt_view discard = {
.type = I915_GGTT_VIEW_PARTIAL,
+ .partial.offset = view->partial.offset,
};
struct drm_i915_gem_object *obj = vma->obj;
+ if (view->type > I915_GGTT_VIEW_PARTIAL)
+ return false;
+
spin_lock(&obj->vma.lock);
if (i915_vma_compare(vma, vma->vm, &discard)) {
struct rb_node *rb, **p;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Flush gen3 relocs harder, again
== Series Details ==
Series: drm/i915/gt: Flush gen3 relocs harder, again
URL : https://patchwork.freedesktop.org/series/78230/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8618 -> Patchwork_17928
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/index.html
Known issues
Here are the changes found in Patchwork_17928 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@c-edp1.html
Possible fixes
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [DMESG-WARN][7] ([i915#402]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Warnings
* igt@kms_flip@basic-flip-vs-modeset@a-dp1:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92]) ->
[DMESG-WARN][10] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-mode...@a-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][12] ([i915#62] / [i915#92]) +5 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8618/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/fi-kbl-x1275/igt@kms_force_connector_ba...@force-edid.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1569]: https://gitlab.freedesktop.org/drm/intel/issues/1569
[i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
[i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
[i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (50 -> 43)
--
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_8618 -> Patchwork_17928
CI-20190529: 20190529
CI_DRM_8618: 88841e30e7f8c60ff464be277e5b8fef49ebaea0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5703: c33471b4aa0a0ae9dd42202048e7037a661e0574 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_17928: c941a56c4805f053450c96e0c4366f90289b14d3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c941a56c4805 drm/i915/gt: Flush gen3 relocs harder, again
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17928/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl+: Fix DP MST ACT status handling
On Thu, Jun 11, 2020 at 06:39:55PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 10, 2020 at 09:31:31PM +0300, Imre Deak wrote:
> > On TGL+ the master transcoder's DP_TP_STATUS register should be used for
> > the MST ACT status handling, so make sure we do that even in case of
> > mulitple streams.
> >
> > This fixes an ACT timeout problem during disabling when using multiple
> > streams. Not sure why this was not a problem during enabling (even the
> > slave's DP_TP_STATUS signaled ACT correctly), but following the spec
> > works in that case too, so let's do that.
> >
> > There is one more place using DP_TP_STATUS, FEC enabling, but I haven't
> > found in BSpec which register to use in that case, so I leave the
> > clarification of that for later.
> >
> > BSpec: 49190
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 47 +
> > 1 file changed, 39 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index d18b406f2a7d..1c3654a117a9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -316,6 +316,40 @@ intel_dp_mst_atomic_check(struct drm_connector
> > *connector,
> > return ret;
> > }
> >
> > +static i915_reg_t
> > +master_dp_tp_status_reg(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> > +
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + return TGL_DP_TP_STATUS(crtc_state->mst_master_transcoder);
> > +
> > + return intel_dp->regs.dp_tp_status;
> > +}
> > +
> > +static void clear_act_sent(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > + i915_reg_t dp_tp_status_reg =
> > + master_dp_tp_status_reg(crtc_state, intel_dp);
> > +
> > + intel_de_write(i915, dp_tp_status_reg,
> > + intel_de_read(i915, dp_tp_status_reg));
>
> Followup material:
> Should we actually just clear the bit(s) we care about? No idea what
> other stuff is in there.
Yes, was thinking about that, but thought to leave it as-is for now,
since enabling may depend on something that we clear there. Though
clearing all the bits may break disabling, so probably better to have
this change already now.
>
> > +}
> > +
> > +static bool wait_for_act_sent(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > + i915_reg_t dp_tp_status_reg =
> > + master_dp_tp_status_reg(crtc_state, intel_dp);
> > +
> > + return intel_de_wait_for_set(i915, dp_tp_status_reg,
> > +DP_TP_STATUS_ACT_SENT, 1) == 0;
> > +}
> > +
> > static void intel_mst_disable_dp(struct intel_atomic_state *state,
> > struct intel_encoder *encoder,
> > const struct intel_crtc_state *old_crtc_state,
> > @@ -376,8 +410,7 @@ static void intel_mst_post_disable_dp(struct
> > intel_atomic_state *state,
> >TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
> >val);
> >
> > - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> > - DP_TP_STATUS_ACT_SENT, 1))
> > + if (!wait_for_act_sent(old_crtc_state, intel_dp))
> > drm_err(&dev_priv->drm,
> > "Timed out waiting for ACT sent when disabling\n");
> > drm_dp_check_act_status(&intel_dp->mst_mgr);
> > @@ -443,7 +476,6 @@ static void intel_mst_pre_enable_dp(struct
> > intel_atomic_state *state,
> > struct intel_connector *connector =
> > to_intel_connector(conn_state->connector);
> > int ret;
> > - u32 temp;
> > bool first_mst_stream;
> >
> > /* MST encoders are bound to a crtc, not to a connector,
> > @@ -476,8 +508,8 @@ static void intel_mst_pre_enable_dp(struct
> > intel_atomic_state *state,
> > drm_err(&dev_priv->drm, "failed to allocate vcpi\n");
> >
> > intel_dp->active_mst_links++;
> > - temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_status);
> > - intel_de_write(dev_priv, intel_dp->regs.dp_tp_status, temp);
> > +
> > + clear_act_sent(pipe_config, intel_dp);
> >
> > ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> >
> > @@ -513,9 +545,8 @@ static void intel_mst_enable_dp(struct
> > intel_atomic_state *state,
> > drm_dbg_kms(&dev_priv->drm, "active links %d\n",
> > intel_dp->active_mst_links);
> >
> > - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> > - DP_TP_STATUS_ACT_SENT, 1))
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl+: Fix DP MST ACT status handling
On Thu, Jun 11, 2020 at 06:38:11PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 10, 2020 at 09:31:31PM +0300, Imre Deak wrote:
> > On TGL+ the master transcoder's DP_TP_STATUS register should be used for
> > the MST ACT status handling, so make sure we do that even in case of
> > mulitple streams.
> >
> > This fixes an ACT timeout problem during disabling when using multiple
> > streams. Not sure why this was not a problem during enabling (even the
> > slave's DP_TP_STATUS signaled ACT correctly), but following the spec
> > works in that case too, so let's do that.
> >
> > There is one more place using DP_TP_STATUS, FEC enabling, but I haven't
> > found in BSpec which register to use in that case, so I leave the
> > clarification of that for later.
> >
> > BSpec: 49190
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 47 +
> > 1 file changed, 39 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index d18b406f2a7d..1c3654a117a9 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -316,6 +316,40 @@ intel_dp_mst_atomic_check(struct drm_connector
> > *connector,
> > return ret;
> > }
> >
> > +static i915_reg_t
> > +master_dp_tp_status_reg(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> > +
> > + if (INTEL_GEN(dev_priv) >= 12)
> > + return TGL_DP_TP_STATUS(crtc_state->mst_master_transcoder);
>
> Was going to say this needs a mst check, but then I noticed you're only
> changing the mst paths. So this looks like a partial take on
> https://patchwork.freedesktop.org/patch/364549/?series=76993&rev=2
> Granted, my patch would require the crtc_state plumbing everywhere
> so not really bug fix material.
Yes, this would fix the problem.
> The main question I have is why are regs.dp_tp* not being populated
> correctly? Pretty sure they were supposed to be.
Yea, the real problem is in intel_ddi_get_config() corrupting those
regs. So an alternative would be to fix that instead..
> Also there are a bunch of places where we poke DP_TP_CTL in
> intel_ddi.c. Why aren't those a problem?
Those happened to be correct for the actual port enabling/disabling.
Only the non-primary streams were screwed up after a get_config() call.
I was also a bit confused about which places need the master transcoder
version of the dp_tp regs, since the spec requires this explicitly only
for the ACT sent status check. But I guess we need to use the master
version in all cases.
>
> > +
> > + return intel_dp->regs.dp_tp_status;
> > +}
> > +
> > +static void clear_act_sent(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > + i915_reg_t dp_tp_status_reg =
> > + master_dp_tp_status_reg(crtc_state, intel_dp);
> > +
> > + intel_de_write(i915, dp_tp_status_reg,
> > + intel_de_read(i915, dp_tp_status_reg));
> > +}
> > +
> > +static bool wait_for_act_sent(const struct intel_crtc_state *crtc_state,
> > + const struct intel_dp *intel_dp)
> > +{
> > + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> > + i915_reg_t dp_tp_status_reg =
> > + master_dp_tp_status_reg(crtc_state, intel_dp);
> > +
> > + return intel_de_wait_for_set(i915, dp_tp_status_reg,
> > +DP_TP_STATUS_ACT_SENT, 1) == 0;
> > +}
> > +
> > static void intel_mst_disable_dp(struct intel_atomic_state *state,
> > struct intel_encoder *encoder,
> > const struct intel_crtc_state *old_crtc_state,
> > @@ -376,8 +410,7 @@ static void intel_mst_post_disable_dp(struct
> > intel_atomic_state *state,
> >TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
> >val);
> >
> > - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> > - DP_TP_STATUS_ACT_SENT, 1))
> > + if (!wait_for_act_sent(old_crtc_state, intel_dp))
> > drm_err(&dev_priv->drm,
> > "Timed out waiting for ACT sent when disabling\n");
> > drm_dp_check_act_status(&intel_dp->mst_mgr);
> > @@ -443,7 +476,6 @@ static void intel_mst_pre_enable_dp(struct
> > intel_atomic_state *state,
> > struct intel_connector *connector =
> > to_intel_connector(conn_state->connector);
> > int ret;
> > - u32 temp;
> > bool first_mst_stream;
> >
> > /* MST encoders are bound to a crtc, not to a connector,
> > @@ -476,8 +508,8 @@ static void intel_mst_pre_enable_dp(struct
> > intel_atomic_state *state,
>
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Flush gen3 relocs harder, again
== Series Details ==
Series: drm/i915/gt: Flush gen3 relocs harder, again
URL : https://patchwork.freedesktop.org/series/78230/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c941a56c4805 drm/i915/gt: Flush gen3 relocs harder, again
-:19: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit a889580c087a ("drm/i915: Flush
GPU relocs harder for gen3")'
#19:
References: a889580c087a ("drm/i915: Flush GPU relocs harder for gen3")
total: 1 errors, 0 warnings, 0 checks, 65 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Tighten timestamp around vblank sampling
On Thu, Jun 11, 2020 at 01:30:38PM +0100, Chris Wilson wrote:
> Tighten the timestamp queries before/after the register read so that we
> have less uncertainity for when the read actually took place. This is
> more apt for the older generations where it is not a simple single
> register read. Whether we are able to discern an improvement in our
> sampling accuracy remains to be seen.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
Apart from the code getting a bit uglier can't really think
of any downsides at least. Upsides (if any) I guess we shall
see from the ci reports.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 57 -
> 1 file changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8e823ba25f5f..9c44df8ecce7 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -713,7 +713,9 @@ u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
> * This function will use Framestamp and current
> * timestamp registers to calculate the scanline.
> */
> -static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
> +static u32
> +__intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc,
> + ktime_t *stime, ktime_t *etime)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct drm_vblank_crtc *vblank =
> @@ -737,6 +739,9 @@ static u32
> __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
>* pipe frame time stamp. The time stamp value
>* is sampled at every start of vertical blank.
>*/
> + if (stime)
> + *stime = ktime_get();
> +
> scan_prev_time = intel_de_read_fw(dev_priv,
> PIPE_FRMTMSTMP(crtc->pipe));
>
> @@ -746,6 +751,9 @@ static u32
> __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
>*/
> scan_curr_time = intel_de_read_fw(dev_priv, IVB_TIMESTAMP_CTR);
>
> + if (etime)
> + *etime = ktime_get();
> +
> scan_post_time = intel_de_read_fw(dev_priv,
> PIPE_FRMTMSTMP(crtc->pipe));
> } while (scan_post_time != scan_prev_time);
> @@ -762,7 +770,8 @@ static u32
> __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
> * intel_de_read_fw(), only for fast reads of display block, no need for
> * forcewake etc.
> */
> -static int __intel_get_crtc_scanline(struct intel_crtc *crtc)
> +static int __intel_get_crtc_scanline(struct intel_crtc *crtc,
> + ktime_t *stime, ktime_t *etime)
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -771,23 +780,34 @@ static int __intel_get_crtc_scanline(struct intel_crtc
> *crtc)
> enum pipe pipe = crtc->pipe;
> int position, vtotal;
>
> - if (!crtc->active)
> + if (!crtc->active) {
> + if (stime)
> + *stime = 0;
> + if (etime)
> + *etime = 0;
> return -1;
> + }
>
> vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)];
> mode = &vblank->hwmode;
>
> if (crtc->mode_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP)
> - return __intel_get_crtc_scanline_from_timestamp(crtc);
> + return __intel_get_crtc_scanline_from_timestamp(crtc,
> + stime,
> + etime);
>
> vtotal = mode->crtc_vtotal;
> if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> vtotal /= 2;
>
> + if (stime)
> + *stime = ktime_get();
> if (IS_GEN(dev_priv, 2))
> position = intel_de_read_fw(dev_priv, PIPEDSL(pipe)) &
> DSL_LINEMASK_GEN2;
> else
> position = intel_de_read_fw(dev_priv, PIPEDSL(pipe)) &
> DSL_LINEMASK_GEN3;
> + if (etime)
> + *etime = ktime_get();
>
> /*
>* On HSW, the DSL reg (0x7) appears to return 0 if we
> @@ -806,7 +826,13 @@ static int __intel_get_crtc_scanline(struct intel_crtc
> *crtc)
>
> for (i = 0; i < 100; i++) {
> udelay(1);
> +
> + if (stime)
> + *stime = ktime_get();
> temp = intel_de_read_fw(dev_priv, PIPEDSL(pipe)) &
> DSL_LINEMASK_GEN3;
> + if (etime)
> + *etime = ktime_get();
> +
> if (temp != position) {
> position = temp;
> break;
> @@ -866,21 +892,25 @@ static bool i915_get_crtc_scano
Re: [Intel-gfx] [PATCH v2] drm/vblank: Estimate sample time
On Thu, Jun 11, 2020 at 01:34:47PM +0100, Chris Wilson wrote:
> Since we have a precise start/end time for the sample, the actual time
> the HW was read back is within that interval, and more likely closer to
> the mean of the interval. Use the mean sample time when estimating the
> vblank time.
>
> Signed-off-by: Chris Wilson
Seems reasonable.
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_vblank.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index da7b0b0c1090..a7043d268cca 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -710,15 +710,18 @@ drm_crtc_vblank_helper_get_vblank_timestamp_internal(
> delta_ns = div_s64(100LL * (vpos * mode->crtc_htotal + hpos),
> mode->crtc_clock);
>
> + /* Estimate when the sample was taken */
> + stime += (etime - stime) >> 1;
> +
> /* Subtract time delta from raw timestamp to get final
>* vblank_time timestamp for end of vblank.
>*/
> - *vblank_time = ktime_sub_ns(etime, delta_ns);
> + *vblank_time = ktime_sub_ns(stime, delta_ns);
>
> if (!drm_debug_enabled(DRM_UT_VBL))
> return true;
>
> - ts_etime = ktime_to_timespec64(etime);
> + ts_etime = ktime_to_timespec64(stime);
> ts_vblank_time = ktime_to_timespec64(*vblank_time);
>
> DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %lld.%06ld -> %lld.%06ld [e %d us,
> %d rep]\n",
> --
> 2.27.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] drm/i915/gt: Flush gen3 relocs harder, again
gen3 does not fully flush MI stores to memory on MI_FLUSH, such that a
subsequent read from e.g. the sampler can bypass the store and read the
stale value from memory. This is a serious issue when we are using MI
stores to rewrite the batches for relocation, as it means that the batch
is reading from random user/kernel memory. While it is particularly
sensitive [and detectable] for relocations, reading stale data at any
time is a worry.
Having started with a small number of delaying stores and doubling until
no more incoherency was seen over a few hours (with and without
background memory pressure), 32 was the magic number.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2018
References: a889580c087a ("drm/i915: Flush GPU relocs harder for gen3")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
So gen3 requires a delay after to flush the previous stores, gen5 is
assuming it requires a delay between the seqno and the
MI_USER_INTERRUPT. Here I've made gen5 reuse the gen3 approach, but I
need to verify that it still holds.
---
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 39 +---
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
index 3fb0dc1fb910..342c476ec872 100644
--- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
@@ -142,19 +142,26 @@ int gen4_emit_flush_vcs(struct i915_request *rq, u32 mode)
return 0;
}
-u32 *gen3_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+static u32 *__gen2_emit_breadcrumb(struct i915_request *rq, u32 *cs, int count)
{
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt !=
rq->engine->status_page.vma);
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) !=
I915_GEM_HWS_SEQNO_ADDR);
*cs++ = MI_FLUSH;
+ *cs++ = MI_NOOP;
+
+ while (count--) {
+ *cs++ = MI_STORE_DWORD_INDEX;
+ *cs++ = I915_GEM_HWS_SCRATCH * sizeof(u32);
+ *cs++ = rq->fence.seqno;
+ *cs++ = MI_FLUSH | MI_NO_WRITE_FLUSH;
+ }
*cs++ = MI_STORE_DWORD_INDEX;
*cs++ = I915_GEM_HWS_SEQNO_ADDR;
*cs++ = rq->fence.seqno;
*cs++ = MI_USER_INTERRUPT;
- *cs++ = MI_NOOP;
rq->tail = intel_ring_offset(rq, cs);
assert_ring_tail_valid(rq->ring, rq->tail);
@@ -162,31 +169,15 @@ u32 *gen3_emit_breadcrumb(struct i915_request *rq, u32
*cs)
return cs;
}
-#define GEN5_WA_STORES 8 /* must be at least 1! */
-u32 *gen5_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+u32 *gen3_emit_breadcrumb(struct i915_request *rq, u32 *cs)
{
- int i;
-
- GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt !=
rq->engine->status_page.vma);
-
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) !=
I915_GEM_HWS_SEQNO_ADDR);
-
- *cs++ = MI_FLUSH;
-
- BUILD_BUG_ON(GEN5_WA_STORES < 1);
- for (i = 0; i < GEN5_WA_STORES; i++) {
- *cs++ = MI_STORE_DWORD_INDEX;
- *cs++ = I915_GEM_HWS_SEQNO_ADDR;
- *cs++ = rq->fence.seqno;
- }
-
- *cs++ = MI_USER_INTERRUPT;
-
- rq->tail = intel_ring_offset(rq, cs);
- assert_ring_tail_valid(rq->ring, rq->tail);
+ return __gen2_emit_breadcrumb(rq, cs, 32);
+}
- return cs;
+u32 *gen5_emit_breadcrumb(struct i915_request *rq, u32 *cs)
+{
+ return __gen2_emit_breadcrumb(rq, cs, 8);
}
-#undef GEN5_WA_STORES
/* Just userspace ABI convention to limit the wa batch bo to a resonable size
*/
#define I830_BATCH_LIMIT SZ_256K
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/8] drm/i915/display: Implement infoframes readback for LSPCON
On Thu, Jun 11, 2020 at 06:46:50PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 11, 2020 at 12:42:30AM +0530, Uma Shankar wrote:
> > Implemented Infoframes enabled readback for LSPCON devices.
> > This will help align the implementation with state readback
> > infrastructure.
> >
> > Signed-off-by: Uma Shankar
> > ---
> > drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
> > 1 file changed, 61 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > index 9034ce6f20b9..0ebe9a700291 100644
> > --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> > +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> > @@ -576,11 +576,70 @@ void lspcon_set_infoframes(struct intel_encoder
> > *encoder,
> > buf, ret);
> > }
> >
> > +static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
> > +{
> > + int ret;
> > + u32 val = 0;
> > + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> > +
> > + ret = drm_dp_dpcd_read(aux, reg, &val, 1);
> > + if (ret < 0) {
> > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > + return false;
> > + }
> > +
> > + if (val & LSPCON_MCA_AVI_IF_KICKOFF)
> > + return true;
> > +
> > + return false;
>
> return val & ...;
>
> > +}
> > +
> > +static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux
> > *aux)
> > +{
> > + int ret;
> > + u32 val = 0;
> > + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> > +
> > + ret = drm_dp_dpcd_read(aux, reg, &val, 1);
> > + if (ret < 0) {
> > + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> > + return false;
> > + }
> > +
> > + if (val & LSPCON_PARADE_AVI_IF_KICKOFF)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> > const struct intel_crtc_state *pipe_config)
> > {
> > - /* FIXME actually read this from the hw */
> > - return 0;
> > + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > + bool infoframes_enabled;
> > + u32 mask = 0;
> > + u32 val;
> > +
> > + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> > + infoframes_enabled =
> > _lspcon_read_avi_infoframe_enabled_mca(&intel_dp->aux);
> > + else
> > + infoframes_enabled =
> > _lspcon_read_avi_infoframe_enabled_parade(&intel_dp->aux);
> > +
> > + if (infoframes_enabled)
> > + return true;
>
> This is supposed to return a bitmask of all enabled infoframes.
Actually since we're dealing with both the LSPCON specific stuff and
DIP stuff for the DRM infoframe I think we should stop using using
intel_hdmi_infoframes_enabled(), and instead provide a LSPCON specific
replacement for it. That way we can directly return the abstract
bitmask instead of pretending to return a bitmask of the DIP bits.
>
> Also my question "how do we turn off infoframes once enabled?"
> from https://patchwork.freedesktop.org/patch/351719/?series=72928&rev=1
> still remains unanswered...
>
> > +
> > + if (lspcon->hdr_supported) {
> > + val = intel_de_read(dev_priv,
> > +
> > HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
> > + mask |= VIDEO_DIP_ENABLE_GMP_HSW;
> > +
> > + if (val & mask)
> > + return val & mask;
> > + }
> > +
> > + return false;
> > }
> >
> > void lspcon_resume(struct intel_lspcon *lspcon)
> > --
> > 2.22.0
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v3 6/8] drm/i915/display: Implement infoframes readback for LSPCON
On Thu, Jun 11, 2020 at 12:42:30AM +0530, Uma Shankar wrote:
> Implemented Infoframes enabled readback for LSPCON devices.
> This will help align the implementation with state readback
> infrastructure.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_lspcon.c | 63 -
> 1 file changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
> b/drivers/gpu/drm/i915/display/intel_lspcon.c
> index 9034ce6f20b9..0ebe9a700291 100644
> --- a/drivers/gpu/drm/i915/display/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/display/intel_lspcon.c
> @@ -576,11 +576,70 @@ void lspcon_set_infoframes(struct intel_encoder
> *encoder,
> buf, ret);
> }
>
> +static bool _lspcon_read_avi_infoframe_enabled_mca(struct drm_dp_aux *aux)
> +{
> + int ret;
> + u32 val = 0;
> + u16 reg = LSPCON_MCA_AVI_IF_CTRL;
> +
> + ret = drm_dp_dpcd_read(aux, reg, &val, 1);
> + if (ret < 0) {
> + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> + return false;
> + }
> +
> + if (val & LSPCON_MCA_AVI_IF_KICKOFF)
> + return true;
> +
> + return false;
return val & ...;
> +}
> +
> +static bool _lspcon_read_avi_infoframe_enabled_parade(struct drm_dp_aux *aux)
> +{
> + int ret;
> + u32 val = 0;
> + u16 reg = LSPCON_PARADE_AVI_IF_CTRL;
> +
> + ret = drm_dp_dpcd_read(aux, reg, &val, 1);
> + if (ret < 0) {
> + DRM_ERROR("DPCD read failed, address 0x%x\n", reg);
> + return false;
> + }
> +
> + if (val & LSPCON_PARADE_AVI_IF_KICKOFF)
> + return true;
> +
> + return false;
> +}
> +
> u32 lspcon_infoframes_enabled(struct intel_encoder *encoder,
> const struct intel_crtc_state *pipe_config)
> {
> - /* FIXME actually read this from the hw */
> - return 0;
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_lspcon *lspcon = enc_to_intel_lspcon(encoder);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + bool infoframes_enabled;
> + u32 mask = 0;
> + u32 val;
> +
> + if (lspcon->vendor == LSPCON_VENDOR_MCA)
> + infoframes_enabled =
> _lspcon_read_avi_infoframe_enabled_mca(&intel_dp->aux);
> + else
> + infoframes_enabled =
> _lspcon_read_avi_infoframe_enabled_parade(&intel_dp->aux);
> +
> + if (infoframes_enabled)
> + return true;
This is supposed to return a bitmask of all enabled infoframes.
Also my question "how do we turn off infoframes once enabled?"
from https://patchwork.freedesktop.org/patch/351719/?series=72928&rev=1
still remains unanswered...
> +
> + if (lspcon->hdr_supported) {
> + val = intel_de_read(dev_priv,
> +
> HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
> + mask |= VIDEO_DIP_ENABLE_GMP_HSW;
> +
> + if (val & mask)
> + return val & mask;
> + }
> +
> + return false;
> }
>
> void lspcon_resume(struct intel_lspcon *lspcon)
> --
> 2.22.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl+: Fix DP MST ACT status handling
On Wed, Jun 10, 2020 at 09:31:31PM +0300, Imre Deak wrote:
> On TGL+ the master transcoder's DP_TP_STATUS register should be used for
> the MST ACT status handling, so make sure we do that even in case of
> mulitple streams.
>
> This fixes an ACT timeout problem during disabling when using multiple
> streams. Not sure why this was not a problem during enabling (even the
> slave's DP_TP_STATUS signaled ACT correctly), but following the spec
> works in that case too, so let's do that.
>
> There is one more place using DP_TP_STATUS, FEC enabling, but I haven't
> found in BSpec which register to use in that case, so I leave the
> clarification of that for later.
>
> BSpec: 49190
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 47 +
> 1 file changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d18b406f2a7d..1c3654a117a9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -316,6 +316,40 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> return ret;
> }
>
> +static i915_reg_t
> +master_dp_tp_status_reg(const struct intel_crtc_state *crtc_state,
> + const struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (INTEL_GEN(dev_priv) >= 12)
> + return TGL_DP_TP_STATUS(crtc_state->mst_master_transcoder);
> +
> + return intel_dp->regs.dp_tp_status;
> +}
> +
> +static void clear_act_sent(const struct intel_crtc_state *crtc_state,
> +const struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> + i915_reg_t dp_tp_status_reg =
> + master_dp_tp_status_reg(crtc_state, intel_dp);
> +
> + intel_de_write(i915, dp_tp_status_reg,
> +intel_de_read(i915, dp_tp_status_reg));
Followup material:
Should we actually just clear the bit(s) we care about? No idea what
other stuff is in there.
> +}
> +
> +static bool wait_for_act_sent(const struct intel_crtc_state *crtc_state,
> + const struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> + i915_reg_t dp_tp_status_reg =
> + master_dp_tp_status_reg(crtc_state, intel_dp);
> +
> + return intel_de_wait_for_set(i915, dp_tp_status_reg,
> + DP_TP_STATUS_ACT_SENT, 1) == 0;
> +}
> +
> static void intel_mst_disable_dp(struct intel_atomic_state *state,
>struct intel_encoder *encoder,
>const struct intel_crtc_state *old_crtc_state,
> @@ -376,8 +410,7 @@ static void intel_mst_post_disable_dp(struct
> intel_atomic_state *state,
> TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
> val);
>
> - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> - DP_TP_STATUS_ACT_SENT, 1))
> + if (!wait_for_act_sent(old_crtc_state, intel_dp))
> drm_err(&dev_priv->drm,
> "Timed out waiting for ACT sent when disabling\n");
> drm_dp_check_act_status(&intel_dp->mst_mgr);
> @@ -443,7 +476,6 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> int ret;
> - u32 temp;
> bool first_mst_stream;
>
> /* MST encoders are bound to a crtc, not to a connector,
> @@ -476,8 +508,8 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> drm_err(&dev_priv->drm, "failed to allocate vcpi\n");
>
> intel_dp->active_mst_links++;
> - temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_status);
> - intel_de_write(dev_priv, intel_dp->regs.dp_tp_status, temp);
> +
> + clear_act_sent(pipe_config, intel_dp);
>
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
>
> @@ -513,9 +545,8 @@ static void intel_mst_enable_dp(struct intel_atomic_state
> *state,
> drm_dbg_kms(&dev_priv->drm, "active links %d\n",
> intel_dp->active_mst_links);
>
> - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> - DP_TP_STATUS_ACT_SENT, 1))
> - drm_err(&dev_priv->drm, "Timed out waiting for ACT sent\n");
> + if (!wait_for_act_sent(pipe_config, intel_dp))
> + drm_err(&dev_priv->drm, "Timed out waiting for ACT sent when
> enabling\n");
>
> drm_dp_check_act_status(&intel_dp->mst_mgr);
>
> --
> 2.23.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.free
Re: [Intel-gfx] [PATCH 1/2] drm/i915/tgl+: Fix DP MST ACT status handling
On Wed, Jun 10, 2020 at 09:31:31PM +0300, Imre Deak wrote:
> On TGL+ the master transcoder's DP_TP_STATUS register should be used for
> the MST ACT status handling, so make sure we do that even in case of
> mulitple streams.
>
> This fixes an ACT timeout problem during disabling when using multiple
> streams. Not sure why this was not a problem during enabling (even the
> slave's DP_TP_STATUS signaled ACT correctly), but following the spec
> works in that case too, so let's do that.
>
> There is one more place using DP_TP_STATUS, FEC enabling, but I haven't
> found in BSpec which register to use in that case, so I leave the
> clarification of that for later.
>
> BSpec: 49190
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 47 +
> 1 file changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index d18b406f2a7d..1c3654a117a9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -316,6 +316,40 @@ intel_dp_mst_atomic_check(struct drm_connector
> *connector,
> return ret;
> }
>
> +static i915_reg_t
> +master_dp_tp_status_reg(const struct intel_crtc_state *crtc_state,
> + const struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
> +
> + if (INTEL_GEN(dev_priv) >= 12)
> + return TGL_DP_TP_STATUS(crtc_state->mst_master_transcoder);
Was going to say this needs a mst check, but then I noticed you're only
changing the mst paths. So this looks like a partial take on
https://patchwork.freedesktop.org/patch/364549/?series=76993&rev=2
Granted, my patch would require the crtc_state plumbing everywhere
so not really bug fix material.
The main question I have is why are regs.dp_tp* not being populated
correctly? Pretty sure they were supposed to be.
Also there are a bunch of places where we poke DP_TP_CTL in
intel_ddi.c. Why aren't those a problem?
> +
> + return intel_dp->regs.dp_tp_status;
> +}
> +
> +static void clear_act_sent(const struct intel_crtc_state *crtc_state,
> +const struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> + i915_reg_t dp_tp_status_reg =
> + master_dp_tp_status_reg(crtc_state, intel_dp);
> +
> + intel_de_write(i915, dp_tp_status_reg,
> +intel_de_read(i915, dp_tp_status_reg));
> +}
> +
> +static bool wait_for_act_sent(const struct intel_crtc_state *crtc_state,
> + const struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
> + i915_reg_t dp_tp_status_reg =
> + master_dp_tp_status_reg(crtc_state, intel_dp);
> +
> + return intel_de_wait_for_set(i915, dp_tp_status_reg,
> + DP_TP_STATUS_ACT_SENT, 1) == 0;
> +}
> +
> static void intel_mst_disable_dp(struct intel_atomic_state *state,
>struct intel_encoder *encoder,
>const struct intel_crtc_state *old_crtc_state,
> @@ -376,8 +410,7 @@ static void intel_mst_post_disable_dp(struct
> intel_atomic_state *state,
> TRANS_DDI_FUNC_CTL(old_crtc_state->cpu_transcoder),
> val);
>
> - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> - DP_TP_STATUS_ACT_SENT, 1))
> + if (!wait_for_act_sent(old_crtc_state, intel_dp))
> drm_err(&dev_priv->drm,
> "Timed out waiting for ACT sent when disabling\n");
> drm_dp_check_act_status(&intel_dp->mst_mgr);
> @@ -443,7 +476,6 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> struct intel_connector *connector =
> to_intel_connector(conn_state->connector);
> int ret;
> - u32 temp;
> bool first_mst_stream;
>
> /* MST encoders are bound to a crtc, not to a connector,
> @@ -476,8 +508,8 @@ static void intel_mst_pre_enable_dp(struct
> intel_atomic_state *state,
> drm_err(&dev_priv->drm, "failed to allocate vcpi\n");
>
> intel_dp->active_mst_links++;
> - temp = intel_de_read(dev_priv, intel_dp->regs.dp_tp_status);
> - intel_de_write(dev_priv, intel_dp->regs.dp_tp_status, temp);
> +
> + clear_act_sent(pipe_config, intel_dp);
>
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
>
> @@ -513,9 +545,8 @@ static void intel_mst_enable_dp(struct intel_atomic_state
> *state,
> drm_dbg_kms(&dev_priv->drm, "active links %d\n",
> intel_dp->active_mst_links);
>
> - if (intel_de_wait_for_set(dev_priv, intel_dp->regs.dp_tp_status,
> - DP_TP_STATUS_ACT_SENT, 1))
> - drm_err(&dev
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
On Thu, Jun 11, 2020 at 4:29 PM Tvrtko Ursulin wrote: > > > On 11/06/2020 12:29, Daniel Vetter wrote: > > On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin > > wrote: > >> On 10/06/2020 16:17, Daniel Vetter wrote: > >>> On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > >>> wrote: > > > On 04/06/2020 09:12, Daniel Vetter wrote: > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > > this explicit annotation can be more liberally sprinkled around. > > With read locks lockdep isn't going to complain if the read-side > > isn't nested the same way under all circumstances, so ABBA > > deadlocks > > are ok. Which they are, since this is an annotation only. > > > > - We're using non-recursive lockdep read lock mode, since in recursive > > read lock mode lockdep does not catch read side hazards. And we > > _very_ much want read side hazards to be caught. For full details > > of > > this limitation see > > > > commit e91498589746065e3ae95d9a00b068e525eec34f > > Author: Peter Zijlstra > > Date: Wed Aug 23 13:13:11 2017 +0200 > > > > locking/lockdep/selftests: Add mixed read-write ABBA tests > > > > - To allow nesting of the read-side explicit annotations we explicitly > > keep track of the nesting. lock_is_held() allows us to do that. > > > > - The wait-side annotation is a write lock, and entirely done within > > dma_fence_wait() for everyone by default. > > > > - To be able to freely annotate helper functions I want to make it ok > > to call dma_fence_begin/end_signalling from soft/hardirq context. > > First attempt was using the hardirq locking context for the write > > side in lockdep, but this forces all normal spinlocks nested within > > dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > > > The approach now is to simple check in_atomic(), and for these > > cases > > entirely rely on the might_sleep() check in dma_fence_wait(). That > > will catch any wrong nesting against spinlocks from soft/hardirq > > contexts. > > > > The idea here is that every code path that's critical for eventually > > signalling a dma_fence should be annotated with > > dma_fence_begin/end_signalling. The annotation ideally starts right > > after a dma_fence is published (added to a dma_resv, exposed as a > > sync_file fd, attached to a drm_syncobj fd, or anything else that > > makes the dma_fence visible to other kernel threads), up to and > > including the dma_fence_wait(). Examples are irq handlers, the > > scheduler rt threads, the tail of execbuf (after the corresponding > > fences are visible), any workers that end up signalling dma_fences and > > really anything else. Not annotated should be code paths that only > > complete fences opportunistically as the gpu progresses, like e.g. > > shrinker/eviction code. > > > > The main class of deadlocks this is supposed to catch are: > > > > Thread A: > > > > mutex_lock(A); > > mutex_unlock(A); > > > > dma_fence_signal(); > > > > Thread B: > > > > mutex_lock(A); > > dma_fence_wait(); > > mutex_unlock(A); > > > > Thread B is blocked on A signalling the fence, but A never gets around > > to that because it cannot acquire the lock A. > > > > Note that dma_fence_wait() is allowed to be nested within > > dma_fence_begin/end_signalling sections. To allow this to happen the > > read lock needs to be upgraded to a write lock, which means that any > > other lock is acquired between the dma_fence_begin_signalling() call and > > the call to dma_fence_wait(), and still held, this will result in an > > immediate lockdep complaint. The only other option would be to not > > annotate such calls, defeating the point. Therefore these annotations > > cannot be sprinkled over the code entirely mindless to avoid false > > positives. > > > > v2: handle soft/hardirq ctx better against write side and dont forget > > EXPORT_SYMBOL, drivers can't use this otherwise. > > > > v3: Kerneldoc. > > > > v4: Some spelling fixes from Mika > > > > Cc: Mika Kuoppala > > Cc: Thomas Hellstrom > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: linux-r...@vger.kernel.org > > Cc: amd-...@lists.freedesktop.org > > Cc: intel-gfx@lists.freedesktop.org > > Cc: Chris Wilson > > Cc: Maarten Lankhorst > > Cc: Christian König > > Signed-off-by: Daniel Vetter > > --- > > Documentation/driver-api/dm
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
On 11/06/2020 12:29, Daniel Vetter wrote: > On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin > wrote: >> On 10/06/2020 16:17, Daniel Vetter wrote: >>> On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin >>> wrote: On 04/06/2020 09:12, Daniel Vetter wrote: > Design is similar to the lockdep annotations for workers, but with > some twists: > > - We use a read-lock for the execution/worker/completion side, so that > this explicit annotation can be more liberally sprinkled around. > With read locks lockdep isn't going to complain if the read-side > isn't nested the same way under all circumstances, so ABBA deadlocks > are ok. Which they are, since this is an annotation only. > > - We're using non-recursive lockdep read lock mode, since in recursive > read lock mode lockdep does not catch read side hazards. And we > _very_ much want read side hazards to be caught. For full details of > this limitation see > > commit e91498589746065e3ae95d9a00b068e525eec34f > Author: Peter Zijlstra > Date: Wed Aug 23 13:13:11 2017 +0200 > > locking/lockdep/selftests: Add mixed read-write ABBA tests > > - To allow nesting of the read-side explicit annotations we explicitly > keep track of the nesting. lock_is_held() allows us to do that. > > - The wait-side annotation is a write lock, and entirely done within > dma_fence_wait() for everyone by default. > > - To be able to freely annotate helper functions I want to make it ok > to call dma_fence_begin/end_signalling from soft/hardirq context. > First attempt was using the hardirq locking context for the write > side in lockdep, but this forces all normal spinlocks nested within > dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > The approach now is to simple check in_atomic(), and for these cases > entirely rely on the might_sleep() check in dma_fence_wait(). That > will catch any wrong nesting against spinlocks from soft/hardirq > contexts. > > The idea here is that every code path that's critical for eventually > signalling a dma_fence should be annotated with > dma_fence_begin/end_signalling. The annotation ideally starts right > after a dma_fence is published (added to a dma_resv, exposed as a > sync_file fd, attached to a drm_syncobj fd, or anything else that > makes the dma_fence visible to other kernel threads), up to and > including the dma_fence_wait(). Examples are irq handlers, the > scheduler rt threads, the tail of execbuf (after the corresponding > fences are visible), any workers that end up signalling dma_fences and > really anything else. Not annotated should be code paths that only > complete fences opportunistically as the gpu progresses, like e.g. > shrinker/eviction code. > > The main class of deadlocks this is supposed to catch are: > > Thread A: > > mutex_lock(A); > mutex_unlock(A); > > dma_fence_signal(); > > Thread B: > > mutex_lock(A); > dma_fence_wait(); > mutex_unlock(A); > > Thread B is blocked on A signalling the fence, but A never gets around > to that because it cannot acquire the lock A. > > Note that dma_fence_wait() is allowed to be nested within > dma_fence_begin/end_signalling sections. To allow this to happen the > read lock needs to be upgraded to a write lock, which means that any > other lock is acquired between the dma_fence_begin_signalling() call and > the call to dma_fence_wait(), and still held, this will result in an > immediate lockdep complaint. The only other option would be to not > annotate such calls, defeating the point. Therefore these annotations > cannot be sprinkled over the code entirely mindless to avoid false > positives. > > v2: handle soft/hardirq ctx better against write side and dont forget > EXPORT_SYMBOL, drivers can't use this otherwise. > > v3: Kerneldoc. > > v4: Some spelling fixes from Mika > > Cc: Mika Kuoppala > Cc: Thomas Hellstrom > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König > Signed-off-by: Daniel Vetter > --- > Documentation/driver-api/dma-buf.rst | 12 +- > drivers/dma-buf/dma-fence.c | 161 +++ > include/linux/dma-fence.h| 12 ++ > 3 files changed, 182 insertions(+), 3 deletions(-) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentati
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/vblank: Estimate sample time (rev2)
== Series Details ==
Series: series starting with [v2] drm/vblank: Estimate sample time (rev2)
URL : https://patchwork.freedesktop.org/series/78223/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8617 -> Patchwork_17927
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17927:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-kbl-7560u}: [FAIL][1] ([i915#1569] / [i915#192] / [i915#193] /
[i915#194]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-kbl-7560u/igt@run...@aborted.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-kbl-7560u/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_17927 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-kbl-soraka: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-kbl-soraka/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-whl-u: [PASS][5] -> [DMESG-WARN][6] ([i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-whl-u/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92] /
[i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-byt-j1900: [PASS][9] -> [DMESG-WARN][10] ([i915#1982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-byt-j1900/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [PASS][11] -> [DMESG-WARN][12] ([i915#1982])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-u2: [FAIL][13] ([i915#1888]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-tgl-u2/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [INCOMPLETE][17] ([i915#1932]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-cml-s: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8617/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17927/fi-cml-s/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][23] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][24] ([i915#62] /
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds (rev2)
== Series Details ==
Series: series starting with drm/i915/gt: Move hsw GT workarounds from
init_clock_gating to workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/78214/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8614_full -> Patchwork_17926_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17926_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17926_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_17926_full:
### IGT changes ###
Possible regressions
* igt@gem_mmap_gtt@fault-concurrent:
- shard-iclb: [PASS][1] -> [CRASH][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/shard-iclb1/igt@gem_mmap_...@fault-concurrent.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/shard-iclb8/igt@gem_mmap_...@fault-concurrent.html
### Piglit changes ###
Possible regressions
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-bitand-neg-uint-uint
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][3] +5 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/pig-icl-1065g7/spec@arb_tessellation_shader@execution@built-in-functi...@tcs-op-bitand-neg-uint-uint.html
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-div-float-vec4
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/pig-icl-1065g7/spec@arb_tessellation_shader@execution@built-in-functi...@tcs-op-div-float-vec4.html
New tests
-
New tests have been introduced between CI_DRM_8614_full and
Patchwork_17926_full:
### New Piglit tests (8) ###
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-assign-bitand-ivec3-ivec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-assign-bitor-int-int:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-bitand-neg-uint-uint:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-bitxor-neg-ivec3-ivec3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-bitxor-not-int-ivec2:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-div-float-vec4:
- Statuses : 1 crash(s)
- Exec time: [0.28] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-op-mult-mat3-mat4x3:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@arb_tessellation_shader@execution@built-in-functions@tcs-step-float-vec2:
- Statuses : 1 crash(s)
- Exec time: [0.26] s
Known issues
Here are the changes found in Patchwork_17926_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process@vcs1:
- shard-tglb: [PASS][5] -> [FAIL][6] ([i915#1528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/shard-tglb5/igt@gem_ctx_persistence@engines-mixed-proc...@vcs1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/shard-tglb2/igt@gem_ctx_persistence@engines-mixed-proc...@vcs1.html
* igt@gem_exec_reloc@basic-concurrent0:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#1930])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/shard-glk6/igt@gem_exec_re...@basic-concurrent0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/shard-glk2/igt@gem_exec_re...@basic-concurrent0.html
* igt@gem_fence_thrash@bo-write-verify-y:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#93] / [i915#95])
+1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/shard-kbl3/igt@gem_fence_thr...@bo-write-verify-y.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/shard-kbl6/igt@gem_fence_thr...@bo-write-verify-y.html
* igt@kms_addfb_basic@bad-pitch-32:
- shard-snb: [PASS][11] -> [TIMEOUT][12] ([i915#1958]) +1 similar
issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/shard-snb2/igt@kms_addfb_ba...@bad-pitch-32.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/shard-snb4/igt@kms_addfb_ba...@bad-pitch-32.html
* igt@kms_atomic@atomic-invalid-params:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#95])
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/dp_mst: Fix the DDC I2C device unregistration of an MST port (rev2)
On Thu, Jun 11, 2020 at 08:46:16AM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/3] drm/dp_mst: Fix the DDC I2C device
> unregistration of an MST port (rev2)
> URL : https://patchwork.freedesktop.org/series/78100/
> State : success
Thanks for the review, the patchset is pushed to drm-misc-next.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8608_full -> Patchwork_17919_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_17919_full:
>
> ### Piglit changes ###
>
> Possible regressions
>
> *
> spec@glsl-4.20@execution@conversion@frag-conversion-implicit-mat4-dmat4-zero-sign
> (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][1]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/pig-icl-1065g7/spec@glsl-4.20@execution@convers...@frag-conversion-implicit-mat4-dmat4-zero-sign.html
>
> *
> spec@glsl-4.20@execution@conversion@vert-conversion-implicit-mat3-dmat3-zero-sign
> (NEW):
> - {pig-icl-1065g7}: NOTRUN -> [CRASH][2] +4 similar issues
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/pig-icl-1065g7/spec@glsl-4.20@execution@convers...@vert-conversion-implicit-mat3-dmat3-zero-sign.html
>
>
> New tests
> -
>
> New tests have been introduced between CI_DRM_8608_full and
> Patchwork_17919_full:
>
> ### New Piglit tests (6) ###
>
> * spec@glsl-4.00@execution@built-in-functions@gs-op-div-dmat4x3-dmat4x3:
> - Statuses : 1 crash(s)
> - Exec time: [98.33] s
>
> *
> spec@glsl-4.20@execution@conversion@frag-conversion-implicit-mat4-dmat4-zero-sign:
> - Statuses : 1 incomplete(s)
> - Exec time: [0.0] s
>
> *
> spec@glsl-4.20@execution@conversion@geom-conversion-implicit-mat3-dmat3-zero-sign:
> - Statuses : 1 crash(s)
> - Exec time: [15.54] s
>
> *
> spec@glsl-4.20@execution@conversion@geom-conversion-implicit-mat4-dmat4-zero-sign:
> - Statuses : 1 crash(s)
> - Exec time: [57.24] s
>
> *
> spec@glsl-4.20@execution@conversion@vert-conversion-implicit-mat3-dmat3-zero-sign:
> - Statuses : 1 crash(s)
> - Exec time: [3.59] s
>
> *
> spec@glsl-4.20@execution@conversion@vert-conversion-implicit-mat3x4-dmat3x4-zero-sign:
> - Statuses : 1 crash(s)
> - Exec time: [25.06] s
>
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_17919_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_schedule@implicit-boths@bcs0:
> - shard-snb: [PASS][3] -> [INCOMPLETE][4] ([i915#82])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-snb4/igt@gem_exec_schedule@implicit-bo...@bcs0.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-snb2/igt@gem_exec_schedule@implicit-bo...@bcs0.html
>
> * igt@gem_exec_suspend@basic-s3:
> - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] /
> [i915#95]) +3 similar issues
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-kbl6/igt@gem_exec_susp...@basic-s3.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-kbl2/igt@gem_exec_susp...@basic-s3.html
>
> * igt@gem_exec_whisper@basic-forked-all:
> - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] /
> [i915#95])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-glk4/igt@gem_exec_whis...@basic-forked-all.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
>
> * igt@i915_suspend@sysfs-reader:
> - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69])
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-skl2/igt@i915_susp...@sysfs-reader.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-skl6/igt@i915_susp...@sysfs-reader.html
>
> * igt@kms_big_fb@y-tiled-64bpp-rotate-0:
> - shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] /
> [i915#95])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html
>
> * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen:
> - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#95]) +16
> similar issues
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
> - shard-kbl: [PASS][15] ->
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RESEND,v3,1/3] drm/i915/dp_mst: Fix disabling MST on a port (rev6)
On Fri, Jun 05, 2020 at 01:53:52PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [RESEND,v3,1/3] drm/i915/dp_mst: Fix disabling > MST on a port (rev6) > URL : https://patchwork.freedesktop.org/series/77969/ > State : success Thanks for the reviews, pushed patch 1 to -dinq and patches 2,3 to drm-misc-next. > > == Summary == > > CI Bug Log - changes from CI_DRM_8590_full -> Patchwork_17882_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_17882_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_whisper@basic-forked-all: > - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / > [i915#95]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-glk7/igt@gem_exec_whis...@basic-forked-all.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-glk2/igt@gem_exec_whis...@basic-forked-all.html > > * igt@gem_mmap_gtt@cpuset-big-copy-odd: > - shard-iclb: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-iclb6/igt@gem_mmap_...@cpuset-big-copy-odd.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-iclb2/igt@gem_mmap_...@cpuset-big-copy-odd.html > > * igt@gem_workarounds@suspend-resume: > - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-apl2/igt@gem_workarou...@suspend-resume.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-apl1/igt@gem_workarou...@suspend-resume.html > > * igt@kms_big_fb@linear-32bpp-rotate-180: > - shard-skl: [PASS][7] -> [DMESG-WARN][8] ([i915#1982]) +9 > similar issues >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-skl6/igt@kms_big...@linear-32bpp-rotate-180.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-skl5/igt@kms_big...@linear-32bpp-rotate-180.html > > * igt@kms_big_fb@linear-64bpp-rotate-180: > - shard-glk: [PASS][9] -> [DMESG-FAIL][10] ([i915#118] / > [i915#95]) +1 similar issue >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-glk2/igt@kms_big...@linear-64bpp-rotate-180.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html > > * igt@kms_big_fb@x-tiled-16bpp-rotate-0: > - shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#1982]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-glk5/igt@kms_big...@x-tiled-16bpp-rotate-0.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-glk4/igt@kms_big...@x-tiled-16bpp-rotate-0.html > > * igt@kms_cursor_crc@pipe-c-cursor-256x85-offscreen: > - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#95]) +17 > similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-apl8/igt@kms_cursor_...@pipe-c-cursor-256x85-offscreen.html > > * igt@kms_cursor_crc@pipe-c-cursor-suspend: > - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +4 > similar issues >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-kbl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html > > * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled: > - shard-snb: [PASS][17] -> [TIMEOUT][18] ([i915#1958]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-snb6/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-snb1/igt@kms_draw_...@draw-method-rgb565-mmap-gtt-xtiled.html > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move: > - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#93] / > [i915#95]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-kbl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17882/shard-kbl1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html > > * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-cpu: > - shard-skl: [PASS][21] -> [FAIL][22] ([i915#49]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8590/shard-skl9/igt@kms_frontbuffer_track...@psr-rgb101010-draw-mmap-cpu.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Tighten timestamp around vblank sampling
Quoting Chris Wilson (2020-06-11 13:30:38)
> Tighten the timestamp queries before/after the register read so that we
> have less uncertainity for when the read actually took place. This is
> more apt for the older generations where it is not a simple single
> register read. Whether we are able to discern an improvement in our
> sampling accuracy remains to be seen.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_irq.c | 57 -
> 1 file changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8e823ba25f5f..9c44df8ecce7 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -713,7 +713,9 @@ u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
> * This function will use Framestamp and current
> * timestamp registers to calculate the scanline.
> */
> -static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
> +static u32
> +__intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc,
> +ktime_t *stime, ktime_t *etime)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct drm_vblank_crtc *vblank =
> @@ -737,6 +739,9 @@ static u32
> __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
> * pipe frame time stamp. The time stamp value
> * is sampled at every start of vertical blank.
> */
> + if (stime)
> + *stime = ktime_get();
> +
> scan_prev_time = intel_de_read_fw(dev_priv,
> PIPE_FRMTMSTMP(crtc->pipe));
>
> @@ -746,6 +751,9 @@ static u32
> __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
> */
> scan_curr_time = intel_de_read_fw(dev_priv,
> IVB_TIMESTAMP_CTR);
>
> + if (etime)
> + *etime = ktime_get();
I guess with PREEMPT_RT and sleeping spinlocks, these timestamps +
intel_de_read_fw deserve to be within preempt_disable().
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/vblank: Estimate sample time
Since we have a precise start/end time for the sample, the actual time
the HW was read back is within that interval, and more likely closer to
the mean of the interval. Use the mean sample time when estimating the
vblank time.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_vblank.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index da7b0b0c1090..a7043d268cca 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -710,15 +710,18 @@ drm_crtc_vblank_helper_get_vblank_timestamp_internal(
delta_ns = div_s64(100LL * (vpos * mode->crtc_htotal + hpos),
mode->crtc_clock);
+ /* Estimate when the sample was taken */
+ stime += (etime - stime) >> 1;
+
/* Subtract time delta from raw timestamp to get final
* vblank_time timestamp for end of vblank.
*/
- *vblank_time = ktime_sub_ns(etime, delta_ns);
+ *vblank_time = ktime_sub_ns(stime, delta_ns);
if (!drm_debug_enabled(DRM_UT_VBL))
return true;
- ts_etime = ktime_to_timespec64(etime);
+ ts_etime = ktime_to_timespec64(stime);
ts_vblank_time = ktime_to_timespec64(*vblank_time);
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %lld.%06ld -> %lld.%06ld [e %d us,
%d rep]\n",
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/vblank: Estimate sample time
Quoting Chris Wilson (2020-06-11 13:30:37) > Since we have a precise start/end time for the sample, the actual time > the HW was read back is within that interval, and more likely closer to > the mean of the interval. Use the mean sample time when estimating the > vblank time. > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/drm_vblank.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c > index da7b0b0c1090..79a5461d3773 100644 > --- a/drivers/gpu/drm/drm_vblank.c > +++ b/drivers/gpu/drm/drm_vblank.c > @@ -710,15 +710,18 @@ drm_crtc_vblank_helper_get_vblank_timestamp_internal( > delta_ns = div_s64(100LL * (vpos * mode->crtc_htotal + hpos), >mode->crtc_clock); > > + /* Estimate when the sample was taken */ > + stime += (etime - stime) >> 2; /2 != >>2 -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Tighten timestamp around vblank sampling
Tighten the timestamp queries before/after the register read so that we
have less uncertainity for when the read actually took place. This is
more apt for the older generations where it is not a simple single
register read. Whether we are able to discern an improvement in our
sampling accuracy remains to be seen.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 57 -
1 file changed, 42 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8e823ba25f5f..9c44df8ecce7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -713,7 +713,9 @@ u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
* This function will use Framestamp and current
* timestamp registers to calculate the scanline.
*/
-static u32 __intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
+static u32
+__intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc,
+ktime_t *stime, ktime_t *etime)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct drm_vblank_crtc *vblank =
@@ -737,6 +739,9 @@ static u32 __intel_get_crtc_scanline_from_timestamp(struct
intel_crtc *crtc)
* pipe frame time stamp. The time stamp value
* is sampled at every start of vertical blank.
*/
+ if (stime)
+ *stime = ktime_get();
+
scan_prev_time = intel_de_read_fw(dev_priv,
PIPE_FRMTMSTMP(crtc->pipe));
@@ -746,6 +751,9 @@ static u32 __intel_get_crtc_scanline_from_timestamp(struct
intel_crtc *crtc)
*/
scan_curr_time = intel_de_read_fw(dev_priv, IVB_TIMESTAMP_CTR);
+ if (etime)
+ *etime = ktime_get();
+
scan_post_time = intel_de_read_fw(dev_priv,
PIPE_FRMTMSTMP(crtc->pipe));
} while (scan_post_time != scan_prev_time);
@@ -762,7 +770,8 @@ static u32 __intel_get_crtc_scanline_from_timestamp(struct
intel_crtc *crtc)
* intel_de_read_fw(), only for fast reads of display block, no need for
* forcewake etc.
*/
-static int __intel_get_crtc_scanline(struct intel_crtc *crtc)
+static int __intel_get_crtc_scanline(struct intel_crtc *crtc,
+ktime_t *stime, ktime_t *etime)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -771,23 +780,34 @@ static int __intel_get_crtc_scanline(struct intel_crtc
*crtc)
enum pipe pipe = crtc->pipe;
int position, vtotal;
- if (!crtc->active)
+ if (!crtc->active) {
+ if (stime)
+ *stime = 0;
+ if (etime)
+ *etime = 0;
return -1;
+ }
vblank = &crtc->base.dev->vblank[drm_crtc_index(&crtc->base)];
mode = &vblank->hwmode;
if (crtc->mode_flags & I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP)
- return __intel_get_crtc_scanline_from_timestamp(crtc);
+ return __intel_get_crtc_scanline_from_timestamp(crtc,
+ stime,
+ etime);
vtotal = mode->crtc_vtotal;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
vtotal /= 2;
+ if (stime)
+ *stime = ktime_get();
if (IS_GEN(dev_priv, 2))
position = intel_de_read_fw(dev_priv, PIPEDSL(pipe)) &
DSL_LINEMASK_GEN2;
else
position = intel_de_read_fw(dev_priv, PIPEDSL(pipe)) &
DSL_LINEMASK_GEN3;
+ if (etime)
+ *etime = ktime_get();
/*
* On HSW, the DSL reg (0x7) appears to return 0 if we
@@ -806,7 +826,13 @@ static int __intel_get_crtc_scanline(struct intel_crtc
*crtc)
for (i = 0; i < 100; i++) {
udelay(1);
+
+ if (stime)
+ *stime = ktime_get();
temp = intel_de_read_fw(dev_priv, PIPEDSL(pipe)) &
DSL_LINEMASK_GEN3;
+ if (etime)
+ *etime = ktime_get();
+
if (temp != position) {
position = temp;
break;
@@ -866,21 +892,25 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc
*_crtc,
/* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */
- /* Get optional system timestamp before query. */
- if (stime)
- *stime = ktime_get();
-
if (use_scanline_counter) {
/* No obvious pixelcount register. Only query vertical
[Intel-gfx] [PATCH 1/2] drm/vblank: Estimate sample time
Since we have a precise start/end time for the sample, the actual time
the HW was read back is within that interval, and more likely closer to
the mean of the interval. Use the mean sample time when estimating the
vblank time.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_vblank.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index da7b0b0c1090..79a5461d3773 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -710,15 +710,18 @@ drm_crtc_vblank_helper_get_vblank_timestamp_internal(
delta_ns = div_s64(100LL * (vpos * mode->crtc_htotal + hpos),
mode->crtc_clock);
+ /* Estimate when the sample was taken */
+ stime += (etime - stime) >> 2;
+
/* Subtract time delta from raw timestamp to get final
* vblank_time timestamp for end of vblank.
*/
- *vblank_time = ktime_sub_ns(etime, delta_ns);
+ *vblank_time = ktime_sub_ns(stime, delta_ns);
if (!drm_debug_enabled(DRM_UT_VBL))
return true;
- ts_etime = ktime_to_timespec64(etime);
+ ts_etime = ktime_to_timespec64(stime);
ts_vblank_time = ktime_to_timespec64(*vblank_time);
DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %lld.%06ld -> %lld.%06ld [e %d us,
%d rep]\n",
--
2.27.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HDR on MCA LSPCON based Gen9 devices (rev3)
== Series Details == Series: Enable HDR on MCA LSPCON based Gen9 devices (rev3) URL : https://patchwork.freedesktop.org/series/68081/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8611_full -> Patchwork_17922_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17922_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17922_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_17922_full: ### IGT changes ### Possible regressions * igt@runner@aborted: - shard-kbl: NOTRUN -> ([FAIL][1], [FAIL][2], [FAIL][3], [FAIL][4], [FAIL][5]) ([i915#1569] / [i915#1611] / [i915#1687] / [i915#192] / [i915#193] / [i915#194]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-kbl4/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-kbl4/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-kbl4/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-kbl4/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-kbl4/igt@run...@aborted.html - shard-apl: NOTRUN -> ([FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10]) ([fdo#109271] / [i915#1610] / [i915#1611]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl1/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl4/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl1/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl4/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17922_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#1528]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@gem_workarounds@suspend-resume: - shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([i915#155] / [i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-kbl3/igt@gem_workarou...@suspend-resume.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-kbl4/igt@gem_workarou...@suspend-resume.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][15] -> [DMESG-WARN][16] ([i915#1436] / [i915#716]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk9/igt@gen9_exec_pa...@allowed-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-glk7/igt@gen9_exec_pa...@allowed-all.html * igt@i915_module_load@reload: - shard-tglb: [PASS][17] -> [DMESG-WARN][18] ([i915#402]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-tglb3/igt@i915_module_l...@reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-tglb1/igt@i915_module_l...@reload.html * igt@i915_pm_rc6_residency@rc6-fence: - shard-hsw: [PASS][19] -> [WARN][20] ([i915#1519]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-hsw6/igt@i915_pm_rc6_reside...@rc6-fence.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][21] -> [INCOMPLETE][22] ([i915#180]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl1/igt@i915_susp...@sysfs-reader.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl4/igt@i915_susp...@sysfs-reader.html * igt@kms_atomic@atomic-invalid-params: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#95]) +11 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl8/igt@kms_ato...@atomic-invalid-params.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17922/shard-apl7/igt@kms_ato...@atomic-invalid-params.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-apl: [PASS][25] -> [DMESG-WARN][26] ([i915#1982]) [25]:
Re: [Intel-gfx] [PATCH 57/59] drm/ast: Use managed pci functions
Hi
Am 15.04.20 um 09:40 schrieb Daniel Vetter:
> Allows us to remove a bit of cleanup code.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: Emil Velikov
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: "Christian König"
> Cc: "Y.C. Chen"
Reviewed-by: Thomas Zimmermann
Thanks for answering my questions. Sorry for never getting back to it.
Best regards
Thomas
> ---
> drivers/gpu/drm/ast/ast_drv.c | 10 +++---
> drivers/gpu/drm/ast/ast_main.c | 3 ---
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
> index b7ba22dddcad..48a9cc4e080a 100644
> --- a/drivers/gpu/drm/ast/ast_drv.c
> +++ b/drivers/gpu/drm/ast/ast_drv.c
> @@ -91,15 +91,13 @@ static int ast_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
>
> ast_kick_out_firmware_fb(pdev);
>
> - ret = pci_enable_device(pdev);
> + ret = pcim_enable_device(pdev);
> if (ret)
> return ret;
>
> dev = drm_dev_alloc(&driver, &pdev->dev);
> - if (IS_ERR(dev)) {
> - ret = PTR_ERR(dev);
> - goto err_pci_disable_device;
> - }
> + if (IS_ERR(dev))
> + return PTR_ERR(dev);
>
> dev->pdev = pdev;
> pci_set_drvdata(pdev, dev);
> @@ -120,8 +118,6 @@ static int ast_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> ast_driver_unload(dev);
> err_drm_dev_put:
> drm_dev_put(dev);
> -err_pci_disable_device:
> - pci_disable_device(pdev);
> return ret;
>
> }
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index e5398e3dabe7..1b35728ad871 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -531,8 +531,5 @@ void ast_driver_unload(struct drm_device *dev)
> drm_mode_config_cleanup(dev);
>
> ast_mm_fini(ast);
> - if (ast->ioregs != ast->regs + AST_IO_MM_OFFSET)
> - pci_iounmap(dev->pdev, ast->ioregs);
> - pci_iounmap(dev->pdev, ast->regs);
> kfree(ast);
> }
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/28] drm/i915/selftests: Remove live_suppress_wait_preempt
On 07/06/2020 23:20, Chris Wilson wrote:
With the removal of the internal wait-priority boosting, we can also
remove the selftest to ensure that those waits were being suppressed
from causing preemptions.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 178 -
1 file changed, 178 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 67d74e6432a8..e838e38a262c 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -2379,183 +2379,6 @@ static int live_suppress_self_preempt(void *arg)
goto err_client_b;
}
-static int __i915_sw_fence_call
-dummy_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
-{
- return NOTIFY_DONE;
-}
-
-static struct i915_request *dummy_request(struct intel_engine_cs *engine)
-{
- struct i915_request *rq;
-
- rq = kzalloc(sizeof(*rq), GFP_KERNEL);
- if (!rq)
- return NULL;
-
- rq->engine = engine;
-
- spin_lock_init(&rq->lock);
- INIT_LIST_HEAD(&rq->fence.cb_list);
- rq->fence.lock = &rq->lock;
- rq->fence.ops = &i915_fence_ops;
-
- i915_sched_node_init(&rq->sched);
-
- /* mark this request as permanently incomplete */
- rq->fence.seqno = 1;
- BUILD_BUG_ON(sizeof(rq->fence.seqno) != 8); /* upper 32b == 0 */
- rq->hwsp_seqno = (u32 *)&rq->fence.seqno + 1;
- GEM_BUG_ON(i915_request_completed(rq));
-
- i915_sw_fence_init(&rq->submit, dummy_notify);
- set_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags);
-
- spin_lock_init(&rq->lock);
- rq->fence.lock = &rq->lock;
- INIT_LIST_HEAD(&rq->fence.cb_list);
-
- return rq;
-}
-
-static void dummy_request_free(struct i915_request *dummy)
-{
- /* We have to fake the CS interrupt to kick the next request */
- i915_sw_fence_commit(&dummy->submit);
-
- i915_request_mark_complete(dummy);
- dma_fence_signal(&dummy->fence);
-
- i915_sched_node_fini(&dummy->sched);
- i915_sw_fence_fini(&dummy->submit);
-
- dma_fence_free(&dummy->fence);
-}
-
-static int live_suppress_wait_preempt(void *arg)
-{
- struct intel_gt *gt = arg;
- struct preempt_client client[4];
- struct i915_request *rq[ARRAY_SIZE(client)] = {};
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
- int err = -ENOMEM;
- int i;
-
- /*
-* Waiters are given a little priority nudge, but not enough
-* to actually cause any preemption. Double check that we do
-* not needlessly generate preempt-to-idle cycles.
-*/
-
- if (!HAS_LOGICAL_RING_PREEMPTION(gt->i915))
- return 0;
-
- if (preempt_client_init(gt, &client[0])) /* ELSP[0] */
- return -ENOMEM;
- if (preempt_client_init(gt, &client[1])) /* ELSP[1] */
- goto err_client_0;
- if (preempt_client_init(gt, &client[2])) /* head of queue */
- goto err_client_1;
- if (preempt_client_init(gt, &client[3])) /* bystander */
- goto err_client_2;
-
- for_each_engine(engine, gt, id) {
- int depth;
-
- if (!intel_engine_has_preemption(engine))
- continue;
-
- if (!engine->emit_init_breadcrumb)
- continue;
-
- for (depth = 0; depth < ARRAY_SIZE(client); depth++) {
- struct i915_request *dummy;
-
- engine->execlists.preempt_hang.count = 0;
-
- dummy = dummy_request(engine);
- if (!dummy)
- goto err_client_3;
-
- for (i = 0; i < ARRAY_SIZE(client); i++) {
- struct i915_request *this;
-
- this = spinner_create_request(&client[i].spin,
- client[i].ctx,
engine,
- MI_NOOP);
- if (IS_ERR(this)) {
- err = PTR_ERR(this);
- goto err_wedged;
- }
-
- /* Disable NEWCLIENT promotion */
-
__i915_active_fence_set(&i915_request_timeline(this)->last_request,
- &dummy->fence);
-
- rq[i] = i915_request_get(this);
- i915_request_add(this);
- }
-
- dummy_request_free(dummy);
-
- GEM_BUG_ON(i915_request_completed(rq[0]));
- if (!igt_wait_for_spinner(&client[0].spin, rq[0])) {
-
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
On Thu, Jun 11, 2020 at 12:36 PM Tvrtko Ursulin wrote: > > > On 10/06/2020 16:17, Daniel Vetter wrote: > > On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > > wrote: > >> > >> > >> On 04/06/2020 09:12, Daniel Vetter wrote: > >>> Design is similar to the lockdep annotations for workers, but with > >>> some twists: > >>> > >>> - We use a read-lock for the execution/worker/completion side, so that > >>> this explicit annotation can be more liberally sprinkled around. > >>> With read locks lockdep isn't going to complain if the read-side > >>> isn't nested the same way under all circumstances, so ABBA deadlocks > >>> are ok. Which they are, since this is an annotation only. > >>> > >>> - We're using non-recursive lockdep read lock mode, since in recursive > >>> read lock mode lockdep does not catch read side hazards. And we > >>> _very_ much want read side hazards to be caught. For full details of > >>> this limitation see > >>> > >>> commit e91498589746065e3ae95d9a00b068e525eec34f > >>> Author: Peter Zijlstra > >>> Date: Wed Aug 23 13:13:11 2017 +0200 > >>> > >>> locking/lockdep/selftests: Add mixed read-write ABBA tests > >>> > >>> - To allow nesting of the read-side explicit annotations we explicitly > >>> keep track of the nesting. lock_is_held() allows us to do that. > >>> > >>> - The wait-side annotation is a write lock, and entirely done within > >>> dma_fence_wait() for everyone by default. > >>> > >>> - To be able to freely annotate helper functions I want to make it ok > >>> to call dma_fence_begin/end_signalling from soft/hardirq context. > >>> First attempt was using the hardirq locking context for the write > >>> side in lockdep, but this forces all normal spinlocks nested within > >>> dma_fence_begin/end_signalling to be spinlocks. That bollocks. > >>> > >>> The approach now is to simple check in_atomic(), and for these cases > >>> entirely rely on the might_sleep() check in dma_fence_wait(). That > >>> will catch any wrong nesting against spinlocks from soft/hardirq > >>> contexts. > >>> > >>> The idea here is that every code path that's critical for eventually > >>> signalling a dma_fence should be annotated with > >>> dma_fence_begin/end_signalling. The annotation ideally starts right > >>> after a dma_fence is published (added to a dma_resv, exposed as a > >>> sync_file fd, attached to a drm_syncobj fd, or anything else that > >>> makes the dma_fence visible to other kernel threads), up to and > >>> including the dma_fence_wait(). Examples are irq handlers, the > >>> scheduler rt threads, the tail of execbuf (after the corresponding > >>> fences are visible), any workers that end up signalling dma_fences and > >>> really anything else. Not annotated should be code paths that only > >>> complete fences opportunistically as the gpu progresses, like e.g. > >>> shrinker/eviction code. > >>> > >>> The main class of deadlocks this is supposed to catch are: > >>> > >>> Thread A: > >>> > >>>mutex_lock(A); > >>>mutex_unlock(A); > >>> > >>>dma_fence_signal(); > >>> > >>> Thread B: > >>> > >>>mutex_lock(A); > >>>dma_fence_wait(); > >>>mutex_unlock(A); > >>> > >>> Thread B is blocked on A signalling the fence, but A never gets around > >>> to that because it cannot acquire the lock A. > >>> > >>> Note that dma_fence_wait() is allowed to be nested within > >>> dma_fence_begin/end_signalling sections. To allow this to happen the > >>> read lock needs to be upgraded to a write lock, which means that any > >>> other lock is acquired between the dma_fence_begin_signalling() call and > >>> the call to dma_fence_wait(), and still held, this will result in an > >>> immediate lockdep complaint. The only other option would be to not > >>> annotate such calls, defeating the point. Therefore these annotations > >>> cannot be sprinkled over the code entirely mindless to avoid false > >>> positives. > >>> > >>> v2: handle soft/hardirq ctx better against write side and dont forget > >>> EXPORT_SYMBOL, drivers can't use this otherwise. > >>> > >>> v3: Kerneldoc. > >>> > >>> v4: Some spelling fixes from Mika > >>> > >>> Cc: Mika Kuoppala > >>> Cc: Thomas Hellstrom > >>> Cc: linux-me...@vger.kernel.org > >>> Cc: linaro-mm-...@lists.linaro.org > >>> Cc: linux-r...@vger.kernel.org > >>> Cc: amd-...@lists.freedesktop.org > >>> Cc: intel-gfx@lists.freedesktop.org > >>> Cc: Chris Wilson > >>> Cc: Maarten Lankhorst > >>> Cc: Christian König > >>> Signed-off-by: Daniel Vetter > >>> --- > >>>Documentation/driver-api/dma-buf.rst | 12 +- > >>>drivers/dma-buf/dma-fence.c | 161 +++ > >>>include/linux/dma-fence.h| 12 ++ > >>>3 files changed, 182 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/Documentation/driver-api/dma-buf.rst > >>> b/Documentation/driver-api/dma-buf.rst > >>> index 63dec76d1d8d..05d856131140 100644 > >
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c (rev2)
== Series Details ==
Series: drm/i915: Include asm sources for {ivb, hsw}_clear_kernel.c (rev2)
URL : https://patchwork.freedesktop.org/series/78126/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8611_full -> Patchwork_17924_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17924_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17924_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_17924_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_endless@dispatch@rcs0:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-iclb1/igt@gem_exec_endless@dispa...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-iclb7/igt@gem_exec_endless@dispa...@rcs0.html
Known issues
Here are the changes found in Patchwork_17924_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-mixed-process@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#1528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl3/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-apl4/igt@gem_ctx_persistence@engines-mixed-proc...@rcs0.html
* igt@gem_exec_suspend@basic-s3:
- shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-kbl3/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-kbl4/igt@gem_exec_susp...@basic-s3.html
* igt@gem_exec_whisper@basic-fds-priority:
- shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
+1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk9/igt@gem_exec_whis...@basic-fds-priority.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-glk1/igt@gem_exec_whis...@basic-fds-priority.html
* igt@gem_workarounds@suspend-resume-context:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl8/igt@gem_workarou...@suspend-resume-context.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-apl1/igt@gem_workarou...@suspend-resume-context.html
* igt@i915_pm_dc@dc5-psr:
- shard-skl: [PASS][11] -> [INCOMPLETE][12] ([i915#198])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-skl8/igt@i915_pm...@dc5-psr.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-skl2/igt@i915_pm...@dc5-psr.html
* igt@kms_big_fb@yf-tiled-32bpp-rotate-0:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl4/igt@kms_big...@yf-tiled-32bpp-rotate-0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-apl3/igt@kms_big...@yf-tiled-32bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-skl: [PASS][15] -> [INCOMPLETE][16] ([i915#300])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge:
- shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#93] / [i915#95])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-kbl3/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-kbl4/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#72])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-glk7/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
* igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-iclb: [PASS][21] -> [DMESG-WARN][22] ([i915#128])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-iclb2/igt@kms_cursor_leg...@all-pipes-torture-move.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17924/shard-iclb4/igt@kms_cursor_leg...@
Re: [Intel-gfx] [git pull] uaccess i915
The pull request you sent on Wed, 10 Jun 2020 21:28:37 +0100: > git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git uaccess.i915 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/3a8557e1aed0043d526f304a1f500108c8976b78 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tgl+: Fix DP MST ACT status handling
== Series Details == Series: series starting with [1/2] drm/i915/tgl+: Fix DP MST ACT status handling URL : https://patchwork.freedesktop.org/series/78193/ State : success == Summary == CI Bug Log - changes from CI_DRM_8611_full -> Patchwork_17921_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17921_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed-process@blt: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#1528]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-skl7/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-skl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@blt.html * igt@gem_exec_whisper@basic-queues-forked-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#118] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk1/igt@gem_exec_whis...@basic-queues-forked-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-glk7/igt@gem_exec_whis...@basic-queues-forked-all.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([i915#1436] / [i915#716]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk9/igt@gen9_exec_pa...@allowed-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-glk1/igt@gen9_exec_pa...@allowed-all.html * igt@i915_module_load@reload: - shard-tglb: [PASS][7] -> [DMESG-WARN][8] ([i915#402]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-tglb3/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-tglb6/igt@i915_module_l...@reload.html * igt@kms_big_fb@linear-32bpp-rotate-180: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl3/igt@kms_big...@linear-32bpp-rotate-180.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-apl8/igt@kms_big...@linear-32bpp-rotate-180.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] / [i915#95]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk4/igt@kms_big...@linear-64bpp-rotate-180.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#93] / [i915#95]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-kbl3/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-kbl1/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#95]) +26 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl3/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-apl7/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@flip-vs-suspend-interruptible@c-dp1: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-apl2/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-apl8/igt@kms_flip@flip-vs-suspend-interrupti...@c-dp1.html * igt@kms_flip@flip-vs-suspend@c-dp1: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-kbl2/igt@kms_flip@flip-vs-susp...@c-dp1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-kbl7/igt@kms_flip@flip-vs-susp...@c-dp1.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-glk: [PASS][21] -> [INCOMPLETE][22] ([i915#58] / [k.org#198133]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-glk7/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17921/shard-glk5/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([i915#123] / [i915#69]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8611/shard-skl3/igt@k
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_reloc: Verify engine isolation
Check that when relocating a batch along an engine, we are not forced to
wait upon a resource elsewhere that userspace may be holding, or else we
are faced with a deadlock that may be injected by another user. That
deadlock may be resolved by resetting the hostile context, but in doing
so we should not break the relocation processing.
Ideally, we would avoid the deadlock.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2021
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_reloc.c | 105 ++--
1 file changed, 89 insertions(+), 16 deletions(-)
diff --git a/tests/i915/gem_exec_reloc.c b/tests/i915/gem_exec_reloc.c
index 6490d3a6f..2d4164076 100644
--- a/tests/i915/gem_exec_reloc.c
+++ b/tests/i915/gem_exec_reloc.c
@@ -43,6 +43,22 @@ static uint32_t find_last_set(uint64_t x)
return i;
}
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, &bbe, sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
static void write_dword(int fd,
uint32_t target_handle,
uint64_t target_offset,
@@ -523,6 +539,72 @@ static void active_spin(int fd, unsigned engine)
igt_spin_free(fd, spin);
}
+static void others_spin(int i915, unsigned engine)
+{
+ struct drm_i915_gem_relocation_entry reloc = {};
+ struct drm_i915_gem_exec_object2 obj = {
+ .relocs_ptr = to_user_pointer(&reloc),
+ .relocation_count = 1,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&obj),
+ .buffer_count = 1,
+ .flags = engine,
+ };
+ const struct intel_execution_engine2 *e;
+ igt_spin_t *spin = NULL;
+ uint64_t addr;
+ int fence;
+
+ __for_each_physical_engine(i915, e) {
+ if (e->flags == engine)
+ continue;
+
+ if (!spin) {
+ spin = igt_spin_new(i915,
+ .engine = e->flags,
+ .flags = IGT_SPIN_FENCE_OUT);
+ fence = dup(spin->out_fence);
+ } else {
+ int old_fence;
+
+ spin->execbuf.flags &= ~I915_EXEC_RING_MASK;
+ spin->execbuf.flags |= e->flags;
+ gem_execbuf_wr(i915, &spin->execbuf);
+
+ old_fence = fence;
+ fence = sync_fence_merge(old_fence,
+spin->execbuf.rsvd2 >> 32);
+ close(spin->execbuf.rsvd2 >> 32);
+ close(old_fence);
+ }
+ }
+ igt_require(spin);
+
+ /* All other engines are busy, let's relocate! */
+ obj.handle = batch_create(i915);
+ reloc.target_handle = obj.handle;
+ reloc.presumed_offset = -1;
+ reloc.offset = 64;
+ gem_execbuf(i915, &execbuf);
+
+ /* Verify the relocation took place */
+ gem_read(i915, obj.handle, 64, &addr, sizeof(addr));
+ igt_assert_eq_u64(addr, obj.offset);
+ gem_close(i915, obj.handle);
+
+ /* Even if the spinner was harmed in the process */
+ igt_spin_end(spin);
+ igt_assert_eq(sync_fence_wait(fence, 200), 0);
+ igt_assert_neq(sync_fence_status(fence), 0);
+ if (sync_fence_status(fence) < 0)
+ igt_warn("Spinner was cancelled, %s\n",
+strerror(-sync_fence_status(fence)));
+ close(fence);
+
+ igt_spin_free(i915, spin);
+}
+
static bool has_64b_reloc(int fd)
{
return intel_gen(intel_get_drm_devid(fd)) >= 8;
@@ -881,22 +963,6 @@ parallel_relocs(int count, unsigned long *out)
return reloc;
}
-static uint32_t __batch_create(int i915, uint32_t offset)
-{
- const uint32_t bbe = MI_BATCH_BUFFER_END;
- uint32_t handle;
-
- handle = gem_create(i915, ALIGN(offset + 4, 4096));
- gem_write(i915, handle, offset, &bbe, sizeof(bbe));
-
- return handle;
-}
-
-static uint32_t batch_create(int i915)
-{
- return __batch_create(i915, 0);
-}
-
static int __execbuf(int i915, struct drm_i915_gem_execbuffer2 *execbuf)
{
int err;
@@ -1336,6 +1402,13 @@ igt_main
}
}
+ igt_subtest_with_dynamic("basic-spin-others") {
+ __for_each_physical_engine(fd, e) {
+ igt_dynamic_f("%s", e->name)
+ others_spin(fd, e->flags);
+ }
+ }
+
igt_subtest_with_dynamic("basic-many-active") {
__for_each_physical_engine(fd, e) {
igt_
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST connectors (rev3)
On Tue, Jun 09, 2020 at 08:58:41PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Fix the i915_dsc_fec_support debugfs file for DP MST > connectors (rev3) > URL : https://patchwork.freedesktop.org/series/78128/ > State : success Thanks for the review, pushed to -dinq. > > == Summary == > > CI Bug Log - changes from CI_DRM_8604_full -> Patchwork_17916_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_17916_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_ctx_shared@q-independent@bcs0: > - shard-kbl: [PASS][1] -> [FAIL][2] ([i915#2013]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-kbl6/igt@gem_ctx_shared@q-independ...@bcs0.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-kbl1/igt@gem_ctx_shared@q-independ...@bcs0.html > > * igt@gem_exec_create@forked: > - shard-hsw: [PASS][3] -> [INCOMPLETE][4] ([i915#61]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-hsw7/igt@gem_exec_cre...@forked.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-hsw2/igt@gem_exec_cre...@forked.html > > * igt@gem_exec_schedule@implicit-read-write@rcs0: > - shard-snb: [PASS][5] -> [INCOMPLETE][6] ([i915#82]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-snb4/igt@gem_exec_schedule@implicit-read-wr...@rcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-snb6/igt@gem_exec_schedule@implicit-read-wr...@rcs0.html > > * igt@gem_exec_whisper@basic-forked-all: > - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / > [i915#95]) +1 similar issue >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-glk8/igt@gem_exec_whis...@basic-forked-all.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-glk4/igt@gem_exec_whis...@basic-forked-all.html > > * igt@gem_workarounds@suspend-resume-context: > - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) +3 > similar issues >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-apl7/igt@gem_workarou...@suspend-resume-context.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-apl4/igt@gem_workarou...@suspend-resume-context.html > > * igt@i915_module_load@reload-with-fault-injection: > - shard-tglb: [PASS][11] -> [DMESG-WARN][12] ([i915#402]) +3 > similar issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-tglb6/igt@i915_module_l...@reload-with-fault-injection.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-tglb5/igt@i915_module_l...@reload-with-fault-injection.html > > * igt@i915_pm_rps@reset: > - shard-skl: [PASS][13] -> [FAIL][14] ([i915#39]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-skl10/igt@i915_pm_...@reset.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-skl5/igt@i915_pm_...@reset.html > > * igt@kms_big_fb@linear-64bpp-rotate-180: > - shard-glk: [PASS][15] -> [DMESG-FAIL][16] ([i915#118] / > [i915#95]) +1 similar issue >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-glk2/igt@kms_big...@linear-64bpp-rotate-180.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html > > * igt@kms_big_fb@yf-tiled-32bpp-rotate-0: > - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1982]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-kbl3/igt@kms_big...@yf-tiled-32bpp-rotate-0.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-kbl1/igt@kms_big...@yf-tiled-32bpp-rotate-0.html > > * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen: > - shard-kbl: [PASS][19] -> [DMESG-FAIL][20] ([i915#54] / > [i915#95]) +1 similar issue >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html > > * igt@kms_cursor_crc@pipe-a-cursor-64x64-onscreen: > - shard-skl: [PASS][21] -> [FAIL][22] ([i915#54]) +1 similar > issue >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-skl4/igt@kms_cursor_...@pipe-a-cursor-64x64-onscreen.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17916/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x64-onscreen.html > > * igt@kms_cursor_crc@pipe-a-cursor-suspend: > - shard-kbl: [PASS][23] ->
Re: [Intel-gfx] [PATCH 2/6] drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds
Quoting Chris Wilson (2020-06-11 09:01:36) > +static void > +ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list > *wal) > + /* > +* BSpec recommends 8x4 when MSAA is used, > +* however in practice 16x4 seems fastest. > +* > +* Note that PS/WM thread counts depend on the WIZ hashing > +* disable bit, which we don't touch here, but it's good > +* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM). > +*/ > + wa_add(wal, GEN7_GT_MODE, 0, > + _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4), > + GEN6_WIZ_HASHING_16x4); Fwiw, from gen8+, we have this in the ctx workarounds. Not sure if that's a better spot or not. An inquiry for later, as it is passing the tests for now :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
On 10/06/2020 16:17, Daniel Vetter wrote: > On Wed, Jun 10, 2020 at 4:22 PM Tvrtko Ursulin > wrote: >> >> >> On 04/06/2020 09:12, Daniel Vetter wrote: >>> Design is similar to the lockdep annotations for workers, but with >>> some twists: >>> >>> - We use a read-lock for the execution/worker/completion side, so that >>> this explicit annotation can be more liberally sprinkled around. >>> With read locks lockdep isn't going to complain if the read-side >>> isn't nested the same way under all circumstances, so ABBA deadlocks >>> are ok. Which they are, since this is an annotation only. >>> >>> - We're using non-recursive lockdep read lock mode, since in recursive >>> read lock mode lockdep does not catch read side hazards. And we >>> _very_ much want read side hazards to be caught. For full details of >>> this limitation see >>> >>> commit e91498589746065e3ae95d9a00b068e525eec34f >>> Author: Peter Zijlstra >>> Date: Wed Aug 23 13:13:11 2017 +0200 >>> >>> locking/lockdep/selftests: Add mixed read-write ABBA tests >>> >>> - To allow nesting of the read-side explicit annotations we explicitly >>> keep track of the nesting. lock_is_held() allows us to do that. >>> >>> - The wait-side annotation is a write lock, and entirely done within >>> dma_fence_wait() for everyone by default. >>> >>> - To be able to freely annotate helper functions I want to make it ok >>> to call dma_fence_begin/end_signalling from soft/hardirq context. >>> First attempt was using the hardirq locking context for the write >>> side in lockdep, but this forces all normal spinlocks nested within >>> dma_fence_begin/end_signalling to be spinlocks. That bollocks. >>> >>> The approach now is to simple check in_atomic(), and for these cases >>> entirely rely on the might_sleep() check in dma_fence_wait(). That >>> will catch any wrong nesting against spinlocks from soft/hardirq >>> contexts. >>> >>> The idea here is that every code path that's critical for eventually >>> signalling a dma_fence should be annotated with >>> dma_fence_begin/end_signalling. The annotation ideally starts right >>> after a dma_fence is published (added to a dma_resv, exposed as a >>> sync_file fd, attached to a drm_syncobj fd, or anything else that >>> makes the dma_fence visible to other kernel threads), up to and >>> including the dma_fence_wait(). Examples are irq handlers, the >>> scheduler rt threads, the tail of execbuf (after the corresponding >>> fences are visible), any workers that end up signalling dma_fences and >>> really anything else. Not annotated should be code paths that only >>> complete fences opportunistically as the gpu progresses, like e.g. >>> shrinker/eviction code. >>> >>> The main class of deadlocks this is supposed to catch are: >>> >>> Thread A: >>> >>>mutex_lock(A); >>>mutex_unlock(A); >>> >>>dma_fence_signal(); >>> >>> Thread B: >>> >>>mutex_lock(A); >>>dma_fence_wait(); >>>mutex_unlock(A); >>> >>> Thread B is blocked on A signalling the fence, but A never gets around >>> to that because it cannot acquire the lock A. >>> >>> Note that dma_fence_wait() is allowed to be nested within >>> dma_fence_begin/end_signalling sections. To allow this to happen the >>> read lock needs to be upgraded to a write lock, which means that any >>> other lock is acquired between the dma_fence_begin_signalling() call and >>> the call to dma_fence_wait(), and still held, this will result in an >>> immediate lockdep complaint. The only other option would be to not >>> annotate such calls, defeating the point. Therefore these annotations >>> cannot be sprinkled over the code entirely mindless to avoid false >>> positives. >>> >>> v2: handle soft/hardirq ctx better against write side and dont forget >>> EXPORT_SYMBOL, drivers can't use this otherwise. >>> >>> v3: Kerneldoc. >>> >>> v4: Some spelling fixes from Mika >>> >>> Cc: Mika Kuoppala >>> Cc: Thomas Hellstrom >>> Cc: linux-me...@vger.kernel.org >>> Cc: linaro-mm-...@lists.linaro.org >>> Cc: linux-r...@vger.kernel.org >>> Cc: amd-...@lists.freedesktop.org >>> Cc: intel-gfx@lists.freedesktop.org >>> Cc: Chris Wilson >>> Cc: Maarten Lankhorst >>> Cc: Christian König >>> Signed-off-by: Daniel Vetter >>> --- >>>Documentation/driver-api/dma-buf.rst | 12 +- >>>drivers/dma-buf/dma-fence.c | 161 +++ >>>include/linux/dma-fence.h| 12 ++ >>>3 files changed, 182 insertions(+), 3 deletions(-) >>> >>> diff --git a/Documentation/driver-api/dma-buf.rst >>> b/Documentation/driver-api/dma-buf.rst >>> index 63dec76d1d8d..05d856131140 100644 >>> --- a/Documentation/driver-api/dma-buf.rst >>> +++ b/Documentation/driver-api/dma-buf.rst >>> @@ -100,11 +100,11 @@ CPU Access to DMA Buffer Objects >>>.. kernel-doc:: drivers/dma-buf/dma-buf.c >>> :doc: cpu access >>> >>> -Fence Poll Support >>> -~~ >>>
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Disable DIP on MST ports with the transcoder clock still on
On Tue, Jun 09, 2020 at 11:56:12PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: Disable DIP on MST ports with the transcoder clock > still on > URL : https://patchwork.freedesktop.org/series/78172/ > State : success Thanks for the review, pushed to -dinq. > > == Summary == > > CI Bug Log - changes from CI_DRM_8604_full -> Patchwork_17917_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_17917_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_create@madvise: > - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / > [i915#95]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-glk6/igt@gem_exec_cre...@madvise.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-glk4/igt@gem_exec_cre...@madvise.html > > * igt@gem_exec_whisper@basic-normal: > - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([i915#93] / > [i915#95]) +3 similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-kbl4/igt@gem_exec_whis...@basic-normal.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-kbl3/igt@gem_exec_whis...@basic-normal.html > > * igt@kms_big_fb@linear-64bpp-rotate-180: > - shard-glk: [PASS][5] -> [DMESG-FAIL][6] ([i915#118] / > [i915#95]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-glk2/igt@kms_big...@linear-64bpp-rotate-180.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html > > * igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen: > - shard-kbl: [PASS][7] -> [DMESG-FAIL][8] ([i915#54] / > [i915#95]) +1 similar issue >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html > > * igt@kms_cursor_crc@pipe-c-cursor-256x256-sliding: > - shard-skl: [PASS][9] -> [FAIL][10] ([i915#54]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-skl10/igt@kms_cursor_...@pipe-c-cursor-256x256-sliding.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-skl8/igt@kms_cursor_...@pipe-c-cursor-256x256-sliding.html > > * igt@kms_cursor_legacy@flip-vs-cursor-busy-crc-legacy: > - shard-kbl: [PASS][11] -> [DMESG-FAIL][12] ([i915#95]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-kbl3/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-kbl4/igt@kms_cursor_leg...@flip-vs-cursor-busy-crc-legacy.html > > * igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-ytiled: > - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +7 > similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-skl7/igt@kms_draw_...@draw-method-xrgb2101010-pwrite-ytiled.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-skl10/igt@kms_draw_...@draw-method-xrgb2101010-pwrite-ytiled.html > > * igt@kms_flip@flip-vs-suspend@a-dp1: > - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3 > similar issues >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-apl2/igt@kms_flip@flip-vs-susp...@a-dp1.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-apl4/igt@kms_flip@flip-vs-susp...@a-dp1.html > > * igt@kms_flip@plain-flip-fb-recreate-interruptible@a-edp1: > - shard-skl: [PASS][17] -> [FAIL][18] ([i915#1928]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-skl3/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-skl5/igt@kms_flip@plain-flip-fb-recreate-interrupti...@a-edp1.html > > * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-wc: > - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-tglb6/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-wc.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17917/shard-tglb5/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-mmap-wc.html > > * igt@kms_hdr@bpc-switch: > - shard-skl: [PASS][21] -> [FAIL][22] ([i915#1188]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8604/shard-skl2/igt@kms_...@bpc-switch.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Include context status in debug dumps
== Series Details == Series: drm/i915/gt: Include context status in debug dumps URL : https://patchwork.freedesktop.org/series/78188/ State : success == Summary == CI Bug Log - changes from CI_DRM_8610_full -> Patchwork_17920_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17920_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reloc@basic-wc-cpu-active: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#95]) +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-apl8/igt@gem_exec_re...@basic-wc-cpu-active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-apl1/igt@gem_exec_re...@basic-wc-cpu-active.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] / [i915#716]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-glk1/igt@gen9_exec_pa...@allowed-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-glk7/igt@gen9_exec_pa...@allowed-all.html * igt@i915_module_load@reload-with-fault-injection: - shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#402]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-tglb3/igt@i915_module_l...@reload-with-fault-injection.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-tglb3/igt@i915_module_l...@reload-with-fault-injection.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [PASS][7] -> [DMESG-FAIL][8] ([i915#118] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-glk5/igt@kms_big...@linear-64bpp-rotate-180.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +16 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-skl6/igt@kms_co...@pipe-c-ctm-0-25.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-skl4/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_cursor_edge_walk@pipe-a-128x128-bottom-edge: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#93] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-kbl4/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-kbl2/igt@kms_cursor_edge_w...@pipe-a-128x128-bottom-edge.html * igt@kms_flip@flip-vs-suspend@b-dp1: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-kbl3/igt@kms_flip@flip-vs-susp...@b-dp1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-kbl4/igt@kms_flip@flip-vs-susp...@b-dp1.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_sprite_blt: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-iclb3/igt@kms_psr@psr2_sprite_blt.html * igt@kms_setmode@basic: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#31]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-apl7/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-apl4/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([i915#180]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-apl7/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-apl4/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html Possible fixes * igt@gem_ctx_persistence@processes: - shard-skl: [FAIL][23] ([i915#1528]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8610/shard-skl3/igt@gem_ctx_persiste...@processes.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17920/shard-skl7/igt@gem_ctx_persiste...@processes.html * igt@i915_suspend@debugfs-reader: - shard-kbl: [DMESG-WARN][25] ([i915#180]) -> [PASS]
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds (rev2)
== Series Details ==
Series: series starting with drm/i915/gt: Move hsw GT workarounds from
init_clock_gating to workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/78214/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8614 -> Patchwork_17926
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17926:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-kbl-7560u}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-kbl-7560u/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_17926 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][2] -> [FAIL][3] ([i915#1888])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][4] -> [DMESG-WARN][5] ([i915#1982])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gem_contexts:
- fi-tgl-u2: [PASS][6] -> [INCOMPLETE][7] ([i915#1932])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-tgl-u2/igt@i915_selftest@live@gem_contexts.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-icl-guc: [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-icl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
Possible fixes
* igt@i915_module_load@reload:
- fi-apl-guc: [DMESG-WARN][10] ([i915#1982]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-apl-guc/igt@i915_module_l...@reload.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- {fi-tgl-dsi}: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-tgl-dsi/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][14] ([i915#1982]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-tgl-u2: [DMESG-FAIL][16] ([i915#1233]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-tgl-u2/igt@i915_selftest@live@gt_lrc.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][18] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][20] ([i915#1982]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
- fi-bsw-kefka: [DMESG-WARN][22] ([i915#1982]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17926/fi-bsw-kefka/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf
Re: [Intel-gfx] [PATCH 6/6] drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 +
> drivers/gpu/drm/i915/intel_pm.c | 15
> 2 files changed, 22 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index f8b9e104378e..7b4be64585c3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -715,15 +715,28 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> }
>
> static void
> -ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +gen4_gt_workarounds_init(struct drm_i915_private *i915,
> + struct i915_wa_list *wal)
> {
> - wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
> + /* WaDisable_RenderCache_OperationalFlush:gen4,ilk */
> + wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
> +}
> +
> +static void
> +g4x_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + gen4_gt_workarounds_init(i915, wal);
>
> - /* WaDisableRenderCachePipelinedFlush:ilk */
> + /* WaDisableRenderCachePipelinedFlush:g4x,ilk */
> wa_masked_en(wal, CACHE_MODE_0, CM0_PIPELINED_RENDER_FLUSH_DISABLE);
> +}
>
> - /* WaDisable_RenderCache_OperationalFlush:ilk */
> - wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
> +static void
> +ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + g4x_gt_workarounds_init(i915, wal);
> +
> + wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
> }
>
> static void
> @@ -1209,6 +1222,10 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> snb_gt_workarounds_init(i915, wal);
> else if (IS_GEN(i915, 5))
> ilk_gt_workarounds_init(i915, wal);
> + else if (IS_G4X(i915))
> + g4x_gt_workarounds_init(i915, wal);
> + else if (IS_GEN(i915, 4))
> + gen4_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> return;
> else
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 7d82a7144a13..2a32d6230795 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7399,13 +7399,6 @@ static void g4x_init_clock_gating(struct
> drm_i915_private *dev_priv)
> dspclk_gate |= DSSUNIT_CLOCK_GATE_DISABLE;
> I915_WRITE(DSPCLK_GATE_D, dspclk_gate);
>
> - /* WaDisableRenderCachePipelinedFlush */
> - I915_WRITE(CACHE_MODE_0,
> -_MASKED_BIT_ENABLE(CM0_PIPELINED_RENDER_FLUSH_DISABLE));
> -
> - /* WaDisable_RenderCache_OperationalFlush:g4x */
> - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
> -
> g4x_disable_trickle_feed(dev_priv);
> }
>
> @@ -7421,11 +7414,6 @@ static void i965gm_init_clock_gating(struct
> drm_i915_private *dev_priv)
> intel_uncore_write(uncore,
> MI_ARB_STATE,
>
> _MASKED_BIT_ENABLE(MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE));
> -
> - /* WaDisable_RenderCache_OperationalFlush:gen4 */
> - intel_uncore_write(uncore,
> -CACHE_MODE_0,
> -_MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
> }
>
> static void i965g_init_clock_gating(struct drm_i915_private *dev_priv)
> @@ -7438,9 +7426,6 @@ static void i965g_init_clock_gating(struct
> drm_i915_private *dev_priv)
> I915_WRITE(RENCLK_GATE_D2, 0);
> I915_WRITE(MI_ARB_STATE,
> _MASKED_BIT_ENABLE(MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE));
> -
> - /* WaDisable_RenderCache_OperationalFlush:gen4 */
> - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
> }
>
> static void gen3_init_clock_gating(struct drm_i915_private *dev_priv)
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 ++
> drivers/gpu/drm/i915/intel_pm.c | 10 --
> 2 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 7b4f3434eb6b..f8b9e104378e 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -714,6 +714,18 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> return 0;
> }
>
> +static void
> +ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
> +
> + /* WaDisableRenderCachePipelinedFlush:ilk */
> + wa_masked_en(wal, CACHE_MODE_0, CM0_PIPELINED_RENDER_FLUSH_DISABLE);
> +
> + /* WaDisable_RenderCache_OperationalFlush:ilk */
> + wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
> +}
> +
> static void
> snb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> {
> @@ -1195,6 +1207,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> ivb_gt_workarounds_init(i915, wal);
> else if (IS_GEN(i915, 6))
> snb_gt_workarounds_init(i915, wal);
> + else if (IS_GEN(i915, 5))
> + ilk_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> return;
> else
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b4bea6451418..7d82a7144a13 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6921,16 +6921,6 @@ static void ilk_init_clock_gating(struct
> drm_i915_private *dev_priv)
> I915_WRITE(ILK_DISPLAY_CHICKEN2,
> I915_READ(ILK_DISPLAY_CHICKEN2) |
> ILK_ELPIN_409_SELECT);
> - I915_WRITE(_3D_CHICKEN2,
> -_3D_CHICKEN2_WM_READ_PIPELINED << 16 |
> -_3D_CHICKEN2_WM_READ_PIPELINED);
> -
> - /* WaDisableRenderCachePipelinedFlush:ilk */
> - I915_WRITE(CACHE_MODE_0,
> -_MASKED_BIT_ENABLE(CM0_PIPELINED_RENDER_FLUSH_DISABLE));
> -
> - /* WaDisable_RenderCache_OperationalFlush:ilk */
> - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
>
> g4x_disable_trickle_feed(dev_priv);
>
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 41 +
> drivers/gpu/drm/i915/intel_pm.c | 33 -
> 2 files changed, 41 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 688ca25d79d0..7b4f3434eb6b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -714,6 +714,45 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> return 0;
> }
>
> +static void
> +snb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + /* WaDisableHiZPlanesWhenMSAAEnabled:snb */
> + wa_masked_en(wal,
> + _3D_CHICKEN,
> + _3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB);
> +
> + /* WaDisable_RenderCache_OperationalFlush:snb */
> + wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
> +
> + /*
> + * BSpec recoomends 8x4 when MSAA is used,
recommends.
Reviewed-by: Mika Kuoppala
> + * however in practice 16x4 seems fastest.
> + *
> + * Note that PS/WM thread counts depend on the WIZ hashing
> + * disable bit, which we don't touch here, but it's good
> + * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
> + */
> + wa_add(wal,
> +GEN6_GT_MODE, 0,
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
> +GEN6_WIZ_HASHING_16x4);
> +
> + wa_masked_dis(wal, CACHE_MODE_0, CM0_STC_EVICT_DISABLE_LRA_SNB);
> +
> + wa_masked_en(wal,
> + _3D_CHICKEN3,
> + /* WaStripsFansDisableFastClipPerformanceFix:snb */
> + _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL |
> + /*
> + * Bspec says:
> + * "This bit must be set if 3DSTATE_CLIP clip mode is set
> + * to normal and 3DSTATE_SF number of SF output attributes
> + * is more than 16."
> + */
> +_3D_CHICKEN3_SF_DISABLE_PIPELINED_ATTR_FETCH);
> +}
> +
> static void
> ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> {
> @@ -1154,6 +1193,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> vlv_gt_workarounds_init(i915, wal);
> else if (IS_IVYBRIDGE(i915))
> ivb_gt_workarounds_init(i915, wal);
> + else if (IS_GEN(i915, 6))
> + snb_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> return;
> else
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 29abde47e987..b4bea6451418 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6993,27 +6993,6 @@ static void gen6_init_clock_gating(struct
> drm_i915_private *dev_priv)
> I915_READ(ILK_DISPLAY_CHICKEN2) |
> ILK_ELPIN_409_SELECT);
>
> - /* WaDisableHiZPlanesWhenMSAAEnabled:snb */
> - I915_WRITE(_3D_CHICKEN,
> -
> _MASKED_BIT_ENABLE(_3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB));
> -
> - /* WaDisable_RenderCache_OperationalFlush:snb */
> - I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
> -
> - /*
> - * BSpec recoomends 8x4 when MSAA is used,
> - * however in practice 16x4 seems fastest.
> - *
> - * Note that PS/WM thread counts depend on the WIZ hashing
> - * disable bit, which we don't touch here, but it's good
> - * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
> - */
> - I915_WRITE(GEN6_GT_MODE,
> -_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
> -
> - I915_WRITE(CACHE_MODE_0,
> -_MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
> -
> I915_WRITE(GEN6_UCGCTL1,
> I915_READ(GEN6_UCGCTL1) |
> GEN6_BLBUNIT_CLOCK_GATE_DISABLE |
> @@ -7036,18 +7015,6 @@ static void gen6_init_clock_gating(struct
> drm_i915_private *dev_priv)
> GEN6_RCPBUNIT_CLOCK_GATE_DISABLE |
> GEN6_RCCUNIT_CLOCK_GATE_DISABLE);
>
> - /* WaStripsFansDisableFastClipPerformanceFix:snb */
> - I915_WRITE(_3D_CHICKEN3,
> -_MASKED_BIT_ENABLE(_3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL));
> -
> - /*
> - * Bspec says:
> - * "This bit must be set if 3DSTATE_CLIP clip mode is set to normal and
> - * 3DSTATE_SF number of SF output attributes is more than 16."
> - */
> - I915_WRITE(_3D_CHICKEN3,
> -
> _MASKED_BIT_ENABLE(_3D_CHICKEN3_SF_DIS
Re: [Intel-gfx] [PATCH 3/6] drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 59
> drivers/gpu/drm/i915/intel_pm.c | 61 -
> 2 files changed, 59 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a5ba3ea8d45a..688ca25d79d0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -774,6 +774,63 @@ ivb_gt_workarounds_init(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> GEN6_WIZ_HASHING_16x4);
> }
>
> +static void
> +vlv_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + /* WaDisableEarlyCull:vlv */
> + wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL);
> +
> + /* WaPsdDispatchEnable:vlv */
> + /* WaDisablePSDDualDispatchEnable:vlv */
> + wa_masked_en(wal,
> + GEN7_HALF_SLICE_CHICKEN1,
> + GEN7_MAX_PS_THREAD_DEP |
> + GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> +
> + /* WaDisable_RenderCache_OperationalFlush:vlv */
> + wa_masked_dis(wal, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
> +
> + /* WaForceL3Serialization:vlv */
> + wa_write_clr(wal, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
> +
> + /*
> + * WaVSThreadDispatchOverride:ivb,vlv
> + *
> + * This actually overrides the dispatch
> + * mode for all thread types.
> + */
> + wa_write_masked_or(wal,
> +GEN7_FF_THREAD_MODE,
> +GEN7_FF_SCHED_MASK,
> +GEN7_FF_TS_SCHED_HW |
> +GEN7_FF_VS_SCHED_HW |
> +GEN7_FF_DS_SCHED_HW);
> +
> + /*
> + * BSpec says this must be set, even though
> + * WaDisable4x2SubspanOptimization isn't listed for VLV.
> + */
> + wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
> +
> + /*
> + * BSpec recommends 8x4 when MSAA is used,
> + * however in practice 16x4 seems fastest.
> + *
> + * Note that PS/WM thread counts depend on the WIZ hashing
> + * disable bit, which we don't touch here, but it's good
> + * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
> + */
> + wa_add(wal, GEN7_GT_MODE, 0,
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
> +GEN6_WIZ_HASHING_16x4);
> +
> + /*
> + * WaIncreaseL3CreditsForVLVB0:vlv
> + * This is the hardware default actually.
> + */
> + wa_write(wal, GEN7_L3SQCREG1, VLV_B0_WA_L3SQCREG1_VALUE);
> +}
> +
> static void
> hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> {
> @@ -1093,6 +1150,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> skl_gt_workarounds_init(i915, wal);
> else if (IS_HASWELL(i915))
> hsw_gt_workarounds_init(i915, wal);
> + else if (IS_VALLEYVIEW(i915))
> + vlv_gt_workarounds_init(i915, wal);
> else if (IS_IVYBRIDGE(i915))
> ivb_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index b835e5e97515..29abde47e987 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7077,24 +7077,6 @@ static void gen6_init_clock_gating(struct
> drm_i915_private *dev_priv)
> gen6_check_mch_setup(dev_priv);
> }
>
> -static void gen7_setup_fixed_func_scheduler(struct drm_i915_private
> *dev_priv)
> -{
> - u32 reg = I915_READ(GEN7_FF_THREAD_MODE);
> -
> - /*
> - * WaVSThreadDispatchOverride:ivb,vlv
> - *
> - * This actually overrides the dispatch
> - * mode for all thread types.
> - */
> - reg &= ~GEN7_FF_SCHED_MASK;
> - reg |= GEN7_FF_TS_SCHED_HW;
> - reg |= GEN7_FF_VS_SCHED_HW;
> - reg |= GEN7_FF_DS_SCHED_HW;
> -
> - I915_WRITE(GEN7_FF_THREAD_MODE, reg);
> -}
> -
> static void lpt_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> /*
> @@ -7381,28 +7363,11 @@ static void ivb_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> static void vlv_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - /* WaDisableEarlyCull:vlv */
> - I915_WRITE(_3D_CHICKEN3,
> -_MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL));
> -
> /* WaDisableBackToBackFlipFix:vlv */
> I915_WRITE(IVB_CHICKEN3,
> CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE |
> CHICK
Re: [Intel-gfx] [PATCH 2/6] drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds
Mika Kuoppala writes:
> Chris Wilson writes:
>
>> Rescue the GT workarounds from being buried inside init_clock_gating so
>> that we remember to apply them after a GT reset, and that they are
>> included in our verification that the workarounds are applied.
>>
>> Signed-off-by: Chris Wilson
>> ---
>> drivers/gpu/drm/i915/gt/intel_workarounds.c | 62 +
>> drivers/gpu/drm/i915/i915_reg.h | 2 +-
>> drivers/gpu/drm/i915/intel_pm.c | 48
>> 3 files changed, 63 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> index 39f070bff09d..a5ba3ea8d45a 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
>> @@ -714,6 +714,66 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
>> return 0;
>> }
>>
>> +static void
>> +ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
>> *wal)
>> +{
>> +/* WaDisableEarlyCull:ivb */
>> +wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL);
>> +
>> +/* WaDisablePSDDualDispatchEnable:ivb */
>> +if (IS_IVB_GT1(i915))
>> +wa_masked_en(wal,
>> + GEN7_HALF_SLICE_CHICKEN1,
>> + GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
>> +
>> +/* WaDisable_RenderCache_OperationalFlush:ivb */
>> +wa_masked_dis(wal, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
>> +
>> +/* Apply the WaDisableRHWOOptimizationForRenderHang:ivb workaround. */
>> +wa_masked_dis(wal,
>> + GEN7_COMMON_SLICE_CHICKEN1,
>> + GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC);
>> +
>> +/* WaApplyL3ControlAndL3ChickenMode:ivb */
>> +wa_write(wal, GEN7_L3CNTLREG1, GEN7_WA_FOR_GEN7_L3_CONTROL);
>> +wa_write(wal, GEN7_L3_CHICKEN_MODE_REGISTER, GEN7_WA_L3_CHICKEN_MODE);
>> +
>> +/* WaForceL3Serialization:ivb */
>> +wa_write_clr(wal, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
>> +
>> +/*
>> + * WaVSThreadDispatchOverride:ivb,vlv
>> + *
>> + * This actually overrides the dispatch
>> + * mode for all thread types.
>> + */
>> +wa_write_masked_or(wal, GEN7_FF_THREAD_MODE,
>> + GEN7_FF_SCHED_MASK,
>> + GEN7_FF_TS_SCHED_HW |
>> + GEN7_FF_VS_SCHED_HW |
>> + GEN7_FF_DS_SCHED_HW);
>> +
>> +if (0) { /* causes HiZ corruption on ivb:gt1 */
>> +/* enable HiZ Raw Stall Optimization */
>> +wa_masked_dis(wal, CACHE_MODE_0_GEN7,
>> HIZ_RAW_STALL_OPT_DISABLE);
>> +}
>> +
>> +/* WaDisable4x2SubspanOptimization:ivb */
>> +wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
>> +
>> +/*
>> + * BSpec recommends 8x4 when MSAA is used,
>> + * however in practice 16x4 seems fastest.
>> + *
>> + * Note that PS/WM thread counts depend on the WIZ hashing
>> + * disable bit, which we don't touch here, but it's good
>> + * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>> + */
>> +wa_add(wal, GEN7_GT_MODE, 0,
>> + _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
>> + GEN6_WIZ_HASHING_16x4);
>> +}
>> +
>> static void
>> hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
>> *wal)
>> {
>> @@ -1033,6 +1093,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
>> struct i915_wa_list *wal)
>> skl_gt_workarounds_init(i915, wal);
>> else if (IS_HASWELL(i915))
>> hsw_gt_workarounds_init(i915, wal);
>> +else if (IS_IVYBRIDGE(i915))
>> +ivb_gt_workarounds_init(i915, wal);
>> else if (INTEL_GEN(i915) <= 8)
>> return;
>> else
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 9aca6d778220..19e1fed198c3 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7924,7 +7924,7 @@ enum {
>>
>> /* GEN7 chicken */
>> #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
>> - #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1 << 10) | (1 << 26))
>> + #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC (1 << 10)
>
> I dont have bspec but evidence is overwhelming that this is masked reg.
>
>>#define GEN9_RHWO_OPTIMIZATION_DISABLE(1 << 14)
>>
>> #define COMMON_SLICE_CHICKEN2
>> _MMIO(0x7014)
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 249ee720874c..b835e5e97515 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -7338,32 +7338,11 @@ static void ivb_init_clock_gating(struct
>> drm_i915_private *dev_priv)
>>
>> I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
>>
>> -/* WaDisableEarlyCull:ivb */
>> -I915_WRITE(_3D_CHICKEN
Re: [Intel-gfx] [PATCH 2/6] drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 62 +
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 48
> 3 files changed, 63 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 39f070bff09d..a5ba3ea8d45a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -714,6 +714,66 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> return 0;
> }
>
> +static void
> +ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + /* WaDisableEarlyCull:ivb */
> + wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL);
> +
> + /* WaDisablePSDDualDispatchEnable:ivb */
> + if (IS_IVB_GT1(i915))
> + wa_masked_en(wal,
> + GEN7_HALF_SLICE_CHICKEN1,
> + GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
> +
> + /* WaDisable_RenderCache_OperationalFlush:ivb */
> + wa_masked_dis(wal, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
> +
> + /* Apply the WaDisableRHWOOptimizationForRenderHang:ivb workaround. */
> + wa_masked_dis(wal,
> + GEN7_COMMON_SLICE_CHICKEN1,
> + GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC);
> +
> + /* WaApplyL3ControlAndL3ChickenMode:ivb */
> + wa_write(wal, GEN7_L3CNTLREG1, GEN7_WA_FOR_GEN7_L3_CONTROL);
> + wa_write(wal, GEN7_L3_CHICKEN_MODE_REGISTER, GEN7_WA_L3_CHICKEN_MODE);
> +
> + /* WaForceL3Serialization:ivb */
> + wa_write_clr(wal, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
> +
> + /*
> + * WaVSThreadDispatchOverride:ivb,vlv
> + *
> + * This actually overrides the dispatch
> + * mode for all thread types.
> + */
> + wa_write_masked_or(wal, GEN7_FF_THREAD_MODE,
> +GEN7_FF_SCHED_MASK,
> +GEN7_FF_TS_SCHED_HW |
> +GEN7_FF_VS_SCHED_HW |
> +GEN7_FF_DS_SCHED_HW);
> +
> + if (0) { /* causes HiZ corruption on ivb:gt1 */
> + /* enable HiZ Raw Stall Optimization */
> + wa_masked_dis(wal, CACHE_MODE_0_GEN7,
> HIZ_RAW_STALL_OPT_DISABLE);
> + }
> +
> + /* WaDisable4x2SubspanOptimization:ivb */
> + wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
> +
> + /*
> + * BSpec recommends 8x4 when MSAA is used,
> + * however in practice 16x4 seems fastest.
> + *
> + * Note that PS/WM thread counts depend on the WIZ hashing
> + * disable bit, which we don't touch here, but it's good
> + * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
> + */
> + wa_add(wal, GEN7_GT_MODE, 0,
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
> +GEN6_WIZ_HASHING_16x4);
> +}
> +
> static void
> hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> {
> @@ -1033,6 +1093,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> skl_gt_workarounds_init(i915, wal);
> else if (IS_HASWELL(i915))
> hsw_gt_workarounds_init(i915, wal);
> + else if (IS_IVYBRIDGE(i915))
> + ivb_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> return;
> else
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9aca6d778220..19e1fed198c3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7924,7 +7924,7 @@ enum {
>
> /* GEN7 chicken */
> #define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
> - #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC ((1 << 10) | (1 << 26))
> + #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC (1 << 10)
I dont have bspec but evidence is overwhelming that this is masked reg.
>#define GEN9_RHWO_OPTIMIZATION_DISABLE (1 << 14)
>
> #define COMMON_SLICE_CHICKEN2
> _MMIO(0x7014)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 249ee720874c..b835e5e97515 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7338,32 +7338,11 @@ static void ivb_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
>
> - /* WaDisableEarlyCull:ivb */
> - I915_WRITE(_3D_CHICKEN3,
> -_MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL));
> -
> /* WaD
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds (rev2)
== Series Details == Series: series starting with drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds (rev2) URL : https://patchwork.freedesktop.org/series/78214/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408
Re: [Intel-gfx] [PATCH] dma-fence: basic lockdep annotations
Op 05-06-2020 om 15:29 schreef Daniel Vetter: > Design is similar to the lockdep annotations for workers, but with > some twists: > > - We use a read-lock for the execution/worker/completion side, so that > this explicit annotation can be more liberally sprinkled around. > With read locks lockdep isn't going to complain if the read-side > isn't nested the same way under all circumstances, so ABBA deadlocks > are ok. Which they are, since this is an annotation only. > > - We're using non-recursive lockdep read lock mode, since in recursive > read lock mode lockdep does not catch read side hazards. And we > _very_ much want read side hazards to be caught. For full details of > this limitation see > > commit e91498589746065e3ae95d9a00b068e525eec34f > Author: Peter Zijlstra > Date: Wed Aug 23 13:13:11 2017 +0200 > > locking/lockdep/selftests: Add mixed read-write ABBA tests > > - To allow nesting of the read-side explicit annotations we explicitly > keep track of the nesting. lock_is_held() allows us to do that. > > - The wait-side annotation is a write lock, and entirely done within > dma_fence_wait() for everyone by default. > > - To be able to freely annotate helper functions I want to make it ok > to call dma_fence_begin/end_signalling from soft/hardirq context. > First attempt was using the hardirq locking context for the write > side in lockdep, but this forces all normal spinlocks nested within > dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > The approach now is to simple check in_atomic(), and for these cases > entirely rely on the might_sleep() check in dma_fence_wait(). That > will catch any wrong nesting against spinlocks from soft/hardirq > contexts. > > The idea here is that every code path that's critical for eventually > signalling a dma_fence should be annotated with > dma_fence_begin/end_signalling. The annotation ideally starts right > after a dma_fence is published (added to a dma_resv, exposed as a > sync_file fd, attached to a drm_syncobj fd, or anything else that > makes the dma_fence visible to other kernel threads), up to and > including the dma_fence_wait(). Examples are irq handlers, the > scheduler rt threads, the tail of execbuf (after the corresponding > fences are visible), any workers that end up signalling dma_fences and > really anything else. Not annotated should be code paths that only > complete fences opportunistically as the gpu progresses, like e.g. > shrinker/eviction code. > > The main class of deadlocks this is supposed to catch are: > > Thread A: > > mutex_lock(A); > mutex_unlock(A); > > dma_fence_signal(); > > Thread B: > > mutex_lock(A); > dma_fence_wait(); > mutex_unlock(A); > > Thread B is blocked on A signalling the fence, but A never gets around > to that because it cannot acquire the lock A. > > Note that dma_fence_wait() is allowed to be nested within > dma_fence_begin/end_signalling sections. To allow this to happen the > read lock needs to be upgraded to a write lock, which means that any > other lock is acquired between the dma_fence_begin_signalling() call and > the call to dma_fence_wait(), and still held, this will result in an > immediate lockdep complaint. The only other option would be to not > annotate such calls, defeating the point. Therefore these annotations > cannot be sprinkled over the code entirely mindless to avoid false > positives. > > Originally I hope that the cross-release lockdep extensions would > alleviate the need for explicit annotations: > > https://lwn.net/Articles/709849/ > > But there's a few reasons why that's not an option: > > - It's not happening in upstream, since it got reverted due to too > many false positives: > > commit e966eaeeb623f09975ef362c2866fae6f86844f9 > Author: Ingo Molnar > Date: Tue Dec 12 12:31:16 2017 +0100 > > locking/lockdep: Remove the cross-release locking checks > > This code (CONFIG_LOCKDEP_CROSSRELEASE=y and > CONFIG_LOCKDEP_COMPLETIONS=y), > while it found a number of old bugs initially, was also causing too > many > false positives that caused people to disable lockdep - which is > arguably > a worse overall outcome. > > - cross-release uses the complete() call to annotate the end of > critical sections, for dma_fence that would be dma_fence_signal(). > But we do not want all dma_fence_signal() calls to be treated as > critical, since many are opportunistic cleanup of gpu requests. If > these get stuck there's still the main completion interrupt and > workers who can unblock everyone. Automatically annotating all > dma_fence_signal() calls would hence cause false positives. > > - cross-release had some educated guesses for when a critical section > starts, like fresh syscall or fresh work callback. This would again > cause false positives without explicit annotations, since for > dma_fence the critica
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds (rev2)
== Series Details == Series: series starting with drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds (rev2) URL : https://patchwork.freedesktop.org/series/78214/ State : warning == Summary == $ dim checkpatch origin/drm-tip a9a19ef20e69 drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds 961e1996e0a8 drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds -:25: ERROR:SPACING: space required after that ',' (ctx:VxV) #25: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:721: + wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL); ^ total: 1 errors, 0 warnings, 0 checks, 153 lines checked 68e40d9f98c3 drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds -:25: ERROR:SPACING: space required after that ',' (ctx:VxV) #25: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:781: + wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL); ^ total: 1 errors, 0 warnings, 0 checks, 161 lines checked 79f6193f4ff2 drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds 3dde510c6178 drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds -:24: ERROR:SPACING: space required after that ',' (ctx:VxV) #24: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:720: + wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED); ^ total: 1 errors, 0 warnings, 0 checks, 42 lines checked 66c89c81b814 drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to workarounds -:47: ERROR:SPACING: space required after that ',' (ctx:VxV) #47: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:739: + wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED); ^ total: 1 errors, 0 warnings, 0 checks, 76 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> v2: Leave HSW_SCRATCH to set an explicit value, not or in our disable
> bit.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 48 +
> drivers/gpu/drm/i915/intel_pm.c | 39 +
> 2 files changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3eec31c5a714..fb337e2d8a27 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -178,6 +178,12 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg,
> u32 set)
> wa_write_masked_or(wal, reg, set, set);
> }
>
> +static void
> +wa_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
> +{
> + wa_write_masked_or(wal, reg, clr, 0);
> +}
> +
> static void
> wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
> {
> @@ -708,6 +714,46 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> return 0;
> }
>
> +static void
> +hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + /* L3 caching of data atomics doesn't work -- disable it. */
> + wa_write(wal, HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
> +
Reviewed-by: Mika Kuoppala
> + wa_add(wal,
> +HSW_ROW_CHICKEN3, 0,
> +_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE),
> + 0 /* XXX does this reg exist? */);
> +
> + /* WaVSRefCountFullforceMissDisable:hsw */
> + wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> +
> + wa_masked_dis(wal,
> + CACHE_MODE_0_GEN7,
> + /* WaDisable_RenderCache_OperationalFlush:hsw */
> + RC_OP_FLUSH_ENABLE |
> + /* enable HiZ Raw Stall Optimization */
> + HIZ_RAW_STALL_OPT_DISABLE);
> +
> + /* WaDisable4x2SubspanOptimization:hsw */
> + wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
> +
> + /*
> + * BSpec recommends 8x4 when MSAA is used,
> + * however in practice 16x4 seems fastest.
> + *
> + * Note that PS/WM thread counts depend on the WIZ hashing
> + * disable bit, which we don't touch here, but it's good
> + * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
> + */
> + wa_add(wal, GEN7_GT_MODE, 0,
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
> +GEN6_WIZ_HASHING_16x4);
> +
> + /* WaSampleCChickenBitEnable:hsw */
> + wa_masked_en(wal, HALF_SLICE_CHICKEN3, HSW_SAMPLE_C_PERFORMANCE);
> +}
> +
> static void
> gen9_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> {
> @@ -985,6 +1031,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> bxt_gt_workarounds_init(i915, wal);
> else if (IS_SKYLAKE(i915))
> skl_gt_workarounds_init(i915, wal);
> + else if (IS_HASWELL(i915))
> + hsw_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> return;
> else
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 26b670fa3f88..249ee720874c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7321,45 +7321,10 @@ static void bdw_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> static void hsw_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - /* L3 caching of data atomics doesn't work -- disable it. */
> - I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
> - I915_WRITE(HSW_ROW_CHICKEN3,
> -
> _MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
> -
> /* This is required by WaCatErrorRejectionIssue:hsw */
> I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
> - I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
> - GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
> -
> - /* WaVSRefCountFullforceMissDisable:hsw */
> - I915_WRITE(GEN7_FF_THREAD_MODE,
> -I915_READ(GEN7_FF_THREAD_MODE) & ~GEN7_FF_VS_REF_CNT_FFME);
> -
> - /* WaDisable_RenderCache_OperationalFlush:hsw */
> - I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
> -
> - /* enable HiZ Raw Stall Optimization */
> - I915_WRITE(CACHE_MODE_0_GEN7,
> -_MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
> -
> - /* WaDisable4x2SubspanOptimization:hsw */
> - I915_WRITE(CACHE_MODE_1,
> -_MA
[Intel-gfx] [PATCH] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
v2: Leave HSW_SCRATCH to set an explicit value, not or in our disable
bit.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 48 +
drivers/gpu/drm/i915/intel_pm.c | 39 +
2 files changed, 50 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3eec31c5a714..fb337e2d8a27 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -178,6 +178,12 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32
set)
wa_write_masked_or(wal, reg, set, set);
}
+static void
+wa_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
+{
+ wa_write_masked_or(wal, reg, clr, 0);
+}
+
static void
wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
{
@@ -708,6 +714,46 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
return 0;
}
+static void
+hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ /* L3 caching of data atomics doesn't work -- disable it. */
+ wa_write(wal, HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
+
+ wa_add(wal,
+ HSW_ROW_CHICKEN3, 0,
+ _MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE),
+ 0 /* XXX does this reg exist? */);
+
+ /* WaVSRefCountFullforceMissDisable:hsw */
+ wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
+
+ wa_masked_dis(wal,
+ CACHE_MODE_0_GEN7,
+ /* WaDisable_RenderCache_OperationalFlush:hsw */
+ RC_OP_FLUSH_ENABLE |
+ /* enable HiZ Raw Stall Optimization */
+ HIZ_RAW_STALL_OPT_DISABLE);
+
+ /* WaDisable4x2SubspanOptimization:hsw */
+ wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
+
+ /*
+* BSpec recommends 8x4 when MSAA is used,
+* however in practice 16x4 seems fastest.
+*
+* Note that PS/WM thread counts depend on the WIZ hashing
+* disable bit, which we don't touch here, but it's good
+* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
+*/
+ wa_add(wal, GEN7_GT_MODE, 0,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
+ GEN6_WIZ_HASHING_16x4);
+
+ /* WaSampleCChickenBitEnable:hsw */
+ wa_masked_en(wal, HALF_SLICE_CHICKEN3, HSW_SAMPLE_C_PERFORMANCE);
+}
+
static void
gen9_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
@@ -985,6 +1031,8 @@ gt_init_workarounds(struct drm_i915_private *i915, struct
i915_wa_list *wal)
bxt_gt_workarounds_init(i915, wal);
else if (IS_SKYLAKE(i915))
skl_gt_workarounds_init(i915, wal);
+ else if (IS_HASWELL(i915))
+ hsw_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
return;
else
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 26b670fa3f88..249ee720874c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7321,45 +7321,10 @@ static void bdw_init_clock_gating(struct
drm_i915_private *dev_priv)
static void hsw_init_clock_gating(struct drm_i915_private *dev_priv)
{
- /* L3 caching of data atomics doesn't work -- disable it. */
- I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
- I915_WRITE(HSW_ROW_CHICKEN3,
-
_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
-
/* This is required by WaCatErrorRejectionIssue:hsw */
I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
- I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
- GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
-
- /* WaVSRefCountFullforceMissDisable:hsw */
- I915_WRITE(GEN7_FF_THREAD_MODE,
- I915_READ(GEN7_FF_THREAD_MODE) & ~GEN7_FF_VS_REF_CNT_FFME);
-
- /* WaDisable_RenderCache_OperationalFlush:hsw */
- I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
-
- /* enable HiZ Raw Stall Optimization */
- I915_WRITE(CACHE_MODE_0_GEN7,
- _MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
-
- /* WaDisable4x2SubspanOptimization:hsw */
- I915_WRITE(CACHE_MODE_1,
- _MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE));
-
- /*
-* BSpec recommends 8x4 when MSAA is used,
-* however in practice 16x4 seems fastest.
-*
-
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Move hsw GT workarounds from
init_clock_gating to workarounds
URL : https://patchwork.freedesktop.org/series/78214/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8614 -> Patchwork_17925
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17925:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-kbl-7560u}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-kbl-7560u/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_17925 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- fi-tgl-u2: [PASS][2] -> [FAIL][3] ([i915#1888])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-tgl-u2/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [PASS][4] -> [DMESG-WARN][5] ([i915#1982]) +1 similar
issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-byt-j1900/igt@i915_module_l...@reload.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-byt-j1900/igt@i915_module_l...@reload.html
- fi-icl-guc: [PASS][6] -> [DMESG-WARN][7] ([i915#1982])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-icl-guc/igt@i915_module_l...@reload.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-icl-guc/igt@i915_module_l...@reload.html
- fi-icl-y: [PASS][8] -> [DMESG-WARN][9] ([i915#1982])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-icl-y/igt@i915_module_l...@reload.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-icl-y/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [PASS][10] -> [DMESG-WARN][11] ([i915#1982])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-glk-dsi: [PASS][12] -> [DMESG-WARN][13] ([i915#1982])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-glk-dsi/igt@i915_pm_...@module-reload.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-glk-dsi/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-tgl-u2: [PASS][14] -> [DMESG-WARN][15] ([i915#402])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-tgl-u2/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html
Possible fixes
* igt@i915_module_load@reload:
- fi-apl-guc: [DMESG-WARN][16] ([i915#1982]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-apl-guc/igt@i915_module_l...@reload.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-apl-guc/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-byt-j1900: [DMESG-WARN][18] ([i915#1982]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-byt-j1900/igt@i915_pm_...@module-reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-byt-j1900/igt@i915_pm_...@module-reload.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][22] ([i915#1982]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8614/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17925/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-legacy.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][24] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][25] ([i915#62] / [i915#92]) +4 similar issues
Re: [Intel-gfx] [PATCH 1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 48 +
> drivers/gpu/drm/i915/intel_pm.c | 39 +
> 2 files changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 3eec31c5a714..39f070bff09d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -178,6 +178,12 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg,
> u32 set)
> wa_write_masked_or(wal, reg, set, set);
> }
>
> +static void
> +wa_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
> +{
> + wa_write_masked_or(wal, reg, clr, 0);
> +}
> +
> static void
> wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
> {
> @@ -708,6 +714,46 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
> return 0;
> }
>
> +static void
> +hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> +{
> + /* L3 caching of data atomics doesn't work -- disable it. */
> + wa_write_or(wal, HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
Just noted here is a change. We cleared everything else but this
previously.
-Mika
> +
> + wa_add(wal,
> +HSW_ROW_CHICKEN3, 0,
> +_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE),
> + 0 /* XXX does this reg exist? */);
> +
> + /* WaVSRefCountFullforceMissDisable:hsw */
> + wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
> +
> + wa_masked_dis(wal,
> + CACHE_MODE_0_GEN7,
> + /* WaDisable_RenderCache_OperationalFlush:hsw */
> + RC_OP_FLUSH_ENABLE |
> + /* enable HiZ Raw Stall Optimization */
> + HIZ_RAW_STALL_OPT_DISABLE);
> +
> + /* WaDisable4x2SubspanOptimization:hsw */
> + wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
> +
> + /*
> + * BSpec recommends 8x4 when MSAA is used,
> + * however in practice 16x4 seems fastest.
> + *
> + * Note that PS/WM thread counts depend on the WIZ hashing
> + * disable bit, which we don't touch here, but it's good
> + * to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
> + */
> + wa_add(wal, GEN7_GT_MODE, 0,
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
> +GEN6_WIZ_HASHING_16x4);
> +
> + /* WaSampleCChickenBitEnable:hsw */
> + wa_masked_en(wal, HALF_SLICE_CHICKEN3, HSW_SAMPLE_C_PERFORMANCE);
> +}
> +
> static void
> gen9_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
> *wal)
> {
> @@ -985,6 +1031,8 @@ gt_init_workarounds(struct drm_i915_private *i915,
> struct i915_wa_list *wal)
> bxt_gt_workarounds_init(i915, wal);
> else if (IS_SKYLAKE(i915))
> skl_gt_workarounds_init(i915, wal);
> + else if (IS_HASWELL(i915))
> + hsw_gt_workarounds_init(i915, wal);
> else if (INTEL_GEN(i915) <= 8)
> return;
> else
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 26b670fa3f88..249ee720874c 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7321,45 +7321,10 @@ static void bdw_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> static void hsw_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> - /* L3 caching of data atomics doesn't work -- disable it. */
> - I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
> - I915_WRITE(HSW_ROW_CHICKEN3,
> -
> _MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
> -
> /* This is required by WaCatErrorRejectionIssue:hsw */
> I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
> - I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
> - GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
> -
> - /* WaVSRefCountFullforceMissDisable:hsw */
> - I915_WRITE(GEN7_FF_THREAD_MODE,
> -I915_READ(GEN7_FF_THREAD_MODE) & ~GEN7_FF_VS_REF_CNT_FFME);
> -
> - /* WaDisable_RenderCache_OperationalFlush:hsw */
> - I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
> -
> - /* enable HiZ Raw Stall Optimization */
> - I915_WRITE(CACHE_MODE_0_GEN7,
> -_MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
> -
> - /* WaDisable4x2SubspanOptimization:hsw */
> - I915_WRITE(CACHE_MODE_1,
> -_MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_D
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
== Series Details == Series: series starting with [1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds URL : https://patchwork.freedesktop.org/series/78214/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
== Series Details == Series: series starting with [1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds URL : https://patchwork.freedesktop.org/series/78214/ State : warning == Summary == $ dim checkpatch origin/drm-tip d733ff00e147 drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds e66a89d1b959 drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds -:25: ERROR:SPACING: space required after that ',' (ctx:VxV) #25: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:721: + wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL); ^ total: 1 errors, 0 warnings, 0 checks, 153 lines checked a5568a200839 drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds -:25: ERROR:SPACING: space required after that ',' (ctx:VxV) #25: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:781: + wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL); ^ total: 1 errors, 0 warnings, 0 checks, 161 lines checked 2bb63f1a6887 drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds 04d5cd5657aa drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds -:24: ERROR:SPACING: space required after that ',' (ctx:VxV) #24: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:720: + wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED); ^ total: 1 errors, 0 warnings, 0 checks, 42 lines checked bb704549ca19 drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to workarounds -:47: ERROR:SPACING: space required after that ',' (ctx:VxV) #47: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:739: + wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED); ^ total: 1 errors, 0 warnings, 0 checks, 76 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
Hi, On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote: > On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > Introducing a global lockmap that cannot capture the rules correctly, > > Can you document the rules all drivers should be following then, > because from here it looks to get refactored every version of i915, > and it would be nice if we could all aim for the same set of things > roughly. We've already had enough problems with amdgpu vs i915 vs > everyone else with fences, if this stops that in the future then I'd > rather we have that than just some unwritten rules per driver and > untestable. As someone who has sunk a bunch of work into explicit-fencing awareness in my compositor so I can never be blocked, I'd be disappointed if the infrastructure was ultimately pointless because the documented fencing rules were \_o_/ or thereabouts. Lockdep definitely isn't my area of expertise so I can't comment on the patch per se, but having something to ensure we don't hit deadlocks sure seems a lot better than nothing. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/dp_mst: Fix the DDC I2C device unregistration of an MST port (rev2)
== Series Details ==
Series: series starting with [1/3] drm/dp_mst: Fix the DDC I2C device
unregistration of an MST port (rev2)
URL : https://patchwork.freedesktop.org/series/78100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8608_full -> Patchwork_17919_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17919_full:
### Piglit changes ###
Possible regressions
*
spec@glsl-4.20@execution@conversion@frag-conversion-implicit-mat4-dmat4-zero-sign
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/pig-icl-1065g7/spec@glsl-4.20@execution@convers...@frag-conversion-implicit-mat4-dmat4-zero-sign.html
*
spec@glsl-4.20@execution@conversion@vert-conversion-implicit-mat3-dmat3-zero-sign
(NEW):
- {pig-icl-1065g7}: NOTRUN -> [CRASH][2] +4 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/pig-icl-1065g7/spec@glsl-4.20@execution@convers...@vert-conversion-implicit-mat3-dmat3-zero-sign.html
New tests
-
New tests have been introduced between CI_DRM_8608_full and
Patchwork_17919_full:
### New Piglit tests (6) ###
* spec@glsl-4.00@execution@built-in-functions@gs-op-div-dmat4x3-dmat4x3:
- Statuses : 1 crash(s)
- Exec time: [98.33] s
*
spec@glsl-4.20@execution@conversion@frag-conversion-implicit-mat4-dmat4-zero-sign:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
*
spec@glsl-4.20@execution@conversion@geom-conversion-implicit-mat3-dmat3-zero-sign:
- Statuses : 1 crash(s)
- Exec time: [15.54] s
*
spec@glsl-4.20@execution@conversion@geom-conversion-implicit-mat4-dmat4-zero-sign:
- Statuses : 1 crash(s)
- Exec time: [57.24] s
*
spec@glsl-4.20@execution@conversion@vert-conversion-implicit-mat3-dmat3-zero-sign:
- Statuses : 1 crash(s)
- Exec time: [3.59] s
*
spec@glsl-4.20@execution@conversion@vert-conversion-implicit-mat3x4-dmat3x4-zero-sign:
- Statuses : 1 crash(s)
- Exec time: [25.06] s
Known issues
Here are the changes found in Patchwork_17919_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_schedule@implicit-boths@bcs0:
- shard-snb: [PASS][3] -> [INCOMPLETE][4] ([i915#82])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-snb4/igt@gem_exec_schedule@implicit-bo...@bcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-snb2/igt@gem_exec_schedule@implicit-bo...@bcs0.html
* igt@gem_exec_suspend@basic-s3:
- shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#93] / [i915#95])
+3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-kbl6/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-kbl2/igt@gem_exec_susp...@basic-s3.html
* igt@gem_exec_whisper@basic-forked-all:
- shard-glk: [PASS][7] -> [DMESG-WARN][8] ([i915#118] / [i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-glk4/igt@gem_exec_whis...@basic-forked-all.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-glk9/igt@gem_exec_whis...@basic-forked-all.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-skl2/igt@i915_susp...@sysfs-reader.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-skl6/igt@i915_susp...@sysfs-reader.html
* igt@kms_big_fb@y-tiled-64bpp-rotate-0:
- shard-glk: [PASS][11] -> [DMESG-FAIL][12] ([i915#118] /
[i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-glk2/igt@kms_big...@y-tiled-64bpp-rotate-0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html
* igt@kms_cursor_crc@pipe-a-cursor-64x21-offscreen:
- shard-apl: [PASS][13] -> [DMESG-WARN][14] ([i915#95]) +16
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-apl6/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
- shard-kbl: [PASS][15] -> [DMESG-FAIL][16] ([i915#54] /
[i915#95]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8608/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17919/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-64x21-offscreen.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][17] -> [D
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote: > > Quoting Daniel Vetter (2020-06-04 09:12:09) > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > > this explicit annotation can be more liberally sprinkled around. > > With read locks lockdep isn't going to complain if the read-side > > isn't nested the same way under all circumstances, so ABBA deadlocks > > are ok. Which they are, since this is an annotation only. > > > > - We're using non-recursive lockdep read lock mode, since in recursive > > read lock mode lockdep does not catch read side hazards. And we > > _very_ much want read side hazards to be caught. For full details of > > this limitation see > > > > commit e91498589746065e3ae95d9a00b068e525eec34f > > Author: Peter Zijlstra > > Date: Wed Aug 23 13:13:11 2017 +0200 > > > > locking/lockdep/selftests: Add mixed read-write ABBA tests > > > > - To allow nesting of the read-side explicit annotations we explicitly > > keep track of the nesting. lock_is_held() allows us to do that. > > > > - The wait-side annotation is a write lock, and entirely done within > > dma_fence_wait() for everyone by default. > > > > - To be able to freely annotate helper functions I want to make it ok > > to call dma_fence_begin/end_signalling from soft/hardirq context. > > First attempt was using the hardirq locking context for the write > > side in lockdep, but this forces all normal spinlocks nested within > > dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > > > The approach now is to simple check in_atomic(), and for these cases > > entirely rely on the might_sleep() check in dma_fence_wait(). That > > will catch any wrong nesting against spinlocks from soft/hardirq > > contexts. > > > > The idea here is that every code path that's critical for eventually > > signalling a dma_fence should be annotated with > > dma_fence_begin/end_signalling. The annotation ideally starts right > > after a dma_fence is published (added to a dma_resv, exposed as a > > sync_file fd, attached to a drm_syncobj fd, or anything else that > > makes the dma_fence visible to other kernel threads), up to and > > including the dma_fence_wait(). Examples are irq handlers, the > > scheduler rt threads, the tail of execbuf (after the corresponding > > fences are visible), any workers that end up signalling dma_fences and > > really anything else. Not annotated should be code paths that only > > complete fences opportunistically as the gpu progresses, like e.g. > > shrinker/eviction code. > > > > The main class of deadlocks this is supposed to catch are: > > > > Thread A: > > > > mutex_lock(A); > > mutex_unlock(A); > > > > dma_fence_signal(); > > > > Thread B: > > > > mutex_lock(A); > > dma_fence_wait(); > > mutex_unlock(A); > > > > Thread B is blocked on A signalling the fence, but A never gets around > > to that because it cannot acquire the lock A. > > > > Note that dma_fence_wait() is allowed to be nested within > > dma_fence_begin/end_signalling sections. To allow this to happen the > > read lock needs to be upgraded to a write lock, which means that any > > other lock is acquired between the dma_fence_begin_signalling() call and > > the call to dma_fence_wait(), and still held, this will result in an > > immediate lockdep complaint. The only other option would be to not > > annotate such calls, defeating the point. Therefore these annotations > > cannot be sprinkled over the code entirely mindless to avoid false > > positives. > > > > v2: handle soft/hardirq ctx better against write side and dont forget > > EXPORT_SYMBOL, drivers can't use this otherwise. > > > > v3: Kerneldoc. > > > > v4: Some spelling fixes from Mika > > > > Cc: Mika Kuoppala > > Cc: Thomas Hellstrom > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: linux-r...@vger.kernel.org > > Cc: amd-...@lists.freedesktop.org > > Cc: intel-gfx@lists.freedesktop.org > > Cc: Chris Wilson > > Cc: Maarten Lankhorst > > Cc: Christian König > > Signed-off-by: Daniel Vetter > > Introducing a global lockmap that cannot capture the rules correctly, Can you document the rules all drivers should be following then, because from here it looks to get refactored every version of i915, and it would be nice if we could all aim for the same set of things roughly. We've already had enough problems with amdgpu vs i915 vs everyone else with fences, if this stops that in the future then I'd rather we have that than just some unwritten rules per driver and untestable. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On Thu, Jun 11, 2020 at 09:30:12AM +0200, Thomas Hellström (Intel) wrote: > > On 6/4/20 10:12 AM, Daniel Vetter wrote: > > Two in one go: > > - it is allowed to call dma_fence_wait() while holding a > >dma_resv_lock(). This is fundamental to how eviction works with ttm, > >so required. > > > > - it is allowed to call dma_fence_wait() from memory reclaim contexts, > >specifically from shrinker callbacks (which i915 does), and from mmu > >notifier callbacks (which amdgpu does, and which i915 sometimes also > >does, and probably always should, but that's kinda a debate). Also > >for stuff like HMM we really need to be able to do this, or things > >get real dicey. > > > > Consequence is that any critical path necessary to get to a > > dma_fence_signal for a fence must never a) call dma_resv_lock nor b) > > allocate memory with GFP_KERNEL. Also by implication of > > dma_resv_lock(), no userspace faulting allowed. That's some supremely > > obnoxious limitations, which is why we need to sprinkle the right > > annotations to all relevant paths. > > > > The one big locking context we're leaving out here is mmu notifiers, > > added in > > > > commit 23b68395c7c78a764e8963fc15a7cfd318bf187f > > Author: Daniel Vetter > > Date: Mon Aug 26 22:14:21 2019 +0200 > > > > mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end > > > > that one covers a lot of other callsites, and it's also allowed to > > wait on dma-fences from mmu notifiers. But there's no ready-made > > functions exposed to prime this, so I've left it out for now. > > > > v2: Also track against mmu notifier context. > > > > v3: kerneldoc to spec the cross-driver contract. Note that currently > > i915 throws in a hard-coded 10s timeout on foreign fences (not sure > > why that was done, but it's there), which is why that rule is worded > > with SHOULD instead of MUST. > > > > Also some of the mmu_notifier/shrinker rules might surprise SoC > > drivers, I haven't fully audited them all. Which is infeasible anyway, > > we'll need to run them with lockdep and dma-fence annotations and see > > what goes boom. > > > > v4: A spelling fix from Mika > > > > Cc: Mika Kuoppala > > Cc: Thomas Hellstrom > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: linux-r...@vger.kernel.org > > Cc: amd-...@lists.freedesktop.org > > Cc: intel-gfx@lists.freedesktop.org > > Cc: Chris Wilson > > Cc: Maarten Lankhorst > > Cc: Christian König > > Signed-off-by: Daniel Vetter > > --- > > Documentation/driver-api/dma-buf.rst | 6 > > drivers/dma-buf/dma-fence.c | 41 > > drivers/dma-buf/dma-resv.c | 4 +++ > > include/linux/dma-fence.h| 1 + > > 4 files changed, 52 insertions(+) > > I still have my doubts about allowing fence waiting from within shrinkers. > IMO ideally they should use a trywait approach, in order to allow memory > allocation during command submission for drivers that > publish fences before command submission. (Since early reservation object > release requires that). Yeah it is a bit annoying, e.g. for drm/scheduler I think we'll end up with a mempool to make sure it can handle it's allocations. > But since drivers are already waiting from within shrinkers and I take your > word for HMM requiring this, Yeah the big trouble is HMM and mmu notifiers. That's the really awkward one, the shrinker one is a lot less established. I do wonder whether the mmu notifier constraint should only be set when mmu notifiers are enabled, since on a bunch of arm-soc gpu drivers that stuff just doesn't matter. But I expect that sooner or later these arm gpus will show up in bigger arm cores, where you might want to have kvm and maybe device virtualization and stuff, and then you need mmu notifiers. Plus having a very clear and consistent cross-driver api contract is imo better than leaving this up to drivers and then having incompatible assumptions. I've pinged a bunch of armsoc gpu driver people and ask them how much this hurts, so that we have a clear answer. On x86 I don't think we have much of a choice on this, with userptr in amd and i915 and hmm work in nouveau (but nouveau I think doesn't use dma_fence in there). I think it'll take us a while to really bottom out on this specific question here. -Daniel > > Reviewed-by: Thomas Hellström > > -- 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
[Intel-gfx] [PATCH 2/6] drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 62 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 48
3 files changed, 63 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 39f070bff09d..a5ba3ea8d45a 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -714,6 +714,66 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
return 0;
}
+static void
+ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ /* WaDisableEarlyCull:ivb */
+ wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL);
+
+ /* WaDisablePSDDualDispatchEnable:ivb */
+ if (IS_IVB_GT1(i915))
+ wa_masked_en(wal,
+GEN7_HALF_SLICE_CHICKEN1,
+GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
+
+ /* WaDisable_RenderCache_OperationalFlush:ivb */
+ wa_masked_dis(wal, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
+
+ /* Apply the WaDisableRHWOOptimizationForRenderHang:ivb workaround. */
+ wa_masked_dis(wal,
+ GEN7_COMMON_SLICE_CHICKEN1,
+ GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC);
+
+ /* WaApplyL3ControlAndL3ChickenMode:ivb */
+ wa_write(wal, GEN7_L3CNTLREG1, GEN7_WA_FOR_GEN7_L3_CONTROL);
+ wa_write(wal, GEN7_L3_CHICKEN_MODE_REGISTER, GEN7_WA_L3_CHICKEN_MODE);
+
+ /* WaForceL3Serialization:ivb */
+ wa_write_clr(wal, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
+
+ /*
+* WaVSThreadDispatchOverride:ivb,vlv
+*
+* This actually overrides the dispatch
+* mode for all thread types.
+*/
+ wa_write_masked_or(wal, GEN7_FF_THREAD_MODE,
+ GEN7_FF_SCHED_MASK,
+ GEN7_FF_TS_SCHED_HW |
+ GEN7_FF_VS_SCHED_HW |
+ GEN7_FF_DS_SCHED_HW);
+
+ if (0) { /* causes HiZ corruption on ivb:gt1 */
+ /* enable HiZ Raw Stall Optimization */
+ wa_masked_dis(wal, CACHE_MODE_0_GEN7,
HIZ_RAW_STALL_OPT_DISABLE);
+ }
+
+ /* WaDisable4x2SubspanOptimization:ivb */
+ wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
+
+ /*
+* BSpec recommends 8x4 when MSAA is used,
+* however in practice 16x4 seems fastest.
+*
+* Note that PS/WM thread counts depend on the WIZ hashing
+* disable bit, which we don't touch here, but it's good
+* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
+*/
+ wa_add(wal, GEN7_GT_MODE, 0,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
+ GEN6_WIZ_HASHING_16x4);
+}
+
static void
hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
@@ -1033,6 +1093,8 @@ gt_init_workarounds(struct drm_i915_private *i915, struct
i915_wa_list *wal)
skl_gt_workarounds_init(i915, wal);
else if (IS_HASWELL(i915))
hsw_gt_workarounds_init(i915, wal);
+ else if (IS_IVYBRIDGE(i915))
+ ivb_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
return;
else
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9aca6d778220..19e1fed198c3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7924,7 +7924,7 @@ enum {
/* GEN7 chicken */
#define GEN7_COMMON_SLICE_CHICKEN1 _MMIO(0x7010)
- #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC((1 << 10) | (1 << 26))
+ #define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC(1 << 10)
#define GEN9_RHWO_OPTIMIZATION_DISABLE (1 << 14)
#define COMMON_SLICE_CHICKEN2 _MMIO(0x7014)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 249ee720874c..b835e5e97515 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7338,32 +7338,11 @@ static void ivb_init_clock_gating(struct
drm_i915_private *dev_priv)
I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
- /* WaDisableEarlyCull:ivb */
- I915_WRITE(_3D_CHICKEN3,
- _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL));
-
/* WaDisableBackToBackFlipFix:ivb */
I915_WRITE(IVB_CHICKEN3,
CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE |
CHICKEN3_DGMG_DONE_FIX_DISABLE);
- /* WaDisablePSDDualDispatchEnable:ivb */
[Intel-gfx] [PATCH 4/6] drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 41 +
drivers/gpu/drm/i915/intel_pm.c | 33 -
2 files changed, 41 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 688ca25d79d0..7b4f3434eb6b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -714,6 +714,45 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
return 0;
}
+static void
+snb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ /* WaDisableHiZPlanesWhenMSAAEnabled:snb */
+ wa_masked_en(wal,
+_3D_CHICKEN,
+_3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB);
+
+ /* WaDisable_RenderCache_OperationalFlush:snb */
+ wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
+
+ /*
+* BSpec recoomends 8x4 when MSAA is used,
+* however in practice 16x4 seems fastest.
+*
+* Note that PS/WM thread counts depend on the WIZ hashing
+* disable bit, which we don't touch here, but it's good
+* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
+*/
+ wa_add(wal,
+ GEN6_GT_MODE, 0,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
+ GEN6_WIZ_HASHING_16x4);
+
+ wa_masked_dis(wal, CACHE_MODE_0, CM0_STC_EVICT_DISABLE_LRA_SNB);
+
+ wa_masked_en(wal,
+_3D_CHICKEN3,
+/* WaStripsFansDisableFastClipPerformanceFix:snb */
+_3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL |
+/*
+ * Bspec says:
+ * "This bit must be set if 3DSTATE_CLIP clip mode is set
+ * to normal and 3DSTATE_SF number of SF output attributes
+ * is more than 16."
+ */
+ _3D_CHICKEN3_SF_DISABLE_PIPELINED_ATTR_FETCH);
+}
+
static void
ivb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
@@ -1154,6 +1193,8 @@ gt_init_workarounds(struct drm_i915_private *i915, struct
i915_wa_list *wal)
vlv_gt_workarounds_init(i915, wal);
else if (IS_IVYBRIDGE(i915))
ivb_gt_workarounds_init(i915, wal);
+ else if (IS_GEN(i915, 6))
+ snb_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
return;
else
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 29abde47e987..b4bea6451418 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6993,27 +6993,6 @@ static void gen6_init_clock_gating(struct
drm_i915_private *dev_priv)
I915_READ(ILK_DISPLAY_CHICKEN2) |
ILK_ELPIN_409_SELECT);
- /* WaDisableHiZPlanesWhenMSAAEnabled:snb */
- I915_WRITE(_3D_CHICKEN,
-
_MASKED_BIT_ENABLE(_3D_CHICKEN_HIZ_PLANE_DISABLE_MSAA_4X_SNB));
-
- /* WaDisable_RenderCache_OperationalFlush:snb */
- I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
-
- /*
-* BSpec recoomends 8x4 when MSAA is used,
-* however in practice 16x4 seems fastest.
-*
-* Note that PS/WM thread counts depend on the WIZ hashing
-* disable bit, which we don't touch here, but it's good
-* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
-*/
- I915_WRITE(GEN6_GT_MODE,
- _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
-
- I915_WRITE(CACHE_MODE_0,
- _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
-
I915_WRITE(GEN6_UCGCTL1,
I915_READ(GEN6_UCGCTL1) |
GEN6_BLBUNIT_CLOCK_GATE_DISABLE |
@@ -7036,18 +7015,6 @@ static void gen6_init_clock_gating(struct
drm_i915_private *dev_priv)
GEN6_RCPBUNIT_CLOCK_GATE_DISABLE |
GEN6_RCCUNIT_CLOCK_GATE_DISABLE);
- /* WaStripsFansDisableFastClipPerformanceFix:snb */
- I915_WRITE(_3D_CHICKEN3,
- _MASKED_BIT_ENABLE(_3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL));
-
- /*
-* Bspec says:
-* "This bit must be set if 3DSTATE_CLIP clip mode is set to normal and
-* 3DSTATE_SF number of SF output attributes is more than 16."
-*/
- I915_WRITE(_3D_CHICKEN3,
-
_MASKED_BIT_ENABLE(_3D_CHICKEN3_SF_DISABLE_PIPELINED_ATTR_FETCH));
-
/*
* According to the spec the following bits should be
* set in order to enable memory self-refresh and fbc:
[Intel-gfx] [PATCH 1/6] drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 48 +
drivers/gpu/drm/i915/intel_pm.c | 39 +
2 files changed, 50 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3eec31c5a714..39f070bff09d 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -178,6 +178,12 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32
set)
wa_write_masked_or(wal, reg, set, set);
}
+static void
+wa_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
+{
+ wa_write_masked_or(wal, reg, clr, 0);
+}
+
static void
wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
{
@@ -708,6 +714,46 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
return 0;
}
+static void
+hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ /* L3 caching of data atomics doesn't work -- disable it. */
+ wa_write_or(wal, HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
+
+ wa_add(wal,
+ HSW_ROW_CHICKEN3, 0,
+ _MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE),
+ 0 /* XXX does this reg exist? */);
+
+ /* WaVSRefCountFullforceMissDisable:hsw */
+ wa_write_clr(wal, GEN7_FF_THREAD_MODE, GEN7_FF_VS_REF_CNT_FFME);
+
+ wa_masked_dis(wal,
+ CACHE_MODE_0_GEN7,
+ /* WaDisable_RenderCache_OperationalFlush:hsw */
+ RC_OP_FLUSH_ENABLE |
+ /* enable HiZ Raw Stall Optimization */
+ HIZ_RAW_STALL_OPT_DISABLE);
+
+ /* WaDisable4x2SubspanOptimization:hsw */
+ wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
+
+ /*
+* BSpec recommends 8x4 when MSAA is used,
+* however in practice 16x4 seems fastest.
+*
+* Note that PS/WM thread counts depend on the WIZ hashing
+* disable bit, which we don't touch here, but it's good
+* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
+*/
+ wa_add(wal, GEN7_GT_MODE, 0,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
+ GEN6_WIZ_HASHING_16x4);
+
+ /* WaSampleCChickenBitEnable:hsw */
+ wa_masked_en(wal, HALF_SLICE_CHICKEN3, HSW_SAMPLE_C_PERFORMANCE);
+}
+
static void
gen9_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
@@ -985,6 +1031,8 @@ gt_init_workarounds(struct drm_i915_private *i915, struct
i915_wa_list *wal)
bxt_gt_workarounds_init(i915, wal);
else if (IS_SKYLAKE(i915))
skl_gt_workarounds_init(i915, wal);
+ else if (IS_HASWELL(i915))
+ hsw_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
return;
else
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 26b670fa3f88..249ee720874c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7321,45 +7321,10 @@ static void bdw_init_clock_gating(struct
drm_i915_private *dev_priv)
static void hsw_init_clock_gating(struct drm_i915_private *dev_priv)
{
- /* L3 caching of data atomics doesn't work -- disable it. */
- I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
- I915_WRITE(HSW_ROW_CHICKEN3,
-
_MASKED_BIT_ENABLE(HSW_ROW_CHICKEN3_L3_GLOBAL_ATOMICS_DISABLE));
-
/* This is required by WaCatErrorRejectionIssue:hsw */
I915_WRITE(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG,
- I915_READ(GEN7_SQ_CHICKEN_MBCUNIT_CONFIG) |
- GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB);
-
- /* WaVSRefCountFullforceMissDisable:hsw */
- I915_WRITE(GEN7_FF_THREAD_MODE,
- I915_READ(GEN7_FF_THREAD_MODE) & ~GEN7_FF_VS_REF_CNT_FFME);
-
- /* WaDisable_RenderCache_OperationalFlush:hsw */
- I915_WRITE(CACHE_MODE_0_GEN7, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
-
- /* enable HiZ Raw Stall Optimization */
- I915_WRITE(CACHE_MODE_0_GEN7,
- _MASKED_BIT_DISABLE(HIZ_RAW_STALL_OPT_DISABLE));
-
- /* WaDisable4x2SubspanOptimization:hsw */
- I915_WRITE(CACHE_MODE_1,
- _MASKED_BIT_ENABLE(PIXEL_SUBSPAN_COLLECT_OPT_DISABLE));
-
- /*
-* BSpec recommends 8x4 when MSAA is used,
-* however in practice 16x4 seems fastest.
-*
-* Note that PS/WM thread counts depend on the WIZ hashing
-* disable bit, which we
Re: [Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations
Quoting Daniel Vetter (2020-06-04 09:12:09) > Design is similar to the lockdep annotations for workers, but with > some twists: > > - We use a read-lock for the execution/worker/completion side, so that > this explicit annotation can be more liberally sprinkled around. > With read locks lockdep isn't going to complain if the read-side > isn't nested the same way under all circumstances, so ABBA deadlocks > are ok. Which they are, since this is an annotation only. > > - We're using non-recursive lockdep read lock mode, since in recursive > read lock mode lockdep does not catch read side hazards. And we > _very_ much want read side hazards to be caught. For full details of > this limitation see > > commit e91498589746065e3ae95d9a00b068e525eec34f > Author: Peter Zijlstra > Date: Wed Aug 23 13:13:11 2017 +0200 > > locking/lockdep/selftests: Add mixed read-write ABBA tests > > - To allow nesting of the read-side explicit annotations we explicitly > keep track of the nesting. lock_is_held() allows us to do that. > > - The wait-side annotation is a write lock, and entirely done within > dma_fence_wait() for everyone by default. > > - To be able to freely annotate helper functions I want to make it ok > to call dma_fence_begin/end_signalling from soft/hardirq context. > First attempt was using the hardirq locking context for the write > side in lockdep, but this forces all normal spinlocks nested within > dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > The approach now is to simple check in_atomic(), and for these cases > entirely rely on the might_sleep() check in dma_fence_wait(). That > will catch any wrong nesting against spinlocks from soft/hardirq > contexts. > > The idea here is that every code path that's critical for eventually > signalling a dma_fence should be annotated with > dma_fence_begin/end_signalling. The annotation ideally starts right > after a dma_fence is published (added to a dma_resv, exposed as a > sync_file fd, attached to a drm_syncobj fd, or anything else that > makes the dma_fence visible to other kernel threads), up to and > including the dma_fence_wait(). Examples are irq handlers, the > scheduler rt threads, the tail of execbuf (after the corresponding > fences are visible), any workers that end up signalling dma_fences and > really anything else. Not annotated should be code paths that only > complete fences opportunistically as the gpu progresses, like e.g. > shrinker/eviction code. > > The main class of deadlocks this is supposed to catch are: > > Thread A: > > mutex_lock(A); > mutex_unlock(A); > > dma_fence_signal(); > > Thread B: > > mutex_lock(A); > dma_fence_wait(); > mutex_unlock(A); > > Thread B is blocked on A signalling the fence, but A never gets around > to that because it cannot acquire the lock A. > > Note that dma_fence_wait() is allowed to be nested within > dma_fence_begin/end_signalling sections. To allow this to happen the > read lock needs to be upgraded to a write lock, which means that any > other lock is acquired between the dma_fence_begin_signalling() call and > the call to dma_fence_wait(), and still held, this will result in an > immediate lockdep complaint. The only other option would be to not > annotate such calls, defeating the point. Therefore these annotations > cannot be sprinkled over the code entirely mindless to avoid false > positives. > > v2: handle soft/hardirq ctx better against write side and dont forget > EXPORT_SYMBOL, drivers can't use this otherwise. > > v3: Kerneldoc. > > v4: Some spelling fixes from Mika > > Cc: Mika Kuoppala > Cc: Thomas Hellstrom > Cc: linux-me...@vger.kernel.org > Cc: linaro-mm-...@lists.linaro.org > Cc: linux-r...@vger.kernel.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian König > Signed-off-by: Daniel Vetter Introducing a global lockmap that cannot capture the rules correctly, Nacked-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 59
drivers/gpu/drm/i915/intel_pm.c | 61 -
2 files changed, 59 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a5ba3ea8d45a..688ca25d79d0 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -774,6 +774,63 @@ ivb_gt_workarounds_init(struct drm_i915_private *i915,
struct i915_wa_list *wal)
GEN6_WIZ_HASHING_16x4);
}
+static void
+vlv_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ /* WaDisableEarlyCull:vlv */
+ wa_masked_en(wal,_3D_CHICKEN3, _3D_CHICKEN_SF_DISABLE_OBJEND_CULL);
+
+ /* WaPsdDispatchEnable:vlv */
+ /* WaDisablePSDDualDispatchEnable:vlv */
+ wa_masked_en(wal,
+GEN7_HALF_SLICE_CHICKEN1,
+GEN7_MAX_PS_THREAD_DEP |
+GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE);
+
+ /* WaDisable_RenderCache_OperationalFlush:vlv */
+ wa_masked_dis(wal, CACHE_MODE_0_GEN7, RC_OP_FLUSH_ENABLE);
+
+ /* WaForceL3Serialization:vlv */
+ wa_write_clr(wal, GEN7_L3SQCREG4, L3SQ_URB_READ_CAM_MATCH_DISABLE);
+
+ /*
+* WaVSThreadDispatchOverride:ivb,vlv
+*
+* This actually overrides the dispatch
+* mode for all thread types.
+*/
+ wa_write_masked_or(wal,
+ GEN7_FF_THREAD_MODE,
+ GEN7_FF_SCHED_MASK,
+ GEN7_FF_TS_SCHED_HW |
+ GEN7_FF_VS_SCHED_HW |
+ GEN7_FF_DS_SCHED_HW);
+
+ /*
+* BSpec says this must be set, even though
+* WaDisable4x2SubspanOptimization isn't listed for VLV.
+*/
+ wa_masked_en(wal, CACHE_MODE_1, PIXEL_SUBSPAN_COLLECT_OPT_DISABLE);
+
+ /*
+* BSpec recommends 8x4 when MSAA is used,
+* however in practice 16x4 seems fastest.
+*
+* Note that PS/WM thread counts depend on the WIZ hashing
+* disable bit, which we don't touch here, but it's good
+* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
+*/
+ wa_add(wal, GEN7_GT_MODE, 0,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4),
+ GEN6_WIZ_HASHING_16x4);
+
+ /*
+* WaIncreaseL3CreditsForVLVB0:vlv
+* This is the hardware default actually.
+*/
+ wa_write(wal, GEN7_L3SQCREG1, VLV_B0_WA_L3SQCREG1_VALUE);
+}
+
static void
hsw_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
@@ -1093,6 +1150,8 @@ gt_init_workarounds(struct drm_i915_private *i915, struct
i915_wa_list *wal)
skl_gt_workarounds_init(i915, wal);
else if (IS_HASWELL(i915))
hsw_gt_workarounds_init(i915, wal);
+ else if (IS_VALLEYVIEW(i915))
+ vlv_gt_workarounds_init(i915, wal);
else if (IS_IVYBRIDGE(i915))
ivb_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b835e5e97515..29abde47e987 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7077,24 +7077,6 @@ static void gen6_init_clock_gating(struct
drm_i915_private *dev_priv)
gen6_check_mch_setup(dev_priv);
}
-static void gen7_setup_fixed_func_scheduler(struct drm_i915_private *dev_priv)
-{
- u32 reg = I915_READ(GEN7_FF_THREAD_MODE);
-
- /*
-* WaVSThreadDispatchOverride:ivb,vlv
-*
-* This actually overrides the dispatch
-* mode for all thread types.
-*/
- reg &= ~GEN7_FF_SCHED_MASK;
- reg |= GEN7_FF_TS_SCHED_HW;
- reg |= GEN7_FF_VS_SCHED_HW;
- reg |= GEN7_FF_DS_SCHED_HW;
-
- I915_WRITE(GEN7_FF_THREAD_MODE, reg);
-}
-
static void lpt_init_clock_gating(struct drm_i915_private *dev_priv)
{
/*
@@ -7381,28 +7363,11 @@ static void ivb_init_clock_gating(struct
drm_i915_private *dev_priv)
static void vlv_init_clock_gating(struct drm_i915_private *dev_priv)
{
- /* WaDisableEarlyCull:vlv */
- I915_WRITE(_3D_CHICKEN3,
- _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL));
-
/* WaDisableBackToBackFlipFix:vlv */
I915_WRITE(IVB_CHICKEN3,
CHICKEN3_DGMG_REQ_OUT_FIX_DISABLE |
CHICKEN3_DGMG_DONE_FIX_DISABLE);
- /* WaPsdDispatchEnable:vlv */
- /* WaDisablePSDDualDispatchEnable:vlv */
- I915_WRITE(GEN7_HALF_SLICE_CHICKEN1,
-
[Intel-gfx] [PATCH 5/6] drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 14 ++
drivers/gpu/drm/i915/intel_pm.c | 10 --
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 7b4f3434eb6b..f8b9e104378e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -714,6 +714,18 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
return 0;
}
+static void
+ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
+
+ /* WaDisableRenderCachePipelinedFlush:ilk */
+ wa_masked_en(wal, CACHE_MODE_0, CM0_PIPELINED_RENDER_FLUSH_DISABLE);
+
+ /* WaDisable_RenderCache_OperationalFlush:ilk */
+ wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
+}
+
static void
snb_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
{
@@ -1195,6 +1207,8 @@ gt_init_workarounds(struct drm_i915_private *i915, struct
i915_wa_list *wal)
ivb_gt_workarounds_init(i915, wal);
else if (IS_GEN(i915, 6))
snb_gt_workarounds_init(i915, wal);
+ else if (IS_GEN(i915, 5))
+ ilk_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
return;
else
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b4bea6451418..7d82a7144a13 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6921,16 +6921,6 @@ static void ilk_init_clock_gating(struct
drm_i915_private *dev_priv)
I915_WRITE(ILK_DISPLAY_CHICKEN2,
I915_READ(ILK_DISPLAY_CHICKEN2) |
ILK_ELPIN_409_SELECT);
- I915_WRITE(_3D_CHICKEN2,
- _3D_CHICKEN2_WM_READ_PIPELINED << 16 |
- _3D_CHICKEN2_WM_READ_PIPELINED);
-
- /* WaDisableRenderCachePipelinedFlush:ilk */
- I915_WRITE(CACHE_MODE_0,
- _MASKED_BIT_ENABLE(CM0_PIPELINED_RENDER_FLUSH_DISABLE));
-
- /* WaDisable_RenderCache_OperationalFlush:ilk */
- I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
g4x_disable_trickle_feed(dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to workarounds
Rescue the GT workarounds from being buried inside init_clock_gating so
that we remember to apply them after a GT reset, and that they are
included in our verification that the workarounds are applied.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 +
drivers/gpu/drm/i915/intel_pm.c | 15
2 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index f8b9e104378e..7b4be64585c3 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -715,15 +715,28 @@ int intel_engine_emit_ctx_wa(struct i915_request *rq)
}
static void
-ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+gen4_gt_workarounds_init(struct drm_i915_private *i915,
+struct i915_wa_list *wal)
{
- wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
+ /* WaDisable_RenderCache_OperationalFlush:gen4,ilk */
+ wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
+}
+
+static void
+g4x_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ gen4_gt_workarounds_init(i915, wal);
- /* WaDisableRenderCachePipelinedFlush:ilk */
+ /* WaDisableRenderCachePipelinedFlush:g4x,ilk */
wa_masked_en(wal, CACHE_MODE_0, CM0_PIPELINED_RENDER_FLUSH_DISABLE);
+}
- /* WaDisable_RenderCache_OperationalFlush:ilk */
- wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
+static void
+ilk_gt_workarounds_init(struct drm_i915_private *i915, struct i915_wa_list
*wal)
+{
+ g4x_gt_workarounds_init(i915, wal);
+
+ wa_masked_en(wal,_3D_CHICKEN2, _3D_CHICKEN2_WM_READ_PIPELINED);
}
static void
@@ -1209,6 +1222,10 @@ gt_init_workarounds(struct drm_i915_private *i915,
struct i915_wa_list *wal)
snb_gt_workarounds_init(i915, wal);
else if (IS_GEN(i915, 5))
ilk_gt_workarounds_init(i915, wal);
+ else if (IS_G4X(i915))
+ g4x_gt_workarounds_init(i915, wal);
+ else if (IS_GEN(i915, 4))
+ gen4_gt_workarounds_init(i915, wal);
else if (INTEL_GEN(i915) <= 8)
return;
else
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7d82a7144a13..2a32d6230795 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7399,13 +7399,6 @@ static void g4x_init_clock_gating(struct
drm_i915_private *dev_priv)
dspclk_gate |= DSSUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, dspclk_gate);
- /* WaDisableRenderCachePipelinedFlush */
- I915_WRITE(CACHE_MODE_0,
- _MASKED_BIT_ENABLE(CM0_PIPELINED_RENDER_FLUSH_DISABLE));
-
- /* WaDisable_RenderCache_OperationalFlush:g4x */
- I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
-
g4x_disable_trickle_feed(dev_priv);
}
@@ -7421,11 +7414,6 @@ static void i965gm_init_clock_gating(struct
drm_i915_private *dev_priv)
intel_uncore_write(uncore,
MI_ARB_STATE,
_MASKED_BIT_ENABLE(MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE));
-
- /* WaDisable_RenderCache_OperationalFlush:gen4 */
- intel_uncore_write(uncore,
- CACHE_MODE_0,
- _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
}
static void i965g_init_clock_gating(struct drm_i915_private *dev_priv)
@@ -7438,9 +7426,6 @@ static void i965g_init_clock_gating(struct
drm_i915_private *dev_priv)
I915_WRITE(RENCLK_GATE_D2, 0);
I915_WRITE(MI_ARB_STATE,
_MASKED_BIT_ENABLE(MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE));
-
- /* WaDisable_RenderCache_OperationalFlush:gen4 */
- I915_WRITE(CACHE_MODE_0, _MASKED_BIT_DISABLE(RC_OP_FLUSH_ENABLE));
}
static void gen3_init_clock_gating(struct drm_i915_private *dev_priv)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave and Daniel, here's the PR for the latest fixes in drm-misc-next-fixes. Best regards Thomas drm-misc-next-fixes-2020-06-11: In core, DRM connectors now notify userspace of hotplug events via sysfs. In drivers, sun4i now uses 4 bits to store the clock's m divider; ast sets up 24/32-bit color mode correctly. The following changes since commit 9ca1f474cea0edc14a1d7ec933e5472c0ff115d3: Merge tag 'amd-drm-next-5.8-2020-05-27' of git://people.freedesktop.org/~agd5f/linux into drm-next (2020-05-28 16:10:17 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-06-11 for you to fetch changes up to 291ddeb621e4a9f1ced8302a777fbd7fbda058c6: drm/ast: fix missing break in switch statement for format->cpp[0] case 4 (2020-06-11 09:05:31 +0200) In core, DRM connectors now notify userspace of hotplug events via sysfs. In drivers, sun4i now uses 4 bits to store the clock's m divider; ast sets up 24/32-bit color mode correctly. Colin Ian King (1): drm/ast: fix missing break in switch statement for format->cpp[0] case 4 Jernej Skrabec (1): drm/sun4i: hdmi ddc clk: Fix size of m divider Jeykumar Sankaran (1): drm/connector: notify userspace on hotplug after register complete drivers/gpu/drm/ast/ast_mode.c | 1 + drivers/gpu/drm/drm_connector.c| 5 + drivers/gpu/drm/drm_sysfs.c| 3 --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 2 +- drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +- 5 files changed, 8 insertions(+), 5 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 04/18] dma-fence: prime lockdep annotations
On 6/4/20 10:12 AM, Daniel Vetter wrote: Two in one go: - it is allowed to call dma_fence_wait() while holding a dma_resv_lock(). This is fundamental to how eviction works with ttm, so required. - it is allowed to call dma_fence_wait() from memory reclaim contexts, specifically from shrinker callbacks (which i915 does), and from mmu notifier callbacks (which amdgpu does, and which i915 sometimes also does, and probably always should, but that's kinda a debate). Also for stuff like HMM we really need to be able to do this, or things get real dicey. Consequence is that any critical path necessary to get to a dma_fence_signal for a fence must never a) call dma_resv_lock nor b) allocate memory with GFP_KERNEL. Also by implication of dma_resv_lock(), no userspace faulting allowed. That's some supremely obnoxious limitations, which is why we need to sprinkle the right annotations to all relevant paths. The one big locking context we're leaving out here is mmu notifiers, added in commit 23b68395c7c78a764e8963fc15a7cfd318bf187f Author: Daniel Vetter Date: Mon Aug 26 22:14:21 2019 +0200 mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end that one covers a lot of other callsites, and it's also allowed to wait on dma-fences from mmu notifiers. But there's no ready-made functions exposed to prime this, so I've left it out for now. v2: Also track against mmu notifier context. v3: kerneldoc to spec the cross-driver contract. Note that currently i915 throws in a hard-coded 10s timeout on foreign fences (not sure why that was done, but it's there), which is why that rule is worded with SHOULD instead of MUST. Also some of the mmu_notifier/shrinker rules might surprise SoC drivers, I haven't fully audited them all. Which is infeasible anyway, we'll need to run them with lockdep and dma-fence annotations and see what goes boom. v4: A spelling fix from Mika Cc: Mika Kuoppala Cc: Thomas Hellstrom Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter --- Documentation/driver-api/dma-buf.rst | 6 drivers/dma-buf/dma-fence.c | 41 drivers/dma-buf/dma-resv.c | 4 +++ include/linux/dma-fence.h| 1 + 4 files changed, 52 insertions(+) I still have my doubts about allowing fence waiting from within shrinkers. IMO ideally they should use a trywait approach, in order to allow memory allocation during command submission for drivers that publish fences before command submission. (Since early reservation object release requires that). But since drivers are already waiting from within shrinkers and I take your word for HMM requiring this, Reviewed-by: Thomas Hellström ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
