Re: [Intel-gfx] [PATCH v2 1/2] drm/panel: panel-innolux: drop unused variable
On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote: > The num_supplies variable is not used, delete it. > Build tested. > > Signed-off-by: Sam Ravnborg > Cc: Thierry Reding > Cc: David Airlie > Cc: Daniel Vetter Reviewed-by: Linus Walleij Yours, Linus Walleij ___ 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: adding state checker for gamma lut values (rev10)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev10) URL : https://patchwork.freedesktop.org/series/58039/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6148_full -> Patchwork_13107_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13107_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13107_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_13107_full: ### IGT changes ### Possible regressions * igt@gem_pwrite@huge-cpu-forwards: - shard-snb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-snb6/igt@gem_pwr...@huge-cpu-forwards.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-snb2/igt@gem_pwr...@huge-cpu-forwards.html * igt@kms_color@pipe-b-ctm-red-to-blue: - shard-hsw: [PASS][3] -> [DMESG-WARN][4] +10 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-hsw8/igt@kms_co...@pipe-b-ctm-red-to-blue.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw1/igt@kms_co...@pipe-b-ctm-red-to-blue.html * igt@runner@aborted: - shard-hsw: NOTRUN -> ([FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw2/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw1/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw6/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw1/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw4/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw7/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw4/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw1/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw6/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-hsw8/igt@run...@aborted.html - shard-snb: NOTRUN -> [FAIL][16] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-snb2/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_13107_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@in-flight-suspend: - shard-glk: [PASS][17] -> [FAIL][18] ([fdo#110667]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-glk1/igt@gem_...@in-flight-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-glk6/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@wide-render: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713] / [fdo#110338 ]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb4/igt@gem_exec_sched...@wide-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-iclb1/igt@gem_exec_sched...@wide-render.html * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: [PASS][21] -> [TIMEOUT][22] ([fdo#109673]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb6/igt@gem_mmap_...@forked-big-copy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-iclb4/igt@gem_mmap_...@forked-big-copy.html * igt@gem_workarounds@suspend-resume-context: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#104108]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-skl1/igt@gem_workarou...@suspend-resume-context.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-skl10/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@legacy-planes: - shard-iclb: [PASS][25] -> [INCOMPLETE][26] ([fdo#107713] / [fdo#108840] / [fdo#109960]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb7/igt@i915_pm_...@legacy-planes.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/shard-iclb2/igt@i915_pm_...@legacy-planes.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-apl: [PASS][27] -> [DMESG-WARN][28] ([
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6) URL : https://patchwork.freedesktop.org/series/61047/ State : success == Summary == CI Bug Log - changes from CI_DRM_6148_full -> Patchwork_13106_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13106_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@forked-big-copy: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#109100]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb6/igt@gem_mmap_...@forked-big-copy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-iclb1/igt@gem_mmap_...@forked-big-copy.html * igt@gem_softpin@noreloc-s3: - shard-snb: [PASS][3] -> [DMESG-WARN][4] ([fdo#102365]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-snb2/igt@gem_soft...@noreloc-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-snb7/igt@gem_soft...@noreloc-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-iclb: [PASS][5] -> [FAIL][6] ([fdo#108686]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb4/igt@gem_tiled_swapp...@non-threaded.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-iclb2/igt@gem_tiled_swapp...@non-threaded.html - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-glk2/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_suspend@fence-restore-untiled: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +4 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-apl8/igt@i915_susp...@fence-restore-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-apl7/igt@i915_susp...@fence-restore-untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([fdo#103359] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-glk7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-glk2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt: - shard-snb: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-snb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-snb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc: - shard-hsw: [PASS][17] -> [SKIP][18] ([fdo#109271]) +23 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-hsw7/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-hsw1/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-shrfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-blt: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-blt.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_primary_mmap_gtt: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/shard-iclb2/igt@kms_psr@psr2_primary_m
Re: [Intel-gfx] [PATCH 2/5] drm/i915/perf: allow holding preemption on filtered ctx
On 24/05/2019 11:07, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-05-24 10:51:49) On 24/05/2019 10:42, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-05-24 10:28:16) On 21/05/2019 17:36, Chris Wilson wrote: Quoting Lionel Landwerlin (2019-05-21 15:08:52) diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c index f263a8374273..2ad95977f7a8 100644 --- a/drivers/gpu/drm/i915/gt/intel_lrc.c +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c @@ -2085,7 +2085,7 @@ static int gen9_emit_bb_start(struct i915_request *rq, if (IS_ERR(cs)) return PTR_ERR(cs); - *cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE; + *cs++ = MI_ARB_ON_OFF | rq->hw_context->arb_enable; My prediction is that this will result in this context being reset due to preemption timeouts and the context under profile being banned. Note that preemption timeouts will be the primary means for hang detection for endless batches. -Chris Another thought : What if we ran with the max priority? It would be fine to have the hangcheck preempt the workload (it's pretty short and shouldn't affect perf counters from 3d/compute pipeline much) as long as ensure nothing else runs. It's certainly safer from the pov that we don't block preemption and so don't incur forced resets. Not keen on the system being perturbed by the act of observing it, and I still dislike the notion of permitting one client to hog the GPU so easily. Makes me think of RT throttling, and generally throwing out the absolute priority system (in exchange for computed deadlines or something). -Chris I don't like it much either but I can't see how to do otherwise with the hardware we currently have. I'm thinking of 2 priorities values one of scheduling, one once running. It's not quite that easy as you may start running concurrently with one of your dependencies and must therefore manage the priority inversion if you boost yourself. And I've just gone through and thrown out the current complexity of manipulating priority as they run because it made timeslicing much harder (where the priority was changing between evaluating the need for the context switch and the context switch occurring -- such mistakes can be noticed in throughput sensitive transcode workloads). It's like you wrote a scheduler before! Here is how I could see this work. I can see the 3 different stages of a request : - waiting on dependencies - in the engine queue - in the HW The request would maintain is normal/default priority until it hits the HW. When hitting the HW for the first time, its priority is upgraded to perf priority so that it sticks to the HW until completition (or some other timeout kicks it off the HW). Does that still sound broken? Thanks a lot, -Lionel Most contexts would have both values equal. Could mitigate the issue a bit? A bit, it gives you a soft notion of a no-preempt flag without queue jumping. rq_prio(rq) | intel_context->effective_priority or somesuch. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC 32.0.3 (rev6)
== Series Details == Series: GuC 32.0.3 (rev6) URL : https://patchwork.freedesktop.org/series/58760/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6150 -> Patchwork_13108 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13108 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13108, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13108: ### IGT changes ### Possible regressions * igt@i915_selftest@live_hangcheck: - fi-icl-u3: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-icl-u3/igt@i915_selftest@live_hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-icl-u3/igt@i915_selftest@live_hangcheck.html * igt@i915_selftest@live_workarounds: - fi-icl-y: [PASS][3] -> [DMESG-FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-icl-y/igt@i915_selftest@live_workarounds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-icl-y/igt@i915_selftest@live_workarounds.html Known issues Here are the changes found in Patchwork_13108 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-skl-6260u: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html * 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_6150/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][9] -> [FAIL][10] ([fdo#109485]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: [PASS][11] -> [DMESG-WARN][12] ([fdo#106387]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-ilk-650/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@gem_exec_suspend@basic-s3: - fi-apl-guc: [DMESG-WARN][13] ([fdo#110512]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html * igt@i915_module_load@reload: - fi-apl-guc: [DMESG-WARN][15] ([fdo#110755]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-apl-guc/igt@i915_module_l...@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-apl-guc/igt@i915_module_l...@reload.html * igt@i915_selftest@live_evict: - fi-bsw-kefka: [DMESG-WARN][17] ([fdo#107709]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-bsw-kefka/igt@i915_selftest@live_evict.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-bsw-kefka/igt@i915_selftest@live_evict.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][19] ([fdo#108602] / [fdo#108744]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: [FAIL][21] ([fdo#103167]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html - fi-icl-u2: [FAIL][23] ([fdo#103167]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6150/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13108/fi-icl-u2/igt@kms_frontbuf
[Intel-gfx] [PATCH v5 16/17] drm/i915/huc: Define HuC firmware version for Icelake
Define HuC firmware version for Icelake. v2: 8.4.3238 is now available Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Anusha Srivatsa Cc: Tony Ye Reviewed-by: Tony Ye --- drivers/gpu/drm/i915/intel_huc_fw.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c b/drivers/gpu/drm/i915/intel_huc_fw.c index 8bac6a051c18..05cbf8338f53 100644 --- a/drivers/gpu/drm/i915/intel_huc_fw.c +++ b/drivers/gpu/drm/i915/intel_huc_fw.c @@ -38,6 +38,10 @@ #define GLK_HUC_FW_MINOR 01 #define GLK_BLD_NUM 2893 +#define ICL_HUC_FW_MAJOR 8 +#define ICL_HUC_FW_MINOR 4 +#define ICL_BLD_NUM 3238 + #define HUC_FW_PATH(platform, major, minor, bld_num) \ "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \ __stringify(minor) "_" __stringify(bld_num) ".bin" @@ -58,6 +62,10 @@ MODULE_FIRMWARE(I915_KBL_HUC_UCODE); GLK_HUC_FW_MINOR, GLK_BLD_NUM) MODULE_FIRMWARE(I915_GLK_HUC_UCODE); +#define I915_ICL_HUC_UCODE HUC_FW_PATH(icl, ICL_HUC_FW_MAJOR, \ + ICL_HUC_FW_MINOR, ICL_BLD_NUM) +MODULE_FIRMWARE(I915_ICL_HUC_UCODE); + static void huc_fw_select(struct intel_uc_fw *huc_fw) { struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw); @@ -88,6 +96,10 @@ static void huc_fw_select(struct intel_uc_fw *huc_fw) huc_fw->path = I915_GLK_HUC_UCODE; huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR; huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR; + } else if (IS_ICELAKE(dev_priv)) { + huc_fw->path = I915_ICL_HUC_UCODE; + huc_fw->major_ver_wanted = ICL_HUC_FW_MAJOR; + huc_fw->minor_ver_wanted = ICL_HUC_FW_MINOR; } } -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 08/17] drm/i915/guc: New GuC interrupt register for Gen11
Gen11 defines new more flexible Host-to-GuC interrupt register. Now the host can write any 32-bit payload to trigger an interrupt and GuC can additionally read this payload from the register. Current GuC firmware ignores the payload so we just write 0. Bspec: 21043 Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Rodrigo Vivi Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_guc.c | 14 +- drivers/gpu/drm/i915/intel_guc_reg.h | 1 + 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 60e6463a3aac..888a1e999c8b 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -34,6 +34,13 @@ static void gen8_guc_raise_irq(struct intel_guc *guc) I915_WRITE(GUC_SEND_INTERRUPT, GUC_SEND_TRIGGER); } +static void gen11_guc_raise_irq(struct intel_guc *guc) +{ + struct drm_i915_private *dev_priv = guc_to_i915(guc); + + I915_WRITE(GEN11_GUC_HOST_INTERRUPT, 0); +} + static inline i915_reg_t guc_send_reg(struct intel_guc *guc, u32 i) { GEM_BUG_ON(!guc->send_regs.base); @@ -63,6 +70,8 @@ void intel_guc_init_send_regs(struct intel_guc *guc) void intel_guc_init_early(struct intel_guc *guc) { + struct drm_i915_private *i915 = guc_to_i915(guc); + intel_guc_fw_init_early(guc); intel_guc_ct_init_early(&guc->ct); intel_guc_log_init_early(&guc->log); @@ -71,7 +80,10 @@ void intel_guc_init_early(struct intel_guc *guc) spin_lock_init(&guc->irq_lock); guc->send = intel_guc_send_nop; guc->handler = intel_guc_to_host_event_handler_nop; - guc->notify = gen8_guc_raise_irq; + if (INTEL_GEN(i915) >= 11) + guc->notify = gen11_guc_raise_irq; + else + guc->notify = gen8_guc_raise_irq; } static int guc_init_wq(struct intel_guc *guc) diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h index 57e7ad522c2f..aec02eddbaed 100644 --- a/drivers/gpu/drm/i915/intel_guc_reg.h +++ b/drivers/gpu/drm/i915/intel_guc_reg.h @@ -103,6 +103,7 @@ #define GUC_SEND_INTERRUPT _MMIO(0xc4c8) #define GUC_SEND_TRIGGER (1<<0) +#define GEN11_GUC_HOST_INTERRUPT _MMIO(0x1901f0) #define GUC_NUM_DOORBELLS 256 -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 10/17] drm/i915/huc: New HuC status register for Gen11
Gen11 defines new register for checking HuC authentication status. Look into the right register and bit. v2: use reg/mask/value instead of dedicated functions (Daniele) BSpec: 19686 Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tony Ye Cc: Vinay Belgaumkar Cc: John Spotswood Cc: Anusha Srivatsa Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_guc_reg.h | 3 +++ drivers/gpu/drm/i915/intel_huc.c | 26 +++--- drivers/gpu/drm/i915/intel_huc.h | 7 +++ 3 files changed, 29 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h index d26de5193568..7eba65795b58 100644 --- a/drivers/gpu/drm/i915/intel_guc_reg.h +++ b/drivers/gpu/drm/i915/intel_guc_reg.h @@ -79,6 +79,9 @@ #define HUC_STATUS2 _MMIO(0xD3B0) #define HUC_FW_VERIFIED (1<<7) +#define GEN11_HUC_KERNEL_LOAD_INFO _MMIO(0xC1DC) +#define HUC_LOAD_SUCCESSFUL(1 << 0) + #define GUC_WOPCM_SIZE _MMIO(0xc050) #define GUC_WOPCM_SIZE_LOCKED (1<<0) #define GUC_WOPCM_SIZE_SHIFT 12 diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c index 1ff1fb015e58..8572a0588efc 100644 --- a/drivers/gpu/drm/i915/intel_huc.c +++ b/drivers/gpu/drm/i915/intel_huc.c @@ -29,7 +29,19 @@ void intel_huc_init_early(struct intel_huc *huc) { + struct drm_i915_private *i915 = huc_to_i915(huc); + intel_huc_fw_init_early(huc); + + if (INTEL_GEN(i915) >= 11) { + huc->status.reg = GEN11_HUC_KERNEL_LOAD_INFO; + huc->status.mask = HUC_LOAD_SUCCESSFUL; + huc->status.value = HUC_LOAD_SUCCESSFUL; + } else { + huc->status.reg = HUC_STATUS2; + huc->status.mask = HUC_FW_VERIFIED; + huc->status.value = HUC_FW_VERIFIED; + } } int intel_huc_init_misc(struct intel_huc *huc) @@ -110,7 +122,6 @@ int intel_huc_auth(struct intel_huc *huc) { struct drm_i915_private *i915 = huc_to_i915(huc); struct intel_guc *guc = &i915->guc; - u32 status; int ret; if (huc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS) @@ -125,12 +136,12 @@ int intel_huc_auth(struct intel_huc *huc) /* Check authentication status, it should be done by now */ ret = __intel_wait_for_register(&i915->uncore, - HUC_STATUS2, - HUC_FW_VERIFIED, - HUC_FW_VERIFIED, - 2, 50, &status); + huc->status.reg, + huc->status.mask, + huc->status.value, + 2, 50, NULL); if (ret) { - DRM_ERROR("HuC: Firmware not verified %#x\n", status); + DRM_ERROR("HuC: Firmware not verified %d\n", ret); goto fail; } @@ -164,7 +175,8 @@ int intel_huc_check_status(struct intel_huc *huc) return -ENODEV; with_intel_runtime_pm(dev_priv, wakeref) - status = I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED; + status = (I915_READ(huc->status.reg) & huc->status.mask) == + huc->status.value; return status; } diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h index a0c21ae02a99..2a6c94e79f17 100644 --- a/drivers/gpu/drm/i915/intel_huc.h +++ b/drivers/gpu/drm/i915/intel_huc.h @@ -25,6 +25,7 @@ #ifndef _INTEL_HUC_H_ #define _INTEL_HUC_H_ +#include "i915_reg.h" #include "intel_uc_fw.h" #include "intel_huc_fw.h" @@ -35,6 +36,12 @@ struct intel_huc { /* HuC-specific additions */ struct i915_vma *rsa_data; void *rsa_data_vaddr; + + struct { + i915_reg_t reg; + u32 mask; + u32 value; + } status; }; void intel_huc_init_early(struct intel_huc *huc); -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 02/17] drm/i915/guc: Don't allow GuC submission
Due to the upcoming changes to the GuC ABI interface, we must disable GuC submission mode until final ABI will be available on all GuC firmwares. To avoid regressions on systems configured to run with no longer supported configuration "enable_guc=3" or "enable_guc=1" clear GuC submission bit. v2: force switch to non-GuC submission mode v3: use GEM_BUG_ON (Joonas) Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Daniele Ceraolo Spurio Cc: John Spotswood Cc: Vinay Belgaumkar Cc: Tony Ye Cc: Anusha Srivatsa Cc: Jeff Mcgee Cc: Antonio Argenziano Cc: Sujaritha Sundaresan Cc: Martin Peres Acked-by: Martin Peres --- drivers/gpu/drm/i915/intel_uc.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 1a265fbd95c7..75943ea4e65d 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -130,6 +130,15 @@ static void sanitize_options_early(struct drm_i915_private *i915) "no HuC firmware"); } + /* XXX: GuC submission is unavailable for now */ + if (intel_uc_is_using_guc_submission(i915)) { + DRM_INFO("Incompatible option detected: %s=%d, %s!\n", +"enable_guc", i915_modparams.enable_guc, +"GuC submission not supported"); + DRM_INFO("Switching to non-GuC submission mode!\n"); + i915_modparams.enable_guc &= ~ENABLE_GUC_SUBMISSION; + } + /* A negative value means "use platform/config default" */ if (i915_modparams.guc_log_level < 0) i915_modparams.guc_log_level = @@ -298,6 +307,9 @@ int intel_uc_init(struct drm_i915_private *i915) if (!HAS_GUC(i915)) return -ENODEV; + /* XXX: GuC submission is unavailable for now */ + GEM_BUG_ON(USES_GUC_SUBMISSION(i915)); + ret = intel_guc_init(guc); if (ret) return ret; -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 09/17] drm/i915/guc: New GuC scratch registers for Gen11
Gen11 adds new set of scratch registers that can be used for MMIO based Host-to-Guc communication. Due to limited number of these registers it is expected that host will use them only for command transport buffers (CTB) communication setup if one is available. Bspec: 21044 Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Rodrigo Vivi Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_guc.c | 12 +--- drivers/gpu/drm/i915/intel_guc_reg.h | 3 +++ 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 888a1e999c8b..538868a10168 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -56,9 +56,15 @@ void intel_guc_init_send_regs(struct intel_guc *guc) enum forcewake_domains fw_domains = 0; unsigned int i; - guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0)); - guc->send_regs.count = GUC_MAX_MMIO_MSG_LEN; - BUILD_BUG_ON(GUC_MAX_MMIO_MSG_LEN > SOFT_SCRATCH_COUNT); + if (HAS_GUC_CT(dev_priv) && INTEL_GEN(dev_priv) >= 11) { + guc->send_regs.base = + i915_mmio_reg_offset(GEN11_SOFT_SCRATCH(0)); + guc->send_regs.count = GEN11_SOFT_SCRATCH_COUNT; + } else { + guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0)); + guc->send_regs.count = GUC_MAX_MMIO_MSG_LEN; + BUILD_BUG_ON(GUC_MAX_MMIO_MSG_LEN > SOFT_SCRATCH_COUNT); + } for (i = 0; i < guc->send_regs.count; i++) { fw_domains |= intel_uncore_forcewake_for_reg(&dev_priv->uncore, diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h index aec02eddbaed..d26de5193568 100644 --- a/drivers/gpu/drm/i915/intel_guc_reg.h +++ b/drivers/gpu/drm/i915/intel_guc_reg.h @@ -51,6 +51,9 @@ #define SOFT_SCRATCH(n)_MMIO(0xc180 + (n) * 4) #define SOFT_SCRATCH_COUNT 16 +#define GEN11_SOFT_SCRATCH(n) _MMIO(0x190240 + (n) * 4) +#define GEN11_SOFT_SCRATCH_COUNT 4 + #define UOS_RSA_SCRATCH(i) _MMIO(0xc200 + (i) * 4) #define UOS_RSA_SCRATCH_COUNT 64 -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 03/17] drm/i915/guc: Updates for GuC 32.0.3 firmware
New GuC 32.0.3 firmware made many changes around its ABI that require driver updates: * FW release version numbering schema now includes patch number * FW release version encoding in CSS header * Boot parameters * Suspend/resume protocol * Sample-forcewake command * Additional Data Structures (ADS) This commit is a squash of patches 3-8 from series [1]. [1] https://patchwork.freedesktop.org/series/58760/ Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Daniele Ceraolo Spurio Cc: Rodrigo Vivi Cc: Anusha Srivatsa Cc: Jeff Mcgee Cc: John Spotswood Cc: Tvrtko Ursulin Cc: Tomasz Lis Acked-by: Daniele Ceraolo Spurio # numbering schema Acked-by: Daniele Ceraolo Spurio # ccs heaser Acked-by: Daniele Ceraolo Spurio # boot params Acked-by: John Spotswood # suspend/resume Acked-by: Daniele Ceraolo Spurio # sample-forcewake Acked-by: John Spotswood # sample-forcewake Acked-by: Daniele Ceraolo Spurio # ADS --- drivers/gpu/drm/i915/gt/intel_engine.h| 2 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/intel_guc.c | 88 -- drivers/gpu/drm/i915/intel_guc_ads.c | 95 +++ drivers/gpu/drm/i915/intel_guc_fw.c | 75 + drivers/gpu/drm/i915/intel_guc_fwif.h | 191 ++ drivers/gpu/drm/i915/intel_uc_fw.c| 20 +-- 7 files changed, 237 insertions(+), 243 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h b/drivers/gpu/drm/i915/gt/intel_engine.h index 9359b3a7ad9c..1c0db151f0b1 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine.h +++ b/drivers/gpu/drm/i915/gt/intel_engine.h @@ -526,6 +526,8 @@ ktime_t intel_engine_get_busy_time(struct intel_engine_cs *engine); struct i915_request * intel_engine_find_active_request(struct intel_engine_cs *engine); +u32 intel_engine_context_size(struct drm_i915_private *i915, u8 class); + #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST) static inline bool inject_preempt_hang(struct intel_engine_execlists *execlists) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index 2590f5904b67..1c83ea9adac0 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -156,7 +156,7 @@ static const struct engine_info intel_engines[] = { }; /** - * ___intel_engine_context_size() - return the size of the context for an engine + * intel_engine_context_size() - return the size of the context for an engine * @dev_priv: i915 device private * @class: engine class * @@ -169,8 +169,7 @@ static const struct engine_info intel_engines[] = { * in LRC mode, but does not include the "shared data page" used with * GuC submission. The caller should account for this if using the GuC. */ -static u32 -__intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class) +u32 intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class) { u32 cxt_size; @@ -327,8 +326,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv, engine->uabi_class = intel_engine_classes[info->class].uabi_class; - engine->context_size = __intel_engine_context_size(dev_priv, - engine->class); + engine->context_size = intel_engine_context_size(dev_priv, +engine->class); if (WARN_ON(engine->context_size > BIT(20))) engine->context_size = 0; if (engine->context_size) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index c4ac29309fcc..60e6463a3aac 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -250,14 +250,7 @@ void intel_guc_fini(struct intel_guc *guc) static u32 guc_ctl_debug_flags(struct intel_guc *guc) { u32 level = intel_guc_log_get_level(&guc->log); - u32 flags; - u32 ads; - - ads = intel_guc_ggtt_offset(guc, guc->ads_vma) >> PAGE_SHIFT; - flags = ads << GUC_ADS_ADDR_SHIFT | GUC_ADS_ENABLED; - - if (!GUC_LOG_LEVEL_IS_ENABLED(level)) - flags |= GUC_LOG_DEFAULT_DISABLED; + u32 flags = 0; if (!GUC_LOG_LEVEL_IS_VERBOSE(level)) flags |= GUC_LOG_DISABLED; @@ -272,11 +265,7 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc) { u32 flags = 0; - flags |= GUC_CTL_VCS2_ENABLED; - - if (USES_GUC_SUBMISSION(guc_to_i915(guc))) - flags |= GUC_CTL_KERNEL_SUBMISSIONS; - else + if (!USES_GUC_SUBMISSION(guc_to_i915(guc))) flags |= GUC_CTL_DISABLE_SCHEDULER; return flags; @@ -340,6 +329,14 @@ static u32 guc_ctl_log_params_flags(struct intel_guc *guc) return flags; } +static u32 guc_ctl_ads_flags(struct intel_guc *guc) +{ + u32 ads = intel_guc_ggtt_offset(guc, guc->ads_vma) >> PAGE_SHIFT; + u32 flags = ads << GUC_ADS_ADDR_SHIFT; + + return flags; +} + /*
[Intel-gfx] [PATCH v5 13/17] drm/i915/guc: Update GuC CTB response definition
Current GuC firmwares identify response message in a different way. v2: update comments for other H2G bits (Daniele) Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Kelvin Gardiner Cc: John Spotswood Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_guc_ct.c | 2 +- drivers/gpu/drm/i915/intel_guc_fwif.h | 8 +--- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c b/drivers/gpu/drm/i915/intel_guc_ct.c index dde1dc0d6e69..2d5dc2aa22a7 100644 --- a/drivers/gpu/drm/i915/intel_guc_ct.c +++ b/drivers/gpu/drm/i915/intel_guc_ct.c @@ -565,7 +565,7 @@ static inline unsigned int ct_header_get_action(u32 header) static inline bool ct_header_is_response(u32 header) { - return ct_header_get_action(header) == INTEL_GUC_ACTION_DEFAULT; + return !!(header & GUC_CT_MSG_IS_RESPONSE); } static int ctb_read(struct intel_guc_ct_buffer *ctb, u32 *data) diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h index fa745a58d38d..3d1de288d96c 100644 --- a/drivers/gpu/drm/i915/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h @@ -355,14 +355,16 @@ struct guc_ct_buffer_desc { * * bit[4..0] message len (in dwords) * bit[7..5] reserved - * bit[8] write fence to desc - * bit[9] write status to H2G buff - * bit[10] send status (via G2H) + * bit[8] response (G2H only) + * bit[8] write fence to desc (H2G only) + * bit[9] write status to H2G buff (H2G only) + * bit[10] send status back via G2H (H2G only) * bit[15..11] reserved * bit[31..16] action code */ #define GUC_CT_MSG_LEN_SHIFT 0 #define GUC_CT_MSG_LEN_MASK0x1F +#define GUC_CT_MSG_IS_RESPONSE (1 << 8) #define GUC_CT_MSG_WRITE_FENCE_TO_DESC (1 << 8) #define GUC_CT_MSG_WRITE_STATUS_TO_BUFF(1 << 9) #define GUC_CT_MSG_SEND_STATUS (1 << 10) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 17/17] HAX: Turn on GuC/HuC auto mode
Run GuC, run! Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 3f14e9881a0d..e28ae23de516 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -54,7 +54,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 04/17] drm/i915/guc: Reset GuC ADS during sanitize
GuC stores some data in there, which might be stale after a reset. Reinitialize whole ADS in case any part of it was corrupted during previous GuC run. v2: s/reinit/init, update functions descriptions (Tomek/Michal) v3: reset ADS right before fw upload Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: MichaĹ Winiarski Cc: Tomasz Lis Reviewed-by: Tomasz Lis #v2 Reviewed-by: MichaĹ Winiarski #v2 --- drivers/gpu/drm/i915/intel_guc_ads.c | 90 ++-- drivers/gpu/drm/i915/intel_guc_ads.h | 1 + drivers/gpu/drm/i915/intel_uc.c | 4 +- 3 files changed, 63 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c index 1aa1ec0ff4a1..ecb69fc94218 100644 --- a/drivers/gpu/drm/i915/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/intel_guc_ads.c @@ -72,43 +72,28 @@ static void guc_ct_pool_entries_init(struct guc_ct_pool_entry *pool, u32 num) */ #define LR_HW_CONTEXT_SIZE (80 * sizeof(u32)) -/** - * intel_guc_ads_create() - creates GuC ADS - * @guc: intel_guc struct - * - */ -int intel_guc_ads_create(struct intel_guc *guc) +/* The ads obj includes the struct itself and buffers passed to GuC */ +struct __guc_ads_blob { + struct guc_ads ads; + struct guc_policies policies; + struct guc_mmio_reg_state reg_state; + struct guc_gt_system_info system_info; + struct guc_clients_info clients_info; + struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE]; + u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE]; +} __packed; + +static int __guc_ads_init(struct intel_guc *guc) { struct drm_i915_private *dev_priv = guc_to_i915(guc); - struct i915_vma *vma; - /* The ads obj includes the struct itself and buffers passed to GuC */ - struct { - struct guc_ads ads; - struct guc_policies policies; - struct guc_mmio_reg_state reg_state; - struct guc_gt_system_info system_info; - struct guc_clients_info clients_info; - struct guc_ct_pool_entry ct_pool[GUC_CT_POOL_SIZE]; - u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE]; - } __packed *blob; + struct __guc_ads_blob *blob; const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE; u32 base; u8 engine_class; - int ret; - - GEM_BUG_ON(guc->ads_vma); - - vma = intel_guc_allocate_vma(guc, PAGE_ALIGN(sizeof(*blob))); - if (IS_ERR(vma)) - return PTR_ERR(vma); - - guc->ads_vma = vma; blob = i915_gem_object_pin_map(guc->ads_vma->obj, I915_MAP_WB); - if (IS_ERR(blob)) { - ret = PTR_ERR(blob); - goto err_vma; - } + if (IS_ERR(blob)) + return PTR_ERR(blob); /* GuC scheduling policies */ guc_policies_init(&blob->policies); @@ -143,7 +128,7 @@ int intel_guc_ads_create(struct intel_guc *guc) blob->system_info.vebox_enable_mask = VEBOX_MASK(dev_priv); blob->system_info.vdbox_sfc_support_mask = RUNTIME_INFO(dev_priv)->vdbox_sfc_access; - base = intel_guc_ggtt_offset(guc, vma); + base = intel_guc_ggtt_offset(guc, guc->ads_vma); /* Clients info */ guc_ct_pool_entries_init(blob->ct_pool, ARRAY_SIZE(blob->ct_pool)); @@ -162,6 +147,34 @@ int intel_guc_ads_create(struct intel_guc *guc) i915_gem_object_unpin_map(guc->ads_vma->obj); return 0; +} + +/** + * intel_guc_ads_create() - allocates and initializes GuC ADS. + * @guc: intel_guc struct + * + * GuC needs memory block (Additional Data Struct), where it will store + * some data. Allocate and initialize such memory block for GuC use. + */ +int intel_guc_ads_create(struct intel_guc *guc) +{ + const u32 size = PAGE_ALIGN(sizeof(struct __guc_ads_blob)); + struct i915_vma *vma; + int ret; + + GEM_BUG_ON(guc->ads_vma); + + vma = intel_guc_allocate_vma(guc, size); + if (IS_ERR(vma)) + return PTR_ERR(vma); + + guc->ads_vma = vma; + + ret = __guc_ads_init(guc); + if (ret) + goto err_vma; + + return 0; err_vma: i915_vma_unpin_and_release(&guc->ads_vma, 0); @@ -172,3 +185,18 @@ void intel_guc_ads_destroy(struct intel_guc *guc) { i915_vma_unpin_and_release(&guc->ads_vma, 0); } + +/** + * intel_guc_ads_reset() - prepares GuC Additional Data Struct for reuse + * @guc: intel_guc struct + * + * GuC stores some data in ADS, which might be stale after a reset. + * Reinitialize whole ADS in case any part of it was corrupted during + * previous GuC run. + */ +void intel_guc_ads_reset(struct intel_guc *guc) +{ + if (!guc->ads_vma) + return; + __guc_ads_init(guc); +} diff --git a/drivers/gpu/drm/i915/intel_guc_ads.h b/drivers/gpu/drm/i915/intel_guc_ads.h index c4735742c564..7f40f9cd5fb9 100644 --- a/drivers/gpu/drm/i
[Intel-gfx] [PATCH v5 05/17] drm/i915/guc: Always ask GuC to update power domain states
With newer GuC firmware it is always ok to ask GuC to update power domain states. Make it an unconditional initialization step. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: John Spotswood Reviewed-by: Daniele Ceraolo Spurio Reviewed-by: John Spotswood --- drivers/gpu/drm/i915/intel_guc_submission.c | 4 drivers/gpu/drm/i915/intel_uc.c | 8 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c index 987ff586d7f9..ffdab22db2b0 100644 --- a/drivers/gpu/drm/i915/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/intel_guc_submission.c @@ -1426,10 +1426,6 @@ int intel_guc_submission_enable(struct intel_guc *guc) GEM_BUG_ON(!guc->execbuf_client); - err = intel_guc_sample_forcewake(guc); - if (err) - return err; - err = guc_clients_enable(guc); if (err) return err; diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 082036164c0c..3eb4f4320667 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -439,14 +439,14 @@ int intel_uc_init_hw(struct drm_i915_private *i915) goto err_communication; } + ret = intel_guc_sample_forcewake(guc); + if (ret) + goto err_communication; + if (USES_GUC_SUBMISSION(i915)) { ret = intel_guc_submission_enable(guc); if (ret) goto err_communication; - } else if (INTEL_GEN(i915) < 11) { - ret = intel_guc_sample_forcewake(guc); - if (ret) - goto err_communication; } dev_info(i915->drm.dev, "GuC firmware version %u.%u\n", -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 01/17] drm/i915/guc: Change platform default GuC mode
Today our most desired GuC configuration is to only enable HuC if it is available (as we need authenticated HuC firmware to enable all media codecs on the hardware) and we really don't care about having GuC submission enabled. Change platform default GuC mode to match our goal, but note that we still don't change default modparam value (GuC/HuC disabled). v2: add why HuC is so important (Joonas) Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Daniele Ceraolo Spurio Cc: John Spotswood Cc: Vinay Belgaumkar Cc: Tony Ye Cc: Anusha Srivatsa Cc: Jeff Mcgee Cc: Antonio Argenziano Cc: Sujaritha Sundaresan Acked-by: Tony Ye Reviewed-by: Sujaritha Sundaresan Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 63fc12cbc25d..1a265fbd95c7 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -57,10 +57,8 @@ static int __get_platform_enable_guc(struct drm_i915_private *i915) struct intel_uc_fw *huc_fw = &i915->huc.fw; int enable_guc = 0; - /* Default is to enable GuC/HuC if we know their firmwares */ - if (intel_uc_fw_is_selected(guc_fw)) - enable_guc |= ENABLE_GUC_SUBMISSION; - if (intel_uc_fw_is_selected(huc_fw)) + /* Default is to use HuC if we know GuC and HuC firmwares */ + if (intel_uc_fw_is_selected(guc_fw) && intel_uc_fw_is_selected(huc_fw)) enable_guc |= ENABLE_GUC_LOAD_HUC; /* Any platform specific fine-tuning can be done here */ -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 15/17] drm/i915/guc: Define GuC firmware version for Icelake
Define GuC firmware version for Icelake. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Anusha Srivatsa Reviewed-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_guc_fw.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c b/drivers/gpu/drm/i915/intel_guc_fw.c index c1e9bb4e04fd..72cdafd9636a 100644 --- a/drivers/gpu/drm/i915/intel_guc_fw.c +++ b/drivers/gpu/drm/i915/intel_guc_fw.c @@ -65,6 +65,13 @@ MODULE_FIRMWARE(KBL_GUC_FIRMWARE_PATH); #define GLK_GUC_FIRMWARE_PATH __MAKE_GUC_FW_PATH(GLK) MODULE_FIRMWARE(GLK_GUC_FIRMWARE_PATH); +#define ICL_GUC_FW_PREFIX icl +#define ICL_GUC_FW_MAJOR 32 +#define ICL_GUC_FW_MINOR 0 +#define ICL_GUC_FW_PATCH 3 +#define ICL_GUC_FIRMWARE_PATH __MAKE_GUC_FW_PATH(ICL) +MODULE_FIRMWARE(ICL_GUC_FIRMWARE_PATH); + static void guc_fw_select(struct intel_uc_fw *guc_fw) { struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw); @@ -79,6 +86,10 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw) guc_fw->path = i915_modparams.guc_firmware_path; guc_fw->major_ver_wanted = 0; guc_fw->minor_ver_wanted = 0; + } else if (IS_ICELAKE(i915)) { + guc_fw->path = ICL_GUC_FIRMWARE_PATH; + guc_fw->major_ver_wanted = ICL_GUC_FW_MAJOR; + guc_fw->minor_ver_wanted = ICL_GUC_FW_MINOR; } else if (IS_GEMINILAKE(i915)) { guc_fw->path = GLK_GUC_FIRMWARE_PATH; guc_fw->major_ver_wanted = GLK_GUC_FW_MAJOR; -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 14/17] drm/i915/guc: Enable GuC CTB communication on Gen11
Gen11 GuC firmware expects H2G command messages to be sent over CTB (command transport buffers). Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: John Spotswood Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index d7c07a947497..fc66d7f348fc 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -746,6 +746,7 @@ static const struct intel_device_info intel_cannonlake_info = { }, \ GEN(11), \ .ddb_size = 2048, \ + .has_guc_ct = 1, \ .has_logical_ring_elsq = 1, \ .color = { .degamma_lut_size = 33, .gamma_lut_size = 1024 } -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 11/17] drm/i915/guc: Create vfuncs for the GuC interrupts control functions
From: Oscar Mateo Controlling and handling of the GuC interrupts is Gen specific. Create virtual functions to avoid redundant runtime Gen checks. Gen-specific versions of these functions will follow. v2: move vfuncs to struct guc (Daniele) v3: rebased Signed-off-by: Oscar Mateo Signed-off-by: Michal Wajdeczko Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Reviewed-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- drivers/gpu/drm/i915/intel_guc.c | 8 ++-- drivers/gpu/drm/i915/intel_guc.h | 8 +++- drivers/gpu/drm/i915/intel_uc.c | 21 ++--- 4 files changed, 34 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 233211fde0ea..607709a8c229 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -600,10 +600,10 @@ void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv) assert_rpm_wakelock_held(dev_priv); spin_lock_irq(&dev_priv->irq_lock); - if (!dev_priv->guc.interrupts_enabled) { + if (!dev_priv->guc.interrupts.enabled) { WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & dev_priv->pm_guc_events); - dev_priv->guc.interrupts_enabled = true; + dev_priv->guc.interrupts.enabled = true; gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events); } spin_unlock_irq(&dev_priv->irq_lock); @@ -614,7 +614,7 @@ void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv) assert_rpm_wakelock_held(dev_priv); spin_lock_irq(&dev_priv->irq_lock); - dev_priv->guc.interrupts_enabled = false; + dev_priv->guc.interrupts.enabled = false; gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events); diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 538868a10168..28642bf977bd 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -86,10 +86,14 @@ void intel_guc_init_early(struct intel_guc *guc) spin_lock_init(&guc->irq_lock); guc->send = intel_guc_send_nop; guc->handler = intel_guc_to_host_event_handler_nop; - if (INTEL_GEN(i915) >= 11) + if (INTEL_GEN(i915) >= 11) { guc->notify = gen11_guc_raise_irq; - else + } else { guc->notify = gen8_guc_raise_irq; + guc->interrupts.reset = gen9_reset_guc_interrupts; + guc->interrupts.enable = gen9_enable_guc_interrupts; + guc->interrupts.disable = gen9_disable_guc_interrupts; + } } static int guc_init_wq(struct intel_guc *guc) diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index d4b015ab8a36..cbfed7a77c8b 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -55,9 +55,15 @@ struct intel_guc { /* intel_guc_recv interrupt related state */ spinlock_t irq_lock; - bool interrupts_enabled; unsigned int msg_enabled_mask; + struct { + bool enabled; + void (*reset)(struct drm_i915_private *i915); + void (*enable)(struct drm_i915_private *i915); + void (*disable)(struct drm_i915_private *i915); + } interrupts; + struct i915_vma *ads_vma; struct i915_vma *stage_desc_pool; void *stage_desc_pool_vaddr; diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 3eb4f4320667..a5ba0f007959 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -218,11 +218,26 @@ static void guc_free_load_err_log(struct intel_guc *guc) i915_gem_object_put(guc->load_err_log); } +static void guc_reset_interrupts(struct intel_guc *guc) +{ + guc->interrupts.reset(guc_to_i915(guc)); +} + +static void guc_enable_interrupts(struct intel_guc *guc) +{ + guc->interrupts.enable(guc_to_i915(guc)); +} + +static void guc_disable_interrupts(struct intel_guc *guc) +{ + guc->interrupts.disable(guc_to_i915(guc)); +} + static int guc_enable_communication(struct intel_guc *guc) { struct drm_i915_private *i915 = guc_to_i915(guc); - gen9_enable_guc_interrupts(i915); + guc_enable_interrupts(guc); if (HAS_GUC_CT(i915)) return intel_guc_ct_enable(&guc->ct); @@ -250,7 +265,7 @@ static void guc_disable_communication(struct intel_guc *guc) if (HAS_GUC_CT(i915)) intel_guc_ct_disable(&guc->ct); - gen9_disable_guc_interrupts(i915); + guc_disable_interrupts(guc); guc->send = intel_guc_send_nop; guc->handler = intel_guc_to_host_event_handler_nop; @@ -391,7 +406,7 @@ int intel_uc_init_hw(struct drm_i915_private *i915) GEM_BUG_ON(!HAS_GUC(i915)); - gen9_reset_guc_interrupts(i9
[Intel-gfx] [PATCH v5 12/17] drm/i915/guc: Correctly handle GuC interrupts on Gen11
From: Oscar Mateo Starting Gen11 GuC shares interrupt registers with SG unit instead of PM. But for now we don't care about SG interrupts. v2: (Chris) v3: rebased (Michal) v4: more bspec pages, use macros, update commit msg (Michal Wi) Bspec: 19820, 19840, 19841, 20176 Signed-off-by: Oscar Mateo Signed-off-by: Michal Wajdeczko Cc: Tvrtko Ursulin Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Reviewed-by: Michał Winiarski --- drivers/gpu/drm/i915/i915_irq.c | 53 +++- drivers/gpu/drm/i915/i915_irq.h | 3 ++ drivers/gpu/drm/i915/i915_reg.h | 4 +++ drivers/gpu/drm/i915/intel_guc.c | 3 ++ drivers/gpu/drm/i915/intel_guc_reg.h | 18 ++ 5 files changed, 80 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 607709a8c229..ca8f4226e598 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -624,6 +624,42 @@ void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv) gen9_reset_guc_interrupts(dev_priv); } +void gen11_reset_guc_interrupts(struct drm_i915_private *i915) +{ + spin_lock_irq(&i915->irq_lock); + gen11_reset_one_iir(i915, 0, GEN11_GUC); + spin_unlock_irq(&i915->irq_lock); +} + +void gen11_enable_guc_interrupts(struct drm_i915_private *dev_priv) +{ + spin_lock_irq(&dev_priv->irq_lock); + if (!dev_priv->guc.interrupts.enabled) { + u32 events = REG_FIELD_PREP(ENGINE1_MASK, + GEN11_GUC_INTR_GUC2HOST); + + WARN_ON_ONCE(gen11_reset_one_iir(dev_priv, 0, GEN11_GUC)); + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, events); + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~events); + dev_priv->guc.interrupts.enabled = true; + } + spin_unlock_irq(&dev_priv->irq_lock); +} + +void gen11_disable_guc_interrupts(struct drm_i915_private *dev_priv) +{ + spin_lock_irq(&dev_priv->irq_lock); + dev_priv->guc.interrupts.enabled = false; + + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~0); + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0); + + spin_unlock_irq(&dev_priv->irq_lock); + synchronize_irq(dev_priv->drm.irq); + + gen11_reset_guc_interrupts(dev_priv); +} + /** * bdw_update_port_irq - update DE port interrupt * @dev_priv: driver private @@ -1893,6 +1929,12 @@ static void gen9_guc_irq_handler(struct drm_i915_private *dev_priv, u32 gt_iir) intel_guc_to_host_event_handler(&dev_priv->guc); } +static void gen11_guc_irq_handler(struct drm_i915_private *i915, u16 iir) +{ + if (iir & GEN11_GUC_INTR_GUC2HOST) + intel_guc_to_host_event_handler(&i915->guc); +} + static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv) { enum pipe pipe; @@ -3015,6 +3057,9 @@ static void gen11_other_irq_handler(struct drm_i915_private * const i915, const u8 instance, const u16 iir) { + if (instance == OTHER_GUC_INSTANCE) + return gen11_guc_irq_handler(i915, iir); + if (instance == OTHER_GTPM_INSTANCE) return gen11_rps_irq_handler(i915, iir); @@ -3545,6 +3590,8 @@ static void gen11_gt_irq_reset(struct drm_i915_private *dev_priv) I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0); I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK, ~0); + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0); + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~0); } static void gen11_irq_reset(struct drm_device *dev) @@ -4200,6 +4247,10 @@ static void gen11_gt_irq_postinstall(struct drm_i915_private *dev_priv) dev_priv->pm_imr = ~dev_priv->pm_ier; I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0); I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK, ~0); + + /* Same thing for GuC interrupts */ + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0); + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~0); } static void icp_irq_postinstall(struct drm_device *dev) @@ -4707,7 +4758,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv) for (i = 0; i < MAX_L3_SLICES; ++i) dev_priv->l3_parity.remap_info[i] = NULL; - if (HAS_GUC_SCHED(dev_priv)) + if (HAS_GUC_SCHED(dev_priv) && INTEL_GEN(dev_priv) < 11) dev_priv->pm_guc_events = GEN9_GUC_TO_HOST_INT_EVENT; /* Let's track the enabled rps events */ diff --git a/drivers/gpu/drm/i915/i915_irq.h b/drivers/gpu/drm/i915/i915_irq.h index 0ccd0d90919d..cb25dd213308 100644 --- a/drivers/gpu/drm/i915/i915_irq.h +++ b/drivers/gpu/drm/i915/i915_irq.h @@ -110,5 +110,8 @@ void gen8_irq_power_well_pre_disable(struct drm_i915_private *dev_priv, void gen9_reset_guc_interrupts(struct drm_i915_private *dev_priv); void gen9_enable_guc_interrupts(struct drm_i915_private *dev_priv); void gen9_disable_guc_interrupts(struct drm_i915_private *dev_priv); +void gen11_reset_guc_interrupts(struct drm_i915_priva
[Intel-gfx] [PATCH v5 00/17] GuC 32.0.3
New GuC firmwares (for SKL, BXT, KBL, GLK, ICL) with updated ABI interface. v2: only HuC authentication is supported v3: never allow to turn on GuC submission mode v4: rebased + newer HuC + GLK v5: squashed + last minutes small fixups Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Martin Peres Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Tony Ye Michal Wajdeczko (15): drm/i915/guc: Change platform default GuC mode drm/i915/guc: Don't allow GuC submission drm/i915/guc: Updates for GuC 32.0.3 firmware drm/i915/guc: Reset GuC ADS during sanitize drm/i915/guc: Always ask GuC to update power domain states drm/i915/guc: Define GuC firmware version for Geminilake drm/i915/huc: Define HuC firmware version for Geminilake drm/i915/guc: New GuC interrupt register for Gen11 drm/i915/guc: New GuC scratch registers for Gen11 drm/i915/huc: New HuC status register for Gen11 drm/i915/guc: Update GuC CTB response definition drm/i915/guc: Enable GuC CTB communication on Gen11 drm/i915/guc: Define GuC firmware version for Icelake drm/i915/huc: Define HuC firmware version for Icelake HAX: Turn on GuC/HuC auto mode Oscar Mateo (2): drm/i915/guc: Create vfuncs for the GuC interrupts control functions drm/i915/guc: Correctly handle GuC interrupts on Gen11 drivers/gpu/drm/i915/gt/intel_engine.h | 2 + drivers/gpu/drm/i915/gt/intel_engine_cs.c | 9 +- drivers/gpu/drm/i915/i915_irq.c | 59 +- drivers/gpu/drm/i915/i915_irq.h | 3 + drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_guc.c| 121 ++-- drivers/gpu/drm/i915/intel_guc.h| 8 +- drivers/gpu/drm/i915/intel_guc_ads.c| 167 ++-- drivers/gpu/drm/i915/intel_guc_ads.h| 1 + drivers/gpu/drm/i915/intel_guc_ct.c | 2 +- drivers/gpu/drm/i915/intel_guc_fw.c | 97 ++ drivers/gpu/drm/i915/intel_guc_fwif.h | 199 +--- drivers/gpu/drm/i915/intel_guc_reg.h| 25 +++ drivers/gpu/drm/i915/intel_guc_submission.c | 4 - drivers/gpu/drm/i915/intel_huc.c| 26 ++- drivers/gpu/drm/i915/intel_huc.h| 7 + drivers/gpu/drm/i915/intel_huc_fw.c | 24 +++ drivers/gpu/drm/i915/intel_uc.c | 51 +++-- drivers/gpu/drm/i915/intel_uc_fw.c | 20 +- 21 files changed, 530 insertions(+), 302 deletions(-) -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 07/17] drm/i915/huc: Define HuC firmware version for Geminilake
Define HuC firmware version for Geminilake. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Joonas Lahtinen Cc: Anusha Srivatsa Cc: Tony Ye Reviewed-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc_fw.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c b/drivers/gpu/drm/i915/intel_huc_fw.c index 44c559526072..8bac6a051c18 100644 --- a/drivers/gpu/drm/i915/intel_huc_fw.c +++ b/drivers/gpu/drm/i915/intel_huc_fw.c @@ -34,6 +34,10 @@ #define KBL_HUC_FW_MINOR 00 #define KBL_BLD_NUM 1810 +#define GLK_HUC_FW_MAJOR 03 +#define GLK_HUC_FW_MINOR 01 +#define GLK_BLD_NUM 2893 + #define HUC_FW_PATH(platform, major, minor, bld_num) \ "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \ __stringify(minor) "_" __stringify(bld_num) ".bin" @@ -50,6 +54,10 @@ MODULE_FIRMWARE(I915_BXT_HUC_UCODE); KBL_HUC_FW_MINOR, KBL_BLD_NUM) MODULE_FIRMWARE(I915_KBL_HUC_UCODE); +#define I915_GLK_HUC_UCODE HUC_FW_PATH(glk, GLK_HUC_FW_MAJOR, \ + GLK_HUC_FW_MINOR, GLK_BLD_NUM) +MODULE_FIRMWARE(I915_GLK_HUC_UCODE); + static void huc_fw_select(struct intel_uc_fw *huc_fw) { struct intel_huc *huc = container_of(huc_fw, struct intel_huc, fw); @@ -76,6 +84,10 @@ static void huc_fw_select(struct intel_uc_fw *huc_fw) huc_fw->path = I915_KBL_HUC_UCODE; huc_fw->major_ver_wanted = KBL_HUC_FW_MAJOR; huc_fw->minor_ver_wanted = KBL_HUC_FW_MINOR; + } else if (IS_GEMINILAKE(dev_priv)) { + huc_fw->path = I915_GLK_HUC_UCODE; + huc_fw->major_ver_wanted = GLK_HUC_FW_MAJOR; + huc_fw->minor_ver_wanted = GLK_HUC_FW_MINOR; } } -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 06/17] drm/i915/guc: Define GuC firmware version for Geminilake
Define GuC firmware version for Geminilake. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Anusha Srivatsa Reviewed-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_guc_fw.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c b/drivers/gpu/drm/i915/intel_guc_fw.c index c740bf3731de..c1e9bb4e04fd 100644 --- a/drivers/gpu/drm/i915/intel_guc_fw.c +++ b/drivers/gpu/drm/i915/intel_guc_fw.c @@ -58,6 +58,13 @@ MODULE_FIRMWARE(BXT_GUC_FIRMWARE_PATH); #define KBL_GUC_FIRMWARE_PATH __MAKE_GUC_FW_PATH(KBL) MODULE_FIRMWARE(KBL_GUC_FIRMWARE_PATH); +#define GLK_GUC_FW_PREFIX glk +#define GLK_GUC_FW_MAJOR 32 +#define GLK_GUC_FW_MINOR 0 +#define GLK_GUC_FW_PATCH 3 +#define GLK_GUC_FIRMWARE_PATH __MAKE_GUC_FW_PATH(GLK) +MODULE_FIRMWARE(GLK_GUC_FIRMWARE_PATH); + static void guc_fw_select(struct intel_uc_fw *guc_fw) { struct intel_guc *guc = container_of(guc_fw, struct intel_guc, fw); @@ -72,6 +79,10 @@ static void guc_fw_select(struct intel_uc_fw *guc_fw) guc_fw->path = i915_modparams.guc_firmware_path; guc_fw->major_ver_wanted = 0; guc_fw->minor_ver_wanted = 0; + } else if (IS_GEMINILAKE(i915)) { + guc_fw->path = GLK_GUC_FIRMWARE_PATH; + guc_fw->major_ver_wanted = GLK_GUC_FW_MAJOR; + guc_fw->minor_ver_wanted = GLK_GUC_FW_MINOR; } else if (IS_KABYLAKE(i915) || IS_COFFEELAKE(i915)) { guc_fw->path = KBL_GUC_FIRMWARE_PATH; guc_fw->major_ver_wanted = KBL_GUC_FW_MAJOR; -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/7] drm: make headers self-contained and drop drmP.h
On Mon, May 27, 2019 at 08:18:35AM +0200, Daniel Vetter wrote: > On Sun, May 26, 2019 at 07:35:28PM +0200, Sam Ravnborg wrote: > > While removing use of drmP.h from files in drm/* I > > noticed that I had to add the same include files due to > > dependencies in the header files. > > > > It is better to let the header files be self-contained and > > let the users pull in only the additional headers files required. > > So I went ahead and made the relevant header files self-contained. > > (I did not check if this made any includes redundant in some files, > > I do not have tooling in place to do so). > > > > Daniel suggested to add support for testing that they stay > > self contained. > > Jani Nikula has sent a patch to kbuild to make this part of the > > kbuild machinery. I have used it locally and as soon as it > > lands in kbuild I will start using it for drm. > > We could have duplicated the infrastructure now but that seemed > > too much code chrunch. > > > > This patchset include the actual removal of drmP.h as one big patch. > > This is build tested on alpha (always interesting), arm, arm64, x86 etc. > > > > For all files touched the following was done: > > - include files divided up in blocks in following order: > > linux/* > > video/* > > drm/* > > "" > > - within each block the include files are sorted alphabetically > > > > v2: > > - use same ordering af blocks > > - move includes down below license text > > - added patch with actual drmP.h removal > > - reworded some subjects to make them more descriptive > > - fixed a few spelling erros in changelogs (but a few may remain) > > > > Sam > > On the series: > > Acked-by: Daniel Vetter > > Did a bit of scrolling, looks all reasonable, but definitely didn't check > things in-depth. Thanks, applied and will be pushed out in a minute. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Make sure we have enough memory bandwidth on ICL
On Fri, May 24, 2019 at 06:36:14PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > ICL has so many planes that it can easily exceed the maximum > effective memory bandwidth of the system. We must therefore check > that we don't exceed that limit. > > The algorithm is very magic number heavy and lacks sufficient > explanation for now. We also have no sane way to query the > memory clock and timings, so we must rely on a combination of > raw readout from the memory controller and hardcoded assumptions. > The memory controller values obviously change as the system > jumps between the different SAGV points, so we try to stabilize > it first by disabling SAGV for the duration of the readout. > > The utilized bandwidth is tracked via a device wide atomic > private object. That is actually not robust because we can't > afford to enforce strict global ordering between the pipes. > Thus I think I'll need to change this to simply chop up the > available bandwidth between all the active pipes. Each pipe > can then do whatever it wants as long as it doesn't exceed > its budget. That scheme will also require that we assume that > any number of planes could be active at any time. > > TODO: make it robust and deal with all the open questions > > v2: Sleep longer after disabling SAGV > v3: Poll for the dclk to get raised (seen it take 250ms!) > If the system has 2133MT/s memory then we pointlessly > wait one full second :( > v4: Use the new pcode interface to get the qgv points rather > that using hardcoded numbers > v5: Move the pcode stuff into intel_bw.c (Matt) > s/intel_sagv_info/intel_qgv_info/ > Do the NV12/P010 as per spec for now (Matt) > s/IS_ICELAKE/IS_GEN11/ > v6: Ignore bandwidth limits if the pcode query fails > > Signed-off-by: Ville Syrjälä > Reviewed-by: Matt Roper > Acked-by: Clint Taylor Series pushed to dinq. Thanks for the reviews. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH] drm/i915: i9xx_read_luts() can be static
Fixes: 14dcd98a43c8 ("drm/i915: Extract i9xx_read_luts()") Signed-off-by: kbuild test robot --- intel_color.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index e8d8167..bf92365 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1462,7 +1462,7 @@ i9xx_read_lut_8(struct intel_crtc_state *crtc_state) return blob; } -void i9xx_read_luts(struct intel_crtc_state *crtc_state) +static void i9xx_read_luts(struct intel_crtc_state *crtc_state) { crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v7][PATCH 04/12] drm/i915: Extract i9xx_read_luts()
Hi Swati, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v5.2-rc2 next-20190524] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Swati-Sharma/drm-i915-adding-state-checker-for-gamma-lut-values/20190527-214948 base: git://anongit.freedesktop.org/drm-intel for-linux-next reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-7-g2b96cd8-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
On Mon, May 27, 2019 at 4:01 PM Thomas Hellstrom wrote: > > On 5/27/19 3:16 PM, Daniel Vetter wrote: > > On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote: > >> On 5/27/19 10:17 AM, Emil Velikov wrote: > >>> From: Emil Velikov > >>> > >>> There are cases (in mesa and applications) where one would open the > >>> primary node without properly authenticating the client. > >>> > >>> Sometimes we don't check if the authentication succeeds, but there's > >>> also cases we simply forget to do it. > >>> > >>> The former was a case for Mesa where it did not not check the return > >>> value of drmGetMagic() [1]. That was fixed recently although, there's > >>> the question of older drivers or other apps that exbibit this behaviour. > >>> > >>> While omitting the call results in issues as seen in [2] and [3]. > >>> > >>> In the libva case, libva itself doesn't authenticate the DRM client and > >>> the vaGetDisplayDRM documentation doesn't mention if the app should > >>> either. > >>> > >>> As of today, the official vainfo utility doesn't authenticate. > >>> > >>> To workaround issues like these, some users resort to running their apps > >>> under sudo. Which admittedly isn't always a good idea. > >>> > >>> Since any DRIVER_RENDER driver has sufficient isolation between clients, > >>> we can use that, for unauthenticated [primary node] ioctls that require > >>> DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. > >>> > >>> v2: > >>> - Rework/simplify if check (Daniel V) > >>> - Add examples to commit messages, elaborate. (Daniel V) > >>> > >>> v3: > >>> - Use single unlikely (Daniel V) > >>> > >>> v4: > >>> - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU > >>> issue is fixed with earlier patch. > >>> > >>> [1] > >>> https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 > >>> [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html > >>> [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 > >>> Testcase: igt/core_unauth_vs_render > >>> Cc: intel-gfx@lists.freedesktop.org > >>> Signed-off-by: Emil Velikov > >>> Reviewed-by: Daniel Vetter > >>> Link: > >>> https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com > >>> --- > >>>drivers/gpu/drm/drm_ioctl.c | 20 > >>>1 file changed, 16 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c > >>> index 9841c0076f02..b64b022a2b29 100644 > >>> --- a/drivers/gpu/drm/drm_ioctl.c > >>> +++ b/drivers/gpu/drm/drm_ioctl.c > >>> @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, > >>> return err; > >>>} > >>> +static inline bool > >>> +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) > >>> +{ > >>> + return drm_core_check_feature(dev, DRIVER_RENDER) && > >>> + (flags & DRM_RENDER_ALLOW); > >>> +} > >>> + > >>>/** > >>> * drm_ioctl_permit - Check ioctl permissions against caller > >>> * > >>> @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, > >>> */ > >>>int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) > >>>{ > >>> + const struct drm_device *dev = file_priv->minor->dev; > >>> + > >>> /* ROOT_ONLY is only for CAP_SYS_ADMIN */ > >>> if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) > >>> return -EACCES; > >>> - /* AUTH is only for authenticated or render client */ > >>> - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && > >>> -!file_priv->authenticated)) > >>> - return -EACCES; > >>> + /* AUTH is only for master ... */ > >>> + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) > >>> { > >>> + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. > >>> */ > >>> + if (!file_priv->authenticated && > >>> + !drm_render_driver_and_ioctl(dev, flags)) > >>> + return -EACCES; > >>> + } > >> This breaks vmwgfx primary client authentication in the surface_reference > >> ioctl, which takes different paths in case of render clients and primary > >> clients, but adding an auth check in the primary path in the vmwgfx code > >> should fix this. > > Hm yeah we need to adjust that ... otoh kinda not sure why this is gated > > on authentication status, and not on "am I master or not" status. At least > > from a very cursory read ... > > -Daniel > > The code snippet in question is: > > > if (drm_is_primary_client(file_priv) && > user_srf->master != file_priv->master) { > DRM_ERROR("Trying to reference surface outside of" >" master domain.\n"); > ret = -EACCES; > goto out_bad_resource; > } > > > In gem term's this means a client can't open a su
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: adding state checker for gamma lut values (rev10)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev10) URL : https://patchwork.freedesktop.org/series/58039/ State : success == Summary == CI Bug Log - changes from CI_DRM_6148 -> Patchwork_13107 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/ Known issues Here are the changes found in Patchwork_13107 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_tiled_pread_basic: - fi-icl-u3: [DMESG-WARN][1] ([fdo#107724]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-u3/igt@gem_tiled_pread_basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/fi-icl-u3/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][3] ([fdo#108602] / [fdo#108744]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html - {fi-icl-dsi}: [INCOMPLETE][5] ([fdo#107713] / [fdo#108569]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/fi-icl-dsi/igt@i915_selftest@live_hangcheck.html Warnings * igt@kms_flip@basic-flip-vs-modeset: - fi-icl-u3: [DMESG-FAIL][7] ([fdo#110718]) -> [DMESG-WARN][8] ([fdo#110718]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-u3/igt@kms_f...@basic-flip-vs-modeset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/fi-icl-u3/igt@kms_f...@basic-flip-vs-modeset.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#110718]: https://bugs.freedesktop.org/show_bug.cgi?id=110718 Participating hosts (52 -> 45) -- Additional (1): fi-gdg-551 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6148 -> Patchwork_13107 CI_DRM_6148: 91e4739d3a58b7a95a43788bad6cd68887934595 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5017: 2892adce93fb8eea3d764dc0f766a202d9dcef37 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13107: d106ea46c08077cd12e35f1bc511b92323da6b86 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d106ea46c080 FOR_TESTING_ONLY: Print rgb values of hw and sw blobs affb0e1188e9 drm/i915: Extract ilk_read_luts() 94bf4f217515 drm/i915: Extract ivb_read_luts() cff18dde61e5 drm/i915: Extract bdw_read_luts() 02d08e6b269c drm/i915: Extract glk_read_luts() 8d64f5ac9f48 drm/i915: Extract icl_read_luts() 5fc9737ac9e0 drm/i915: Extract i965_read_luts() bf2b1d9e58da drm/i915: Extract chv_read_luts() 383d2598835a drm/i915: Extract i9xx_read_luts() 118f9a116296 drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values 729d4500e37f drm/i915: Enable intel_color_get_config() d7ec7acfa25a drm/i915: Introduce vfunc read_luts() to create hw lut == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13107/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/icl: Fix AUX-B HW not done issue w/o AUX-A
On Mon, May 27, 2019 at 06:50:14AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/icl: Fix AUX-B HW not done issue w/o AUX-A > URL : https://patchwork.freedesktop.org/series/61123/ > State : failure Thanks for the review pushed to -dinq. > > == Summary == > > CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13095_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_13095_full absolutely need to > be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_13095_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_13095_full: > > ### Piglit changes ### > > Possible regressions > > * spec@glsl-1.30@execution@tex-miplevel-selection texture(bias) cubearray > (NEW): > - pig-snb-2600: NOTRUN -> [FAIL][1] >[1]: None Unrelated platform, there is no combo PHY on SNB. > > > New tests > - > > New tests have been introduced between CI_DRM_6142_full and > Patchwork_13095_full: > > ### New Piglit tests (1) ### > > * spec@glsl-1.30@execution@tex-miplevel-selection texture(bias) cubearray: > - Statuses : 1 fail(s) > - Exec time: [6.78] s > > > > Known issues > > > Here are the changes found in Patchwork_13095_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_create@forked: > - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([fdo#108838]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl3/igt@gem_exec_cre...@forked.html >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-skl4/igt@gem_exec_cre...@forked.html > > * igt@gem_tiled_swapping@non-threaded: > - shard-kbl: [PASS][4] -> [FAIL][5] ([fdo#108686]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-kbl3/igt@gem_tiled_swapp...@non-threaded.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-kbl4/igt@gem_tiled_swapp...@non-threaded.html > > * igt@gem_workarounds@suspend-resume-context: > - shard-apl: [PASS][6] -> [DMESG-WARN][7] ([fdo#108566]) +4 > similar issues >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl2/igt@gem_workarou...@suspend-resume-context.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-apl1/igt@gem_workarou...@suspend-resume-context.html > > * igt@i915_pm_rpm@modeset-lpsp-stress-no-wait: > - shard-iclb: [PASS][8] -> [INCOMPLETE][9] ([fdo#107713] / > [fdo#108840]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb5/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-iclb2/igt@i915_pm_...@modeset-lpsp-stress-no-wait.html > > * igt@kms_dp_dsc@basic-dsc-enable-edp: > - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#109349]) >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-iclb1/igt@kms_dp_...@basic-dsc-enable-edp.html > > * igt@kms_flip@basic-plain-flip: > - shard-kbl: [PASS][12] -> [INCOMPLETE][13] ([fdo#103665]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-kbl3/igt@kms_f...@basic-plain-flip.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-kbl4/igt@kms_f...@basic-plain-flip.html > > * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: > - shard-iclb: [PASS][14] -> [FAIL][15] ([fdo#103167]) +6 similar > issues >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html > > * igt@kms_plane_lowres@pipe-a-tiling-y: > - shard-iclb: [PASS][16] -> [FAIL][17] ([fdo#103166]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-y.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13095/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-y.html > > * igt@kms_psr2_su@frontbuffer: > - shard-iclb: [PASS][18] -> [SKIP][19] ([fdo#109642]) >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr2...@frontbuffer.html >[19]: > https://intel-gfx-ci.01.org/tree
Re: [Intel-gfx] [PATCH v4 17/22] drm/i915/guc: Correctly handle GuC interrupts on Gen11
On Thu, May 23, 2019 at 11:30:44PM +, Michal Wajdeczko wrote: > From: Oscar Mateo > > The GuC interrupts now get their own interrupt vector (instead of > sharing a register with the PM interrupts) so handle appropriately. > > v2: (Chris) > v3: rebased (Michal) > Bspec: 19820 Bspec: 19820, 19840, 19841, 20176 > > Signed-off-by: Oscar Mateo > Signed-off-by: Michal Wajdeczko > Cc: Tvrtko Ursulin > Cc: Daniele Ceraolo Spurio > Cc: Joonas Lahtinen > --- > drivers/gpu/drm/i915/i915_drv.h | 6 ++- > drivers/gpu/drm/i915/i915_irq.c | 58 +++- > drivers/gpu/drm/i915/i915_irq.h | 3 ++ > drivers/gpu/drm/i915/i915_reg.h | 1 + > drivers/gpu/drm/i915/intel_guc.c | 3 ++ > drivers/gpu/drm/i915/intel_guc_reg.h | 18 + > 6 files changed, 86 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 311e19154672..6bd7a9347071 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1570,7 +1570,11 @@ struct drm_i915_private { > u32 pm_imr; > u32 pm_ier; > u32 pm_rps_events; > - u32 pm_guc_events; > + union { > + /* RPS and GuC share a register pre-Gen11 */ > + u32 pm_guc_events; > + u32 guc_events; > + }; > u32 pipestat_irq_mask[I915_MAX_PIPES]; > > struct i915_hotplug hotplug; > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 607709a8c229..52345772f84c 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -624,6 +624,41 @@ void gen9_disable_guc_interrupts(struct drm_i915_private > *dev_priv) > gen9_reset_guc_interrupts(dev_priv); > } > > +void gen11_reset_guc_interrupts(struct drm_i915_private *i915) > +{ > + spin_lock_irq(&i915->irq_lock); > + gen11_reset_one_iir(i915, 0, GEN11_GUC); > + spin_unlock_irq(&i915->irq_lock); > +} > + > +void gen11_enable_guc_interrupts(struct drm_i915_private *dev_priv) > +{ > + spin_lock_irq(&dev_priv->irq_lock); > + if (!dev_priv->guc.interrupts.enabled) { > + u32 guc_events = dev_priv->guc_events << 16; #define the GuC enable/mask shift somewhere (also, adding a comment stating that GuC is sharing this register with SG, and we currently don't care about SG interrupts wouldn't hurt) With that Reviewed-by: Michał Winiarski -Michał > + > + WARN_ON_ONCE(gen11_reset_one_iir(dev_priv, 0, GEN11_GUC)); > + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, guc_events); > + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~guc_events); > + dev_priv->guc.interrupts.enabled = true; > + } > + spin_unlock_irq(&dev_priv->irq_lock); > +} > + > +void gen11_disable_guc_interrupts(struct drm_i915_private *dev_priv) > +{ > + spin_lock_irq(&dev_priv->irq_lock); > + dev_priv->guc.interrupts.enabled = false; > + > + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~0); > + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0); > + > + spin_unlock_irq(&dev_priv->irq_lock); > + synchronize_irq(dev_priv->drm.irq); > + > + gen11_reset_guc_interrupts(dev_priv); > +} > + > /** > * bdw_update_port_irq - update DE port interrupt > * @dev_priv: driver private > @@ -1893,6 +1928,12 @@ static void gen9_guc_irq_handler(struct > drm_i915_private *dev_priv, u32 gt_iir) > intel_guc_to_host_event_handler(&dev_priv->guc); > } > > +static void gen11_guc_irq_handler(struct drm_i915_private *i915, u16 iir) > +{ > + if (iir & GEN11_GUC_INTR_GUC2HOST) > + intel_guc_to_host_event_handler(&i915->guc); > +} > + > static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv) > { > enum pipe pipe; > @@ -3015,6 +3056,9 @@ static void > gen11_other_irq_handler(struct drm_i915_private * const i915, > const u8 instance, const u16 iir) > { > + if (instance == OTHER_GUC_INSTANCE) > + return gen11_guc_irq_handler(i915, iir); > + > if (instance == OTHER_GTPM_INSTANCE) > return gen11_rps_irq_handler(i915, iir); > > @@ -3545,6 +3589,8 @@ static void gen11_gt_irq_reset(struct drm_i915_private > *dev_priv) > > I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0); > I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK, ~0); > + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0); > + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~0); > } > > static void gen11_irq_reset(struct drm_device *dev) > @@ -4200,6 +4246,10 @@ static void gen11_gt_irq_postinstall(struct > drm_i915_private *dev_priv) > dev_priv->pm_imr = ~dev_priv->pm_ier; > I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0); > I915_WRITE(GEN11_GPM_WGBOXPERF_INTR_MASK, ~0); > + > + /* Same thing for GuC interrupts */ > + I915_WRITE(GEN11_GUC_SG_INTR_ENABLE, 0); > + I915_WRITE(GEN11_GUC_SG_INTR_MASK, ~0); > } > > static void icp_irq_postinstall(struct drm_de
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: adding state checker for gamma lut values (rev10)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev10) URL : https://patchwork.freedesktop.org/series/58039/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Introduce vfunc read_luts() to create hw lut Okay! Commit: drm/i915: Enable intel_color_get_config() Okay! Commit: drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values Okay! Commit: drm/i915: Extract i9xx_read_luts() +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1425:15: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_color.c:1465:6: warning: symbol 'i9xx_read_luts' was not declared. Should it be static? Commit: drm/i915: Extract chv_read_luts() Okay! Commit: drm/i915: Extract i965_read_luts() Okay! Commit: drm/i915: Extract icl_read_luts() Okay! Commit: drm/i915: Extract glk_read_luts() Okay! Commit: drm/i915: Extract bdw_read_luts() Okay! Commit: drm/i915: Extract ivb_read_luts() Okay! Commit: drm/i915: Extract ilk_read_luts() Okay! Commit: FOR_TESTING_ONLY: Print rgb values of hw and sw blobs Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
On 5/27/19 3:16 PM, Daniel Vetter wrote: On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote: On 5/27/19 10:17 AM, Emil Velikov wrote: From: Emil Velikov There are cases (in mesa and applications) where one would open the primary node without properly authenticating the client. Sometimes we don't check if the authentication succeeds, but there's also cases we simply forget to do it. The former was a case for Mesa where it did not not check the return value of drmGetMagic() [1]. That was fixed recently although, there's the question of older drivers or other apps that exbibit this behaviour. While omitting the call results in issues as seen in [2] and [3]. In the libva case, libva itself doesn't authenticate the DRM client and the vaGetDisplayDRM documentation doesn't mention if the app should either. As of today, the official vainfo utility doesn't authenticate. To workaround issues like these, some users resort to running their apps under sudo. Which admittedly isn't always a good idea. Since any DRIVER_RENDER driver has sufficient isolation between clients, we can use that, for unauthenticated [primary node] ioctls that require DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. v2: - Rework/simplify if check (Daniel V) - Add examples to commit messages, elaborate. (Daniel V) v3: - Use single unlikely (Daniel V) v4: - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU issue is fixed with earlier patch. [1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 Testcase: igt/core_unauth_vs_render Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com --- drivers/gpu/drm/drm_ioctl.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 9841c0076f02..b64b022a2b29 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, return err; } +static inline bool +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) +{ + return drm_core_check_feature(dev, DRIVER_RENDER) && + (flags & DRM_RENDER_ALLOW); +} + /** * drm_ioctl_permit - Check ioctl permissions against caller * @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, */ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) { + const struct drm_device *dev = file_priv->minor->dev; + /* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) return -EACCES; - /* AUTH is only for authenticated or render client */ - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && -!file_priv->authenticated)) - return -EACCES; + /* AUTH is only for master ... */ + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) { + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ + if (!file_priv->authenticated && + !drm_render_driver_and_ioctl(dev, flags)) + return -EACCES; + } This breaks vmwgfx primary client authentication in the surface_reference ioctl, which takes different paths in case of render clients and primary clients, but adding an auth check in the primary path in the vmwgfx code should fix this. Hm yeah we need to adjust that ... otoh kinda not sure why this is gated on authentication status, and not on "am I master or not" status. At least from a very cursory read ... -Daniel The code snippet in question is: if (drm_is_primary_client(file_priv) && user_srf->master != file_priv->master) { DRM_ERROR("Trying to reference surface outside of" " master domain.\n"); ret = -EACCES; goto out_bad_resource; } In gem term's this means a client can't open a surface that hasn't been flinked by a client in the same master realm: You can't read from resources belonging to another X server's clients /Thomas /Thomas /* MASTER is only for master or control clients */ if (unlikely((flags & DRM_MASTER) && ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/i
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: adding state checker for gamma lut values (rev10)
== Series Details == Series: drm/i915: adding state checker for gamma lut values (rev10) URL : https://patchwork.freedesktop.org/series/58039/ State : warning == Summary == $ dim checkpatch origin/drm-tip d7ec7acfa25a drm/i915: Introduce vfunc read_luts() to create hw lut 729d4500e37f drm/i915: Enable intel_color_get_config() 118f9a116296 drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: -Corrected smatch warn "variable dereferenced before check" [Dan Carpenter] -:37: ERROR:SWITCH_CASE_INDENT_LEVEL: switch and case should be at the same indent #37: FILE: drivers/gpu/drm/i915/intel_color.c:1259: + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: [...] + case GAMMA_MODE_MODE_10BIT: [...] + default: -:64: ERROR:SWITCH_CASE_INDENT_LEVEL: switch and case should be at the same indent #64: FILE: drivers/gpu/drm/i915/intel_color.c:1286: + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: [...] + case GAMMA_MODE_MODE_10BIT: [...] + default: -:83: ERROR:SWITCH_CASE_INDENT_LEVEL: switch and case should be at the same indent #83: FILE: drivers/gpu/drm/i915/intel_color.c:1305: + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: [...] + case GAMMA_MODE_MODE_SPLIT: + case GAMMA_MODE_MODE_10BIT: [...] + default: -:103: ERROR:SWITCH_CASE_INDENT_LEVEL: switch and case should be at the same indent #103: FILE: drivers/gpu/drm/i915/intel_color.c:1325: + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: [...] + case GAMMA_MODE_MODE_10BIT: [...] + default: -:119: ERROR:SWITCH_CASE_INDENT_LEVEL: switch and case should be at the same indent #119: FILE: drivers/gpu/drm/i915/intel_color.c:1341: + switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) { + case GAMMA_MODE_MODE_8BIT: [...] + case GAMMA_MODE_MODE_10BIT: [...] + default: -:155: ERROR:CODE_INDENT: code indent should use tabs where possible #155: FILE: drivers/gpu/drm/i915/intel_color.c:1377: +^I struct drm_color_lut *hw_lut, u32 err)$ -:155: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #155: FILE: drivers/gpu/drm/i915/intel_color.c:1377: +static inline bool err_check(struct drm_color_lut *sw_lut, +struct drm_color_lut *hw_lut, u32 err) -:157: WARNING:TABSTOP: Statements should start on a tabstop #157: FILE: drivers/gpu/drm/i915/intel_color.c:1379: +return ((abs((long)hw_lut->red - sw_lut->red)) <= err) && -:158: ERROR:CODE_INDENT: code indent should use tabs where possible #158: FILE: drivers/gpu/drm/i915/intel_color.c:1380: +^I((abs((long)hw_lut->blue - sw_lut->blue)) <= err) &&$ -:159: ERROR:CODE_INDENT: code indent should use tabs where possible #159: FILE: drivers/gpu/drm/i915/intel_color.c:1381: +^I((abs((long)hw_lut->green - sw_lut->green)) <= err);$ -:190: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (8, 17) #190: FILE: drivers/gpu/drm/i915/intel_color.c:1412: + for (i = 0; i < sw_lut_size; i++) { +if (!err_check(&hw_lut[i], &sw_lut[i], err)) -:191: WARNING:TABSTOP: Statements should start on a tabstop #191: FILE: drivers/gpu/drm/i915/intel_color.c:1413: +if (!err_check(&hw_lut[i], &sw_lut[i], err)) -:237: WARNING:LONG_LINE: line over 100 characters #237: FILE: drivers/gpu/drm/i915/intel_display.c:11895: + pipe_config->cgm_mode, pipe_config->gamma_mode, pipe_config->gamma_enable, -:237: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #237: FILE: drivers/gpu/drm/i915/intel_display.c:11895: + DRM_DEBUG_KMS("cgm_mode:%d gamma_mode:%d gamma_enable:%d csc_enable:%d\n", + pipe_config->cgm_mode, pipe_config->gamma_mode, pipe_config->gamma_enable, -:241: WARNING:LONG_LINE: line over 100 characters #241: FILE: drivers/gpu/drm/i915/intel_display.c:11899: + pipe_config->csc_mode, pipe_config->gamma_mode, pipe_config->gamma_enable, -:241: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #241: FILE: drivers/gpu/drm/i915/intel_display.c:11899: + DRM_DEBUG_KMS("csc_mode:%d gamma_mode:%d gamma_enable:%d csc_enable:%d\n", + pipe_config->csc_mode, pipe_config->gamma_mode, pipe_config->gamma_enable, -:259: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible side-effects? #259: FILE: drivers/gpu/drm/i915/intel_display.c:12431: +#define PIPE_CONF_CHECK_COLOR_LUT(name, bit_precision) do { \ + if (!intel_color_lut_equal(current_config->nam
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6) URL : https://patchwork.freedesktop.org/series/61047/ State : success == Summary == CI Bug Log - changes from CI_DRM_6148 -> Patchwork_13106 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/ Known issues Here are the changes found in Patchwork_13106 that come from known issues: ### IGT changes ### Issues hit * igt@core_auth@basic-auth: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-u3/igt@core_a...@basic-auth.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/fi-icl-u3/igt@core_a...@basic-auth.html * igt@gem_exec_fence@basic-busy-default: - fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-y/igt@gem_exec_fe...@basic-busy-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/fi-icl-y/igt@gem_exec_fe...@basic-busy-default.html * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - fi-pnv-d510:[PASS][5] -> [FAIL][6] ([fdo#106081]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-pnv-d510/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/fi-pnv-d510/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html Possible fixes * igt@gem_tiled_pread_basic: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-u3/igt@gem_tiled_pread_basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/fi-icl-u3/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live_hangcheck: - fi-skl-iommu: [INCOMPLETE][9] ([fdo#108602] / [fdo#108744]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/fi-skl-iommu/igt@i915_selftest@live_hangcheck.html Warnings * igt@kms_flip@basic-flip-vs-modeset: - fi-icl-u3: [DMESG-FAIL][11] ([fdo#110718]) -> [DMESG-WARN][12] ([fdo#110718]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6148/fi-icl-u3/igt@kms_f...@basic-flip-vs-modeset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/fi-icl-u3/igt@kms_f...@basic-flip-vs-modeset.html {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). [fdo#106081]: https://bugs.freedesktop.org/show_bug.cgi?id=106081 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602 [fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744 [fdo#110718]: https://bugs.freedesktop.org/show_bug.cgi?id=110718 Participating hosts (52 -> 45) -- Additional (1): fi-gdg-551 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_6148 -> Patchwork_13106 CI_DRM_6148: 91e4739d3a58b7a95a43788bad6cd68887934595 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5017: 2892adce93fb8eea3d764dc0f766a202d9dcef37 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13106: fbf134649c9df2620e89d6f658e317ccd7528c9b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fbf134649c9d drm/i915: Keep user GGTT alive for a minimum of 250ms == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13106/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 02/12] drm/i915: Enable intel_color_get_config()
In this patch, intel_color_get_config() is enabled and support for read_luts() will be added platform by platform incrementally in the follow-up patches. v4: -Renamed intel_get_color_config to intel_color_get_config [Jani] -Added the user early on such that support for get_color_config() can be added platform by platform incrementally [Jani] v5: -Incorrect place for calling intel_color_get_config() in haswell_get_pipe_config() [Ville] v6: -Renamed intel_color_read_luts() to intel_color_get_config() [Jani and Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/intel_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 05177f3..3e01028 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8351,6 +8351,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc, pipe_config->cgm_mode = I915_READ(CGM_PIPE_MODE(crtc->pipe)); i9xx_get_pipe_color_config(pipe_config); + intel_color_get_config(pipe_config); if (INTEL_GEN(dev_priv) < 4) pipe_config->double_wide = tmp & PIPECONF_DOUBLE_WIDE; @@ -9426,6 +9427,7 @@ static bool ironlake_get_pipe_config(struct intel_crtc *crtc, pipe_config->csc_mode = I915_READ(PIPE_CSC_MODE(crtc->pipe)); i9xx_get_pipe_color_config(pipe_config); + intel_color_get_config(pipe_config); if (I915_READ(PCH_TRANSCONF(crtc->pipe)) & TRANS_ENABLE) { struct intel_shared_dpll *pll; @@ -9874,6 +9876,8 @@ static bool haswell_get_pipe_config(struct intel_crtc *crtc, i9xx_get_pipe_color_config(pipe_config); } + intel_color_get_config(pipe_config); + power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe); WARN_ON(power_domain_mask & BIT_ULL(power_domain)); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 05/12] drm/i915: Extract chv_read_luts()
In this patch, hw gamma and degamma blob is created for cherryview. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed function cherryview_get_color_config() to chv_read_luts() -Renamed cherryview_get_gamma_config() to chv_read_cgm_gamma_lut() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/i915_reg.h| 3 +++ drivers/gpu/drm/i915/intel_color.c | 40 ++ 2 files changed, 43 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d8475f2..b58c66d 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -10160,6 +10160,9 @@ enum skl_power_gate { #define CGM_PIPE_MODE_GAMMA (1 << 2) #define CGM_PIPE_MODE_CSC(1 << 1) #define CGM_PIPE_MODE_DEGAMMA(1 << 0) +#define CGM_PIPE_GAMMA_RED_MASK REG_GENMASK(9, 0) +#define CGM_PIPE_GAMMA_GREEN_MASK REG_GENMASK(25, 16) +#define CGM_PIPE_GAMMA_BLUE_MASK REG_GENMASK(9, 0) #define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900) #define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index e8d8167..9d759e1 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1467,6 +1467,45 @@ void i9xx_read_luts(struct intel_crtc_state *crtc_state) crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); } +static struct drm_property_blob * +chv_read_cgm_gamma_lut(struct intel_crtc_state *crtc_state) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + u32 i, val, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size; + enum pipe pipe = crtc->pipe; + struct drm_property_blob *blob; + struct drm_color_lut *blob_data; + + blob = drm_property_create_blob(&dev_priv->drm, + sizeof(struct drm_color_lut) * lut_size, + NULL); + if (IS_ERR(blob)) + return NULL; + + blob_data = blob->data; + + for (i = 0; i < lut_size; i++) { + val = I915_READ(CGM_PIPE_GAMMA(pipe, i, 0)); + blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_GREEN_MASK, val), 10); + blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_BLUE_MASK, val), 10); + + val = I915_READ(CGM_PIPE_GAMMA(pipe, i, 1)); + blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_GAMMA_RED_MASK, val), 10); + } + + return blob; +} + +static void chv_read_luts(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else + crtc_state->base.gamma_lut = chv_read_cgm_gamma_lut(crtc_state); + +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1479,6 +1518,7 @@ void intel_color_init(struct intel_crtc *crtc) dev_priv->display.color_check = chv_color_check; dev_priv->display.color_commit = i9xx_color_commit; dev_priv->display.load_luts = chv_load_luts; + dev_priv->display.read_luts = chv_read_luts; } else if (INTEL_GEN(dev_priv) >= 4) { dev_priv->display.color_check = i9xx_color_check; dev_priv->display.color_commit = i9xx_color_commit; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 10/12] drm/i915: Extract ivb_read_luts()
In this patch, gamma and degamma hw blobs are created for IVB. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed ivb_get_color_config() to ivb_read_luts() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/intel_color.c | 50 -- 1 file changed, 48 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index ce6dc5e..4c00215 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1607,6 +1607,51 @@ static void bdw_read_luts(struct intel_crtc_state *crtc_state) crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); } +static struct drm_property_blob * +ivb_read_lut_10(struct intel_crtc_state *crtc_state, + u32 prec_index) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + int hw_lut_size = ivb_lut_10_size(prec_index); + enum pipe pipe = crtc->pipe; + struct drm_property_blob *blob; + struct drm_color_lut *blob_data; + u32 i, val; + + blob = drm_property_create_blob(&dev_priv->drm, + sizeof(struct drm_color_lut) * hw_lut_size, + NULL); + if (IS_ERR(blob)) + return NULL; + + blob_data = blob->data; + + for (i = 0; i < hw_lut_size; i++) { + I915_WRITE(PREC_PAL_INDEX(pipe), prec_index++); + val = I915_READ(PREC_PAL_DATA(pipe)); + + blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_RED_MASK, val), 10); + blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_GREEN_MASK, val), 10); + blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_BLUE_MASK, val), 10); + } + + I915_WRITE(PREC_PAL_INDEX(pipe), 0); + + return blob; +} + +static void ivb_read_luts(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) + crtc_state->base.gamma_lut = ivb_read_lut_10(crtc_state, PAL_PREC_SPLIT_MODE | PAL_PREC_INDEX_VALUE(512)); + else + crtc_state->base.gamma_lut = ivb_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); + +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1657,9 +1702,10 @@ void intel_color_init(struct intel_crtc *crtc) } else if (INTEL_GEN(dev_priv) >= 8) { dev_priv->display.load_luts = bdw_load_luts; dev_priv->display.read_luts = bdw_read_luts; - } - else if (INTEL_GEN(dev_priv) >= 7) + } else if (INTEL_GEN(dev_priv) >= 7) { dev_priv->display.load_luts = ivb_load_luts; + dev_priv->display.read_luts = ivb_read_luts; + } else dev_priv->display.load_luts = ilk_load_luts; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 00/12] drm/i915: adding state checker for gamma lut values
In this patch series, added state checker to validate gamma and will be extended to validate degamma lut values aswell. This reads hardware state, and compares the originally requested state to the state read from hardware. v1: -Implementation done for legacy platforms (removed all the placeholders) (Jani) v2: -Restructured code and created platform specific patch series for gamma validation v3: -Rebase v4: -Minor changes-function name changes mainly v5: -Added degamma validation (Ville) v6: -Removed degamma changes, debugging was becoming difficult -Added function to assign bit_precision for gamma/degamma lut values /platform -Added debug info into intel_dump_pipe_config() (Jani) v7: -Added platform specific functions to compute gamma bit precision on the basis of GAMMA_MODE (Ville) Swati Sharma (12): drm/i915: Introduce vfunc read_luts() to create hw lut drm/i915: Enable intel_color_get_config() drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values drm/i915: Extract i9xx_read_luts() drm/i915: Extract chv_read_luts() drm/i915: Extract i965_read_luts() drm/i915: Extract icl_read_luts() drm/i915: Extract glk_read_luts() drm/i915: Extract bdw_read_luts() drm/i915: Extract ivb_read_luts() drm/i915: Extract ilk_read_luts() FOR_TESTING_ONLY: Print rgb values of hw and sw blobs drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 15 ++ drivers/gpu/drm/i915/intel_color.c | 467 ++- drivers/gpu/drm/i915/intel_color.h | 8 + drivers/gpu/drm/i915/intel_display.c | 29 +++ 5 files changed, 515 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 06/12] drm/i915: Extract i965_read_luts()
In this patch, hw gamma blob is created for i965. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed i965_get_color_config() to i965_read_lut() [Ville] -Renamed i965_get_gamma_config_10p6() to i965_read_gamma_lut_10p6() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/i915_reg.h| 3 +++ drivers/gpu/drm/i915/intel_color.c | 39 ++ 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b58c66d..7988fa5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3584,6 +3584,9 @@ enum i915_power_well_id { #define _PALETTE_A 0xa000 #define _PALETTE_B 0xa800 #define _CHV_PALETTE_C 0xc000 +#define PALETTE_RED_MASKREG_GENMASK(23, 16) +#define PALETTE_GREEN_MASK REG_GENMASK(15, 8) +#define PALETTE_BLUE_MASK REG_GENMASK(7, 0) #define PALETTE(pipe, i) _MMIO(DISPLAY_MMIO_BASE(dev_priv) + \ _PICK((pipe), _PALETTE_A, \ _PALETTE_B, _CHV_PALETTE_C) + \ diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 9d759e1..0b91e22 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1506,6 +1506,44 @@ static void chv_read_luts(struct intel_crtc_state *crtc_state) } +static struct drm_property_blob * +i965_read_gamma_lut_10p6(struct intel_crtc_state *crtc_state) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + u32 i, val1, val2, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size; + enum pipe pipe = crtc->pipe; + struct drm_property_blob *blob; + struct drm_color_lut *blob_data; + + blob = drm_property_create_blob(&dev_priv->drm, + sizeof(struct drm_color_lut) * lut_size, + NULL); + if (IS_ERR(blob)) + return NULL; + + blob_data = blob->data; + + for (i = 0; i < lut_size - 1; i++) { + val1 = I915_READ(PALETTE(pipe, 2 * i + 0)); + val2 = I915_READ(PALETTE(pipe, 2 * i + 1)); + + blob_data[i].red = REG_FIELD_GET(PALETTE_RED_MASK, val1) << 8 | REG_FIELD_GET(PALETTE_RED_MASK, val2); + blob_data[i].green = REG_FIELD_GET(PALETTE_GREEN_MASK, val1) << 8 | REG_FIELD_GET(PALETTE_GREEN_MASK, val2); + blob_data[i].blue = REG_FIELD_GET(PALETTE_BLUE_MASK, val1) << 8 | REG_FIELD_GET(PALETTE_BLUE_MASK, val2) ; + } + + return blob; +} + +static void i965_read_luts(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else + crtc_state->base.gamma_lut = i965_read_gamma_lut_10p6(crtc_state); +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1523,6 +1561,7 @@ void intel_color_init(struct intel_crtc *crtc) dev_priv->display.color_check = i9xx_color_check; dev_priv->display.color_commit = i9xx_color_commit; dev_priv->display.load_luts = i965_load_luts; + dev_priv->display.read_luts = i965_read_luts; } else { dev_priv->display.color_check = i9xx_color_check; dev_priv->display.color_commit = i9xx_color_commit; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 12/12] FOR_TESTING_ONLY: Print rgb values of hw and sw blobs
Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/intel_color.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 061bdbf..31e5a44 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1376,6 +1376,8 @@ int intel_color_get_gamma_bit_precision(struct intel_crtc_state *crtc_state) static inline bool err_check(struct drm_color_lut *sw_lut, struct drm_color_lut *hw_lut, u32 err) { + DRM_DEBUG_KMS("hw_lut->red=0x%x sw_lut->red=0x%x hw_lut->blue=0x%x sw_lut->blue=0x%x hw_lut->green=0x%x sw_lut->green=0x%x", hw_lut->red, sw_lut->red, hw_lut->blue, sw_lut->blue, hw_lut->green, sw_lut->green); + return ((abs((long)hw_lut->red - sw_lut->red)) <= err) && ((abs((long)hw_lut->blue - sw_lut->blue)) <= err) && ((abs((long)hw_lut->green - sw_lut->green)) <= err); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 08/12] drm/i915: Extract glk_read_luts()
In this patch, gamma and degamma hw blobs are created for GLK. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed glk_get_color_config() to glk_read_luts() [Ville] -Added degamma validation [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/intel_color.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index fa8e895..4e58cd1 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1589,6 +1589,14 @@ static void icl_read_luts(struct intel_crtc_state *crtc_state) crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); } +static void glk_read_luts(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else + crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1633,9 +1641,10 @@ void intel_color_init(struct intel_crtc *crtc) if (INTEL_GEN(dev_priv) >= 11) { dev_priv->display.load_luts = icl_load_luts; dev_priv->display.read_luts = icl_read_luts; - } - else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) + } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) { dev_priv->display.load_luts = glk_load_luts; + dev_priv->display.read_luts = glk_read_luts; + } else if (INTEL_GEN(dev_priv) >= 8) dev_priv->display.load_luts = bdw_load_luts; else if (INTEL_GEN(dev_priv) >= 7) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 09/12] drm/i915: Extract bdw_read_luts()
In this patch, gamma and degamma hw blobs are created for BDW. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed bdw_get_color_config() to bdw_read_luts() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/intel_color.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 4e58cd1..ce6dc5e 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1597,6 +1597,16 @@ static void glk_read_luts(struct intel_crtc_state *crtc_state) crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); } +static void bdw_read_luts(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else if (crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT) + crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(512)); + else + crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1644,9 +1654,10 @@ void intel_color_init(struct intel_crtc *crtc) } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) { dev_priv->display.load_luts = glk_load_luts; dev_priv->display.read_luts = glk_read_luts; - } - else if (INTEL_GEN(dev_priv) >= 8) + } else if (INTEL_GEN(dev_priv) >= 8) { dev_priv->display.load_luts = bdw_load_luts; + dev_priv->display.read_luts = bdw_read_luts; + } else if (INTEL_GEN(dev_priv) >= 7) dev_priv->display.load_luts = ivb_load_luts; else -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 11/12] drm/i915: Extract ilk_read_luts()
In this patch, hw gamma blob is created for ILK. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed ilk_get_color_config() to ilk_read_luts() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/i915_reg.h| 3 +++ drivers/gpu/drm/i915/intel_color.c | 42 -- 2 files changed, 43 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 249296b..d5ff323 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -7189,6 +7189,9 @@ enum { /* ilk/snb precision palette */ #define _PREC_PALETTE_A 0x4b000 #define _PREC_PALETTE_B 0x4c000 +#define PREC_PALETTE_RED_MASK REG_GENMASK(29, 20) +#define PREC_PALETTE_GREEN_MASK REG_GENMASK(19, 10) +#define PREC_PALETTE_BLUE_MASK REG_GENMASK(9, 0) #define PREC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _PREC_PALETTE_A, _PREC_PALETTE_B) + (i) * 4) #define _PREC_PIPEAGCMAX 0x4d000 diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 4c00215..061bdbf 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1652,6 +1652,43 @@ static void ivb_read_luts(struct intel_crtc_state *crtc_state) } +static struct drm_property_blob * +ilk_read_gamma_lut(struct intel_crtc_state *crtc_state) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + u32 i, val, lut_size = INTEL_INFO(dev_priv)->color.gamma_lut_size; + enum pipe pipe = crtc->pipe; + struct drm_property_blob *blob; + struct drm_color_lut *blob_data; + + blob = drm_property_create_blob(&dev_priv->drm, + sizeof(struct drm_color_lut) * lut_size, + NULL); + if (IS_ERR(blob)) + return NULL; + + blob_data = blob->data; + + for (i = 0; i < lut_size - 1; i++) { + val = I915_READ(PREC_PALETTE(pipe, i)); + + blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_RED_MASK, val), 10); + blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_GREEN_MASK, val), 10); + blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(PREC_PALETTE_BLUE_MASK, val), 10); + } + + return blob; +} + +static void ilk_read_luts(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->gamma_mode == GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else + crtc_state->base.gamma_lut = ilk_read_gamma_lut(crtc_state); +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1705,9 +1742,10 @@ void intel_color_init(struct intel_crtc *crtc) } else if (INTEL_GEN(dev_priv) >= 7) { dev_priv->display.load_luts = ivb_load_luts; dev_priv->display.read_luts = ivb_read_luts; - } - else + } else { dev_priv->display.load_luts = ilk_load_luts; + dev_priv->display.read_luts = ilk_read_luts; + } } drm_crtc_enable_color_mgmt(&crtc->base, -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 07/12] drm/i915: Extract icl_read_luts()
In this patch, gamma hw blobs are created for ICL. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally within the function [Ville] -Renamed icl_get_color_config() to icl_read_luts() [Ville] -Renamed bdw_get_gamma_config() to bdw_read_lut_10() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/i915_reg.h| 3 +++ drivers/gpu/drm/i915/intel_color.c | 49 +- 2 files changed, 51 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 7988fa5..249296b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -10124,6 +10124,9 @@ enum skl_power_gate { #define _PAL_PREC_DATA_A 0x4A404 #define _PAL_PREC_DATA_B 0x4AC04 #define _PAL_PREC_DATA_C 0x4B404 +#define PREC_PAL_DATA_RED_MASK REG_GENMASK(29, 20) +#define PREC_PAL_DATA_GREEN_MASK REG_GENMASK(19, 10) +#define PREC_PAL_DATA_BLUE_MASK REG_GENMASK(9, 0) #define _PAL_PREC_GC_MAX_A 0x4A410 #define _PAL_PREC_GC_MAX_B 0x4AC10 #define _PAL_PREC_GC_MAX_C 0x4B410 diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 0b91e22..fa8e895 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1544,6 +1544,51 @@ static void i965_read_luts(struct intel_crtc_state *crtc_state) crtc_state->base.gamma_lut = i965_read_gamma_lut_10p6(crtc_state); } +static struct drm_property_blob * +bdw_read_lut_10(struct intel_crtc_state *crtc_state, + u32 prec_index) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + int hw_lut_size = ivb_lut_10_size(prec_index); + enum pipe pipe = crtc->pipe; + struct drm_property_blob *blob; + struct drm_color_lut *blob_data; + u32 i, val; + + I915_WRITE(PREC_PAL_INDEX(pipe), prec_index | + PAL_PREC_AUTO_INCREMENT); + + blob = drm_property_create_blob(&dev_priv->drm, + sizeof(struct drm_color_lut) * hw_lut_size, + NULL); + if (IS_ERR(blob)) + return NULL; + + blob_data = blob->data; + + for (i = 0; i < hw_lut_size; i++) { + val = I915_READ(PREC_PAL_DATA(pipe)); + + blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_RED_MASK, val), 10); + blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_GREEN_MASK, val), 10); + blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(PREC_PAL_DATA_BLUE_MASK, val), 10); + } + + I915_WRITE(PREC_PAL_INDEX(pipe), 0); + + return blob; +} + +static void icl_read_luts(struct intel_crtc_state *crtc_state) +{ + if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) == + GAMMA_MODE_MODE_8BIT) + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); + else + crtc_state->base.gamma_lut = bdw_read_lut_10(crtc_state, PAL_PREC_INDEX_VALUE(0)); +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1585,8 +1630,10 @@ void intel_color_init(struct intel_crtc *crtc) else dev_priv->display.color_commit = ilk_color_commit; - if (INTEL_GEN(dev_priv) >= 11) + if (INTEL_GEN(dev_priv) >= 11) { dev_priv->display.load_luts = icl_load_luts; + dev_priv->display.read_luts = icl_read_luts; + } else if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) dev_priv->display.load_luts = glk_load_luts; else if (INTEL_GEN(dev_priv) >= 8) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 04/12] drm/i915: Extract i9xx_read_luts()
In this patch, hw gamma blob is created for the legacy gamma. Also, function intel_color_lut_pack is added to convert hw value with given bit_precision to lut property val. v4: -No need to initialize *blob [Jani] -Removed right shifts [Jani] -Dropped dev local var [Jani] v5: -Returned blob instead of assigning it internally withing the function [Ville] -Renamed function i9xx_get_color_config() to i9xx_read_luts() -Renamed i9xx_get_config_internal() to i9xx_read_lut_8() [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/i915_reg.h| 3 +++ drivers/gpu/drm/i915/intel_color.c | 51 ++ 2 files changed, 54 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e97c47f..d8475f2 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -7178,6 +7178,9 @@ enum { /* legacy palette */ #define _LGC_PALETTE_A 0x4a000 #define _LGC_PALETTE_B 0x4a800 +#define LGC_PALETTE_RED_MASK REG_GENMASK(23, 16) +#define LGC_PALETTE_GREEN_MASK REG_GENMASK(15, 8) +#define LGC_PALETTE_BLUE_MASKREG_GENMASK(7, 0) #define LGC_PALETTE(pipe, i) _MMIO(_PIPE(pipe, _LGC_PALETTE_A, _LGC_PALETTE_B) + (i) * 4) /* ilk/snb precision palette */ diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index e566af5..e8d8167 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1417,6 +1417,56 @@ bool intel_color_lut_equal(struct drm_property_blob *blob1, return true; } +/* convert hw value with given bit_precision to lut property val */ +static u32 intel_color_lut_pack(u32 val, u32 bit_precision) +{ + u32 max = 0x >> (16 - bit_precision); + + val = clamp_val(val, 0, max); + + if (bit_precision < 16) + val <<= 16 - bit_precision; + + return val; +} + +static struct drm_property_blob * +i9xx_read_lut_8(struct intel_crtc_state *crtc_state) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum pipe pipe = crtc->pipe; + struct drm_property_blob *blob; + struct drm_color_lut *blob_data; + u32 i, val; + + blob = drm_property_create_blob(&dev_priv->drm, + sizeof(struct drm_color_lut) * 256, + NULL); + if (IS_ERR(blob)) + return NULL; + + blob_data = blob->data; + + for (i = 0; i < 256; i++) { + if (HAS_GMCH(dev_priv)) + val = I915_READ(PALETTE(pipe, i)); + else + val = I915_READ(LGC_PALETTE(pipe, i)); + + blob_data[i].red = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_RED_MASK, val), 8); + blob_data[i].green = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_GREEN_MASK, val), 8); + blob_data[i].blue = intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, val), 8); + } + + return blob; +} + +void i9xx_read_luts(struct intel_crtc_state *crtc_state) +{ + crtc_state->base.gamma_lut = i9xx_read_lut_8(crtc_state); +} + void intel_color_init(struct intel_crtc *crtc) { struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); @@ -1437,6 +1487,7 @@ void intel_color_init(struct intel_crtc *crtc) dev_priv->display.color_check = i9xx_color_check; dev_priv->display.color_commit = i9xx_color_commit; dev_priv->display.load_luts = i9xx_load_luts; + dev_priv->display.read_luts = i9xx_read_luts; } } else { if (INTEL_GEN(dev_priv) >= 11) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [v7][PATCH 03/12] drm/i915: Add intel_color_lut_equal() to compare hw and sw gamma/degamma lut values
v3: -Rebase v4: -Renamed intel_compare_color_lut() to intel_color_lut_equal() [Jani] -Added the default label above the correct label [Jani] -Corrected smatch warn "variable dereferenced before check" [Dan Carpenter] v5: -Added condition (!blob1 && !blob2) return true [Jani] -Called PIPE_CONF_CHECK_COLOR_LUT inside if (!adjust) [Jani] -Added #undef PIPE_CONF_CHECK_COLOR_LUT [Jani] v6: -Added func intel_color_get_bit_precision() to get bit precision for gamma and degamma lut readout depending upon platform and corresponding to load_luts() [Ankit] -Added debug log for color para in intel_dump_pipe_config [Jani] -Made patch11 as patch3 [Jani] v7: -Renamed func intel_color_get_bit_precision() to intel_color_get_gamma_bit_precision() -Added separate function/platform for gamma bit precision [Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/intel_color.c | 166 +++ drivers/gpu/drm/i915/intel_color.h | 7 ++ drivers/gpu/drm/i915/intel_display.c | 25 ++ 3 files changed, 198 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 50b98ee..e566af5 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -1251,6 +1251,172 @@ static int icl_color_check(struct intel_crtc_state *crtc_state) return 0; } +static int i9xx_gamma_precision(struct intel_crtc_state *crtc_state) +{ + if (!crtc_state->gamma_enable) + return 0; + + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: + return 8; + case GAMMA_MODE_MODE_10BIT: + return 16; + default: + MISSING_CASE(crtc_state->gamma_mode); + return 0; + } +} + +static int chv_gamma_precision(struct intel_crtc_state *crtc_state) +{ + if (crtc_state->cgm_mode & CGM_PIPE_MODE_GAMMA) + return 10; + else + return i9xx_gamma_precision(crtc_state); +} + +static int ilk_gamma_precision(struct intel_crtc_state *crtc_state) +{ + if (!crtc_state->gamma_enable) + return 0; + + if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0) + return 0; + + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: + return 8; + case GAMMA_MODE_MODE_10BIT: + return 10; + default: + MISSING_CASE(crtc_state->gamma_mode); + return 0; + } +} + +static int ivb_gamma_precision(struct intel_crtc_state *crtc_state) +{ + if (!crtc_state->gamma_enable) + return 0; + + if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0) + return 0; + + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: + return 8; + case GAMMA_MODE_MODE_SPLIT: + case GAMMA_MODE_MODE_10BIT: + return 10; + default: + MISSING_CASE(crtc_state->gamma_mode); + return 0; + } +} + +static int glk_gamma_precision(struct intel_crtc_state *crtc_state) +{ + if (!crtc_state->gamma_enable) + return 0; + + if ((crtc_state->csc_mode & CSC_POSITION_BEFORE_GAMMA) == 0) + return 0; + + switch (crtc_state->gamma_mode) { + case GAMMA_MODE_MODE_8BIT: + return 8; + case GAMMA_MODE_MODE_10BIT: + return 10; + default: + MISSING_CASE(crtc_state->gamma_mode); + return 0; + } +} + +static int icl_gamma_precision(struct intel_crtc_state *crtc_state) +{ + if ((crtc_state->gamma_mode & PRE_CSC_GAMMA_ENABLE) == 0) + return 0; + + switch (crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) { + case GAMMA_MODE_MODE_8BIT: + return 8; + case GAMMA_MODE_MODE_10BIT: + return 10; + default: + MISSING_CASE(crtc_state->gamma_mode); + return 0; + } +} + +int intel_color_get_gamma_bit_precision(struct intel_crtc_state *crtc_state) +{ + struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc); + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + + if (HAS_GMCH(dev_priv)) { + if (IS_CHERRYVIEW(dev_priv)) + return chv_gamma_precision(crtc_state); + else + return i9xx_gamma_precision(crtc_state); + } else { + if (INTEL_GEN(dev_priv) >= 11) + return icl_gamma_precision(crtc_state); + else if (IS_CANNON
[Intel-gfx] [v7][PATCH 01/12] drm/i915: Introduce vfunc read_luts() to create hw lut
In this patch, a vfunc read_luts() is introduced to create a hw lut i.e. lut having values read from gamma/degamma registers which will later be used to compare with sw lut to validate gamma/degamma lut values. v3: -Rebase v4: -Renamed intel_get_color_config to intel_color_get_config [Jani] -Wrapped get_color_config() [Jani] v5: -Renamed intel_color_get_config() to intel_color_read_luts() -Renamed get_color_config to read_luts v6: -Renamed intel_color_read_luts() back to intel_color_get_config() [Jani and Ville] Signed-off-by: Swati Sharma --- drivers/gpu/drm/i915/i915_drv.h| 1 + drivers/gpu/drm/i915/intel_color.c | 8 drivers/gpu/drm/i915/intel_color.h | 1 + 3 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index d025780..6343e70 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -343,6 +343,7 @@ struct drm_i915_display_funcs { * involved with the same commit. */ void (*load_luts)(const struct intel_crtc_state *crtc_state); + void (*read_luts)(struct intel_crtc_state *crtc_state); }; struct intel_csr { diff --git a/drivers/gpu/drm/i915/intel_color.c b/drivers/gpu/drm/i915/intel_color.c index 962db12..50b98ee 100644 --- a/drivers/gpu/drm/i915/intel_color.c +++ b/drivers/gpu/drm/i915/intel_color.c @@ -879,6 +879,14 @@ int intel_color_check(struct intel_crtc_state *crtc_state) return dev_priv->display.color_check(crtc_state); } +void intel_color_get_config(struct intel_crtc_state *crtc_state) +{ + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev); + + if (dev_priv->display.read_luts) + dev_priv->display.read_luts(crtc_state); +} + static bool need_plane_update(struct intel_plane *plane, const struct intel_crtc_state *crtc_state) { diff --git a/drivers/gpu/drm/i915/intel_color.h b/drivers/gpu/drm/i915/intel_color.h index b8a3ce6..057e8ac 100644 --- a/drivers/gpu/drm/i915/intel_color.h +++ b/drivers/gpu/drm/i915/intel_color.h @@ -13,5 +13,6 @@ int intel_color_check(struct intel_crtc_state *crtc_state); void intel_color_commit(const struct intel_crtc_state *crtc_state); void intel_color_load_luts(const struct intel_crtc_state *crtc_state); +void intel_color_get_config(struct intel_crtc_state *crtc_state); #endif /* __INTEL_COLOR_H__ */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
On Mon, May 27, 2019 at 02:39:18PM +0200, Thomas Hellstrom wrote: > On 5/27/19 10:17 AM, Emil Velikov wrote: > > From: Emil Velikov > > > > There are cases (in mesa and applications) where one would open the > > primary node without properly authenticating the client. > > > > Sometimes we don't check if the authentication succeeds, but there's > > also cases we simply forget to do it. > > > > The former was a case for Mesa where it did not not check the return > > value of drmGetMagic() [1]. That was fixed recently although, there's > > the question of older drivers or other apps that exbibit this behaviour. > > > > While omitting the call results in issues as seen in [2] and [3]. > > > > In the libva case, libva itself doesn't authenticate the DRM client and > > the vaGetDisplayDRM documentation doesn't mention if the app should > > either. > > > > As of today, the official vainfo utility doesn't authenticate. > > > > To workaround issues like these, some users resort to running their apps > > under sudo. Which admittedly isn't always a good idea. > > > > Since any DRIVER_RENDER driver has sufficient isolation between clients, > > we can use that, for unauthenticated [primary node] ioctls that require > > DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. > > > > v2: > > - Rework/simplify if check (Daniel V) > > - Add examples to commit messages, elaborate. (Daniel V) > > > > v3: > > - Use single unlikely (Daniel V) > > > > v4: > > - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU > > issue is fixed with earlier patch. > > > > [1] > > https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 > > [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html > > [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 > > Testcase: igt/core_unauth_vs_render > > Cc: intel-gfx@lists.freedesktop.org > > Signed-off-by: Emil Velikov > > Reviewed-by: Daniel Vetter > > Link: > > https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com > > --- > > drivers/gpu/drm/drm_ioctl.c | 20 > > 1 file changed, 16 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c > > index 9841c0076f02..b64b022a2b29 100644 > > --- a/drivers/gpu/drm/drm_ioctl.c > > +++ b/drivers/gpu/drm/drm_ioctl.c > > @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, > > return err; > > } > > +static inline bool > > +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) > > +{ > > + return drm_core_check_feature(dev, DRIVER_RENDER) && > > + (flags & DRM_RENDER_ALLOW); > > +} > > + > > /** > >* drm_ioctl_permit - Check ioctl permissions against caller > >* > > @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, > >*/ > > int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) > > { > > + const struct drm_device *dev = file_priv->minor->dev; > > + > > /* ROOT_ONLY is only for CAP_SYS_ADMIN */ > > if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) > > return -EACCES; > > - /* AUTH is only for authenticated or render client */ > > - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && > > -!file_priv->authenticated)) > > - return -EACCES; > > + /* AUTH is only for master ... */ > > + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) { > > + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ > > + if (!file_priv->authenticated && > > + !drm_render_driver_and_ioctl(dev, flags)) > > + return -EACCES; > > + } > > This breaks vmwgfx primary client authentication in the surface_reference > ioctl, which takes different paths in case of render clients and primary > clients, but adding an auth check in the primary path in the vmwgfx code > should fix this. Hm yeah we need to adjust that ... otoh kinda not sure why this is gated on authentication status, and not on "am I master or not" status. At least from a very cursory read ... -Daniel > > /Thomas > > > > /* MASTER is only for master or control clients */ > > if (unlikely((flags & DRM_MASTER) && > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6) URL : https://patchwork.freedesktop.org/series/61047/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Keep user GGTT alive for a minimum of 250ms + +drivers/gpu/drm/i915/i915_utils.h:220:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_wakeref.c:86:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +Error in reading or end of file. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: Fix AUX-B HW not done issue w/o AUX-A
On Fri, May 24, 2019 at 08:35:32PM +0300, Imre Deak wrote: > Atm AUX-B transfers can fail with the following error if AUX-A is not > enabled: > > [ 594.594108] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status > 0x7c2003ff > [ 594.615854] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not > signal timeout! > [ 594.632851] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp aux hw did not > signal timeout! > [ 594.632915] [drm:intel_dp_aux_xfer [i915]] *ERROR* dp_aux_ch not done > status 0xac2003ff > [ 594.641786] [ cut here ] > [ 594.641790] dp_aux_ch not started status 0xac2003ff > [ 594.641874] WARNING: CPU: 4 PID: 1366 at > drivers/gpu/drm/i915/intel_dp.c:1268 intel_dp_aux_xfer+0x232/0x890 [i915] > > Ville noticed this issue already earlier and managed to work around it > by keeping AUX-A always powered whenever AUX-B was used. He also > reported the issue to HW folks and they have now root caused the problem > and updated BSpec with a fix (see internal BSpec/Index/21257, > HSD/1607152412). > > I noticed the same error - even with the WA being applied - while doing > AUX transfers with Chamelium being connected with a DP cable to the > source but letting Chamelium imitate an unplug. This is probably some > unstandard way on Chamelium's behalf of disconnecting itself from the > AUX pins. For instance it could still pull on the AUX pins which would > prevent the source from detecting AUX timeouts in the proper way, > leading to the ERRORs or WARNs seen in the logs in the Reference: bug > below. > > In case I disconnect the sink properly (the cable itself, not via the > Chamelium unplug xmlrpc command) then the AUX timeout signaling works > properly and so there won't be any ERRORs/WARNs emitted. > > Reference: https://bugs.freedesktop.org/show_bug.cgi?id=110718 > Cc: Ville Syrjälä > Reported-by: Ville Syrjälä > Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/i915_reg.h| 3 +++ > drivers/gpu/drm/i915/intel_combo_phy.c | 6 ++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 87e8780711d7..bae4a2547eb2 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1846,6 +1846,9 @@ enum i915_power_well_id { > #define VOLTAGE_INFO_MASK (3 << 24) > #define VOLTAGE_INFO_SHIFT 24 > > +#define ICL_PORT_COMP_DW8(port) _MMIO(_ICL_PORT_COMP_DW(8, > port)) > +#define IREFGEN(1 << 24) > + > #define CNL_PORT_COMP_DW9_MMIO(0x162124) > #define ICL_PORT_COMP_DW9(port) _MMIO(_ICL_PORT_COMP_DW(9, > port)) > > diff --git a/drivers/gpu/drm/i915/intel_combo_phy.c > b/drivers/gpu/drm/i915/intel_combo_phy.c > index 19a9333b727a..98213cc58736 100644 > --- a/drivers/gpu/drm/i915/intel_combo_phy.c > +++ b/drivers/gpu/drm/i915/intel_combo_phy.c > @@ -275,6 +275,12 @@ static void icl_combo_phys_init(struct drm_i915_private > *dev_priv) > > cnl_set_procmon_ref_values(dev_priv, port); > > + if (port == PORT_A) { > + val = I915_READ(ICL_PORT_COMP_DW8(port)); > + val |= IREFGEN; > + I915_WRITE(ICL_PORT_COMP_DW8(port), val); > + } > + > val = I915_READ(ICL_PORT_COMP_DW0(port)); > val |= COMP_INIT; > I915_WRITE(ICL_PORT_COMP_DW0(port), val); > -- > 2.17.1 -- 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.CHECKPATCH: warning for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev6) URL : https://patchwork.freedesktop.org/series/61047/ State : warning == Summary == $ dim checkpatch origin/drm-tip fbf134649c9d drm/i915: Keep user GGTT alive for a minimum of 250ms -:196: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #196: FILE: drivers/gpu/drm/i915/intel_wakeref.h:139: + spinlock_t lock; total: 0 errors, 0 warnings, 1 checks, 167 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
On 2019/05/27, Thomas Hellstrom wrote: > On 5/27/19 10:17 AM, Emil Velikov wrote: > > From: Emil Velikov > > > > There are cases (in mesa and applications) where one would open the > > primary node without properly authenticating the client. > > > > Sometimes we don't check if the authentication succeeds, but there's > > also cases we simply forget to do it. > > > > The former was a case for Mesa where it did not not check the return > > value of drmGetMagic() [1]. That was fixed recently although, there's > > the question of older drivers or other apps that exbibit this behaviour. > > > > While omitting the call results in issues as seen in [2] and [3]. > > > > In the libva case, libva itself doesn't authenticate the DRM client and > > the vaGetDisplayDRM documentation doesn't mention if the app should > > either. > > > > As of today, the official vainfo utility doesn't authenticate. > > > > To workaround issues like these, some users resort to running their apps > > under sudo. Which admittedly isn't always a good idea. > > > > Since any DRIVER_RENDER driver has sufficient isolation between clients, > > we can use that, for unauthenticated [primary node] ioctls that require > > DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. > > > > v2: > > - Rework/simplify if check (Daniel V) > > - Add examples to commit messages, elaborate. (Daniel V) > > > > v3: > > - Use single unlikely (Daniel V) > > > > v4: > > - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU > > issue is fixed with earlier patch. > > > > [1] > > https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 > > [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html > > [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 > > Testcase: igt/core_unauth_vs_render > > Cc: intel-gfx@lists.freedesktop.org > > Signed-off-by: Emil Velikov > > Reviewed-by: Daniel Vetter > > Link: > > https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com > > --- > > drivers/gpu/drm/drm_ioctl.c | 20 > > 1 file changed, 16 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c > > index 9841c0076f02..b64b022a2b29 100644 > > --- a/drivers/gpu/drm/drm_ioctl.c > > +++ b/drivers/gpu/drm/drm_ioctl.c > > @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, > > return err; > > } > > +static inline bool > > +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) > > +{ > > + return drm_core_check_feature(dev, DRIVER_RENDER) && > > + (flags & DRM_RENDER_ALLOW); > > +} > > + > > /** > >* drm_ioctl_permit - Check ioctl permissions against caller > >* > > @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, > >*/ > > int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) > > { > > + const struct drm_device *dev = file_priv->minor->dev; > > + > > /* ROOT_ONLY is only for CAP_SYS_ADMIN */ > > if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) > > return -EACCES; > > - /* AUTH is only for authenticated or render client */ > > - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && > > -!file_priv->authenticated)) > > - return -EACCES; > > + /* AUTH is only for master ... */ > > + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) { > > + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ > > + if (!file_priv->authenticated && > > + !drm_render_driver_and_ioctl(dev, flags)) > > + return -EACCES; > > + } > > This breaks vmwgfx primary client authentication in the surface_reference > ioctl, which takes different paths in case of render clients and primary > clients, but adding an auth check in the primary path in the vmwgfx code > should fix this. > Ack. Thanks for having a look. Will include a permission check in v2 of the series. -Emil ___ 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/panel: drmP.h removal + small fix
== Series Details == Series: drm/panel: drmP.h removal + small fix URL : https://patchwork.freedesktop.org/series/61157/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13104_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13104_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13104_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_13104_full: ### IGT changes ### Possible regressions * igt@gem_pwrite@small-gtt-backwards: - shard-apl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl8/igt@gem_pwr...@small-gtt-backwards.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-apl5/igt@gem_pwr...@small-gtt-backwards.html * igt@runner@aborted: - shard-apl: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-apl5/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_13104_full that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries_display_off: - shard-skl: [PASS][4] -> [INCOMPLETE][5] ([fdo#104108]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl2/igt@debugfs_test@read_all_entries_display_off.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-skl5/igt@debugfs_test@read_all_entries_display_off.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][6] -> [INCOMPLETE][7] ([fdo#103359] / [k.org#198133]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk7/igt@gem_tiled_swapp...@non-threaded.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][8] -> [DMESG-WARN][9] ([fdo#108566]) +7 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][10] -> [FAIL][11] ([fdo#106509] / [fdo#107409]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk5/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-glk4/igt@kms_cursor_leg...@2x-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109349]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-iclb6/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][14] -> [FAIL][15] ([fdo#105363]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_flip@2x-wf_vblank-ts-check-interruptible: - shard-hsw: [PASS][16] -> [SKIP][17] ([fdo#109271]) +9 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_flip@2x-wf_vblank-ts-check-interruptible.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-hsw1/igt@kms_flip@2x-wf_vblank-ts-check-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][18] -> [FAIL][19] ([fdo#103167]) +6 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109642]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr2...@frontbuffer.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13104/shard-iclb6/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - s
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
On 5/27/19 10:17 AM, Emil Velikov wrote: From: Emil Velikov There are cases (in mesa and applications) where one would open the primary node without properly authenticating the client. Sometimes we don't check if the authentication succeeds, but there's also cases we simply forget to do it. The former was a case for Mesa where it did not not check the return value of drmGetMagic() [1]. That was fixed recently although, there's the question of older drivers or other apps that exbibit this behaviour. While omitting the call results in issues as seen in [2] and [3]. In the libva case, libva itself doesn't authenticate the DRM client and the vaGetDisplayDRM documentation doesn't mention if the app should either. As of today, the official vainfo utility doesn't authenticate. To workaround issues like these, some users resort to running their apps under sudo. Which admittedly isn't always a good idea. Since any DRIVER_RENDER driver has sufficient isolation between clients, we can use that, for unauthenticated [primary node] ioctls that require DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. v2: - Rework/simplify if check (Daniel V) - Add examples to commit messages, elaborate. (Daniel V) v3: - Use single unlikely (Daniel V) v4: - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU issue is fixed with earlier patch. [1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 Testcase: igt/core_unauth_vs_render Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com --- drivers/gpu/drm/drm_ioctl.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 9841c0076f02..b64b022a2b29 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, return err; } +static inline bool +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) +{ + return drm_core_check_feature(dev, DRIVER_RENDER) && + (flags & DRM_RENDER_ALLOW); +} + /** * drm_ioctl_permit - Check ioctl permissions against caller * @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, */ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) { + const struct drm_device *dev = file_priv->minor->dev; + /* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) return -EACCES; - /* AUTH is only for authenticated or render client */ - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && -!file_priv->authenticated)) - return -EACCES; + /* AUTH is only for master ... */ + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) { + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ + if (!file_priv->authenticated && + !drm_render_driver_and_ioctl(dev, flags)) + return -EACCES; + } This breaks vmwgfx primary client authentication in the surface_reference ioctl, which takes different paths in case of render clients and primary clients, but adding an auth check in the primary path in the vmwgfx code should fix this. /Thomas /* MASTER is only for master or control clients */ if (unlikely((flags & DRM_MASTER) && ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
Am 27.05.19 um 14:10 schrieb Emil Velikov: > On 2019/05/27, Christian König wrote: >> Am 27.05.19 um 10:17 schrieb Emil Velikov: >>> From: Emil Velikov >>> >>> There are cases (in mesa and applications) where one would open the >>> primary node without properly authenticating the client. >>> >>> Sometimes we don't check if the authentication succeeds, but there's >>> also cases we simply forget to do it. >>> >>> The former was a case for Mesa where it did not not check the return >>> value of drmGetMagic() [1]. That was fixed recently although, there's >>> the question of older drivers or other apps that exbibit this behaviour. >>> >>> While omitting the call results in issues as seen in [2] and [3]. >>> >>> In the libva case, libva itself doesn't authenticate the DRM client and >>> the vaGetDisplayDRM documentation doesn't mention if the app should >>> either. >>> >>> As of today, the official vainfo utility doesn't authenticate. >>> >>> To workaround issues like these, some users resort to running their apps >>> under sudo. Which admittedly isn't always a good idea. >>> >>> Since any DRIVER_RENDER driver has sufficient isolation between clients, >>> we can use that, for unauthenticated [primary node] ioctls that require >>> DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. >>> >>> v2: >>> - Rework/simplify if check (Daniel V) >>> - Add examples to commit messages, elaborate. (Daniel V) >>> >>> v3: >>> - Use single unlikely (Daniel V) >>> >>> v4: >>> - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU >>> issue is fixed with earlier patch. >> As far as I can see this only affects the following two IOCTLs after >> removing DRM_AUTH from the DRM_RENDER_ALLOW IOCTLs: >>> DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, >>> drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW), >>> DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, >>> drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW) >> So I think it would be simpler to just remove DRM_AUTH from those two >> instead of allowing it for everybody. >> > If I understand you correctly this will remove DRM_AUTH also for drivers > which expose only a primary node. I'm not sure if that is a good idea. That's a good point, but I have doubts that those drivers implement the necessary callbacks and/or set the core feature flag for the IOCTLs. So the maximum what could happen is that you change the returned error from -EACCES into -EOPNOTSUPP/-ENOSYS. Regards, Christian. > That said, if others are OK with the idea I will prepare a patch. > > Thanks > Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
On 2019/05/27, Christian König wrote: > Am 27.05.19 um 10:17 schrieb Emil Velikov: > > From: Emil Velikov > > > > There are cases (in mesa and applications) where one would open the > > primary node without properly authenticating the client. > > > > Sometimes we don't check if the authentication succeeds, but there's > > also cases we simply forget to do it. > > > > The former was a case for Mesa where it did not not check the return > > value of drmGetMagic() [1]. That was fixed recently although, there's > > the question of older drivers or other apps that exbibit this behaviour. > > > > While omitting the call results in issues as seen in [2] and [3]. > > > > In the libva case, libva itself doesn't authenticate the DRM client and > > the vaGetDisplayDRM documentation doesn't mention if the app should > > either. > > > > As of today, the official vainfo utility doesn't authenticate. > > > > To workaround issues like these, some users resort to running their apps > > under sudo. Which admittedly isn't always a good idea. > > > > Since any DRIVER_RENDER driver has sufficient isolation between clients, > > we can use that, for unauthenticated [primary node] ioctls that require > > DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. > > > > v2: > > - Rework/simplify if check (Daniel V) > > - Add examples to commit messages, elaborate. (Daniel V) > > > > v3: > > - Use single unlikely (Daniel V) > > > > v4: > > - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU > > issue is fixed with earlier patch. > > As far as I can see this only affects the following two IOCTLs after > removing DRM_AUTH from the DRM_RENDER_ALLOW IOCTLs: > > DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, > > drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW), > > DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, > > drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW) > > So I think it would be simpler to just remove DRM_AUTH from those two > instead of allowing it for everybody. > If I understand you correctly this will remove DRM_AUTH also for drivers which expose only a primary node. I'm not sure if that is a good idea. That said, if others are OK with the idea I will prepare a patch. Thanks Emil ___ 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: make headers self-contained and drop drmP.h
== Series Details == Series: drm: make headers self-contained and drop drmP.h URL : https://patchwork.freedesktop.org/series/61156/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13103_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13103_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_pwrite@small-cpu-fbr: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl5/igt@gem_pwr...@small-cpu-fbr.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-apl6/igt@gem_pwr...@small-cpu-fbr.html * igt@i915_pm_rpm@gem-execbuf: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107803] / [fdo#107807]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl1/igt@i915_pm_...@gem-execbuf.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-skl1/igt@i915_pm_...@gem-execbuf.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [PASS][7] -> [INCOMPLETE][8] ([fdo#103540]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_f...@2x-flip-vs-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-hsw2/igt@kms_f...@2x-flip-vs-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-move: - shard-hsw: [PASS][11] -> [SKIP][12] ([fdo#109271]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-cur-indfb-move.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-hsw1/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-cur-indfb-move.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +2 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-snb: [PASS][15] -> [INCOMPLETE][16] ([fdo#105411]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-snb1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@tools_test@tools_test: - shard-apl: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl5/igt@tools_test@tools_test.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-apl7/igt@tools_test@tools_test.html Possible fixes * igt@gem_exec_schedule@preemptive-hang-render: - shard-glk: [INCOMPLETE][23] ([fdo#103359] / [k.org#198133]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk7/igt@gem_exec_sched...@preemptive-hang-render.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13103/shard-glk4/igt@gem_exec_sched...@preemptive-hang-render.html * igt@gem_tiled_swapping@non-threaded: - sha
Re: [Intel-gfx] [PATCH 05/13] drm/i915: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls
On 2019/05/27, Jani Nikula wrote: > On Mon, 27 May 2019, Emil Velikov wrote: > > From: Emil Velikov > > > > The authentication can be circumvented, by design, by using the render > > node. > > > > From the driver POV there is no distinction between primary and render > > nodes, thus we can drop the token. > > > > Note: the outstanding DRM_AUTH instances are: > > - legacy DRI1 ioctls, which are already neutered > > - modern but deprecated ioctls > > > > Cc: Jani Nikula > > Cc: Joonas Lahtinen > > Cc: Rodrigo Vivi > > Cc: intel-gfx@lists.freedesktop.org > > Cc: David Airlie > > Cc: Daniel Vetter > > Signed-off-by: Emil Velikov > > Please see > > commit b972fffa114b18a120a7bbde105d69a080d24970 > Author: Christian König > Date: Wed Apr 17 13:25:24 2019 +0200 > > drm/i915: remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW > > It's headed to drm-next in [1]. > Right my series is based on drm-misc-next, which does not (yet) have the patch. I'll drop my patch when the equivalent, shows up in drm-misc-next. Thanks Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 02/22] drm/i915/guc: Don't allow GuC submission
On Mon, 27 May 2019 13:40:25 +0200, Joonas Lahtinen wrote: Quoting Michal Wajdeczko (2019-05-24 02:30:29) Due to the upcoming changes to the GuC ABI interface, we must disable GuC submission mode until final ABI will be available on all GuC firmwares. To avoid regressions on systems configured to run with no longer supported configuration "enable_guc=3" or "enable_guc=1" clear GuC submission bit. v2: force switch to non-GuC submission mode Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Rodrigo Vivi Cc: Daniele Ceraolo Spurio Cc: John Spotswood Cc: Vinay Belgaumkar Cc: Tony Ye Cc: Anusha Srivatsa Cc: Jeff Mcgee Cc: Antonio Argenziano Cc: Sujaritha Sundaresan Cc: Martin Peres Acked-by: Martin Peres diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 1a265fbd95c7..f66105d756df 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -298,6 +307,10 @@ int intel_uc_init(struct drm_i915_private *i915) if (!HAS_GUC(i915)) return -ENODEV; + /* XXX: GuC submission is unavailable for now */ + if (USES_GUC_SUBMISSION(i915)) + return -EIO; + This would be a driver programmer error, wouldn't it? Maybe add GEM_BUG_ON() to the later branch that does the check? Yes as this should never happen now as in v2 we forced non-GuC submission mode (it was needed only in v1 where we were just printing message) Thanks for catching that! Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
Am 27.05.19 um 10:17 schrieb Emil Velikov: From: Emil Velikov There are cases (in mesa and applications) where one would open the primary node without properly authenticating the client. Sometimes we don't check if the authentication succeeds, but there's also cases we simply forget to do it. The former was a case for Mesa where it did not not check the return value of drmGetMagic() [1]. That was fixed recently although, there's the question of older drivers or other apps that exbibit this behaviour. While omitting the call results in issues as seen in [2] and [3]. In the libva case, libva itself doesn't authenticate the DRM client and the vaGetDisplayDRM documentation doesn't mention if the app should either. As of today, the official vainfo utility doesn't authenticate. To workaround issues like these, some users resort to running their apps under sudo. Which admittedly isn't always a good idea. Since any DRIVER_RENDER driver has sufficient isolation between clients, we can use that, for unauthenticated [primary node] ioctls that require DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. v2: - Rework/simplify if check (Daniel V) - Add examples to commit messages, elaborate. (Daniel V) v3: - Use single unlikely (Daniel V) v4: - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU issue is fixed with earlier patch. As far as I can see this only affects the following two IOCTLs after removing DRM_AUTH from the DRM_RENDER_ALLOW IOCTLs: DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW), DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW) So I think it would be simpler to just remove DRM_AUTH from those two instead of allowing it for everybody. Regards, Christian. [1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 Testcase: igt/core_unauth_vs_render Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com --- drivers/gpu/drm/drm_ioctl.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 9841c0076f02..b64b022a2b29 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, return err; } +static inline bool +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) +{ + return drm_core_check_feature(dev, DRIVER_RENDER) && + (flags & DRM_RENDER_ALLOW); +} + /** * drm_ioctl_permit - Check ioctl permissions against caller * @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, */ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) { + const struct drm_device *dev = file_priv->minor->dev; + /* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) return -EACCES; - /* AUTH is only for authenticated or render client */ - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && -!file_priv->authenticated)) - return -EACCES; + /* AUTH is only for master ... */ + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) { + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ + if (!file_priv->authenticated && + !drm_render_driver_and_ioctl(dev, flags)) + return -EACCES; + } /* MASTER is only for master or control clients */ if (unlikely((flags & DRM_MASTER) && ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/33] fbcon notifier begone!
On Mon, May 27, 2019 at 9:17 AM Daniel Vetter wrote: > > On Sat, May 25, 2019 at 07:19:28PM +0200, Sam Ravnborg wrote: > > Hi Daniel. > > > > Good work, nice cleanup all over. > > > > A few comments to a few patches - not something that warrant a > > new series to be posted as long as it is fixed before the patches are > > applied. > > Hm yeah good idea, I'll add that to the next version. Actually I thought a bit more about the locking story, and it's a bit worse than my simple plan here. I think better to just have that floating around, and not make it look like it's an easy simple cleanup. The case I forgot about is that any places that has a printk can recurse through the console_lock, which means we need a lot more try_lock than I originally thought we'd need. -Daniel > > > > btw for future plans: I think this is tricky enough (it's old code and all > > > that) that we should let this soak for 2-3 kernel releases. I think the > > > following would be nice subsequent cleanup/fixes: > > > > > > - push the console lock completely from fbmem.c to fbcon.c. I think we're > > > mostly there with prep, but needs to pondering of corner cases. > > I wonder - should this code consistently use __acquire() etc so we could > > get a little static analysis help for the locking? > > > > I have not played with this for several years and I do not know the > > maturity of this today. > > Ime these sparse annotations are pretty useless because too inflexible. I > tend to use runtime locking checks based on lockdep. Those are more > accurate, and work even when the place the lock is taken is very far away > from where you're checking, without having to annoate all functions in > between. We need that for something like console_lock which is a very big > lock. Only downside is that only paths you hit at runtime are checked. > > > > - move fbcon.c from using indices for tracking fb_info (and accessing > > > registered_fbs without proper locking all the time) to real fb_info > > > pointers with the right amount of refcounting. Mostly motivated by the > > > fun I had trying to simplify fbcon_exit(). > > > > > > - make sure that fbcon call lock/unlock_fb when it calls fbmem.c > > > functions, and sprinkle assert_lockdep_held around in fbmem.c. This > > > needs the console_lock cleanups first. > > > > > > But I think that's material for maybe next year or so. > > Or maybe after next kernel release. > > Could we put this nice plan into todo.rst or similar so we do not have > > to hunt it down by asking google? > > > > For the whole series you can add my: > > Reviewed-by: Sam Ravnborg > > > > Some parts are reviewed as "this looks entirely correct", other parts > > I would claim that I actually understood. > > And after having spend some hours on this a r-b seems in order. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Keep user GGTT alive for a minimum of 250ms
Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too quickly. For example, igt sets the autosuspend delay to 0, and so we immediately attempt to perform runtime suspend upon releasing the wakeref. Unfortunately, that involves tearing down GGTT mmaps as they require an active device. Override the autosuspend for GGTT mmaps, by keeping the wakeref around for 250ms after populating the PTE for a fresh mmap. v2: Prefer refcount_t for its under/overflow error detection v3: Flush the user runtime autosuspend prior to system system. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/Kconfig.profile | 14 +++ drivers/gpu/drm/i915/i915_drv.h | 3 ++ drivers/gpu/drm/i915/i915_gem.c | 7 drivers/gpu/drm/i915/i915_gem_pm.c | 1 + drivers/gpu/drm/i915/intel_wakeref.c | 63 drivers/gpu/drm/i915/intel_wakeref.h | 31 ++ 6 files changed, 119 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 0e5db98da8f3..4fd1ea639d0f 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -1,3 +1,17 @@ +config DRM_I915_USERFAULT_AUTOSUSPEND + int "Runtime autosuspend delay for userspace GGTT mmaps (ms)" + default 250 # milliseconds + help + On runtime suspend, as we suspend the device, we have to revoke + userspace GGTT mmaps and force userspace to take a pagefault on + their next access. The revocation and subsequent recreation of + the GGTT mmap can be very slow and so we impose a small hysteris + that complements the runtime-pm autosuspend and provides a lower + floor on the autosuspend delay. + + May be 0 to disable the extra delay and solely use the device level + runtime pm autosuspend delay tunable. + config DRM_I915_SPIN_REQUEST int default 5 # microseconds diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a2664ea1395b..e7452d6b663f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -874,6 +874,9 @@ struct i915_gem_mm { */ struct list_head userfault_list; + /* Manual runtime pm autosuspend delay for user GGTT mmaps */ + struct intel_wakeref_auto userfault_wakeref; + /** * List of objects which are pending destruction. */ diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index d3b7dac527dc..902162c04d35 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1834,6 +1834,9 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf) assert_rpm_wakelock_held(dev_priv); if (!i915_vma_set_userfault(vma) && !obj->userfault_count++) list_add(&obj->userfault_link, &dev_priv->mm.userfault_list); + if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND) + intel_wakeref_auto(&dev_priv->mm.userfault_wakeref, + msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)); GEM_BUG_ON(!obj->userfault_count); i915_vma_set_ggtt_write(vma); @@ -4671,6 +4674,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv) { GEM_BUG_ON(dev_priv->gt.awake); + intel_wakeref_auto_fini(&dev_priv->mm.userfault_wakeref); + i915_gem_suspend_late(dev_priv); intel_disable_gt_powersave(dev_priv); @@ -4746,7 +4751,9 @@ static void i915_gem_init__mm(struct drm_i915_private *i915) INIT_LIST_HEAD(&i915->mm.unbound_list); INIT_LIST_HEAD(&i915->mm.bound_list); INIT_LIST_HEAD(&i915->mm.fence_list); + INIT_LIST_HEAD(&i915->mm.userfault_list); + intel_wakeref_auto_init(&i915->mm.userfault_wakeref, i915); INIT_WORK(&i915->mm.free_work, __i915_gem_free_work); } diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c b/drivers/gpu/drm/i915/i915_gem_pm.c index fa9c2ebd966a..c0ad19605297 100644 --- a/drivers/gpu/drm/i915/i915_gem_pm.c +++ b/drivers/gpu/drm/i915/i915_gem_pm.c @@ -126,6 +126,7 @@ void i915_gem_suspend(struct drm_i915_private *i915) { GEM_TRACE("\n"); + intel_wakeref_auto(&i915->mm.userfault_wakeref, 0); flush_workqueue(i915->wq); mutex_lock(&i915->drm.struct_mutex); diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c index 91196d9612bb..c2dda5a375f0 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.c +++ b/drivers/gpu/drm/i915/intel_wakeref.c @@ -73,3 +73,66 @@ void __intel_wakeref_init(struct intel_wakeref *wf, struct lock_class_key *key) atomic_set(&wf->count, 0); wf->wakeref = 0; } + +static void wakeref_auto_timeout(struct timer_list *t) +{ + struct intel_wakeref_auto *wf = from_timer(wf, t, timer); + intel_wakeref_t wakeref; + unsigned long flags; + + if (!refcount_dec_and_l
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev5)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev5) URL : https://patchwork.freedesktop.org/series/61047/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6147 -> Patchwork_13105 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13105 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13105, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13105: ### IGT changes ### Possible regressions * igt@i915_module_load@reload: - fi-kbl-r: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-kbl-r/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-kbl-r/igt@i915_module_l...@reload.html - fi-whl-u: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-whl-u/igt@i915_module_l...@reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-whl-u/igt@i915_module_l...@reload.html - fi-skl-iommu: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-skl-iommu/igt@i915_module_l...@reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-skl-iommu/igt@i915_module_l...@reload.html - fi-hsw-4770r: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-hsw-4770r/igt@i915_module_l...@reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-hsw-4770r/igt@i915_module_l...@reload.html - fi-skl-6700k2: [PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-skl-6700k2/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-skl-6700k2/igt@i915_module_l...@reload.html - fi-bsw-kefka: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-bsw-kefka/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-bsw-kefka/igt@i915_module_l...@reload.html - fi-bdw-5557u: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-bdw-5557u/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-bdw-5557u/igt@i915_module_l...@reload.html - fi-skl-guc: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-skl-guc/igt@i915_module_l...@reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-skl-guc/igt@i915_module_l...@reload.html - fi-kbl-guc: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-kbl-guc/igt@i915_module_l...@reload.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-kbl-guc/igt@i915_module_l...@reload.html - fi-cfl-8109u: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-cfl-8109u/igt@i915_module_l...@reload.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-cfl-8109u/igt@i915_module_l...@reload.html - fi-kbl-7500u: [PASS][21] -> [INCOMPLETE][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-kbl-7500u/igt@i915_module_l...@reload.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-kbl-7500u/igt@i915_module_l...@reload.html - fi-cfl-8700k: [PASS][23] -> [INCOMPLETE][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-cfl-8700k/igt@i915_module_l...@reload.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-cfl-8700k/igt@i915_module_l...@reload.html - fi-snb-2520m: [PASS][25] -> [INCOMPLETE][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-snb-2520m/igt@i915_module_l...@reload.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-snb-2520m/igt@i915_module_l...@reload.html - fi-hsw-4770:[PASS][27] -> [INCOMPLETE][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-hsw-4770/igt@i915_module_l...@reload.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13105/fi-hsw-4770/igt@i915_module_l...@reload.html - fi-cfl-guc: [PASS][29] -> [INCOMPLETE][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6147/fi-cfl-guc/igt@i915_module_l...@reload.html [30]: https://intel-gfx-ci.01.org/t
Re: [Intel-gfx] [PATCH v4 02/22] drm/i915/guc: Don't allow GuC submission
Quoting Michal Wajdeczko (2019-05-24 02:30:29) > Due to the upcoming changes to the GuC ABI interface, we must > disable GuC submission mode until final ABI will be available > on all GuC firmwares. > > To avoid regressions on systems configured to run with no longer > supported configuration "enable_guc=3" or "enable_guc=1" clear > GuC submission bit. > > v2: force switch to non-GuC submission mode > > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Rodrigo Vivi > Cc: Daniele Ceraolo Spurio > Cc: John Spotswood > Cc: Vinay Belgaumkar > Cc: Tony Ye > Cc: Anusha Srivatsa > Cc: Jeff Mcgee > Cc: Antonio Argenziano > Cc: Sujaritha Sundaresan > Cc: Martin Peres > Acked-by: Martin Peres > diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c > index 1a265fbd95c7..f66105d756df 100644 > --- a/drivers/gpu/drm/i915/intel_uc.c > +++ b/drivers/gpu/drm/i915/intel_uc.c > @@ -298,6 +307,10 @@ int intel_uc_init(struct drm_i915_private *i915) > if (!HAS_GUC(i915)) > return -ENODEV; > > + /* XXX: GuC submission is unavailable for now */ > + if (USES_GUC_SUBMISSION(i915)) > + return -EIO; > + This would be a driver programmer error, wouldn't it? Maybe add GEM_BUG_ON() to the later branch that does the check? Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 01/22] drm/i915/guc: Change platform default GuC mode
Quoting Michal Wajdeczko (2019-05-24 02:30:28) > Today our most desired GuC configuration is to only enable HuC > if it is available and we really don't care about GuC submission. > Change platform default GuC mode to match our desire. You should amend here that the HuC authentication is needed to enable all media codecs on the hardware. > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen > Cc: Chris Wilson > Cc: Rodrigo Vivi > Cc: Daniele Ceraolo Spurio > Cc: John Spotswood > Cc: Vinay Belgaumkar > Cc: Tony Ye > Cc: Anusha Srivatsa > Cc: Jeff Mcgee > Cc: Antonio Argenziano > Cc: Sujaritha Sundaresan > Acked-by: Tony Ye > Reviewed-by: Sujaritha Sundaresan With the patch message amended, this is: Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev5)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev5) URL : https://patchwork.freedesktop.org/series/61047/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Keep user GGTT alive for a minimum of 250ms + +drivers/gpu/drm/i915/i915_utils.h:220:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_wakeref.c:86:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +Error in reading or end of file. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded
On Fri, 24 May 2019 15:29:22 +0200, Michal Wajdeczko wrote: On Fri, 24 May 2019 15:10:58 +0200, Joonas Lahtinen wrote: Quoting Ye, Tony (2019-05-22 14:32:41) From UMD perspective, when HuC is not working as expected, usually we look into the kernel log and i915_huc_load_status debugfs to find out why it's not working. It will be helpful to know the reason of the failure from the error code. The typically failures we encountered are "HuC FW not loaded (FW not built into initramfs)" and "HuC FW authentication failed". And it looks clearer to me if we can define 0 as "disabled by user" to distinguish it from other errors like ENODEV, ENOPKG and "not authenticated". Suggestion by Chris for 0/1 for huc_status makes sense to me to reflect if HuC authentication was succesful or not. Mostly because the name of the debugfs and func is huc_status. one more thought on debugfs: we are dumping there raw register value, not just single bit that holds authentication status (and auth bit is 7), so I'm not sure why do you want to link that value with getparam value? Michal It also nicely maps to a register. But this entry is not limited to "huc authentication status", as then we should even not try to introduce new errors, but return 0 to match register. On other hand, under normal conditions, we expect HuC to be authenticated and running or explicitly disabled by the user. Other cases are unexpected error conditions. I would expect from the ABI that these error conditions will be reported as errors. For me ABI is something more than reg value. One could have huc_enabled which would then collapse to easy 0/1, but that'd be bit redundant. that's why we wanted to provide more details in new error codes for existing GETPARAM, without breaking current usages. Michal Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Keep user GGTT alive for a minimum of 250ms (rev5)
== Series Details == Series: drm/i915: Keep user GGTT alive for a minimum of 250ms (rev5) URL : https://patchwork.freedesktop.org/series/61047/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6e1b0f65e952 drm/i915: Keep user GGTT alive for a minimum of 250ms -:195: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #195: FILE: drivers/gpu/drm/i915/intel_wakeref.h:139: + spinlock_t lock; total: 0 errors, 0 warnings, 1 checks, 166 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915: Keep user GGTT alive for a minimum of 250ms
Do not allow runtime pm autosuspend to remove userspace GGTT mmaps too quickly. For example, igt sets the autosuspend delay to 0, and so we immediately attempt to perform runtime suspend upon releasing the wakeref. Unfortunately, that involves tearing down GGTT mmaps as they require an active device. Override the autosuspend for GGTT mmaps, by keeping the wakeref around for 250ms after populating the PTE for a fresh mmap. v2: Prefer refcount_t for its under/overflow error detection v3: Flush the user runtime autosuspend prior to system system. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/Kconfig.profile | 14 +++ drivers/gpu/drm/i915/i915_drv.h | 3 ++ drivers/gpu/drm/i915/i915_gem.c | 7 drivers/gpu/drm/i915/i915_gem_pm.c | 1 + drivers/gpu/drm/i915/intel_wakeref.c | 62 drivers/gpu/drm/i915/intel_wakeref.h | 31 ++ 6 files changed, 118 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.profile b/drivers/gpu/drm/i915/Kconfig.profile index 0e5db98da8f3..4fd1ea639d0f 100644 --- a/drivers/gpu/drm/i915/Kconfig.profile +++ b/drivers/gpu/drm/i915/Kconfig.profile @@ -1,3 +1,17 @@ +config DRM_I915_USERFAULT_AUTOSUSPEND + int "Runtime autosuspend delay for userspace GGTT mmaps (ms)" + default 250 # milliseconds + help + On runtime suspend, as we suspend the device, we have to revoke + userspace GGTT mmaps and force userspace to take a pagefault on + their next access. The revocation and subsequent recreation of + the GGTT mmap can be very slow and so we impose a small hysteris + that complements the runtime-pm autosuspend and provides a lower + floor on the autosuspend delay. + + May be 0 to disable the extra delay and solely use the device level + runtime pm autosuspend delay tunable. + config DRM_I915_SPIN_REQUEST int default 5 # microseconds diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a2664ea1395b..e7452d6b663f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -874,6 +874,9 @@ struct i915_gem_mm { */ struct list_head userfault_list; + /* Manual runtime pm autosuspend delay for user GGTT mmaps */ + struct intel_wakeref_auto userfault_wakeref; + /** * List of objects which are pending destruction. */ diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index d3b7dac527dc..902162c04d35 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -1834,6 +1834,9 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf) assert_rpm_wakelock_held(dev_priv); if (!i915_vma_set_userfault(vma) && !obj->userfault_count++) list_add(&obj->userfault_link, &dev_priv->mm.userfault_list); + if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND) + intel_wakeref_auto(&dev_priv->mm.userfault_wakeref, + msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)); GEM_BUG_ON(!obj->userfault_count); i915_vma_set_ggtt_write(vma); @@ -4671,6 +4674,8 @@ void i915_gem_fini(struct drm_i915_private *dev_priv) { GEM_BUG_ON(dev_priv->gt.awake); + intel_wakeref_auto_fini(&dev_priv->mm.userfault_wakeref); + i915_gem_suspend_late(dev_priv); intel_disable_gt_powersave(dev_priv); @@ -4746,7 +4751,9 @@ static void i915_gem_init__mm(struct drm_i915_private *i915) INIT_LIST_HEAD(&i915->mm.unbound_list); INIT_LIST_HEAD(&i915->mm.bound_list); INIT_LIST_HEAD(&i915->mm.fence_list); + INIT_LIST_HEAD(&i915->mm.userfault_list); + intel_wakeref_auto_init(&i915->mm.userfault_wakeref, i915); INIT_WORK(&i915->mm.free_work, __i915_gem_free_work); } diff --git a/drivers/gpu/drm/i915/i915_gem_pm.c b/drivers/gpu/drm/i915/i915_gem_pm.c index fa9c2ebd966a..c0ad19605297 100644 --- a/drivers/gpu/drm/i915/i915_gem_pm.c +++ b/drivers/gpu/drm/i915/i915_gem_pm.c @@ -126,6 +126,7 @@ void i915_gem_suspend(struct drm_i915_private *i915) { GEM_TRACE("\n"); + intel_wakeref_auto(&i915->mm.userfault_wakeref, 0); flush_workqueue(i915->wq); mutex_lock(&i915->drm.struct_mutex); diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c index 91196d9612bb..84b49056e677 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.c +++ b/drivers/gpu/drm/i915/intel_wakeref.c @@ -73,3 +73,65 @@ void __intel_wakeref_init(struct intel_wakeref *wf, struct lock_class_key *key) atomic_set(&wf->count, 0); wf->wakeref = 0; } + +static void wakeref_auto_timeout(struct timer_list *t) +{ + struct intel_wakeref_auto *wf = from_timer(wf, t, timer); + intel_wakeref_t wakeref; + unsigned long flags; + + if (!refcount_dec_and_l
[Intel-gfx] ✓ Fi.CI.IGT: success for fbcon notifier begone! (rev4)
== Series Details == Series: fbcon notifier begone! (rev4) URL : https://patchwork.freedesktop.org/series/60843/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13102_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13102_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_crc@pipe-b-cursor-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_6142/shard-apl5/igt@kms_cursor_...@pipe-b-cursor-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-apl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109349]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-iclb6/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@2x-plain-flip-ts-check-interruptible: - shard-hsw: [PASS][5] -> [SKIP][6] ([fdo#109271]) +32 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_f...@2x-plain-flip-ts-check-interruptible.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-hsw1/igt@kms_f...@2x-plain-flip-ts-check-interruptible.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][7] -> [FAIL][8] ([fdo#105363]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-glk8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-snb: [PASS][9] -> [INCOMPLETE][10] ([fdo#105411]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb1/igt@kms_f...@flip-vs-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-snb1/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-rgb565-draw-render: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-render.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-rgb565-draw-render.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr2...@frontbuffer.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-iclb6/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_rotation_crc@multiplane-rotation: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713] / [fdo#110026]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb7/igt@kms_rotation_...@multiplane-rotation.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-iclb5/igt@kms_rotation_...@multiplane-rotation.html Possible fixes * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [DMESG-WARN][19] ([fdo#108566]) -> [PASS][20] +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl4/igt@gem_ctx_isolat...@vecs0-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-apl5/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [DMESG-WARN][21] ([fdo#108686]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-apl2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-context: - shard-kbl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-kbl1/igt@gem_workarou...@suspend-resume-context.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13102/shard-kbl1/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [INCOMPLETE][25] ([fdo#104108] / [fdo#107807]) -> [PASS][
Re: [Intel-gfx] [PATCH 24/33] Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
On 5/24/19 5:28 PM, Daniel Vetter wrote: > Hi Daniel, > > On Fri, May 24, 2019 at 3:14 PM Daniel Thompson > wrote: >> >> On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote: >>> This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928. >>> >>> The justification is that if hw blanking fails (i.e. fbops->fb_blank) >>> fails, then we still want to shut down the backlight. Which is exactly >>> _not_ what fb_blank() does and so rather inconsistent if we end up >>> with different behaviour between fbcon and direct fbdev usage. Given >>> that the entire notifier maze is getting in the way anyway I figured >>> it's simplest to revert this not well justified commit. >>> >>> v2: Add static inline to the dummy version. >>> >>> Cc: Richard Purdie >>> Signed-off-by: Daniel Vetter >>> Cc: Lee Jones >>> Cc: Daniel Thompson >>> Cc: Jingoo Han >>> Cc: Bartlomiej Zolnierkiewicz >>> Cc: Daniel Vetter >>> Cc: Hans de Goede >>> Cc: Yisheng Xie >>> Cc: linux-fb...@vger.kernel.org >> >> Hi Daniel >> >> When this goes round again could you add me to the covering letter? >> >> I looked at all three of the patches and no objections on my side but >> I'm reluctant to send out acks because I'm not sure I understood the >> wider picture well enough. > > It's one of these patch series with some many different subsystems and > people you can't cc the cover to all of them or mailing lists start > rejecting you because too many recipients. I tried to spam sufficient > mailng lists, but I guess not enough. BTW Not all relevant patches were posted to linux-fbdev and me (i.e. "[PATCH 05/33] fbdev/sa1100fb: Remove dead code") - I found them on other mailing lists but it requires some additional work from me to find / process them. If possible please Cc: linux-fbdev & me on all patches in the patchset. Thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/panel: drop drmP.h usage
On Mon, May 27, 2019 at 11:11:18AM +0200, Linus Walleij wrote: > On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote: > > > Drop use of the deprecated drmP.h header file. > > > > While touching the list of include files: > > - Divide include files in blocks of linux/* video/* drm/* etc. > > Be consistent in the order of the blocks > > - Sort individual blocks of include files > > > > Signed-off-by: Sam Ravnborg > > Cc: Thierry Reding > > Cc: Linus Walleij > > Cc: Stefan Mavrodiev > > Cc: David Airlie > > Cc: Daniel Vetter > > Reviewed-by: Linus Walleij Thanks, can I get you to review patch 1/2 too? Sam ___ 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: Make intel_fuzzy_clock_check available outside of intel_display.c
== Series Details == Series: series starting with [1/2] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c URL : https://patchwork.freedesktop.org/series/61127/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13098_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13098_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_suspend@basic-s3-devices: - shard-snb: [PASS][3] -> [FAIL][4] ([fdo#107918]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb6/igt@gem_exec_susp...@basic-s3-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb7/igt@gem_exec_susp...@basic-s3-devices.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109349]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([fdo#103540]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_f...@2x-flip-vs-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-hsw1/igt@kms_f...@2x-flip-vs-suspend.html * igt@kms_flip@2x-plain-flip: - shard-hsw: [PASS][11] -> [SKIP][12] ([fdo#109271]) +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_f...@2x-plain-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-hsw1/igt@kms_f...@2x-plain-flip.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#109507]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb1/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb3/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb3/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb8/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-snb: [PASS][17] -> [FAIL][18] ([fdo#103375]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr2...@frontbuffer.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb8/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb6/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb3/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_sysfs_edid_timing: - shard-hsw: [PASS][25] -> [FAIL][26] ([fdo#100047]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Introduce Mule Creek Canyon PCH
== Series Details == Series: drm/i915/ehl: Introduce Mule Creek Canyon PCH URL : https://patchwork.freedesktop.org/series/61137/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13101_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13101_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]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl2/igt@debugfs_test@read_all_entries_display_off.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-skl5/igt@debugfs_test@read_all_entries_display_off.html * igt@gem_exec_schedule@preempt-hang-blt: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#109100]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb8/igt@gem_exec_sched...@preempt-hang-blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-iclb7/igt@gem_exec_sched...@preempt-hang-blt.html * igt@gem_tiled_blits@interruptible: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb1/igt@gem_tiled_bl...@interruptible.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-iclb1/igt@gem_tiled_bl...@interruptible.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl4/igt@i915_susp...@debugfs-reader.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-apl3/igt@i915_susp...@debugfs-reader.html * igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic: - shard-glk: [PASS][9] -> [FAIL][10] ([fdo#106509] / [fdo#107409]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk3/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-glk4/igt@kms_cursor_leg...@2x-long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@modeset-vs-vblank-race-interruptible: - shard-hsw: [PASS][13] -> [DMESG-FAIL][14] ([fdo#102614] / [fdo#103060]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_f...@modeset-vs-vblank-race-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-hsw5/igt@kms_f...@modeset-vs-vblank-race-interruptible.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move: - shard-hsw: [PASS][15] -> [SKIP][16] ([fdo#109271]) +20 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-move.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-hsw1/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-move.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#108341]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb6/igt@kms_psr@no_drrs.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_cursor_blt: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-iclb3/igt@kms_psr@psr2_cursor_blt.html * igt@kms_vblank@pipe-b-query-forked-hang: - shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb2/igt@kms_vbl...@pipe-b-query-forked-hang.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13101/shard-snb4/igt@kms_vbl...@pipe-b-query-forked-hang.html Possible fixes
Re: [Intel-gfx] [PATCH V3 i-g-t] lib: Drop __kms_addfb() wrapper
Quoting Rodrigo Siqueira (2019-05-27 02:19:51) > The function __kms_addfb() and drmModeAddFB2WithModifiers() have a > similar code. Due to this similarity, this commit replaces all the > occurrences of __kms_addfb() by drmModeAddFB2WithModifiers() and adds > the required adaptations. No. There is a critical difference between the two: igt_ioctl. That allows us to control the ioctl for error injection into the kernel. If you want to test libdrm API and not the kernel, please add tests to libdrm. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make REG_BIT() and REG_GENMASK() work with variables
On Fri, 24 May 2019, Chris Wilson wrote: > Quoting Jani Nikula (2019-05-24 19:52:53) >> REG_BIT() and REG_GENMASK() were intended to work with both constant >> expressions and otherwise, with the former having extra compile time >> checks for the bit ranges. Incredibly, the result of >> __builtin_constant_p() is not an integer constant expression when given >> a non-constant expression, leading to errors in BUILD_BUG_ON_ZERO(). >> >> Replace __builtin_constant_p() with the __is_constexpr() magic spell. >> >> Reported-by: Ville Syrjala >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/i915_reg.h | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index 49dce04dd688..019c48748dc9 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -126,7 +126,7 @@ >> */ >> #define REG_BIT(__n) \ >> ((u32)(BIT(__n) + \ >> - BUILD_BUG_ON_ZERO(__builtin_constant_p(__n) && \ >> + BUILD_BUG_ON_ZERO(__is_constexpr(__n) && \ >> ((__n) < 0 || (__n) > 31 >> >> /** >> @@ -140,8 +140,8 @@ >> */ >> #define REG_GENMASK(__high, __low) \ >> ((u32)(GENMASK(__high, __low) + \ >> - BUILD_BUG_ON_ZERO(__builtin_constant_p(__high) &&\ >> -__builtin_constant_p(__low) && \ >> + BUILD_BUG_ON_ZERO(__is_constexpr(__high) && \ >> +__is_constexpr(__low) && \ >> ((__low) < 0 || (__high) > 31 || (__low) > >> (__high) > > Ok, one old one remaining in _MASKED_FIELD(). > > Reviewed-by: Chris Wilson Thanks, pushed to dinq. BR, Jani. > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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: success for drm/i915/gtt: set err to -ENOMEM on memory allocation failure
== Series Details == Series: drm/i915/gtt: set err to -ENOMEM on memory allocation failure URL : https://patchwork.freedesktop.org/series/61134/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13100_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13100_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_legacy@cursorb-vs-flipb-atomic: - shard-hsw: [PASS][3] -> [SKIP][4] ([fdo#109271]) +30 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_cursor_leg...@cursorb-vs-flipb-atomic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-hsw1/igt@kms_cursor_leg...@cursorb-vs-flipb-atomic.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][5] -> [FAIL][6] ([fdo#105363]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-skl2/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-tilingchange: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_frontbuffer_track...@fbc-tilingchange.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-iclb5/igt@kms_frontbuffer_track...@fbc-tilingchange.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-skl: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108] / [fdo#106978]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl10/igt@kms_frontbuffer_track...@fbcpsr-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-skl1/igt@kms_frontbuffer_track...@fbcpsr-suspend.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-kbl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-iclb5/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_rotation_crc@primary-rotation-180: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713] / [fdo#110026]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb7/igt@kms_rotation_...@primary-rotation-180.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-iclb7/igt@kms_rotation_...@primary-rotation-180.html * igt@kms_sysfs_edid_timing: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#100047]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb1/igt@kms_sysfs_edid_timing.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-iclb3/igt@kms_sysfs_edid_timing.html Possible fixes * igt@gem_exec_schedule@preemptive-hang-render: - shard-glk: [INCOMPLETE][21] ([fdo#103359] / [k.org#198133]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk7/igt@gem_exec_sched...@preemptive-hang-render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13100/shard-glk2/igt@gem_exec_sched...@preemptive-hang-render.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [DMESG-WARN][23] ([fdo#108686]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html [24]: https
[Intel-gfx] [PATCH i-g-t] benchmarks/gem_wsim: Tidy manual sizeof VLA calculations
We can use offsetof for the same effect, much tidier with no dummy locals. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- benchmarks/gem_wsim.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c index db19925b1..a76fdbfe2 100644 --- a/benchmarks/gem_wsim.c +++ b/benchmarks/gem_wsim.c @@ -1443,23 +1443,20 @@ set_ctx_sseu(struct ctx *ctx, uint64_t slice_mask) static size_t sizeof_load_balance(int count) { - struct i915_context_engines_load_balance *ptr; - - return sizeof(*ptr) + count * sizeof(ptr->engines[0]); + return offsetof(struct i915_context_engines_load_balance, + engines[count]); } static size_t sizeof_param_engines(int count) { - struct i915_context_param_engines *ptr; - - return sizeof(*ptr) + count * sizeof(ptr->engines[0]); + return offsetof(struct i915_context_param_engines, + engines[count]); } static size_t sizeof_engines_bond(int count) { - struct i915_context_engines_bond *ptr; - - return sizeof(*ptr) + count * sizeof(ptr->engines[0]); + return offsetof(struct i915_context_engines_bond, + engines[count]); } #define alloca0(sz) ({ size_t sz__ = (sz); memset(alloca(sz__), 0, sz__); }) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/panel: drop drmP.h usage
On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote: > Drop use of the deprecated drmP.h header file. > > While touching the list of include files: > - Divide include files in blocks of linux/* video/* drm/* etc. > Be consistent in the order of the blocks > - Sort individual blocks of include files > > Signed-off-by: Sam Ravnborg > Cc: Thierry Reding > Cc: Linus Walleij > Cc: Stefan Mavrodiev > Cc: David Airlie > Cc: Daniel Vetter Reviewed-by: Linus Walleij Yours, Linus Walleij ___ 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: make REG_BIT() and REG_GENMASK() work with variables
== Series Details == Series: drm/i915: make REG_BIT() and REG_GENMASK() work with variables URL : https://patchwork.freedesktop.org/series/61129/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13099_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13099_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-snb1/igt@gem_...@unwedge-stress.html * igt@i915_pm_rpm@cursor-dpms: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#107807]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl2/igt@i915_pm_...@cursor-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-skl8/igt@i915_pm_...@cursor-dpms.html * igt@i915_pm_rpm@gem-execbuf: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107803] / [fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl1/igt@i915_pm_...@gem-execbuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-skl7/igt@i915_pm_...@gem-execbuf.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110741]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-skl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109349]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@2x-plain-flip: - shard-hsw: [PASS][15] -> [SKIP][16] ([fdo#109271]) +8 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_f...@2x-plain-flip.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-hsw1/igt@kms_f...@2x-plain-flip.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#105363]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-skl10/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_lowres@pipe-a-tiling-x: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103166]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-x.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr2...@frontbuffer.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13099/shard-iclb8/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109441]) +2 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DR
Re: [Intel-gfx] [PATCH 05/13] drm/i915: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls
On Mon, 27 May 2019, Emil Velikov wrote: > From: Emil Velikov > > The authentication can be circumvented, by design, by using the render > node. > > From the driver POV there is no distinction between primary and render > nodes, thus we can drop the token. > > Note: the outstanding DRM_AUTH instances are: > - legacy DRI1 ioctls, which are already neutered > - modern but deprecated ioctls > > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: intel-gfx@lists.freedesktop.org > Cc: David Airlie > Cc: Daniel Vetter > Signed-off-by: Emil Velikov Please see commit b972fffa114b18a120a7bbde105d69a080d24970 Author: Christian König Date: Wed Apr 17 13:25:24 2019 +0200 drm/i915: remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW It's headed to drm-next in [1]. BR, Jani. [1] 87sgt3n45z.fsf@intel.com">http://mid.mail-archive.com/87sgt3n45z.fsf@intel.com > --- > drivers/gpu/drm/i915/i915_drv.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 1ad88e6d7c04..ea7a713654dd 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -3098,7 +3098,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { > DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, drm_noop, DRM_AUTH), > DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, drm_noop, DRM_AUTH), > DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, drm_noop, DRM_AUTH), > - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam_ioctl, > DRM_AUTH|DRM_RENDER_ALLOW), > + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam_ioctl, DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_SETPARAM, drm_noop, > DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), > DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH), > DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH), > @@ -3111,13 +3111,13 @@ static const struct drm_ioctl_desc i915_ioctls[] = { > DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, > DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), > DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, > DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), > DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer_ioctl, > DRM_AUTH), > - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2_ioctl, > DRM_AUTH|DRM_RENDER_ALLOW), > + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2_ioctl, > DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, > DRM_AUTH|DRM_ROOT_ONLY), > DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, > DRM_AUTH|DRM_ROOT_ONLY), > - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, > DRM_AUTH|DRM_RENDER_ALLOW), > + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, > DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, > DRM_RENDER_ALLOW), > - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, > DRM_AUTH|DRM_RENDER_ALLOW), > + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, > DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop, > DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), > DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop, > DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), > DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, > DRM_RENDER_ALLOW), > @@ -3136,7 +3136,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { > DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs_ioctl, > DRM_MASTER), > DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, > intel_sprite_set_colorkey_ioctl, DRM_MASTER), > DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_COLORKEY, drm_noop, DRM_MASTER), > - DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl, > DRM_AUTH|DRM_RENDER_ALLOW), > + DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl, DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE_EXT, > i915_gem_context_create_ioctl, DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY, > i915_gem_context_destroy_ioctl, DRM_RENDER_ALLOW), > DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_RENDER_ALLOW), -- 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 i-g-t] prime_vgem: Fix typo in checking for invalid engines
Move the stray ')' from gem_can_store_dword(exec_id) | exec_flags to gem_can_store_dword(exec_id | exec_flags) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110764 Signed-off-by: Chris Wilson --- tests/prime_vgem.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c index 09e3373be..69ae8c9b0 100644 --- a/tests/prime_vgem.c +++ b/tests/prime_vgem.c @@ -845,7 +845,7 @@ igt_main e->exec_id == 0 ? "basic-" : "", e->name) { gem_require_ring(i915, e->exec_id | e->flags); - igt_require(gem_can_store_dword(i915, e->exec_id) | e->flags); + igt_require(gem_can_store_dword(i915, e->exec_id | e->flags)); gem_quiescent_gpu(i915); test_sync(i915, vgem, e->exec_id, e->flags); @@ -857,7 +857,7 @@ igt_main e->exec_id == 0 ? "basic-" : "", e->name) { gem_require_ring(i915, e->exec_id | e->flags); - igt_require(gem_can_store_dword(i915, e->exec_id) | e->flags); + igt_require(gem_can_store_dword(i915, e->exec_id | e->flags)); gem_quiescent_gpu(i915); test_busy(i915, vgem, e->exec_id, e->flags); @@ -869,7 +869,7 @@ igt_main e->exec_id == 0 ? "basic-" : "", e->name) { gem_require_ring(i915, e->exec_id | e->flags); - igt_require(gem_can_store_dword(i915, e->exec_id) | e->flags); + igt_require(gem_can_store_dword(i915, e->exec_id | e->flags)); gem_quiescent_gpu(i915); test_wait(i915, vgem, e->exec_id, e->flags); @@ -892,7 +892,7 @@ igt_main e->exec_id == 0 ? "basic-" : "", e->name) { gem_require_ring(i915, e->exec_id | e->flags); - igt_require(gem_can_store_dword(i915, e->exec_id) | e->flags); + igt_require(gem_can_store_dword(i915, e->exec_id | e->flags)); gem_quiescent_gpu(i915); test_fence_wait(i915, vgem, e->exec_id, e->flags); -- 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: failure for series starting with [1/2] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c
== Series Details == Series: series starting with [1/2] drm/i915: Make intel_fuzzy_clock_check available outside of intel_display.c URL : https://patchwork.freedesktop.org/series/61127/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13098_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13098_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13098_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_13098_full: ### IGT changes ### Possible regressions * igt@perf_pmu@busy-idle-check-all-vcs0: - shard-snb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb4/igt@perf_...@busy-idle-check-all-vcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb6/igt@perf_...@busy-idle-check-all-vcs0.html Known issues Here are the changes found in Patchwork_13098_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][3] -> [FAIL][4] ([fdo#109661]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb5/igt@gem_...@unwedge-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_suspend@basic-s3-devices: - shard-snb: [PASS][5] -> [FAIL][6] ([fdo#107918]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb6/igt@gem_exec_susp...@basic-s3-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb7/igt@gem_exec_susp...@basic-s3-devices.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-apl6/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109349]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb8/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_flip@2x-flip-vs-suspend: - shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_f...@2x-flip-vs-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-hsw1/igt@kms_f...@2x-flip-vs-suspend.html * igt@kms_flip@2x-plain-flip: - shard-hsw: [PASS][13] -> [SKIP][14] ([fdo#109271]) +11 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw6/igt@kms_f...@2x-plain-flip.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-hsw1/igt@kms_f...@2x-plain-flip.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([fdo#107713] / [fdo#109507]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb1/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb3/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-indfb-scaledprimary: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb3/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb8/igt@kms_frontbuffer_track...@fbc-indfb-scaledprimary.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-snb: [PASS][19] -> [FAIL][20] ([fdo#103375]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-snb7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr2...@frontbuffer.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13098/shard-iclb8/igt@kms_ps
[Intel-gfx] [PATCH 13/13] drm: allow render capable master with DRM_AUTH ioctls
From: Emil Velikov There are cases (in mesa and applications) where one would open the primary node without properly authenticating the client. Sometimes we don't check if the authentication succeeds, but there's also cases we simply forget to do it. The former was a case for Mesa where it did not not check the return value of drmGetMagic() [1]. That was fixed recently although, there's the question of older drivers or other apps that exbibit this behaviour. While omitting the call results in issues as seen in [2] and [3]. In the libva case, libva itself doesn't authenticate the DRM client and the vaGetDisplayDRM documentation doesn't mention if the app should either. As of today, the official vainfo utility doesn't authenticate. To workaround issues like these, some users resort to running their apps under sudo. Which admittedly isn't always a good idea. Since any DRIVER_RENDER driver has sufficient isolation between clients, we can use that, for unauthenticated [primary node] ioctls that require DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW. v2: - Rework/simplify if check (Daniel V) - Add examples to commit messages, elaborate. (Daniel V) v3: - Use single unlikely (Daniel V) v4: - Patch was reverted because it broke AMDGPU, apply again. The AMDGPU issue is fixed with earlier patch. [1] https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136 [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1 Testcase: igt/core_unauth_vs_render Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190114085408.15933-2-emil.l.veli...@gmail.com --- drivers/gpu/drm/drm_ioctl.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index 9841c0076f02..b64b022a2b29 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -511,6 +511,13 @@ int drm_version(struct drm_device *dev, void *data, return err; } +static inline bool +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags) +{ + return drm_core_check_feature(dev, DRIVER_RENDER) && + (flags & DRM_RENDER_ALLOW); +} + /** * drm_ioctl_permit - Check ioctl permissions against caller * @@ -525,14 +532,19 @@ int drm_version(struct drm_device *dev, void *data, */ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv) { + const struct drm_device *dev = file_priv->minor->dev; + /* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN))) return -EACCES; - /* AUTH is only for authenticated or render client */ - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) && -!file_priv->authenticated)) - return -EACCES; + /* AUTH is only for master ... */ + if (unlikely((flags & DRM_AUTH) && drm_is_primary_client(file_priv))) { + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ + if (!file_priv->authenticated && + !drm_render_driver_and_ioctl(dev, flags)) + return -EACCES; + } /* MASTER is only for master or control clients */ if (unlikely((flags & DRM_MASTER) && -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/13] drm/i915: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls
From: Emil Velikov The authentication can be circumvented, by design, by using the render node. From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Note: the outstanding DRM_AUTH instances are: - legacy DRI1 ioctls, which are already neutered - modern but deprecated ioctls Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: intel-gfx@lists.freedesktop.org Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Emil Velikov --- drivers/gpu/drm/i915/i915_drv.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 1ad88e6d7c04..ea7a713654dd 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -3098,7 +3098,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, drm_noop, DRM_AUTH), DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, drm_noop, DRM_AUTH), DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, drm_noop, DRM_AUTH), - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam_ioctl, DRM_AUTH|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_SETPARAM, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH), DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH), @@ -3111,13 +3111,13 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer_ioctl, DRM_AUTH), - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2_ioctl, DRM_AUTH|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY), DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, DRM_AUTH|DRM_ROOT_ONLY), - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_AUTH|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, DRM_RENDER_ALLOW), - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, DRM_AUTH|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, drm_noop, DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY), DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_RENDER_ALLOW), @@ -3136,7 +3136,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs_ioctl, DRM_MASTER), DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_set_colorkey_ioctl, DRM_MASTER), DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_COLORKEY, drm_noop, DRM_MASTER), - DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl, DRM_AUTH|DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_GEM_WAIT, i915_gem_wait_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE_EXT, i915_gem_context_create_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY, i915_gem_context_destroy_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_RENDER_ALLOW), -- 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 drm/i915/kvmgt: Use struct_size() helper
== Series Details == Series: drm/i915/kvmgt: Use struct_size() helper URL : https://patchwork.freedesktop.org/series/61124/ State : success == Summary == CI Bug Log - changes from CI_DRM_6142_full -> Patchwork_13096_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_13096_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13096_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_13096_full: ### IGT changes ### Warnings * igt@prime_vgem@sync-bsd1: - shard-snb: [INCOMPLETE][1] ([fdo#105411]) -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-snb4/igt@prime_v...@sync-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-snb6/igt@prime_v...@sync-bsd1.html Known issues Here are the changes found in Patchwork_13096_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@cursor-dpms: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108840]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb1/igt@i915_pm_...@cursor-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-iclb2/igt@i915_pm_...@cursor-dpms.html * igt@i915_pm_rpm@modeset-stress-extra-wait: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl3/igt@i915_pm_...@modeset-stress-extra-wait.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-skl3/igt@i915_pm_...@modeset-stress-extra-wait.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl10/igt@i915_pm_...@system-suspend-execbuf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-skl4/igt@i915_pm_...@system-suspend-execbuf.html * igt@i915_suspend@fence-restore-untiled: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-skl10/igt@i915_susp...@fence-restore-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-skl9/igt@i915_susp...@fence-restore-untiled.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@pipe-b-forked-move: - shard-apl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103927]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-apl8/igt@kms_cursor_leg...@pipe-b-forked-move.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-apl2/igt@kms_cursor_leg...@pipe-b-forked-move.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109349]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-iclb1/igt@kms_dp_...@basic-dsc-enable-edp.html * igt@kms_draw_crc@draw-method-xrgb2101010-blt-untiled: - shard-hsw: [PASS][17] -> [DMESG-FAIL][18] ([fdo#102614] / [fdo#103232]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_draw_...@draw-method-xrgb2101010-blt-untiled.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-hsw5/igt@kms_draw_...@draw-method-xrgb2101010-blt-untiled.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-glk2/igt@kms_f...@2x-flip-vs-expired-vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-glk5/igt@kms_f...@2x-flip-vs-expired-vblank.html * igt@kms_flip@blocking-wf_vblank: - shard-hsw: [PASS][21] -> [DMESG-FAIL][22] ([fdo#102614]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-hsw5/igt@kms_flip@blocking-wf_vblank.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13096/shard-hsw5/igt@kms_flip@blocking-wf_vblank.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#105363]
Re: [Intel-gfx] [PATCH 32/33] staging/olpc_dcon: Add drm conversion to TODO
On Mon, May 27, 2019 at 09:11:26AM +0200, Daniel Vetter wrote: > On Fri, May 24, 2019 at 10:53:53AM +0200, Daniel Vetter wrote: > > this driver is pretty horrible from a design pov, and needs a complete > > overhaul. Concrete thing that annoys me is that it looks at > > registered_fb, which is an internal thing to fbmem.c and fbcon.c. And > > ofc it gets the lifetime rules all wrong (it should at least use > > get/put_fb_info). > > > > Looking at the history, there's been an attempt at dropping this from > > staging in 2016, but that had to be reverted. Since then not real > > effort except the usual stream of trivial patches, and fbdev has been > > formally closed for any new hw support. Time to try again and drop > > this? > > > > Signed-off-by: Daniel Vetter > > Cc: Jens Frederich > > Cc: Daniel Drake > > Cc: Jon Nettleton > > Hi Greg > > Again get_mainatiners didn't pick you up on this somehow (I manually added > you now for the next round). Do you want to pick this up to staging, or > ack for merging through drm/fbdev as part of the larger fbdev/fbcon > rework? > > Also, I think time to retry and attempt at dropping this imo ... Acked-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/33] staging/olpc: lock_fb_info can't fail
On Mon, May 27, 2019 at 09:10:10AM +0200, Daniel Vetter wrote: > On Fri, May 24, 2019 at 10:53:35AM +0200, Daniel Vetter wrote: > > Simply because olpc never unregisters the damn thing. It also > > registers the framebuffer directly by poking around in fbdev > > core internals, so it's all around rather broken. > > > > Signed-off-by: Daniel Vetter > > Cc: Jens Frederich > > Cc: Daniel Drake > > Cc: Jon Nettleton > > Hi Greg, > > Somehow get_maintainers didn't pick you up for this. Ack for merging this > through drm/fbdev? It's part of a bigger series to rework fbdev/fbcon > interactions. Again, all good for you to take: Acked-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/33] vt: More locking checks
On Mon, May 27, 2019 at 09:08:58AM +0200, Daniel Vetter wrote: > On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote: > > I honestly have no idea what the subtle differences between > > con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But > > it looks like both vc->vc_display_fg and con_driver_map are protected > > by the console_lock, so probably better if we hold that when checking > > this. > > > > To do that I had to deinline the con_is_visible function. > > > > Signed-off-by: Daniel Vetter > > Cc: Greg Kroah-Hartman > > Cc: Nicolas Pitre > > Cc: Martin Hostettler > > Cc: Adam Borowski > > Cc: Daniel Vetter > > Cc: Mikulas Patocka > > Hi Greg, > > Do you want to merge this through your console tree or ack for merging > through drm/fbdev? It's part of a bigger series, and I'd like to have more > testing with this in our trees, but also ok to merge stand-alone if you > prefer that. It's just locking checks and some docs. > > Same for the preceeding patch in this series here. For all of these, please take them through your tree(s): Acked-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/33] fbcon notifier begone!
On Sat, May 25, 2019 at 07:19:28PM +0200, Sam Ravnborg wrote: > Hi Daniel. > > Good work, nice cleanup all over. > > A few comments to a few patches - not something that warrant a > new series to be posted as long as it is fixed before the patches are > applied. Hm yeah good idea, I'll add that to the next version. > > btw for future plans: I think this is tricky enough (it's old code and all > > that) that we should let this soak for 2-3 kernel releases. I think the > > following would be nice subsequent cleanup/fixes: > > > > - push the console lock completely from fbmem.c to fbcon.c. I think we're > > mostly there with prep, but needs to pondering of corner cases. > I wonder - should this code consistently use __acquire() etc so we could > get a little static analysis help for the locking? > > I have not played with this for several years and I do not know the > maturity of this today. Ime these sparse annotations are pretty useless because too inflexible. I tend to use runtime locking checks based on lockdep. Those are more accurate, and work even when the place the lock is taken is very far away from where you're checking, without having to annoate all functions in between. We need that for something like console_lock which is a very big lock. Only downside is that only paths you hit at runtime are checked. > > - move fbcon.c from using indices for tracking fb_info (and accessing > > registered_fbs without proper locking all the time) to real fb_info > > pointers with the right amount of refcounting. Mostly motivated by the > > fun I had trying to simplify fbcon_exit(). > > > > - make sure that fbcon call lock/unlock_fb when it calls fbmem.c > > functions, and sprinkle assert_lockdep_held around in fbmem.c. This > > needs the console_lock cleanups first. > > > > But I think that's material for maybe next year or so. > Or maybe after next kernel release. > Could we put this nice plan into todo.rst or similar so we do not have > to hunt it down by asking google? > > For the whole series you can add my: > Reviewed-by: Sam Ravnborg > > Some parts are reviewed as "this looks entirely correct", other parts > I would claim that I actually understood. > And after having spend some hours on this a r-b seems in order. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 32/33] staging/olpc_dcon: Add drm conversion to TODO
On Fri, May 24, 2019 at 10:53:53AM +0200, Daniel Vetter wrote: > this driver is pretty horrible from a design pov, and needs a complete > overhaul. Concrete thing that annoys me is that it looks at > registered_fb, which is an internal thing to fbmem.c and fbcon.c. And > ofc it gets the lifetime rules all wrong (it should at least use > get/put_fb_info). > > Looking at the history, there's been an attempt at dropping this from > staging in 2016, but that had to be reverted. Since then not real > effort except the usual stream of trivial patches, and fbdev has been > formally closed for any new hw support. Time to try again and drop > this? > > Signed-off-by: Daniel Vetter > Cc: Jens Frederich > Cc: Daniel Drake > Cc: Jon Nettleton Hi Greg Again get_mainatiners didn't pick you up on this somehow (I manually added you now for the next round). Do you want to pick this up to staging, or ack for merging through drm/fbdev as part of the larger fbdev/fbcon rework? Also, I think time to retry and attempt at dropping this imo ... Thanks, Daniel > --- > drivers/staging/olpc_dcon/TODO | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/staging/olpc_dcon/TODO b/drivers/staging/olpc_dcon/TODO > index 665a0b061719..fe09efbc7f77 100644 > --- a/drivers/staging/olpc_dcon/TODO > +++ b/drivers/staging/olpc_dcon/TODO > @@ -1,4 +1,11 @@ > TODO: > + - complete rewrite: > + 1. The underlying fbdev drivers need to be converted into drm kernel > + modesetting drivers. > + 2. The dcon low-power display mode can then be integrated using the > + drm damage tracking and self-refresh helpers. > + This bolted-on self-refresh support that digs around in fbdev > + internals, but isn't properly integrated, is not the correct solution. > - see if vx855 gpio API can be made similar enough to cs5535 so we can > share more code > - convert all uses of the old GPIO API from to the > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/33] staging/olpc: lock_fb_info can't fail
On Fri, May 24, 2019 at 10:53:35AM +0200, Daniel Vetter wrote: > Simply because olpc never unregisters the damn thing. It also > registers the framebuffer directly by poking around in fbdev > core internals, so it's all around rather broken. > > Signed-off-by: Daniel Vetter > Cc: Jens Frederich > Cc: Daniel Drake > Cc: Jon Nettleton Hi Greg, Somehow get_maintainers didn't pick you up for this. Ack for merging this through drm/fbdev? It's part of a bigger series to rework fbdev/fbcon interactions. Thanks, Daniel > --- > drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/drivers/staging/olpc_dcon/olpc_dcon.c > b/drivers/staging/olpc_dcon/olpc_dcon.c > index 6b714f740ac3..a254238be181 100644 > --- a/drivers/staging/olpc_dcon/olpc_dcon.c > +++ b/drivers/staging/olpc_dcon/olpc_dcon.c > @@ -250,11 +250,7 @@ static bool dcon_blank_fb(struct dcon_priv *dcon, bool > blank) > int err; > > console_lock(); > - if (!lock_fb_info(dcon->fbinfo)) { > - console_unlock(); > - dev_err(&dcon->client->dev, "unable to lock framebuffer\n"); > - return false; > - } > + lock_fb_info(dcon->fbinfo); > > dcon->ignore_fb_events = true; > err = fb_blank(dcon->fbinfo, > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/33] vt: More locking checks
On Fri, May 24, 2019 at 10:53:25AM +0200, Daniel Vetter wrote: > I honestly have no idea what the subtle differences between > con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But > it looks like both vc->vc_display_fg and con_driver_map are protected > by the console_lock, so probably better if we hold that when checking > this. > > To do that I had to deinline the con_is_visible function. > > Signed-off-by: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: Nicolas Pitre > Cc: Martin Hostettler > Cc: Adam Borowski > Cc: Daniel Vetter > Cc: Mikulas Patocka Hi Greg, Do you want to merge this through your console tree or ack for merging through drm/fbdev? It's part of a bigger series, and I'd like to have more testing with this in our trees, but also ok to merge stand-alone if you prefer that. It's just locking checks and some docs. Same for the preceeding patch in this series here. Thanks, Daniel > --- > drivers/tty/vt/vt.c| 16 > include/linux/console_struct.h | 5 + > 2 files changed, 17 insertions(+), 4 deletions(-) > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index bc9813b14c58..a8988a085138 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -3815,6 +3815,8 @@ int con_is_bound(const struct consw *csw) > { > int i, bound = 0; > > + WARN_CONSOLE_UNLOCKED(); > + > for (i = 0; i < MAX_NR_CONSOLES; i++) { > if (con_driver_map[i] == csw) { > bound = 1; > @@ -3826,6 +3828,20 @@ int con_is_bound(const struct consw *csw) > } > EXPORT_SYMBOL(con_is_bound); > > +/** > + * con_is_visible - checks whether the current console is visible > + * @vc: virtual console > + * > + * RETURNS: zero if not visible, nonzero if visible > + */ > +bool con_is_visible(const struct vc_data *vc) > +{ > + WARN_CONSOLE_UNLOCKED(); > + > + return *vc->vc_display_fg == vc; > +} > +EXPORT_SYMBOL(con_is_visible); > + > /** > * con_debug_enter - prepare the console for the kernel debugger > * @sw: console driver > diff --git a/include/linux/console_struct.h b/include/linux/console_struct.h > index ed798e114663..24d4c16e3ae0 100644 > --- a/include/linux/console_struct.h > +++ b/include/linux/console_struct.h > @@ -168,9 +168,6 @@ extern void vc_SAK(struct work_struct *work); > > #define CUR_DEFAULT CUR_UNDERLINE > > -static inline bool con_is_visible(const struct vc_data *vc) > -{ > - return *vc->vc_display_fg == vc; > -} > +bool con_is_visible(const struct vc_data *vc); > > #endif /* _LINUX_CONSOLE_STRUCT_H */ > -- > 2.20.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx