[Intel-gfx] ✓ Fi.CI.IGT: success for Make macro definitions consistent in intel_reg.h
== Series Details ==
Series: Make macro definitions consistent in intel_reg.h
URL : https://patchwork.freedesktop.org/series/55875/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498_full -> Patchwork_12064_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12064_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12064_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_12064_full:
### IGT changes ###
Warnings
* igt@kms_vblank@crtc-id:
- shard-snb: {SKIP} [fdo#109271] -> FAIL
Known issues
Here are the changes found in Patchwork_12064_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_flip@modeset-vs-vblank-race:
- shard-kbl: PASS -> FAIL [fdo#103060]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-glk: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge:
- shard-snb: {SKIP} [fdo#109271] / [fdo#109278] -> PASS
* igt@kms_color@pipe-a-legacy-gamma:
- shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS +1
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
- shard-apl: FAIL [fdo#103166] -> PASS +2
Warnings
* igt@i915_suspend@shrink:
- shard-kbl: INCOMPLETE [fdo#103665] / [fdo#106886] -> DMESG-WARN
[fdo#109244]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5498 -> Patchwork_12064
CI_DRM_5498: bebd74b74f0c62ff61036fc2d349fc470502b565 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12064: 504ef6aa90bab8188ef6e9e09f7062cefc1bf2f6 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12064/
___
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/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/55874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498_full -> Patchwork_12063_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12063_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12063_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_12063_full:
### IGT changes ###
Warnings
* igt@kms_vblank@crtc-id:
- shard-snb: {SKIP} [fdo#109271] -> FAIL
Known issues
Here are the changes found in Patchwork_12063_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_reloc@basic-write-wc:
- shard-apl: PASS -> INCOMPLETE [fdo#103927] +1
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: PASS -> FAIL [fdo#103232] +3
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: PASS -> FAIL [fdo#104873]
* igt@kms_draw_crc@fill-fb:
- shard-glk: PASS -> FAIL [fdo#103184]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +3
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_mmap_gtt@hang:
- shard-glk: FAIL [fdo#109469] -> PASS
* igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge:
- shard-snb: {SKIP} [fdo#109271] / [fdo#109278] -> PASS
* igt@kms_color@pipe-a-degamma:
- shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
- shard-kbl: FAIL [fdo#99912] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-kbl: INCOMPLETE [fdo#103665] / [fdo#106886] -> DMESG-WARN
[fdo#109244]
- shard-snb: DMESG-WARN [fdo#109244] -> INCOMPLETE [fdo#105411] /
[fdo#106886]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109469]: https://bugs.freedesktop.org/show_bug.cgi?id=109469
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5498 -> Patchwork_12063
CI_DRM_5498: bebd74b74f0c62ff61036fc2d349fc470502b565 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12063: 54975717b65be43e905bf56bc7d7f8329f9871ae @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: MST and wakeref leak fixes
== Series Details ==
Series: drm/i915: MST and wakeref leak fixes
URL : https://patchwork.freedesktop.org/series/55868/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498_full -> Patchwork_12062_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_12062_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12062_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_12062_full:
### IGT changes ###
Warnings
* igt@kms_vblank@crtc-id:
- shard-snb: {SKIP} [fdo#109271] -> FAIL
Known issues
Here are the changes found in Patchwork_12062_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b:
- shard-apl: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@kms_chv_cursor_fail@pipe-a-256x256-bottom-edge:
- shard-snb: {SKIP} [fdo#109271] / [fdo#109278] -> PASS
* igt@kms_color@pipe-a-legacy-gamma:
- shard-apl: FAIL [fdo#104782] / [fdo#108145] -> PASS +1
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS +3
* igt@kms_plane_multiple@atomic-pipe-a-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
Warnings
* igt@i915_suspend@shrink:
- shard-kbl: INCOMPLETE [fdo#103665] / [fdo#106886] -> DMESG-WARN
[fdo#109244]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
[fdo#106886]: https://bugs.freedesktop.org/show_bug.cgi?id=106886
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109244]: https://bugs.freedesktop.org/show_bug.cgi?id=109244
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5498 -> Patchwork_12062
CI_DRM_5498: bebd74b74f0c62ff61036fc2d349fc470502b565 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12062: 5733e328479164dfbf27f2a284706c5ea79a04f1 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12062/
___
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 [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5497_full -> Patchwork_12061_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12061_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-c:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_content_protection@atomic:
- shard-kbl: NOTRUN -> FAIL [fdo#108597]
- shard-apl: NOTRUN -> FAIL [fdo#108597]
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-apl: PASS -> FAIL [fdo#103232]
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_flip@2x-dpms-vs-vblank-race:
- shard-hsw: PASS -> DMESG-FAIL [fdo#102614] / [fdo#103060]
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: NOTRUN -> FAIL [fdo#103166]
- shard-apl: NOTRUN -> FAIL [fdo#103166]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
* igt@kms_sysfs_edid_timing:
- shard-apl: NOTRUN -> FAIL [fdo#100047]
- shard-kbl: NOTRUN -> FAIL [fdo#100047]
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@gem_eio@in-flight-contexts-1us:
- shard-kbl: DMESG-WARN [fdo#109467] -> PASS +3
- shard-apl: DMESG-WARN [fdo#109467] -> PASS +3
* igt@gem_eio@in-flight-external:
- shard-glk: DMESG-WARN [fdo#109467] -> PASS +3
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: FAIL [fdo#108147] -> PASS
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: INCOMPLETE [fdo#103359] / [k.org#198133] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS
- shard-apl: FAIL [fdo#103166] -> PASS +2
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#100047]: https://bugs.freedesktop.org/show_bug.cgi?id=100047
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108597]: https://bugs.freedesktop.org/show_bug.cgi?id=108597
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109373]: https://bugs.freedesktop.org/show_bug.cgi?id=109373
[fdo#109467]: https://bugs.freedesktop.org/show_bug.cgi?id=109467
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5497 -> Patchwork_12061
CI_DRM_5497: 67aa6866708f2fa3a2ec914257cca94a872072ac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12061: 84abe369e1be51fe392e6a97143cd9377b8ea135 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12061/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing
On Mon, Jan 21, 2019, at 4:20 PM, Chris Wilson wrote: > Rather than every backend and GPU driver reinventing the same wheel for > user level debugging of HW execution, the common dma-fence framework > should include the tracing infrastructure required for most client API > level flow visualisation. > > With these common dma-fence level tracepoints, the userspace tools can > establish a detailed view of the client <-> HW flow across different > kernels. There is a strong ask to have this available, so that the > userspace developer can effectively assess if they're doing a good job > about feeding the beast of a GPU hardware. ... I've got a first pass of this visualizing with gpuvis. Screenshots: ; with dma_event tracepoints patch https://imgur.com/a/MwvoAYY ; with old i915 tracepoints https://imgur.com/a/tG2iyHS Couple questions... With your new dma_event traceponts patch, we're still getting these tracepoints: i915_request_in i915_request_out intel_engine_notify And the in/out tracepoints line up with dma_fence_executes (same ctx:seqno and time): -0 [006] 150.376273: dma_fence_execute_start: context=31, seqno=35670, hwid=0 -0 [006] 150.413215: dma_fence_execute_end: context=31, seqno=35670, hwid=0 -0 [006] 150.376272: i915_request_in: dev=0, engine=0:0, hw_id=4, ctx=31, seqno=35670, prio=0, global=41230, port=1 -0 [006] 150.413217: i915_request_out: dev=0, engine=0:0, hw_id=4, ctx=31, seqno=35670, global=41230, completed?=1 However I'm also seeing several i915_request_in --> intel_engine_notify tracepoints that don't have dma_fence_execute_* tracepoints: RenderThread-1279 [001] 150.341336: dma_fence_init: driver=i915 timeline=ShooterGame[1226]/2 context=31 seqno=35669 RenderThread-1279 [001] 150.341352: dma_fence_emit: context=31, seqno=35669 -0 [006] 150.376271: i915_request_in: dev=0, engine=0:0, hw_id=4, ctx=31, seqno=35669, prio=0, global=41229, port=1 -0 [006] 150.411525: intel_engine_notify: dev=0, engine=0:0, seqno=41229, waiters=1 RenderThread-1279 [001] 150.419779: dma_fence_signaled: context=31, seqno=35669 RenderThread-1279 [001] 150.419838: dma_fence_destroy:context=31, seqno=35669 I assume something is going on at a lower level that we can't get the information for via dma_fence? Thanks! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for icl: Misc PLL patches (rev3)
== Series Details ==
Series: icl: Misc PLL patches (rev3)
URL : https://patchwork.freedesktop.org/series/55378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5496_full -> Patchwork_12060_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12060_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-immediate:
- shard-glk: PASS -> DMESG-WARN [fdo#109467]
* igt@gem_workarounds@suspend-resume-context:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_color@pipe-a-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782] / [fdo#108145]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_draw_crc@fill-fb:
- shard-glk: PASS -> FAIL [fdo#103184]
* igt@kms_flip@modeset-vs-vblank-race:
- shard-kbl: PASS -> FAIL [fdo#103060]
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: PASS -> INCOMPLETE [fdo#103665]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: PASS -> FAIL [fdo#109016]
* igt@kms_universal_plane@universal-plane-pipe-c-functional:
- shard-glk: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_pwrite_pread@snooped-copy-performance:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-kbl: DMESG-WARN [fdo#108566] -> PASS
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: FAIL [fdo#104873] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
- shard-kbl: FAIL [fdo#99912] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103184]: https://bugs.freedesktop.org/show_bug.cgi?id=103184
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#104873]: https://bugs.freedesktop.org/show_bug.cgi?id=104873
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#109016]: https://bugs.freedesktop.org/show_bug.cgi?id=109016
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109467]: https://bugs.freedesktop.org/show_bug.cgi?id=109467
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5496 -> Patchwork_12060
CI_DRM_5496: 32894ce8772d3679dbe8368d4cdab6d92efe4d25 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12060: aa2c54207f3d50b7b3ea278675b74f3bcb36ed8c @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12060/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects
Noralf Trønnes writes:
> Den 28.01.2019 21.57, skrev Rob Herring:
>> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
>>>
>>>
>>> Den 30.11.2018 00.58, skrev Eric Anholt:
Daniel Vetter writes:
> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
>> Daniel Vetter writes:
>>
>>> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
Daniel Vetter writes:
> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
>> Noralf Trønnes writes:
>>> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>>> +{
>>> + struct drm_gem_object *obj = vma->vm_private_data;
>>> + struct drm_gem_shmem_object *shmem =
>>> to_drm_gem_shmem_obj(obj);
>>> +
>>> + drm_gem_shmem_put_pages(shmem);
>>> + drm_gem_vm_close(vma);
>>> +}
>>> +
>>> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>>> + .fault = drm_gem_shmem_fault,
>>> + .open = drm_gem_vm_open,
>>> + .close = drm_gem_shmem_vm_close,
>>> +};
>>> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
>> I just saw a warning from drm_gem_shmem_put_pages() for
>> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
>> drm_gem_shmem_get_pages().
> Yeah we need a drm_gem_shmem_vm_open here.
Adding one of those fixed my refcounting issues, so I've sent out a v6
with it.
>>> Just realized that I've reviewed this patch already, spotted that vma
>>> management issue there too. Plus a pile of other things. From reading
>>> that
>>> other thread discussion with Noralf concluded with "not yet ready for
>>> prime time" unfortunately :-/
>> I saw stuff about how it wasn't usable for SPI because SPI does weird
>> things with DMA mapping. Was there something else?
> Looking through that mail it was a bunch of comments to improve the
> kerneldoc. Plus a note that buffer sharing/mmap is going to be all
> incoherent and horrible (but I guess for vkms we don't care that much).
> I'm just kinda vary of generic buffer handling that turns out to not be
> actually all that useful. We have lots of deadends and kinda-midlayers in
> this area already (but this one here definitely smells plenty better than
> lots of older ones).
FWIW, I really want shmem helpers for v3d. The fault handling in
particular has magic I don't understand, and this is not my first fault
handler. :/
>>>
>>>
>>> If you can use it for a "real" hw driver like v3d, I think it makes a lot
>>> sense to have it as a helper. I believe udl and a future simpledrm can
>>> also make use of it.
>>
>> FWIW, I think etnaviv at least could use this too.
>>
>> I'm starting to look at panfrost and lima drivers and was trying to
>> figure out where to start with the GEM code. So I've been comparing
>> etnaviv, freedreno, and vgem implementations. They are all pretty
>> similar from what I see. The per driver GEM obj structs certainly are.
>> I can't bring myself to just copy etnaviv code over and do a
>> s/etnaviv/panfrost/. So searching around a bit, I ended up on this
>> thread. This seems to be what I need for panfrost (based on my brief
>> study).
>>
>
> I gave up on this due to problems with SPI DMA.
> Eric tried to use it with vkms, but it failed. On his blog he speculates
> that it might be due to cached CPU mappings:
> https://anholt.github.io/twivc4/2018/12/03/twiv/
>
> For tinydrm I wanted cached mappings, but it might not work that well
> with shmem. Maybe that's why I had problems with SPI DMA.
Actually, for tinydrm buffers that are dma-buf exported through prime, I
really want tinydrm using WC mappings so that vc4 or v3d rendering (now
supported on Mesa master with kmsro) works.
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Make macro definitions consistent in intel_reg.h
== Series Details ==
Series: Make macro definitions consistent in intel_reg.h
URL : https://patchwork.freedesktop.org/series/55875/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498 -> Patchwork_12064
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55875/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12064 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +2
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: FAIL [fdo#108800] -> PASS
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL [fdo#108511] -> PASS
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (44 -> 40)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-skl-6700hq
Build changes
-
* Linux: CI_DRM_5498 -> Patchwork_12064
CI_DRM_5498: bebd74b74f0c62ff61036fc2d349fc470502b565 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12064: 504ef6aa90bab8188ef6e9e09f7062cefc1bf2f6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
504ef6aa90ba drm/i915: Make MG phy macros semantically consistent
1eaa92c3b871 drm/i915: Make macro definitions consistent for ICL and CNL
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12064/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
== Series Details ==
Series: series starting with [1/3] drm/i915/ringbuffer: EMIT_INVALIDATE
*before* switch context
URL : https://patchwork.freedesktop.org/series/55874/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498 -> Patchwork_12063
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55874/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12063 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
Possible fixes
* igt@gem_ctx_create@basic:
- fi-elk-e7500: {SKIP} [fdo#109271] -> PASS +5
* igt@gem_ctx_exec@basic:
- fi-bwr-2160:{SKIP} [fdo#109271] -> PASS +5
* igt@gem_ctx_param@basic-default:
- fi-ilk-650: {SKIP} [fdo#109271] -> PASS +5
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: FAIL [fdo#108800] -> PASS
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL [fdo#108511] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108756]: https://bugs.freedesktop.org/show_bug.cgi?id=108756
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (44 -> 41)
--
Missing(3): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5498 -> Patchwork_12063
CI_DRM_5498: bebd74b74f0c62ff61036fc2d349fc470502b565 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12063: 54975717b65be43e905bf56bc7d7f8329f9871ae @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
54975717b65b drm/i915: Enable render context support for gen4 (Broadwater to
Cantiga)
e469a783cf96 drm/i915: Enable render context support for Ironlake (gen5)
43137479bd30 drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12063/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Make macro definitions consistent in intel_reg.h
== Series Details == Series: Make macro definitions consistent in intel_reg.h URL : https://patchwork.freedesktop.org/series/55875/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1eaa92c3b871 drm/i915: Make macro definitions consistent for ICL and CNL 504ef6aa90ba drm/i915: Make MG phy macros semantically consistent -:23: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ln0p1' - possible side-effects? #23: FILE: drivers/gpu/drm/i915/i915_reg.h:1900: +#define MG_PHY_PORT_LN(ln, port, ln0p1, ln0p2, ln1p1) \ _MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - (ln0p1))) total: 0 errors, 0 warnings, 1 checks, 243 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 5/6] drm/i915/icl: Enable pipe output csc
On Wed, Jan 16, 2019 at 09:51:36PM +0530, Uma Shankar wrote:
> GEN11+ onwards an output csc hardware block has been added.
> This is after the pipe gamma block and is in addition to the
> legacy pipe CSC block. Primary use case for this block is to
> convert RGB to YUV in case sink supports YUV.
> This patch adds supports for the same.
>
> v2: This is added after splitting the existing ICL pipe CSC
> handling. As per Matt's suggestion, made this to co-exist
> with existing pipe CSC, wherein both can be enabled if a
> certain usecase arises.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_reg.h| 41 +
> drivers/gpu/drm/i915/intel_color.c | 75
> --
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> 3 files changed, 99 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3c3a902..edd6b4d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9864,6 +9864,7 @@ enum skl_power_gate {
>
> #define _PIPE_A_CSC_MODE 0x49028
> #define ICL_CSC_ENABLE (1 << 31)
> +#define ICL_OUTPUT_CSC_ENABLE (1 << 30)
> #define CSC_BLACK_SCREEN_OFFSET (1 << 2)
> #define CSC_POSITION_BEFORE_GAMMA (1 << 1)
> #define CSC_MODE_YUV_TO_RGB (1 << 0)
> @@ -9903,6 +9904,46 @@ enum skl_power_gate {
> #define PIPE_CSC_POSTOFF_ME(pipe)_MMIO_PIPE(pipe,
> _PIPE_A_CSC_POSTOFF_ME, _PIPE_B_CSC_POSTOFF_ME)
> #define PIPE_CSC_POSTOFF_LO(pipe)_MMIO_PIPE(pipe,
> _PIPE_A_CSC_POSTOFF_LO, _PIPE_B_CSC_POSTOFF_LO)
>
> +/* Pipe Output CSC */
> +#define _PIPE_A_OUTPUT_CSC_COEFF_RY_GY 0x49050
> +#define _PIPE_A_OUTPUT_CSC_COEFF_BY 0x49054
> +#define _PIPE_A_OUTPUT_CSC_COEFF_RU_GU 0x49058
> +#define _PIPE_A_OUTPUT_CSC_COEFF_BU 0x4905c
> +#define _PIPE_A_OUTPUT_CSC_COEFF_RV_GV 0x49060
> +#define _PIPE_A_OUTPUT_CSC_COEFF_BV 0x49064
> +#define _PIPE_A_OUTPUT_CSC_PREOFF_HI 0x49068
> +#define _PIPE_A_OUTPUT_CSC_PREOFF_ME 0x4906c
> +#define _PIPE_A_OUTPUT_CSC_PREOFF_LO 0x49070
> +#define _PIPE_A_OUTPUT_CSC_POSTOFF_HI0x49074
> +#define _PIPE_A_OUTPUT_CSC_POSTOFF_ME0x49078
> +#define _PIPE_A_OUTPUT_CSC_POSTOFF_LO0x4907c
> +
> +#define _PIPE_B_OUTPUT_CSC_COEFF_RY_GY 0x49150
> +#define _PIPE_B_OUTPUT_CSC_COEFF_BY 0x49154
> +#define _PIPE_B_OUTPUT_CSC_COEFF_RU_GU 0x49158
> +#define _PIPE_B_OUTPUT_CSC_COEFF_BU 0x4915c
> +#define _PIPE_B_OUTPUT_CSC_COEFF_RV_GV 0x49160
> +#define _PIPE_B_OUTPUT_CSC_COEFF_BV 0x49164
> +#define _PIPE_B_OUTPUT_CSC_PREOFF_HI 0x49168
> +#define _PIPE_B_OUTPUT_CSC_PREOFF_ME 0x4916c
> +#define _PIPE_B_OUTPUT_CSC_PREOFF_LO 0x49170
> +#define _PIPE_B_OUTPUT_CSC_POSTOFF_HI0x49174
> +#define _PIPE_B_OUTPUT_CSC_POSTOFF_ME0x49178
> +#define _PIPE_B_OUTPUT_CSC_POSTOFF_LO0x4917c
> +
> +#define PIPE_CSC_OUTPUT_COEFF_RY_GY(pipe)_MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_COEFF_RY_GY, _PIPE_B_OUTPUT_CSC_COEFF_RY_GY)
> +#define PIPE_CSC_OUTPUT_COEFF_BY(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_COEFF_BY, _PIPE_B_OUTPUT_CSC_COEFF_BY)
> +#define PIPE_CSC_OUTPUT_COEFF_RU_GU(pipe)_MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_COEFF_RU_GU, _PIPE_B_OUTPUT_CSC_COEFF_RU_GU)
> +#define PIPE_CSC_OUTPUT_COEFF_BU(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_COEFF_BU, _PIPE_B_OUTPUT_CSC_COEFF_BU)
> +#define PIPE_CSC_OUTPUT_COEFF_RV_GV(pipe)_MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_COEFF_RV_GV, _PIPE_B_OUTPUT_CSC_COEFF_RV_GV)
> +#define PIPE_CSC_OUTPUT_COEFF_BV(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_COEFF_BV, _PIPE_B_OUTPUT_CSC_COEFF_BV)
> +#define PIPE_CSC_OUTPUT_PREOFF_HI(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_PREOFF_HI, _PIPE_B_OUTPUT_CSC_PREOFF_HI)
> +#define PIPE_CSC_OUTPUT_PREOFF_ME(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_PREOFF_ME, _PIPE_B_OUTPUT_CSC_PREOFF_ME)
> +#define PIPE_CSC_OUTPUT_PREOFF_LO(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_PREOFF_LO, _PIPE_B_OUTPUT_CSC_PREOFF_LO)
> +#define PIPE_CSC_OUTPUT_POSTOFF_HI(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_POSTOFF_HI, _PIPE_B_OUTPUT_CSC_POSTOFF_HI)
> +#define PIPE_CSC_OUTPUT_POSTOFF_ME(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_POSTOFF_ME, _PIPE_B_OUTPUT_CSC_POSTOFF_ME)
> +#define PIPE_CSC_OUTPUT_POSTOFF_LO(pipe) _MMIO_PIPE(pipe,
> _PIPE_A_OUTPUT_CSC_POSTOFF_LO, _PIPE_B_OUTPUT_CSC_POSTOFF_LO)
> +
> /* pipe degamma/gamma LUTs on IVB+ */
> #define _PAL_PREC_INDEX_A0x4A400
> #define _PAL_PREC_INDEX_B0x4AC00
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 9b8d2de..c95adb9 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -113,29 +113,58 @@ static u64 *ctm_mult_by_limited(u64 *result, const u64
> *input)
> return result;
> }
>
> -static
Re: [Intel-gfx] [v6 4/6] drm/i915/icl: Enable ICL Pipe CSC block
On Wed, Jan 16, 2019 at 09:51:35PM +0530, Uma Shankar wrote:
> Enable ICL pipe csc hardware. CSC block is enabled
> in CSC_MODE register instead of PLANE_COLOR_CTL.
>
> ToDO: Extend the ABI to accept 32 bit coefficient values
> instead of 16bit for future platforms.
>
> v2: Addressed Maarten's review comments.
>
> v3: Addressed Matt's review comments. Removed rmw patterns
> as suggested by Matt.
>
> v4: Addressed Matt's review comments.
>
> v5: Addressed Ville's review comments.
>
> v6: Separated pipe output csc programming from regular csc.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_reg.h| 9 ++---
> drivers/gpu/drm/i915/intel_color.c | 7 ++-
> 2 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a84200f..3c3a902 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9861,10 +9861,13 @@ enum skl_power_gate {
> #define _PIPE_A_CSC_COEFF_BU 0x4901c
> #define _PIPE_A_CSC_COEFF_RV_GV 0x49020
> #define _PIPE_A_CSC_COEFF_BV 0x49024
> +
> #define _PIPE_A_CSC_MODE 0x49028
> -#define CSC_BLACK_SCREEN_OFFSET(1 << 2)
> -#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
> -#define CSC_MODE_YUV_TO_RGB(1 << 0)
> +#define ICL_CSC_ENABLE (1 << 31)
> +#define CSC_BLACK_SCREEN_OFFSET (1 << 2)
> +#define CSC_POSITION_BEFORE_GAMMA (1 << 1)
> +#define CSC_MODE_YUV_TO_RGB (1 << 0)
> +
> #define _PIPE_A_CSC_PREOFF_HI0x49030
> #define _PIPE_A_CSC_PREOFF_ME0x49034
> #define _PIPE_A_CSC_PREOFF_LO0x49038
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 494891c..9b8d2de 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -134,6 +134,7 @@ static void ilk_load_ycbcr_conversion_matrix(struct
> intel_crtc *crtc)
> I915_WRITE(PIPE_CSC_POSTOFF_HI(pipe), POSTOFF_RGB_TO_YUV_HI);
> I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), POSTOFF_RGB_TO_YUV_ME);
> I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), POSTOFF_RGB_TO_YUV_LO);
> +
> I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> }
Seems like an unintentional change?
Otherwise, this looks good now that the output csc for rgb->yuv is moved
to the next patch.
Reviewed-by: Matt Roper
>
> @@ -242,7 +243,10 @@ static void ilk_load_csc_matrix(struct intel_crtc_state
> *crtc_state)
> I915_WRITE(PIPE_CSC_POSTOFF_ME(pipe), postoff);
> I915_WRITE(PIPE_CSC_POSTOFF_LO(pipe), postoff);
>
> - I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> + if (INTEL_GEN(dev_priv) >= 11)
> + I915_WRITE(PIPE_CSC_MODE(pipe), ICL_CSC_ENABLE);
> + else
> + I915_WRITE(PIPE_CSC_MODE(pipe), 0);
> } else {
> uint32_t mode = CSC_MODE_YUV_TO_RGB;
>
> @@ -692,6 +696,7 @@ void intel_color_init(struct intel_crtc *crtc)
> dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> dev_priv->display.load_luts = glk_load_luts;
> } else if (IS_ICELAKE(dev_priv)) {
> + dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> dev_priv->display.load_luts = icl_load_luts;
> } else {
> dev_priv->display.load_luts = i9xx_load_luts;
> --
> 1.9.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 3/6] drm/i915/icl: Add icl pipe degamma and gamma support
On Wed, Jan 16, 2019 at 09:51:34PM +0530, Uma Shankar wrote:
> Add support for icl pipe degamma and gamma.
>
> v2: Removed a POSTING_READ and corrected the Bit
> Definition as per Maarten's comments.
>
> v3: Addressed Matt's review comments. Removed rmw patterns
> as suggested by Matt.
>
> v4: Fixed Matt's review comments.
>
> v5: Corrected macro alignment as per Jani Nikula's comments.
> Addressed Ville and Matt's review comments.
>
> v6: Merged ICL degamma handling with GLK and dropped ICL
> degamma function as per Ville and Matt's comments.
>
> Signed-off-by: Uma Shankar
The general changes and direction here look good, but this will need a
rebase after Ville's series lands, so I'll wait on that to give the
final r-b.
Matt
> ---
> drivers/gpu/drm/i915/i915_reg.h| 12 +++-
> drivers/gpu/drm/i915/intel_color.c | 21 +
> 2 files changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fad5a9e..a84200f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7088,11 +7088,13 @@ enum {
> #define _GAMMA_MODE_A0x4a480
> #define _GAMMA_MODE_B0x4ac80
> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
> -#define GAMMA_MODE_MODE_MASK (3 << 0)
> -#define GAMMA_MODE_MODE_8BIT (0 << 0)
> -#define GAMMA_MODE_MODE_10BIT(1 << 0)
> -#define GAMMA_MODE_MODE_12BIT(2 << 0)
> -#define GAMMA_MODE_MODE_SPLIT(3 << 0)
> +#define PRE_CSC_GAMMA_ENABLE(1 << 31)
> +#define POST_CSC_GAMMA_ENABLE (1 << 30)
> +#define GAMMA_MODE_MODE_MASK(3 << 0)
> +#define GAMMA_MODE_MODE_8BIT(0 << 0)
> +#define GAMMA_MODE_MODE_10BIT (1 << 0)
> +#define GAMMA_MODE_MODE_12BIT (2 << 0)
> +#define GAMMA_MODE_MODE_SPLIT (3 << 0)
>
> /* DMC/CSR */
> #define CSR_PROGRAM(i) _MMIO(0x8 + (i) * 4)
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 3712bd0..494891c 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -557,6 +557,25 @@ static void glk_load_luts(struct intel_crtc_state
> *crtc_state)
> POSTING_READ(GAMMA_MODE(pipe));
> }
>
> +static void icl_load_luts(struct intel_crtc_state *crtc_state)
> +{
> + struct drm_crtc *crtc = crtc_state->base.crtc;
> + struct drm_device *dev = crtc_state->base.crtc->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
> +
> + if (crtc_state_is_legacy_gamma(crtc_state)) {
> + haswell_load_luts(crtc_state);
> + return;
> + }
> +
> + glk_load_degamma_lut(crtc_state);
> + bdw_load_gamma_lut(crtc_state, 0);
> +
> + I915_WRITE(GAMMA_MODE(pipe), GAMMA_MODE_MODE_10BIT |
> +PRE_CSC_GAMMA_ENABLE | POST_CSC_GAMMA_ENABLE);
> +}
> +
> /* Loads the palette/gamma unit for the CRTC on CherryView. */
> static void cherryview_load_luts(struct intel_crtc_state *crtc_state)
> {
> @@ -672,6 +691,8 @@ void intel_color_init(struct intel_crtc *crtc)
> } else if (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) {
> dev_priv->display.load_csc_matrix = ilk_load_csc_matrix;
> dev_priv->display.load_luts = glk_load_luts;
> + } else if (IS_ICELAKE(dev_priv)) {
> + dev_priv->display.load_luts = icl_load_luts;
> } else {
> dev_priv->display.load_luts = i9xx_load_luts;
> }
> --
> 1.9.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Make MG phy macros semantically consistent
Macros to be organized semantically by dword, lane and
port(in this order).
Cc: Clint Taylor
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 50
drivers/gpu/drm/i915/intel_ddi.c | 44 ++--
2 files changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b0535073c3f0..da8fcdc456d2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1897,7 +1897,7 @@ enum i915_power_well_id {
#define N_SCALAR(x) ((x) << 24)
#define N_SCALAR_MASK(0x7F << 24)
-#define MG_PHY_PORT_LN(port, ln, ln0p1, ln0p2, ln1p1) \
+#define MG_PHY_PORT_LN(ln, port, ln0p1, ln0p2, ln1p1) \
_MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - (ln0p1)))
#define MG_TX_LINK_PARAMS_TX1LN0_PORT1 0x16812C
@@ -1908,8 +1908,8 @@ enum i915_power_well_id {
#define MG_TX_LINK_PARAMS_TX1LN1_PORT3 0x16A52C
#define MG_TX_LINK_PARAMS_TX1LN0_PORT4 0x16B12C
#define MG_TX_LINK_PARAMS_TX1LN1_PORT4 0x16B52C
-#define MG_TX1_LINK_PARAMS(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
+#define MG_TX1_LINK_PARAMS(ln, port) \
+ MG_PHY_PORT_LN(ln, port, MG_TX_LINK_PARAMS_TX1LN0_PORT1, \
MG_TX_LINK_PARAMS_TX1LN0_PORT2, \
MG_TX_LINK_PARAMS_TX1LN1_PORT1)
@@ -1921,8 +1921,8 @@ enum i915_power_well_id {
#define MG_TX_LINK_PARAMS_TX2LN1_PORT3 0x16A4AC
#define MG_TX_LINK_PARAMS_TX2LN0_PORT4 0x16B0AC
#define MG_TX_LINK_PARAMS_TX2LN1_PORT4 0x16B4AC
-#define MG_TX2_LINK_PARAMS(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
+#define MG_TX2_LINK_PARAMS(ln, port) \
+ MG_PHY_PORT_LN(ln, port, MG_TX_LINK_PARAMS_TX2LN0_PORT1, \
MG_TX_LINK_PARAMS_TX2LN0_PORT2, \
MG_TX_LINK_PARAMS_TX2LN1_PORT1)
#define CRI_USE_FS32 (1 << 5)
@@ -1935,8 +1935,8 @@ enum i915_power_well_id {
#define MG_TX_PISO_READLOAD_TX1LN1_PORT3 0x16A54C
#define MG_TX_PISO_READLOAD_TX1LN0_PORT4 0x16B14C
#define MG_TX_PISO_READLOAD_TX1LN1_PORT4 0x16B54C
-#define MG_TX1_PISO_READLOAD(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_PISO_READLOAD_TX1LN0_PORT1, \
+#define MG_TX1_PISO_READLOAD(ln, port) \
+ MG_PHY_PORT_LN(ln, port, MG_TX_PISO_READLOAD_TX1LN0_PORT1, \
MG_TX_PISO_READLOAD_TX1LN0_PORT2, \
MG_TX_PISO_READLOAD_TX1LN1_PORT1)
@@ -1948,8 +1948,8 @@ enum i915_power_well_id {
#define MG_TX_PISO_READLOAD_TX2LN1_PORT3 0x16A4CC
#define MG_TX_PISO_READLOAD_TX2LN0_PORT4 0x16B0CC
#define MG_TX_PISO_READLOAD_TX2LN1_PORT4 0x16B4CC
-#define MG_TX2_PISO_READLOAD(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_PISO_READLOAD_TX2LN0_PORT1, \
+#define MG_TX2_PISO_READLOAD(ln, port) \
+ MG_PHY_PORT_LN(ln, port, MG_TX_PISO_READLOAD_TX2LN0_PORT1, \
MG_TX_PISO_READLOAD_TX2LN0_PORT2, \
MG_TX_PISO_READLOAD_TX2LN1_PORT1)
#define CRI_CALCINIT (1 << 1)
@@ -1962,8 +1962,8 @@ enum i915_power_well_id {
#define MG_TX_SWINGCTRL_TX1LN1_PORT3 0x16A548
#define MG_TX_SWINGCTRL_TX1LN0_PORT4 0x16B148
#define MG_TX_SWINGCTRL_TX1LN1_PORT4 0x16B548
-#define MG_TX1_SWINGCTRL(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_SWINGCTRL_TX1LN0_PORT1, \
+#define MG_TX1_SWINGCTRL(ln, port) \
+ MG_PHY_PORT_LN(ln, port, MG_TX_SWINGCTRL_TX1LN0_PORT1, \
MG_TX_SWINGCTRL_TX1LN0_PORT2, \
MG_TX_SWINGCTRL_TX1LN1_PORT1)
@@ -1975,8 +1975,8 @@ enum i915_power_well_id {
#define MG_TX_SWINGCTRL_TX2LN1_PORT3 0x16A4C8
#define MG_TX_SWINGCTRL_TX2LN0_PORT4 0x16B0C8
#define MG_TX_SWINGCTRL_TX2LN1_PORT4 0x16B4C8
-#define MG_TX2_SWINGCTRL(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_SWINGCTRL_TX2LN0_PORT1, \
+#define MG_TX2_SWINGCTRL(ln, port) \
+ MG_PHY_PORT_LN(ln, port, MG_TX_SWINGCTRL_TX2LN0_PORT1, \
MG_TX_SWINGCTRL_TX2LN0_PORT2, \
MG_TX_SWINGCTRL_TX2LN1_PORT1)
#define CRI_TXDEEMPH_OVERRIDE_17_12(x) ((x) << 0)
@@ -1990,8 +1990,8 @@ enum i915_power_well_id {
#define MG_TX_DRVCTRL_TX1LN1_TXPORT3 0x16A544
#define MG_TX_DRVCTRL_TX1LN0_TXPORT4 0x16B144
#define MG_TX_DRVCTRL_TX1LN1_TXPORT4 0x16B544
-#define MG_TX1_DRVCTRL(port, ln) \
- MG_PHY_PORT_LN(port, ln, MG_TX_DRVCTRL_TX1LN0_TXPORT1, \
+#define MG_TX1_DRVCTRL(ln, port) \
+ MG_PHY_PORT_LN(ln,
[Intel-gfx] [PATCH 1/2] drm/i915: Make macro definitions consistent for ICL and CNL
Macro definitions to be organized semantically based on dword, lane and
port(in this order).
Cc: Clint Taylor
Cc: Imre Deak
Cc: Jani Nikula
Signed-off-by: Aditya Swarup
---
drivers/gpu/drm/i915/i915_reg.h | 6 +++---
drivers/gpu/drm/i915/icl_dsi.c | 8
drivers/gpu/drm/i915/intel_ddi.c | 16
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1eca166d95bb..b0535073c3f0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1860,13 +1860,13 @@ enum i915_power_well_id {
#define _CNL_PORT_TX_DW4_LN1_AE0x1624D0
#define CNL_PORT_TX_DW4_GRP(port) _MMIO(_CNL_PORT_TX_DW_GRP(4, (port)))
#define CNL_PORT_TX_DW4_LN0(port) _MMIO(_CNL_PORT_TX_DW_LN0(4, (port)))
-#define CNL_PORT_TX_DW4_LN(port, ln) _MMIO(_CNL_PORT_TX_DW_LN0(4, (port)) + \
+#define CNL_PORT_TX_DW4_LN(ln, port) _MMIO(_CNL_PORT_TX_DW_LN0(4, (port)) + \
((ln) * (_CNL_PORT_TX_DW4_LN1_AE - \
_CNL_PORT_TX_DW4_LN0_AE)))
#define ICL_PORT_TX_DW4_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(4, port))
#define ICL_PORT_TX_DW4_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(4, port))
#define ICL_PORT_TX_DW4_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(4, 0, port))
-#define ICL_PORT_TX_DW4_LN(port, ln) _MMIO(_ICL_PORT_TX_DW_LN(4, ln, port))
+#define ICL_PORT_TX_DW4_LN(ln, port) _MMIO(_ICL_PORT_TX_DW_LN(4, ln, port))
#define LOADGEN_SELECT (1 << 31)
#define POST_CURSOR_1(x) ((x) << 12)
#define POST_CURSOR_1_MASK (0x3F << 12)
@@ -1893,7 +1893,7 @@ enum i915_power_well_id {
#define ICL_PORT_TX_DW7_AUX(port) _MMIO(_ICL_PORT_TX_DW_AUX(7, port))
#define ICL_PORT_TX_DW7_GRP(port) _MMIO(_ICL_PORT_TX_DW_GRP(7, port))
#define ICL_PORT_TX_DW7_LN0(port) _MMIO(_ICL_PORT_TX_DW_LN(7, 0, port))
-#define ICL_PORT_TX_DW7_LN(port, ln) _MMIO(_ICL_PORT_TX_DW_LN(7, ln, port))
+#define ICL_PORT_TX_DW7_LN(ln, port) _MMIO(_ICL_PORT_TX_DW_LN(7, ln, port))
#define N_SCALAR(x) ((x) << 24)
#define N_SCALAR_MASK(0x7F << 24)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 73a7bee24a66..beb30d9a855c 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -246,13 +246,13 @@ static void dsi_program_swing_and_deemphasis(struct
intel_encoder *encoder)
for (lane = 0; lane <= 3; lane++) {
/* Bspec: must not use GRP register for write */
- tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
+ tmp = I915_READ(ICL_PORT_TX_DW4_LN(lane, port));
tmp &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
CURSOR_COEFF_MASK);
tmp |= POST_CURSOR_1(0x0);
tmp |= POST_CURSOR_2(0x0);
tmp |= CURSOR_COEFF(0x3f);
- I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
+ I915_WRITE(ICL_PORT_TX_DW4_LN(lane, port), tmp);
}
}
}
@@ -390,11 +390,11 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
tmp &= ~LOADGEN_SELECT;
I915_WRITE(ICL_PORT_TX_DW4_AUX(port), tmp);
for (lane = 0; lane <= 3; lane++) {
- tmp = I915_READ(ICL_PORT_TX_DW4_LN(port, lane));
+ tmp = I915_READ(ICL_PORT_TX_DW4_LN(lane, port));
tmp &= ~LOADGEN_SELECT;
if (lane != 2)
tmp |= LOADGEN_SELECT;
- I915_WRITE(ICL_PORT_TX_DW4_LN(port, lane), tmp);
+ I915_WRITE(ICL_PORT_TX_DW4_LN(lane, port), tmp);
}
}
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index acd94354afc8..c6def69348a6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2315,13 +2315,13 @@ static void cnl_ddi_vswing_program(struct intel_encoder
*encoder,
/* Program PORT_TX_DW4 */
/* We cannot write to GRP. It would overrite individual loadgen */
for (ln = 0; ln < 4; ln++) {
- val = I915_READ(CNL_PORT_TX_DW4_LN(port, ln));
+ val = I915_READ(CNL_PORT_TX_DW4_LN(ln, port));
val &= ~(POST_CURSOR_1_MASK | POST_CURSOR_2_MASK |
CURSOR_COEFF_MASK);
val |= POST_CURSOR_1(ddi_translations[level].dw4_post_cursor_1);
val |= POST_CURSOR_2(ddi_translations[level].dw4_post_cursor_2);
val |= CURSOR_COEFF(ddi_translations[level].dw4_cursor_coeff);
- I915_WRITE(CNL_PORT_TX_DW4_LN(port, ln), val);
+
[Intel-gfx] [PATCH 0/2] Make macro definitions consistent in intel_reg.h
Arrange macros definitions for ICL, CNL and MG phy programming registers semantically in order by dword, lane and port; to make it consistent. Aditya Swarup (2): drm/i915: Make macro definitions consistent for ICL and CNL drm/i915: Make MG phy macros semantically consistent drivers/gpu/drm/i915/i915_reg.h | 56 ++--- drivers/gpu/drm/i915/icl_dsi.c | 8 ++--- drivers/gpu/drm/i915/intel_ddi.c | 60 3 files changed, 62 insertions(+), 62 deletions(-) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects
On Mon, Jan 28, 2019 at 3:26 PM Noralf Trønnes wrote:
>
>
>
> Den 28.01.2019 21.57, skrev Rob Herring:
> > On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
> >>
> >>
> >> Den 30.11.2018 00.58, skrev Eric Anholt:
> >>> Daniel Vetter writes:
> >>>
> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
> > Daniel Vetter writes:
> >
> >> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
> >>> Daniel Vetter writes:
> >>>
> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
> > Noralf Trønnes writes:
> >> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
> >> +{
> >> + struct drm_gem_object *obj = vma->vm_private_data;
> >> + struct drm_gem_shmem_object *shmem =
> >> to_drm_gem_shmem_obj(obj);
> >> +
> >> + drm_gem_shmem_put_pages(shmem);
> >> + drm_gem_vm_close(vma);
> >> +}
> >> +
> >> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
> >> + .fault = drm_gem_shmem_fault,
> >> + .open = drm_gem_vm_open,
> >> + .close = drm_gem_shmem_vm_close,
> >> +};
> >> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
> > I just saw a warning from drm_gem_shmem_put_pages() for
> > !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
> > drm_gem_shmem_get_pages().
> Yeah we need a drm_gem_shmem_vm_open here.
> >>> Adding one of those fixed my refcounting issues, so I've sent out a v6
> >>> with it.
> >> Just realized that I've reviewed this patch already, spotted that vma
> >> management issue there too. Plus a pile of other things. From reading
> >> that
> >> other thread discussion with Noralf concluded with "not yet ready for
> >> prime time" unfortunately :-/
> > I saw stuff about how it wasn't usable for SPI because SPI does weird
> > things with DMA mapping. Was there something else?
> Looking through that mail it was a bunch of comments to improve the
> kerneldoc. Plus a note that buffer sharing/mmap is going to be all
> incoherent and horrible (but I guess for vkms we don't care that much).
> I'm just kinda vary of generic buffer handling that turns out to not be
> actually all that useful. We have lots of deadends and kinda-midlayers in
> this area already (but this one here definitely smells plenty better than
> lots of older ones).
> >>> FWIW, I really want shmem helpers for v3d. The fault handling in
> >>> particular has magic I don't understand, and this is not my first fault
> >>> handler. :/
> >>
> >>
> >> If you can use it for a "real" hw driver like v3d, I think it makes a lot
> >> sense to have it as a helper. I believe udl and a future simpledrm can
> >> also make use of it.
> >
> > FWIW, I think etnaviv at least could use this too.
> >
> > I'm starting to look at panfrost and lima drivers and was trying to
> > figure out where to start with the GEM code. So I've been comparing
> > etnaviv, freedreno, and vgem implementations. They are all pretty
> > similar from what I see. The per driver GEM obj structs certainly are.
> > I can't bring myself to just copy etnaviv code over and do a
> > s/etnaviv/panfrost/. So searching around a bit, I ended up on this
> > thread. This seems to be what I need for panfrost (based on my brief
> > study).
> >
>
> I gave up on this due to problems with SPI DMA.
> Eric tried to use it with vkms, but it failed. On his blog he speculates
> that it might be due to cached CPU mappings:
> https://anholt.github.io/twivc4/2018/12/03/twiv/
>
> For tinydrm I wanted cached mappings, but it might not work that well
> with shmem. Maybe that's why I had problems with SPI DMA.
I think for most ARM systems, a cached mapping is not coherent. So
there will need to be cache flushes using the dma API. I see there's
been some discussion around that too.
> Maybe this change to drm_gem_shmem_mmap() is all it takes:
>
> - vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
> + vma->vm_page_prot =
> pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
Seems like at least this part needs some flexibility. etnaviv,
freedreno, and omap at least all appear to support cached, uncached,
and writecombined based on flags in the GEM object.
> The memory subsystem is really complicated and I have kind of given up
> on trying to decipher it.
Yes. All the more reason to not let each driver figure out what to do.
Rob
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Enable render context support for Ironlake (gen5)
Ironlake does support being able to saving and reloading context specific
registers between contexts, providing isolation of the basic GPU state
(as programmable by userspace). This allows userspace to assume that the
GPU retains their state from one batch to the next, minimising the
amount of state it needs to reload, or manually save and restore.
v2: Fix off-by-one in reading CXT_SIZE, and add a comment that the
CXT_SIZE and context-layout do not match in bspec, but the difference is
irrelevant as we overallocate the full page anyway (Ville).
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Kenneth Graunke
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_engine_cs.c | 16
drivers/gpu/drm/i915/intel_ringbuffer.c | 13 +
2 files changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ead9c4371fe1..148c3e06a2eb 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -220,6 +220,22 @@ __intel_engine_context_size(struct drm_i915_private
*dev_priv, u8 class)
return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
PAGE_SIZE);
case 5:
+ /*
+* There is a discrepancy here between the size reported
+* by the register and the size of the context layout
+* in the docs. Both are described as authorative!
+*
+* The discrepancy is on the order of a few cachelines,
+* but the total is under one page (4k), which is our
+* minimum allocation anyway so it should all come
+* out in the wash.
+*/
+ cxt_size = I915_READ(CXT_SIZE) + 1;
+ DRM_DEBUG_DRIVER("gen%d CXT_SIZE = %d bytes [0x%08x]\n",
+INTEL_GEN(dev_priv),
+cxt_size * 64,
+cxt_size - 1);
+ return round_up(cxt_size * 64, PAGE_SIZE);
case 4:
case 3:
case 2:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index db21606095d2..19def67bf1c5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1726,11 +1726,14 @@ static inline int mi_set_context(struct i915_request
*rq, u32 flags)
/* These flags are for resource streamer on HSW+ */
flags |= HSW_MI_RS_SAVE_STATE_EN | HSW_MI_RS_RESTORE_STATE_EN;
else
+ /* We need to save the extended state for powersaving modes */
flags |= MI_SAVE_EXT_STATE_EN | MI_RESTORE_EXT_STATE_EN;
len = 4;
if (IS_GEN(i915, 7))
len += 2 + (num_rings ? 4*num_rings + 6 : 0);
+ else if (IS_GEN(i915, 5))
+ len += 2;
if (flags & MI_FORCE_RESTORE) {
GEM_BUG_ON(flags & MI_RESTORE_INHIBIT);
flags &= ~MI_FORCE_RESTORE;
@@ -1759,6 +1762,14 @@ static inline int mi_set_context(struct i915_request
*rq, u32 flags)
GEN6_PSMI_SLEEP_MSG_DISABLE);
}
}
+ } else if (IS_GEN(i915, 5)) {
+ /*
+* This w/a is only listed for pre-production ilk a/b steppings,
+* but is also mentioned for programming the powerctx. To be
+* safe, just apply the workaround; we do not use SyncFlush so
+* this should never take effect and so be a no-op!
+*/
+ *cs++ = MI_SUSPEND_FLUSH | MI_SUSPEND_FLUSH_EN;
}
if (force_restore) {
@@ -1813,6 +1824,8 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
*cs++ = MI_NOOP;
}
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+ } else if (IS_GEN(i915, 5)) {
+ *cs++ = MI_SUSPEND_FLUSH;
}
intel_ring_advance(rq, cs);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimising the amount of state it needs to reload and manually save
across batches.
v2: CONSTANT_BUFFER woes
Running through piglit turned up an interesting issue, a GPU hang inside
the context load. The context image includes the CONSTANT_BUFFER command
that loads an address into a on-gpu buffer, and the context load was
executing that immediately. However, since it was reading from the GTT
there is no guarantee that the GTT retains the same configuration as
when the context was saved, resulting in stray reads and a GPU hang.
Having tried issuing a CONSTANT_BUFFER (to disable the command) from the
ring before saving the context to no avail, we resort to patching out
the instruction inside the context image before loading.
This does impose that gen4 always reissues CONSTANT_BUFFER commands on
each batch, but due to the use of a shared GTT that was and will remain
a requirement.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
Cc: Kenneth Graunke
Reviewed-by: Ville Syrjälä #v1
---
drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/intel_gpu_commands.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 148c3e06a2eb..32bd850eec30 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -220,6 +220,7 @@ __intel_engine_context_size(struct drm_i915_private
*dev_priv, u8 class)
return round_up(GEN6_CXT_TOTAL_SIZE(cxt_size) * 64,
PAGE_SIZE);
case 5:
+ case 4:
/*
* There is a discrepancy here between the size reported
* by the register and the size of the context layout
@@ -236,7 +237,6 @@ __intel_engine_context_size(struct drm_i915_private
*dev_priv, u8 class)
cxt_size * 64,
cxt_size - 1);
return round_up(cxt_size * 64, PAGE_SIZE);
- case 4:
case 3:
case 2:
/* For the special day when i810 gets merged. */
diff --git a/drivers/gpu/drm/i915/intel_gpu_commands.h
b/drivers/gpu/drm/i915/intel_gpu_commands.h
index b96a31bc1080..a95bfd922c41 100644
--- a/drivers/gpu/drm/i915/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/intel_gpu_commands.h
@@ -265,6 +265,9 @@
#define GFX_OP_3DSTATE_BINDING_TABLE_EDIT_PS \
((0x3<<29)|(0x3<<27)|(0x0<<24)|(0x47<<16))
+#define GFX_OP_CONSTANT_BUFFER \
+ (0x3 << 29 | 0x0 << 27 | 0x0 << 24 | 0x2 << 16)
+
#define MFX_WAIT ((0x3<<29)|(0x1<<27)|(0x0<<16))
#define COLOR_BLT ((0x2<<29)|(0x40<<22))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 19def67bf1c5..c03d156d59d9 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1734,6 +1734,8 @@ static inline int mi_set_context(struct i915_request *rq,
u32 flags)
len += 2 + (num_rings ? 4*num_rings + 6 : 0);
else if (IS_GEN(i915, 5))
len += 2;
+ else if (IS_GEN(i915, 4))
+ len += 4;
if (flags & MI_FORCE_RESTORE) {
GEM_BUG_ON(flags & MI_RESTORE_INHIBIT);
flags &= ~MI_FORCE_RESTORE;
@@ -1770,6 +1772,21 @@ static inline int mi_set_context(struct i915_request
*rq, u32 flags)
* this should never take effect and so be a no-op!
*/
*cs++ = MI_SUSPEND_FLUSH | MI_SUSPEND_FLUSH_EN;
+ } else if (IS_GEN(i915, 4)) {
+ /*
+* Disable CONSTANT_BUFFER before it is loaded from the context
+* image. For as it is loaded, it is executed and the stored
+* address may no longer be valid, leading to a GPU hang.
+*
+* This imposes the requirement that userspace reload their
+* CONSTANT_BUFFER on every batch, fortunately a requirement
+* they are already accustomed to from before contexts were
+* enabled.
+*/
+ *cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
+ *cs++ = 0;
+ *cs++ = i915_ggtt_offset(rq->hw_context->state) + 0x1d4;
+ *cs++ = GFX_OP_CONSTANT_BUFFER; /* inactive */
}
if (force_restore) {
--
2.20.1
___
Intel-gfx mailing list
[Intel-gfx] [PATCH 1/3] drm/i915/ringbuffer: EMIT_INVALIDATE *before* switch context
Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g.
simple rendercopies with igt, do not suffer).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ee3719324e2d..db21606095d2 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1968,12 +1968,12 @@ static int ring_request_alloc(struct i915_request
*request)
*/
request->reserved_space += LEGACY_REQUEST_SIZE;
- ret = switch_context(request);
+ /* Unconditionally invalidate GPU caches and TLBs. */
+ ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
if (ret)
return ret;
- /* Unconditionally invalidate GPU caches and TLBs. */
- ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
+ ret = switch_context(request);
if (ret)
return ret;
--
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: MST and wakeref leak fixes
== Series Details ==
Series: drm/i915: MST and wakeref leak fixes
URL : https://patchwork.freedesktop.org/series/55868/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5498 -> Patchwork_12062
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55868/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12062 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#109485] -> PASS
* igt@kms_flip@basic-flip-vs-modeset:
- fi-skl-6700hq: DMESG-WARN [fdo#105998] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: {SKIP} [fdo#109271] -> PASS
* igt@pm_rpm@basic-rte:
- fi-byt-j1900: FAIL [fdo#108800] -> PASS
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: FAIL [fdo#108511] -> PASS
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108800]: https://bugs.freedesktop.org/show_bug.cgi?id=108800
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
Participating hosts (44 -> 40)
--
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan fi-pnv-d510
Build changes
-
* Linux: CI_DRM_5498 -> Patchwork_12062
CI_DRM_5498: bebd74b74f0c62ff61036fc2d349fc470502b565 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12062: 5733e328479164dfbf27f2a284706c5ea79a04f1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5733e3284791 drm/i915: Don't send hotplug in intel_dp_check_mst_status()
cd2c9cb2d8c9 drm/i915: Don't send MST hotplugs during resume
642ed0b4731b drm/i915: Block fbdev HPD processing during suspend
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12062/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v6 2/6] drm/i915/glk: Fix degamma lut programming
On Wed, Jan 16, 2019 at 09:51:33PM +0530, Uma Shankar wrote:
> Fixed the glk degamma lut programming which currently
> was hard coding a linear lut all the time, making degamma
> block of glk basically a pass through.
>
> Currently degamma lut for glk is assigned as 0 in platform
> configuration. Updated the same to 33 as per the hardware
> capability. IGT tests for degamma were getting skipped due to
> this, spotted by Swati.
>
> ToDo: The current gamma/degamm lut ABI has just 16bit for each
> color component. This is not enough for GLK+, since input
> precision is increased to 3.16 which will need 19bit entries.
>
> Credits-to: Swati Sharma
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/i915_pci.c| 2 +-
> drivers/gpu/drm/i915/intel_color.c | 36
> 2 files changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index dd4aff2..24248d0 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -69,7 +69,7 @@
> #define CHV_COLORS \
> .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> #define GLK_COLORS \
> - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> + .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 }
>
> /* Keep in gen based order, and chronological order within a gen */
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index 37fd9dd..3712bd0 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -491,7 +491,7 @@ static void glk_load_degamma_lut(struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> enum pipe pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
> - const uint32_t lut_size = 33;
> + const uint32_t lut_size = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> uint32_t i;
>
> /*
> @@ -502,14 +502,34 @@ static void glk_load_degamma_lut(struct
> intel_crtc_state *crtc_state)
> I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), 0);
> I915_WRITE(PRE_CSC_GAMC_INDEX(pipe), PRE_CSC_GAMC_AUTO_INCREMENT);
>
> - /*
> - * FIXME: The pipe degamma table in geminilake doesn't support
> - * different values per channel, so this just loads a linear table.
> - */
> - for (i = 0; i < lut_size; i++) {
> - uint32_t v = (i * (1 << 16)) / (lut_size - 1);
>
> - I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
> + if (crtc_state->base.degamma_lut) {
> + struct drm_color_lut *lut = crtc_state->base.degamma_lut->data;
> +
> + for (i = 0; i < lut_size; i++) {
> + /*
> + * First 33 entries represent range from 0 to 1.0
> + * 34th and 35th entry will represent extended range
> + * inputs 3.0 and 7.0 respectively, currently clamped
> + * at 1.0. Since the precision is 16bit, the user
> + * value can be directly filled to register.
> + * The pipe degamma table in GLK+ onwards doesn't
> + * support different values per channel, so this just
> + * programs green value which will be equal to Red and
> + * Blue into the lut registers.
> + * ToDo: Extend to max 7.0. Enable 32 bit input value
> + * as compared to just 16 to achieve this.
> + */
> + I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
> + I915_WRITE(PRE_CSC_GAMC_DATA(pipe), lut[i].green);
I don't think the double-write here was intentional (and would probably
cause more problems than usual due to the index auto increment).
Other than that,
Reviewed-by: Matt Roper
> + }
> + } else {
> + /* load a linear table. */
> + for (i = 0; i < lut_size; i++) {
> + uint32_t v = (i * (1 << 16)) / (lut_size - 1);
> +
> + I915_WRITE(PRE_CSC_GAMC_DATA(pipe), v);
> + }
> }
>
> /* Clamp values > 1.0. */
> --
> 1.9.1
>
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects
Den 28.01.2019 21.57, skrev Rob Herring:
> On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
>>
>>
>> Den 30.11.2018 00.58, skrev Eric Anholt:
>>> Daniel Vetter writes:
>>>
On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
> Daniel Vetter writes:
>
>> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
>>> Daniel Vetter writes:
>>>
On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
> Noralf Trønnes writes:
>> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>> +{
>> + struct drm_gem_object *obj = vma->vm_private_data;
>> + struct drm_gem_shmem_object *shmem =
>> to_drm_gem_shmem_obj(obj);
>> +
>> + drm_gem_shmem_put_pages(shmem);
>> + drm_gem_vm_close(vma);
>> +}
>> +
>> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>> + .fault = drm_gem_shmem_fault,
>> + .open = drm_gem_vm_open,
>> + .close = drm_gem_shmem_vm_close,
>> +};
>> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
> I just saw a warning from drm_gem_shmem_put_pages() for
> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
> drm_gem_shmem_get_pages().
Yeah we need a drm_gem_shmem_vm_open here.
>>> Adding one of those fixed my refcounting issues, so I've sent out a v6
>>> with it.
>> Just realized that I've reviewed this patch already, spotted that vma
>> management issue there too. Plus a pile of other things. From reading
>> that
>> other thread discussion with Noralf concluded with "not yet ready for
>> prime time" unfortunately :-/
> I saw stuff about how it wasn't usable for SPI because SPI does weird
> things with DMA mapping. Was there something else?
Looking through that mail it was a bunch of comments to improve the
kerneldoc. Plus a note that buffer sharing/mmap is going to be all
incoherent and horrible (but I guess for vkms we don't care that much).
I'm just kinda vary of generic buffer handling that turns out to not be
actually all that useful. We have lots of deadends and kinda-midlayers in
this area already (but this one here definitely smells plenty better than
lots of older ones).
>>> FWIW, I really want shmem helpers for v3d. The fault handling in
>>> particular has magic I don't understand, and this is not my first fault
>>> handler. :/
>>
>>
>> If you can use it for a "real" hw driver like v3d, I think it makes a lot
>> sense to have it as a helper. I believe udl and a future simpledrm can
>> also make use of it.
>
> FWIW, I think etnaviv at least could use this too.
>
> I'm starting to look at panfrost and lima drivers and was trying to
> figure out where to start with the GEM code. So I've been comparing
> etnaviv, freedreno, and vgem implementations. They are all pretty
> similar from what I see. The per driver GEM obj structs certainly are.
> I can't bring myself to just copy etnaviv code over and do a
> s/etnaviv/panfrost/. So searching around a bit, I ended up on this
> thread. This seems to be what I need for panfrost (based on my brief
> study).
>
I gave up on this due to problems with SPI DMA.
Eric tried to use it with vkms, but it failed. On his blog he speculates
that it might be due to cached CPU mappings:
https://anholt.github.io/twivc4/2018/12/03/twiv/
For tinydrm I wanted cached mappings, but it might not work that well
with shmem. Maybe that's why I had problems with SPI DMA.
Maybe this change to drm_gem_shmem_mmap() is all it takes:
- vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
The memory subsystem is really complicated and I have kind of given up
on trying to decipher it.
Noralf.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: MST and wakeref leak fixes
== Series Details == Series: drm/i915: MST and wakeref leak fixes URL : https://patchwork.freedesktop.org/series/55868/ State : warning == Summary == $ dim checkpatch origin/drm-tip 642ed0b4731b drm/i915: Block fbdev HPD processing during suspend -:69: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #69: FILE: drivers/gpu/drm/i915/intel_drv.h:218: + bool hpd_suspended : 1; -:73: WARNING:BOOL_BITFIELD: Avoid using bool as bitfield. Prefer bool bitfields as unsigned int or u<8|16|32> #73: FILE: drivers/gpu/drm/i915/intel_drv.h:222: + bool hpd_waiting : 1; total: 0 errors, 2 warnings, 0 checks, 77 lines checked cd2c9cb2d8c9 drm/i915: Don't send MST hotplugs during resume 5733e3284791 drm/i915: Don't send hotplug in intel_dp_check_mst_status() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 4/5] drm: Add library for shmem backed GEM objects
On Sun, Dec 2, 2018 at 9:59 AM Noralf Trønnes wrote:
>
>
> Den 30.11.2018 00.58, skrev Eric Anholt:
> > Daniel Vetter writes:
> >
> >> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote:
> >>> Daniel Vetter writes:
> >>>
> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote:
> > Daniel Vetter writes:
> >
> >> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote:
> >>> Noralf Trønnes writes:
> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
> +{
> + struct drm_gem_object *obj = vma->vm_private_data;
> + struct drm_gem_shmem_object *shmem =
> to_drm_gem_shmem_obj(obj);
> +
> + drm_gem_shmem_put_pages(shmem);
> + drm_gem_vm_close(vma);
> +}
> +
> +const struct vm_operations_struct drm_gem_shmem_vm_ops = {
> + .fault = drm_gem_shmem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_shmem_vm_close,
> +};
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops);
> >>> I just saw a warning from drm_gem_shmem_put_pages() for
> >>> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to
> >>> drm_gem_shmem_get_pages().
> >> Yeah we need a drm_gem_shmem_vm_open here.
> > Adding one of those fixed my refcounting issues, so I've sent out a v6
> > with it.
> Just realized that I've reviewed this patch already, spotted that vma
> management issue there too. Plus a pile of other things. From reading
> that
> other thread discussion with Noralf concluded with "not yet ready for
> prime time" unfortunately :-/
> >>> I saw stuff about how it wasn't usable for SPI because SPI does weird
> >>> things with DMA mapping. Was there something else?
> >> Looking through that mail it was a bunch of comments to improve the
> >> kerneldoc. Plus a note that buffer sharing/mmap is going to be all
> >> incoherent and horrible (but I guess for vkms we don't care that much).
> >> I'm just kinda vary of generic buffer handling that turns out to not be
> >> actually all that useful. We have lots of deadends and kinda-midlayers in
> >> this area already (but this one here definitely smells plenty better than
> >> lots of older ones).
> > FWIW, I really want shmem helpers for v3d. The fault handling in
> > particular has magic I don't understand, and this is not my first fault
> > handler. :/
>
>
> If you can use it for a "real" hw driver like v3d, I think it makes a lot
> sense to have it as a helper. I believe udl and a future simpledrm can
> also make use of it.
FWIW, I think etnaviv at least could use this too.
I'm starting to look at panfrost and lima drivers and was trying to
figure out where to start with the GEM code. So I've been comparing
etnaviv, freedreno, and vgem implementations. They are all pretty
similar from what I see. The per driver GEM obj structs certainly are.
I can't bring myself to just copy etnaviv code over and do a
s/etnaviv/panfrost/. So searching around a bit, I ended up on this
thread. This seems to be what I need for panfrost (based on my brief
study).
Rob
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: Block fbdev HPD processing during suspend
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.
This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.
(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).
We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.
This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.
Signed-off-by: Lyude Paul
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Imre Deak
Cc: intel-gfx@lists.freedesktop.org
Cc: # v3.17+
---
drivers/gpu/drm/i915/intel_drv.h | 10 ++
drivers/gpu/drm/i915/intel_fbdev.c | 30 +-
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85b913ea6e80..c8549588b2ce 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -213,6 +213,16 @@ struct intel_fbdev {
unsigned long vma_flags;
async_cookie_t cookie;
int preferred_bpp;
+
+ /* Whether or not fbdev hpd processing is temporarily suspended */
+ bool hpd_suspended : 1;
+ /* Set when a hotplug was received while HPD processing was
+* suspended
+*/
+ bool hpd_waiting : 1;
+
+ /* Protects hpd_suspended */
+ struct mutex hpd_lock;
};
struct intel_encoder {
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 8cf3efe88f02..3a6c0bebaaf9 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -681,6 +681,7 @@ int intel_fbdev_init(struct drm_device *dev)
if (ifbdev == NULL)
return -ENOMEM;
+ mutex_init(>hpd_lock);
drm_fb_helper_prepare(dev, >helper, _fb_helper_funcs);
if (!intel_fbdev_init_bios(dev, ifbdev))
@@ -754,6 +755,23 @@ void intel_fbdev_fini(struct drm_i915_private *dev_priv)
intel_fbdev_destroy(ifbdev);
}
+/* Suspends/resumes fbdev processing of incoming HPD events. When resuming HPD
+ * processing, fbdev will perform a full connector reprobe if a hotplug event
+ * was received while HPD was suspended.
+ */
+static void intel_fbdev_hpd_set_suspend(struct intel_fbdev *ifbdev, int state)
+{
+ mutex_lock(>hpd_lock);
+ ifbdev->hpd_suspended = state == FBINFO_STATE_SUSPENDED;
+ if (ifbdev->hpd_waiting) {
+ ifbdev->hpd_waiting = false;
+
+ DRM_DEBUG_KMS("Handling delayed fbcon HPD event\n");
+ drm_fb_helper_hotplug_event(>helper);
+ }
+ mutex_unlock(>hpd_lock);
+}
+
void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -775,6 +793,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
*/
[Intel-gfx] [PATCH v2 0/3] drm/i915: MST and wakeref leak fixes
While trying to fix a problem with suspend/resume that I introduced in the atomic VCPI helpers for MST, I also ran into some issues with i915 varying from "not that bad" to "oh wow that's very bad". Here are the fixes for those issues. This series was originally just one patch, "drm/i915: Don't send MST hotplugs during resume" Lyude Paul (3): drm/i915: Block fbdev HPD processing during suspend drm/i915: Don't send MST hotplugs during resume drm/i915: Don't send hotplug in intel_dp_check_mst_status() drivers/gpu/drm/i915/intel_dp.c| 13 +++-- drivers/gpu/drm/i915/intel_drv.h | 10 ++ drivers/gpu/drm/i915/intel_fbdev.c | 30 +- 3 files changed, 46 insertions(+), 7 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: Don't send hotplug in intel_dp_check_mst_status()
This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c2399acf177b..f9113c0cdfcd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4608,12 +4608,10 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
return ret;
} else {
- struct intel_digital_port *intel_dig_port =
dp_to_dig_port(intel_dp);
DRM_DEBUG_KMS("failed to get ESI - device may have
failed\n");
intel_dp->is_mst = false;
- drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
intel_dp->is_mst);
- /* send a hotplug event */
-
drm_kms_helper_hotplug_event(intel_dig_port->base.base.dev);
+ drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
+ intel_dp->is_mst);
}
}
return -EINVAL;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Don't send MST hotplugs during resume
We have a bad habit of calling drm_fb_helper_hotplug_event() far more
then we actually need to. MST appears to be one of these cases, where we
call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
topology in intel_dp_mst_resume(). We don't actually need to do this at
all though since hotplug events are already sent from
drm_dp_connector_destroy_work() every time connectors are unregistered
from userspace's PoV. Additionally, extra calls to
drm_fb_helper_hotplug_event() also just mean more of a chance of doing a
connector probe somewhere we shouldn't.
So, don't send any hotplug events during resume if the MST topology
fails to come up. Just rely on the DP MST helpers to send them for us.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 681e88405ada..c2399acf177b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private
*dev_priv)
continue;
ret = drm_dp_mst_topology_mgr_resume(_dp->mst_mgr);
- if (ret)
- intel_dp_check_mst_status(intel_dp);
+ if (ret) {
+ intel_dp->is_mst = false;
+ drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
+ false);
+ }
}
}
--
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 drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
URL : https://patchwork.freedesktop.org/series/55733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494_full -> Patchwork_12058_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12058_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-contexts-10ms:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#109467]
* igt@gem_eio@wait-immediate:
- shard-kbl: PASS -> FAIL [fdo#105957]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-x:
- shard-hsw: PASS -> DMESG-WARN [fdo#102614]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +2
* igt@prime_vgem@basic-fence-flip:
- shard-kbl: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_plane_alpha_blend@pipe-b-alpha-opaque-fb:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: FAIL [fdo#109016] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-modeset-hang:
- shard-snb: {SKIP} [fdo#109271] -> PASS
* igt@prime_busy@hang-bsd:
- shard-hsw: FAIL [fdo#108807] -> PASS
Warnings
* igt@gem_eio@in-flight-immediate:
- shard-kbl: DMESG-FAIL [fdo#109467] -> DMESG-WARN [fdo#109467]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105957]: https://bugs.freedesktop.org/show_bug.cgi?id=105957
[fdo#106641]: https://bugs.freedesktop.org/show_bug.cgi?id=106641
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108807]: https://bugs.freedesktop.org/show_bug.cgi?id=108807
[fdo#109016]: https://bugs.freedesktop.org/show_bug.cgi?id=109016
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109467]: https://bugs.freedesktop.org/show_bug.cgi?id=109467
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5494 -> Patchwork_12058
CI_DRM_5494: 543c074ff6a401b2bca5333234a9c13c4b0a5152 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4795: 031715e369cf01aecbe293910211e80e51995ffb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12058: cfbebb24056d36048d2eef0c934c85ef4a4695c0 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12058/
___
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 [CI,1/5] drm/i915: Stop tracking MRU activity on VMA
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on
VMA
URL : https://patchwork.freedesktop.org/series/55829/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494_full -> Patchwork_12057_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12057_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@in-flight-contexts-10ms:
- shard-apl: NOTRUN -> DMESG-WARN [fdo#109467]
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
- shard-glk: PASS -> FAIL [fdo#106641]
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x21-offscreen:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +3
* igt@kms_universal_plane@universal-plane-pipe-a-functional:
- shard-apl: PASS -> FAIL [fdo#103166]
Possible fixes
* igt@kms_cursor_crc@cursor-64x21-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: FAIL [fdo#103166] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: FAIL [fdo#109016] -> PASS
* igt@kms_vblank@pipe-b-ts-continuation-modeset-hang:
- shard-snb: {SKIP} [fdo#109271] -> PASS
* igt@prime_busy@hang-bsd:
- shard-hsw: FAIL [fdo#108807] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103540]: https://bugs.freedesktop.org/show_bug.cgi?id=103540
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#106641]: https://bugs.freedesktop.org/show_bug.cgi?id=106641
[fdo#108807]: https://bugs.freedesktop.org/show_bug.cgi?id=108807
[fdo#109016]: https://bugs.freedesktop.org/show_bug.cgi?id=109016
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109467]: https://bugs.freedesktop.org/show_bug.cgi?id=109467
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (6 -> 5)
--
Missing(1): shard-skl
Build changes
-
* Linux: CI_DRM_5494 -> Patchwork_12057
CI_DRM_5494: 543c074ff6a401b2bca5333234a9c13c4b0a5152 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4795: 031715e369cf01aecbe293910211e80e51995ffb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12057: 58651f8391777c88dccd46da5a609a7e4b636e16 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12057/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Apply LUT validation checks to platforms more accurately
On Fri, Jan 25, 2019 at 05:28:40PM -0800, Matt Roper wrote:
> Use of the new DRM_COLOR_LUT_NON_DECREASING test was a bit over-zealous;
> it doesn't actually need to be applied to the degamma on "bdw-style"
> platforms. Likewise, we overlooked the fact that CHV should have that
> test applied to the gamma LUT as well as the degamma LUT.
>
> Rather than adding more complicated platform checking to
> intel_color_check(), let's just store the appropriate set of LUT
> validation flags for each platform in the intel_device_info structure.
>
> Fixes: 85e2d61e4976 ("drm/i915: Validate userspace-provided color management
> LUT's (v4)")
> References:
> https://lists.freedesktop.org/archives/intel-gfx/2019-January/187634.html
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_pci.c | 10 --
> drivers/gpu/drm/i915/intel_color.c | 19 +--
> drivers/gpu/drm/i915/intel_device_info.h | 2 ++
> 3 files changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 44c23ac60347..17f5a605b0b3 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -69,9 +69,15 @@
> #define BDW_COLORS \
> .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
> #define CHV_COLORS \
> - .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> + .color = { .degamma_lut_size = 65, .gamma_lut_size = 257, \
> +.degamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING, \
> +.gamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING, \
> + }
> #define GLK_COLORS \
> - .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024 }
> + .color = { .degamma_lut_size = 0, .gamma_lut_size = 1024, \
> +.degamma_lut_tests = DRM_COLOR_LUT_NON_DECREASING | \
> + DRM_COLOR_LUT_EQUAL_CHANNELS, \
> + }
>
> /* Keep in gen based order, and chronological order within a gen */
>
> diff --git a/drivers/gpu/drm/i915/intel_color.c
> b/drivers/gpu/drm/i915/intel_color.c
> index bc7589656a8f..cd08f58b1e47 100644
> --- a/drivers/gpu/drm/i915/intel_color.c
> +++ b/drivers/gpu/drm/i915/intel_color.c
> @@ -609,24 +609,15 @@ int intel_color_check(struct intel_crtc_state
> *crtc_state)
> {
> struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> size_t gamma_length, degamma_length;
> - uint32_t tests = DRM_COLOR_LUT_NON_DECREASING;
> + u32 gamma_tests, degamma_tests;
>
> degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
> gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
> + degamma_tests = INTEL_INFO(dev_priv)->color.degamma_lut_tests;
> + gamma_tests = INTEL_INFO(dev_priv)->color.gamma_lut_tests;
>
> - /*
> - * All of our platforms mandate that the degamma curve be
> - * non-decreasing. Additionally, GLK and gen11 only accept a single
> - * value for red, green, and blue in the degamma table. Make sure
> - * userspace didn't try to pass us something we can't handle.
> - *
> - * We don't have any extra hardware constraints on the gamma table,
> - * so no need to explicitly check it.
> - */
> - if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 10)
> - tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
> -
> - if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
> + if (drm_color_lut_check(crtc_state->base.degamma_lut, degamma_tests) ||
> + drm_color_lut_check(crtc_state->base.gamma_lut, gamma_tests))
We'll need to exclude the legacy LUT from this test somehow.
> return -EINVAL;
>
> /*
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 957c6527f76b..7bf09cef591a 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -189,6 +189,8 @@ struct intel_device_info {
> struct color_luts {
> u16 degamma_lut_size;
> u16 gamma_lut_size;
> + u32 degamma_lut_tests;
> + u32 gamma_lut_tests;
> } color;
> };
>
> --
> 2.14.5
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
== Series Details ==
Series: series starting with [CI,1/6] drm/i915: Introduce concept of
per-timeline (context) HWSP
URL : https://patchwork.freedesktop.org/series/55856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5497 -> Patchwork_12061
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55856/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12061 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_execlists:
- fi-apl-guc: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- fi-byt-clapper: FAIL [fdo#103167] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#108622]: https://bugs.freedesktop.org/show_bug.cgi?id=108622
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
Participating hosts (43 -> 41)
--
Additional (1): fi-hsw-4770r
Missing(3): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5497 -> Patchwork_12061
CI_DRM_5497: 67aa6866708f2fa3a2ec914257cca94a872072ac @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12061: 84abe369e1be51fe392e6a97143cd9377b8ea135 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
84abe369e1be drm/i915: Track active timelines
30cf3f265ea3 drm/i915: Track the context's seqno in its own timeline HWSP
34006d56d0d6 drm/i915: Share per-timeline HWSP using a slab suballocator
6b1e92bf46ca drm/i915: Allocate a status page for each timeline
7b660a9e3cd7 drm/i915: Enlarge vma->pin_count
d5418c9092a6 drm/i915: Introduce concept of per-timeline (context) HWSP
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12061/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
== Series Details == Series: series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP URL : https://patchwork.freedesktop.org/series/55856/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Introduce concept of per-timeline (context) HWSP Okay! Commit: drm/i915: Enlarge vma->pin_count Okay! Commit: drm/i915: Allocate a status page for each timeline +./include/linux/mm.h:619:13: error: not a function +./include/linux/mm.h:619:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/mm.h:619:13: warning: call with no type! Commit: drm/i915: Share per-timeline HWSP using a slab suballocator -drivers/gpu/drm/i915/selftests/../i915_drv.h:3544:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3548:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:89:38: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:89:38: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:92:44: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/i915_timeline.c:92:44: warning: expression using sizeof(void) +./include/linux/slab.h:664:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:664:13: warning: call with no type! Commit: drm/i915: Track the context's seqno in its own timeline HWSP Okay! Commit: drm/i915: Track active timelines Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
== Series Details == Series: series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP URL : https://patchwork.freedesktop.org/series/55856/ State : warning == Summary == $ dim checkpatch origin/drm-tip d5418c9092a6 drm/i915: Introduce concept of per-timeline (context) HWSP 7b660a9e3cd7 drm/i915: Enlarge vma->pin_count 6b1e92bf46ca drm/i915: Allocate a status page for each timeline 34006d56d0d6 drm/i915: Share per-timeline HWSP using a slab suballocator -:85: CHECK:SPACING: No space is necessary after a cast #85: FILE: drivers/gpu/drm/i915/i915_timeline.c:49: + BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE); total: 0 errors, 0 warnings, 1 checks, 408 lines checked 30cf3f265ea3 drm/i915: Track the context's seqno in its own timeline HWSP 84abe369e1be drm/i915: Track active timelines ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for icl: Misc PLL patches (rev3)
== Series Details ==
Series: icl: Misc PLL patches (rev3)
URL : https://patchwork.freedesktop.org/series/55378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5496 -> Patchwork_12060
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55378/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12060 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: WARN [fdo#109380] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> PASS +33
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Participating hosts (41 -> 40)
--
Additional (2): fi-glk-j4005 fi-pnv-d510
Missing(3): fi-icl-y fi-ilk-m540 fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5496 -> Patchwork_12060
CI_DRM_5496: 32894ce8772d3679dbe8368d4cdab6d92efe4d25 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4796: d1bd9c6ad6f3482bbccf4aa6417dd449e9efbe39 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12060: aa2c54207f3d50b7b3ea278675b74f3bcb36ed8c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
aa2c54207f3d drm/i915/icl: keep track of unused pll while looping
ba2294c9c01e drm/i915/icl: remove dpll from clk_sel
62571d76a760 drm/i915: always return something on DDI clock selection
df9a6b02958e drm/i915/icl: use tc_port in MG_PLL macros
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12060/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/6] drm/i915: Allocate a status page for each timeline
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP for the solitary ringbuffer
timeline, so that we do not have to emit (using per-gen specialised
vfuncs) the breadcrumb into the distinct timeline HWSP and instead can
keep on using the common MI_STORE_DWORD_INDEX. However, to maintain the
sleight-of-hand for the global/per-context seqno switchover, we will
store both temporarily (and so use a custom offset for the shared timeline
HWSP until the switch over).
v3: Keep things simple and allocate a page for each timeline, page
sharing comes next.
v4: I was caught repeating the same MI_STORE_DWORD_IMM over and over
again in selftests.
v5: And caught red handed copying create timeline + check.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_timeline.c | 121 ++-
drivers/gpu/drm/i915/i915_timeline.h | 21 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 76 ++--
drivers/gpu/drm/i915/intel_lrc.c | 22 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 +-
.../drm/i915/selftests/i915_live_selftests.h | 1 +
.../drm/i915/selftests/i915_mock_selftests.h | 2 +-
.../gpu/drm/i915/selftests/i915_timeline.c| 326 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 14 +-
10 files changed, 543 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 84550f17d3df..8d5792311a8f 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,28 +9,78 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
-void i915_timeline_init(struct drm_i915_private *i915,
- struct i915_timeline *timeline,
- const char *name)
+static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+
+ obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, >ggtt.vm, NULL);
+ if (IS_ERR(vma))
+ i915_gem_object_put(obj);
+
+ return vma;
+}
+
+static int hwsp_alloc(struct i915_timeline *timeline)
+{
+ struct i915_vma *vma;
+
+ vma = __hwsp_alloc(timeline->i915);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ timeline->hwsp_ggtt = vma;
+ timeline->hwsp_offset = 0;
+
+ return 0;
+}
+
+int i915_timeline_init(struct drm_i915_private *i915,
+ struct i915_timeline *timeline,
+ const char *name,
+ struct i915_vma *global_hwsp)
{
struct i915_gt_timelines *gt = >gt.timelines;
+ void *vaddr;
+ int err;
/*
* Ideally we want a set of engines on a single leaf as we expect
* to mostly be tracking synchronisation between engines. It is not
* a huge issue if this is not the case, but we may want to mitigate
* any page crossing penalties if they become an issue.
+*
+* Called during early_init before we know how many engines there are.
*/
BUILD_BUG_ON(KSYNCMAP < I915_NUM_ENGINES);
timeline->i915 = i915;
timeline->name = name;
+ timeline->pin_count = 0;
+
+ if (global_hwsp) {
+ timeline->hwsp_ggtt = i915_vma_get(global_hwsp);
+ timeline->hwsp_offset = I915_GEM_HWS_SEQNO_ADDR;
+ } else {
+ err = hwsp_alloc(timeline);
+ if (err)
+ return err;
+ }
- mutex_lock(>mutex);
- list_add(>link, >list);
- mutex_unlock(>mutex);
+ vaddr = i915_gem_object_pin_map(timeline->hwsp_ggtt->obj, I915_MAP_WB);
+ if (IS_ERR(vaddr)) {
+ i915_vma_put(timeline->hwsp_ggtt);
+ return PTR_ERR(vaddr);
+ }
- /* Called during early_init before we know how many engines there are */
+ timeline->hwsp_seqno =
+ memset(vaddr + timeline->hwsp_offset, 0, CACHELINE_BYTES);
timeline->fence_context = dma_fence_context_alloc(1);
@@ -40,6 +90,12 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(>requests);
i915_syncmap_init(>sync);
+
+ mutex_lock(>mutex);
+ list_add(>link, >list);
+ mutex_unlock(>mutex);
+
+ return 0;
}
void i915_timelines_init(struct drm_i915_private *i915)
@@ -85,6 +141,7 @@ void i915_timeline_fini(struct i915_timeline *timeline)
{
struct
[Intel-gfx] [CI 6/6] drm/i915: Track active timelines
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_reset.c| 2 +-
drivers/gpu/drm/i915/i915_timeline.c | 39 ++--
4 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a051381f535..d072f3369ee1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1977,7 +1977,7 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
- struct list_head list;
+ struct list_head active_list;
/* Pack multiple timelines' seqnos into the same page */
spinlock_t hwsp_lock;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1bd724d663d9..05627000b77d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3248,7 +3248,7 @@ wait_for_timelines(struct drm_i915_private *i915,
return timeout;
mutex_lock(>mutex);
- list_for_each_entry(tl, >list, link) {
+ list_for_each_entry(tl, >active_list, link) {
struct i915_request *rq;
rq = i915_gem_active_get_unlocked(>last_request);
@@ -3276,7 +3276,7 @@ wait_for_timelines(struct drm_i915_private *i915,
/* restart after reacquiring the lock */
mutex_lock(>mutex);
- tl = list_entry(>list, typeof(*tl), link);
+ tl = list_entry(>active_list, typeof(*tl), link);
}
mutex_unlock(>mutex);
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index bd82f9b1043f..acf3c777e49d 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -856,7 +856,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* No more can be submitted until we reset the wedged bit.
*/
mutex_lock(>gt.timelines.mutex);
- list_for_each_entry(tl, >gt.timelines.list, link) {
+ list_for_each_entry(tl, >gt.timelines.active_list, link) {
struct i915_request *rq;
long timeout;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index e4c11414a824..79838d89bdb9 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -120,7 +120,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
const char *name,
struct i915_vma *hwsp)
{
- struct i915_gt_timelines *gt = >gt.timelines;
void *vaddr;
/*
@@ -168,10 +167,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
i915_syncmap_init(>sync);
- mutex_lock(>mutex);
- list_add(>link, >list);
- mutex_unlock(>mutex);
-
return 0;
}
@@ -180,7 +175,7 @@ void i915_timelines_init(struct drm_i915_private *i915)
struct i915_gt_timelines *gt = >gt.timelines;
mutex_init(>mutex);
- INIT_LIST_HEAD(>list);
+ INIT_LIST_HEAD(>active_list);
spin_lock_init(>hwsp_lock);
INIT_LIST_HEAD(>hwsp_free_list);
@@ -189,6 +184,24 @@ void i915_timelines_init(struct drm_i915_private *i915)
i915_gem_shrinker_taints_mutex(i915, >mutex);
}
+static void timeline_add_to_active(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+
+ mutex_lock(>mutex);
+ list_add(>link, >active_list);
+ mutex_unlock(>mutex);
+}
+
+static void timeline_remove_from_active(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+
+ mutex_lock(>mutex);
+ list_del(>link);
+ mutex_unlock(>mutex);
+}
+
/**
* i915_timelines_park - called when the driver idles
* @i915: the drm_i915_private device
@@ -205,7 +218,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
struct i915_timeline *timeline;
mutex_lock(>mutex);
- list_for_each_entry(timeline, >list, link) {
+ list_for_each_entry(timeline, >active_list, link) {
/*
* All known fences are completed so we can scrap
* the current sync point tracking and start afresh,
@@ -219,15 +232,9 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
- struct i915_gt_timelines *gt = >i915->gt.timelines;
-
GEM_BUG_ON(timeline->pin_count);
[Intel-gfx] [CI 5/6] drm/i915: Track the context's seqno in its own timeline HWSP
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to unwind the per-context timeline, and so requests are
always consistent with the timeline breadcrumb, greatly simplifying the
completion checks as we no longer need to be concerned about the
global_seqno changing mid check.
One complication though is that we have to be wary that the request may
outlive the HWSP and so avoid touching the potentially danging pointer
after we have retired the fence. We also have to guard our access of the
HWSP with RCU, the release of the obj->mm.pages should already be RCU-safe.
At this point, we are emitting both per-context and global seqno and
still using the single per-engine execution timeline for resolving
interrupts.
v2: s/fake_complete/mark_complete/
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 3 +-
drivers/gpu/drm/i915/i915_request.h | 30 +++
drivers/gpu/drm/i915/i915_reset.c | 1 +
drivers/gpu/drm/i915/i915_timeline.c | 4 +
drivers/gpu/drm/i915/intel_engine_cs.c| 15 +++-
drivers/gpu/drm/i915/intel_lrc.c | 31 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 87 +++
.../gpu/drm/i915/selftests/i915_timeline.c| 7 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 19 +++-
10 files changed, 139 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d68f3fdd8a8e..1bd724d663d9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2892,7 +2892,7 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
*/
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry(request, >timeline.requests, link) {
- if (__i915_request_completed(request, request->global_seqno))
+ if (i915_request_completed(request))
continue;
active = request;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a076fd0b7ba6..4d58770e6a8c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -199,6 +199,7 @@ static void __retire_engine_request(struct intel_engine_cs
*engine,
spin_unlock(>timeline.lock);
spin_lock(>lock);
+ i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(>fence);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
@@ -621,7 +622,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
- rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
+ rq->hwsp_seqno = rq->timeline->hwsp_seqno;
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index ade010fe6e26..96c586d6ff4d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -289,6 +289,7 @@ long i915_request_wait(struct i915_request *rq,
static inline bool i915_request_signaled(const struct i915_request *rq)
{
+ /* The request may live longer than its HWSP, so check flags first! */
return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags);
}
@@ -340,32 +341,23 @@ static inline u32 hwsp_seqno(const struct i915_request
*rq)
*/
static inline bool i915_request_started(const struct i915_request *rq)
{
- u32 seqno;
-
- seqno = i915_request_global_seqno(rq);
- if (!seqno) /* not yet submitted to HW */
- return false;
+ if (i915_request_signaled(rq))
+ return true;
- return i915_seqno_passed(hwsp_seqno(rq), seqno - 1);
-}
-
-static inline bool
-__i915_request_completed(const struct i915_request *rq, u32 seqno)
-{
- GEM_BUG_ON(!seqno);
- return i915_seqno_passed(hwsp_seqno(rq), seqno) &&
- seqno == i915_request_global_seqno(rq);
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
}
static inline bool i915_request_completed(const struct i915_request *rq)
{
- u32 seqno;
+ if (i915_request_signaled(rq))
+ return true;
- seqno = i915_request_global_seqno(rq);
- if (!seqno)
- return false;
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno);
+}
- return __i915_request_completed(rq, seqno);
+static inline void i915_request_mark_complete(struct i915_request *rq)
+{
[Intel-gfx] [CI 2/6] drm/i915: Enlarge vma->pin_count
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum permissible pin_count small allows us to quickly catch a
potential leak. However, as we want to split a 4096B page into 64
different cachelines and pin each cacheline for use by a different
timeline, we will exceed the current maximum permissible vma->pin_count
and so time has come to enlarge it.
Whilst we are here, try to pull together the similar bits:
Address/layout specification:
- bias, mappable, zone_4g: address limit specifiers
- fixed: address override, limits still apply though
- high: not strictly an address limit, but an address direction to search
Search controls:
- nonblock, nonfault, noevict
v2: Rewrite the guideline comment on bit consumption.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 -
drivers/gpu/drm/i915/i915_vma.h | 45 +++--
2 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index bd679c8c56dd..03ade71b8d9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -642,19 +642,19 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
/* Flags used by pin/bind */
#define PIN_NONBLOCK BIT_ULL(0)
-#define PIN_MAPPABLE BIT_ULL(1)
-#define PIN_ZONE_4GBIT_ULL(2)
-#define PIN_NONFAULT BIT_ULL(3)
-#define PIN_NOEVICTBIT_ULL(4)
-
-#define PIN_MBZBIT_ULL(5) /* I915_VMA_PIN_OVERFLOW */
-#define PIN_GLOBAL BIT_ULL(6) /* I915_VMA_GLOBAL_BIND */
-#define PIN_USER BIT_ULL(7) /* I915_VMA_LOCAL_BIND */
-#define PIN_UPDATE BIT_ULL(8)
-
-#define PIN_HIGH BIT_ULL(9)
-#define PIN_OFFSET_BIASBIT_ULL(10)
-#define PIN_OFFSET_FIXED BIT_ULL(11)
+#define PIN_NONFAULT BIT_ULL(1)
+#define PIN_NOEVICTBIT_ULL(2)
+#define PIN_MAPPABLE BIT_ULL(3)
+#define PIN_ZONE_4GBIT_ULL(4)
+#define PIN_HIGH BIT_ULL(5)
+#define PIN_OFFSET_BIASBIT_ULL(6)
+#define PIN_OFFSET_FIXED BIT_ULL(7)
+
+#define PIN_MBZBIT_ULL(8) /* I915_VMA_PIN_OVERFLOW */
+#define PIN_GLOBAL BIT_ULL(9) /* I915_VMA_GLOBAL_BIND */
+#define PIN_USER BIT_ULL(10) /* I915_VMA_LOCAL_BIND */
+#define PIN_UPDATE BIT_ULL(11)
+
#define PIN_OFFSET_MASK(-I915_GTT_PAGE_SIZE)
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 7252abc73d3e..5793abe509a2 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -71,29 +71,42 @@ struct i915_vma {
unsigned int open_count;
unsigned long flags;
/**
-* How many users have pinned this object in GTT space. The following
-* users can each hold at most one reference: pwrite/pread, execbuffer
-* (objects are not allowed multiple times for the same batchbuffer),
-* and the framebuffer code. When switching/pageflipping, the
-* framebuffer code has at most two buffers pinned per crtc.
+* How many users have pinned this object in GTT space.
*
-* In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
-* bits with absolutely no headroom. So use 4 bits.
+* This is a tightly bound, fairly small number of users, so we
+* stuff inside the flags field so that we can both check for overflow
+* and detect a no-op i915_vma_pin() in a single check, while also
+* pinning the vma.
+*
+* The worst case display setup would have the same vma pinned for
+* use on each plane on each crtc, while also building the next atomic
+* state and holding a pin for the length of the cleanup queue. In the
+* future, the flip queue may be increased from 1.
+* Estimated worst case: 3 [qlen] * 4 [max crtcs] * 7 [max planes] = 84
+*
+* For GEM, the number of concurrent users for pwrite/pread is
+* unbounded. For execbuffer, it is currently one but will in future
+* be extended to allow multiple clients to pin vma concurrently.
+*
+* We also use suballocated pages, with each suballocation claiming
+* its own pin on the shared vma. At present, this is limited to
+* exclusive cachelines of a single page, so a maximum of 64 possible
+* users.
*/
-#define I915_VMA_PIN_MASK 0xf
-#define I915_VMA_PIN_OVERFLOW BIT(5)
+#define I915_VMA_PIN_MASK 0xff
+#define I915_VMA_PIN_OVERFLOW BIT(8)
/**
[Intel-gfx] [CI 4/6] drm/i915: Share per-timeline HWSP using a slab suballocator
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh allocation as a slab of 64 entries, we can keep it
around for the next 64 allocation attempts until we need to refresh the
slab cache.
John Harrison noted the issue of fragmentation leading to the same worst
case performance of one page per timeline as before, which can be
mitigated by adopting a freelist.
v2: Keep all partially allocated HWSP on a freelist
This is still without migration, so it is possible for the system to end
up with each timeline in its own page, but we ensure that no new
allocation would needless allocate a fresh page!
v3: Throw a selftest at the allocator to try and catch invalid cacheline
reuse.
Signed-off-by: Chris Wilson
Cc: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_timeline.c | 124 ---
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/selftests/i915_random.c | 33 +++-
drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
.../gpu/drm/i915/selftests/i915_timeline.c| 143 ++
6 files changed, 280 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8a181b455197..6a051381f535 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1978,6 +1978,10 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
struct list_head list;
+
+ /* Pack multiple timelines' seqnos into the same page */
+ spinlock_t hwsp_lock;
+ struct list_head hwsp_free_list;
} timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 8d5792311a8f..add8fc33cf6e 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,6 +9,18 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
+struct i915_timeline_hwsp {
+ struct i915_vma *vma;
+ struct list_head free_link;
+ u64 free_bitmap;
+};
+
+static inline struct i915_timeline_hwsp *
+i915_timeline_hwsp(const struct i915_timeline *tl)
+{
+ return tl->hwsp_ggtt->private;
+}
+
static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
{
struct drm_i915_gem_object *obj;
@@ -27,28 +39,89 @@ static struct i915_vma *__hwsp_alloc(struct
drm_i915_private *i915)
return vma;
}
-static int hwsp_alloc(struct i915_timeline *timeline)
+static struct i915_vma *
+hwsp_alloc(struct i915_timeline *timeline, unsigned int *cacheline)
{
- struct i915_vma *vma;
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_gt_timelines *gt = >gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
- vma = __hwsp_alloc(timeline->i915);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
- timeline->hwsp_ggtt = vma;
- timeline->hwsp_offset = 0;
+ spin_lock(>hwsp_lock);
- return 0;
+ /* hwsp_free_list only contains HWSP that have available cachelines */
+ hwsp = list_first_entry_or_null(>hwsp_free_list,
+ typeof(*hwsp), free_link);
+ if (!hwsp) {
+ struct i915_vma *vma;
+
+ spin_unlock(>hwsp_lock);
+
+ hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
+ if (!hwsp)
+ return ERR_PTR(-ENOMEM);
+
+ vma = __hwsp_alloc(i915);
+ if (IS_ERR(vma)) {
+ kfree(hwsp);
+ return vma;
+ }
+
+ vma->private = hwsp;
+ hwsp->vma = vma;
+ hwsp->free_bitmap = ~0ull;
+
+ spin_lock(>hwsp_lock);
+ list_add(>free_link, >hwsp_free_list);
+ }
+
+ GEM_BUG_ON(!hwsp->free_bitmap);
+ *cacheline = __ffs64(hwsp->free_bitmap);
+ hwsp->free_bitmap &= ~BIT_ULL(*cacheline);
+ if (!hwsp->free_bitmap)
+ list_del(>free_link);
+
+ spin_unlock(>hwsp_lock);
+
+ GEM_BUG_ON(hwsp->vma->private != hwsp);
+ return hwsp->vma;
+}
+
+static void hwsp_free(struct i915_timeline *timeline)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+
+ hwsp = i915_timeline_hwsp(timeline);
+ if (!hwsp) /* leave global HWSP alone! */
+ return;
+
+ spin_lock(>hwsp_lock);
[Intel-gfx] [CI 1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global timeline.
v2: s/i915_request_hwsp/hwsp_seqno/ to emphasis that this is the current
HW value and that we are accessing it via i915_request merely as a
convenience.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_request.c | 16 ++
drivers/gpu/drm/i915/i915_request.h | 45 -
drivers/gpu/drm/i915/intel_lrc.c| 9 --
3 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f4241a17e2ad..a076fd0b7ba6 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -182,10 +182,11 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
- GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
__func__, engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ hwsp_seqno(rq),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!i915_request_completed(rq));
@@ -244,10 +245,11 @@ static void i915_request_retire(struct i915_request
*request)
{
struct i915_gem_active *active, *next;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
request->engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ hwsp_seqno(request),
intel_engine_get_seqno(request->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -307,10 +309,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
rq->engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ hwsp_seqno(rq),
intel_engine_get_seqno(rq->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -355,10 +358,11 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
- GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
engine->timeline.seqno + 1,
+ hwsp_seqno(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -405,10 +409,11 @@ void __i915_request_unsubmit(struct i915_request *request)
{
struct intel_engine_cs *engine = request->engine;
- GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ hwsp_seqno(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -616,6 +621,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
+ rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index c0f084ca4f29..ade010fe6e26 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -130,6 +130,13 @@ struct i915_request {
struct i915_sched_node sched;
struct i915_dependency dep;
+ /*
+* A convenience pointer to the current breadcrumb value stored in
+* the HW status page (or our timeline's local equivalent). The full
+* path would be rq->hw_context->ring->timeline->hwsp_seqno.
+*/
+ const u32 *hwsp_seqno;
+
/**
* GEM sequence number associated with this request on the
* global execution timeline. It is zero when the request is not
@@ -285,11 +292,6 @@
[Intel-gfx] [PULL] drm-intel-next
Hi Dave, This pull includes the tag as described below and the GVT stuff, which " includes Coffeelake support for GVT, making kvmgt as self load module to have better dependence with vfio/mdev, with some const treatment and kernel type change. " Also please notice that we have a drm color management LUT validation helper coming on this bucket. Here goes drm-intel-next-2019-01-24: - Track all runtime-PM wakerefs and other rpm improvements (Chris) - Fix ILK-IVB primary plane enable delays (Juha-Pekka) - Differentiate between gtt->mutex and ppgtt->mutex (Chris) - Prevent concurrent GGTT update and use on Braswell (Chris) - Fix CNL macros for DDI vswing (Aditya) - Fix static code analysis warning (RK) - Only dump GPU state on set-wedged if interesting (Chris) - Port F detection improvements (Imre) - userptr mutex lock fixes (Chris) - Fix on MST allocation by propagating error value at compute_config (Lyude) - Serialise concurrent calls to set_wedge (Chris) - Unify reset functionality into i915_reset.c (Chris) - Switch to kernel fixed size types (Jani) - Limit the for_each_set_bit to the valid range (Chris) - Fix wakeref cooie handling (Tvrtko) - IRQs handling improvements (Chris) - Selftests improvements (Chris) - Remove superfluous PANEL_POWER_OFF macro (Jani) - Global seqno fix (Chris) - DSI fixes (Hans) - Refactor out intel_context_init() (Chris) - Show all active engines on hangcheck (Chris) - PSR2 fixes and improvements (Jose) - Do a posting read after irq install on Ice Lake (Daniele) - Add few more device IDs for Ice Lake (Rodrigo) - Mark up priority boost on preemption (Chris) - Add color management LUT validation helper (Matt) - Split out intel_crt_present to platform specific setup (Jani) - LVDS and TV clean up and improvements (Jani) - Simplify CRT VBT check for per-VLV/DDI (Jani) - De-inline intel_context_init() (Chris) - Backlight fixes (Maarten) - Enable fastset for non-boot modesets (Maarten) - Make HW readout mark CRTC scaler as in use (Maarten) Thanks, Rodrigo. The following changes since commit f164a94c2c87752caeb1a3cbe068c440e7f7921f: Merge tag 'drm-misc-next-2019-01-16' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-01-18 09:31:28 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-01-24 for you to fetch changes up to 85baa5dbf79163026dcb78f742294c522e176432: drm/i915: Update DRIVER_DATE to 20190124 (2019-01-24 15:00:59 -0800) - Track all runtime-PM wakerefs and other rpm improvements (Chris) - Fix ILK-IVB primary plane enable delays (Juha-Pekka) - Differentiate between gtt->mutex and ppgtt->mutex (Chris) - Prevent concurrent GGTT update and use on Braswell (Chris) - Fix CNL macros for DDI vswing (Aditya) - Fix static code analysis warning (RK) - Only dump GPU state on set-wedged if interesting (Chris) - Port F detection improvements (Imre) - userptr mutex lock fixes (Chris) - Fix on MST allocation by propagating error value at compute_config (Lyude) - Serialise concurrent calls to set_wedge (Chris) - Unify reset functionality into i915_reset.c (Chris) - Switch to kernel fixed size types (Jani) - Limit the for_each_set_bit to the valid range (Chris) - Fix wakeref cooie handling (Tvrtko) - IRQs handling improvements (Chris) - Selftests improvements (Chris) - Remove superfluous PANEL_POWER_OFF macro (Jani) - Global seqno fix (Chris) - DSI fixes (Hans) - Refactor out intel_context_init() (Chris) - Show all active engines on hangcheck (Chris) - PSR2 fixes and improvements (Jose) - Do a posting read after irq install on Ice Lake (Daniele) - Add few more device IDs for Ice Lake (Rodrigo) - Mark up priority boost on preemption (Chris) - Add color management LUT validation helper (Matt) - Split out intel_crt_present to platform specific setup (Jani) - LVDS and TV clean up and improvements (Jani) - Simplify CRT VBT check for per-VLV/DDI (Jani) - De-inline intel_context_init() (Chris) - Backlight fixes (Maarten) - Enable fastset for non-boot modesets (Maarten) - Make HW readout mark CRTC scaler as in use (Maarten) Aditya Swarup (1): drm/i915/cnl: Fix CNL macros for Voltage Swing programming Chris Wilson (46): drm/i915: Track all held rpm wakerefs drm/i915: Markup paired operations on wakerefs drm/i915: Track GT wakeref drm/i915: Track the rpm wakerefs for error handling drm/i915: Mark up sysfs with rpm wakeref tracking drm/i915: Mark up debugfs with rpm wakeref tracking drm/i915/perf: Track the rpm wakeref drm/i915/pmu: Track rpm wakeref drm/i915/guc: Track the rpm wakeref drm/i915/gem: Track the rpm wakerefs drm/i915/fb: Track rpm wakerefs drm/i915/hotplug: Track temporary rpm wakeref drm/i915/panel: Track temporary rpm wakeref drm/i915/selftests: Mark up rpm wakerefs
Re: [Intel-gfx] [PATCH v2] drm/i915/icl: Add TypeC ports only if VBT is present
On Mon, 2019-01-28 at 13:42 +0200, Imre Deak wrote: > We can't safely probe Type C ports, whether they are a legacy or a > USB/Thunderbolt DP Alternate Type C port. This would require > performing > the TypeC connect sequence - as described by the specification - but > that may have unwanted side-effects. These side-effects include at > least > - without completeness - timeouts during AUX power well enabling and > subsequent PLL enabling errors. > > To safely identify these ports we really need VBT, which has the > proper > flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt). > Based on the above disable Type C ports if we can't load VBT for some > reason. > > v2: > - Notice that we disable TypeC ports completely and simplify > accordingly > (Jose). > - Add code comment explaining why we disabled the ports. (Jani) Reviewed-by: José Roberto de Souza > > Cc: Jani Nikula > Cc: Paulo Zanoni > Cc: Jose Roberto de Souza > Cc: Ville Syrjälä > Cc: Rodrigo Vivi > Signed-off-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_bios.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_bios.c > b/drivers/gpu/drm/i915/intel_bios.c > index 561a4f9f044c..b508d8a735e0 100644 > --- a/drivers/gpu/drm/i915/intel_bios.c > +++ b/drivers/gpu/drm/i915/intel_bios.c > @@ -1663,6 +1663,13 @@ init_vbt_missing_defaults(struct > drm_i915_private *dev_priv) > struct ddi_vbt_port_info *info = > _priv->vbt.ddi_port_info[port]; > > + /* > + * VBT has the TypeC mode (native,TBT/USB) and we don't > want > + * to detect it. > + */ > + if (intel_port_is_tc(dev_priv, port)) > + continue; > + > info->supports_dvi = (port != PORT_A && port != > PORT_E); > info->supports_hdmi = info->supports_dvi; > info->supports_dp = (port != PORT_E); signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
== Series Details == Series: series starting with [CI,1/6] drm/i915: Introduce concept of per-timeline (context) HWSP URL : https://patchwork.freedesktop.org/series/55850/ State : failure == Summary == Applying: drm/i915: Introduce concept of per-timeline (context) HWSP Applying: drm/i915: Enlarge vma->pin_count Applying: drm/i915: Allocate a status page for each timeline error: sha1 information is lacking or useless (drivers/gpu/drm/i915/intel_lrc.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 drm/i915: Allocate a status page for each timeline When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/6] drm/i915: Share per-timeline HWSP using a slab suballocator
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh allocation as a slab of 64 entries, we can keep it
around for the next 64 allocation attempts until we need to refresh the
slab cache.
John Harrison noted the issue of fragmentation leading to the same worst
case performance of one page per timeline as before, which can be
mitigated by adopting a freelist.
v2: Keep all partially allocated HWSP on a freelist
This is still without migration, so it is possible for the system to end
up with each timeline in its own page, but we ensure that no new
allocation would needless allocate a fresh page!
v3: Throw a selftest at the allocator to try and catch invalid cacheline
reuse.
Signed-off-by: Chris Wilson
Cc: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_timeline.c | 124 ---
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/selftests/i915_random.c | 33 +++-
drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
.../gpu/drm/i915/selftests/i915_timeline.c| 143 ++
6 files changed, 280 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8a181b455197..6a051381f535 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1978,6 +1978,10 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
struct list_head list;
+
+ /* Pack multiple timelines' seqnos into the same page */
+ spinlock_t hwsp_lock;
+ struct list_head hwsp_free_list;
} timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 8d5792311a8f..add8fc33cf6e 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,6 +9,18 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
+struct i915_timeline_hwsp {
+ struct i915_vma *vma;
+ struct list_head free_link;
+ u64 free_bitmap;
+};
+
+static inline struct i915_timeline_hwsp *
+i915_timeline_hwsp(const struct i915_timeline *tl)
+{
+ return tl->hwsp_ggtt->private;
+}
+
static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
{
struct drm_i915_gem_object *obj;
@@ -27,28 +39,89 @@ static struct i915_vma *__hwsp_alloc(struct
drm_i915_private *i915)
return vma;
}
-static int hwsp_alloc(struct i915_timeline *timeline)
+static struct i915_vma *
+hwsp_alloc(struct i915_timeline *timeline, unsigned int *cacheline)
{
- struct i915_vma *vma;
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_gt_timelines *gt = >gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
- vma = __hwsp_alloc(timeline->i915);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
- timeline->hwsp_ggtt = vma;
- timeline->hwsp_offset = 0;
+ spin_lock(>hwsp_lock);
- return 0;
+ /* hwsp_free_list only contains HWSP that have available cachelines */
+ hwsp = list_first_entry_or_null(>hwsp_free_list,
+ typeof(*hwsp), free_link);
+ if (!hwsp) {
+ struct i915_vma *vma;
+
+ spin_unlock(>hwsp_lock);
+
+ hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
+ if (!hwsp)
+ return ERR_PTR(-ENOMEM);
+
+ vma = __hwsp_alloc(i915);
+ if (IS_ERR(vma)) {
+ kfree(hwsp);
+ return vma;
+ }
+
+ vma->private = hwsp;
+ hwsp->vma = vma;
+ hwsp->free_bitmap = ~0ull;
+
+ spin_lock(>hwsp_lock);
+ list_add(>free_link, >hwsp_free_list);
+ }
+
+ GEM_BUG_ON(!hwsp->free_bitmap);
+ *cacheline = __ffs64(hwsp->free_bitmap);
+ hwsp->free_bitmap &= ~BIT_ULL(*cacheline);
+ if (!hwsp->free_bitmap)
+ list_del(>free_link);
+
+ spin_unlock(>hwsp_lock);
+
+ GEM_BUG_ON(hwsp->vma->private != hwsp);
+ return hwsp->vma;
+}
+
+static void hwsp_free(struct i915_timeline *timeline)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+
+ hwsp = i915_timeline_hwsp(timeline);
+ if (!hwsp) /* leave global HWSP alone! */
+ return;
+
+ spin_lock(>hwsp_lock);
[Intel-gfx] [CI 1/6] drm/i915: Introduce concept of per-timeline (context) HWSP
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global timeline.
v2: s/i915_request_hwsp/hwsp_seqno/ to emphasis that this is the current
HW value and that we are accessing it via i915_request merely as a
convenience.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_request.c | 16 ++
drivers/gpu/drm/i915/i915_request.h | 45 -
drivers/gpu/drm/i915/intel_lrc.c| 9 --
3 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f4241a17e2ad..a076fd0b7ba6 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -182,10 +182,11 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
- GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
__func__, engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ hwsp_seqno(rq),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!i915_request_completed(rq));
@@ -244,10 +245,11 @@ static void i915_request_retire(struct i915_request
*request)
{
struct i915_gem_active *active, *next;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
request->engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ hwsp_seqno(request),
intel_engine_get_seqno(request->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -307,10 +309,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
rq->engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ hwsp_seqno(rq),
intel_engine_get_seqno(rq->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -355,10 +358,11 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
- GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
engine->timeline.seqno + 1,
+ hwsp_seqno(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -405,10 +409,11 @@ void __i915_request_unsubmit(struct i915_request *request)
{
struct intel_engine_cs *engine = request->engine;
- GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ hwsp_seqno(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -616,6 +621,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
+ rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index c0f084ca4f29..ade010fe6e26 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -130,6 +130,13 @@ struct i915_request {
struct i915_sched_node sched;
struct i915_dependency dep;
+ /*
+* A convenience pointer to the current breadcrumb value stored in
+* the HW status page (or our timeline's local equivalent). The full
+* path would be rq->hw_context->ring->timeline->hwsp_seqno.
+*/
+ const u32 *hwsp_seqno;
+
/**
* GEM sequence number associated with this request on the
* global execution timeline. It is zero when the request is not
@@ -285,11 +292,6 @@
[Intel-gfx] [CI 2/6] drm/i915: Enlarge vma->pin_count
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum permissible pin_count small allows us to quickly catch a
potential leak. However, as we want to split a 4096B page into 64
different cachelines and pin each cacheline for use by a different
timeline, we will exceed the current maximum permissible vma->pin_count
and so time has come to enlarge it.
Whilst we are here, try to pull together the similar bits:
Address/layout specification:
- bias, mappable, zone_4g: address limit specifiers
- fixed: address override, limits still apply though
- high: not strictly an address limit, but an address direction to search
Search controls:
- nonblock, nonfault, noevict
v2: Rewrite the guideline comment on bit consumption.
Signed-off-by: Chris Wilson
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 -
drivers/gpu/drm/i915/i915_vma.h | 45 +++--
2 files changed, 42 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index bd679c8c56dd..03ade71b8d9a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -642,19 +642,19 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
/* Flags used by pin/bind */
#define PIN_NONBLOCK BIT_ULL(0)
-#define PIN_MAPPABLE BIT_ULL(1)
-#define PIN_ZONE_4GBIT_ULL(2)
-#define PIN_NONFAULT BIT_ULL(3)
-#define PIN_NOEVICTBIT_ULL(4)
-
-#define PIN_MBZBIT_ULL(5) /* I915_VMA_PIN_OVERFLOW */
-#define PIN_GLOBAL BIT_ULL(6) /* I915_VMA_GLOBAL_BIND */
-#define PIN_USER BIT_ULL(7) /* I915_VMA_LOCAL_BIND */
-#define PIN_UPDATE BIT_ULL(8)
-
-#define PIN_HIGH BIT_ULL(9)
-#define PIN_OFFSET_BIASBIT_ULL(10)
-#define PIN_OFFSET_FIXED BIT_ULL(11)
+#define PIN_NONFAULT BIT_ULL(1)
+#define PIN_NOEVICTBIT_ULL(2)
+#define PIN_MAPPABLE BIT_ULL(3)
+#define PIN_ZONE_4GBIT_ULL(4)
+#define PIN_HIGH BIT_ULL(5)
+#define PIN_OFFSET_BIASBIT_ULL(6)
+#define PIN_OFFSET_FIXED BIT_ULL(7)
+
+#define PIN_MBZBIT_ULL(8) /* I915_VMA_PIN_OVERFLOW */
+#define PIN_GLOBAL BIT_ULL(9) /* I915_VMA_GLOBAL_BIND */
+#define PIN_USER BIT_ULL(10) /* I915_VMA_LOCAL_BIND */
+#define PIN_UPDATE BIT_ULL(11)
+
#define PIN_OFFSET_MASK(-I915_GTT_PAGE_SIZE)
#endif
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 7252abc73d3e..5793abe509a2 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -71,29 +71,42 @@ struct i915_vma {
unsigned int open_count;
unsigned long flags;
/**
-* How many users have pinned this object in GTT space. The following
-* users can each hold at most one reference: pwrite/pread, execbuffer
-* (objects are not allowed multiple times for the same batchbuffer),
-* and the framebuffer code. When switching/pageflipping, the
-* framebuffer code has at most two buffers pinned per crtc.
+* How many users have pinned this object in GTT space.
*
-* In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
-* bits with absolutely no headroom. So use 4 bits.
+* This is a tightly bound, fairly small number of users, so we
+* stuff inside the flags field so that we can both check for overflow
+* and detect a no-op i915_vma_pin() in a single check, while also
+* pinning the vma.
+*
+* The worst case display setup would have the same vma pinned for
+* use on each plane on each crtc, while also building the next atomic
+* state and holding a pin for the length of the cleanup queue. In the
+* future, the flip queue may be increased from 1.
+* Estimated worst case: 3 [qlen] * 4 [max crtcs] * 7 [max planes] = 84
+*
+* For GEM, the number of concurrent users for pwrite/pread is
+* unbounded. For execbuffer, it is currently one but will in future
+* be extended to allow multiple clients to pin vma concurrently.
+*
+* We also use suballocated pages, with each suballocation claiming
+* its own pin on the shared vma. At present, this is limited to
+* exclusive cachelines of a single page, so a maximum of 64 possible
+* users.
*/
-#define I915_VMA_PIN_MASK 0xf
-#define I915_VMA_PIN_OVERFLOW BIT(5)
+#define I915_VMA_PIN_MASK 0xff
+#define I915_VMA_PIN_OVERFLOW BIT(8)
/**
[Intel-gfx] [CI 3/6] drm/i915: Allocate a status page for each timeline
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP for the solitary ringbuffer
timeline, so that we do not have to emit (using per-gen specialised
vfuncs) the breadcrumb into the distinct timeline HWSP and instead can
keep on using the common MI_STORE_DWORD_INDEX. However, to maintain the
sleight-of-hand for the global/per-context seqno switchover, we will
store both temporarily (and so use a custom offset for the shared timeline
HWSP until the switch over).
v3: Keep things simple and allocate a page for each timeline, page
sharing comes next.
v4: I was caught repeating the same MI_STORE_DWORD_IMM over and over
again in selftests.
v5: And caught red handed copying create timeline + check.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_timeline.c | 121 ++-
drivers/gpu/drm/i915/i915_timeline.h | 21 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 76 ++--
drivers/gpu/drm/i915/intel_lrc.c | 22 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 +-
.../drm/i915/selftests/i915_live_selftests.h | 1 +
.../drm/i915/selftests/i915_mock_selftests.h | 2 +-
.../gpu/drm/i915/selftests/i915_timeline.c| 326 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 14 +-
10 files changed, 543 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 84550f17d3df..8d5792311a8f 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,28 +9,78 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
-void i915_timeline_init(struct drm_i915_private *i915,
- struct i915_timeline *timeline,
- const char *name)
+static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+
+ obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(obj))
+ return ERR_CAST(obj);
+
+ i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
+
+ vma = i915_vma_instance(obj, >ggtt.vm, NULL);
+ if (IS_ERR(vma))
+ i915_gem_object_put(obj);
+
+ return vma;
+}
+
+static int hwsp_alloc(struct i915_timeline *timeline)
+{
+ struct i915_vma *vma;
+
+ vma = __hwsp_alloc(timeline->i915);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ timeline->hwsp_ggtt = vma;
+ timeline->hwsp_offset = 0;
+
+ return 0;
+}
+
+int i915_timeline_init(struct drm_i915_private *i915,
+ struct i915_timeline *timeline,
+ const char *name,
+ struct i915_vma *global_hwsp)
{
struct i915_gt_timelines *gt = >gt.timelines;
+ void *vaddr;
+ int err;
/*
* Ideally we want a set of engines on a single leaf as we expect
* to mostly be tracking synchronisation between engines. It is not
* a huge issue if this is not the case, but we may want to mitigate
* any page crossing penalties if they become an issue.
+*
+* Called during early_init before we know how many engines there are.
*/
BUILD_BUG_ON(KSYNCMAP < I915_NUM_ENGINES);
timeline->i915 = i915;
timeline->name = name;
+ timeline->pin_count = 0;
+
+ if (global_hwsp) {
+ timeline->hwsp_ggtt = i915_vma_get(global_hwsp);
+ timeline->hwsp_offset = I915_GEM_HWS_SEQNO_ADDR;
+ } else {
+ err = hwsp_alloc(timeline);
+ if (err)
+ return err;
+ }
- mutex_lock(>mutex);
- list_add(>link, >list);
- mutex_unlock(>mutex);
+ vaddr = i915_gem_object_pin_map(timeline->hwsp_ggtt->obj, I915_MAP_WB);
+ if (IS_ERR(vaddr)) {
+ i915_vma_put(timeline->hwsp_ggtt);
+ return PTR_ERR(vaddr);
+ }
- /* Called during early_init before we know how many engines there are */
+ timeline->hwsp_seqno =
+ memset(vaddr + timeline->hwsp_offset, 0, CACHELINE_BYTES);
timeline->fence_context = dma_fence_context_alloc(1);
@@ -40,6 +90,12 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(>requests);
i915_syncmap_init(>sync);
+
+ mutex_lock(>mutex);
+ list_add(>link, >list);
+ mutex_unlock(>mutex);
+
+ return 0;
}
void i915_timelines_init(struct drm_i915_private *i915)
@@ -85,6 +141,7 @@ void i915_timeline_fini(struct i915_timeline *timeline)
{
struct
[Intel-gfx] [CI 6/6] drm/i915: Track active timelines
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_reset.c| 2 +-
drivers/gpu/drm/i915/i915_timeline.c | 39 ++--
4 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6a051381f535..d072f3369ee1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1977,7 +1977,7 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
- struct list_head list;
+ struct list_head active_list;
/* Pack multiple timelines' seqnos into the same page */
spinlock_t hwsp_lock;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1bd724d663d9..05627000b77d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3248,7 +3248,7 @@ wait_for_timelines(struct drm_i915_private *i915,
return timeout;
mutex_lock(>mutex);
- list_for_each_entry(tl, >list, link) {
+ list_for_each_entry(tl, >active_list, link) {
struct i915_request *rq;
rq = i915_gem_active_get_unlocked(>last_request);
@@ -3276,7 +3276,7 @@ wait_for_timelines(struct drm_i915_private *i915,
/* restart after reacquiring the lock */
mutex_lock(>mutex);
- tl = list_entry(>list, typeof(*tl), link);
+ tl = list_entry(>active_list, typeof(*tl), link);
}
mutex_unlock(>mutex);
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index bd82f9b1043f..acf3c777e49d 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -856,7 +856,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* No more can be submitted until we reset the wedged bit.
*/
mutex_lock(>gt.timelines.mutex);
- list_for_each_entry(tl, >gt.timelines.list, link) {
+ list_for_each_entry(tl, >gt.timelines.active_list, link) {
struct i915_request *rq;
long timeout;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index e4c11414a824..79838d89bdb9 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -120,7 +120,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
const char *name,
struct i915_vma *hwsp)
{
- struct i915_gt_timelines *gt = >gt.timelines;
void *vaddr;
/*
@@ -168,10 +167,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
i915_syncmap_init(>sync);
- mutex_lock(>mutex);
- list_add(>link, >list);
- mutex_unlock(>mutex);
-
return 0;
}
@@ -180,7 +175,7 @@ void i915_timelines_init(struct drm_i915_private *i915)
struct i915_gt_timelines *gt = >gt.timelines;
mutex_init(>mutex);
- INIT_LIST_HEAD(>list);
+ INIT_LIST_HEAD(>active_list);
spin_lock_init(>hwsp_lock);
INIT_LIST_HEAD(>hwsp_free_list);
@@ -189,6 +184,24 @@ void i915_timelines_init(struct drm_i915_private *i915)
i915_gem_shrinker_taints_mutex(i915, >mutex);
}
+static void timeline_add_to_active(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+
+ mutex_lock(>mutex);
+ list_add(>link, >active_list);
+ mutex_unlock(>mutex);
+}
+
+static void timeline_remove_from_active(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+
+ mutex_lock(>mutex);
+ list_del(>link);
+ mutex_unlock(>mutex);
+}
+
/**
* i915_timelines_park - called when the driver idles
* @i915: the drm_i915_private device
@@ -205,7 +218,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
struct i915_timeline *timeline;
mutex_lock(>mutex);
- list_for_each_entry(timeline, >list, link) {
+ list_for_each_entry(timeline, >active_list, link) {
/*
* All known fences are completed so we can scrap
* the current sync point tracking and start afresh,
@@ -219,15 +232,9 @@ void i915_timelines_park(struct drm_i915_private *i915)
void i915_timeline_fini(struct i915_timeline *timeline)
{
- struct i915_gt_timelines *gt = >i915->gt.timelines;
-
GEM_BUG_ON(timeline->pin_count);
[Intel-gfx] [CI 5/6] drm/i915: Track the context's seqno in its own timeline HWSP
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to unwind the per-context timeline, and so requests are
always consistent with the timeline breadcrumb, greatly simplifying the
completion checks as we no longer need to be concerned about the
global_seqno changing mid check.
One complication though is that we have to be wary that the request may
outlive the HWSP and so avoid touching the potentially danging pointer
after we have retired the fence. We also have to guard our access of the
HWSP with RCU, the release of the obj->mm.pages should already be RCU-safe.
At this point, we are emitting both per-context and global seqno and
still using the single per-engine execution timeline for resolving
interrupts.
v2: s/fake_complete/mark_complete/
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 3 +-
drivers/gpu/drm/i915/i915_request.h | 30 +++
drivers/gpu/drm/i915/i915_reset.c | 1 +
drivers/gpu/drm/i915/i915_timeline.c | 4 +
drivers/gpu/drm/i915/intel_engine_cs.c| 15 +++-
drivers/gpu/drm/i915/intel_lrc.c | 31 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 87 +++
.../gpu/drm/i915/selftests/i915_timeline.c| 7 +-
drivers/gpu/drm/i915/selftests/mock_engine.c | 19 +++-
10 files changed, 139 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d68f3fdd8a8e..1bd724d663d9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2892,7 +2892,7 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
*/
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry(request, >timeline.requests, link) {
- if (__i915_request_completed(request, request->global_seqno))
+ if (i915_request_completed(request))
continue;
active = request;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index a076fd0b7ba6..4d58770e6a8c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -199,6 +199,7 @@ static void __retire_engine_request(struct intel_engine_cs
*engine,
spin_unlock(>timeline.lock);
spin_lock(>lock);
+ i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(>fence);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
@@ -621,7 +622,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
- rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
+ rq->hwsp_seqno = rq->timeline->hwsp_seqno;
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index ade010fe6e26..96c586d6ff4d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -289,6 +289,7 @@ long i915_request_wait(struct i915_request *rq,
static inline bool i915_request_signaled(const struct i915_request *rq)
{
+ /* The request may live longer than its HWSP, so check flags first! */
return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags);
}
@@ -340,32 +341,23 @@ static inline u32 hwsp_seqno(const struct i915_request
*rq)
*/
static inline bool i915_request_started(const struct i915_request *rq)
{
- u32 seqno;
-
- seqno = i915_request_global_seqno(rq);
- if (!seqno) /* not yet submitted to HW */
- return false;
+ if (i915_request_signaled(rq))
+ return true;
- return i915_seqno_passed(hwsp_seqno(rq), seqno - 1);
-}
-
-static inline bool
-__i915_request_completed(const struct i915_request *rq, u32 seqno)
-{
- GEM_BUG_ON(!seqno);
- return i915_seqno_passed(hwsp_seqno(rq), seqno) &&
- seqno == i915_request_global_seqno(rq);
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
}
static inline bool i915_request_completed(const struct i915_request *rq)
{
- u32 seqno;
+ if (i915_request_signaled(rq))
+ return true;
- seqno = i915_request_global_seqno(rq);
- if (!seqno)
- return false;
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno);
+}
- return __i915_request_completed(rq, seqno);
+static inline void i915_request_mark_complete(struct i915_request *rq)
+{
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
URL : https://patchwork.freedesktop.org/series/55733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494 -> Patchwork_12058
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55733/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12058:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s3:
- {fi-icl-y}: NOTRUN -> DMESG-WARN
* igt@i915_selftest@live_contexts:
- {fi-icl-y}: NOTRUN -> DMESG-FAIL
* igt@kms_flip@basic-flip-vs-modeset:
- {fi-icl-y}: NOTRUN -> {SKIP} +79
Known issues
Here are the changes found in Patchwork_12058 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: {SKIP} [fdo#109271] / [fdo#109278] -> PASS +2
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: WARN [fdo#109380] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> PASS +33
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Participating hosts (43 -> 41)
--
Additional (1): fi-skl-6700hq
Missing(3): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5494 -> Patchwork_12058
CI_DRM_5494: 543c074ff6a401b2bca5333234a9c13c4b0a5152 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4795: 031715e369cf01aecbe293910211e80e51995ffb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12058: cfbebb24056d36048d2eef0c934c85ef4a4695c0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cfbebb24056d drm/i915/icl: Add TypeC ports only if VBT is present
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12058/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
== Series Details ==
Series: drm/i915/icl: Add TypeC ports only if VBT is present (rev2)
URL : https://patchwork.freedesktop.org/series/55733/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5494 -> Patchwork_12058
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12058 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12058, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55733/revisions/2/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12058:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-icl-y: NOTRUN -> DMESG-WARN
* igt@i915_selftest@live_contexts:
- fi-icl-y: NOTRUN -> DMESG-FAIL
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_flip@basic-flip-vs-modeset:
- fi-icl-y: NOTRUN -> {SKIP} +79
Known issues
Here are the changes found in Patchwork_12058 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-a:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
Possible fixes
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: {SKIP} [fdo#109271] / [fdo#109278] -> PASS +2
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: WARN [fdo#109380] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> PASS +33
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Participating hosts (43 -> 41)
--
Additional (1): fi-skl-6700hq
Missing(3): fi-kbl-soraka fi-ilk-m540 fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5494 -> Patchwork_12058
CI_DRM_5494: 543c074ff6a401b2bca5333234a9c13c4b0a5152 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4795: 031715e369cf01aecbe293910211e80e51995ffb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12058: cfbebb24056d36048d2eef0c934c85ef4a4695c0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
cfbebb24056d drm/i915/icl: Add TypeC ports only if VBT is present
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12058/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/28] drm/i915: Replace global breadcrumbs with per-context interrupt tracking
On 28/01/2019 01:02, Chris Wilson wrote:
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without incurring any cpu overhead.
To handle certain fragility of our hw meant that we could not do a
simple check inside the irq handler (some generations required almost
unbounded delays before we could be sure of seqno coherency) and so
request completion checking required delegation.
Before commit 688e6c725816, the solution was simple. Every client
waiting on a request would be woken on every interrupt and each would do
a heavyweight check to see if their request was complete. Commit
688e6c725816 introduced an rbtree so that only the earliest waiter on
the global timeline would woken, and would wake the next and so on.
(Along with various complications to handle requests being reordered
along the global timeline, and also a requirement for kthread to provide
a delegate for fence signaling that had no process context.)
The global rbtree depends on knowing the execution timeline (and global
seqno). Without knowing that order, we must instead check all contexts
queued to the HW to see which may have advanced. We trim that list by
only checking queued contexts that are being waited on, but still we
keep a list of all active contexts and their active signalers that we
inspect from inside the irq handler. By moving the waiters onto the fence
signal list, we can combine the client wakeup with the dma_fence
signaling (a dramatic reduction in complexity, but does require the HW
being coherent, the seqno must be visible from the cpu before the
interrupt is raised - we keep a timer backup just in case).
Having previously fixed all the issues with irq-seqno serialisation (by
inserting delays onto the GPU after each request instead of random delays
on the CPU after each interrupt), we can rely on the seqno state to
perfom direct wakeups from the interrupt handler. This allows us to
preserve our single context switch behaviour of the current routine,
with the only downside that we lose the RT priority sorting of wakeups.
In general, direct wakeup latency of multiple clients is about the same
(about 10% better in most cases) with a reduction in total CPU time spent
in the waiter (about 20-50% depending on gen). Average herd behaviour is
improved, but at the cost of not delegating wakeups on task_prio.
v2: Capture fence signaling state for error state and add comments to
warm even the most cold of hearts.
v3: Check if the request is still active before busywaiting
v4: Reduce the amount of pointer misdirection with list_for_each_safe
and using a local i915_request variable inside the loops
v5: Add a missing pluralisation to a purely informative selftest message.
There were some more changes which you implemented after the last round
of review.
I have no further significant complaints.
Reviewed-by: Tvrtko Ursulin
Ideally John re-appears to lend another pair of eyes to the problem.
Given the size of the change it would be good to double check it.
Regards,
Tvrtko
References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request
herd")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 28 +-
drivers/gpu/drm/i915/i915_gem_context.c | 3 +
drivers/gpu/drm/i915/i915_gem_context.h | 2 +
drivers/gpu/drm/i915/i915_gpu_error.c | 83 +-
drivers/gpu/drm/i915/i915_gpu_error.h | 9 +-
drivers/gpu/drm/i915/i915_irq.c | 88 +-
drivers/gpu/drm/i915/i915_request.c | 142 ++-
drivers/gpu/drm/i915/i915_request.h | 72 +-
drivers/gpu/drm/i915/i915_reset.c | 16 +-
drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
drivers/gpu/drm/i915/intel_breadcrumbs.c | 818 +-
drivers/gpu/drm/i915/intel_engine_cs.c| 35 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 94 +-
.../drm/i915/selftests/i915_mock_selftests.h | 1 -
drivers/gpu/drm/i915/selftests/i915_request.c | 425 +
drivers/gpu/drm/i915/selftests/igt_spinner.c | 5 -
.../drm/i915/selftests/intel_breadcrumbs.c| 470 --
.../gpu/drm/i915/selftests/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 54 ++
drivers/gpu/drm/i915/selftests/lib_sw_fence.h | 3 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 17 +-
drivers/gpu/drm/i915/selftests/mock_engine.h | 6 -
23 files changed, 894 insertions(+), 1483 deletions(-)
delete mode 100644 drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f5ac03f06e26..b1ac0f78cb42 100644
---
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on VMA
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on
VMA
URL : https://patchwork.freedesktop.org/series/55829/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5494 -> Patchwork_12057
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55829/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12057 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
Possible fixes
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: FAIL [fdo#103182] -> PASS
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: WARN [fdo#109380] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c:
- fi-kbl-7567u: {SKIP} [fdo#109271] -> PASS +33
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
Participating hosts (43 -> 38)
--
Additional (1): fi-skl-6700hq
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-bsw-cyan
fi-pnv-d510 fi-icl-y
Build changes
-
* Linux: CI_DRM_5494 -> Patchwork_12057
CI_DRM_5494: 543c074ff6a401b2bca5333234a9c13c4b0a5152 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4795: 031715e369cf01aecbe293910211e80e51995ffb @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12057: 58651f8391777c88dccd46da5a609a7e4b636e16 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
58651f839177 drm/i915: Move list of timelines under its own lock
2a803627cd9e drm/i915: Always allocate an object/vma for the HWSP
3c6c66d230a5 drm/i915: Move vma lookup to its own lock
61fb9c56e8df drm/i915: Pull VM lists under the VM mutex.
6c5b3f15bc23 drm/i915: Stop tracking MRU activity on VMA
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12057/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on VMA
== Series Details == Series: series starting with [CI,1/5] drm/i915: Stop tracking MRU activity on VMA URL : https://patchwork.freedesktop.org/series/55829/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Stop tracking MRU activity on VMA Okay! Commit: drm/i915: Pull VM lists under the VM mutex. Okay! Commit: drm/i915: Move vma lookup to its own lock Okay! Commit: drm/i915: Always allocate an object/vma for the HWSP Okay! Commit: drm/i915: Move list of timelines under its own lock -drivers/gpu/drm/i915/selftests/../i915_drv.h:3541:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3544:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
On Mon, Jan 28, 2019 at 09:30:35AM +, Kahola, Mika wrote:
> The patch look ok to me.
>
> On Fri, 2019-01-11 at 19:49 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
> > which misprograms the hardware badly when encountering a suitably
> > high resolution display. The programmed pipe timings are somewhat
> > bonkers and the DPLL is totally misprogrammed (P divider == 0).
> > That will result in atomic commit timeouts as apparently the pipe
> > is sufficiently stuck to not signal vblank interrupts.
> >
> > IIRC something like this was also observed on some other SNB
> > machine years ago (might have been a Dell XPS 8300) but a BIOS
> > update cured it. Sadly looks like this was never fixed for the
> > ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still
> > broken.
> >
> > The quickest way to deal with this seems to be to shut down
> > the pipe+ports+DPLL. Unfortunately doing this during the
> > normal sanitization phase isn't quite soon enough as we
> > already spew several WARNs about the bogus hardware state.
> > But it's better than hanging the boot for a few dozen seconds.
> > Since this is limited to a few old machines it doesn't seem
> > entirely worthwile to try and rework the readout+sanitization
> > code to handle it more gracefully.
> >
> > v2: Fix potential NULL deref (kbuild test robot)
> > Constify has_bogus_dpll_config()
> >
> > Cc: sta...@vger.kernel.org # v4.20+
> > Cc: Daniel Kamil Kozar
> > Reported-by: Daniel Kamil Kozar
> > Tested-by: Daniel Kamil Kozar
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245
> > Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup
> > with external display")
>
> Reviewed-by: Mika Kahola
Thanks. Pushed to dinq.
>
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 50
> >
> > 1 file changed, 44 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 5dc0de89c49e..6cd6048b4731 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15438,16 +15438,45 @@ static void intel_sanitize_crtc(struct
> > intel_crtc *crtc,
> > }
> > }
> >
> > +static bool has_bogus_dpll_config(const struct intel_crtc_state
> > *crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc_state-
> > >base.crtc->dev);
> > +
> > + /*
> > +* Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram
> > +* the hardware when a high res displays plugged in. DPLL P
> > +* divider is zero, and the pipe timings are bonkers. We'll
> > +* try to disable everything in that case.
> > +*
> > +* FIXME would be nice to be able to sanitize this state
> > +* without several WARNs, but for now let's take the easy
> > +* road.
> > +*/
> > + return IS_GEN(dev_priv, 6) &&
> > + crtc_state->base.active &&
> > + crtc_state->shared_dpll &&
> > + crtc_state->port_clock == 0;
> > +}
> > +
> > static void intel_sanitize_encoder(struct intel_encoder *encoder)
> > {
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > struct intel_connector *connector;
> > + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> > + struct intel_crtc_state *crtc_state = crtc ?
> > + to_intel_crtc_state(crtc->base.state) : NULL;
> >
> > /* We need to check both for a crtc link (meaning that the
> > * encoder is active and trying to read from a pipe) and the
> > * pipe itself being active. */
> > - bool has_active_crtc = encoder->base.crtc &&
> > - to_intel_crtc(encoder->base.crtc)->active;
> > + bool has_active_crtc = crtc_state &&
> > + crtc_state->base.active;
> > +
> > + if (crtc_state && has_bogus_dpll_config(crtc_state)) {
> > + DRM_DEBUG_KMS("BIOS has misprogrammed the hardware.
> > Disabling pipe %c\n",
> > + pipe_name(crtc->pipe));
> > + has_active_crtc = false;
> > + }
> >
> > connector = intel_encoder_find_connector(encoder);
> > if (connector && !has_active_crtc) {
> > @@ -15458,16 +15487,25 @@ static void intel_sanitize_encoder(struct
> > intel_encoder *encoder)
> > /* Connector is active, but has no active pipe. This is
> > * fallout from our resume register restoring. Disable
> > * the encoder manually again. */
> > - if (encoder->base.crtc) {
> > - struct drm_crtc_state *crtc_state = encoder-
> > >base.crtc->state;
> > + if (crtc_state) {
> > + struct drm_encoder *best_encoder;
> >
> > DRM_DEBUG_KMS("[ENCODER:%d:%s] manually
> > disabled\n",
> > encoder->base.base.id,
> >
Re: [Intel-gfx] [PATCH 2/2] drm/i915/tv: Use the scanline counter for timestamps on i965gm TV output
On Fri, Jan 25, 2019 at 10:17:04PM +0200, Imre Deak wrote:
> On Fri, Jan 25, 2019 at 08:19:31PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Just like the frame counter, the pixel counter also reads zero
> > all the time when the TV encoder is used. Fortunately the
> > scanline counter still works sufficiently well so let's use that
> > to correct the vblank timestamps. Otherwise the timestamps may
> > en up out of whack, and since we use them to guesstimate the
> > vblank counter value that may end up incorrect as well.
> >
> > Cc: Imre Deak
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Imre Deak
Thanks. Series pushed to dinq.
>
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 7 +--
> > drivers/gpu/drm/i915/intel_drv.h | 4 +++-
> > drivers/gpu/drm/i915/intel_tv.c | 10 ++
> > 3 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index fe097725c27a..caade521c174 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1014,6 +1014,9 @@ static bool i915_get_crtc_scanoutpos(struct
> > drm_device *dev, unsigned int pipe,
> > int position;
> > int vbl_start, vbl_end, hsync_start, htotal, vtotal;
> > unsigned long irqflags;
> > + bool use_scanline_counter = INTEL_GEN(dev_priv) >= 5 ||
> > + IS_G4X(dev_priv) || IS_GEN(dev_priv, 2) ||
> > + mode->private_flags & I915_MODE_FLAG_USE_SCANLINE_COUNTER;
> >
> > if (WARN_ON(!mode->crtc_clock)) {
> > DRM_DEBUG_DRIVER("trying to get scanoutpos for disabled "
> > @@ -1046,7 +1049,7 @@ static bool i915_get_crtc_scanoutpos(struct
> > drm_device *dev, unsigned int pipe,
> > if (stime)
> > *stime = ktime_get();
> >
> > - if (IS_GEN(dev_priv, 2) || IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >=
> > 5) {
> > + if (use_scanline_counter) {
> > /* No obvious pixelcount register. Only query vertical
> > * scanout position from Display scan line register.
> > */
> > @@ -1106,7 +1109,7 @@ static bool i915_get_crtc_scanoutpos(struct
> > drm_device *dev, unsigned int pipe,
> > else
> > position += vtotal - vbl_end;
> >
> > - if (IS_GEN(dev_priv, 2) || IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >=
> > 5) {
> > + if (use_scanline_counter) {
> > *vpos = position;
> > *hpos = 0;
> > } else {
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 85b913ea6e80..90ba5436370e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -630,9 +630,11 @@ struct intel_crtc_scaler_state {
> > };
> >
> > /* drm_mode->private_flags */
> > -#define I915_MODE_FLAG_INHERITED 1
> > +#define I915_MODE_FLAG_INHERITED (1<<0)
> > /* Flag to get scanline using frame time stamps */
> > #define I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP (1<<1)
> > +/* Flag to use the scanline counter instead of the pixel counter */
> > +#define I915_MODE_FLAG_USE_SCANLINE_COUNTER (1<<2)
> >
> > struct intel_pipe_wm {
> > struct intel_wm_level wm[5];
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 78be08e2971b..751b88dde18e 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -1150,6 +1150,11 @@ intel_tv_get_config(struct intel_encoder *encoder,
> > ypos, mode.vdisplay - ysize - ypos);
> >
> > adjusted_mode->crtc_clock = mode.clock;
> > +
> > + /* pixel counter doesn't work on i965gm TV output */
> > + if (IS_I965GM(dev_priv))
> > + adjusted_mode->private_flags |=
> > + I915_MODE_FLAG_USE_SCANLINE_COUNTER;
> > }
> >
> > static int
> > @@ -1295,6 +1300,11 @@ intel_tv_compute_config(struct intel_encoder
> > *encoder,
> > drm_mode_set_crtcinfo(adjusted_mode, 0);
> > adjusted_mode->name[0] = '\0';
> >
> > + /* pixel counter doesn't work on i965gm TV output */
> > + if (IS_I965GM(dev_priv))
> > + adjusted_mode->private_flags |=
> > + I915_MODE_FLAG_USE_SCANLINE_COUNTER;
> > +
> > return 0;
> > }
> >
> > --
> > 2.19.2
> >
--
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 i-g-t] i915/gem_workarounds: Require GPU resets
Quoting Tvrtko Ursulin (2019-01-28 13:44:47) > > On 28/01/2019 11:12, Chris Wilson wrote: > Agreed on that, but worry who will notice it in review. For the next week of struct_mutex removal (haha), CI will tell us. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets
On 28/01/2019 11:23, Chris Wilson wrote:
Check that we are allowed to reset the GPU prior to execution.
v2: Push the require checking up into a subgroup
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
index 78478ad2c..44e3dce8a 100644
--- a/tests/i915/gem_workarounds.c
+++ b/tests/i915/gem_workarounds.c
@@ -282,9 +282,32 @@ igt_main
}
for (op = ops; op->name; op++) {
- for (m = modes; m->name; m++) {
- igt_subtest_f("%s%s", op->name, m->name)
- check_workarounds(device, op->op, m->flags);
+ igt_subtest_group {
+ igt_hang_t hang = {};
+
+ igt_fixture {
+ switch (op->op) {
+ case GPU_RESET:
+ hang = igt_allow_hang(device, 0, 0);
+ break;
+ default:
+ break;
+ }
+ }
+
+ for (m = modes; m->name; m++)
+ igt_subtest_f("%s%s", op->name, m->name)
+ check_workarounds(device, op->op,
m->flags);
+
+ igt_fixture {
+ switch (op->op) {
+ case GPU_RESET:
+ igt_disallow_hang(device, hang);
+ break;
+ default:
+ break;
+ }
+ }
}
}
}
Why the verbose switch and not just:
it (op->op == GPU_RESET)
hand = igt_allow_hang(...)
?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets
On 28/01/2019 11:12, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-28 11:07:40)
Quoting Tvrtko Ursulin (2019-01-28 11:03:30)
On 27/01/2019 13:06, Chris Wilson wrote:
Check that we are allowed to reset the GPU prior to execution.
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
index 78478ad2c..0e9ab2386 100644
--- a/tests/i915/gem_workarounds.c
+++ b/tests/i915/gem_workarounds.c
@@ -192,7 +192,11 @@ static void check_workarounds(int fd, enum operation op,
unsigned int flags)
switch (op) {
case GPU_RESET:
- igt_force_gpu_reset(fd);
+ {
+ igt_hang_t hang = igt_allow_hang(fd, ctx, 0);
+ igt_force_gpu_reset(fd);
+ igt_disallow_hang(fd, hang);
+ }
break;
case SUSPEND_RESUME:
If it doesn't make sense to add the checks into igt_force_gpu_reset (so
force means force), should we have igt_try_gpu_reset to avoid having to
wrap it everywhere?
Ugh. igt_try_gpu_reset_with_many_many_options_depending_on_test().
I like my requires as high up in the chain as possible, I've been bitten
too many times by hiding them.
The key benefit from doing it higher up, is that we should be doing it
as early as possible and should be more descriptive about why.
Agreed on that, but worry who will notice it in review.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't send MST hotplugs until after resume
On Fri, Jan 25, 2019 at 08:24:35PM -0500, Lyude Paul wrote:
> Turns out we are sending a lot more hotplug events then we need, and
> this is causing some pretty serious issues. Currently, we call
> intel_dp_mst_resume() in i915_drm_resume() well before we have any sort
> of hotplugging setup.
We call hpd_irq_setup() before calling intel_dp_mst_resume(). The only
purpose of that part (lifted out from intel_hpd_init()) is to provide
the short HPD interrupt functionality MST AUX transfers need.
But you are right in that - as a side-effect - we'll also enable generic
hotplug functionality that is independent of the above MST requirement.
Doing that kind of generic hotplug processing before
intel_display_resume() is probably not a good idea, it can interfere at
least with the mode restore in __intel_display_resume().
> This is a pretty big problem, because in practice it will generally
> result in throwing the power domain refcounts out of wack.
>
> For instance: On my T480s, removing a previously connected topology
> before the system finishes resuming causes
> drm_kms_helper_hotplug_event() to be called before HPD is setup again,
> which causes us to do a connector reprobe, which then causes
> intel_dp_detect() to be called on all DP devices -including- the eDP
> display. From there, intel_dp_detect() is run on the eDP display which
> triggers DPCD transactions. Those DPCD transactions then cause us to
> call edp_panel_vdd_on(), which then causes us to grab an additional
> wakeref to the relevant power wells (PORT_DDI_A_IO on this machine).
> From there, this wakeref is never released which then causes the next
> suspend/resume cycle to entirely fail due to the hardware not being
> powered off correctly.
>
> This sucks really badly, and I don't see any decent way to actually fix
> this in intel_dp_detect() easily. Additionally, I don't even think it'd
> be worth the time now since we're not expecting to handle any kind of
> connector reprobing at the point in which we call intel_dp_mst_resume(),
> but we also can't move intel_dp_mst_resume() any higher in the resume
> process since MST topologies need to be resumed before
> intel_display_resume() is called.
>
> However, there's a light at the end of the tunnel! After reading through
> a lot of code dozens of times, it occurred to me that we -never-
> actually need to send hotplug events when calling
> drm_dp_mst_topology_mgr_set_mst() since we send hotplug events in
> drm_dp_destroy_connector_work(). Imagine that!
>
> So, since we only seem to call intel_dp_mst_check_status() to disable
> MST on the encoder in question and then send a hotplug, get rid of this
> and instead just disable MST mode when a hub fails in
> intel_dp_mst_resume(). From there, drm_dp_destroy_connector_work() will
> eventually send the hotplug event.
>
> Signed-off-by: Lyude Paul
> Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
> Cc: Todd Previte
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> Cc: # v3.17+
Not knowing enough about the MST code, but we do need to prevent
generic hotplug processing at this point:
Acked-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_dp.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 681e88405ada..c2399acf177b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -7096,7 +7096,10 @@ void intel_dp_mst_resume(struct drm_i915_private
> *dev_priv)
> continue;
>
> ret = drm_dp_mst_topology_mgr_resume(_dp->mst_mgr);
> - if (ret)
> - intel_dp_check_mst_status(intel_dp);
> + if (ret) {
> + intel_dp->is_mst = false;
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> + false);
> + }
> }
> }
> --
> 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 03/26] drm/irq: Ditch DRIVER_IRQ_SHARED
On 2019/01/25, Daniel Vetter wrote: > On Fri, Jan 25, 2019 at 02:46:55PM +, Emil Velikov wrote: > > On Thu, 24 Jan 2019 at 16:58, Daniel Vetter wrote: > > > > > > This is only used by drm_irq_install(), which is an optional helper. > > > And the right choice is to set it for all pci devices, and not for > > > everything else. > > > > > Can you please add some information (or reference) why it's the right > > choice? > > pci devices can have a shared interrupt line. That's definitely the case > for legacy pci, and I guess carries over to pcie. msi/msi-x interrupts > will give you dedicated interrupts, but it doesn't really hurt to mark > them as shared. > > I guess I could rephrase to state: > > "This is only used by drm_irq_install(), which is an optional helper. > For legacy pci devices this is required (due to interrupt sharing without > msi/msi-x), and just making this the default exactly matches the behaviour > of all existing drivers using the drm_irq_install() helpers. In case that > ever becomes wrong drivers can roll their own irq handling, as many > drivers already do (for other reasons like needing a threaded interrupt > handler, or having an entire pile of different interrupt sources)." > > That better? It's amazing. Thank you very much. -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/icl: Add TypeC ports only if VBT is present
We can't safely probe Type C ports, whether they are a legacy or a USB/Thunderbolt DP Alternate Type C port. This would require performing the TypeC connect sequence - as described by the specification - but that may have unwanted side-effects. These side-effects include at least - without completeness - timeouts during AUX power well enabling and subsequent PLL enabling errors. To safely identify these ports we really need VBT, which has the proper flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt). Based on the above disable Type C ports if we can't load VBT for some reason. v2: - Notice that we disable TypeC ports completely and simplify accordingly (Jose). - Add code comment explaining why we disabled the ports. (Jani) Cc: Jani Nikula Cc: Paulo Zanoni Cc: Jose Roberto de Souza Cc: Ville Syrjälä Cc: Rodrigo Vivi Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_bios.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 561a4f9f044c..b508d8a735e0 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1663,6 +1663,13 @@ init_vbt_missing_defaults(struct drm_i915_private *dev_priv) struct ddi_vbt_port_info *info = _priv->vbt.ddi_port_info[port]; + /* +* VBT has the TypeC mode (native,TBT/USB) and we don't want +* to detect it. +*/ + if (intel_port_is_tc(dev_priv, port)) + continue; + info->supports_dvi = (port != PORT_A && port != PORT_E); info->supports_hdmi = info->supports_dvi; info->supports_dp = (port != PORT_E); -- 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/5] drm/i915: prepare for drmP.h removal from drm_modeset_helper.h
On Sat, 26 Jan 2019, Sam Ravnborg wrote:
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused i915 to fail to build.
>
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from drm_modeset_helper.h.
>
> In the files touched the lists of include files was grouped
> and sorted.
>
> Build tested on x86 and arm allmodconfig / allyesconfig.
>
> Signed-off-by: Sam Ravnborg
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
Not going to second-guess the compiler, looks good to me,
Acked-by: Jani Nikula
and good to merge via whichever tree you see fit.
> ---
> drivers/gpu/drm/i915/i915_drv.c | 4 +++-
> drivers/gpu/drm/i915/intel_atomic.c | 2 ++
> drivers/gpu/drm/i915/intel_atomic_plane.c | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 29 -
> drivers/gpu/drm/i915/intel_pm.c | 7 +--
> 5 files changed, 28 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 9883921013b1..8c8f36a91e7e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -41,8 +41,10 @@
> #include
> #include
>
> -#include
> #include
> +#include
> +#include
> +#include
> #include
>
> #include "i915_drv.h"
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index d8dbc9980281..f415ed239184 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -31,7 +31,9 @@
>
> #include
> #include
> +#include
> #include
> +
> #include "intel_drv.h"
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 683a75dad4fb..79139d496c78 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -32,7 +32,9 @@
> */
>
> #include
> +#include
> #include
> +
> #include "intel_drv.h"
>
> struct intel_plane *intel_plane_alloc(void)
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 15d758cd0c1b..e0f40be07131 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -24,29 +24,32 @@
> * Eric Anholt
> */
>
> -#include
> -#include
> #include
> +#include
> +#include
> #include
> +#include
> +#include
> #include
> #include
> -#include
> -#include "intel_drv.h"
> -#include "intel_frontbuffer.h"
> -#include
> -#include "i915_drv.h"
> -#include "i915_gem_clflush.h"
> -#include "intel_dsi.h"
> -#include "i915_trace.h"
> +
> #include
> #include
> +#include
> #include
> +#include
> +#include
> #include
> #include
> #include
> -#include
> -#include
> -#include
> +#include
> +
> +#include "i915_drv.h"
> +#include "i915_gem_clflush.h"
> +#include "i915_trace.h"
> +#include "intel_drv.h"
> +#include "intel_dsi.h"
> +#include "intel_frontbuffer.h"
>
> /* Primary plane formats for gen <= 3 */
> static const uint32_t i8xx_primary_formats[] = {
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 83b01cde8113..48c755dc895b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -26,13 +26,16 @@
> */
>
> #include
> +#include
> #include
> +
> +#include
> +#include
> #include
> +
> #include "i915_drv.h"
> #include "intel_drv.h"
> #include "../../../platform/x86/intel_ips.h"
> -#include
> -#include
>
> /**
> * DOC: RC6
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check for hangs allowed
Quoting Tvrtko Ursulin (2019-01-28 11:00:43)
>
> On 28/01/2019 10:18, Chris Wilson wrote:
> > Check we can reset the GPU before running the reset test.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > Different meaning of flags, it's not the ring id!
> > ---
> > tests/perf_pmu.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
> > index 21292bf3a..c9881e59f 100644
> > --- a/tests/perf_pmu.c
> > +++ b/tests/perf_pmu.c
> > @@ -1812,8 +1812,13 @@ igt_main
> > accuracy(fd, e, pct[i], 10);
> > }
> >
> > - igt_subtest_f("busy-hang-%s", e->name)
> > + igt_subtest_f("busy-hang-%s", e->name) {
> > + igt_hang_t hang = igt_allow_hang(fd, 0, 0);
> > +
> > single(fd, e, TEST_BUSY | FLAG_HANG);
> > +
> > + igt_disallow_hang(fd, hang);
> > + }
> > }
> >
> > /**
> >
>
> So all IGTs which trigger hangs/resets should call this?
Yeah, aside from checking we have gpu-reset, it is meant to prep the
context to expect a hang. It just happens to work fine until we hit a
corner case (such as gen2, guc currently, or too many resets).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets
Check that we are allowed to reset the GPU prior to execution.
v2: Push the require checking up into a subgroup
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
index 78478ad2c..44e3dce8a 100644
--- a/tests/i915/gem_workarounds.c
+++ b/tests/i915/gem_workarounds.c
@@ -282,9 +282,32 @@ igt_main
}
for (op = ops; op->name; op++) {
- for (m = modes; m->name; m++) {
- igt_subtest_f("%s%s", op->name, m->name)
- check_workarounds(device, op->op, m->flags);
+ igt_subtest_group {
+ igt_hang_t hang = {};
+
+ igt_fixture {
+ switch (op->op) {
+ case GPU_RESET:
+ hang = igt_allow_hang(device, 0, 0);
+ break;
+ default:
+ break;
+ }
+ }
+
+ for (m = modes; m->name; m++)
+ igt_subtest_f("%s%s", op->name, m->name)
+ check_workarounds(device, op->op,
m->flags);
+
+ igt_fixture {
+ switch (op->op) {
+ case GPU_RESET:
+ igt_disallow_hang(device, hang);
+ break;
+ default:
+ break;
+ }
+ }
}
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets
Quoting Chris Wilson (2019-01-28 11:07:40)
> Quoting Tvrtko Ursulin (2019-01-28 11:03:30)
> >
> > On 27/01/2019 13:06, Chris Wilson wrote:
> > > Check that we are allowed to reset the GPU prior to execution.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > tests/i915/gem_workarounds.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
> > > index 78478ad2c..0e9ab2386 100644
> > > --- a/tests/i915/gem_workarounds.c
> > > +++ b/tests/i915/gem_workarounds.c
> > > @@ -192,7 +192,11 @@ static void check_workarounds(int fd, enum operation
> > > op, unsigned int flags)
> > >
> > > switch (op) {
> > > case GPU_RESET:
> > > - igt_force_gpu_reset(fd);
> > > + {
> > > + igt_hang_t hang = igt_allow_hang(fd, ctx, 0);
> > > + igt_force_gpu_reset(fd);
> > > + igt_disallow_hang(fd, hang);
> > > + }
> > > break;
> > >
> > > case SUSPEND_RESUME:
> > >
> >
> > If it doesn't make sense to add the checks into igt_force_gpu_reset (so
> > force means force), should we have igt_try_gpu_reset to avoid having to
> > wrap it everywhere?
>
> Ugh. igt_try_gpu_reset_with_many_many_options_depending_on_test().
>
> I like my requires as high up in the chain as possible, I've been bitten
> too many times by hiding them.
The key benefit from doing it higher up, is that we should be doing it
as early as possible and should be more descriptive about why.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets
Quoting Tvrtko Ursulin (2019-01-28 11:03:30)
>
> On 27/01/2019 13:06, Chris Wilson wrote:
> > Check that we are allowed to reset the GPU prior to execution.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/i915/gem_workarounds.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
> > index 78478ad2c..0e9ab2386 100644
> > --- a/tests/i915/gem_workarounds.c
> > +++ b/tests/i915/gem_workarounds.c
> > @@ -192,7 +192,11 @@ static void check_workarounds(int fd, enum operation
> > op, unsigned int flags)
> >
> > switch (op) {
> > case GPU_RESET:
> > - igt_force_gpu_reset(fd);
> > + {
> > + igt_hang_t hang = igt_allow_hang(fd, ctx, 0);
> > + igt_force_gpu_reset(fd);
> > + igt_disallow_hang(fd, hang);
> > + }
> > break;
> >
> > case SUSPEND_RESUME:
> >
>
> If it doesn't make sense to add the checks into igt_force_gpu_reset (so
> force means force), should we have igt_try_gpu_reset to avoid having to
> wrap it everywhere?
Ugh. igt_try_gpu_reset_with_many_many_options_depending_on_test().
I like my requires as high up in the chain as possible, I've been bitten
too many times by hiding them.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/28] drm/i915: Rename execlists->queue_priority to preempt_priority_hint
Quoting Tvrtko Ursulin (2019-01-28 10:56:24)
>
> On 28/01/2019 01:02, Chris Wilson wrote:
> > After noticing that we trigger preemption events for currently executing
> > requests, as well as requests that complete before the preemption and
> > attempting to suppress those preemption events, it is wise to not
> > consider the queue_priority to be authoritative. As we only track the
> > maximum priority seen between dequeue passes, if the maximum priority
> > request is no longer available for dequeuing (it completed or is even
> > executing on another engine), we have no knowledge of the previous
> > queue_priority as it would require us to keep a full history of enqueued
> > requests -- but we already have that history in the priolists!
> >
> > Rename the queue_priority to preempt_priority_hint so that we do not
> > confuse it as being the maximum priority in the queue, but merely an
> > indication that we have seen a new maximum priority value and as such we
> > should check whether it should preempt the currently running request.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_scheduler.c | 11 +--
> > drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
> > drivers/gpu/drm/i915/intel_guc_submission.c | 5 +++--
> > drivers/gpu/drm/i915/intel_lrc.c| 20 +++-
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 8 ++--
> > 5 files changed, 27 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 340faea6c08a..0da718ceab43 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -127,8 +127,7 @@ static inline struct i915_priolist *to_priolist(struct
> > rb_node *rb)
> > return rb_entry(rb, struct i915_priolist, node);
> > }
> >
> > -static void assert_priolists(struct intel_engine_execlists * const
> > execlists,
> > - long queue_priority)
> > +static void assert_priolists(struct intel_engine_execlists * const
> > execlists)
> > {
> > struct rb_node *rb;
> > long last_prio, i;
> > @@ -139,7 +138,7 @@ static void assert_priolists(struct
> > intel_engine_execlists * const execlists,
> > GEM_BUG_ON(rb_first_cached(>queue) !=
> > rb_first(>queue.rb_root));
> >
> > - last_prio = (queue_priority >> I915_USER_PRIORITY_SHIFT) + 1;
> > + last_prio = (INT_MAX >> I915_USER_PRIORITY_SHIFT) + 1;
> > for (rb = rb_first_cached(>queue); rb; rb = rb_next(rb)) {
> > const struct i915_priolist *p = to_priolist(rb);
> >
> > @@ -166,7 +165,7 @@ i915_sched_lookup_priolist(struct intel_engine_cs
> > *engine, int prio)
> > int idx, i;
> >
> > lockdep_assert_held(>timeline.lock);
> > - assert_priolists(execlists, INT_MAX);
> > + assert_priolists(execlists);
> >
> > /* buckets sorted from highest [in slot 0] to lowest priority */
> > idx = I915_PRIORITY_COUNT - (prio & I915_PRIORITY_MASK) - 1;
> > @@ -353,7 +352,7 @@ static void __i915_schedule(struct i915_request *rq,
> > continue;
> > }
> >
> > - if (prio <= engine->execlists.queue_priority)
> > + if (prio <= engine->execlists.preempt_priority_hint)
> > continue;
> >
> > /*
> > @@ -366,7 +365,7 @@ static void __i915_schedule(struct i915_request *rq,
> > continue;
> >
> > /* Defer (tasklet) submission until after all of our updates.
> > */
> > - engine->execlists.queue_priority = prio;
> > + engine->execlists.preempt_priority_hint = prio;
>
> I am wondering whether stopping tracking the queue priority here, and
> making it mean one thing only, would simplify things.
No, it doesn't simply things. We already track queue_priority (it's the
queue!) What we need is a very quick test as to whether we even need to
consider preemption.
> We make queue_priority strictly track the priority of whatever is in
> port0 only, updated on dequeue and after context switch. Ie.
> execlists.queue_priority gets the meaning of "top of the hw backend
> queue priority".
That is already tracked in port0.
> For the purpose of kicking the tasklet that should work I think. It
> wouldn't interrupt the port0 rq, and then on CS, dequeue would inspect
> the real queue and see it there is need to preempt.
... hence the patches ...
> At the end of __i915_schedule we peek at top of the queue and decide
> whether to kick the tasklet.
>
> So we end up with two heads of queue priority. The HW backend one, and
> the scheduling tree. Which seems like a clear separation of duties.
>
> need_preempt() on dequeue then compares the two priorities only. Just
> needs additional protection against not preempting the same context.
>
> I
Re: [Intel-gfx] [PATCH i-g-t] i915/gem_workarounds: Require GPU resets
On 27/01/2019 13:06, Chris Wilson wrote:
Check that we are allowed to reset the GPU prior to execution.
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
index 78478ad2c..0e9ab2386 100644
--- a/tests/i915/gem_workarounds.c
+++ b/tests/i915/gem_workarounds.c
@@ -192,7 +192,11 @@ static void check_workarounds(int fd, enum operation op,
unsigned int flags)
switch (op) {
case GPU_RESET:
- igt_force_gpu_reset(fd);
+ {
+ igt_hang_t hang = igt_allow_hang(fd, ctx, 0);
+ igt_force_gpu_reset(fd);
+ igt_disallow_hang(fd, hang);
+ }
break;
case SUSPEND_RESUME:
If it doesn't make sense to add the checks into igt_force_gpu_reset (so
force means force), should we have igt_try_gpu_reset to avoid having to
wrap it everywhere?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check for hangs allowed
On 28/01/2019 10:18, Chris Wilson wrote:
Check we can reset the GPU before running the reset test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Different meaning of flags, it's not the ring id!
---
tests/perf_pmu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 21292bf3a..c9881e59f 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1812,8 +1812,13 @@ igt_main
accuracy(fd, e, pct[i], 10);
}
- igt_subtest_f("busy-hang-%s", e->name)
+ igt_subtest_f("busy-hang-%s", e->name) {
+ igt_hang_t hang = igt_allow_hang(fd, 0, 0);
+
single(fd, e, TEST_BUSY | FLAG_HANG);
+
+ igt_disallow_hang(fd, hang);
+ }
}
/**
So all IGTs which trigger hangs/resets should call this?
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Add TypeC ports only if VBT is present
On Fri, Jan 25, 2019 at 11:16:08PM +0200, Souza, Jose wrote:
> On Fri, 2019-01-25 at 16:34 +0200, Imre Deak wrote:
> > We can't safely probe Type C ports, whether they are a legacy or a
> > USB/Thunderbolt DP Alternate Type C port. This would require
> > performing
> > the TypeC connect sequence - as described by the specification - but
> > that may have unwanted side-effects. These side-effects include at
> > least
> > - without completeness - timeouts during AUX power well enabling and
> > subsequent PLL enabling errors.
> >
>
> Makes sense, behaps there is a bug open with this timeouts and errors
> to link to?
There's no specific bug for these issues as we don't try to detect the
mode.
>
> > To safely identify these ports we really need VBT, which has the
> > proper
> > flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt).
> > Based on the above disable Type C ports if we can't load VBT for some
> > reason.
>
>
> Reviewed-by: José Roberto de Souza
>
> >
> > Cc: Jani Nikula
> > Cc: Paulo Zanoni
> > Cc: Jose Roberto de Souza
> > Cc: Ville Syrjälä
> > Cc: Rodrigo Vivi
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_bios.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 561a4f9f044c..270e7f0ad5cd 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1662,10 +1662,12 @@ init_vbt_missing_defaults(struct
> > drm_i915_private *dev_priv)
> > for (port = PORT_A; port < I915_MAX_PORTS; port++) {
> > struct ddi_vbt_port_info *info =
> > _priv->vbt.ddi_port_info[port];
> > + bool is_tc_port = intel_port_is_tc(dev_priv, port);
>
> Nit:
>
> if (intel_port_is_tc(dev_priv, port))
> continue;
>
> instead?
Yep, makes sense, thanks for noticing.
>
> >
> > - info->supports_dvi = (port != PORT_A && port !=
> > PORT_E);
> > + info->supports_dvi = (port != PORT_A && port != PORT_E
> > &&
> > + !is_tc_port);
> > info->supports_hdmi = info->supports_dvi;
> > - info->supports_dp = (port != PORT_E);
> > + info->supports_dp = (port != PORT_E && !is_tc_port);
> > }
> > }
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/28] drm/i915: Rename execlists->queue_priority to preempt_priority_hint
On 28/01/2019 01:02, Chris Wilson wrote:
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritative. As we only track the
maximum priority seen between dequeue passes, if the maximum priority
request is no longer available for dequeuing (it completed or is even
executing on another engine), we have no knowledge of the previous
queue_priority as it would require us to keep a full history of enqueued
requests -- but we already have that history in the priolists!
Rename the queue_priority to preempt_priority_hint so that we do not
confuse it as being the maximum priority in the queue, but merely an
indication that we have seen a new maximum priority value and as such we
should check whether it should preempt the currently running request.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_scheduler.c | 11 +--
drivers/gpu/drm/i915/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 5 +++--
drivers/gpu/drm/i915/intel_lrc.c| 20 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 8 ++--
5 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
b/drivers/gpu/drm/i915/i915_scheduler.c
index 340faea6c08a..0da718ceab43 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -127,8 +127,7 @@ static inline struct i915_priolist *to_priolist(struct
rb_node *rb)
return rb_entry(rb, struct i915_priolist, node);
}
-static void assert_priolists(struct intel_engine_execlists * const execlists,
-long queue_priority)
+static void assert_priolists(struct intel_engine_execlists * const execlists)
{
struct rb_node *rb;
long last_prio, i;
@@ -139,7 +138,7 @@ static void assert_priolists(struct intel_engine_execlists
* const execlists,
GEM_BUG_ON(rb_first_cached(>queue) !=
rb_first(>queue.rb_root));
- last_prio = (queue_priority >> I915_USER_PRIORITY_SHIFT) + 1;
+ last_prio = (INT_MAX >> I915_USER_PRIORITY_SHIFT) + 1;
for (rb = rb_first_cached(>queue); rb; rb = rb_next(rb)) {
const struct i915_priolist *p = to_priolist(rb);
@@ -166,7 +165,7 @@ i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
int idx, i;
lockdep_assert_held(>timeline.lock);
- assert_priolists(execlists, INT_MAX);
+ assert_priolists(execlists);
/* buckets sorted from highest [in slot 0] to lowest priority */
idx = I915_PRIORITY_COUNT - (prio & I915_PRIORITY_MASK) - 1;
@@ -353,7 +352,7 @@ static void __i915_schedule(struct i915_request *rq,
continue;
}
- if (prio <= engine->execlists.queue_priority)
+ if (prio <= engine->execlists.preempt_priority_hint)
continue;
/*
@@ -366,7 +365,7 @@ static void __i915_schedule(struct i915_request *rq,
continue;
/* Defer (tasklet) submission until after all of our updates. */
- engine->execlists.queue_priority = prio;
+ engine->execlists.preempt_priority_hint = prio;
I am wondering whether stopping tracking the queue priority here, and
making it mean one thing only, would simplify things.
We make queue_priority strictly track the priority of whatever is in
port0 only, updated on dequeue and after context switch. Ie.
execlists.queue_priority gets the meaning of "top of the hw backend
queue priority".
For the purpose of kicking the tasklet that should work I think. It
wouldn't interrupt the port0 rq, and then on CS, dequeue would inspect
the real queue and see it there is need to preempt.
At the end of __i915_schedule we peek at top of the queue and decide
whether to kick the tasklet.
So we end up with two heads of queue priority. The HW backend one, and
the scheduling tree. Which seems like a clear separation of duties.
need_preempt() on dequeue then compares the two priorities only. Just
needs additional protection against not preempting the same context.
I hope I did not miss something, what do you think?
tasklet_hi_schedule(>execlists.tasklet);
}
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1a5c163b98d6..1ffec0d69157 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -480,7 +480,7 @@ static void intel_engine_init_execlist(struct
intel_engine_cs *engine)
GEM_BUG_ON(!is_power_of_2(execlists_num_ports(execlists)));
GEM_BUG_ON(execlists_num_ports(execlists) > EXECLIST_MAX_PORTS);
- execlists->queue_priority = INT_MIN;
+
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add Colorspace connector property interface (rev7)
== Series Details ==
Series: Add Colorspace connector property interface (rev7)
URL : https://patchwork.freedesktop.org/series/47132/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5490_full -> Patchwork_12056_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12056_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12056_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_12056_full:
### IGT changes ###
Possible regressions
* igt@prime_busy@hang-default:
- shard-hsw: PASS -> FAIL
Known issues
Here are the changes found in Patchwork_12056_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_color@pipe-c-degamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x128-sliding:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-256x256-random:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_flip@2x-wf_vblank-ts-check:
- shard-hsw: PASS -> DMESG-FAIL [fdo#102614]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-none:
- shard-glk: PASS -> FAIL [fdo#103166]
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@i915_selftest@live_requests:
- shard-apl: DMESG-FAIL -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: FAIL [fdo#102887] / [fdo#105363] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_setmode@basic:
- shard-glk: FAIL [fdo#99912] -> PASS
* igt@perf_pmu@rc6-runtime-pm-long:
- shard-kbl: FAIL [fdo#105010] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#102887]: https://bugs.freedesktop.org/show_bug.cgi?id=102887
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#105010]: https://bugs.freedesktop.org/show_bug.cgi?id=105010
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5490 -> Patchwork_12056
CI_DRM_5490: 310d38b4b51e06ef7096716430e2ef262c3e45fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12056: 7195c72c35da94b4b353ccbd62a7c32281c4bb79 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12056/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 5/5] drm/i915: Move list of timelines under its own lock
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_gem.c | 103 ++
drivers/gpu/drm/i915/i915_reset.c | 8 +-
drivers/gpu/drm/i915/i915_timeline.c | 38 ++-
drivers/gpu/drm/i915/i915_timeline.h | 3 +
.../gpu/drm/i915/selftests/mock_gem_device.c | 7 +-
.../gpu/drm/i915/selftests/mock_timeline.c| 3 +-
7 files changed, 109 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0133d1da3d3c..8a181b455197 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1975,7 +1975,10 @@ struct drm_i915_private {
void (*resume)(struct drm_i915_private *);
void (*cleanup_engine)(struct intel_engine_cs *engine);
- struct list_head timelines;
+ struct i915_gt_timelines {
+ struct mutex mutex; /* protects list, tainted by GPU */
+ struct list_head list;
+ } timelines;
struct list_head active_rings;
struct list_head closed_vma;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 653c7ba4c69f..d68f3fdd8a8e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3224,33 +3224,6 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
return ret;
}
-static long wait_for_timeline(struct i915_timeline *tl,
- unsigned int flags, long timeout)
-{
- struct i915_request *rq;
-
- rq = i915_gem_active_get_unlocked(>last_request);
- if (!rq)
- return timeout;
-
- /*
-* "Race-to-idle".
-*
-* Switching to the kernel context is often used a synchronous
-* step prior to idling, e.g. in suspend for flushing all
-* current operations to memory before sleeping. These we
-* want to complete as quickly as possible to avoid prolonged
-* stalls, so allow the gpu to boost to maximum clocks.
-*/
- if (flags & I915_WAIT_FOR_IDLE_BOOST)
- gen6_rps_boost(rq, NULL);
-
- timeout = i915_request_wait(rq, flags, timeout);
- i915_request_put(rq);
-
- return timeout;
-}
-
static int wait_for_engines(struct drm_i915_private *i915)
{
if (wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) {
@@ -3264,6 +3237,52 @@ static int wait_for_engines(struct drm_i915_private
*i915)
return 0;
}
+static long
+wait_for_timelines(struct drm_i915_private *i915,
+ unsigned int flags, long timeout)
+{
+ struct i915_gt_timelines *gt = >gt.timelines;
+ struct i915_timeline *tl;
+
+ if (!READ_ONCE(i915->gt.active_requests))
+ return timeout;
+
+ mutex_lock(>mutex);
+ list_for_each_entry(tl, >list, link) {
+ struct i915_request *rq;
+
+ rq = i915_gem_active_get_unlocked(>last_request);
+ if (!rq)
+ continue;
+
+ mutex_unlock(>mutex);
+
+ /*
+* "Race-to-idle".
+*
+* Switching to the kernel context is often used a synchronous
+* step prior to idling, e.g. in suspend for flushing all
+* current operations to memory before sleeping. These we
+* want to complete as quickly as possible to avoid prolonged
+* stalls, so allow the gpu to boost to maximum clocks.
+*/
+ if (flags & I915_WAIT_FOR_IDLE_BOOST)
+ gen6_rps_boost(rq, NULL);
+
+ timeout = i915_request_wait(rq, flags, timeout);
+ i915_request_put(rq);
+ if (timeout < 0)
+ return timeout;
+
+ /* restart after reacquiring the lock */
+ mutex_lock(>mutex);
+ tl = list_entry(>list, typeof(*tl), link);
+ }
+ mutex_unlock(>mutex);
+
+ return timeout;
+}
+
int i915_gem_wait_for_idle(struct drm_i915_private *i915,
unsigned int flags, long timeout)
{
@@ -3275,17 +3294,15 @@ int i915_gem_wait_for_idle(struct drm_i915_private
*i915,
if (!READ_ONCE(i915->gt.awake))
return 0;
+ timeout = wait_for_timelines(i915, flags, timeout);
+ if (timeout < 0)
+ return timeout;
+
if (flags & I915_WAIT_LOCKED) {
- struct i915_timeline *tl;
int err;
lockdep_assert_held(>drm.struct_mutex);
-
[Intel-gfx] [CI 4/5] drm/i915: Always allocate an object/vma for the HWSP
Currently we only allocate an object and vma if we are using a GGTT
virtual HWSP, and a plain struct page for a physical HWSP. For
convenience later on with global timelines, it will be useful to always
have the status page being tracked by a struct i915_vma. Make it so.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/intel_engine_cs.c | 109 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 6 +
drivers/gpu/drm/i915/intel_lrc.c | 12 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 +++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 23 +---
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
6 files changed, 93 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 1a5c163b98d6..2657eb6fd914 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -506,27 +506,61 @@ void intel_engine_setup_common(struct intel_engine_cs
*engine)
static void cleanup_status_page(struct intel_engine_cs *engine)
{
+ struct i915_vma *vma;
+
/* Prevent writes into HWSP after returning the page to the system */
intel_engine_set_hwsp_writemask(engine, ~0u);
- if (HWS_NEEDS_PHYSICAL(engine->i915)) {
- void *addr = fetch_and_zero(>status_page.page_addr);
+ vma = fetch_and_zero(>status_page.vma);
+ if (!vma)
+ return;
- __free_page(virt_to_page(addr));
- }
+ if (!HWS_NEEDS_PHYSICAL(engine->i915))
+ i915_vma_unpin(vma);
+
+ i915_gem_object_unpin_map(vma->obj);
+ __i915_gem_object_release_unless_active(vma->obj);
+}
+
+static int pin_ggtt_status_page(struct intel_engine_cs *engine,
+ struct i915_vma *vma)
+{
+ unsigned int flags;
+
+ flags = PIN_GLOBAL;
+ if (!HAS_LLC(engine->i915))
+ /*
+* On g33, we cannot place HWS above 256MiB, so
+* restrict its pinning to the low mappable arena.
+* Though this restriction is not documented for
+* gen4, gen5, or byt, they also behave similarly
+* and hang if the HWS is placed at the top of the
+* GTT. To generalise, it appears that all !llc
+* platforms have issues with us placing the HWS
+* above the mappable region (even though we never
+* actually map it).
+*/
+ flags |= PIN_MAPPABLE;
+ else
+ flags |= PIN_HIGH;
- i915_vma_unpin_and_release(>status_page.vma,
- I915_VMA_RELEASE_MAP);
+ return i915_vma_pin(vma, 0, 0, flags);
}
static int init_status_page(struct intel_engine_cs *engine)
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
- unsigned int flags;
void *vaddr;
int ret;
+ /*
+* Though the HWS register does support 36bit addresses, historically
+* we have had hangs and corruption reported due to wild writes if
+* the HWS is placed above 4G. We only allow objects to be allocated
+* in GFP_DMA32 for i965, and no earlier physical address users had
+* access to more than 4G.
+*/
obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
if (IS_ERR(obj)) {
DRM_ERROR("Failed to allocate status page\n");
@@ -543,61 +577,30 @@ static int init_status_page(struct intel_engine_cs
*engine)
goto err;
}
- flags = PIN_GLOBAL;
- if (!HAS_LLC(engine->i915))
- /* On g33, we cannot place HWS above 256MiB, so
-* restrict its pinning to the low mappable arena.
-* Though this restriction is not documented for
-* gen4, gen5, or byt, they also behave similarly
-* and hang if the HWS is placed at the top of the
-* GTT. To generalise, it appears that all !llc
-* platforms have issues with us placing the HWS
-* above the mappable region (even though we never
-* actually map it).
-*/
- flags |= PIN_MAPPABLE;
- else
- flags |= PIN_HIGH;
- ret = i915_vma_pin(vma, 0, 0, flags);
- if (ret)
- goto err;
-
vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
- goto err_unpin;
+ goto err;
}
+ engine->status_page.addr = memset(vaddr, 0, PAGE_SIZE);
engine->status_page.vma = vma;
- engine->status_page.ggtt_offset = i915_ggtt_offset(vma);
- engine->status_page.page_addr = memset(vaddr, 0, PAGE_SIZE);
+
+ if (!HWS_NEEDS_PHYSICAL(engine->i915)) {
+ ret =
[Intel-gfx] [CI 2/5] drm/i915: Pull VM lists under the VM mutex.
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as the guard for all things GTT/VM and switch instead to a
specific mutex inside i915_address_space.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c| 4
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/i915_vma.c | 11 +++
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 3 +++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 +++
8 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 12a0a80bc989..111a047a45b7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -247,18 +247,19 @@ int
i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct i915_ggtt *ggtt = _priv->ggtt;
+ struct i915_ggtt *ggtt = _i915(dev)->ggtt;
struct drm_i915_gem_get_aperture *args = data;
struct i915_vma *vma;
u64 pinned;
+ mutex_lock(>vm.mutex);
+
pinned = ggtt->vm.reserved;
- mutex_lock(>struct_mutex);
list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
- mutex_unlock(>struct_mutex);
+
+ mutex_unlock(>vm.mutex);
args->aper_size = ggtt->vm.total;
args->aper_available_size = args->aper_size - pinned;
@@ -1531,20 +1532,21 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
*data,
static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
{
- struct drm_i915_private *i915;
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct list_head *list;
struct i915_vma *vma;
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
+ mutex_lock(>ggtt.vm.mutex);
for_each_ggtt_vma(vma, obj) {
if (!drm_mm_node_allocated(>node))
continue;
list_move_tail(>vm_link, >vm->bound_list);
}
+ mutex_unlock(>ggtt.vm.mutex);
- i915 = to_i915(obj->base.dev);
spin_lock(>mm.obj_lock);
list = obj->bind_count ? >mm.bound_list : >mm.unbound_list;
list_move_tail(>mm.link, list);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index d76839670632..68d74c50ac39 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -430,6 +430,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
}
INIT_LIST_HEAD(_list);
+ mutex_lock(>mutex);
list_for_each_entry(vma, >bound_list, vm_link) {
if (i915_vma_is_pinned(vma))
continue;
@@ -437,6 +438,7 @@ int i915_gem_evict_vm(struct i915_address_space *vm)
__i915_vma_pin(vma);
list_add(>evict_link, _list);
}
+ mutex_unlock(>mutex);
ret = 0;
list_for_each_entry_safe(vma, next, _list, evict_link) {
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 2ad9070a54c1..49b00996a15e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1931,7 +1931,10 @@ static struct i915_vma *pd_vma_create(struct
gen6_hw_ppgtt *ppgtt, int size)
vma->ggtt_view.type = I915_GGTT_VIEW_ROTATED; /* prevent fencing */
INIT_LIST_HEAD(>obj_link);
+
+ mutex_lock(>vm->mutex);
list_add(>vm_link, >vm->unbound_list);
+ mutex_unlock(>vm->mutex);
return vma;
}
@@ -3504,9 +3507,10 @@ void i915_gem_restore_gtt_mappings(struct
drm_i915_private *dev_priv)
i915_check_and_clear_faults(dev_priv);
+ mutex_lock(>vm.mutex);
+
/* First fill our portion of the GTT with scratch pages */
ggtt->vm.clear_range(>vm, 0, ggtt->vm.total);
-
ggtt->vm.closed = true; /* skip rewriting PTE on VMA unbind */
/* clflush objects bound into the GGTT and rebind them. */
@@ -3516,19 +3520,26 @@ void i915_gem_restore_gtt_mappings(struct
drm_i915_private *dev_priv)
if (!(vma->flags & I915_VMA_GLOBAL_BIND))
continue;
+ mutex_unlock(>vm.mutex);
+
if (!i915_vma_unbind(vma))
- continue;
+
[Intel-gfx] [CI 3/5] drm/i915: Move vma lookup to its own lock
Remove the struct_mutex requirement for looking up the vma for an
object.
v2: Highlight how the race for duplicate vma creation is resolved on
reacquiring the lock with a short comment.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_gem.c | 33 +++-
drivers/gpu/drm/i915/i915_gem_object.h| 45 +---
drivers/gpu/drm/i915/i915_vma.c | 66 ---
drivers/gpu/drm/i915/i915_vma.h | 2 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 4 +-
6 files changed, 98 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e46de507fea2..f5ac03f06e26 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -160,14 +160,14 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
obj->mm.madv == I915_MADV_DONTNEED ? " purgeable" : "");
if (obj->base.name)
seq_printf(m, " (name: %d)", obj->base.name);
- list_for_each_entry(vma, >vma_list, obj_link) {
+ list_for_each_entry(vma, >vma.list, obj_link) {
if (i915_vma_is_pinned(vma))
pin_count++;
}
seq_printf(m, " (pinned x %d)", pin_count);
if (obj->pin_global)
seq_printf(m, " (global)");
- list_for_each_entry(vma, >vma_list, obj_link) {
+ list_for_each_entry(vma, >vma.list, obj_link) {
if (!drm_mm_node_allocated(>node))
continue;
@@ -323,7 +323,7 @@ static int per_file_stats(int id, void *ptr, void *data)
if (obj->base.name || obj->base.dma_buf)
stats->shared += obj->base.size;
- list_for_each_entry(vma, >vma_list, obj_link) {
+ list_for_each_entry(vma, >vma.list, obj_link) {
if (!drm_mm_node_allocated(>node))
continue;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 111a047a45b7..653c7ba4c69f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -439,15 +439,19 @@ int i915_gem_object_unbind(struct drm_i915_gem_object
*obj)
if (ret)
return ret;
- while ((vma = list_first_entry_or_null(>vma_list,
- struct i915_vma,
- obj_link))) {
+ spin_lock(>vma.lock);
+ while (!ret && (vma = list_first_entry_or_null(>vma.list,
+ struct i915_vma,
+ obj_link))) {
list_move_tail(>obj_link, _in_list);
+ spin_unlock(>vma.lock);
+
ret = i915_vma_unbind(vma);
- if (ret)
- break;
+
+ spin_lock(>vma.lock);
}
- list_splice(_in_list, >vma_list);
+ list_splice(_in_list, >vma.list);
+ spin_unlock(>vma.lock);
return ret;
}
@@ -3491,7 +3495,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
* reading an invalid PTE on older architectures.
*/
restart:
- list_for_each_entry(vma, >vma_list, obj_link) {
+ list_for_each_entry(vma, >vma.list, obj_link) {
if (!drm_mm_node_allocated(>node))
continue;
@@ -3569,7 +3573,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
*/
}
- list_for_each_entry(vma, >vma_list, obj_link) {
+ list_for_each_entry(vma, >vma.list, obj_link) {
if (!drm_mm_node_allocated(>node))
continue;
@@ -3579,7 +3583,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
}
}
- list_for_each_entry(vma, >vma_list, obj_link)
+ list_for_each_entry(vma, >vma.list, obj_link)
vma->node.color = cache_level;
i915_gem_object_set_cache_coherency(obj, cache_level);
obj->cache_dirty = true; /* Always invalidate stale cachelines */
@@ -4155,7 +4159,9 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
{
mutex_init(>mm.lock);
- INIT_LIST_HEAD(>vma_list);
+ spin_lock_init(>vma.lock);
+ INIT_LIST_HEAD(>vma.list);
+
INIT_LIST_HEAD(>lut_list);
INIT_LIST_HEAD(>batch_pool_link);
@@ -4321,14 +4327,13 @@ static void __i915_gem_free_objects(struct
drm_i915_private *i915,
mutex_lock(>drm.struct_mutex);
GEM_BUG_ON(i915_gem_object_is_active(obj));
- list_for_each_entry_safe(vma, vn,
->vma_list, obj_link) {
+ list_for_each_entry_safe(vma, vn, >vma.list,
[Intel-gfx] [CI 1/5] drm/i915: Stop tracking MRU activity on VMA
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracking is less agreeable. One solution is not to do any
MRU tracking and do a simple coarse evaluation during eviction of
active/inactive, with a loose temporal ordering of last
insertion/evaluation. That keeps all the locking constrained to when we
are manipulating the VM itself, neatly avoiding the tricky handling of
possible recursive locking during execbuf and elsewhere.
Note that discarding the MRU (currently implemented as a pair of lists,
to avoid scanning the active list for a NONBLOCKING search) is unlikely
to impact upon our efficiency to reclaim VM space (where we think a LRU
model is best) as our current strategy is to use random idle replacement
first before doing a search, and over time the use of softpinned 48b
per-ppGTT is growing (thereby eliminating any need to perform any eviction
searches, in theory at least) with the remaining users being found on
much older devices (gen2-gen6).
v2: Changelog and commentary rewritten to elaborate on the duality of a
single list being both an inactive and active list.
v3: Consolidate bool parameters into a single set of flags; don't
comment on the duality of a single variable being a multiplicity of
bits.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 87 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 +-
drivers/gpu/drm/i915/i915_gem_stolen.c| 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 42 -
drivers/gpu/drm/i915/i915_vma.c | 9 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
10 files changed, 95 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcbe644869b3..12a0a80bc989 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -255,10 +255,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
pinned = ggtt->vm.reserved;
mutex_lock(>struct_mutex);
- list_for_each_entry(vma, >vm.active_list, vm_link)
- if (i915_vma_is_pinned(vma))
- pinned += vma->node.size;
- list_for_each_entry(vma, >vm.inactive_list, vm_link)
+ list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(>struct_mutex);
@@ -1541,13 +1538,10 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
for_each_ggtt_vma(vma, obj) {
- if (i915_vma_is_active(vma))
- continue;
-
if (!drm_mm_node_allocated(>node))
continue;
- list_move_tail(>vm_link, >vm->inactive_list);
+ list_move_tail(>vm_link, >vm->bound_list);
}
i915 = to_i915(obj->base.dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index f6855401f247..d76839670632 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -126,31 +126,25 @@ i915_gem_evict_something(struct i915_address_space *vm,
struct drm_i915_private *dev_priv = vm->i915;
struct drm_mm_scan scan;
struct list_head eviction_list;
- struct list_head *phases[] = {
- >inactive_list,
- >active_list,
- NULL,
- }, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
enum drm_mm_insert_mode mode;
+ struct i915_vma *active;
int ret;
lockdep_assert_held(>i915->drm.struct_mutex);
trace_i915_gem_evict(vm, min_size, alignment, flags);
/*
-* The goal is to evict objects and amalgamate space in LRU order.
-* The oldest idle objects reside on the inactive list, which is in
-* retirement order. The next objects to retire are those in flight,
-* on the active list, again in retirement order.
+* The goal is to evict objects and amalgamate space in rough LRU order.
+* Since both active and inactive objects reside on the same list,
+* in a mix of creation and last scanned order, as we process the list
+* we sort it into inactive/active, which keeps the active portion
+* in a rough MRU order.
*
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check for hangs allowed
Check we can reset the GPU before running the reset test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Different meaning of flags, it's not the ring id!
---
tests/perf_pmu.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 21292bf3a..c9881e59f 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1812,8 +1812,13 @@ igt_main
accuracy(fd, e, pct[i], 10);
}
- igt_subtest_f("busy-hang-%s", e->name)
+ igt_subtest_f("busy-hang-%s", e->name) {
+ igt_hang_t hang = igt_allow_hang(fd, 0, 0);
+
single(fd, e, TEST_BUSY | FLAG_HANG);
+
+ igt_disallow_hang(fd, hang);
+ }
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Check for hangs allowed
Check we can reset the GPU before running the reset test.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/perf_pmu.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 21292bf3a..1fdbcc154 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -1812,8 +1812,14 @@ igt_main
accuracy(fd, e, pct[i], 10);
}
- igt_subtest_f("busy-hang-%s", e->name)
+ igt_subtest_f("busy-hang-%s", e->name) {
+ igt_hang_t hang =
+ igt_allow_hang(fd, 0, e2ring(fd, e));
+
single(fd, e, TEST_BUSY | FLAG_HANG);
+
+ igt_disallow_hang(fd, hang);
+ }
}
/**
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/28] drm/i915: Stop tracking MRU activity on VMA
On 28/01/2019 01:02, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracking is less agreeable. One solution is not to do any
MRU tracking and do a simple coarse evaluation during eviction of
active/inactive, with a loose temporal ordering of last
insertion/evaluation. That keeps all the locking constrained to when we
are manipulating the VM itself, neatly avoiding the tricky handling of
possible recursive locking during execbuf and elsewhere.
Note that discarding the MRU (currently implemented as a pair of lists,
to avoid scanning the active list for a NONBLOCKING search) is unlikely
to impact upon our efficiency to reclaim VM space (where we think a LRU
model is best) as our current strategy is to use random idle replacement
first before doing a search, and over time the use of softpinned 48b
per-ppGTT is growing (thereby eliminating any need to perform any eviction
searches, in theory at least) with the remaining users being found on
much older devices (gen2-gen6).
v2: Changelog and commentary rewritten to elaborate on the duality of a
single list being both an inactive and active list.
v3: Consolidate bool parameters into a single set of flags; don't
comment on the duality of a single variable being a multiplicity of
bits.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_gem.c | 10 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 87 +++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 26 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 8 +-
drivers/gpu/drm/i915/i915_gem_stolen.c| 3 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 42 -
drivers/gpu/drm/i915/i915_vma.c | 9 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
10 files changed, 95 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dcbe644869b3..12a0a80bc989 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -255,10 +255,7 @@ i915_gem_get_aperture_ioctl(struct drm_device *dev, void
*data,
pinned = ggtt->vm.reserved;
mutex_lock(>struct_mutex);
- list_for_each_entry(vma, >vm.active_list, vm_link)
- if (i915_vma_is_pinned(vma))
- pinned += vma->node.size;
- list_for_each_entry(vma, >vm.inactive_list, vm_link)
+ list_for_each_entry(vma, >vm.bound_list, vm_link)
if (i915_vma_is_pinned(vma))
pinned += vma->node.size;
mutex_unlock(>struct_mutex);
@@ -1541,13 +1538,10 @@ static void i915_gem_object_bump_inactive_ggtt(struct
drm_i915_gem_object *obj)
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
for_each_ggtt_vma(vma, obj) {
- if (i915_vma_is_active(vma))
- continue;
-
if (!drm_mm_node_allocated(>node))
continue;
- list_move_tail(>vm_link, >vm->inactive_list);
+ list_move_tail(>vm_link, >vm->bound_list);
}
i915 = to_i915(obj->base.dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index f6855401f247..d76839670632 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -126,31 +126,25 @@ i915_gem_evict_something(struct i915_address_space *vm,
struct drm_i915_private *dev_priv = vm->i915;
struct drm_mm_scan scan;
struct list_head eviction_list;
- struct list_head *phases[] = {
- >inactive_list,
- >active_list,
- NULL,
- }, **phase;
struct i915_vma *vma, *next;
struct drm_mm_node *node;
enum drm_mm_insert_mode mode;
+ struct i915_vma *active;
int ret;
lockdep_assert_held(>i915->drm.struct_mutex);
trace_i915_gem_evict(vm, min_size, alignment, flags);
/*
-* The goal is to evict objects and amalgamate space in LRU order.
-* The oldest idle objects reside on the inactive list, which is in
-* retirement order. The next objects to retire are those in flight,
-* on the active list, again in retirement order.
+* The goal is to evict objects and amalgamate space in rough LRU order.
+* Since both active and inactive objects reside on the same list,
+* in a mix of creation and last scanned order, as we process the list
+* we sort it into inactive/active, which keeps the active
Re: [Intel-gfx] [PATCH 01/28] drm/i915: Wait for a moment before forcibly resetting the device
Quoting Mika Kuoppala (2019-01-28 09:24:12) > Chris Wilson writes: > > > During igt, we ask to reset the device if any requests are still > > outstanding at the end of a test, as this quickly kills off any > > erroneous hanging request streams that may escape a test. However, since > > it may take the device a few milliseconds to flush itself after the end > > of a normal test, *cough* guc *cough*, we may accidentally tell the > > device to reset itself after it idles. If we wait a moment, our usual > > I915_IDLE_ENGINES_TIMEOUT of 200ms (seems a bit high, but still better > > than umpteen hangchecks!), we can differentiate better between a stuck > > engine and a healthy one, and so avoid prematurely forcing the reset and > > any extra complications that may entail. > > > > Signed-off-by: Chris Wilson > > Cc: Mika Kuoppala > > --- > > drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > > b/drivers/gpu/drm/i915/i915_debugfs.c > > index 3b995f9fdc06..e46de507fea2 100644 > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > @@ -4051,7 +4051,8 @@ i915_drop_caches_set(void *data, u64 val) > > val, val & DROP_ALL); > > wakeref = intel_runtime_pm_get(i915); > > > > - if (val & DROP_RESET_ACTIVE && !intel_engines_are_idle(i915)) > > + if (val & DROP_RESET_ACTIVE && > > + wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) > > i915_gem_set_wedged(i915); > > Some of the compilications have been welcomed. But it is still > better to try to entail them into tests explicitly rather > than using indirect test harness stress. > > Reviewed-by: Mika Kuoppala Pushed to mask potential problems in *-guc BAT. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen
The patch look ok to me.
On Fri, 2019-01-11 at 19:49 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
> which misprograms the hardware badly when encountering a suitably
> high resolution display. The programmed pipe timings are somewhat
> bonkers and the DPLL is totally misprogrammed (P divider == 0).
> That will result in atomic commit timeouts as apparently the pipe
> is sufficiently stuck to not signal vblank interrupts.
>
> IIRC something like this was also observed on some other SNB
> machine years ago (might have been a Dell XPS 8300) but a BIOS
> update cured it. Sadly looks like this was never fixed for the
> ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still
> broken.
>
> The quickest way to deal with this seems to be to shut down
> the pipe+ports+DPLL. Unfortunately doing this during the
> normal sanitization phase isn't quite soon enough as we
> already spew several WARNs about the bogus hardware state.
> But it's better than hanging the boot for a few dozen seconds.
> Since this is limited to a few old machines it doesn't seem
> entirely worthwile to try and rework the readout+sanitization
> code to handle it more gracefully.
>
> v2: Fix potential NULL deref (kbuild test robot)
> Constify has_bogus_dpll_config()
>
> Cc: sta...@vger.kernel.org # v4.20+
> Cc: Daniel Kamil Kozar
> Reported-by: Daniel Kamil Kozar
> Tested-by: Daniel Kamil Kozar
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245
> Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup
> with external display")
Reviewed-by: Mika Kahola
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 50
>
> 1 file changed, 44 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5dc0de89c49e..6cd6048b4731 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15438,16 +15438,45 @@ static void intel_sanitize_crtc(struct
> intel_crtc *crtc,
> }
> }
>
> +static bool has_bogus_dpll_config(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state-
> >base.crtc->dev);
> +
> + /*
> + * Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram
> + * the hardware when a high res displays plugged in. DPLL P
> + * divider is zero, and the pipe timings are bonkers. We'll
> + * try to disable everything in that case.
> + *
> + * FIXME would be nice to be able to sanitize this state
> + * without several WARNs, but for now let's take the easy
> + * road.
> + */
> + return IS_GEN(dev_priv, 6) &&
> + crtc_state->base.active &&
> + crtc_state->shared_dpll &&
> + crtc_state->port_clock == 0;
> +}
> +
> static void intel_sanitize_encoder(struct intel_encoder *encoder)
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct intel_connector *connector;
> + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> + struct intel_crtc_state *crtc_state = crtc ?
> + to_intel_crtc_state(crtc->base.state) : NULL;
>
> /* We need to check both for a crtc link (meaning that the
>* encoder is active and trying to read from a pipe) and the
>* pipe itself being active. */
> - bool has_active_crtc = encoder->base.crtc &&
> - to_intel_crtc(encoder->base.crtc)->active;
> + bool has_active_crtc = crtc_state &&
> + crtc_state->base.active;
> +
> + if (crtc_state && has_bogus_dpll_config(crtc_state)) {
> + DRM_DEBUG_KMS("BIOS has misprogrammed the hardware.
> Disabling pipe %c\n",
> + pipe_name(crtc->pipe));
> + has_active_crtc = false;
> + }
>
> connector = intel_encoder_find_connector(encoder);
> if (connector && !has_active_crtc) {
> @@ -15458,16 +15487,25 @@ static void intel_sanitize_encoder(struct
> intel_encoder *encoder)
> /* Connector is active, but has no active pipe. This is
>* fallout from our resume register restoring. Disable
>* the encoder manually again. */
> - if (encoder->base.crtc) {
> - struct drm_crtc_state *crtc_state = encoder-
> >base.crtc->state;
> + if (crtc_state) {
> + struct drm_encoder *best_encoder;
>
> DRM_DEBUG_KMS("[ENCODER:%d:%s] manually
> disabled\n",
> encoder->base.base.id,
> encoder->base.name);
> +
> + /* avoid oopsing in case the hooks consult
> best_encoder */
> + best_encoder = connector->base.state-
> >best_encoder;
> +
Re: [Intel-gfx] [PATCH 01/28] drm/i915: Wait for a moment before forcibly resetting the device
Chris Wilson writes: > During igt, we ask to reset the device if any requests are still > outstanding at the end of a test, as this quickly kills off any > erroneous hanging request streams that may escape a test. However, since > it may take the device a few milliseconds to flush itself after the end > of a normal test, *cough* guc *cough*, we may accidentally tell the > device to reset itself after it idles. If we wait a moment, our usual > I915_IDLE_ENGINES_TIMEOUT of 200ms (seems a bit high, but still better > than umpteen hangchecks!), we can differentiate better between a stuck > engine and a healthy one, and so avoid prematurely forcing the reset and > any extra complications that may entail. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_debugfs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 3b995f9fdc06..e46de507fea2 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -4051,7 +4051,8 @@ i915_drop_caches_set(void *data, u64 val) > val, val & DROP_ALL); > wakeref = intel_runtime_pm_get(i915); > > - if (val & DROP_RESET_ACTIVE && !intel_engines_are_idle(i915)) > + if (val & DROP_RESET_ACTIVE && > + wait_for(intel_engines_are_idle(i915), I915_IDLE_ENGINES_TIMEOUT)) > i915_gem_set_wedged(i915); Some of the compilications have been welcomed. But it is still better to try to entail them into tests explicitly rather than using indirect test harness stress. Reviewed-by: Mika Kuoppala > > /* No need to check and wait for gpu resets, only libdrm auto-restarts > -- > 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
[Intel-gfx] ✓ Fi.CI.BAT: success for Add Colorspace connector property interface (rev7)
== Series Details ==
Series: Add Colorspace connector property interface (rev7)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5490 -> Patchwork_12056
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/47132/revisions/7/mbox/
Known issues
Here are the changes found in Patchwork_12056 that come from known issues:
### IGT changes ###
Issues hit
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL [fdo#108511]
Possible fixes
* igt@gem_exec_reloc@basic-gtt-noreloc:
- fi-skl-guc: {SKIP} [fdo#109271] -> PASS +81
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (43 -> 35)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-pnv-d510 fi-icl-y
Build changes
-
* Linux: CI_DRM_5490 -> Patchwork_12056
CI_DRM_5490: 310d38b4b51e06ef7096716430e2ef262c3e45fe @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4790: dcdf4b04e16312f8f52ad389388d834f9d74b8f0 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12056: 7195c72c35da94b4b353ccbd62a7c32281c4bb79 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7195c72c35da drm/i915: Attach colorspace property and enable modeset
997f79fd2b2f drm: Add colorspace connector property
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12056/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add Colorspace connector property interface (rev7)
== Series Details == Series: Add Colorspace connector property interface (rev7) URL : https://patchwork.freedesktop.org/series/47132/ State : warning == Summary == $ dim checkpatch origin/drm-tip 997f79fd2b2f drm: Add colorspace connector property 7195c72c35da drm/i915: Attach colorspace property and enable modeset -:117: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #117: FILE: drivers/gpu/drm/i915/intel_connector.c:319: + if (!drm_mode_create_colorspace_property(connector, + gen10_hdmi_colorspaces, -:120: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #120: FILE: drivers/gpu/drm/i915/intel_connector.c:322: + drm_object_attach_property(>base, + connector->colorspace_property, 0); -:123: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #123: FILE: drivers/gpu/drm/i915/intel_connector.c:325: + if (!drm_mode_create_colorspace_property(connector, + legacy_hdmi_colorspaces, -:126: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #126: FILE: drivers/gpu/drm/i915/intel_connector.c:328: + drm_object_attach_property(>base, + connector->colorspace_property, 0); total: 0 errors, 0 warnings, 4 checks, 117 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Fix bits vs. bytes mixup in dbuf block size computation
On Fri, 2018-12-21 at 19:14 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The spec used to say "8bpp" which someone took to mean 8 bytes per > pixel when in fact it was supposed to be 8 bits per pixel. The > spec has been updated to make it more clear now. Fix the code > to match. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 0aac7e7b660f..55a1c577f060 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4618,7 +4618,7 @@ skl_compute_plane_wm_params(const struct > intel_crtc_state *cstate, >intel_p > state); > > if (INTEL_GEN(dev_priv) >= 11 && > - fb->modifier == I915_FORMAT_MOD_Yf_TILED && wp->cpp == > 8) > + fb->modifier == I915_FORMAT_MOD_Yf_TILED && wp->cpp == > 1) > wp->dbuf_block_size = 256; > else > wp->dbuf_block_size = 512; Interesting how this small misunderstanding could affect our bugs previously. Reviewed-by: Stanislav Lisovskiy -- Best Regards, Lisovskiy Stanislav ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Don't ignore level 0 lines watermark for glk+
On Fri, 2018-12-21 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On glk+ the level 0 lines watermark actually matters. Do not ignore
> it.
> And while at it let's change things so that we always program a
> consistnet 0 to the register when the lines watermarks is ignored
> by the hardware.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 2a6ffb8b975a..d132ef10fa60 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4675,6 +4675,15 @@ skl_compute_plane_wm_params(const struct
> intel_crtc_state *cstate,
> return 0;
> }
>
> +static bool skl_wm_has_lines(struct drm_i915_private *dev_priv, int
> level)
> +{
> + if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> + return true;
> +
> + /* The number of lines are ignored for the level 0
> watermark. */
> + return level > 0;
> +}
> +
> static void skl_compute_plane_wm(const struct intel_crtc_state
> *cstate,
>const struct intel_plane_state
> *intel_pstate,
>int level,
> @@ -4757,8 +4766,10 @@ static void skl_compute_plane_wm(const struct
> intel_crtc_state *cstate,
> }
> }
>
> - /* The number of lines are ignored for the level 0
> watermark. */
> - if (level > 0 && res_lines > 31)
> + if (!skl_wm_has_lines(dev_priv, level))
> + res_lines = 0;
> +
> + if (res_lines > 31)
> return;
>
> /*
Reviewed-by: Stanislav Lisovskiy
--
Best Regards,
Lisovskiy Stanislav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/9] drm/i915: Reinstate an early latency==0 check for skl+
On Fri, 2018-12-21 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I thought we could remove all the early latency==0 checks
> and rely on skl_wm_method{1,2}() checking for it. But
> skl_compute_plane_wm() applies a bunch of workarounds to bump
> up the latency before calling those guys so clearly it won't
> end up doing the right thing. Also not sure if the calculations
> based on the method1/2 results are safe agaisnt overflows so
> it might not work all that well in any case. Let's put the
> early check back.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index d132ef10fa60..0aac7e7b660f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4701,6 +4701,9 @@ static void skl_compute_plane_wm(const struct
> intel_crtc_state *cstate,
> to_intel_atomic_state(cstate->base.state);
> bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
>
> + if (latency == 0)
> + return;
> +
> /* Display WA #1141: kbl,cfl */
> if ((IS_KABYLAKE(dev_priv) || IS_COFFEELAKE(dev_priv) ||
> IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_B0)) &&
Reviewed-by: Stanislav Lisovskiy
--
Best Regards,
Lisovskiy Stanislav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7 2/2] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Added Platform specific colorspace enums and called the
property creation helper using the same.
v6: Addressed Shashank's review comments.
v7: Rebase
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 63 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 19 ++
4 files changed, 84 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..76b7114 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_state->colorspace != old_state->colorspace ||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..114fcf2 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -30,6 +30,48 @@
#include "intel_drv.h"
#include "i915_drv.h"
+static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "ITU_601" },
+ { COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_OPRGB, "opRGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+ /* Colorimetry based on ITU-R BT.2020 */
+ { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
+static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "ITU_601" },
+ { COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_OPRGB, "opRGB" },
+};
+
int intel_connector_init(struct intel_connector *connector)
{
struct intel_digital_connector_state *conn_state;
@@ -265,3 +307,24 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct
[Intel-gfx] [v7 0/2] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Driver will expose the platform supported colorspaces, however sink supported colorspaces should be retrieved by userspace from EDID. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list based on the colorspaces supported by the respective protocol standard. Handled the default case more efficiently. v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. Uma Shankar (2): drm: Add colorspace connector property drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 79 ++ drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 63 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 19 include/drm/drm_connector.h| 17 include/uapi/drm/drm_mode.h| 32 ++ 8 files changed, 216 insertions(+) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7 1/2] drm: Add colorspace connector property
Create a new connector property to program colorspace to sink devices.
Modern sink devices support more than 1 type of colorspace like 601,
709, BT2020 etc. This helps to switch based on content type which is
to be displayed. The decision lies with compositors as to in which
scenarios, a particular colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Driver will expose the platform supported colorspaces,
however sink supported colorspaces should be retrieved by userspace
from EDID.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 95 +++
include/drm/drm_connector.h | 17 +++
include/uapi/drm/drm_mode.h | 32 +
4 files changed, 148 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8475396..eafa643 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+/* List of HDMI Colorspaces supported */
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { COLORIMETRY_ITU_601, "ITU_601" },
+ { COLORIMETRY_ITU_709, "ITU_709" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+ /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+ { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 [33] */
+ { COLORIMETRY_OPYCC_601, "opYCC_601" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { COLORIMETRY_OPRGB,
[Intel-gfx] [PATCH] drm/i915: Allocate active tracking nodes from a slabcache
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and keep track of inflight nodes so we can reap the
stale entries upon parking (thereby trimming our memory usage).
Signed-off-by: Chris Wilson
---
Move i915_gt_active_fini() out of struct_mutex for mock device teardown,
beware the rcu_barrier() inside kmem_cache_destroy.
---
drivers/gpu/drm/i915/i915_active.c| 55 ---
drivers/gpu/drm/i915/i915_active.h| 29 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 16 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 3 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 3 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 6 ++
8 files changed, 100 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index e0182e19cb8b..3c7abbde42ac 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -7,7 +7,9 @@
#include "i915_drv.h"
#include "i915_active.h"
-#define BKL(ref) (&(ref)->i915->drm.struct_mutex)
+#define i915_from_gt(x) \
+ container_of(x, struct drm_i915_private, gt.active_refs)
+#define BKL(ref) (_from_gt((ref)->gt)->drm.struct_mutex)
struct active_node {
struct i915_gem_active base;
@@ -79,11 +81,11 @@ active_instance(struct i915_active *ref, u64 idx)
p = >rb_left;
}
- node = kmalloc(sizeof(*node), GFP_KERNEL);
+ node = kmem_cache_alloc(ref->gt->slab_cache, GFP_KERNEL);
/* kmalloc may retire the ref->last (thanks shrinker)! */
if (unlikely(!i915_gem_active_raw(>last, BKL(ref {
- kfree(node);
+ kmem_cache_free(ref->gt->slab_cache, node);
goto out;
}
@@ -94,6 +96,9 @@ active_instance(struct i915_active *ref, u64 idx)
node->ref = ref;
node->timeline = idx;
+ if (RB_EMPTY_ROOT(>tree))
+ list_add(>active_link, >gt->active_refs);
+
rb_link_node(>node, parent, p);
rb_insert_color(>node, >tree);
@@ -119,11 +124,11 @@ active_instance(struct i915_active *ref, u64 idx)
return >last;
}
-void i915_active_init(struct drm_i915_private *i915,
+void i915_active_init(struct i915_gt_active *gt,
struct i915_active *ref,
void (*retire)(struct i915_active *ref))
{
- ref->i915 = i915;
+ ref->gt = gt;
ref->retire = retire;
ref->tree = RB_ROOT;
init_request_active(>last, last_retire);
@@ -161,6 +166,7 @@ void i915_active_release(struct i915_active *ref)
int i915_active_wait(struct i915_active *ref)
{
+ struct kmem_cache *slab = ref->gt->slab_cache;
struct active_node *it, *n;
int ret;
@@ -168,15 +174,19 @@ int i915_active_wait(struct i915_active *ref)
if (ret)
return ret;
+ if (RB_EMPTY_ROOT(>tree))
+ return 0;
+
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
ret = i915_gem_active_retire(>base, BKL(ref));
if (ret)
return ret;
GEM_BUG_ON(i915_gem_active_isset(>base));
- kfree(it);
+ kmem_cache_free(slab, it);
}
ref->tree = RB_ROOT;
+ list_del(>active_link);
return 0;
}
@@ -210,15 +220,46 @@ int i915_request_await_active(struct i915_request *rq,
struct i915_active *ref)
void i915_active_fini(struct i915_active *ref)
{
+ struct kmem_cache *slab = ref->gt->slab_cache;
struct active_node *it, *n;
+ lockdep_assert_held(BKL(ref));
GEM_BUG_ON(i915_gem_active_isset(>last));
+ if (RB_EMPTY_ROOT(>tree))
+ return;
+
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
GEM_BUG_ON(i915_gem_active_isset(>base));
- kfree(it);
+ kmem_cache_free(slab, it);
}
ref->tree = RB_ROOT;
+ list_del(>active_link);
+}
+
+int i915_gt_active_init(struct i915_gt_active *gt)
+{
+ gt->slab_cache = KMEM_CACHE(active_node, SLAB_HWCACHE_ALIGN);
+ if (!gt->slab_cache)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(>active_refs);
+
+ return 0;
+}
+
+void i915_gt_active_park(struct i915_gt_active *gt)
+{
+ struct i915_active *it, *n;
+
+ list_for_each_entry_safe(it, n, >active_refs, active_link)
+ i915_active_fini(it);
+}
+
+void i915_gt_active_fini(struct i915_gt_active *gt)
+{
+ GEM_BUG_ON(!list_empty(>active_refs));
+ kmem_cache_destroy(gt->slab_cache);
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index 0057b84565f7..eed34e8903fc 100644
---
