[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]:
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]:
[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(>ct);
intel_guc_log_init_early(>log);
@@ -71,7 +80,10 @@ void intel_guc_init_early(struct intel_guc *guc)
spin_lock_init(>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 = >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(>uncore,
- HUC_STATUS2,
- HUC_FW_VERIFIED,
- HUC_FW_VERIFIED,
- 2, 50, );
+ 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(_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(>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 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 = >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 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(>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(>ads_vma, 0);
@@ -172,3 +185,18 @@ void intel_guc_ads_destroy(struct intel_guc *guc)
{
i915_vma_unpin_and_release(>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
---
[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 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(_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(_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(_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(>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(>ct);
@@ -250,7 +265,7 @@ static void guc_disable_communication(struct intel_guc *guc)
if (HAS_GUC_CT(i915))
intel_guc_ct_disable(>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(i915);
+
[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(>irq_lock);
+ gen11_reset_one_iir(i915, 0, GEN11_GUC);
+ spin_unlock_irq(>irq_lock);
+}
+
+void gen11_enable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+ spin_lock_irq(_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(_priv->irq_lock);
+}
+
+void gen11_disable_guc_interrupts(struct drm_i915_private *dev_priv)
+{
+ spin_lock_irq(_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(_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(_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(>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_private *i915);
+void
[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 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
[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]: >
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(>irq_lock);
> + gen11_reset_one_iir(i915, 0, GEN11_GUC);
> + spin_unlock_irq(>irq_lock);
> +}
> +
> +void gen11_enable_guc_interrupts(struct drm_i915_private *dev_priv)
> +{
> + spin_lock_irq(_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(_priv->irq_lock);
> +}
> +
> +void gen11_disable_guc_interrupts(struct drm_i915_private *dev_priv)
> +{
> + spin_lock_irq(_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(_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(_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(>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_device *dev)
> @@ -4707,8 +4757,12 @@
[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
[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(_lut[i], _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(_lut[i], _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->name, \
+
[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(_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(_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(_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(_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(>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(_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(_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
[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: -
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: -
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(>userfault_link, _priv->mm.userfault_list);
+ if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
+ intel_wakeref_auto(_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(_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(>mm.unbound_list);
INIT_LIST_HEAD(>mm.bound_list);
INIT_LIST_HEAD(>mm.fence_list);
+
INIT_LIST_HEAD(>mm.userfault_list);
+ intel_wakeref_auto_init(>mm.userfault_wakeref, i915);
INIT_WORK(>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(>mm.userfault_wakeref, 0);
flush_workqueue(i915->wq);
mutex_lock(>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(>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_lock_irqsave(>count, >lock, ))
+ return;
+
+
[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]:
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(>userfault_link, _priv->mm.userfault_list);
+ if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
+ intel_wakeref_auto(_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(_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(>mm.unbound_list);
INIT_LIST_HEAD(>mm.bound_list);
INIT_LIST_HEAD(>mm.fence_list);
+
INIT_LIST_HEAD(>mm.userfault_list);
+ intel_wakeref_auto_init(>mm.userfault_wakeref, i915);
INIT_WORK(>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(>mm.userfault_wakeref, 0);
flush_workqueue(i915->wq);
mutex_lock(>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(>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_lock_irqsave(>count, >lock, ))
+ return;
+
+
[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]) ->
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 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]:
[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]:
[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]:
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]:
[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] [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] ✓ 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]
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(>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
Re: [Intel-gfx] [PATCH v2 0/7] drm: make headers self-contained and drop drmP.h
Hi Daniel. 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 Thanks > > Did a bit of scrolling, looks all reasonable, but definitely didn't check > things in-depth. > > btw did you look at the i915 Makefile trickery to make sure headers stay > self-contained? Yup, this is what Jani works on getting upstreamed to be part of kbuild. When it lands I will activate it for the drm headers (if not beaten by someone else) I used it locally to check everything was OK. Sam ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/33] fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
On Mon, May 27, 2019 at 08:13:06AM +0200, Daniel Vetter wrote: > On Sat, May 25, 2019 at 05:01:59PM +0200, Sam Ravnborg wrote: > > Hi Daniel > > > > > It's dead code, and removing it avoids me having to understand > > > what it's doing with lock_fb_info. > > > > I pushed the series through my build tests which include the sh > > architecture. > > > > One error and one warning was triggered from sh_mobile_lcdcfb.c. > > The rest was fine. > > > > The patch below removed the sole user of > > sh_mobile_lcdc_must_reconfigure() so this triggers a warning. > > > > And I also get the following error: > > drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_fb_reconfig’: > > drivers/video/fbdev/sh_mobile_lcdcfb.c:1800:2: error: implicit declaration > > of function ‘fbcon_update_vcs’; did you mean ‘file_update_time’? > > [-Werror=implicit-function-declaration] > > fbcon_update_vcs(info, true); > > ^~~~ > > file_update_time > > > > I did not check but assume the error was triggered in patch 28 where > > fbcon_update_vcs() in introduced. > > Oops. Can I have your sob so I can squash this in? Yes, here we go. (It was trivial so I thought not needed, sorry) Signed-off-by: Sam Ravnborg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/33] fbcon: Remove fbcon_has_exited
Hi Daniel. > But I indeed forgot > to delete the initial assignment of info at the function start. Is that > what you mean here? Yes. Sam ___ 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/icl: Fix AUX-B HW not done issue w/o AUX-A
== 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 == 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 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/drm-tip/Patchwork_13095/shard-iclb1/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6142/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [21]:
Re: [Intel-gfx] [PATCH v2 0/7] drm: make headers self-contained and drop drmP.h
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. btw did you look at the i915 Makefile trickery to make sure headers stay self-contained? -Daniel > > > Sam Ravnborg (7): > drm: make drm/drm_auth.h self contained > drm: make drm/drm_legacy.h self-contained > drm: make drm_crtc_internal.h self-contained > drm: make drm_internal.h self-contained > drm: make drm_legacy.h self-contained > drm: make drm_trace.h self-contained > drm: drop use of drmP.h in drm/* > > drivers/gpu/drm/ati_pcigart.c| 5 - > drivers/gpu/drm/drm_agpsupport.c | 11 +-- > drivers/gpu/drm/drm_atomic.c | 9 +++-- > drivers/gpu/drm/drm_atomic_helper.c | 11 +++ > drivers/gpu/drm/drm_atomic_state_helper.c| 7 --- > drivers/gpu/drm/drm_auth.c | 10 -- > drivers/gpu/drm/drm_blend.c | 9 ++--- > drivers/gpu/drm/drm_bufs.c | 21 - > drivers/gpu/drm/drm_client.c | 2 +- > drivers/gpu/drm/drm_color_mgmt.c | 8 ++-- > drivers/gpu/drm/drm_context.c| 8 +++- > drivers/gpu/drm/drm_crtc_helper.c| 14 -- > drivers/gpu/drm/drm_crtc_internal.h | 24 > drivers/gpu/drm/drm_debugfs.c| 13 - > drivers/gpu/drm/drm_debugfs_crc.c| 9 - > drivers/gpu/drm/drm_dma.c| 6 +- > drivers/gpu/drm/drm_drv.c| 9 ++--- > drivers/gpu/drm/drm_dumb_buffers.c | 4 +++- > drivers/gpu/drm/drm_encoder.c| 4 +++- > drivers/gpu/drm/drm_fb_helper.c | 19 --- > drivers/gpu/drm/drm_file.c | 11 +++ > drivers/gpu/drm/drm_flip_work.c | 6 -- > drivers/gpu/drm/drm_fourcc.c | 2 +- > drivers/gpu/drm/drm_framebuffer.c| 13 + > drivers/gpu/drm/drm_gem.c| 8 ++-- > drivers/gpu/drm/drm_gem_cma_helper.c | 11 ++- > drivers/gpu/drm/drm_gem_framebuffer_helper.c | 1 - > drivers/gpu/drm/drm_hashtab.c| 10 +++--- > drivers/gpu/drm/drm_internal.h | 10 +- > drivers/gpu/drm/drm_ioc32.c | 9 ++--- > drivers/gpu/drm/drm_ioctl.c | 22 ++ > drivers/gpu/drm/drm_irq.c| 13 + > drivers/gpu/drm/drm_kms_helper_common.c | 3 ++- > drivers/gpu/drm/drm_lease.c | 15 ++- > drivers/gpu/drm/drm_legacy.h | 4 > drivers/gpu/drm/drm_legacy_misc.c| 7 ++- > drivers/gpu/drm/drm_lock.c | 8 ++-- > drivers/gpu/drm/drm_memory.c | 9 +++-- > drivers/gpu/drm/drm_mm.c | 9 + > drivers/gpu/drm/drm_mode_config.c| 6 +- > drivers/gpu/drm/drm_mode_object.c| 9 +++-- > drivers/gpu/drm/drm_modes.c | 7 +-- > drivers/gpu/drm/drm_modeset_lock.c | 2 +- > drivers/gpu/drm/drm_of.c | 5 +++-- > drivers/gpu/drm/drm_pci.c| 11 --- > drivers/gpu/drm/drm_plane_helper.c
Re: [Intel-gfx] [PATCH 11/33] fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify
On Sat, May 25, 2019 at 05:01:59PM +0200, Sam Ravnborg wrote:
> Hi Daniel
>
> > It's dead code, and removing it avoids me having to understand
> > what it's doing with lock_fb_info.
>
> I pushed the series through my build tests which include the sh
> architecture.
>
> One error and one warning was triggered from sh_mobile_lcdcfb.c.
> The rest was fine.
>
> The patch below removed the sole user of
> sh_mobile_lcdc_must_reconfigure() so this triggers a warning.
>
> And I also get the following error:
> drivers/video/fbdev/sh_mobile_lcdcfb.c: In function ‘sh_mobile_fb_reconfig’:
> drivers/video/fbdev/sh_mobile_lcdcfb.c:1800:2: error: implicit declaration of
> function ‘fbcon_update_vcs’; did you mean ‘file_update_time’?
> [-Werror=implicit-function-declaration]
> fbcon_update_vcs(info, true);
> ^~~~
> file_update_time
>
> I did not check but assume the error was triggered in patch 28 where
> fbcon_update_vcs() in introduced.
Oops. Can I have your sob so I can squash this in?
Thanks, Daniel
>
>
> Both are trivially fixed by appended patch.
>
> Sam
>
> diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> index bb1a610d0363..b8454424910d 100644
> --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -533,25 +534,6 @@ static void sh_mobile_lcdc_display_off(struct
> sh_mobile_lcdc_chan *ch)
> ch->tx_dev->ops->display_off(ch->tx_dev);
> }
>
> -static bool
> -sh_mobile_lcdc_must_reconfigure(struct sh_mobile_lcdc_chan *ch,
> - const struct fb_videomode *new_mode)
> -{
> - dev_dbg(ch->info->dev, "Old %ux%u, new %ux%u\n",
> - ch->display.mode.xres, ch->display.mode.yres,
> - new_mode->xres, new_mode->yres);
> -
> - /* It can be a different monitor with an equal video-mode */
> - if (fb_mode_is_equal(>display.mode, new_mode))
> - return false;
> -
> - dev_dbg(ch->info->dev, "Switching %u -> %u lines\n",
> - ch->display.mode.yres, new_mode->yres);
> - ch->display.mode = *new_mode;
> -
> - return true;
> -}
> -
> static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
> struct fb_info *info);
>
>
>
> > Signed-off-by: Daniel Vetter
> > Reviewed-by: Geert Uytterhoeven
> > Cc: Geert Uytterhoeven
> > Cc: Daniel Vetter
> > ---
> > drivers/video/fbdev/sh_mobile_lcdcfb.c | 63 --
> > drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 --
> > 2 files changed, 68 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > index dc46be38c970..c5924f5e98c6 100644
> > --- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > +++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
> > @@ -556,67 +556,6 @@ sh_mobile_lcdc_must_reconfigure(struct
> > sh_mobile_lcdc_chan *ch,
> > static int sh_mobile_lcdc_check_var(struct fb_var_screeninfo *var,
> > struct fb_info *info);
> >
> > -static int sh_mobile_lcdc_display_notify(struct sh_mobile_lcdc_chan *ch,
> > -enum sh_mobile_lcdc_entity_event event,
> > -const struct fb_videomode *mode,
> > -const struct fb_monspecs *monspec)
> > -{
> > - struct fb_info *info = ch->info;
> > - struct fb_var_screeninfo var;
> > - int ret = 0;
> > -
> > - switch (event) {
> > - case SH_MOBILE_LCDC_EVENT_DISPLAY_CONNECT:
> > - /* HDMI plug in */
> > - console_lock();
> > - if (lock_fb_info(info)) {
> > -
> > -
> > - ch->display.width = monspec->max_x * 10;
> > - ch->display.height = monspec->max_y * 10;
> > -
> > - if (!sh_mobile_lcdc_must_reconfigure(ch, mode) &&
> > - info->state == FBINFO_STATE_RUNNING) {
> > - /* First activation with the default monitor.
> > -* Just turn on, if we run a resume here, the
> > -* logo disappears.
> > -*/
> > - info->var.width = ch->display.width;
> > - info->var.height = ch->display.height;
> > - sh_mobile_lcdc_display_on(ch);
> > - } else {
> > - /* New monitor or have to wake up */
> > - fb_set_suspend(info, 0);
> > - }
> > -
> > -
> > - unlock_fb_info(info);
> > - }
> > - console_unlock();
> > - break;
> > -
> > - case SH_MOBILE_LCDC_EVENT_DISPLAY_DISCONNECT:
> > - /* HDMI disconnect */
> > - console_lock();
> >
Re: [Intel-gfx] [PATCH 09/33] fbcon: Remove fbcon_has_exited
On Sat, May 25, 2019 at 05:38:26PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> One detail I noticed while brosing the changes.
>
> >
> > @@ -1064,9 +1062,13 @@ static void fbcon_init(struct vc_data *vc, int init)
> > int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
> > int cap, ret;
> >
> > - if (info_idx == -1 || info == NULL)
> > + if (WARN_ON(info_idx == -1))
> > return;
> >
> > + if (con2fb_map[vc->vc_num] == -1)
> > + con2fb_map[vc->vc_num] = info_idx;
> > +
> > + info = registered_fb[con2fb_map[vc->vc_num]];
> > cap = info->flags;
>
> When info is defined it is also assigned:
> struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
>
> As the test for info is gone this assignment is no longer
> requrired and can be deleted.
We use it later on, so we definitely still need info. But I indeed forgot
to delete the initial assignment of info at the function start. Is that
what you mean here?
>
> The code now assumes that there is always an fb_info if con2fb_map[]
> is not set to -1. I could not determine if this is OK, but this
> likely boils down to your locking concern of registered_fb.
Yup, see how fb_registered/unregistered manage this. I think that part
actually all works out correctly (as long as everyone is holding
console_lock). But it's a bit unpretty that fbcon digs around in the raw
registered_fb array instead of going through the refcounted helpers, and
having a full refcounted pointer. Much easier to convince yourself of that
than chasing indices assigments all over imo.
-Daniel
>
> Sam
>
> >
> > if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
> > @@ -3336,14 +3338,6 @@ static int fbcon_event_notify(struct notifier_block
> > *self,
> > struct fb_blit_caps *caps;
> > int idx, ret = 0;
> >
> > - /*
> > -* ignore all events except driver registration and deregistration
> > -* if fbcon is not active
> > -*/
> > - if (fbcon_has_exited && !(action == FB_EVENT_FB_REGISTERED ||
> > - action == FB_EVENT_FB_UNREGISTERED))
> > - goto done;
> > -
> > switch(action) {
> > case FB_EVENT_SUSPEND:
> > fbcon_suspended(info);
> > @@ -3396,7 +3390,6 @@ static int fbcon_event_notify(struct notifier_block
> > *self,
> > fbcon_remap_all(idx);
> > break;
> > }
> > -done:
> > return ret;
> > }
> >
> > @@ -3443,9 +3436,6 @@ static ssize_t store_rotate(struct device *device,
> > int rotate, idx;
> > char **last = NULL;
> >
> > - if (fbcon_has_exited)
> > - return count;
> > -
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > @@ -3468,9 +3458,6 @@ static ssize_t store_rotate_all(struct device *device,
> > int rotate, idx;
> > char **last = NULL;
> >
> > - if (fbcon_has_exited)
> > - return count;
> > -
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > @@ -3491,9 +3478,6 @@ static ssize_t show_rotate(struct device *device,
> > struct fb_info *info;
> > int rotate = 0, idx;
> >
> > - if (fbcon_has_exited)
> > - return 0;
> > -
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > @@ -3514,9 +3498,6 @@ static ssize_t show_cursor_blink(struct device
> > *device,
> > struct fbcon_ops *ops;
> > int idx, blink = -1;
> >
> > - if (fbcon_has_exited)
> > - return 0;
> > -
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > @@ -3543,9 +3524,6 @@ static ssize_t store_cursor_blink(struct device
> > *device,
> > int blink, idx;
> > char **last = NULL;
> >
> > - if (fbcon_has_exited)
> > - return count;
> > -
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > @@ -3668,9 +3646,6 @@ static void fbcon_exit(void)
> > struct fb_info *info;
> > int i, j, mapped;
> >
> > - if (fbcon_has_exited)
> > - return;
> > -
> > #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > if (deferred_takeover) {
> > dummycon_unregister_output_notifier(_output_nb);
> > @@ -3695,7 +3670,7 @@ static void fbcon_exit(void)
> > for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > if (con2fb_map[j] == i) {
> > mapped = 1;
> > - break;
> > + con2fb_map[j] = -1;
> > }
> > }
> >
> > @@ -3718,8 +3693,6 @@ static void fbcon_exit(void)
> > info->queue.func = NULL;
> > }
> > }
> > -
> > - fbcon_has_exited = 1;
> > }
> >
> > void __init fb_console_init(void)
> > --
> > 2.20.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
