[Intel-gfx] [PATCH] drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
Inside the signal handler, we expect the requests to be ordered by their breadcrumb such that no later request may be complete if we find an earlier incomplete. Add an assert to check that the next breadcrumb should not be logically before the current. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c index 3cbffd400b1b..a6ffb25f72a2 100644 --- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c @@ -99,6 +99,12 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs *engine) struct i915_request *rq = list_entry(pos, typeof(*rq), signal_link); + GEM_BUG_ON(next != &ce->signals && + i915_seqno_passed(rq->fence.seqno, +list_entry(next, + typeof(*rq), + signal_link)->fence.seqno)); + if (!__request_completed(rq)) 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 5/6] drm/i915: Remove inline from sseu helper functions
On Wed, 01 May 2019, "Summers, Stuart" wrote: > On Wed, 2019-05-01 at 14:19 -0700, Daniele Ceraolo Spurio wrote: >> >> On 5/1/19 2:04 PM, Summers, Stuart wrote: >> > On Wed, 2019-05-01 at 13:04 -0700, Daniele Ceraolo Spurio wrote: >> > > Can you elaborate a bit more on what's the rationale for this? do >> > > you just want to avoid having too many inlines since the paths >> > > they're used in are not critical, or do you have some more >> > > functional reason? This is not a critic to the patch, I just >> > > want to understand where you're coming from ;) >> > >> > This was a request from Jani Nikula in a previous series update. I >> > don't have a strong preference either way personally. If you don't >> > have any major concerns, I'd prefer to keep the series as-is to >> > prevent too much thrash here, but let me know. >> > >> >> No concerns, just please update the commit message to explain that >> we're moving them because there is no need for them to be inline >> since they're not on a critical path where we need preformance. > > Sounds great. I've become critical of superfluous inlines. They break the abstraction by exposing the internals in the header, and make the interdependencies of headers harder to resolve. As the driver keeps growing and more people contribute to it, I think we need to pay more attention on how we structure the source. To this end we've added new gt/ subdir, are about to add gem/ and likely display/ too before long, and we've significantly split off the monster i915_drv.h and intel_drv.h headers. Obviously inlines have their place and purpose, but I think we sprinkle them a bit too eagerly without paying attention. I like the patch. Acked-by: Jani Nikula -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Engine discovery query (rev10)
== Series Details == Series: drm/i915: Engine discovery query (rev10) URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == CI Bug Log - changes from CI_DRM_6025 -> Patchwork_12932 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/39958/revisions/10/mbox/ Known issues Here are the changes found in Patchwork_12932 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][1] -> [INCOMPLETE][2] ([fdo#108602] / [fdo#108744]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html * igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size: - fi-glk-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#103359] / [k.org#198133]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-glk-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/fi-glk-dsi/igt@kms_cursor_leg...@basic-flip-before-cursor-varying-size.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@gem_ctx_create@basic-files: - fi-icl-y: [INCOMPLETE][7] ([fdo#107713] / [fdo#109100]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-icl-y/igt@gem_ctx_cre...@basic-files.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/fi-icl-y/igt@gem_ctx_cre...@basic-files.html * igt@i915_selftest@live_hangcheck: - fi-bsw-kefka: [INCOMPLETE][9] ([fdo#105876]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html [fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359 [fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 [k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133 Participating hosts (50 -> 45) -- Additional (2): fi-icl-u2 fi-apl-guc Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper Build changes - * Linux: CI_DRM_6025 -> Patchwork_12932 CI_DRM_6025: 60fc981bcf66e011011756e167e47cc4d4bebc10 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4971: fc5e0467eb6913d21ad932aa8a31c77fdb5a9c77 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12932: 48c015259183d3799ae88a70031de3bf52a06a10 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 48c015259183 drm/i915: Engine discovery query == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/ ___ 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 [v3,1/4] drm/i915: Fix the pipe state timing mismatch warnings
== Series Details == Series: series starting with [v3,1/4] drm/i915: Fix the pipe state timing mismatch warnings URL : https://patchwork.freedesktop.org/series/60186/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4f4166d5345c drm/i915: Fix the pipe state timing mismatch warnings -:48: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #48: FILE: drivers/gpu/drm/i915/icl_dsi.c:1223: + +} total: 0 errors, 0 warnings, 1 checks, 41 lines checked acb46e6ef365 drm/i915: Refactor bdw_get_pipemisc_bpp 387ba833429c drm/i915: Fix pipe config mismatch for bpp, output format 2538e2d41f5e drm/i915: Fix pixel clock and crtc clock config mismatch ___ 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 [v3,1/4] drm/i915: Fix the pipe state timing mismatch warnings
== Series Details ==
Series: series starting with [v3,1/4] drm/i915: Fix the pipe state timing
mismatch warnings
URL : https://patchwork.freedesktop.org/series/60186/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6025 -> Patchwork_12933
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/60186/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12933:
### 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-s4-devices:
- {fi-icl-dsi}: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-icl-dsi/igt@gem_exec_susp...@basic-s4-devices.html
* igt@runner@aborted:
- {fi-icl-dsi}: [FAIL][2] ([fdo#109593]) -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-icl-dsi/igt@run...@aborted.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-icl-dsi/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_12933 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][4] -> [INCOMPLETE][5] ([fdo#107718])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_contexts:
- fi-skl-gvtdvm: [PASS][6] -> [DMESG-FAIL][7] ([fdo#110235])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-icl-y: [INCOMPLETE][8] ([fdo#107713] / [fdo#109100]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-icl-y/igt@gem_ctx_cre...@basic-files.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-icl-y/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live_hangcheck:
- fi-bsw-kefka: [INCOMPLETE][10] ([fdo#105876]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [INCOMPLETE][12] ([fdo#107807]) -> [SKIP][13]
([fdo#109271])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109593]: https://bugs.freedesktop.org/show_bug.cgi?id=109593
[fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
Participating hosts (50 -> 45)
--
Additional (2): fi-icl-u2 fi-apl-guc
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper
Build changes
-
* Linux: CI_DRM_6025 -> Patchwork_12933
CI_DRM_6025: 60fc981bcf66e011011756e167e47cc4d4bebc10 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4971: fc5e0467eb6913d21ad932aa8a31c77fdb5a9c77 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12933: 2538e2d41f5e7870919958d5fc050743f8ea39d4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2538e2d41f5e drm/i915: Fix pixel clock and crtc clock config mismatch
387ba833429c drm/i915: Fix pipe config mismatch for bpp, output format
acb46e6ef365 drm/i915: Refactor bdw_get_pipemisc_bpp
4f4166d5345c drm/i915: Fix the pipe state timing mismatch warnings
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Use mul_u32_u32() more (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Use mul_u32_u32() more (rev2) URL : https://patchwork.freedesktop.org/series/59180/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12909_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12909_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12909_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_12909_full: ### IGT changes ### Possible regressions * igt@gem_fence_thrash@bo-write-verify-threaded-y: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@gem_fence_thr...@bo-write-verify-threaded-y.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl3/igt@gem_fence_thr...@bo-write-verify-threaded-y.html * igt@syncobj_wait@wait-for-submit-snapshot: - shard-skl: NOTRUN -> [INCOMPLETE][3] +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl2/igt@syncobj_w...@wait-for-submit-snapshot.html Known issues Here are the changes found in Patchwork_12909_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([fdo#107807]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@i915_pm_...@basic-rte.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl3/igt@i915_pm_...@basic-rte.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][6] -> [FAIL][7] ([fdo#103184] / [fdo#103232]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([fdo#104108] / [fdo#107773]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl5/igt@kms_fbcon_...@psr-suspend.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl4/igt@kms_fbcon_...@psr-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][10] -> [FAIL][11] ([fdo#108040]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: [PASS][12] -> [FAIL][13] ([fdo#103167]) +5 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb1/igt@kms_frontbuffer_track...@fbc-stridechange.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-iclb5/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-iclb: [PASS][14] -> [INCOMPLETE][15] ([fdo#107713] / [fdo#110036 ]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb1/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-iclb1/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][16] -> [DMESG-WARN][17] ([fdo#108566]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][18] -> [FAIL][19] ([fdo#108145]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb2/igt@k
Re: [Intel-gfx] [PATCH v4] drm/i915: Corrupt DSI picture fix for GeminiLake
On Tue, 30 Apr 2019, Stanislav Lisovskiy wrote:
> Currently due to regression CI machine
> displays show corrupt picture.
> Problem is when CDCLK is as low as 79200, picture gets
> unstable, while DSI and DE pll values were
> confirmed to be correct.
> Limiting to 158400 as agreed with Ville.
>
> We could not come up with any better solution
> yet, as PLL divider values both for MIPI(DSI PLL) and
> CDCLK(DE PLL) are correct, however seems that due to some
> boundary conditions, when clocking is too low we get
> wrong timings for DSI display.
> Similar workaround exists for VLV though, so just
> took similar condition into use. At least that way
> GLK platform will start to be usable again, with
> current drm-tip.
>
> v2: Fixed commit subject as suggested.
>
> v3: Added generic bugs(crc failures, screen not init
> for GLK DSI which might be affected).
>
> v4: Added references tag for bugs affected.
>
> Signed-off-by: Stanislav Lisovskiy
> Acked-by: Ville Syrjälä
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109267
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103184
Pushed, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c
> b/drivers/gpu/drm/i915/intel_cdclk.c
> index ae40a8679314..2b23f8500362 100644
> --- a/drivers/gpu/drm/i915/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/intel_cdclk.c
> @@ -2277,6 +2277,15 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
> IS_VALLEYVIEW(dev_priv))
> min_cdclk = max(32, min_cdclk);
>
> + /*
> + * On Geminilake once the CDCLK gets as low as 79200
> + * picture gets unstable, despite that values are
> + * correct for DSI PLL and DE PLL.
> + */
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) &&
> + IS_GEMINILAKE(dev_priv))
> + min_cdclk = max(158400, min_cdclk);
> +
> if (min_cdclk > dev_priv->max_cdclk_freq) {
> DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n",
> min_cdclk, dev_priv->max_cdclk_freq);
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Corrupt DSI picture fix for GeminiLake (rev3)
== Series Details == Series: drm/i915: Corrupt DSI picture fix for GeminiLake (rev3) URL : https://patchwork.freedesktop.org/series/60084/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12911_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12911_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12911_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_12911_full: ### IGT changes ### Possible regressions * igt@gem_mocs_settings@mocs-rc6-render: - shard-skl: [PASS][1] -> [INCOMPLETE][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl10/igt@gem_mocs_setti...@mocs-rc6-render.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl8/igt@gem_mocs_setti...@mocs-rc6-render.html * igt@gem_tiled_blits@normal: - shard-skl: NOTRUN -> [INCOMPLETE][3] +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl8/igt@gem_tiled_bl...@normal.html Known issues Here are the changes found in Patchwork_12911_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([fdo#108566]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl6/igt@gem_...@in-flight-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-apl7/igt@gem_...@in-flight-suspend.html * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([fdo#107807]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@i915_pm_...@basic-rte.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@i915_pm_...@basic-rte.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][8] -> [FAIL][9] ([fdo#100368]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-glk7/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-glk6/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][10] -> [FAIL][11] ([fdo#108040]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: [PASS][12] -> [FAIL][13] ([fdo#103167]) +6 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-move: - shard-skl: [PASS][14] -> [FAIL][15] ([fdo#103167]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-move.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-move.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][16] -> [FAIL][17] ([fdo#108145]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][18] -> [FAIL][19] ([fdo#103166]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-y.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb2/igt@kms_psr@psr2_basic.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-iclb3/igt@kms_psr@psr2_basic.html * ig
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf: add struct dma_buf_attach_info v2
== Series Details == Series: dma-buf: add struct dma_buf_attach_info v2 URL : https://patchwork.freedesktop.org/series/60107/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12908_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12908_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12908_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_12908_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-xtiled: - shard-skl: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl4/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-xtiled.html Known issues Here are the changes found in Patchwork_12908_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_fence_thrash@bo-write-verify-threaded-y: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([fdo#110581]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@gem_fence_thr...@bo-write-verify-threaded-y.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl2/igt@gem_fence_thr...@bo-write-verify-threaded-y.html * igt@i915_pm_rpm@i2c: - shard-iclb: [PASS][4] -> [DMESG-WARN][5] ([fdo#109982]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb7/igt@i915_pm_...@i2c.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-iclb2/igt@i915_pm_...@i2c.html * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([fdo#104108] / [fdo#107773]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl10/igt@kms_cursor_...@cursor-128x128-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl7/igt@kms_cursor_...@cursor-128x128-suspend.html * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([fdo#104108]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@kms_cursor_...@cursor-64x64-suspend.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl8/igt@kms_cursor_...@cursor-64x64-suspend.html * igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy: - shard-hsw: [PASS][10] -> [FAIL][11] ([fdo#105767]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-hsw1/igt@kms_cursor_leg...@2x-cursor-vs-flip-legacy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-hsw6/igt@kms_cursor_leg...@2x-cursor-vs-flip-legacy.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][12] -> [FAIL][13] ([fdo#103184] / [fdo#103232]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl5/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_flip@flip-vs-suspend: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([fdo#108566]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl2/igt@kms_f...@flip-vs-suspend.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-apl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-iclb: [PASS][16] -> [INCOMPLETE][17] ([fdo#107713]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb7/igt@kms_flip_til...@flip-changes-tiling.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-iclb8/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][18] -> [FAIL][19] ([fdo#103167]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][20] -> [FAIL][21] ([fdo#103167]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/sha
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Don't skip audio enable if ELD is bogus
== Series Details == Series: series starting with [1/2] drm/i915: Don't skip audio enable if ELD is bogus URL : https://patchwork.freedesktop.org/series/60119/ State : success == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12912_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12912_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@system-suspend-modeset: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#108840]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb7/igt@i915_pm_...@system-suspend-modeset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-iclb4/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl6/igt@i915_susp...@debugfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-apl7/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb2/igt@kms_cursor_...@cursor-128x42-offscreen.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-iclb3/igt@kms_cursor_...@cursor-128x42-offscreen.html * igt@kms_cursor_crc@cursor-256x256-sliding: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-hsw1/igt@kms_cursor_...@cursor-256x256-sliding.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-hsw1/igt@kms_cursor_...@cursor-256x256-sliding.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103184] / [fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-skl4/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#102887] / [fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-glk8/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-glk4/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108040]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-skl4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#110581]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-wc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-skl2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103167]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-plflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-skl4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-plflip-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12912/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar i
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Complete both freed-object passes before draining the workqueue
== Series Details == Series: series starting with [1/3] drm/i915: Complete both freed-object passes before draining the workqueue URL : https://patchwork.freedesktop.org/series/60162/ State : success == Summary == CI Bug Log - changes from CI_DRM_6021_full -> Patchwork_12924_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12924_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_softpin@softpin: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl4/igt@gem_soft...@softpin.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-skl3/igt@gem_soft...@softpin.html * igt@i915_pm_rpm@gem-evict-pwrite: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807] / [fdo#110581]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl7/igt@i915_pm_...@gem-evict-pwrite.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-skl6/igt@i915_pm_...@gem-evict-pwrite.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-apl8/igt@i915_susp...@debugfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-apl5/igt@i915_susp...@debugfs-reader.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-iclb7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([fdo#103540]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-hsw6/igt@kms_f...@flip-vs-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-hsw1/igt@kms_f...@flip-vs-suspend.html - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#109507] / [fdo#110581]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl9/igt@kms_f...@flip-vs-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-skl9/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-msflip-blt: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#106978] / [fdo#110581]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-msflip-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-skl4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-msflip-blt.html * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-glk5/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / [fdo#110036 ]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb1/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-iclb2/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12924/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-glk: [PASS][23] -> [SKIP][24] ([fdo#109271] / [fdo#109278]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-glk9/igt@kms_plane_scal...@pipe-c-scaler-with-pixel-format.html [24]: https://intel-gfx-ci.01.org/
Re: [Intel-gfx] [PATCH] drm/i915/csr: alpha_support doesn't depend on csr or vice versa
On Mon, 29 Apr 2019, Rodrigo Vivi wrote:
> On Mon, Apr 29, 2019 at 05:22:53PM +0300, Jani Nikula wrote:
>> Debug logging should not be dependent on alpha support flag.
>>
>> Cc: Rodrigo Vivi
>> Signed-off-by: Jani Nikula
>
> I agree... this is not the right way to track dependencies.
>
> Reviewed-by: Rodrigo Vivi
Pushed, thanks.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_csr.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_csr.c
>> b/drivers/gpu/drm/i915/intel_csr.c
>> index f43c2a2563a5..4527b9662330 100644
>> --- a/drivers/gpu/drm/i915/intel_csr.c
>> +++ b/drivers/gpu/drm/i915/intel_csr.c
>> @@ -529,8 +529,6 @@ void intel_csr_ucode_init(struct drm_i915_private
>> *dev_priv)
>>
>> if (csr->fw_path == NULL) {
>> DRM_DEBUG_KMS("No known CSR firmware for platform, disabling
>> runtime PM\n");
>> -WARN_ON(!IS_ALPHA_SUPPORT(INTEL_INFO(dev_priv)));
>> -
>> return;
>> }
>>
>> --
>> 2.20.1
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/dp: use logical operators with boolean type
Using arithmetic operators with booleans is confusing. Switch to logical operators. Cc: Paulo Zanoni Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 4e7b8d..ef4992f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5094,7 +5094,7 @@ static void icl_update_tc_port_type(struct drm_i915_private *dev_priv, enum port port = intel_dig_port->base.port; enum tc_port_type old_type = intel_dig_port->tc_type; - WARN_ON(is_legacy + is_typec + is_tbt != 1); + WARN_ON(is_legacy || is_typec || !is_tbt); if (is_legacy) intel_dig_port->tc_type = TC_PORT_LEGACY; -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 0/5] cgroup support for GPU devices
On Wed, May 01, 2019 at 10:04:33AM -0400, Brian Welty wrote: > In containerized or virtualized environments, there is desire to have > controls in place for resources that can be consumed by users of a GPU > device. This RFC patch series proposes a framework for integrating > use of existing cgroup controllers into device drivers. > The i915 driver is updated in this series as our primary use case to > leverage this framework and to serve as an example for discussion. > > The patch series enables device drivers to use cgroups to control the > following resources within a GPU (or other accelerator device): > * control allocation of device memory (reuse of memcg) Count us (Mellanox) too, our RDMA devices are exposing special and limited in size device memory to the users and we would like to provide an option to use cgroup to control its exposure. > and with future work, we could extend to: > * track and control share of GPU time (reuse of cpu/cpuacct) > * apply mask of allowed execution engines (reuse of cpusets) > > Instead of introducing a new cgroup subsystem for GPU devices, a new > framework is proposed to allow devices to register with existing cgroup > controllers, which creates per-device cgroup_subsys_state within the > cgroup. This gives device drivers their own private cgroup controls > (such as memory limits or other parameters) to be applied to device > resources instead of host system resources. > Device drivers (GPU or other) are then able to reuse the existing cgroup > controls, instead of inventing similar ones. > > Per-device controls would be exposed in cgroup filesystem as: > mount//.devices// > such as (for example): > mount//memory.devices//memory.max > mount//memory.devices//memory.current > mount//cpu.devices//cpu.stat > mount//cpu.devices//cpu.weight > > The drm/i915 patch in this series is based on top of other RFC work [1] > for i915 device memory support. > > AMD [2] and Intel [3] have proposed related work in this area within the > last few years, listed below as reference. This new RFC reuses existing > cgroup controllers and takes a different approach than prior work. > > Finally, some potential discussion points for this series: > * merge proposed .devices into a single devices directory? > * allow devices to have multiple registrations for subsets of resources? > * document a 'common charging policy' for device drivers to follow? > > [1] https://patchwork.freedesktop.org/series/56683/ > [2] https://lists.freedesktop.org/archives/dri-devel/2018-November/197106.html > [3] https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html > > > Brian Welty (5): > cgroup: Add cgroup_subsys per-device registration framework > cgroup: Change kernfs_node for directories to store > cgroup_subsys_state > memcg: Add per-device support to memory cgroup subsystem > drm: Add memory cgroup registration and DRIVER_CGROUPS feature bit > drm/i915: Use memory cgroup for enforcing device memory limit > > drivers/gpu/drm/drm_drv.c | 12 + > drivers/gpu/drm/drm_gem.c | 7 + > drivers/gpu/drm/i915/i915_drv.c| 2 +- > drivers/gpu/drm/i915/intel_memory_region.c | 24 +- > include/drm/drm_device.h | 3 + > include/drm/drm_drv.h | 8 + > include/drm/drm_gem.h | 11 + > include/linux/cgroup-defs.h| 28 ++ > include/linux/cgroup.h | 3 + > include/linux/memcontrol.h | 10 + > kernel/cgroup/cgroup-v1.c | 10 +- > kernel/cgroup/cgroup.c | 310 ++--- > mm/memcontrol.c| 183 +++- > 13 files changed, 552 insertions(+), 59 deletions(-) > > -- > 2.21.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Use mul_u32_u32() more (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Use mul_u32_u32() more (rev2) URL : https://patchwork.freedesktop.org/series/59180/ State : success == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12909_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12909_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_fence_thrash@bo-write-verify-threaded-y: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@gem_fence_thr...@bo-write-verify-threaded-y.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl3/igt@gem_fence_thr...@bo-write-verify-threaded-y.html * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@i915_pm_...@basic-rte.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl3/igt@i915_pm_...@basic-rte.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#103184] / [fdo#103232]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107773]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl5/igt@kms_fbcon_...@psr-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl4/igt@kms_fbcon_...@psr-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108040]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb1/igt@kms_frontbuffer_track...@fbc-stridechange.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-iclb5/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#110036 ]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb1/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-iclb1/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb2/igt@kms_psr@psr2_basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-iclb6/igt@kms_psr@psr2_basic.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl1/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-apl1/igt@kms_setm...@basic.html - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-kbl4/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12909/shard-kbl1/igt@kms_setm...@basic.html Possible fixes #
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf: add struct dma_buf_attach_info v2
== Series Details == Series: dma-buf: add struct dma_buf_attach_info v2 URL : https://patchwork.freedesktop.org/series/60107/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12908_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12908_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12908_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_12908_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-xtiled: - shard-skl: NOTRUN -> [DMESG-WARN][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl4/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-xtiled.html Known issues Here are the changes found in Patchwork_12908_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_fence_thrash@bo-write-verify-threaded-y: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([fdo#110581]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@gem_fence_thr...@bo-write-verify-threaded-y.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl2/igt@gem_fence_thr...@bo-write-verify-threaded-y.html * igt@i915_pm_rpm@i2c: - shard-iclb: [PASS][4] -> [DMESG-WARN][5] ([fdo#109982]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb7/igt@i915_pm_...@i2c.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-iclb2/igt@i915_pm_...@i2c.html * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-skl: [PASS][6] -> [INCOMPLETE][7] ([fdo#104108] / [fdo#107773]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl10/igt@kms_cursor_...@cursor-128x128-suspend.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl7/igt@kms_cursor_...@cursor-128x128-suspend.html * igt@kms_cursor_crc@cursor-64x64-suspend: - shard-skl: [PASS][8] -> [INCOMPLETE][9] ([fdo#104108]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@kms_cursor_...@cursor-64x64-suspend.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl8/igt@kms_cursor_...@cursor-64x64-suspend.html * igt@kms_cursor_legacy@2x-cursor-vs-flip-legacy: - shard-hsw: [PASS][10] -> [FAIL][11] ([fdo#105767]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-hsw1/igt@kms_cursor_leg...@2x-cursor-vs-flip-legacy.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-hsw6/igt@kms_cursor_leg...@2x-cursor-vs-flip-legacy.html * igt@kms_draw_crc@draw-method-xrgb2101010-render-xtiled: - shard-skl: [PASS][12] -> [FAIL][13] ([fdo#103184] / [fdo#103232]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl5/igt@kms_draw_...@draw-method-xrgb2101010-render-xtiled.html * igt@kms_flip@flip-vs-suspend: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([fdo#108566]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl2/igt@kms_f...@flip-vs-suspend.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-apl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-iclb: [PASS][16] -> [INCOMPLETE][17] ([fdo#107713]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb7/igt@kms_flip_til...@flip-changes-tiling.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-iclb8/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][18] -> [FAIL][19] ([fdo#103167]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/shard-skl5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][20] -> [FAIL][21] ([fdo#103167]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12908/sha
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Corrupt DSI picture fix for GeminiLake (rev3)
== Series Details == Series: drm/i915: Corrupt DSI picture fix for GeminiLake (rev3) URL : https://patchwork.freedesktop.org/series/60084/ State : success == Summary == CI Bug Log - changes from CI_DRM_6017_full -> Patchwork_12911_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12911_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl6/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-apl7/igt@gem_...@in-flight-suspend.html * igt@gem_mocs_settings@mocs-rc6-render: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#110581]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl10/igt@gem_mocs_setti...@mocs-rc6-render.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl8/igt@gem_mocs_setti...@mocs-rc6-render.html * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl2/igt@i915_pm_...@basic-rte.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@i915_pm_...@basic-rte.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#100368]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-glk7/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-glk6/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108040]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-move: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103167]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-move.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-iclb4/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-iclb2/igt@kms_psr@psr2_basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-iclb3/igt@kms_psr@psr2_basic.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-apl1/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-apl2/igt@kms_setm...@basic.html - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6017/shard-kbl4/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12911/shard-kbl2/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-skl: [PASS][25] -> [INCOMPLETE][26] ([fdo#104108] / [fdo#
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Assert breadcrumbs are correctly ordered in the signal handler
== Series Details == Series: drm/i915: Assert breadcrumbs are correctly ordered in the signal handler URL : https://patchwork.freedesktop.org/series/60187/ State : success == Summary == CI Bug Log - changes from CI_DRM_6025 -> Patchwork_12934 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/60187/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12934 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([fdo#105411] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-snb-2600/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/fi-snb-2600/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] ([fdo#108602] / [fdo#108744] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@gem_ctx_create@basic-files: - fi-icl-y: [INCOMPLETE][7] ([fdo#107713] / [fdo#109100]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-icl-y/igt@gem_ctx_cre...@basic-files.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/fi-icl-y/igt@gem_ctx_cre...@basic-files.html * igt@i915_selftest@live_hangcheck: - fi-bsw-kefka: [INCOMPLETE][9] ([fdo#105876]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html Warnings * igt@i915_pm_rpm@basic-pci-d3-state: - fi-kbl-guc: [INCOMPLETE][11] ([fdo#107807]) -> [INCOMPLETE][12] ([fdo#107807] / [fdo#110581]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html [fdo#105411]: https://bugs.freedesktop.org/show_bug.cgi?id=105411 [fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (50 -> 44) -- Additional (2): fi-icl-u2 fi-apl-guc Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-icl-dsi Build changes - * Linux: CI_DRM_6025 -> Patchwork_12934 CI_DRM_6025: 60fc981bcf66e011011756e167e47cc4d4bebc10 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4971: fc5e0467eb6913d21ad932aa8a31c77fdb5a9c77 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12934: 3a20e2c3cdca8009ba8341b9967448dd1691c7f4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3a20e2c3cdca drm/i915: Assert breadcrumbs are correctly ordered in the signal handler == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Refactor to expand subslice mask (rev7)
== Series Details == Series: Refactor to expand subslice mask (rev7) URL : https://patchwork.freedesktop.org/series/59742/ State : success == Summary == CI Bug Log - changes from CI_DRM_6021_full -> Patchwork_12926_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12926_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@debugfs-reader: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-kbl4/igt@i915_susp...@debugfs-reader.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-kbl7/igt@i915_susp...@debugfs-reader.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-apl4/igt@i915_susp...@fence-restore-untiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-apl2/igt@i915_susp...@fence-restore-untiled.html * igt@kms_cursor_crc@cursor-64x21-sliding: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#110581]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl6/igt@kms_cursor_...@cursor-64x21-sliding.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-skl2/igt@kms_cursor_...@cursor-64x21-sliding.html * igt@kms_draw_crc@draw-method-xrgb-render-xtiled: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-snb1/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-snb4/igt@kms_draw_...@draw-method-xrgb-render-xtiled.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl4/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-skl8/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#110581]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-iclb6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540] / [fdo#110581]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-hsw6/igt@kms_f...@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-hsw1/igt@kms_f...@flip-vs-suspend.html - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#107773] / [fdo#109507] / [fdo#110581]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl9/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-skl9/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#106978] / [fdo#107713] / [fdo#110581]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12926/shard-glk4/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [24]: https://intel-
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/14] drm/i915/hangcheck: Track context changes (rev4)
== Series Details == Series: series starting with [01/14] drm/i915/hangcheck: Track context changes (rev4) URL : https://patchwork.freedesktop.org/series/60153/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6021_full -> Patchwork_12928_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12928_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12928_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_12928_full: ### IGT changes ### Possible regressions * igt@gem_ppgtt@flink-and-close-vma-leak: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb5/igt@gem_pp...@flink-and-close-vma-leak.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-iclb7/igt@gem_pp...@flink-and-close-vma-leak.html * igt@i915_pm_rpm@cursor: - shard-iclb: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb3/igt@i915_pm_...@cursor.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-iclb4/igt@i915_pm_...@cursor.html Known issues Here are the changes found in Patchwork_12928_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-apl8/igt@i915_susp...@debugfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-apl2/igt@i915_susp...@debugfs-reader.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#105363]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-glk3/igt@kms_f...@2x-flip-vs-expired-vblank.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank.html * igt@kms_flip@bo-too-big: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110581]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl4/igt@kms_f...@bo-too-big.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-skl2/igt@kms_f...@bo-too-big.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#110581]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-iclb4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540] / [fdo#110581]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-hsw6/igt@kms_f...@flip-vs-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-hsw1/igt@kms_f...@flip-vs-suspend.html - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#109507] / [fdo#110581]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl9/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-skl5/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip_tiling@flip-to-x-tiled: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#108134]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb1/igt@kms_flip_til...@flip-to-x-tiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-iclb6/igt@kms_flip_til...@flip-to-x-tiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([fdo#104108] / [fdo#106978] / [fdo#110581]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl10/igt@kms_frontbuffer_track...@psr-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12928/shard-skl8/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_plane@pixel-format-pipe-b-pl
[Intel-gfx] [PATCH] drm/i915/execlists: Unshadow MI_USER_INTERRUPT
Given an immediate preemption event on re-enabling arbitration (MI_ARB_ON_OFF | MI_ARB_ENABLE) it appears that the HW may forget about the ongoing MI_USER_INTERRUPT, losing the interrupt in the process. If we happen to be waiting on that interrupt at the time, the system may then grind to a halt. My presumption is that there is an effective shadow inside the CS as it parses and buffers the commands, and if we push the MI_USER_INTERRUPT out of the immediate parse buffer it is not lost by the arbitration check. Testcase: igt/gem_concurrent_blit Signed-off-by: Chris Wilson --- Plausible? I need a few hours to confirm my hunch. -Chris --- drivers/gpu/drm/i915/gt/intel_lrc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index 851e62ddcb87..526cb9231d58 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2271,14 +2271,13 @@ static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs) request->fence.seqno, request->timeline->hwsp_offset, 0); + *cs++ = MI_USER_INTERRUPT; cs = gen8_emit_ggtt_write(cs, intel_engine_next_hangcheck_seqno(request->engine), I915_GEM_HWS_HANGCHECK_ADDR, MI_FLUSH_DW_STORE_INDEX); - - *cs++ = MI_USER_INTERRUPT; *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; request->tail = intel_ring_offset(request, cs); @@ -2297,13 +2296,13 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32 *cs) PIPE_CONTROL_DC_FLUSH_ENABLE | PIPE_CONTROL_FLUSH_ENABLE | PIPE_CONTROL_CS_STALL); + *cs++ = MI_USER_INTERRUPT; cs = gen8_emit_ggtt_write_rcs(cs, intel_engine_next_hangcheck_seqno(request->engine), I915_GEM_HWS_HANGCHECK_ADDR, PIPE_CONTROL_STORE_DATA_INDEX); - *cs++ = MI_USER_INTERRUPT; *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; request->tail = intel_ring_offset(request, cs); -- 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/perf: Refactor oa object to better manage resources
== Series Details == Series: drm/i915/perf: Refactor oa object to better manage resources URL : https://patchwork.freedesktop.org/series/60176/ State : success == Summary == CI Bug Log - changes from CI_DRM_6021_full -> Patchwork_12929_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12929_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@flink: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl3/igt@drm_import_exp...@flink.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-skl6/igt@drm_import_exp...@flink.html * igt@gem_ctx_isolation@rcs0-s3: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-kbl1/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-kbl7/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-apl5/igt@gem_...@in-flight-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-apl4/igt@gem_...@in-flight-suspend.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927] / [fdo#110581]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-apl8/igt@gem_exec_as...@concurrent-writes-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-apl2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108686]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-apl3/igt@gem_tiled_swapp...@non-threaded.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#110581]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-iclb5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-msflip-blt: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#106978] / [fdo#110581]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-msflip-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-skl3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-indfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108] / [fdo#106978] / [fdo#110581]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-skl9/igt@kms_frontbuffer_track...@fbcpsr-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-skl4/igt@kms_frontbuffer_track...@fbcpsr-suspend.html * igt@kms_plane@pixel-format-pipe-b-planes: - shard-glk: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-glk7/igt@kms_pl...@pixel-format-pipe-b-planes.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713] / [fdo#110036 ] / [fdo#110581]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6021/shard-iclb1/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12929/shard-iclb3/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html * igt@kms_plane_scaling@pipe-c-scaler-with-pixel-format: - shard-glk: [PASS][23] -> [SKIP][24] ([fdo#109271] / [fdo#109278]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/
[Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
Framebuffer formats P01x are supported by GLK, but the function which
handles CSC on plane color control register, still expectes the input
buffer to be REC709. This can cause inaccurate output for direct P01x
flips.
This patch checks if the color_encoding property is set to YCBCR_2020,
and enables the corresponding color conversion mode on plane CSC.
PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
Cc: Ville Syrjala
Cc: Maarten Lankhorst
Cc: Uma Shankar
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_display.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dd65d7c521c1..2d4d3128bf1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
to_i915(plane_state->base.plane->dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
- u32 plane_color_ctl = 0;
+ u32 color_ctl = 0;
- plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
- plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
+ color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
+ color_ctl |= glk_plane_color_ctl_alpha(plane_state);
if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
- if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
- plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
- else
- plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+ switch (plane_state->base.color_encoding) {
+ case DRM_COLOR_YCBCR_BT709:
+ color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
+ break;
+ case DRM_COLOR_YCBCR_BT2020:
+ color_ctl |= PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
+ break;
+ default:
+ color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
+ }
if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
- plane_color_ctl |=
PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
+ color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
} else if (fb->format->is_yuv) {
- plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
+ color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
}
- return plane_color_ctl;
+ return color_ctl;
}
static int
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
On Thu, May 02, 2019 at 03:19:42PM +0530, Shashank Sharma wrote:
> Framebuffer formats P01x are supported by GLK, but the function which
> handles CSC on plane color control register, still expectes the input
> buffer to be REC709. This can cause inaccurate output for direct P01x
> flips.
>
> This patch checks if the color_encoding property is set to YCBCR_2020,
> and enables the corresponding color conversion mode on plane CSC.
>
> PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
>
> Cc: Ville Syrjala
> Cc: Maarten Lankhorst
> Cc: Uma Shankar
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_display.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index dd65d7c521c1..2d4d3128bf1f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
> *crtc_state,
> to_i915(plane_state->base.plane->dev);
> const struct drm_framebuffer *fb = plane_state->base.fb;
> struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> - u32 plane_color_ctl = 0;
> + u32 color_ctl = 0;
>
> - plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> - plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> + color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> + color_ctl |= glk_plane_color_ctl_alpha(plane_state);
>
> if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> - if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
> - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> - else
> - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> + switch (plane_state->base.color_encoding) {
> + case DRM_COLOR_YCBCR_BT709:
> + color_ctl |= PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> + break;
> + case DRM_COLOR_YCBCR_BT2020:
> + color_ctl |= PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> + break;
> + default:
> + color_ctl |= PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> + }
This isn't going to do anything without adjusting the property supported
encodings as well.
>
> if (plane_state->base.color_range == DRM_COLOR_YCBCR_FULL_RANGE)
> - plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> + color_ctl |= PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> } else if (fb->format->is_yuv) {
> - plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> + color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> }
>
> - return plane_color_ctl;
> + return color_ctl;
> }
>
> static int
> --
> 2.17.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Tune down WARN about incorrect VBT TC legacy flag
Looks like VBT contains again the wrong information about a port's TypeC
legacy vs. DP-alt/TBT-alt type. There is no further issues after we
notice this and fix it up, so tune down the WARN to be a a DRM_ERROR.
This also avoids CI tainting the kernel and stopping the test run.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110578
Cc: Jani Nikula
Signed-off-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 4e7b8d29d733..07fa2670a677 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5230,9 +5230,12 @@ static bool icl_tc_port_connected(struct
drm_i915_private *dev_priv,
* WARN if we got a legacy port HPD, but VBT didn't mark the port as
* legacy. Treat the port as legacy from now on.
*/
- if (WARN_ON(!intel_dig_port->tc_legacy_port &&
- I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)))
+ if (!intel_dig_port->tc_legacy_port &&
+ I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)) {
+ DRM_ERROR("VBT incorrectly claims port %c is not TypeC
legacy\n",
+ port_name(port));
intel_dig_port->tc_legacy_port = true;
+ }
is_legacy = intel_dig_port->tc_legacy_port;
/*
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Unshadow MI_USER_INTERRUPT
Quoting Chris Wilson (2019-05-02 10:41:19) > Given an immediate preemption event on re-enabling arbitration > (MI_ARB_ON_OFF | MI_ARB_ENABLE) it appears that the HW may forget about > the ongoing MI_USER_INTERRUPT, losing the interrupt in the process. If > we happen to be waiting on that interrupt at the time, the system may > then grind to a halt. > > My presumption is that there is an effective shadow inside the CS as it > parses and buffers the commands, and if we push the MI_USER_INTERRUPT > out of the immediate parse buffer it is not lost by the arbitration > check. > > Testcase: igt/gem_concurrent_blit > Signed-off-by: Chris Wilson > --- > Plausible? I need a few hours to confirm my hunch. Sadly, it got stuck again. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/perf: Refactor oa object to better manage resources
On 01/05/2019 17:50, Umesh Nerlige Ramappa wrote:
The oa object manages the oa buffer and must be allocated when the user
intends to read performance counter snapshots. This can be achieved by
making the oa object part of the stream object which is allocated when a
stream is opened by the user.
Attributes in the oa object that are gen-specific are moved to the perf
object so that they can be initialized on driver load.
The split provides a better separation of the objects used in perf
implementation of i915 driver so that resources are allocated and
initialized only when needed.
Signed-off-by: Umesh Nerlige Ramappa
This refactoring makes sense.
I've opened a PR on gputop to match the changes in the generated files :
https://github.com/rib/gputop/pull/201
Reviewed-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 219 +-
drivers/gpu/drm/i915/i915_oa_bdw.c| 30 +-
drivers/gpu/drm/i915/i915_oa_bxt.c| 30 +-
drivers/gpu/drm/i915/i915_oa_cflgt2.c | 30 +-
drivers/gpu/drm/i915/i915_oa_cflgt3.c | 30 +-
drivers/gpu/drm/i915/i915_oa_chv.c| 30 +-
drivers/gpu/drm/i915/i915_oa_cnl.c| 30 +-
drivers/gpu/drm/i915/i915_oa_glk.c| 30 +-
drivers/gpu/drm/i915/i915_oa_hsw.c| 30 +-
drivers/gpu/drm/i915/i915_oa_icl.c| 30 +-
drivers/gpu/drm/i915/i915_oa_kblgt2.c | 30 +-
drivers/gpu/drm/i915/i915_oa_kblgt3.c | 30 +-
drivers/gpu/drm/i915/i915_oa_sklgt2.c | 30 +-
drivers/gpu/drm/i915/i915_oa_sklgt3.c | 30 +-
drivers/gpu/drm/i915/i915_oa_sklgt4.c | 30 +-
drivers/gpu/drm/i915/i915_perf.c | 580 ++
18 files changed, 627 insertions(+), 598 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 7f448f3bea0b..fa78df39521a 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -32,7 +32,7 @@ u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
* cases which disable slices for functional, apart for performance
* reasons. So in this case we select a known stable subset.
*/
- if (!i915->perf.oa.exclusive_stream) {
+ if (!i915->perf.exclusive_stream) {
ctx_sseu = *req_sseu;
} else {
ctx_sseu = intel_sseu_from_device_info(sseu);
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 7ae42f2ebfe8..878e71a927de 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -81,8 +81,8 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
u32 *reg_state, bool save)
{
struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
- u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
- u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+ u32 ctx_oactxctrl = dev_priv->perf.ctx_oactxctrl_offset;
+ u32 ctx_flexeu0 = dev_priv->perf.ctx_flexeu0_offset;
int i = 0;
u32 flex_mmio[] = {
i915_mmio_reg_offset(EU_PERF_CNTL0),
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1cea98f8b85c..9536550f11cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1399,6 +1399,86 @@ struct i915_perf_stream {
* @oa_config: The OA configuration used by the stream.
*/
struct i915_oa_config *oa_config;
+
+ /**
+* The OA context specific information.
+*/
+ struct intel_context *pinned_ctx;
+ u32 specific_ctx_id;
+ u32 specific_ctx_id_mask;
+
+ struct hrtimer poll_check_timer;
+ wait_queue_head_t poll_wq;
+ bool pollin;
+
+ bool periodic;
+ int period_exponent;
+
+ /**
+* State of the OA buffer.
+*/
+ struct {
+ struct i915_vma *vma;
+ u8 *vaddr;
+ u32 last_ctx_id;
+ int format;
+ int format_size;
+ int size_exponent;
+
+ /**
+* Locks reads and writes to all head/tail state
+*
+* Consider: the head and tail pointer state needs to be read
+* consistently from a hrtimer callback (atomic context) and
+* read() fop (user context) with tail pointer updates happening
+* in atomic context and head updates in user context and the
+* (unlikely) possibility of read() errors needing to reset all
+* head/tail state.
+*
+* Note: Contention/performance aren't currently a significant
+* concern here considering the relatively low frequency of
+* hrtimer callbacks (5ms period) and that reads typically only
+* happe
Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, May 2, 2019 3:45 PM
> To: Sharma, Shashank
> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> ; Lankhorst,
> Maarten
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for
> BT2020 framebuffers
>
> On Thu, May 02, 2019 at 03:19:42PM +0530, Shashank Sharma wrote:
> > Framebuffer formats P01x are supported by GLK, but the function which
> > handles CSC on plane color control register, still expectes the input
> > buffer to be REC709. This can cause inaccurate output for direct P01x
> > flips.
> >
> > This patch checks if the color_encoding property is set to YCBCR_2020,
> > and enables the corresponding color conversion mode on plane CSC.
> >
> > PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
> >
> > Cc: Ville Syrjala
> > Cc: Maarten Lankhorst
> > Cc: Uma Shankar
> > Signed-off-by: Shashank Sharma
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 26 --
> > 1 file changed, 16 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index dd65d7c521c1..2d4d3128bf1f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct
> > intel_crtc_state
> *crtc_state,
> > to_i915(plane_state->base.plane->dev);
> > const struct drm_framebuffer *fb = plane_state->base.fb;
> > struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > - u32 plane_color_ctl = 0;
> > + u32 color_ctl = 0;
> >
> > - plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > - plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > + color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > + color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> >
> > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > - if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
> > - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > - else
> > - plane_color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > + switch (plane_state->base.color_encoding) {
> > + case DRM_COLOR_YCBCR_BT709:
> > + color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > + break;
> > + case DRM_COLOR_YCBCR_BT2020:
> > + color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > + break;
> > + default:
> > + color_ctl |=
> PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > + }
>
> This isn't going to do anything without adjusting the property supported
> encodings as
> well.
>
I might have not understood this comment properly, but, AFAIK, if userspace
sets this property well, and we set this color_ctl bit properly, driver is
setting PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020 bits in GLK color control
register. As GLK has a fix function plane CSC, HW will apply a different matrix
internally to convert input buffer to RGB_2020 from YCBCR_2020 (earlier this
would have been YCBCR_709). So I think we should see visible changes in
output. Do you think otherwise ?
- Shashank
> >
> > if (plane_state->base.color_range ==
> DRM_COLOR_YCBCR_FULL_RANGE)
> > - plane_color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > + color_ctl |=
> PLANE_COLOR_YUV_RANGE_CORRECTION_DISABLE;
> > } else if (fb->format->is_yuv) {
> > - plane_color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > + color_ctl |= PLANE_COLOR_INPUT_CSC_ENABLE;
> > }
> >
> > - return plane_color_ctl;
> > + return color_ctl;
> > }
> >
> > static int
> > --
> > 2.17.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
On Thu, May 02, 2019 at 10:40:39AM +, Sharma, Shashank wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Thursday, May 2, 2019 3:45 PM
> > To: Sharma, Shashank
> > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> > ; Lankhorst,
> > Maarten
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for
> > BT2020 framebuffers
> >
> > On Thu, May 02, 2019 at 03:19:42PM +0530, Shashank Sharma wrote:
> > > Framebuffer formats P01x are supported by GLK, but the function which
> > > handles CSC on plane color control register, still expectes the input
> > > buffer to be REC709. This can cause inaccurate output for direct P01x
> > > flips.
> > >
> > > This patch checks if the color_encoding property is set to YCBCR_2020,
> > > and enables the corresponding color conversion mode on plane CSC.
> > >
> > > PS: renamed variable plane_color_ctl to color_ctl for 80 char stuff.
> > >
> > > Cc: Ville Syrjala
> > > Cc: Maarten Lankhorst
> > > Cc: Uma Shankar
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 26 --
> > > 1 file changed, 16 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index dd65d7c521c1..2d4d3128bf1f 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct
> > > intel_crtc_state
> > *crtc_state,
> > > to_i915(plane_state->base.plane->dev);
> > > const struct drm_framebuffer *fb = plane_state->base.fb;
> > > struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
> > > - u32 plane_color_ctl = 0;
> > > + u32 color_ctl = 0;
> > >
> > > - plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > > - plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > > + color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > > + color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > >
> > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
> > > - if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
> > > - plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > - else
> > > - plane_color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > + switch (plane_state->base.color_encoding) {
> > > + case DRM_COLOR_YCBCR_BT709:
> > > + color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > + break;
> > > + case DRM_COLOR_YCBCR_BT2020:
> > > + color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > + break;
> > > + default:
> > > + color_ctl |=
> > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > + }
> >
> > This isn't going to do anything without adjusting the property supported
> > encodings as
> > well.
> >
> I might have not understood this comment properly, but, AFAIK, if userspace
> sets this property well, and we set this color_ctl bit properly, driver is
> setting PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020 bits in GLK color control
> register. As GLK has a fix function plane CSC, HW will apply a different
> matrix internally to convert input buffer to RGB_2020 from YCBCR_2020
> (earlier this would have been YCBCR_709). So I think we should see visible
> changes in output. Do you think otherwise ?
The property won't accept the BT2020 value. Or if it does we have a bug
somewhere.
I guess tests would be nice. Maybe we should extend the kms_plane pixel
format tests to check different YCbCr encodings as well? Or maybe
Maarten's kms_yuv already tests this?
--
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] drm/i915: Tune down WARN about incorrect VBT TC legacy flag
On Thu, 02 May 2019, Imre Deak wrote:
> Looks like VBT contains again the wrong information about a port's TypeC
> legacy vs. DP-alt/TBT-alt type. There is no further issues after we
> notice this and fix it up, so tune down the WARN to be a a DRM_ERROR.
>
> This also avoids CI tainting the kernel and stopping the test run.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110578
> Cc: Jani Nikula
> Signed-off-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 4e7b8d29d733..07fa2670a677 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5230,9 +5230,12 @@ static bool icl_tc_port_connected(struct
> drm_i915_private *dev_priv,
>* WARN if we got a legacy port HPD, but VBT didn't mark the port as
With the comment fixed,
Reviewed-by: Jani Nikula
>* legacy. Treat the port as legacy from now on.
>*/
> - if (WARN_ON(!intel_dig_port->tc_legacy_port &&
> - I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)))
> + if (!intel_dig_port->tc_legacy_port &&
> + I915_READ(SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port)) {
> + DRM_ERROR("VBT incorrectly claims port %c is not TypeC
> legacy\n",
> + port_name(port));
> intel_dig_port->tc_legacy_port = true;
> + }
> is_legacy = intel_dig_port->tc_legacy_port;
>
> /*
--
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 1/2] drm/i915: Don't skip audio enable if ELD is bogus
On Tue, 30 Apr 2019, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We've already committed to enabling audio when intel_audio_codec_enable()
> is called. We can't back out even if the ELD has turned sour in the
> meantime. So just spew some debug log and plow ahead. Otherwise the
> state checker gets unhappy when audio isn't enabled when it is
> expected to be.
>
> I suppose we really ought to precompute the ELD as well, but
> let's just toss in a FIXME for the future.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103841
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_audio.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index bca4cc025d3d..68a24dada44c 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -644,8 +644,10 @@ void intel_audio_codec_enable(struct intel_encoder
> *encoder,
> enum port port = encoder->port;
> enum pipe pipe = crtc->pipe;
>
> + /* FIXME precompute the ELD in .compute_config() */
> if (!connector->eld[0])
> - return;
> + DRM_DEBUG_KMS("Bogus ELD on [CONNECTOR:%d:%s]\n",
> + connector->base.id, connector->name);
>
> DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>connector->base.id,
--
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 2/2] drm/i915: hsw+ audio regs are per-transocder
On Tue, 30 Apr 2019, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> s/pipe/transcoder/ when dealing with hsw+ audio registers. This
> won't actually make any real difference since there is no audio
> on the EDP transcoder. But this should avoid a bit of confusion
> when cross checking against the spec.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h| 12 +++
> drivers/gpu/drm/i915/intel_audio.c | 55 ++
> 2 files changed, 32 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 6f0a0866c802..926e058d09ee 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9010,32 +9010,32 @@ enum {
> /* HSW Audio */
> #define _HSW_AUD_CONFIG_A0x65000
> #define _HSW_AUD_CONFIG_B0x65100
> -#define HSW_AUD_CFG(pipe)_MMIO_PIPE(pipe, _HSW_AUD_CONFIG_A,
> _HSW_AUD_CONFIG_B)
> +#define HSW_AUD_CFG(trans) _MMIO_TRANS(trans, _HSW_AUD_CONFIG_A,
> _HSW_AUD_CONFIG_B)
>
> #define _HSW_AUD_MISC_CTRL_A 0x65010
> #define _HSW_AUD_MISC_CTRL_B 0x65110
> -#define HSW_AUD_MISC_CTRL(pipe) _MMIO_PIPE(pipe,
> _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> +#define HSW_AUD_MISC_CTRL(trans) _MMIO_TRANS(trans,
> _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
>
> #define _HSW_AUD_M_CTS_ENABLE_A 0x65028
> #define _HSW_AUD_M_CTS_ENABLE_B 0x65128
> -#define HSW_AUD_M_CTS_ENABLE(pipe) _MMIO_PIPE(pipe,
> _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> +#define HSW_AUD_M_CTS_ENABLE(trans) _MMIO_TRANS(trans,
> _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> #define AUD_M_CTS_M_VALUE_INDEX(1 << 21)
> #define AUD_M_CTS_M_PROG_ENABLE(1 << 20)
> #define AUD_CONFIG_M_MASK 0xf
>
> #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
> #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
> -#define HSW_AUD_DIP_ELD_CTRL(pipe) _MMIO_PIPE(pipe,
> _HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B)
> +#define HSW_AUD_DIP_ELD_CTRL(trans) _MMIO_TRANS(trans,
> _HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B)
>
> /* Audio Digital Converter */
> #define _HSW_AUD_DIG_CNVT_1 0x65080
> #define _HSW_AUD_DIG_CNVT_2 0x65180
> -#define AUD_DIG_CNVT(pipe) _MMIO_PIPE(pipe, _HSW_AUD_DIG_CNVT_1,
> _HSW_AUD_DIG_CNVT_2)
> +#define AUD_DIG_CNVT(trans) _MMIO_TRANS(trans, _HSW_AUD_DIG_CNVT_1,
> _HSW_AUD_DIG_CNVT_2)
> #define DIP_PORT_SEL_MASK0x3
>
> #define _HSW_AUD_EDID_DATA_A 0x65050
> #define _HSW_AUD_EDID_DATA_B 0x65150
> -#define HSW_AUD_EDID_DATA(pipe) _MMIO_PIPE(pipe,
> _HSW_AUD_EDID_DATA_A, _HSW_AUD_EDID_DATA_B)
> +#define HSW_AUD_EDID_DATA(trans) _MMIO_TRANS(trans,
> _HSW_AUD_EDID_DATA_A, _HSW_AUD_EDID_DATA_B)
>
> #define HSW_AUD_PIPE_CONV_CFG_MMIO(0x6507c)
> #define HSW_AUD_PIN_ELD_CP_VLD _MMIO(0x650c0)
> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> b/drivers/gpu/drm/i915/intel_audio.c
> index 68a24dada44c..5c0b73f63843 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -319,9 +319,8 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
> {
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> struct i915_audio_component *acomp = dev_priv->audio_component;
> - struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> enum port port = encoder->port;
> - enum pipe pipe = crtc->pipe;
> const struct dp_aud_n_m *nm;
> int rate;
> u32 tmp;
> @@ -333,7 +332,7 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
> else
> DRM_DEBUG_KMS("using automatic Maud, Naud\n");
>
> - tmp = I915_READ(HSW_AUD_CFG(pipe));
> + tmp = I915_READ(HSW_AUD_CFG(cpu_transcoder));
> tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
> tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
> @@ -345,9 +344,9 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
> tmp |= AUD_CONFIG_N_PROG_ENABLE;
> }
>
> - I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> + I915_WRITE(HSW_AUD_CFG(cpu_transcoder), tmp);
>
> - tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
> + tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(cpu_transcoder));
> tmp &= ~AUD_CONFIG_M_MASK;
> tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
> tmp &= ~AUD_M_CTS_M_PROG_ENABLE;
> @@ -358,7 +357,7 @@ hsw_dp_audio_config_update(struct intel_encoder *encoder,
> tmp |= AUD_M_CTS_M_PROG_ENABLE;
> }
>
> - I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
> + I915_WRITE(HSW_AUD_M_CTS_ENABLE(cpu_transcoder), tmp);
> }
>
> static void
> @@ -367,15 +366,14 @@ hsw_hdmi_audi
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel, Here is a drm-misc fixes PR for 5.1. Thanks! Maxime drm-misc-fixes-2019-05-02: - One revert for QXL for a DRI3 breakage The following changes since commit c4cba44eeecab9d5ccd3dd2d5520a7d1e5be544f: drm/bridge: dw-hdmi: fix SCDC configuration for ddc-i2c-bus (2019-04-25 10:38:21 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-05-02 for you to fetch changes up to ab042b824c11502bd39abfdfd4c7f285347d483a: Revert "drm/qxl: drop prime import/export callbacks" (2019-04-30 14:08:48 +0200) - One revert for QXL for a DRI3 breakage Gerd Hoffmann (1): Revert "drm/qxl: drop prime import/export callbacks" drivers/gpu/drm/qxl/qxl_drv.c | 4 drivers/gpu/drm/qxl/qxl_prime.c | 12 2 files changed, 16 insertions(+) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com 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.IGT: success for drm/i915: add single combo phy init/unit functions (rev2)
== Series Details == Series: drm/i915: add single combo phy init/unit functions (rev2) URL : https://patchwork.freedesktop.org/series/60112/ State : success == Summary == CI Bug Log - changes from CI_DRM_6025_full -> Patchwork_12931_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12931_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#107807] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl10/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-skl8/igt@i915_pm_...@basic-rte.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-apl3/igt@i915_susp...@sysfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-apl3/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@flip-vs-suspend: - shard-glk: [PASS][5] -> [INCOMPLETE][6] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk1/igt@kms_f...@flip-vs-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-glk2/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#110581]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_flip_til...@flip-changes-tiling.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-iclb6/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110581]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-wc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-skl3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#106978] / [fdo#110581]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-skl5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-glk8/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713] / [fdo#110036 ] / [fdo#110581]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb7/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-iclb6/igt@kms_pl...@pixel-format-pipe-c-planes-source-clamping.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108] / [fdo#110581]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12931/shard-iclb1/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_setmode@basic: - shard-kbl: [PASS][
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Engine discovery query (rev10)
== Series Details == Series: drm/i915: Engine discovery query (rev10) URL : https://patchwork.freedesktop.org/series/39958/ State : success == Summary == CI Bug Log - changes from CI_DRM_6025_full -> Patchwork_12932_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12932_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-skl: [PASS][1] -> [INCOMPLETE][2] ([fdo#104108] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl10/igt@debugfs_test@read_all_entries_display_off.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-skl7/igt@debugfs_test@read_all_entries_display_off.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-apl8/igt@gem_workarou...@suspend-resume-context.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@basic-rte: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807] / [fdo#110581]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl10/igt@i915_pm_...@basic-rte.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-skl4/igt@i915_pm_...@basic-rte.html * igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#110581]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl2/igt@kms_b...@extended-modeset-hang-newfb-with-reset-render-a.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-skl9/igt@kms_b...@extended-modeset-hang-newfb-with-reset-render-a.html * igt@kms_flip@2x-flip-vs-dpms-interruptible: - shard-glk: [PASS][9] -> [INCOMPLETE][10] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk6/igt@kms_f...@2x-flip-vs-dpms-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-glk5/igt@kms_f...@2x-flip-vs-dpms-interruptible.html * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#100368]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk1/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-glk2/igt@kms_f...@2x-plain-flip-fb-recreate-interruptible.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#110581]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_flip_til...@flip-changes-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-iclb1/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: [PASS][17] -> [SKIP][18] ([fdo#109271]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-glk8/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html * igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / [fdo#110041] / [fdo#110581]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb6/igt@kms_plane_scal...@pipe-b-scaler-with-clipping-clamping.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-iclb3/igt@kms_plane_scal...@pipe-b-scaler-with-clipping-clamping.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12932/shard-iclb7/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_setmode@basic: - shard-kbl: [PASS][23] -> [FAIL][24] ([fdo#99912])
Re: [Intel-gfx] [PATCH 05/14] drm/i915: Remove delay for idle_work
On 01/05/2019 12:45, Chris Wilson wrote:
The original intent for the delay before running the idle_work was to
provide a hysteresis to avoid ping-ponging the device runtime-pm. Since
then we have also pulled in some memory management and general device
management for parking. But with the inversion of the wakeref handling,
GEM is no longer responsible for the wakeref and by the time we call the
idle_work, the device is asleep. It seems appropriate now to drop the
delay and just run the worker immediately to flush the cached GEM state
before sleeping.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_pm.c| 21 +++
.../gpu/drm/i915/selftests/i915_gem_object.c | 2 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 4 ++--
5 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e4dffcd4da4..7e8898d0b78b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3935,8 +3935,8 @@ i915_drop_caches_set(void *data, u64 val)
if (val & DROP_IDLE) {
do {
flush_delayed_work(&i915->gem.retire_work);
- drain_delayed_work(&i915->gem.idle_work);
} while (READ_ONCE(i915->gt.awake));
+ flush_work(&i915->gem.idle_work);
}
if (val & DROP_FREED)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 13270e19eb87..cbf4a7d8bdae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2035,7 +2035,7 @@ struct drm_i915_private {
* arrive within a small period of time, we fire
* off the idle_work.
*/
- struct delayed_work idle_work;
+ struct work_struct idle_work;
} gem;
/* For i945gm vblank irq vs. C3 workaround */
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 49b0ce594f20..ae91ad7cb31e 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private *i915)
static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
- container_of(work, typeof(*i915), gem.idle_work.work);
+ container_of(work, typeof(*i915), gem.idle_work);
mutex_lock(&i915->drm.struct_mutex);
intel_wakeref_lock(&i915->gt.wakeref);
- if (!intel_wakeref_active(&i915->gt.wakeref))
+ if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
What is the reason for the !work_pending check?
Regards,
Tvrtko
i915_gem_park(i915);
intel_wakeref_unlock(&i915->gt.wakeref);
@@ -74,9 +74,7 @@ static int pm_notifier(struct notifier_block *nb,
break;
case INTEL_GT_PARK:
- mod_delayed_work(i915->wq,
-&i915->gem.idle_work,
-msecs_to_jiffies(100));
+ queue_work(i915->wq, &i915->gem.idle_work);
break;
}
@@ -142,16 +140,11 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- GEM_BUG_ON(i915->gt.awake);
- cancel_delayed_work_sync(&i915->gpu_error.hangcheck_work);
-
drain_delayed_work(&i915->gem.retire_work);
+ GEM_BUG_ON(i915->gt.awake);
+ flush_work(&i915->gem.idle_work);
- /*
-* As the idle_work is rearming if it detects a race, play safe and
-* repeat the flush until it is definitely idle.
-*/
- drain_delayed_work(&i915->gem.idle_work);
+ cancel_delayed_work_sync(&i915->gpu_error.hangcheck_work);
i915_gem_drain_freed_objects(i915);
@@ -242,7 +235,7 @@ void i915_gem_resume(struct drm_i915_private *i915)
void i915_gem_init__pm(struct drm_i915_private *i915)
{
- INIT_DELAYED_WORK(&i915->gem.idle_work, idle_work_handler);
+ INIT_WORK(&i915->gem.idle_work, idle_work_handler);
INIT_DELAYED_WORK(&i915->gem.retire_work, retire_work_handler);
i915->gem.pm_notifier.notifier_call = pm_notifier;
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
index 088b2aa05dcd..b926d1cd165d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -509,7 +509,7 @@ static void disable_retire_worker(struct drm_i915_private
*i915)
intel_gt_pm_get(i915);
cancel_delayed_work_sync(&i915->gem.retire_work);
- cancel_delayed_work_sync(&i915->gem.idle_work
[Intel-gfx] [PATCH v6 00/10] HDCP2.2 Phase II
This series adds the content type capability for HDCP through a drm connetor proeprty "HDCP Content Type". By default this property will be "Type 0". And this property is exposed by the drivers which has the HDCP2.2 capability to enable the userspace to configure for "Type 1". HDCP Content Type: This property is used to indicate the content type classification of a stream. Which indicate the HDCP version required for the rendering of that streams. This conten type is one of the parameter in the HDCP2.2 authentication flow, as even downstream repeaters will mandate the HDCP version requirement. Two values possible for content type of a stream: Type 0: Stream can be rendered only on HDCP encrypted link no restriction on HDCP versions. Type 1: Stream can be rendered only on HDCP2.2 encrypted link. And also this series adds a uevent for a change in the property state change of a connector. This helps the userspace to monitor the uevent for a proeprty state change than the trivial polling. Userspace consumer for above "HDCP Content Type" property and uevent is almost at the last phase of review at #wayland community. So Patches 6, 7, 8, 9 and 10 can be merged only when patches in #wayland community receives the ACK. HDCP SRM is implemented through request_firmware() interface. Hence userspace is expected to write the signature validated latest available SRM table into /lib/firmware/ as "display_hdcp_srm.bin". On every HDCP authentication kernel will read the SRM from above mentioned file and do the revocation check. And also this series gathers all HDCP related DRM code into drm_hdcp.c Thanks Daniel Vetter for all the reviews. Series can be cloned from github https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v6 Test-with: <20190502131625.27551-2-ramalinga...@intel.com> Ramalingam C (10): drm: move content protection property to mode_config drm/i915: debugfs: HDCP2.2 capability read drm: revocation check at drm subsystem drm/i915: SRM revocation check for HDCP1.4 and 2.2 drm/hdcp: gathering hdcp related code into drm_hdcp.c drm: Add Content protection type property drm/i915: Attach content type property drm: uevent for connector status change drm/hdcp: update content protection property with uevent drm/i915: update the hdcp state with uevent Documentation/gpu/drm-kms-helpers.rst | 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_atomic_uapi.c | 8 +- drivers/gpu/drm/drm_connector.c | 61 +--- drivers/gpu/drm/drm_hdcp.c| 455 ++ drivers/gpu/drm/drm_internal.h| 4 + drivers/gpu/drm/drm_sysfs.c | 37 +++ drivers/gpu/drm/i915/i915_debugfs.c | 13 +- drivers/gpu/drm/i915/intel_ddi.c | 37 ++- drivers/gpu/drm/i915/intel_hdcp.c | 100 -- drivers/gpu/drm/i915/intel_hdcp.h | 3 +- include/drm/drm_connector.h | 15 +- include/drm/drm_hdcp.h| 29 ++ include/drm/drm_mode_config.h | 12 + include/drm/drm_sysfs.h | 5 +- include/uapi/drm/drm_mode.h | 4 + 16 files changed, 699 insertions(+), 92 deletions(-) create mode 100644 drivers/gpu/drm/drm_hdcp.c -- 2.19.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 02/10] drm/i915: debugfs: HDCP2.2 capability read
Adding the HDCP2.2 capability of HDCP src and sink info into debugfs
entry "i915_hdcp_sink_capability"
This helps the userspace tests to skip the HDCP2.2 test on non HDCP2.2
sinks.
v2:
Rebased.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
drivers/gpu/drm/i915/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/intel_hdcp.h | 1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ffbf5d920429..969985095170 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4750,6 +4750,7 @@ static int i915_hdcp_sink_capability_show(struct seq_file
*m, void *data)
{
struct drm_connector *connector = m->private;
struct intel_connector *intel_connector = to_intel_connector(connector);
+ bool hdcp_cap, hdcp2_cap;
if (connector->status != connector_status_connected)
return -ENODEV;
@@ -4760,8 +4761,16 @@ static int i915_hdcp_sink_capability_show(struct
seq_file *m, void *data)
seq_printf(m, "%s:%d HDCP version: ", connector->name,
connector->base.id);
- seq_printf(m, "%s ", !intel_hdcp_capable(intel_connector) ?
- "None" : "HDCP1.4");
+ hdcp_cap = intel_hdcp_capable(intel_connector);
+ hdcp2_cap = intel_hdcp2_capable(intel_connector);
+
+ if (hdcp_cap)
+ seq_puts(m, "HDCP1.4 ");
+ if (hdcp2_cap)
+ seq_puts(m, "HDCP2.2 ");
+
+ if (!hdcp_cap && !hdcp2_cap)
+ seq_puts(m, "None");
seq_puts(m, "\n");
return 0;
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index ca5982e45e3e..b8c8d6d1a33d 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -79,7 +79,7 @@ bool intel_hdcp_capable(struct intel_connector *connector)
}
/* Is HDCP2.2 capable on Platform and Sink */
-static bool intel_hdcp2_capable(struct intel_connector *connector)
+bool intel_hdcp2_capable(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
diff --git a/drivers/gpu/drm/i915/intel_hdcp.h
b/drivers/gpu/drm/i915/intel_hdcp.h
index a75f25f09d39..be8da85c866a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/intel_hdcp.h
@@ -25,6 +25,7 @@ int intel_hdcp_enable(struct intel_connector *connector);
int intel_hdcp_disable(struct intel_connector *connector);
bool is_hdcp_supported(struct drm_i915_private *dev_priv, enum port port);
bool intel_hdcp_capable(struct intel_connector *connector);
+bool intel_hdcp2_capable(struct intel_connector *connector);
void intel_hdcp_component_init(struct drm_i915_private *dev_priv);
void intel_hdcp_component_fini(struct drm_i915_private *dev_priv);
void intel_hdcp_cleanup(struct intel_connector *connector);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 03/10] drm: revocation check at drm subsystem
On every hdcp revocation check request SRM is read from fw file
/lib/firmware/display_hdcp_srm.bin
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and 2.2 versions of SRM table.
v2:
moved the uAPI to request_firmware_direct() [Daniel]
v3:
kdoc added. [Daniel]
srm_header unified and bit field definitions are removed. [Daniel]
locking improved. [Daniel]
vrl length violation is fixed. [Daniel]
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 6 +
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_hdcp.c| 342 ++
drivers/gpu/drm/drm_internal.h| 4 +
drivers/gpu/drm/drm_sysfs.c | 2 +
include/drm/drm_hdcp.h| 24 ++
6 files changed, 379 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_hdcp.c
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 14102ae035dc..0fe726a6ee67 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -181,6 +181,12 @@ Panel Helper Reference
.. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c
:export:
+HDCP Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c
+ :export:
+
Display Port Helper Functions Reference
===
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 72f5036d9bfa..dd02e9dec810 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -17,7 +17,7 @@ drm-y :=drm_auth.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
- drm_atomic_uapi.o
+ drm_atomic_uapi.o drm_hdcp.o
drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
drm_dma.o drm_scatter.o drm_lock.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index ..dc0e13409221
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,342 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+struct hdcp_srm {
+ u8 *srm_buf;
+ size_t received_srm_sz;
+ u32 revoked_ksv_cnt;
+ u8 *revoked_ksv_list;
+
+ /* Mutex to protect above struct member */
+ struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const u8 *ksv)
+{
+ DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n",
+ ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]);
+}
+
+static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+ while (parsed_bytes < vrls_length) {
+ vrl_ksv_cnt = *buf;
+ ksv_count += vrl_ksv_cnt;
+
+ vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+ buf += vrl_sz;
+ parsed_bytes += vrl_sz;
+ }
+
+ /*
+* When vrls are not valid, ksvs are not considered.
+* Hence SRM will be discarded.
+*/
+ if (parsed_bytes != vrls_length)
+ ksv_count = 0;
+
+ return ksv_count;
+}
+
+static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list,
+u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0;
+ u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+ buf++;
+
+ DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+ memcpy(revoked_ksv_list, buf, vrl_ksv_sz);
+
+ ksv_count += vrl_ksv_cnt;
+ revoked_ksv_list += vrl_ksv_sz;
+ buf += vrl_ksv_sz;
+
+ parsed_bytes += (vrl_ksv_sz + 1);
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static inline u32 get_vrl_length(const u8 *buf)
+{
+ return (u32)(buf[0] << 16 | buf[1] << 8 | buf[2]);
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count)
+{
+ struct hdcp_srm_header *header;
+ u32 vrl_length, ksv_count;
+
+ if (count < (sizeof(struct hdcp_srm_header) +
+ DRM_HDCP_1_4_VRL_LENGTH_SIZE + DRM_HDCP_1_4_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length\n");
+ return -EINVAL;
+
[Intel-gfx] [PATCH v6 06/10] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
Need ACK for this new conenctor property from userspace consumer.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
v5:
kernel doc nits addressed [Daniel]
Rebased as part of patch reordering.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 18
drivers/gpu/drm/drm_hdcp.c| 36 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
include/drm/drm_connector.h | 7 ++
include/drm/drm_hdcp.h| 2 +-
include/drm/drm_mode_config.h | 6 ++
include/uapi/drm/drm_mode.h | 4
8 files changed, 78 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 4131e669785a..a85f3ccfe699 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -738,6 +738,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -816,6 +818,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->scaling_mode;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 764c7903edf6..de9e06583e8c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -955,6 +955,24 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* the value transitions from ENABLED to DESIRED. This signifies the link
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
+ * HDCP Content Type:
+ * This property is used by the userspace to configure the kernel with
+ * to be displayed stream's content type. Content Type of a stream is
+ * decided by the owner of the stream, as HDCP Type0 or HDCP Type1.
+ *
+ * The value of the property can be one the below:
+ * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * HDCP Type0 streams can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or HDCP 2.2.
+ * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ * HDCP Type1 streams can be transmitted on a link which is
+ * encrypted only with HDCP 2.2.
+ *
+ * Note that the HDCP Content Type property is specific to HDCP 2.2, and
+ * defaults to type 0. It is only exposed by drivers supporting HDCP 2.2
+ * If content type is changed when content_protection is not UNDESIRED,
+ * then kernel will disable the HDCP and re-enable with new type in the
+ * same atomic commit
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index ff3fb2326b46..fc9083db833d 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -351,23 +351,41 @@ static struct drm_prop_enum_list drm_cp_enum_list[] = {
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+ { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+ { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+drm_hdcp_content_type_enum_list)
+
/**
* drm_connector_attach_content_protection_property - attach content protection
*
[Intel-gfx] [PATCH v6 05/10] drm/hdcp: gathering hdcp related code into drm_hdcp.c
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
v2:
Rebased.
v2:
Rebased.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 44 --
drivers/gpu/drm/drm_hdcp.c | 47 +
include/drm/drm_connector.h | 2 --
include/drm/drm_hdcp.h | 3 +++
4 files changed, 50 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c0eda9cca60..764c7903edf6 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -823,13 +823,6 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_cp_enum_list[] = {
- { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
- { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
- { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
-};
-DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -1515,43 +1508,6 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
-/**
- * drm_connector_attach_content_protection_property - attach content protection
- * property
- *
- * @connector: connector to attach CP property on.
- *
- * This is used to add support for content protection on select connectors.
- * Content Protection is intentionally vague to allow for different underlying
- * technologies, however it is most implemented by HDCP.
- *
- * The content protection will be set to
&drm_connector_state.content_protection
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_attach_content_protection_property(
- struct drm_connector *connector)
-{
- struct drm_device *dev = connector->dev;
- struct drm_property *prop =
- dev->mode_config.content_protection_property;
-
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(&connector->base, prop,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- dev->mode_config.content_protection_property = prop;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
-
/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index dc0e13409221..ff3fb2326b46 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -17,6 +17,9 @@
#include
#include
#include
+#include
+#include
+#include
struct hdcp_srm {
u8 *srm_buf;
@@ -340,3 +343,47 @@ void drm_teardown_hdcp_srm(struct class *drm_class)
kfree(srm_data);
}
}
+
+static struct drm_prop_enum_list drm_cp_enum_list[] = {
+ { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
+ { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
+ { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+
+/**
+ * drm_connector_attach_content_protection_property - attach content protection
+ * property
+ *
+ * @connector: connector to attach CP property on.
+ *
+ * This is used to add support for content protection on select connectors.
+ * Content Protection is intentionally vague to allow for different underlying
+ * technologies, however it is most implemented by HDCP.
+ *
+ * The content protection will be set to
&drm_connector_state.content_protection
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_content_protection_property(
+ struct drm_connector *connector)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
+
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ return -ENOMEM;
+
+ drm_object_attach_property(&connector->base, prop,
+ DRM_MODE_CONTENT
[Intel-gfx] [PATCH v6 01/10] drm: move content protection property to mode_config
Content protection property is created once and stored in
drm_mode_config. And attached to all HDCP capable connectors.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 13 +++--
include/drm/drm_connector.h | 6 --
include/drm/drm_mode_config.h | 6 ++
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 428d82662dc4..4131e669785a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -732,7 +732,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
if (val == DRM_MODE_CONTENT_PROTECTION_ENABLED) {
DRM_DEBUG_KMS("only drivers can set CP Enabled\n");
return -EINVAL;
@@ -814,7 +814,7 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
- } else if (property == connector->content_protection_property) {
+ } else if (property == config->content_protection_property) {
*val = state->content_protection;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124849db..7c0eda9cca60 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1534,18 +1534,19 @@ int drm_connector_attach_content_protection_property(
struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
- struct drm_property *prop;
+ struct drm_property *prop =
+ dev->mode_config.content_protection_property;
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
+ if (!prop)
+ prop = drm_property_create_enum(dev, 0, "Content Protection",
+ drm_cp_enum_list,
+ ARRAY_SIZE(drm_cp_enum_list));
if (!prop)
return -ENOMEM;
drm_object_attach_property(&connector->base, prop,
DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
-
- connector->content_protection_property = prop;
+ dev->mode_config.content_protection_property = prop;
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 02a131202add..5e41942e5679 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1061,12 +1061,6 @@ struct drm_connector {
*/
struct drm_property *vrr_capable_property;
- /**
-* @content_protection_property: DRM ENUM property for content
-* protection. See drm_connector_attach_content_protection_property().
-*/
- struct drm_property *content_protection_property;
-
/**
* @colorspace_property: Connector property to set the suitable
* colorspace supported by the sink.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7f60e8eb269a..5764ee3c7453 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -836,6 +836,12 @@ struct drm_mode_config {
*/
struct drm_property *writeback_out_fence_ptr_property;
+ /**
+* @content_protection_property: DRM ENUM property for content
+* protection. See drm_connector_attach_content_protection_property().
+*/
+ struct drm_property *content_protection_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 07/10] drm/i915: Attach content type property
Attaches the content type property for HDCP2.2 capable connectors.
Implements the update of content type from property and apply the
restriction on HDCP version selection.
Need ACK for content type property from userspace consumer.
v2:
s/cp_content_type/content_protection_type [daniel]
disable at hdcp_atomic_check to avoid check at atomic_set_property
[Maarten]
v3:
s/content_protection_type/hdcp_content_type [Pekka]
v4:
hdcp disable incase of type change is moved into commit [daniel].
v5:
Simplified the Type change procedure. [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c | 37 +-
drivers/gpu/drm/i915/intel_hdcp.c | 43 ---
drivers/gpu/drm/i915/intel_hdcp.h | 2 +-
3 files changed, 60 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index f181c26f62fd..9c7caf39964a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3474,7 +3474,8 @@ static void intel_enable_ddi(struct intel_encoder
*encoder,
/* Enable hdcp if it's desired */
if (conn_state->content_protection ==
DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
+ intel_hdcp_enable(to_intel_connector(conn_state->connector),
+ (u8)conn_state->hdcp_content_type);
}
static void intel_disable_ddi_dp(struct intel_encoder *encoder,
@@ -3543,15 +3544,39 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
+ struct intel_connector *connector =
+ to_intel_connector(conn_state->connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ bool content_protection_type_changed =
+ conn_state->hdcp_content_type != hdcp->content_type;
+
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+ /*
+* During the HDCP encryption session if Type change is requested,
+* disable the HDCP and reenable it with new TYPE value.
+*/
if (conn_state->content_protection ==
- DRM_MODE_CONTENT_PROTECTION_DESIRED)
- intel_hdcp_enable(to_intel_connector(conn_state->connector));
- else if (conn_state->content_protection ==
-DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
- intel_hdcp_disable(to_intel_connector(conn_state->connector));
+ DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_disable(connector);
+
+ /*
+* Mark the hdcp state as DESIRED after the hdcp disable of type
+* change procedure.
+*/
+ if (content_protection_type_changed) {
+ mutex_lock(&hdcp->mutex);
+ hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED;
+ schedule_work(&hdcp->prop_work);
+ mutex_unlock(&hdcp->mutex);
+ }
+
+ if (conn_state->content_protection ==
+ DRM_MODE_CONTENT_PROTECTION_DESIRED ||
+ content_protection_type_changed)
+ intel_hdcp_enable(connector, (u8)conn_state->hdcp_content_type);
}
static void intel_ddi_set_fia_lane_count(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index be36d594129d..2e159ffd17e6 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -1747,14 +1747,15 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
-static inline int initialize_hdcp_port_data(struct intel_connector *connector)
+static inline int initialize_hdcp_port_data(struct intel_connector *connector,
+ const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
data->port = connector->encoder->port;
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
- data->protocol = (u8)hdcp->shim->protocol;
+ data->protocol = (u8)shim->protocol;
data->k = 1;
if (!data->streams)
@@ -1804,12 +1805,13 @@ void intel_hdcp_component_init(struct drm_i915_private
*dev_priv)
}
}
-static void intel_hdcp2_init(struct intel_connector *connector)
+static void intel_hdcp2_init(struct intel_connector *connector,
+const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = &connector->hdcp;
int ret;
- ret = initialize_hdcp_port_data(connector);
+
[Intel-gfx] [PATCH v6 09/10] drm/hdcp: update content protection property with uevent
drm function is defined and exported to update a connector's
content protection property state and to generate a uevent along
with it.
Need ACK for the uevent from userspace consumer.
v2:
Update only when state is different from old one.
v3:
KDoc is added [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_hdcp.c | 32
include/drm/drm_hdcp.h | 2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index fc9083db833d..75ae4cd90c53 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -381,6 +381,10 @@ DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
*
* The content protection will be set to
&drm_connector_state.content_protection
*
+ * When kernel triggered content protection state change like DESIRED->ENABLED
+ * and ENABLED->DESIRED, will use drm_hdcp_update_content_protection() to
update
+ * the content protection state of a connector.
+ *
* Returns:
* Zero on success, negative errno on failure.
*/
@@ -421,3 +425,31 @@ int drm_connector_attach_content_protection_property(
return 0;
}
EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
+
+/**
+ * drm_hdcp_update_content_protection - Updates the content protection state
+ * of a connector
+ *
+ * @connector: drm_connector on which content protection state needs an update
+ * @val: New state of the content protection property
+ *
+ * This function can be used by display drivers, to update the kernel triggered
+ * content protection state change of a drm_connector. This function update the
+ * new state of the property into the connector's state and generate an uevent
+ * to notify the userspace.
+ */
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_connector_state *state = connector->state;
+
+ WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
+ if (state->content_protection == val)
+ return;
+
+ state->content_protection = val;
+ drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
+}
+EXPORT_SYMBOL(drm_hdcp_update_content_protection);
diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index c9dd973f43df..e49fe40f767f 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -292,4 +292,6 @@ bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev,
u8 *ksvs, u32 ksv_count);
int drm_connector_attach_content_protection_property(
struct drm_connector *connector, bool hdcp_content_type);
+void drm_hdcp_update_content_protection(struct drm_connector *connector,
+ u64 val);
#endif
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 04/10] drm/i915: SRM revocation check for HDCP1.4 and 2.2
DRM HDCP SRM revocation check services are used from I915 for HDCP1.4
and 2.2 revocation check during the respective authentication flow.
v2:
Rebased.
v3:
%s/*_ksvs_revocated/*_check_ksvs_revoked [Daniel]
unwanted noise is removed.
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 45 ++-
1 file changed, 38 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index b8c8d6d1a33d..8eb3bbb3fa7f 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -491,9 +491,11 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port
*intel_dig_port,
/* Implements Part 2 of the HDCP authorization procedure */
static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ const struct intel_hdcp_shim *shim = connector->hdcp.shim;
+ struct drm_device *dev = connector->base.dev;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
@@ -532,6 +534,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
if (ret)
goto err;
+ if (drm_hdcp_check_ksvs_revoked(dev, ksv_fifo, num_downstream)) {
+ DRM_ERROR("Revoked Ksv(s) in ksv_fifo\n");
+ return -EPERM;
+ }
+
/*
* When V prime mismatches, DP Spec mandates re-read of
* V prime atleast twice.
@@ -558,9 +565,12 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
}
/* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ struct drm_device *dev = connector->base.dev;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -626,6 +636,11 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
if (ret < 0)
return ret;
+ if (drm_hdcp_check_ksvs_revoked(dev, bksv.shim, 1)) {
+ DRM_ERROR("BKSV is revoked\n");
+ return -EPERM;
+ }
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
@@ -699,7 +714,7 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
*/
if (repeater_present)
- return intel_hdcp_auth_downstream(intel_dig_port, shim);
+ return intel_hdcp_auth_downstream(connector);
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -762,7 +777,7 @@ static int _intel_hdcp_enable(struct intel_connector
*connector)
/* Incase of authentication failures, HDCP spec expects reauth. */
for (i = 0; i < tries; i++) {
- ret = intel_hdcp_auth(conn_to_dig_port(connector), hdcp->shim);
+ ret = intel_hdcp_auth(connector);
if (!ret) {
hdcp->hdcp_encrypted = true;
return 0;
@@ -1161,6 +1176,7 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = &connector->hdcp;
+ struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_ake_init ake_init;
struct hdcp2_ake_send_cert send_cert;
@@ -1195,6 +1211,12 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
hdcp->is_repeater = HDCP_2_2_RX_REPEATER(msgs.send_cert.rx_caps[2]);
+ if (drm_hdcp_check_ksvs_revoked(dev, msgs.send_cert.cert_rx.receiver_id,
+ 1)) {
+ DRM_ERROR("Receiver ID is revoked\n");
+ return -EPERM;
+ }
+
/*
* Here msgs.no_stored_km will hold msgs corresponding to the km
* stored also.
@@ -1347,13 +1369,14 @@ int hdcp2_authenticate_repeater_topology(struct
intel_connector *connector)
{
struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
struct intel_hdcp *hdcp = &connector->hdcp;
+ struct drm_device *dev = connector->base.dev;
union {
struct hdcp2_rep_send_receiverid_list recvid_list;
struct hdcp2_rep_send_ack rep_ac
[Intel-gfx] [PATCH v6 08/10] drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
Need ACK from this uevent from userspace consumer.
v2:
Minor fixes at KDoc comments [Daniel]
v3:
Check the property is really attached with connector [Daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_sysfs.c | 35 +++
include/drm/drm_sysfs.h | 5 -
2 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..63fa951a20db 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -21,6 +21,7 @@
#include
#include
#include "drm_internal.h"
+#include "drm_crtc_internal.h"
#define to_drm_minor(d) dev_get_drvdata(d)
#define to_drm_connector(d) dev_get_drvdata(d)
@@ -320,6 +321,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -332,6 +336,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev. Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+ struct drm_device *dev = connector->dev;
+ char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+ char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+ WARN_ON(!drm_mode_obj_find_prop_id(&connector->base,
+ property->base.id));
+
+ snprintf(conn_id, ARRAY_SIZE(conn_id),
+"CONNECTOR=%u", connector->base.id);
+ snprintf(prop_id, ARRAY_SIZE(prop_id),
+"PROPERTY=%u", property->base.id);
+
+ DRM_DEBUG("generating connector status event\n");
+
+ kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
static void drm_sysfs_release(struct device *dev)
{
kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
struct drm_device;
struct device;
+struct drm_connector;
+struct drm_property;
int drm_class_device_register(struct device *dev);
void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
#endif
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 10/10] drm/i915: update the hdcp state with uevent
drm function to update the content protection property state and to
generate a uevent is invoked from the intel hdcp property work.
Hence whenever kernel changes the property state, userspace will be
updated with a uevent.
Need a ACK for uevent generating uAPI from userspace.
v2:
state update is moved into drm function [daniel]
Signed-off-by: Ramalingam C
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_hdcp.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index 2e159ffd17e6..f5c5ea921e8a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -865,7 +865,6 @@ static void intel_hdcp_prop_work(struct work_struct *work)
prop_work);
struct intel_connector *connector = intel_hdcp_to_connector(hdcp);
struct drm_device *dev = connector->base.dev;
- struct drm_connector_state *state;
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
mutex_lock(&hdcp->mutex);
@@ -875,10 +874,9 @@ static void intel_hdcp_prop_work(struct work_struct *work)
* those to UNDESIRED is handled by core. If value == UNDESIRED,
* we're running just after hdcp has been disabled, so just exit
*/
- if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
- state = connector->base.state;
- state->content_protection = hdcp->value;
- }
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ drm_hdcp_update_content_protection(&connector->base,
+ hdcp->value);
mutex_unlock(&hdcp->mutex);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/4] drm/i915: Fix the pipe state timing mismatch warnings
== Series Details == Series: series starting with [v3,1/4] drm/i915: Fix the pipe state timing mismatch warnings URL : https://patchwork.freedesktop.org/series/60186/ State : success == Summary == CI Bug Log - changes from CI_DRM_6025_full -> Patchwork_12933_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12933_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@system-suspend-modeset: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#108840] / [fdo#110581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@i915_pm_...@system-suspend-modeset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-iclb4/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-apl1/igt@i915_susp...@debugfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-apl3/igt@i915_susp...@debugfs-reader.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#103167]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-render.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#106978] / [fdo#107713] / [fdo#110581]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-glk5/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-iclb6/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_rotation_crc@multiplane-rotation: - shard-kbl: [PASS][13] -> [FAIL][14] ([fdo#109016]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-kbl3/igt@kms_rotation_...@multiplane-rotation.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-kbl5/igt@kms_rotation_...@multiplane-rotation.html * igt@kms_setmode@basic: - shard-kbl: [PASS][15] -> [FAIL][16] ([fdo#99912]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-kbl2/igt@kms_setm...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-kbl7/igt@kms_setm...@basic.html Possible fixes * igt@gem_ctx_switch@basic-all-light: - shard-apl: [INCOMPLETE][17] ([fdo#103927] / [fdo#110581]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-apl3/igt@gem_ctx_swi...@basic-all-light.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-apl7/igt@gem_ctx_swi...@basic-all-light.html * igt@kms_cursor_crc@cursor-128x128-suspend: - shard-apl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-apl3/igt@kms_cursor_...@cursor-128x128-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-apl4/igt@kms_cursor_...@cursor-128x128-suspend.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - shard-snb: [SKIP][21] ([fdo#109271]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-snb4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12933/shard-snb5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-iclb: [INCOMPLETE][23] ([fdo#107713] / [fdo#110581]) -> [PASS][24] [23]: https://intel
Re: [Intel-gfx] [PATCH 05/14] drm/i915: Remove delay for idle_work
Quoting Tvrtko Ursulin (2019-05-02 14:19:38)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
> > b/drivers/gpu/drm/i915/i915_gem_pm.c
> > index 49b0ce594f20..ae91ad7cb31e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_pm.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_pm.c
> > @@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private *i915)
> > static void idle_work_handler(struct work_struct *work)
> > {
> > struct drm_i915_private *i915 =
> > - container_of(work, typeof(*i915), gem.idle_work.work);
> > + container_of(work, typeof(*i915), gem.idle_work);
> >
> > mutex_lock(&i915->drm.struct_mutex);
> >
> > intel_wakeref_lock(&i915->gt.wakeref);
> > - if (!intel_wakeref_active(&i915->gt.wakeref))
> > + if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
>
> What is the reason for the !work_pending check?
Just that we are going to be called again, so wait until the next time to
see if we still need to park.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/14] drm/i915: Cancel retire_worker on parking
On 01/05/2019 12:45, Chris Wilson wrote:
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although that the igt is trying to idle from one child while submitting
from another may be a contributing factor as to why it runs so slowly...
Testcase: igt/gem_concurrent_blit
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index ae91ad7cb31e..b239b55f84cd 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
container_of(work, typeof(*i915), gem.idle_work);
+ bool restart = true;
+ cancel_delayed_work_sync(&i915->gem.retire_work);
mutex_lock(&i915->drm.struct_mutex);
You don't want to run another retire here? Since the retire worker might
have just been canceled I thought you should.
Regards,
Tvrtko
intel_wakeref_lock(&i915->gt.wakeref);
- if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
+ if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work)) {
i915_gem_park(i915);
+ restart = false;
+ }
intel_wakeref_unlock(&i915->gt.wakeref);
mutex_unlock(&i915->drm.struct_mutex);
+ if (restart)
+ queue_delayed_work(i915->wq,
+ &i915->gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static void retire_work_handler(struct work_struct *work)
@@ -52,10 +60,9 @@ static void retire_work_handler(struct work_struct *work)
mutex_unlock(&i915->drm.struct_mutex);
}
- if (intel_wakeref_active(&i915->gt.wakeref))
- queue_delayed_work(i915->wq,
- &i915->gem.retire_work,
- round_jiffies_up_relative(HZ));
+ queue_delayed_work(i915->wq,
+ &i915->gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static int pm_notifier(struct notifier_block *nb,
@@ -140,7 +147,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- drain_delayed_work(&i915->gem.retire_work);
GEM_BUG_ON(i915->gt.awake);
flush_work(&i915->gem.idle_work);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d919f512042c..9fd02025d382 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -58,7 +58,6 @@ static void mock_device_release(struct drm_device *dev)
i915_gem_contexts_lost(i915);
mutex_unlock(&i915->drm.struct_mutex);
- drain_delayed_work(&i915->gem.retire_work);
flush_work(&i915->gem.idle_work);
i915_gem_drain_workqueue(i915);
___
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: Assert breadcrumbs are correctly ordered in the signal handler
== Series Details == Series: drm/i915: Assert breadcrumbs are correctly ordered in the signal handler URL : https://patchwork.freedesktop.org/series/60187/ State : success == Summary == CI Bug Log - changes from CI_DRM_6025_full -> Patchwork_12934_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12934_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-apl4/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-apl3/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#110581]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl2/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-skl9/igt@gem_...@unwedge-stress.html * igt@i915_pm_rpm@cursor: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807] / [fdo#110581]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl2/igt@i915_pm_...@cursor.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-skl10/igt@i915_pm_...@cursor.html * igt@kms_cursor_crc@cursor-128x42-offscreen: - shard-glk: [PASS][7] -> [INCOMPLETE][8] ([fdo#103359] / [fdo#110581] / [k.org#198133]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk9/igt@kms_cursor_...@cursor-128x42-offscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-glk6/igt@kms_cursor_...@cursor-128x42-offscreen.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#102670]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl2/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-skl9/igt@kms_cursor_leg...@flip-vs-cursor-atomic.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#100368]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-skl5/igt@kms_f...@plain-flip-fb-recreate-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-skl5/igt@kms_f...@plain-flip-fb-recreate-interruptible.html * igt@kms_flip_tiling@flip-changes-tiling: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#110581]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_flip_til...@flip-changes-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-iclb5/igt@kms_flip_til...@flip-changes-tiling.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#106978] / [fdo#107713] / [fdo#110581]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping: - shard-glk: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-glk9/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-glk6/igt@kms_pl...@pixel-format-pipe-b-planes-source-clamping.html * igt@kms_psr@psr2_cursor_plane_onoff: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb2/igt@kms_psr@psr2_cursor_plane_onoff.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-iclb5/igt@kms_psr@psr2_cursor_plane_onoff.html * igt@kms_sysfs_edid_timing: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#100047]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6025/shard-iclb1/igt@kms_sysfs_edid_timing.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12934/shard-iclb2/igt@kms_
[Intel-gfx] [v4 3/4] drm/i915: Fix pipe config mismatch for bpp, output format
Read back the pixel fomrat register and get the bpp.
v2: Read the PIPE_MISC register (Jani).
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/icl_dsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index 45fe69c..cd6a4f3 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1226,6 +1226,7 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
/* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */
@@ -1234,6 +1235,7 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->base.adjusted_mode.crtc_clock = intel_dsi->pclk;
gen11_dsi_get_timings(encoder, pipe_config);
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
+ pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc);
}
static int gen11_dsi_compute_config(struct intel_encoder *encoder,
@@ -1249,6 +1251,7 @@ static int gen11_dsi_compute_config(struct intel_encoder
*encoder,
struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
+ pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
intel_fixed_panel_mode(fixed_mode, adjusted_mode);
intel_pch_panel_fitting(crtc, pipe_config, conn_state->scaling_mode);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/14] drm/i915: Cancel retire_worker on parking
Quoting Tvrtko Ursulin (2019-05-02 14:29:50)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > Replace the racy continuation check within retire_work with a definite
> > kill-switch on idling. The race was being exposed by gem_concurrent_blit
> > where the retire_worker would be terminated too early leaving us
> > spinning in debugfs/i915_drop_caches with nothing flushing the
> > retirement queue.
> >
> > Although that the igt is trying to idle from one child while submitting
> > from another may be a contributing factor as to why it runs so slowly...
> >
> > Testcase: igt/gem_concurrent_blit
> > Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
> > .../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
> > 2 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
> > b/drivers/gpu/drm/i915/i915_gem_pm.c
> > index ae91ad7cb31e..b239b55f84cd 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_pm.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_pm.c
> > @@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
> > {
> > struct drm_i915_private *i915 =
> > container_of(work, typeof(*i915), gem.idle_work);
> > + bool restart = true;
> >
> > + cancel_delayed_work_sync(&i915->gem.retire_work);
> > mutex_lock(&i915->drm.struct_mutex);
> >
>
> You don't want to run another retire here? Since the retire worker might
> have just been canceled I thought you should.
Why though? If there are retires outstanding, we won't sleep and want to
defer parking until after the next cycle.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/14] drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
On 01/05/2019 12:45, Chris Wilson wrote:
If the user is racing a call to debugfs/i915_drop_caches with ongoing
submission from another thread/process, we may never end up idling the
GPU and be uninterruptibly spinning in debugfs/i915_drop_caches trying
to catch an idle moment.
Just flush the work once, that should be enough to park the system under
correct conditions. Outside of those we either have a driver bug or the
user is racing themselves. Sadly, because the user may be provoking the
unwanted situation we can't put a warn here to attract attention to a
probable bug.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7e8898d0b78b..2ecefacb1e66 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3933,9 +3933,7 @@ i915_drop_caches_set(void *data, u64 val)
fs_reclaim_release(GFP_KERNEL);
if (val & DROP_IDLE) {
- do {
- flush_delayed_work(&i915->gem.retire_work);
- } while (READ_ONCE(i915->gt.awake));
+ flush_delayed_work(&i915->gem.retire_work);
flush_work(&i915->gem.idle_work);
}
What were supposed to be semantics of DROP_IDLE? Now it seems rather
weak. Should it for instance also imply DROP_ACTIVE?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel, A quick fix to unbreak media driver, worthy inclusion before the merge window. Best Regards, Joonas *** drm-intel-next-fixes-2019-05-02: - Whitelist a register to avoid media driver from hanging The following changes since commit 879a4e70f96a26a9368a3caed2f552aa67105852: drm/i915: Fix ICL output CSC programming (2019-04-29 09:49:21 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-05-02 for you to fetch changes up to 9628e15ca9d5f7595ba886173e98a139d0a56cd1: drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 (2019-04-30 10:16:18 +0300) - Whitelist a register to avoid media driver from hanging Tvrtko Ursulin (1): drm/i915/icl: Whitelist GEN9_SLICE_COMMON_ECO_CHICKEN1 drivers/gpu/drm/i915/intel_workarounds.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v4 2/4] drm/i915: Refactor bdw_get_pipemisc_bpp
Move bdw_get_pipemisc_bpp alongside bdw_set_pipemisc
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/intel_display.c | 22 ++
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/vlv_dsi.c | 22 --
3 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 40b8151..de6d209 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8944,6 +8944,28 @@ static void bdw_set_pipemisc(const struct
intel_crtc_state *crtc_state)
I915_WRITE(PIPEMISC(crtc->pipe), val);
}
+int bdw_get_pipemisc_bpp(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ u32 tmp;
+
+ tmp = I915_READ(PIPEMISC(crtc->pipe));
+
+ switch (tmp & PIPEMISC_DITHER_BPC_MASK) {
+ case PIPEMISC_DITHER_6_BPC:
+ return 18;
+ case PIPEMISC_DITHER_8_BPC:
+ return 24;
+ case PIPEMISC_DITHER_10_BPC:
+ return 30;
+ case PIPEMISC_DITHER_12_BPC:
+ return 36;
+ default:
+ MISSING_CASE(tmp);
+ return 0;
+ }
+}
+
int ironlake_get_lanes_required(int target_clock, int link_bw, int bpp)
{
/*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 57ae396..ba75842 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1759,6 +1759,7 @@ u32 skl_plane_stride(const struct intel_plane_state
*plane_state,
unsigned int i9xx_plane_max_stride(struct intel_plane *plane,
u32 pixel_format, u64 modifier,
unsigned int rotation);
+int bdw_get_pipemisc_bpp(struct intel_crtc *crtc);
/* intel_runtime_pm.c */
static inline void
diff --git a/drivers/gpu/drm/i915/vlv_dsi.c b/drivers/gpu/drm/i915/vlv_dsi.c
index bc5b782..895ea1a 100644
--- a/drivers/gpu/drm/i915/vlv_dsi.c
+++ b/drivers/gpu/drm/i915/vlv_dsi.c
@@ -262,28 +262,6 @@ static void band_gap_reset(struct drm_i915_private
*dev_priv)
vlv_flisdsi_put(dev_priv);
}
-static int bdw_get_pipemisc_bpp(struct intel_crtc *crtc)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- u32 tmp;
-
- tmp = I915_READ(PIPEMISC(crtc->pipe));
-
- switch (tmp & PIPEMISC_DITHER_BPC_MASK) {
- case PIPEMISC_DITHER_6_BPC:
- return 18;
- case PIPEMISC_DITHER_8_BPC:
- return 24;
- case PIPEMISC_DITHER_10_BPC:
- return 30;
- case PIPEMISC_DITHER_12_BPC:
- return 36;
- default:
- MISSING_CASE(tmp);
- return 0;
- }
-}
-
static int intel_dsi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v4 1/4] drm/i915: Fix the pipe state timing mismatch warnings
Adjust the get transcoder timings for mipi dsi as per the
set timing calculations.
v2: Use the existing intel_get_pipe_timings and do the dsi
specific adjustments in the encoder get_config hook.(Ville, Jani)
v3: Exclude VBLANK and HBLANK registers for dsi transcoder.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/icl_dsi.c | 29 +
drivers/gpu/drm/i915/intel_display.c | 20 ++--
2 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index c6ecc00..45fe69c 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1194,6 +1194,34 @@ static void gen11_dsi_disable(struct intel_encoder
*encoder,
gen11_dsi_disable_io_power(encoder);
}
+static void gen11_dsi_get_timings(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
+{
+ struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
+ struct drm_display_mode *adjusted_mode =
+ &pipe_config->base.adjusted_mode;
+
+ if (intel_dsi->dual_link) {
+ adjusted_mode->crtc_hdisplay *= 2;
+ if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK)
+ adjusted_mode->crtc_hdisplay -=
+ intel_dsi->pixel_overlap;
+ adjusted_mode->crtc_htotal *= 2;
+ }
+ adjusted_mode->crtc_hblank_start = adjusted_mode->crtc_hdisplay;
+ adjusted_mode->crtc_hblank_end = adjusted_mode->crtc_htotal;
+
+ if (intel_dsi->operation_mode == INTEL_DSI_VIDEO_MODE) {
+ if (intel_dsi->dual_link) {
+ adjusted_mode->crtc_hsync_start *= 2;
+ adjusted_mode->crtc_hsync_end *= 2;
+ }
+ }
+ adjusted_mode->crtc_vblank_start = adjusted_mode->crtc_vdisplay;
+ adjusted_mode->crtc_vblank_end = adjusted_mode->crtc_vtotal;
+
+}
+
static void gen11_dsi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -1204,6 +1232,7 @@ static void gen11_dsi_get_config(struct intel_encoder
*encoder,
pipe_config->port_clock =
cnl_calc_wrpll_link(dev_priv, &pipe_config->dpll_hw_state);
pipe_config->base.adjusted_mode.crtc_clock = intel_dsi->pclk;
+ gen11_dsi_get_timings(encoder, pipe_config);
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dd65d7c..40b8151 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7736,9 +7736,13 @@ static void intel_get_pipe_timings(struct intel_crtc
*crtc,
tmp = I915_READ(HTOTAL(cpu_transcoder));
pipe_config->base.adjusted_mode.crtc_hdisplay = (tmp & 0x) + 1;
pipe_config->base.adjusted_mode.crtc_htotal = ((tmp >> 16) & 0x) +
1;
- tmp = I915_READ(HBLANK(cpu_transcoder));
- pipe_config->base.adjusted_mode.crtc_hblank_start = (tmp & 0x) + 1;
- pipe_config->base.adjusted_mode.crtc_hblank_end = ((tmp >> 16) &
0x) + 1;
+
+ if (!transcoder_is_dsi(cpu_transcoder))
+ tmp = I915_READ(HBLANK(cpu_transcoder));
+ pipe_config->base.adjusted_mode.crtc_hblank_start =
+ (tmp & 0x) + 1;
+ pipe_config->base.adjusted_mode.crtc_hblank_end =
+ ((tmp >> 16) & 0x) + 1;
tmp = I915_READ(HSYNC(cpu_transcoder));
pipe_config->base.adjusted_mode.crtc_hsync_start = (tmp & 0x) + 1;
pipe_config->base.adjusted_mode.crtc_hsync_end = ((tmp >> 16) & 0x)
+ 1;
@@ -7746,9 +7750,13 @@ static void intel_get_pipe_timings(struct intel_crtc
*crtc,
tmp = I915_READ(VTOTAL(cpu_transcoder));
pipe_config->base.adjusted_mode.crtc_vdisplay = (tmp & 0x) + 1;
pipe_config->base.adjusted_mode.crtc_vtotal = ((tmp >> 16) & 0x) +
1;
- tmp = I915_READ(VBLANK(cpu_transcoder));
- pipe_config->base.adjusted_mode.crtc_vblank_start = (tmp & 0x) + 1;
- pipe_config->base.adjusted_mode.crtc_vblank_end = ((tmp >> 16) &
0x) + 1;
+
+ if (!transcoder_is_dsi(cpu_transcoder))
+ tmp = I915_READ(VBLANK(cpu_transcoder));
+ pipe_config->base.adjusted_mode.crtc_vblank_start =
+ (tmp & 0x) + 1;
+ pipe_config->base.adjusted_mode.crtc_vblank_end =
+ ((tmp >> 16) & 0x) + 1;
tmp = I915_READ(VSYNC(cpu_transcoder));
pipe_config->base.adjusted_mode.crtc_vsync_start = (tmp & 0x) + 1;
pipe_config->base.adjusted_mode.crtc_vsync_end = ((tmp >> 16) & 0x
Re: [Intel-gfx] [PATCH v6 00/10] HDCP2.2 Phase II
On 2019-05-02 at 18:52:53 +0530, Ramalingam C wrote: > This series adds the content type capability for HDCP through a > drm connetor proeprty "HDCP Content Type". By default this property will > be "Type 0". And this property is exposed by the drivers which has the > HDCP2.2 capability to enable the userspace to configure for "Type 1". > > HDCP Content Type: > This property is used to indicate the content type > classification of a stream. Which indicate the HDCP version required > for the rendering of that streams. This conten type is one of the > parameter in the HDCP2.2 authentication flow, as even downstream > repeaters will mandate the HDCP version requirement. > > Two values possible for content type of a stream: > Type 0: Stream can be rendered only on HDCP encrypted link no > restriction on HDCP versions. > Type 1: Stream can be rendered only on HDCP2.2 encrypted link. > > And also this series adds a uevent for a change in the property state > change of a connector. This helps the userspace to monitor the uevent > for a proeprty state change than the trivial polling. > > Userspace consumer for above "HDCP Content Type" property and uevent is > almost at the last phase of review at #wayland community. So Patches 6, > 7, 8, 9 and 10 can be merged only when patches in #wayland community > receives the ACK. > > HDCP SRM is implemented through request_firmware() interface. Hence > userspace is expected to write the signature validated latest available > SRM table into /lib/firmware/ as "display_hdcp_srm.bin". On every HDCP > authentication kernel will read the SRM from above mentioned file and > do the revocation check. > > And also this series gathers all HDCP related DRM code into drm_hdcp.c > > Thanks Daniel Vetter for all the reviews. Daniel, Could you please review https://patchwork.freedesktop.org/patch/303048/?series=57232&rev=8 And for all other patches I have imcorporated all your suggestions and added your Rbed-by. Please have a look. Thanks and Regards, -Ram > > Series can be cloned from github > https://github.com/ramalingampc2008/drm-tip.git hdcp2_2_p2_v6 > > Test-with: <20190502131625.27551-2-ramalinga...@intel.com> > > Ramalingam C (10): > drm: move content protection property to mode_config > drm/i915: debugfs: HDCP2.2 capability read > drm: revocation check at drm subsystem > drm/i915: SRM revocation check for HDCP1.4 and 2.2 > drm/hdcp: gathering hdcp related code into drm_hdcp.c > drm: Add Content protection type property > drm/i915: Attach content type property > drm: uevent for connector status change > drm/hdcp: update content protection property with uevent > drm/i915: update the hdcp state with uevent > > Documentation/gpu/drm-kms-helpers.rst | 6 + > drivers/gpu/drm/Makefile | 2 +- > drivers/gpu/drm/drm_atomic_uapi.c | 8 +- > drivers/gpu/drm/drm_connector.c | 61 +--- > drivers/gpu/drm/drm_hdcp.c| 455 ++ > drivers/gpu/drm/drm_internal.h| 4 + > drivers/gpu/drm/drm_sysfs.c | 37 +++ > drivers/gpu/drm/i915/i915_debugfs.c | 13 +- > drivers/gpu/drm/i915/intel_ddi.c | 37 ++- > drivers/gpu/drm/i915/intel_hdcp.c | 100 -- > drivers/gpu/drm/i915/intel_hdcp.h | 3 +- > include/drm/drm_connector.h | 15 +- > include/drm/drm_hdcp.h| 29 ++ > include/drm/drm_mode_config.h | 12 + > include/drm/drm_sysfs.h | 5 +- > include/uapi/drm/drm_mode.h | 4 + > 16 files changed, 699 insertions(+), 92 deletions(-) > create mode 100644 drivers/gpu/drm/drm_hdcp.c > > -- > 2.19.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v4 4/4] drm/i915: Fix pixel clock and crtc clock config mismatch
In case of dual link mode, the mode clock that we get from the VBT is halved. v2: Simplify the calculation (Jani). Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/i915/icl_dsi.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c index cd6a4f3..46b3d30 100644 --- a/drivers/gpu/drm/i915/icl_dsi.c +++ b/drivers/gpu/drm/i915/icl_dsi.c @@ -1232,7 +1232,11 @@ static void gen11_dsi_get_config(struct intel_encoder *encoder, /* FIXME: adapt icl_ddi_clock_get() for DSI and use that? */ pipe_config->port_clock = cnl_calc_wrpll_link(dev_priv, &pipe_config->dpll_hw_state); + pipe_config->base.adjusted_mode.crtc_clock = intel_dsi->pclk; + if (intel_dsi->dual_link) + pipe_config->base.adjusted_mode.crtc_clock *= 2; + gen11_dsi_get_timings(encoder, pipe_config); pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI); pipe_config->pipe_bpp = bdw_get_pipemisc_bpp(crtc); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/14] drm/i915: Include fence signaled bit in print_request()
On 01/05/2019 12:45, Chris Wilson wrote: Show the fence flags view of request completion in addition to the normal hwsp check and whether signaling is enabled. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 6e40f8ea9a6a..f178f1268f4e 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -1229,8 +1229,11 @@ static void print_request(struct drm_printer *m, i915_request_completed(rq) ? "!" : i915_request_started(rq) ? "*" : "", + test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, + &rq->fence.flags) ? "+" : test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, - &rq->fence.flags) ? "+" : "", + &rq->fence.flags) ? "-" : + "", buf, jiffies_to_msecs(jiffies - rq->emitted_jiffies), name); We need a decoding cheat sheet now.. Reviewed-by: Tvrtko Ursulin Can we make it somewhat self-explanatory? Maybe only in my head.. ">-|" (started/signaling enabled/completed) ">+" (started/signaled) Imagine more fun if completed would be '<'. :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] mm/pgtable: Drop pgtable_t variable from pte_fn_t functions
On Thu, May 02, 2019 at 06:48:46PM +0530, Anshuman Khandual wrote:
> Drop the pgtable_t variable from all implementation for pte_fn_t as none of
> them use it. apply_to_pte_range() should stop computing it as well. Should
> help us save some cycles.
You didn't add Martin Schwidefsky for some reason. He introduced
it originally for s390 for sub-page page tables back in 2008 (commit
2f569afd9c). I think he should confirm that he no longer needs it.
> ---
> - Boot tested on arm64 and x86 platforms.
> - Build tested on multiple platforms with their defconfig
>
> arch/arm/kernel/efi.c | 3 +--
> arch/arm/mm/dma-mapping.c | 3 +--
> arch/arm/mm/pageattr.c | 3 +--
> arch/arm64/kernel/efi.c| 3 +--
> arch/arm64/mm/pageattr.c | 3 +--
> arch/x86/xen/mmu_pv.c | 3 +--
> drivers/gpu/drm/i915/i915_mm.c | 3 +--
> drivers/xen/gntdev.c | 6 ++
> drivers/xen/privcmd.c | 6 ++
> drivers/xen/xlate_mmu.c| 3 +--
> include/linux/mm.h | 3 +--
> mm/memory.c| 5 +
> mm/vmalloc.c | 2 +-
> 13 files changed, 15 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
> index 9f43ba012d10..b1f142a01f2f 100644
> --- a/arch/arm/kernel/efi.c
> +++ b/arch/arm/kernel/efi.c
> @@ -11,8 +11,7 @@
> #include
> #include
>
> -static int __init set_permissions(pte_t *ptep, pgtable_t token,
> - unsigned long addr, void *data)
> +static int __init set_permissions(pte_t *ptep, unsigned long addr, void
> *data)
> {
> efi_memory_desc_t *md = data;
> pte_t pte = *ptep;
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 43f46aa7ef33..739286511a18 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -496,8 +496,7 @@ void __init dma_contiguous_remap(void)
> }
> }
>
> -static int __dma_update_pte(pte_t *pte, pgtable_t token, unsigned long addr,
> - void *data)
> +static int __dma_update_pte(pte_t *pte, unsigned long addr, void *data)
> {
> struct page *page = virt_to_page(addr);
> pgprot_t prot = *(pgprot_t *)data;
> diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
> index 1403cb4a0c3d..c8b500940e1f 100644
> --- a/arch/arm/mm/pageattr.c
> +++ b/arch/arm/mm/pageattr.c
> @@ -22,8 +22,7 @@ struct page_change_data {
> pgprot_t clear_mask;
> };
>
> -static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long
> addr,
> - void *data)
> +static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
> {
> struct page_change_data *cdata = data;
> pte_t pte = *ptep;
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 4f9acb5fbe97..230cff073a08 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -86,8 +86,7 @@ int __init efi_create_mapping(struct mm_struct *mm,
> efi_memory_desc_t *md)
> return 0;
> }
>
> -static int __init set_permissions(pte_t *ptep, pgtable_t token,
> - unsigned long addr, void *data)
> +static int __init set_permissions(pte_t *ptep, unsigned long addr, void
> *data)
> {
> efi_memory_desc_t *md = data;
> pte_t pte = READ_ONCE(*ptep);
> diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
> index 6cd645edcf35..0be077628b21 100644
> --- a/arch/arm64/mm/pageattr.c
> +++ b/arch/arm64/mm/pageattr.c
> @@ -27,8 +27,7 @@ struct page_change_data {
>
> bool rodata_full __ro_after_init =
> IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED);
>
> -static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long
> addr,
> - void *data)
> +static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
> {
> struct page_change_data *cdata = data;
> pte_t pte = READ_ONCE(*ptep);
> diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
> index a21e1734fc1f..308a6195fd26 100644
> --- a/arch/x86/xen/mmu_pv.c
> +++ b/arch/x86/xen/mmu_pv.c
> @@ -2702,8 +2702,7 @@ struct remap_data {
> struct mmu_update *mmu_update;
> };
>
> -static int remap_area_pfn_pte_fn(pte_t *ptep, pgtable_t token,
> - unsigned long addr, void *data)
> +static int remap_area_pfn_pte_fn(pte_t *ptep, unsigned long addr, void *data)
> {
> struct remap_data *rmd = data;
> pte_t pte = pte_mkspecial(mfn_pte(*rmd->pfn, rmd->prot));
> diff --git a/drivers/gpu/drm/i915/i915_mm.c b/drivers/gpu/drm/i915/i915_mm.c
> index e4935dd1fd37..c23bb29e6d3e 100644
> --- a/drivers/gpu/drm/i915/i915_mm.c
> +++ b/drivers/gpu/drm/i915/i915_mm.c
> @@ -35,8 +35,7 @@ struct remap_pfn {
> pgprot_t prot;
> };
>
> -static int remap_pfn(pte_t *pte, pgtable_t token,
> - unsigned long addr, void *data)
> +static int remap_pfn(pte_t *pte, unsigned long addr, void *data)
> {
> str
Re: [Intel-gfx] [PATCH 03/14] drm/i915/execlists: Flush the tasklet on parking
On 01/05/2019 12:45, Chris Wilson wrote:
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 851e62ddcb87..7be54b868d8e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct i915_request *rq)
return i915_gem_render_state_emit(rq);
}
+static void execlists_park(struct intel_engine_cs *engine)
+{
+ tasklet_kill(&engine->execlists.tasklet);
Isn't it actually a problem if tasklet is scheduled and unstarted, or
even in progress at the point of engine getting parked?
Regards,
Tvrtko
+}
+
void intel_execlists_set_default_submission(struct intel_engine_cs *engine)
{
engine->submit_request = execlists_submit_request;
@@ -2342,7 +2347,7 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
engine->reset.reset = execlists_reset;
engine->reset.finish = execlists_reset_finish;
- engine->park = NULL;
+ engine->park = execlists_park;
engine->unpark = NULL;
engine->flags |= I915_ENGINE_SUPPORTS_STATS;
diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c
b/drivers/gpu/drm/i915/intel_guc_submission.c
index 4c814344809c..ed94001028f2 100644
--- a/drivers/gpu/drm/i915/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/intel_guc_submission.c
@@ -1363,6 +1363,7 @@ static void guc_interrupts_release(struct
drm_i915_private *dev_priv)
static void guc_submission_park(struct intel_engine_cs *engine)
{
+ tasklet_kill(&engine->execlists.tasklet);
intel_engine_unpin_breadcrumbs_irq(engine);
engine->flags &= ~I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/14] drm/i915: Remove delay for idle_work
On 02/05/2019 14:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 14:19:38)
On 01/05/2019 12:45, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 49b0ce594f20..ae91ad7cb31e 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private *i915)
static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
- container_of(work, typeof(*i915), gem.idle_work.work);
+ container_of(work, typeof(*i915), gem.idle_work);
mutex_lock(&i915->drm.struct_mutex);
intel_wakeref_lock(&i915->gt.wakeref);
- if (!intel_wakeref_active(&i915->gt.wakeref))
+ if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
What is the reason for the !work_pending check?
Just that we are going to be called again, so wait until the next time to
see if we still need to park.
When does it get called again? If a whole new cycle of unpark-park
happened before the previous park was able to finish?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915/execlists: Flush the tasklet on parking
Quoting Tvrtko Ursulin (2019-05-02 14:48:18)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > Tidy up the cleanup sequence by always ensure that the tasklet is
> > flushed on parking (before we cleanup). The parking provides a
> > convenient point to ensure that the backend is truly idle.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
> > drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 851e62ddcb87..7be54b868d8e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct i915_request
> > *rq)
> > return i915_gem_render_state_emit(rq);
> > }
> >
> > +static void execlists_park(struct intel_engine_cs *engine)
> > +{
> > + tasklet_kill(&engine->execlists.tasklet);
>
> Isn't it actually a problem if tasklet is scheduled and unstarted, or
> even in progress at the point of engine getting parked?
That would be a broken driver. :|
We must be quite sure that engine isn't going to send an interrupt as we
are just about to drop the wakeref we need to service that interrupt.
tasklet_kill()
GEM_BUG_ON(engine->execlists.active);
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP2.2 Phase II (rev8)
== Series Details ==
Series: HDCP2.2 Phase II (rev8)
URL : https://patchwork.freedesktop.org/series/57232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d32d7d16faa9 drm: move content protection property to mode_config
7c8e2a00dcfb drm/i915: debugfs: HDCP2.2 capability read
a5b17cb4ee04 drm: revocation check at drm subsystem
-:57: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#57:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 411 lines checked
81c292f4a663 drm/i915: SRM revocation check for HDCP1.4 and 2.2
d3f799e34d25 drm/hdcp: gathering hdcp related code into drm_hdcp.c
-:104: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#104: FILE: drivers/gpu/drm/drm_hdcp.c:352:
+};
+DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-:121: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#121: FILE: drivers/gpu/drm/drm_hdcp.c:369:
+int drm_connector_attach_content_protection_property(
-:167: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#167: FILE: include/drm/drm_hdcp.h:293:
+int drm_connector_attach_content_protection_property(
total: 0 errors, 0 warnings, 3 checks, 130 lines checked
98ef28b2c4cf drm: Add Content protection type property
-:98: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#98: FILE: drivers/gpu/drm/drm_hdcp.c:358:
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
-:143: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#143: FILE: drivers/gpu/drm/drm_hdcp.c:411:
+ prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
+ drm_hdcp_content_type_enum_list,
-:144: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#144: FILE: drivers/gpu/drm/drm_hdcp.c:412:
+ ARRAY_SIZE(
total: 0 errors, 0 warnings, 3 checks, 161 lines checked
d62727632f63 drm/i915: Attach content type property
d9d60b9cf1f2 drm: uevent for connector status change
0883f3d8b956 drm/hdcp: update content protection property with uevent
-:64: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#64: FILE: drivers/gpu/drm/drm_hdcp.c:453:
+ drm_sysfs_connector_status_event(connector,
+dev->mode_config.content_protection_property);
total: 0 errors, 0 warnings, 1 checks, 47 lines checked
d2f45ad5ba5d drm/i915: update the hdcp state with uevent
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/14] drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
Quoting Tvrtko Ursulin (2019-05-02 14:34:11)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > If the user is racing a call to debugfs/i915_drop_caches with ongoing
> > submission from another thread/process, we may never end up idling the
> > GPU and be uninterruptibly spinning in debugfs/i915_drop_caches trying
> > to catch an idle moment.
> >
> > Just flush the work once, that should be enough to park the system under
> > correct conditions. Outside of those we either have a driver bug or the
> > user is racing themselves. Sadly, because the user may be provoking the
> > unwanted situation we can't put a warn here to attract attention to a
> > probable bug.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 7e8898d0b78b..2ecefacb1e66 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -3933,9 +3933,7 @@ i915_drop_caches_set(void *data, u64 val)
> > fs_reclaim_release(GFP_KERNEL);
> >
> > if (val & DROP_IDLE) {
> > - do {
> > - flush_delayed_work(&i915->gem.retire_work);
> > - } while (READ_ONCE(i915->gt.awake));
> > + flush_delayed_work(&i915->gem.retire_work);
> > flush_work(&i915->gem.idle_work);
> > }
> >
> >
>
> What were supposed to be semantics of DROP_IDLE? Now it seems rather
> weak. Should it for instance also imply DROP_ACTIVE?
All I need for DROP_IDLE is that the idle worker is flushed. I've always
assumed you would pass in DROP_ACTIVE | DROP_RETIRE | DROP_IDLE as the
trifecta.
The biggest problem here is that's it is an uninterruptible loop.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP2.2 Phase II (rev8)
== Series Details == Series: HDCP2.2 Phase II (rev8) URL : https://patchwork.freedesktop.org/series/57232/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm: move content protection property to mode_config Okay! Commit: drm/i915: debugfs: HDCP2.2 capability read Okay! Commit: drm: revocation check at drm subsystem +drivers/gpu/drm/drm_hdcp.c:236:6: warning: symbol 'drm_hdcp_request_srm' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:29:3: warning: symbol 'srm_data' was not declared. Should it be static? +drivers/gpu/drm/drm_hdcp.c:335:6: warning: symbol 'drm_teardown_hdcp_srm' was not declared. Should it be static? +./include/linux/slab.h:666:13: error: not a function +./include/linux/slab.h:666:13: error: not a function +./include/linux/slab.h:666:13: error: undefined identifier '__builtin_mul_overflow' +./include/linux/slab.h:666:13: warning: call with no type! Commit: drm/i915: SRM revocation check for HDCP1.4 and 2.2 Okay! Commit: drm/hdcp: gathering hdcp related code into drm_hdcp.c Okay! Commit: drm: Add Content protection type property Okay! Commit: drm/i915: Attach content type property Okay! Commit: drm: uevent for connector status change Okay! Commit: drm/hdcp: update content protection property with uevent Okay! Commit: drm/i915: update the hdcp state with uevent Okay! ___ 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/dp: use logical operators with boolean type
== Series Details == Series: drm/i915/dp: use logical operators with boolean type URL : https://patchwork.freedesktop.org/series/60190/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6026 -> Patchwork_12935 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_12935 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_12935, 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/60190/revisions/1/mbox/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_12935: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-icl-u3: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/fi-icl-u3/igt@run...@aborted.html Warnings * igt@gem_exec_suspend@basic-s3: - fi-apl-guc: [DMESG-WARN][2] ([fdo#110512]) -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html Known issues Here are the changes found in Patchwork_12935 that come from known issues: ### IGT changes ### Issues hit * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-apl-guc: [PASS][4] -> [DMESG-WARN][5] ([fdo#110512]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/fi-apl-guc/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [DMESG-WARN][6] ([fdo#108965]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [INCOMPLETE][8] ([fdo#107718] / [fdo#110581]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][10] ([fdo#108602] / [fdo#108744] / [fdo#110581]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#110512]: https://bugs.freedesktop.org/show_bug.cgi?id=110512 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (52 -> 46) -- Additional (1): fi-byt-j1900 Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6026 -> Patchwork_12935 CI_DRM_6026: 2d2d8d3b9d8896c99c88307a881120885afd2ddb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12935: a0c6eb96eafc2476ab98276783fc1509c44e37b3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a0c6eb96eafc drm/i915/dp: use logical operators with boolean type == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12935/ ___ 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/execlists: Unshadow MI_USER_INTERRUPT
== Series Details == Series: drm/i915/execlists: Unshadow MI_USER_INTERRUPT URL : https://patchwork.freedesktop.org/series/60192/ State : success == Summary == CI Bug Log - changes from CI_DRM_6026 -> Patchwork_12936 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/60192/revisions/1/mbox/ Known issues Here are the changes found in Patchwork_12936 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][1] -> [DMESG-WARN][2] ([fdo#107709]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-bsw-kefka/igt@i915_selftest@live_evict.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12936/fi-bsw-kefka/igt@i915_selftest@live_evict.html Possible fixes * igt@amdgpu/amd_basic@userptr: - fi-kbl-8809g: [DMESG-WARN][3] ([fdo#108965]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12936/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718] / [fdo#110581]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12936/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][7] ([fdo#108602] / [fdo#108744] / [fdo#110581]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12936/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965 [fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581 Participating hosts (52 -> 45) -- Additional (1): fi-byt-j1900 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6026 -> Patchwork_12936 CI_DRM_6026: 2d2d8d3b9d8896c99c88307a881120885afd2ddb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12936: c533a8e9146df2845199dfcfb32ec6bc695cacb3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c533a8e9146d drm/i915/execlists: Unshadow MI_USER_INTERRUPT == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12936/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
== Series Details ==
Series: drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
URL : https://patchwork.freedesktop.org/series/60195/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6026 -> Patchwork_12937
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/60195/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12937 that come from known issues:
### IGT changes ###
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: [DMESG-WARN][1] ([fdo#108965]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12937/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [INCOMPLETE][3] ([fdo#107718] / [fdo#110581]) ->
[PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12937/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][5] ([fdo#108602] / [fdo#108744] /
[fdo#110581]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12937/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103841]: https://bugs.freedesktop.org/show_bug.cgi?id=103841
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
Participating hosts (52 -> 45)
--
Additional (1): fi-byt-j1900
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-apl-guc fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6026 -> Patchwork_12937
CI_DRM_6026: 2d2d8d3b9d8896c99c88307a881120885afd2ddb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12937: 0809bda74a2027f28cd5aa06bafd0d08c3b0281e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0809bda74a20 drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12937/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: hsw+ audio regs are per-transocder
On Thu, May 02, 2019 at 03:16:37PM +0300, Jani Nikula wrote: > On Tue, 30 Apr 2019, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > s/pipe/transcoder/ when dealing with hsw+ audio registers. This > > won't actually make any real difference since there is no audio > > on the EDP transcoder. But this should avoid a bit of confusion > > when cross checking against the spec. > > > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Jani Nikula Thanks. Series pushed to dinq. -- 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 drm/i915: Tune down WARN about incorrect VBT TC legacy flag
== Series Details ==
Series: drm/i915: Tune down WARN about incorrect VBT TC legacy flag
URL : https://patchwork.freedesktop.org/series/60197/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6026 -> Patchwork_12938
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/60197/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12938:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@dp-crc-fast:
- {fi-icl-u2}:NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12938/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@runner@aborted:
- {fi-icl-u2}:[FAIL][2] ([fdo#110578] / [k.org#202973]) -> [FAIL][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-icl-u2/igt@run...@aborted.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12938/fi-icl-u2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_12938 that come from known issues:
### IGT changes ###
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: [DMESG-WARN][4] ([fdo#108965]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12938/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#110578]: https://bugs.freedesktop.org/show_bug.cgi?id=110578
[k.org#202973]: https://bugzilla.kernel.org/show_bug.cgi?id=202973
Participating hosts (52 -> 46)
--
Additional (1): fi-byt-j1900
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_6026 -> Patchwork_12938
CI_DRM_6026: 2d2d8d3b9d8896c99c88307a881120885afd2ddb @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4972: f052e49a43cc9704ea5f240df15dd9d3dfed68ab @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12938: 51220cd2ff773c282dd02aef53c605577f5ce73d @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
51220cd2ff77 drm/i915: Tune down WARN about incorrect VBT TC legacy flag
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12938/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915/execlists: Flush the tasklet on parking
On 02/05/2019 14:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 14:48:18)
On 01/05/2019 12:45, Chris Wilson wrote:
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 851e62ddcb87..7be54b868d8e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct i915_request *rq)
return i915_gem_render_state_emit(rq);
}
+static void execlists_park(struct intel_engine_cs *engine)
+{
+ tasklet_kill(&engine->execlists.tasklet);
Isn't it actually a problem if tasklet is scheduled and unstarted, or
even in progress at the point of engine getting parked?
That would be a broken driver. :|
We must be quite sure that engine isn't going to send an interrupt as we
are just about to drop the wakeref we need to service that interrupt.
tasklet_kill()
GEM_BUG_ON(engine->execlists.active);
Or instead of both:
/* Tasklet must not be running or scheduled at this point. */
GEM_BUG_ON(engine->execlists.tasklet.state);
?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/14] drm/i915: Stop spinning for DROP_IDLE (debugfs/i915_drop_caches)
On 02/05/2019 15:00, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 14:34:11)
On 01/05/2019 12:45, Chris Wilson wrote:
If the user is racing a call to debugfs/i915_drop_caches with ongoing
submission from another thread/process, we may never end up idling the
GPU and be uninterruptibly spinning in debugfs/i915_drop_caches trying
to catch an idle moment.
Just flush the work once, that should be enough to park the system under
correct conditions. Outside of those we either have a driver bug or the
user is racing themselves. Sadly, because the user may be provoking the
unwanted situation we can't put a warn here to attract attention to a
probable bug.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7e8898d0b78b..2ecefacb1e66 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3933,9 +3933,7 @@ i915_drop_caches_set(void *data, u64 val)
fs_reclaim_release(GFP_KERNEL);
if (val & DROP_IDLE) {
- do {
- flush_delayed_work(&i915->gem.retire_work);
- } while (READ_ONCE(i915->gt.awake));
+ flush_delayed_work(&i915->gem.retire_work);
flush_work(&i915->gem.idle_work);
}
What were supposed to be semantics of DROP_IDLE? Now it seems rather
weak. Should it for instance also imply DROP_ACTIVE?
All I need for DROP_IDLE is that the idle worker is flushed. I've always
assumed you would pass in DROP_ACTIVE | DROP_RETIRE | DROP_IDLE as the
trifecta.
The biggest problem here is that's it is an uninterruptible loop.
Okay.. lets see if IGT is playing ball. :)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] RFC: console: hack up console_trylock more
console_trylock, called from within printk, can be called from pretty
much anywhere. Including try_to_wake_up. Note that this isn't common,
usually the box is in pretty bad shape at that point already. But it
really doesn't help when then lockdep jumps in and spams the logs,
potentially obscuring the real backtrace we're really interested in.
One case I've seen (slightly simplified backtrace):
Call Trace:
console_trylock+0xe/0x60
vprintk_emit+0xf1/0x320
printk+0x4d/0x69
__warn_printk+0x46/0x90
native_smp_send_reschedule+0x2f/0x40
check_preempt_curr+0x81/0xa0
ttwu_do_wakeup+0x14/0x220
try_to_wake_up+0x218/0x5f0
pollwake+0x6f/0x90
credit_entropy_bits+0x204/0x310
add_interrupt_randomness+0x18f/0x210
handle_irq+0x67/0x160
do_IRQ+0x5e/0x130
common_interrupt+0xf/0xf
This alone isn't a problem, but the spinlock in the semaphore is also
still held while waking up waiters (up() -> __up() -> try_to_wake_up()
callchain), which then closes the runqueue vs. semaphore.lock loop,
and upsets lockdep, which issues a circular locking splat to dmesg.
Worse it upsets developers, since we don't want to spam dmesg with
clutter when the machine is dying already.
Fix this by creating a __down_trylock which only trylocks the
semaphore.lock. This isn't correct in full generality, but good enough
for console_lock:
- there's only ever one console_lock holder, we won't fail spuriously
because someone is doing a down() or up() while there's still room
(unlike other semaphores with count > 1).
- console_unlock() has one massive retry loop, which will catch anyone
who races the trylock against the up(). This makes sure that no
printk lines will get lost. Making the trylock more racy therefore
has no further impact.
Also cc'ing John Ogness since perhaps his printk rework fixes this all
properly.
Signed-off-by: Daniel Vetter
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Petr Mladek
Cc: Sergey Senozhatsky
Cc: Steven Rostedt
Cc: Daniel Vetter
Cc: John Ogness
Cc: linux-ker...@vger.kernel.org
---
include/linux/semaphore.h | 1 +
kernel/locking/semaphore.c | 33 +
kernel/printk/printk.c | 2 +-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/semaphore.h b/include/linux/semaphore.h
index 11c86fbfeb98..82f6db6121c3 100644
--- a/include/linux/semaphore.h
+++ b/include/linux/semaphore.h
@@ -40,6 +40,7 @@ extern void down(struct semaphore *sem);
extern int __must_check down_interruptible(struct semaphore *sem);
extern int __must_check down_killable(struct semaphore *sem);
extern int __must_check down_trylock(struct semaphore *sem);
+extern int __must_check __down_trylock(struct semaphore *sem);
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
extern void up(struct semaphore *sem);
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index 561acdd39960..345123336019 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -143,6 +143,39 @@ int down_trylock(struct semaphore *sem)
}
EXPORT_SYMBOL(down_trylock);
+/**
+ * __down_trylock - try to acquire the semaphore, without any locking
+ * @sem: the semaphore to be acquired
+ *
+ * Try to acquire the semaphore atomically. Returns 0 if the semaphore has
+ * been acquired successfully or 1 if it it cannot be acquired.
+ *
+ * NOTE: This return value is inverted from both spin_trylock and
+ * mutex_trylock! Be careful about this when converting code.
+ *
+ * Unlike mutex_trylock, this function can be used from interrupt context,
+ * and the semaphore can be released by any task or interrupt.
+ *
+ * WARNING: Unlike down_trylock this function doesn't guarantee that that the
+ * semaphore will be acquired if it could, it's best effort only. Use for
+ * down_trylock_console_sem only.
+ */
+int __down_trylock(struct semaphore *sem)
+{
+ unsigned long flags;
+ int count;
+
+ if (!raw_spin_trylock_irqsave(&sem->lock, flags))
+ return 1;
+ count = sem->count - 1;
+ if (likely(count >= 0))
+ sem->count = count;
+ raw_spin_unlock_irqrestore(&sem->lock, flags);
+
+ return (count < 0);
+}
+EXPORT_SYMBOL(__down_trylock);
+
/**
* down_timeout - acquire the semaphore within a specified time
* @sem: the semaphore to be acquired
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 02ca827b8fac..5293803eec1f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -217,7 +217,7 @@ static int __down_trylock_console_sem(unsigned long ip)
* deadlock in printk()->down_trylock_console_sem() otherwise.
*/
printk_safe_enter_irqsave(flags);
- lock_failed = down_trylock(&console_sem);
+ lock_failed = __down_trylock(&console_sem);
printk_safe_exit_irqrestore(flags);
if (lock_failed)
--
2.20.1
___
Intel-gfx mailing list
Intel
[Intel-gfx] [PATCH v2] drm/i915/execlists: Ensure arbitration is disabled for the breadcrumb
If we interrupt building of the request, we may emit a request with no
payload at all, with the consequence that we never disable arbitration
prior to the breadcrumb. If we get preempted during the breadcrumb, it
appears possible to lose the association of the interrupt with
breadcrumb, and under the right conditions miss the breadcrumb interrupt
entirely, leaving the request's waiters dangling.
Now that we always disable the arbitration in the breadcrumb, we can
remove the redundant command to disable it after emitting the batch.
Testcase: igt/gem_concurrent_blit
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 851e62ddcb87..c8e87011044e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2117,7 +2117,7 @@ static int gen9_emit_bb_start(struct i915_request *rq,
{
u32 *cs;
- cs = intel_ring_begin(rq, 6);
+ cs = intel_ring_begin(rq, 4);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -2128,9 +2128,6 @@ static int gen9_emit_bb_start(struct i915_request *rq,
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
- *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
- *cs++ = MI_NOOP;
-
intel_ring_advance(rq, cs);
return 0;
@@ -2267,19 +2264,21 @@ static u32 *gen8_emit_wa_tail(struct i915_request
*request, u32 *cs)
static u32 *gen8_emit_fini_breadcrumb(struct i915_request *request, u32 *cs)
{
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
cs = gen8_emit_ggtt_write(cs,
request->fence.seqno,
request->timeline->hwsp_offset,
0);
+ *cs++ = MI_USER_INTERRUPT;
cs = gen8_emit_ggtt_write(cs,
intel_engine_next_hangcheck_seqno(request->engine),
I915_GEM_HWS_HANGCHECK_ADDR,
MI_FLUSH_DW_STORE_INDEX);
-
- *cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+ *cs++ = MI_NOOP;
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
@@ -2289,6 +2288,8 @@ static u32 *gen8_emit_fini_breadcrumb(struct i915_request
*request, u32 *cs)
static u32 *gen8_emit_fini_breadcrumb_rcs(struct i915_request *request, u32
*cs)
{
+ *cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
cs = gen8_emit_ggtt_write_rcs(cs,
request->fence.seqno,
request->timeline->hwsp_offset,
@@ -2297,14 +2298,15 @@ static u32 *gen8_emit_fini_breadcrumb_rcs(struct
i915_request *request, u32 *cs)
PIPE_CONTROL_DC_FLUSH_ENABLE |
PIPE_CONTROL_FLUSH_ENABLE |
PIPE_CONTROL_CS_STALL);
+ *cs++ = MI_USER_INTERRUPT;
cs = gen8_emit_ggtt_write_rcs(cs,
intel_engine_next_hangcheck_seqno(request->engine),
I915_GEM_HWS_HANGCHECK_ADDR,
PIPE_CONTROL_STORE_DATA_INDEX);
- *cs++ = MI_USER_INTERRUPT;
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
+ *cs++ = MI_NOOP;
request->tail = intel_ring_offset(request, cs);
assert_ring_tail_valid(request->ring, request->tail);
--
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 HDCP2.2 Phase II (rev8)
== Series Details ==
Series: HDCP2.2 Phase II (rev8)
URL : https://patchwork.freedesktop.org/series/57232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6026 -> Patchwork_12939
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/57232/revisions/8/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12939:
### IGT changes ###
Possible regressions
* {igt@kms_content_protection@srm} (NEW):
- {fi-cml-u}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-cml-u/igt@kms_content_protect...@srm.html
- fi-cfl-8109u: NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-cfl-8109u/igt@kms_content_protect...@srm.html
- fi-icl-y: NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-icl-y/igt@kms_content_protect...@srm.html
- fi-skl-lmem:NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-skl-lmem/igt@kms_content_protect...@srm.html
- fi-apl-guc: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-apl-guc/igt@kms_content_protect...@srm.html
- fi-skl-gvtdvm: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-skl-gvtdvm/igt@kms_content_protect...@srm.html
New tests
-
New tests have been introduced between CI_DRM_6026 and Patchwork_12939:
### New IGT tests (1) ###
* igt@kms_content_protection@srm:
- Statuses : 4 fail(s) 5 pass(s) 33 skip(s)
- Exec time: [0.0, 131.04] s
Known issues
Here are the changes found in Patchwork_12939 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_contexts:
- fi-bdw-gvtdvm: [PASS][7] -> [DMESG-FAIL][8] ([fdo#110235])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html
* igt@kms_busy@basic-flip-c:
- fi-skl-6770hq: [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278])
+2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-skl-6770hq/igt@kms_b...@basic-flip-c.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6770hq: [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: [DMESG-WARN][13] ([fdo#108965]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-kbl-8809g/igt@amdgpu/amd_ba...@userptr.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [INCOMPLETE][15] ([fdo#107718] / [fdo#110581]) ->
[PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: [INCOMPLETE][17] ([fdo#108602] / [fdo#108744] /
[fdo#110581]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6026/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12939/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[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#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235
[fdo#110581]: https://bugs.freedesktop.org/show_bug.cgi?id=110581
Participating hosts (52 -> 46)
--
Additional (1): fi-byt-j1900
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/icl: Factor out combo PHY lane power setup helper
On Fri, Apr 26, 2019 at 08:39:12AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/2] drm/i915/icl: Factor out combo PHY lane > power setup helper > URL : https://patchwork.freedesktop.org/series/59954/ > State : success Thanks for the review, series pushed to -dinq, with the s/icl_/intel_/ change and adding the headers to intel_combo_phy.h required by the recent header refactoring. > > == Summary == > > CI Bug Log - changes from CI_DRM_6000_full -> Patchwork_12877_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Known issues > > > Here are the changes found in Patchwork_12877_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_tiled_swapping@non-threaded: > - shard-iclb: [PASS][1] -> [DMESG-WARN][2] ([fdo#108686]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb6/igt@gem_tiled_swapp...@non-threaded.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb3/igt@gem_tiled_swapp...@non-threaded.html > > * igt@i915_pm_rpm@legacy-planes: > - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl5/igt@i915_pm_...@legacy-planes.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl6/igt@i915_pm_...@legacy-planes.html > > * igt@kms_cursor_crc@cursor-64x64-dpms: > - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#103232]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl8/igt@kms_cursor_...@cursor-64x64-dpms.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl5/igt@kms_cursor_...@cursor-64x64-dpms.html > > * igt@kms_flip@flip-vs-expired-vblank-interruptible: > - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#105363]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: > - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html > > * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: > - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html > > * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: > - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / > [fdo#110403]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html > > * igt@kms_psr2_su@frontbuffer: > - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb2/igt@kms_psr2...@frontbuffer.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb1/igt@kms_psr2...@frontbuffer.html > > * igt@kms_psr@psr2_sprite_render: > - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar > issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb2/igt@kms_psr@psr2_sprite_render.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb8/igt@kms_psr@psr2_sprite_render.html > > * igt@kms_psr@suspend: > - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#107773]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl7/igt@kms_...@suspend.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl1/igt@kms_...@suspend.html > > * igt@kms_rotation_crc@multiplane-rotation: > - shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103665]) >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-kbl4/igt@kms_rotation_...@multiplane-rotation.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-kbl4/igt@kms_rotation_...@multiplane-rotation.html > > * igt@kms_vblank@pipe-a-ts-continuation-suspend: > - shard-apl: [PASS][23] -
Re: [Intel-gfx] [PATCH 04/14] drm/i915: Leave engine parking to the engines
On 01/05/2019 12:45, Chris Wilson wrote:
Drop the check in GEM parking that the engines were already parked. The
intention here was that before we dropped the GT wakeref, we were sure
that no more interrupts could be raised -- however, we have already
dropped the wakeref by this point and the warning is no longer valid.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 3b6e8d5be8e1..49b0ce594f20 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -17,24 +17,8 @@ static void i915_gem_park(struct drm_i915_private *i915)
lockdep_assert_held(&i915->drm.struct_mutex);
- for_each_engine(engine, i915, id) {
- /*
-* We are committed now to parking the engines, make sure there
-* will be no more interrupts arriving later and the engines
-* are truly idle.
-*/
- if (wait_for(intel_engine_is_idle(engine), 10)) {
- struct drm_printer p = drm_debug_printer(__func__);
-
- dev_err(i915->drm.dev,
- "%s is not idle before parking\n",
- engine->name);
- intel_engine_dump(engine, &p, NULL);
- }
- tasklet_kill(&engine->execlists.tasklet);
-
+ for_each_engine(engine, i915, id)
i915_gem_batch_pool_fini(&engine->batch_pool);
- }
i915_timelines_park(i915);
i915_vma_parked(i915);
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 06/14] drm/i915: Cancel retire_worker on parking
On 02/05/2019 14:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 14:29:50)
On 01/05/2019 12:45, Chris Wilson wrote:
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although that the igt is trying to idle from one child while submitting
from another may be a contributing factor as to why it runs so slowly...
Testcase: igt/gem_concurrent_blit
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index ae91ad7cb31e..b239b55f84cd 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
container_of(work, typeof(*i915), gem.idle_work);
+ bool restart = true;
+ cancel_delayed_work_sync(&i915->gem.retire_work);
mutex_lock(&i915->drm.struct_mutex);
You don't want to run another retire here? Since the retire worker might
have just been canceled I thought you should.
Why though? If there are retires outstanding, we won't sleep and want to
defer parking until after the next cycle.
In this case what is the point of cancel_delayed_work_*sync* and not
just the async cancel?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915/execlists: Flush the tasklet on parking
Quoting Tvrtko Ursulin (2019-05-02 15:14:08)
>
> On 02/05/2019 14:53, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-02 14:48:18)
> >>
> >> On 01/05/2019 12:45, Chris Wilson wrote:
> >>> Tidy up the cleanup sequence by always ensure that the tasklet is
> >>> flushed on parking (before we cleanup). The parking provides a
> >>> convenient point to ensure that the backend is truly idle.
> >>>
> >>> Signed-off-by: Chris Wilson
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
> >>>drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
> >>>2 files changed, 7 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> index 851e62ddcb87..7be54b868d8e 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> >>> @@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct
> >>> i915_request *rq)
> >>>return i915_gem_render_state_emit(rq);
> >>>}
> >>>
> >>> +static void execlists_park(struct intel_engine_cs *engine)
> >>> +{
> >>> + tasklet_kill(&engine->execlists.tasklet);
> >>
> >> Isn't it actually a problem if tasklet is scheduled and unstarted, or
> >> even in progress at the point of engine getting parked?
> >
> > That would be a broken driver. :|
> >
> > We must be quite sure that engine isn't going to send an interrupt as we
> > are just about to drop the wakeref we need to service that interrupt.
> >
> > tasklet_kill()
> > GEM_BUG_ON(engine->execlists.active);
>
> Or instead of both:
>
> /* Tasklet must not be running or scheduled at this point. */
> GEM_BUG_ON(engine->execlists.tasklet.state);
There's the dilemma that we start parking based on retirement not
final CS event.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/14] drm/i915: Remove delay for idle_work
Quoting Tvrtko Ursulin (2019-05-02 14:51:31)
>
> On 02/05/2019 14:22, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-02 14:19:38)
> >>
> >> On 01/05/2019 12:45, Chris Wilson wrote:
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> b/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> index 49b0ce594f20..ae91ad7cb31e 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> @@ -29,12 +29,12 @@ static void i915_gem_park(struct drm_i915_private
> >>> *i915)
> >>>static void idle_work_handler(struct work_struct *work)
> >>>{
> >>>struct drm_i915_private *i915 =
> >>> - container_of(work, typeof(*i915), gem.idle_work.work);
> >>> + container_of(work, typeof(*i915), gem.idle_work);
> >>>
> >>>mutex_lock(&i915->drm.struct_mutex);
> >>>
> >>>intel_wakeref_lock(&i915->gt.wakeref);
> >>> - if (!intel_wakeref_active(&i915->gt.wakeref))
> >>> + if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
> >>
> >> What is the reason for the !work_pending check?
> >
> > Just that we are going to be called again, so wait until the next time to
> > see if we still need to park.
>
> When does it get called again? If a whole new cycle of unpark-park
> happened before the previous park was able to finish?
work_pending() implies that we've done at least one cycle while we
waited for the locks and the work is already queued to be rerun.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915/execlists: Flush the tasklet on parking
On 02/05/2019 15:21, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 15:14:08)
On 02/05/2019 14:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-05-02 14:48:18)
On 01/05/2019 12:45, Chris Wilson wrote:
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 851e62ddcb87..7be54b868d8e 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct i915_request *rq)
return i915_gem_render_state_emit(rq);
}
+static void execlists_park(struct intel_engine_cs *engine)
+{
+ tasklet_kill(&engine->execlists.tasklet);
Isn't it actually a problem if tasklet is scheduled and unstarted, or
even in progress at the point of engine getting parked?
That would be a broken driver. :|
We must be quite sure that engine isn't going to send an interrupt as we
are just about to drop the wakeref we need to service that interrupt.
tasklet_kill()
GEM_BUG_ON(engine->execlists.active);
Or instead of both:
/* Tasklet must not be running or scheduled at this point. */
GEM_BUG_ON(engine->execlists.tasklet.state);
There's the dilemma that we start parking based on retirement not
final CS event.
But engine->park() is called once the last engine pm reference is
dropped. Are we dropping the last reference with a CS event pending?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/14] drm/i915: Cancel retire_worker on parking
Quoting Tvrtko Ursulin (2019-05-02 15:20:52)
>
> On 02/05/2019 14:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-02 14:29:50)
> >>
> >> On 01/05/2019 12:45, Chris Wilson wrote:
> >>> Replace the racy continuation check within retire_work with a definite
> >>> kill-switch on idling. The race was being exposed by gem_concurrent_blit
> >>> where the retire_worker would be terminated too early leaving us
> >>> spinning in debugfs/i915_drop_caches with nothing flushing the
> >>> retirement queue.
> >>>
> >>> Although that the igt is trying to idle from one child while submitting
> >>> from another may be a contributing factor as to why it runs so slowly...
> >>>
> >>> Testcase: igt/gem_concurrent_blit
> >>> Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
> >>> Signed-off-by: Chris Wilson
> >>> Cc: Tvrtko Ursulin
> >>> ---
> >>>drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
> >>>.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
> >>>2 files changed, 12 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> b/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> index ae91ad7cb31e..b239b55f84cd 100644
> >>> --- a/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> +++ b/drivers/gpu/drm/i915/i915_gem_pm.c
> >>> @@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct
> >>> *work)
> >>>{
> >>>struct drm_i915_private *i915 =
> >>>container_of(work, typeof(*i915), gem.idle_work);
> >>> + bool restart = true;
> >>>
> >>> + cancel_delayed_work_sync(&i915->gem.retire_work);
> >>>mutex_lock(&i915->drm.struct_mutex);
> >>>
> >>
> >> You don't want to run another retire here? Since the retire worker might
> >> have just been canceled I thought you should.
> >
> > Why though? If there are retires outstanding, we won't sleep and want to
> > defer parking until after the next cycle.
>
> In this case what is the point of cancel_delayed_work_*sync* and not
> just the async cancel?
There's an non-sync version? Ah ha!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Cancel retire_worker on parking
Replace the racy continuation check within retire_work with a definite
kill-switch on idling. The race was being exposed by gem_concurrent_blit
where the retire_worker would be terminated too early leaving us
spinning in debugfs/i915_drop_caches with nothing flushing the
retirement queue.
Although that the igt is trying to idle from one child while submitting
from another may be a contributing factor as to why it runs so slowly...
v2: Use the non-sync version of cancel_delayed_work(), we only need to
stop it from being scheduled as we independently check whether now is
the right time to be parking.
Testcase: igt/gem_concurrent_blit
Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 --
.../gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index ae91ad7cb31e..fa9c2ebd966a 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -30,15 +30,23 @@ static void idle_work_handler(struct work_struct *work)
{
struct drm_i915_private *i915 =
container_of(work, typeof(*i915), gem.idle_work);
+ bool restart = true;
+ cancel_delayed_work(&i915->gem.retire_work);
mutex_lock(&i915->drm.struct_mutex);
intel_wakeref_lock(&i915->gt.wakeref);
- if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work))
+ if (!intel_wakeref_active(&i915->gt.wakeref) && !work_pending(work)) {
i915_gem_park(i915);
+ restart = false;
+ }
intel_wakeref_unlock(&i915->gt.wakeref);
mutex_unlock(&i915->drm.struct_mutex);
+ if (restart)
+ queue_delayed_work(i915->wq,
+ &i915->gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static void retire_work_handler(struct work_struct *work)
@@ -52,10 +60,9 @@ static void retire_work_handler(struct work_struct *work)
mutex_unlock(&i915->drm.struct_mutex);
}
- if (intel_wakeref_active(&i915->gt.wakeref))
- queue_delayed_work(i915->wq,
- &i915->gem.retire_work,
- round_jiffies_up_relative(HZ));
+ queue_delayed_work(i915->wq,
+ &i915->gem.retire_work,
+ round_jiffies_up_relative(HZ));
}
static int pm_notifier(struct notifier_block *nb,
@@ -140,7 +147,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
* Assert that we successfully flushed all the work and
* reset the GPU back to its idle, low power state.
*/
- drain_delayed_work(&i915->gem.retire_work);
GEM_BUG_ON(i915->gt.awake);
flush_work(&i915->gem.idle_work);
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d919f512042c..9fd02025d382 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -58,7 +58,6 @@ static void mock_device_release(struct drm_device *dev)
i915_gem_contexts_lost(i915);
mutex_unlock(&i915->drm.struct_mutex);
- drain_delayed_work(&i915->gem.retire_work);
flush_work(&i915->gem.idle_work);
i915_gem_drain_workqueue(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle plane CSC for BT2020 framebuffers
tor 2019-05-02 klockan 14:51 +0300 skrev Ville Syrjälä:
> On Thu, May 02, 2019 at 10:40:39AM +, Sharma, Shashank wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Thursday, May 2, 2019 3:45 PM
> > > To: Sharma, Shashank
> > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > a...@intel.com>; Lankhorst,
> > > Maarten
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/GLK: Properly handle
> > > plane CSC for
> > > BT2020 framebuffers
> > >
> > > On Thu, May 02, 2019 at 03:19:42PM +0530, Shashank Sharma wrote:
> > > > Framebuffer formats P01x are supported by GLK, but the function
> > > > which
> > > > handles CSC on plane color control register, still expectes the
> > > > input
> > > > buffer to be REC709. This can cause inaccurate output for
> > > > direct P01x
> > > > flips.
> > > >
> > > > This patch checks if the color_encoding property is set to
> > > > YCBCR_2020,
> > > > and enables the corresponding color conversion mode on plane
> > > > CSC.
> > > >
> > > > PS: renamed variable plane_color_ctl to color_ctl for 80 char
> > > > stuff.
> > > >
> > > > Cc: Ville Syrjala
> > > > Cc: Maarten Lankhorst
> > > > Cc: Uma Shankar
> > > > Signed-off-by: Shashank Sharma
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.c | 26 --
> > > >
> > > > 1 file changed, 16 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index dd65d7c521c1..2d4d3128bf1f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -3868,24 +3868,30 @@ u32 glk_plane_color_ctl(const struct
> > > > intel_crtc_state
> > >
> > > *crtc_state,
> > > > to_i915(plane_state->base.plane->dev);
> > > > const struct drm_framebuffer *fb = plane_state-
> > > > >base.fb;
> > > > struct intel_plane *plane =
> > > > to_intel_plane(plane_state->base.plane);
> > > > - u32 plane_color_ctl = 0;
> > > > + u32 color_ctl = 0;
> > > >
> > > > - plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > > > - plane_color_ctl |=
> > > > glk_plane_color_ctl_alpha(plane_state);
> > > > + color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
> > > > + color_ctl |= glk_plane_color_ctl_alpha(plane_state);
> > > >
> > > > if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv,
> > > > plane->id)) {
> > > > - if (plane_state->base.color_encoding ==
> > > > DRM_COLOR_YCBCR_BT709)
> > > > - plane_color_ctl |=
> > >
> > > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > > - else
> > > > - plane_color_ctl |=
> > >
> > > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > > + switch (plane_state->base.color_encoding) {
> > > > + case DRM_COLOR_YCBCR_BT709:
> > > > + color_ctl |=
> > >
> > > PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
> > > > + break;
> > > > + case DRM_COLOR_YCBCR_BT2020:
> > > > + color_ctl |=
> > >
> > > PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020;
> > > > + break;
> > > > + default:
> > > > + color_ctl |=
> > >
> > > PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709;
> > > > + }
> > >
> > > This isn't going to do anything without adjusting the property
> > > supported encodings as
> > > well.
> > >
> >
> > I might have not understood this comment properly, but, AFAIK, if
> > userspace sets this property well, and we set this color_ctl bit
> > properly, driver is setting PLANE_COLOR_CSC_MODE_YUV2020_TO_RGB2020
> > bits in GLK color control register. As GLK has a fix function plane
> > CSC, HW will apply a different matrix internally to convert input
> > buffer to RGB_2020 from YCBCR_2020 (earlier this would have been
> > YCBCR_709). So I think we should see visible changes in output. Do
> > you think otherwise ?
>
> The property won't accept the BT2020 value. Or if it does we have a
> bug
> somewhere.
>
> I guess tests would be nice. Maybe we should extend the kms_plane
> pixel
> format tests to check different YCbCr encodings as well? Or maybe
> Maarten's kms_yuv already tests this?
Not yet, unfortunately we have no way to set CSC in igt yet. :(
Best way to do so would be to add a igt_create_fb_yuv() which would a
igt_create_fb that accepts igt color encoding and range as arguments.
~Maarten
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/14] drm/i915/execlists: Flush the tasklet on parking
Quoting Tvrtko Ursulin (2019-05-02 15:24:16)
>
> On 02/05/2019 15:21, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-05-02 15:14:08)
> >>
> >> On 02/05/2019 14:53, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2019-05-02 14:48:18)
>
> On 01/05/2019 12:45, Chris Wilson wrote:
> > Tidy up the cleanup sequence by always ensure that the tasklet is
> > flushed on parking (before we cleanup). The parking provides a
> > convenient point to ensure that the backend is truly idle.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 7 ++-
> > drivers/gpu/drm/i915/intel_guc_submission.c | 1 +
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 851e62ddcb87..7be54b868d8e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -2331,6 +2331,11 @@ static int gen8_init_rcs_context(struct
> > i915_request *rq)
> > return i915_gem_render_state_emit(rq);
> > }
> >
> > +static void execlists_park(struct intel_engine_cs *engine)
> > +{
> > + tasklet_kill(&engine->execlists.tasklet);
>
> Isn't it actually a problem if tasklet is scheduled and unstarted, or
> even in progress at the point of engine getting parked?
> >>>
> >>> That would be a broken driver. :|
> >>>
> >>> We must be quite sure that engine isn't going to send an interrupt as we
> >>> are just about to drop the wakeref we need to service that interrupt.
> >>>
> >>> tasklet_kill()
> >>> GEM_BUG_ON(engine->execlists.active);
> >>
> >> Or instead of both:
> >>
> >> /* Tasklet must not be running or scheduled at this point. */
> >> GEM_BUG_ON(engine->execlists.tasklet.state);
> >
> > There's the dilemma that we start parking based on retirement not
> > final CS event.
>
> But engine->park() is called once the last engine pm reference is
> dropped. Are we dropping the last reference with a CS event pending?
Potentially we are.
i915_request_retire() -> context->exit() -> engine->park()
At no point along that chain do we actually check we have flushed the
backend. The tasklet_kill() would flush if the interrupt had already
been sent, but that's not very strict.
Oh well, you've talked me into to re-adding the wait loop here.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/2] drm/i915/icl: Factor out combo PHY lane power setup helper
On Thu, 02 May 2019, Imre Deak wrote: > On Fri, Apr 26, 2019 at 08:39:12AM +, Patchwork wrote: >> == Series Details == >> >> Series: series starting with [v2,1/2] drm/i915/icl: Factor out combo PHY >> lane power setup helper >> URL : https://patchwork.freedesktop.org/series/59954/ >> State : success > > Thanks for the review, series pushed to -dinq, with the s/icl_/intel_/ > change and adding the headers to intel_combo_phy.h required by the > recent header refactoring. Hey, I expected a resend. Please always resend the the rebased patches for CI, and only push patches that have gone through CI! BR, Jani. > >> >> == Summary == >> >> CI Bug Log - changes from CI_DRM_6000_full -> Patchwork_12877_full >> >> >> Summary >> --- >> >> **SUCCESS** >> >> No regressions found. >> >> >> >> Known issues >> >> >> Here are the changes found in Patchwork_12877_full that come from known >> issues: >> >> ### IGT changes ### >> >> Issues hit >> >> * igt@gem_tiled_swapping@non-threaded: >> - shard-iclb: [PASS][1] -> [DMESG-WARN][2] ([fdo#108686]) >>[1]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb6/igt@gem_tiled_swapp...@non-threaded.html >>[2]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb3/igt@gem_tiled_swapp...@non-threaded.html >> >> * igt@i915_pm_rpm@legacy-planes: >> - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) >>[3]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl5/igt@i915_pm_...@legacy-planes.html >>[4]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl6/igt@i915_pm_...@legacy-planes.html >> >> * igt@kms_cursor_crc@cursor-64x64-dpms: >> - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#103232]) >>[5]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl8/igt@kms_cursor_...@cursor-64x64-dpms.html >>[6]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl5/igt@kms_cursor_...@cursor-64x64-dpms.html >> >> * igt@kms_flip@flip-vs-expired-vblank-interruptible: >> - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#105363]) >>[7]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >>[8]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html >> >> * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: >> - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) >>[9]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html >>[10]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-pgflip-blt.html >> >> * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: >> - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108]) >>[11]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html >>[12]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html >> >> * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: >> - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / >> [fdo#110403]) >>[13]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html >>[14]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html >> >> * igt@kms_psr2_su@frontbuffer: >> - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109642]) >>[15]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb2/igt@kms_psr2...@frontbuffer.html >>[16]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb1/igt@kms_psr2...@frontbuffer.html >> >> * igt@kms_psr@psr2_sprite_render: >> - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar >> issues >>[17]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-iclb2/igt@kms_psr@psr2_sprite_render.html >>[18]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-iclb8/igt@kms_psr@psr2_sprite_render.html >> >> * igt@kms_psr@suspend: >> - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#107773]) >>[19]: >> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6000/shard-skl7/igt@kms_...@suspend.html >>[20]: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12877/shard-skl1/igt@kms_...@suspend.html >> >> * igt@kms_rotation_crc@multiplane-rotation: >> - shard-kbl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103665]) >>[21]: >> https://intel-gfx-ci.01.org/tree/drm
Re: [Intel-gfx] [PATCH 6/6] drm/i915: Expand subslice mask
On Wed, 2019-05-01 at 15:04 -0700, Daniele Ceraolo Spurio wrote:
>
> On 5/1/19 8:34 AM, Stuart Summers wrote:
> > Currently, the subslice_mask runtime parameter is stored as an
> > array of subslices per slice. Expand the subslice mask array to
> > better match what is presented to userspace through the
> > I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
> > then calculated:
> >slice * subslice stride + subslice index / 8
> >
> > v2: fix spacing in set_sseu_info args
> > use set_sseu_info to initialize sseu data when building
> > device status in debugfs
> > rename variables in intel_engine_types.h to avoid checkpatch
> > warnings
> > v3: update headers in intel_sseu.h
> > v4: add const to some sseu_dev_info variables
> > use sseu->eu_stride for EU stride calculations
> >
> > Cc: Daniele Ceraolo Spurio
> > Signed-off-by: Stuart Summers
>
> Can you also get an ack from Lionel, to make sure this all fits with
> the
> expected reporting?
Cc: Lionel Landwerlin
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 6 +-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 32 +++--
> > drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
> > drivers/gpu/drm/i915/gt/intel_sseu.c | 49 +--
> > drivers/gpu/drm/i915/gt/intel_sseu.h | 16 ++-
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 44 +++---
> > drivers/gpu/drm/i915/i915_drv.c | 6 +-
> > drivers/gpu/drm/i915/i915_gpu_error.c| 5 +-
> > drivers/gpu/drm/i915/i915_query.c| 10 +-
> > drivers/gpu/drm/i915/intel_device_info.c | 142 +++---
> > -
> > 11 files changed, 198 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 6e40f8ea9a6a..8f7967cc9a50 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -914,7 +914,7 @@ u32 intel_calculate_mcr_s_ss_select(struct
> > drm_i915_private *dev_priv)
> > const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)-
> > >sseu;
> > u32 mcr_s_ss_select;
> > u32 slice = fls(sseu->slice_mask);
> > - u32 subslice = fls(sseu->subslice_mask[slice]);
> > + u32 subslice = fls(sseu->subslice_mask[slice * sseu-
> > >ss_stride]);
>
> This (and the registers we use below) only works if ss_stride = 1.
> Can
> we add a:
>
> GEM_BUG_ON(sseu->ss_stride > 1);
>
> to catch the fact that this function will need updating to handle
> that
> case if/when we get it?
I'll rework this and post an update.
>
> >
> > if (IS_GEN(dev_priv, 10))
> > mcr_s_ss_select = GEN8_MCR_SLICE(slice) |
> > @@ -990,6 +990,7 @@ void intel_engine_get_instdone(struct
> > intel_engine_cs *engine,
> >struct intel_instdone *instdone)
> > {
> > struct drm_i915_private *dev_priv = engine->i915;
> > + const struct sseu_dev_info *sseu = &RUNTIME_INFO(dev_priv)-
> > >sseu;
> > struct intel_uncore *uncore = engine->uncore;
> > u32 mmio_base = engine->mmio_base;
> > int slice;
> > @@ -1007,7 +1008,8 @@ void intel_engine_get_instdone(struct
> > intel_engine_cs *engine,
> >
> > instdone->slice_common =
> > intel_uncore_read(uncore, GEN7_SC_INSTDONE);
> > - for_each_instdone_slice_subslice(dev_priv, slice,
> > subslice) {
> > + for_each_instdone_slice_subslice(dev_priv, sseu, slice,
> > +subslice) {
> > instdone->sampler[slice][subslice] =
> > read_subslice_reg(dev_priv, slice,
> > subslice,
> > GEN7_SAMPLER_INSTDONE
> > );
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 9d64e33f8427..1710546a2446 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -534,20 +534,22 @@ intel_engine_needs_breadcrumb_tasklet(const
> > struct intel_engine_cs *engine)
> > return engine->flags & I915_ENGINE_NEEDS_BREADCRUMB_TASKLET;
> > }
> >
> > -#define instdone_slice_mask(dev_priv__) \
> > - (IS_GEN(dev_priv__, 7) ? \
> > -1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
> > -
> > -#define instdone_subslice_mask(dev_priv__) \
> > - (IS_GEN(dev_priv__, 7) ? \
> > -1 : RUNTIME_INFO(dev_priv__)->sseu.subslice_mask[0])
> > -
> > -#define for_each_instdone_slice_subslice(dev_priv__, slice__,
> > subslice__) \
> > - for ((slice__) = 0, (subslice__) = 0; \
> > -(slice__) < I915_MAX_SLICES; \
> > -(subslice__) = ((subslice__) + 1) < I915_MAX_SUBSLICES ?
> > (subslice__) + 1 : 0, \
> > - (slice__) += ((subslice__) == 0)) \
> > - for_each_if((BIT(slice__)
[Intel-gfx] [PATCH v3] drm/i915: add single combo phy init/unit functions
Work on the principle that files should prefer not to expose platform
specific functions.
v2, v3: Rebase
Cc: Imre Deak
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_combo_phy.c | 24
drivers/gpu/drm/i915/intel_combo_phy.h | 6 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 10 +-
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c
b/drivers/gpu/drm/i915/intel_combo_phy.c
index f1b883..19a933 100644
--- a/drivers/gpu/drm/i915/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/intel_combo_phy.c
@@ -148,7 +148,7 @@ static bool cnl_combo_phy_verify_state(struct
drm_i915_private *dev_priv)
return ret;
}
-void cnl_combo_phys_init(struct drm_i915_private *dev_priv)
+static void cnl_combo_phys_init(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -168,7 +168,7 @@ void cnl_combo_phys_init(struct drm_i915_private *dev_priv)
I915_WRITE(CNL_PORT_CL1CM_DW5, val);
}
-void cnl_combo_phys_uninit(struct drm_i915_private *dev_priv)
+static void cnl_combo_phys_uninit(struct drm_i915_private *dev_priv)
{
u32 val;
@@ -256,7 +256,7 @@ void intel_combo_phy_power_up_lanes(struct drm_i915_private
*dev_priv,
I915_WRITE(ICL_PORT_CL_DW10(port), val);
}
-void icl_combo_phys_init(struct drm_i915_private *dev_priv)
+static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
{
enum port port;
@@ -285,7 +285,7 @@ void icl_combo_phys_init(struct drm_i915_private *dev_priv)
}
}
-void icl_combo_phys_uninit(struct drm_i915_private *dev_priv)
+static void icl_combo_phys_uninit(struct drm_i915_private *dev_priv)
{
enum port port;
@@ -306,3 +306,19 @@ void icl_combo_phys_uninit(struct drm_i915_private
*dev_priv)
I915_WRITE(ICL_PORT_COMP_DW0(port), val);
}
}
+
+void intel_combo_phy_init(struct drm_i915_private *i915)
+{
+ if (INTEL_GEN(i915) >= 11)
+ icl_combo_phys_init(i915);
+ else if (IS_CANNONLAKE(i915))
+ cnl_combo_phys_init(i915);
+}
+
+void intel_combo_phy_uninit(struct drm_i915_private *i915)
+{
+ if (INTEL_GEN(i915) >= 11)
+ icl_combo_phys_uninit(i915);
+ else if (IS_CANNONLAKE(i915))
+ cnl_combo_phys_uninit(i915);
+}
diff --git a/drivers/gpu/drm/i915/intel_combo_phy.h
b/drivers/gpu/drm/i915/intel_combo_phy.h
index 749b644..e6e195 100644
--- a/drivers/gpu/drm/i915/intel_combo_phy.h
+++ b/drivers/gpu/drm/i915/intel_combo_phy.h
@@ -11,10 +11,8 @@
struct drm_i915_private;
-void icl_combo_phys_init(struct drm_i915_private *dev_priv);
-void icl_combo_phys_uninit(struct drm_i915_private *dev_priv);
-void cnl_combo_phys_init(struct drm_i915_private *dev_priv);
-void cnl_combo_phys_uninit(struct drm_i915_private *dev_priv);
+void intel_combo_phy_init(struct drm_i915_private *dev_priv);
+void intel_combo_phy_uninit(struct drm_i915_private *dev_priv);
void intel_combo_phy_power_up_lanes(struct drm_i915_private *dev_priv,
enum port port, bool is_dsi,
int lane_count, bool lane_reversal);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 30e7cb..be7119 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1140,7 +1140,7 @@ static void gen9_dc_off_power_well_enable(struct
drm_i915_private *dev_priv,
* PHY's HW context for port B is lost after DC transitions,
* so we need to restore it manually.
*/
- icl_combo_phys_init(dev_priv);
+ intel_combo_phy_init(dev_priv);
}
static void gen9_dc_off_power_well_disable(struct drm_i915_private *dev_priv,
@@ -3779,7 +3779,7 @@ static void cnl_display_core_init(struct drm_i915_private
*dev_priv, bool resume
intel_pch_reset_handshake(dev_priv, !HAS_PCH_NOP(dev_priv));
/* 2-3. */
- cnl_combo_phys_init(dev_priv);
+ intel_combo_phy_init(dev_priv);
/*
* 4. Enable Power Well 1 (PG1).
@@ -3828,7 +3828,7 @@ static void cnl_display_core_uninit(struct
drm_i915_private *dev_priv)
usleep_range(10, 30); /* 10 us delay per Bspec */
/* 5. */
- cnl_combo_phys_uninit(dev_priv);
+ intel_combo_phy_uninit(dev_priv);
}
void icl_display_core_init(struct drm_i915_private *dev_priv,
@@ -3843,7 +3843,7 @@ void icl_display_core_init(struct drm_i915_private
*dev_priv,
intel_pch_reset_handshake(dev_priv, !HAS_PCH_NOP(dev_priv));
/* 2. Initialize all combo phys */
- icl_combo_phys_init(dev_priv);
+ intel_combo_phy_init(dev_priv);
/*
* 3. Enable Power Well 1 (PG1).
@@ -3893,7 +3893,7 @@ void icl_display_core_uninit(struct drm_i915_private
*dev_priv)
mutex_unlock(&power_domains->lock);
/* 5. */
-
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Remove inline from sseu helper functions
On Thu, 2019-05-02 at 10:15 +0300, Jani Nikula wrote: > On Wed, 01 May 2019, "Summers, Stuart" > wrote: > > On Wed, 2019-05-01 at 14:19 -0700, Daniele Ceraolo Spurio wrote: > > > > > > On 5/1/19 2:04 PM, Summers, Stuart wrote: > > > > On Wed, 2019-05-01 at 13:04 -0700, Daniele Ceraolo Spurio > > > > wrote: > > > > > Can you elaborate a bit more on what's the rationale for > > > > > this? do > > > > > you just want to avoid having too many inlines since the > > > > > paths > > > > > they're used in are not critical, or do you have some more > > > > > functional reason? This is not a critic to the patch, I just > > > > > want to understand where you're coming from ;) > > > > > > > > This was a request from Jani Nikula in a previous series > > > > update. I > > > > don't have a strong preference either way personally. If you > > > > don't > > > > have any major concerns, I'd prefer to keep the series as-is to > > > > prevent too much thrash here, but let me know. > > > > > > > > > > No concerns, just please update the commit message to explain > > > that > > > we're moving them because there is no need for them to be inline > > > since they're not on a critical path where we need preformance. > > > > Sounds great. > > I've become critical of superfluous inlines. They break the > abstraction > by exposing the internals in the header, and make the > interdependencies > of headers harder to resolve. > > As the driver keeps growing and more people contribute to it, I think > we > need to pay more attention on how we structure the source. To this > end > we've added new gt/ subdir, are about to add gem/ and likely display/ > too before long, and we've significantly split off the monster > i915_drv.h and intel_drv.h headers. > > Obviously inlines have their place and purpose, but I think we > sprinkle > them a bit too eagerly without paying attention. > > I like the patch. > > Acked-by: Jani Nikula Jani, based on Daniele's feedback, I'm planning on squashing this patch with the patch that moves these helper functions to intel_sseu.h. Any issue keeping your Ack here? -Stuart > > smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Remove inline from sseu helper functions
On Thu, 02 May 2019, "Summers, Stuart" wrote: > On Thu, 2019-05-02 at 10:15 +0300, Jani Nikula wrote: >> Acked-by: Jani Nikula > > Jani, based on Daniele's feedback, I'm planning on squashing this patch > with the patch that moves these helper functions to intel_sseu.h. Any > issue keeping your Ack here? None. BR, Jani. -- 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 5/6] drm/i915: Remove inline from sseu helper functions
On Thu, 2019-05-02 at 17:58 +0300, Jani Nikula wrote: > On Thu, 02 May 2019, "Summers, Stuart" > wrote: > > On Thu, 2019-05-02 at 10:15 +0300, Jani Nikula wrote: > > > Acked-by: Jani Nikula > > > > Jani, based on Daniele's feedback, I'm planning on squashing this > > patch > > with the patch that moves these helper functions to intel_sseu.h. > > Any > > issue keeping your Ack here? > > None. Thanks for the Ack! -Stuart > > BR, > Jani. > smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/13] drm/i915/dvo: move DVO chip types to intel_dvo.c
Reduce clutter from intel_drv.h with the minimal change.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h | 5 -
drivers/gpu/drm/i915/intel_dvo.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 57ae396..ab11c3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -184,11 +184,6 @@ enum intel_output_type {
INTEL_OUTPUT_DP_MST = 11,
};
-#define INTEL_DVO_CHIP_NONE 0
-#define INTEL_DVO_CHIP_LVDS 1
-#define INTEL_DVO_CHIP_TMDS 2
-#define INTEL_DVO_CHIP_TVOUT 4
-
#define INTEL_DSI_VIDEO_MODE 0
#define INTEL_DSI_COMMAND_MODE 1
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 930013..79a43f 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -39,6 +39,11 @@
#include "intel_dvo_dev.h"
#include "intel_panel.h"
+#define INTEL_DVO_CHIP_NONE0
+#define INTEL_DVO_CHIP_LVDS1
+#define INTEL_DVO_CHIP_TMDS2
+#define INTEL_DVO_CHIP_TVOUT 4
+
#define SIL164_ADDR0x38
#define CH7xxx_ADDR0x76
#define TFP410_ADDR0x38
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/13] drm/i915: the great header refactoring, part three
Continue the header refactoring started in [1] and [2].
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/59022/
[2] https://patchwork.freedesktop.org/series/60060/
Jani Nikula (13):
drm/i915/dvo: move DVO chip types to intel_dvo.c
drm/i915/dsi: move operation mode types to intel_dsi.h
drm/i915: move ranges to intel_display.c
drm/i915: remove unused/stale macros and comments from intel_drv.h
drm/i915/csr: move CSR version macros to intel_csr.h
drm/i915: extract intel_dpio_phy.h from i915_drv.h
drm/i915: extract intel_lpe_audio.h from i915_drv.h
drm/i915: extract intel_acpi.h from i915_drv.h
drm/i915: extract i915_debugfs.h from i915_drv.h
drm/i915: move i915_vgacntrl_reg() where needed
drm/i915: make i915_utils.h self-contained
drm/i915: move more generic utils to i915_utils.h
drm/i915: extract intel_gmbus.h from i915_drv.h and rename intel_i2c.c
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/Makefile.header-test | 6 +
drivers/gpu/drm/i915/i915_debugfs.c | 2 +
drivers/gpu/drm/i915/i915_debugfs.h | 20 +++
drivers/gpu/drm/i915/i915_drv.c | 8 +-
drivers/gpu/drm/i915/i915_drv.h | 145
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
drivers/gpu/drm/i915/i915_irq.c | 1 +
drivers/gpu/drm/i915/i915_suspend.c | 3 +-
drivers/gpu/drm/i915/i915_utils.h | 159 +-
drivers/gpu/drm/i915/intel_acpi.c | 3 +
drivers/gpu/drm/i915/intel_acpi.h | 17 ++
drivers/gpu/drm/i915/intel_audio.c| 2 +-
drivers/gpu/drm/i915/intel_bios.c | 2 +
drivers/gpu/drm/i915/intel_crt.c | 1 +
drivers/gpu/drm/i915/intel_csr.h | 4 +
drivers/gpu/drm/i915/intel_ddi.c | 2 +
drivers/gpu/drm/i915/intel_display.c | 29 +++-
drivers/gpu/drm/i915/intel_dp.c | 2 +
drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
drivers/gpu/drm/i915/intel_dpio_phy.c | 1 +
drivers/gpu/drm/i915/intel_dpio_phy.h | 58 +++
drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 140 ---
drivers/gpu/drm/i915/intel_dsi.h | 3 +
drivers/gpu/drm/i915/intel_dvo.c | 6 +
.../drm/i915/{intel_i2c.c => intel_gmbus.c} | 27 ++-
drivers/gpu/drm/i915/intel_gmbus.h| 27 +++
drivers/gpu/drm/i915/intel_hdmi.c | 3 +
drivers/gpu/drm/i915/intel_lpe_audio.c| 8 +-
drivers/gpu/drm/i915/intel_lpe_audio.h| 22 +++
drivers/gpu/drm/i915/intel_lvds.c | 1 +
drivers/gpu/drm/i915/intel_pipe_crc.h | 3 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
drivers/gpu/drm/i915/intel_sdvo.c | 1 +
35 files changed, 408 insertions(+), 304 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_debugfs.h
create mode 100644 drivers/gpu/drm/i915/intel_acpi.h
create mode 100644 drivers/gpu/drm/i915/intel_dpio_phy.h
rename drivers/gpu/drm/i915/{intel_i2c.c => intel_gmbus.c} (98%)
create mode 100644 drivers/gpu/drm/i915/intel_gmbus.h
create mode 100644 drivers/gpu/drm/i915/intel_lpe_audio.h
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/13] drm/i915/dsi: move operation mode types to intel_dsi.h
Reduce clutter from intel_drv.h with the minimal change.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h | 3 ---
drivers/gpu/drm/i915/intel_dsi.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab11c3..25a5fb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -184,9 +184,6 @@ enum intel_output_type {
INTEL_OUTPUT_DP_MST = 11,
};
-#define INTEL_DSI_VIDEO_MODE 0
-#define INTEL_DSI_COMMAND_MODE 1
-
struct intel_framebuffer {
struct drm_framebuffer base;
struct intel_rotation_info rot_info;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 1d1e6b..f9b9006 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -28,6 +28,9 @@
#include
#include "intel_drv.h"
+#define INTEL_DSI_VIDEO_MODE 0
+#define INTEL_DSI_COMMAND_MODE 1
+
/* Dual Link support */
#define DSI_DUAL_LINK_NONE 0
#define DSI_DUAL_LINK_FRONT_BACK 1
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Leave engine parking to the engines
Drop the check in GEM parking that the engines were already parked. The
intention here was that before we dropped the GT wakeref, we were sure
that no more interrupts could be raised -- however, we have already
dropped the wakeref by this point and the warning is no longer valid.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_pm.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c
b/drivers/gpu/drm/i915/i915_gem_pm.c
index 3b6e8d5be8e1..49b0ce594f20 100644
--- a/drivers/gpu/drm/i915/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/i915_gem_pm.c
@@ -17,24 +17,8 @@ static void i915_gem_park(struct drm_i915_private *i915)
lockdep_assert_held(&i915->drm.struct_mutex);
- for_each_engine(engine, i915, id) {
- /*
-* We are committed now to parking the engines, make sure there
-* will be no more interrupts arriving later and the engines
-* are truly idle.
-*/
- if (wait_for(intel_engine_is_idle(engine), 10)) {
- struct drm_printer p = drm_debug_printer(__func__);
-
- dev_err(i915->drm.dev,
- "%s is not idle before parking\n",
- engine->name);
- intel_engine_dump(engine, &p, NULL);
- }
- tasklet_kill(&engine->execlists.tasklet);
-
+ for_each_engine(engine, i915, id)
i915_gem_batch_pool_fini(&engine->batch_pool);
- }
i915_timelines_park(i915);
i915_vma_parked(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Flush the tasklet on parking
Tidy up the cleanup sequence by always ensure that the tasklet is
flushed on parking (before we cleanup). The parking provides a
convenient point to ensure that the backend is truly idle.
v2: Do the full check for idleness before parking, to be sure we flush
any residual interrupt.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 27 +
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 2 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 16 ++--
drivers/gpu/drm/i915/intel_guc_submission.c | 2 ++
5 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 763f34af55eb..797d8f0d0a6e 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1097,6 +1097,8 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine)
if (READ_ONCE(engine->execlists.active)) {
struct tasklet_struct *t = &engine->execlists.tasklet;
+ synchronize_irq(engine->i915->drm.irq);
+
local_bh_disable();
if (tasklet_trylock(t)) {
/* Must wait for any GPU reset in progress. */
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3976aea3c1d1..ccf034764741 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -10,7 +10,7 @@
#include "intel_engine_pm.h"
#include "intel_gt_pm.h"
-static int intel_engine_unpark(struct intel_wakeref *wf)
+static int __engine_unpark(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
@@ -37,7 +37,24 @@ static int intel_engine_unpark(struct intel_wakeref *wf)
void intel_engine_pm_get(struct intel_engine_cs *engine)
{
- intel_wakeref_get(engine->i915, &engine->wakeref, intel_engine_unpark);
+ intel_wakeref_get(engine->i915, &engine->wakeref, __engine_unpark);
+}
+
+void intel_engine_park(struct intel_engine_cs *engine)
+{
+ /*
+* We are committed now to parking this engine, make sure there
+* will be no more interrupts arriving later and the engine
+* is truly idle.
+*/
+ if (wait_for(intel_engine_is_idle(engine), 10)) {
+ struct drm_printer p = drm_debug_printer(__func__);
+
+ dev_err(engine->i915->drm.dev,
+ "%s is not idle before parking\n",
+ engine->name);
+ intel_engine_dump(engine, &p, NULL);
+ }
}
static bool switch_to_kernel_context(struct intel_engine_cs *engine)
@@ -56,7 +73,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
* Note, we do this without taking the timeline->mutex. We cannot
* as we may be called while retiring the kernel context and so
* already underneath the timeline->mutex. Instead we rely on the
-* exclusive property of the intel_engine_park that prevents anyone
+* exclusive property of the __engine_park that prevents anyone
* else from creating a request on this engine. This also requires
* that the ring is empty and we avoid any waits while constructing
* the context, as they assume protection by the timeline->mutex.
@@ -76,7 +93,7 @@ static bool switch_to_kernel_context(struct intel_engine_cs
*engine)
return false;
}
-static int intel_engine_park(struct intel_wakeref *wf)
+static int __engine_park(struct intel_wakeref *wf)
{
struct intel_engine_cs *engine =
container_of(wf, typeof(*engine), wakeref);
@@ -114,7 +131,7 @@ static int intel_engine_park(struct intel_wakeref *wf)
void intel_engine_pm_put(struct intel_engine_cs *engine)
{
- intel_wakeref_put(engine->i915, &engine->wakeref, intel_engine_park);
+ intel_wakeref_put(engine->i915, &engine->wakeref, __engine_park);
}
void intel_engine_init__pm(struct intel_engine_cs *engine)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
index 143ac90ba117..b326cd993d60 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
@@ -13,6 +13,8 @@ struct intel_engine_cs;
void intel_engine_pm_get(struct intel_engine_cs *engine);
void intel_engine_pm_put(struct intel_engine_cs *engine);
+void intel_engine_park(struct intel_engine_cs *engine);
+
void intel_engine_init__pm(struct intel_engine_cs *engine);
int intel_engines_resume(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 22cc895aca1b..c4684bdfae07 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -136,6 +136,7 @@
#inclu
[Intel-gfx] [PATCH 05/13] drm/i915/csr: move CSR version macros to intel_csr.h
Reduce clutter from i915_drv.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gpu_error.c | 1 +
drivers/gpu/drm/i915/intel_csr.h | 4
4 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e4dff..0d7d19 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -36,6 +36,7 @@
#include "i915_gem_context.h"
#include "i915_irq.h"
+#include "intel_csr.h"
#include "intel_dp.h"
#include "intel_drv.h"
#include "intel_fbc.h"
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9a634b..9e701d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -345,10 +345,6 @@ struct drm_i915_display_funcs {
void (*load_luts)(const struct intel_crtc_state *crtc_state);
};
-#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
-#define CSR_VERSION_MAJOR(version) ((version) >> 16)
-#define CSR_VERSION_MINOR(version) ((version) & 0x)
-
struct intel_csr {
struct work_struct work;
const char *fw_path;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index e1b858..4f85cbd 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -39,6 +39,7 @@
#include "i915_drv.h"
#include "i915_gpu_error.h"
#include "intel_atomic.h"
+#include "intel_csr.h"
#include "intel_overlay.h"
static inline const struct intel_engine_cs *
diff --git a/drivers/gpu/drm/i915/intel_csr.h b/drivers/gpu/drm/i915/intel_csr.h
index 17a32c..03c64f8 100644
--- a/drivers/gpu/drm/i915/intel_csr.h
+++ b/drivers/gpu/drm/i915/intel_csr.h
@@ -8,6 +8,10 @@
struct drm_i915_private;
+#define CSR_VERSION(major, minor) ((major) << 16 | (minor))
+#define CSR_VERSION_MAJOR(version) ((version) >> 16)
+#define CSR_VERSION_MINOR(version) ((version) & 0x)
+
void intel_csr_ucode_init(struct drm_i915_private *i915);
void intel_csr_load_program(struct drm_i915_private *i915);
void intel_csr_ucode_fini(struct drm_i915_private *i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/13] drm/i915: remove unused/stale macros and comments from intel_drv.h
Reduce clutter from intel_drv.h.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 709647..addf6f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -158,15 +158,6 @@ struct drm_printer;
* Display related stuff
*/
-/* store information about an Ixxx DVO */
-/* The i830->i865 use multiple DVOs with multiple i2cs */
-/* the i915, i945 have a single sDVO i2c bus - which is different */
-#define MAX_OUTPUTS 6
-/* maximum connectors per crtcs in the mode set */
-
-#define INTEL_I2C_BUS_DVO 1
-#define INTEL_I2C_BUS_SDVO 2
-
/* these are outputs from the chip - integrated only
external chips are via DVO or SDVO output */
enum intel_output_type {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
