[Intel-gfx] ✗ Fi.CI.IGT: failure for Refactor to expand subslice mask (rev 2)
== Series Details == Series: Refactor to expand subslice mask (rev 2) URL : https://patchwork.freedesktop.org/series/64858/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6649_full -> Patchwork_13905_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13905_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13905_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_13905_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb8/igt@gem_exec_sched...@preempt-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-iclb2/igt@gem_exec_sched...@preempt-bsd.html Warnings * igt@gem_ctx_isolation@vcs1-nonpriv: - shard-iclb: [SKIP][3] ([fdo#109276]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb8/igt@gem_ctx_isolat...@vcs1-nonpriv.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-iclb2/igt@gem_ctx_isolat...@vcs1-nonpriv.html Known issues Here are the changes found in Patchwork_13905_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +12 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-iclb6/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#110741]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-skl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-apl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@cursora-vs-flipa-atomic: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb5/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-iclb7/igt@kms_cursor_leg...@cursora-vs-flipa-atomic.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-skl5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-skl4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108] / [fdo#106978]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-skl6/igt@kms_frontbuffer_track...@fbcpsr-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-skl8/igt@kms_frontbuffer_track...@fbcpsr-suspend.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-skl5/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103166]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb2/igt@kms_plane_low...@pipe-a-tiling-y.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642] / [fdo#111068]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]:
Re: [Intel-gfx] [PATCH v3 38/41] powerpc: convert put_page() to put_user_page*()
Hi John,
john.hubb...@gmail.com writes:
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index b056cae3388b..e126193ba295 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -203,6 +202,7 @@ static void mm_iommu_unpin(struct
> mm_iommu_table_group_mem_t *mem)
> {
> long i;
> struct page *page = NULL;
> + bool dirty = false;
I don't think you need that initialisation do you?
> if (!mem->hpas)
> return;
> @@ -215,10 +215,9 @@ static void mm_iommu_unpin(struct
> mm_iommu_table_group_mem_t *mem)
> if (!page)
> continue;
>
> - if (mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY)
> - SetPageDirty(page);
> + dirty = mem->hpas[i] & MM_IOMMU_TABLE_GROUP_PAGE_DIRTY;
> - put_page(page);
> + put_user_pages_dirty_lock(, 1, dirty);
> mem->hpas[i] = 0;
> }
> }
cheers
___
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/perf: Refactor oa object to better manage resources (rev6)
== Series Details == Series: drm/i915/perf: Refactor oa object to better manage resources (rev6) URL : https://patchwork.freedesktop.org/series/60176/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6649_full -> Patchwork_13904_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13904_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13904_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_13904_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@gem_pipe_control_store_loop@reused-buffer: - shard-kbl: [PASS][3] -> [DMESG-WARN][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-kbl7/igt@gem_pipe_control_store_l...@reused-buffer.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-kbl4/igt@gem_pipe_control_store_l...@reused-buffer.html Warnings * igt@gem_exec_schedule@deep-bsd: - shard-iclb: [INCOMPLETE][5] ([fdo#107713]) -> [SKIP][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb7/igt@gem_exec_sched...@deep-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-iclb1/igt@gem_exec_sched...@deep-bsd.html * igt@gem_mocs_settings@mocs-settings-bsd2: - shard-iclb: [SKIP][7] ([fdo#109276]) -> [FAIL][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb7/igt@gem_mocs_setti...@mocs-settings-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-iclb4/igt@gem_mocs_setti...@mocs-settings-bsd2.html Known issues Here are the changes found in Patchwork_13904_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-contexts-bsd2: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#109276]) +14 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb2/igt@gem_exec_sched...@preempt-contexts-bsd2.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-iclb8/igt@gem_exec_sched...@preempt-contexts-bsd2.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-apl8/igt@gem_soft...@noreloc-s3.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-apl6/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103665] / [fdo#107807]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-kbl7/igt@i915_pm_...@system-suspend-modeset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-kbl6/igt@i915_pm_...@system-suspend-modeset.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-kbl7/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-kbl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-wc.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-snb: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-snb2/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/shard-snb1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/shard-skl9/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [22]:
Re: [Intel-gfx] [PATCH v6 19/24] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
On Fri, Jul 26, 2019 at 07:23:13PM +0200, Andrzej Pietrasiewicz wrote: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz > Reviewed-by: Neil Armstrong This patch results in a crash when running qemu:versatilepb. Unable to handle kernel NULL pointer dereference at virtual address 00c5 pgd = (ptrval) [00c5] *pgd= Internal error: Oops: 5 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.3.0-rc1+ #1 Hardware name: ARM-Versatile (Device Tree Support) PC is at sysfs_do_create_link_sd+0x38/0xd8 LR is at sysfs_do_create_link_sd+0x38/0xd8 pc : []lr : []psr: a153 sp : c783bd18 ip : fp : c783bde8 r10: c7ef5ea8 r9 : 0001 r8 : c0955dc0 r7 : c73cb5b0 r6 : c73cd800 r5 : 00ad r4 : r3 : c7838ae0 r2 : r1 : 0008 r0 : c0aa2898 Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 00093177 Table: 4000 DAC: 0053 Process swapper (pid: 1, stack limit = 0x(ptrval)) Stack: (0xc783bd18 to 0xc783c000) bd00: c73ccc48 c73ccc74 bd20: c73cd800 c0ac7c88 c729cc80 c7ef5ea8 c04c7fc0 c73ccc48 c0a73068 bd40: c73cd800 c0ac7c88 c04c87e0 0001 c04cefcc c04dc3f8 bd60: c73a9030 c73cd800 c73ccc48 7fc2ce37 c73cd800 c04cefcc bd80: c73cd800 c04b4ebc c0a73068 c7ef5ea8 c783bde8 c049ffcc bda0: c73a9020 c73cd800 c78e6000 c73a9020 c73a9020 c0a73068 c04df2f8 bdc0: c783bde8 c095a76c c73a9020 c0065744 c73ccc20 c73a9020 0001 bde0: c7838ae0 c73ccc20 7fc2ce37 c78e6000 c0ac7c34 be00: c07dc1f8 c0a6b384 c0a59858 c045e8d8 c78e6000 c1173a78 be20: c0ac7c34 c04e77c4 c78e6000 c0ac7c34 c0ac7c34 c0a73068 be40: e000 c0a6b384 c04e7a34 c0ac7c34 c0ac7c34 c0a73068 c78e6000 be60: c0ac7c34 c0a73068 e000 c0a6b384 c0a59858 c04e7cf0 be80: c0ac7c34 c78e6000 c04e7d7c c0ac7c34 c04e7cf8 c04e5928 bea0: c73b2800 c78d88a0 c78dd110 7fc2ce37 e000 c0ac7c34 c73b2800 c0ac16e0 bec0: c04e6b28 c095a73c c0af0a60 c0a73068 c0ac7c34 c0af0a60 c0a73068 bee0: c0a401c4 c04e8968 e000 c0af0a60 c0a73068 c000b3bc 0115 bf00: c7ffce6c c7ffce00 c09e15b0 0115 0115 c0048844 c09e000c c097cfd4 bf20: 0006 0006 c7ffce6c e000 c006954c bf40: e000 7fc2ce37 c0afb000 c0af0a60 0115 c0afb000 0007 c0a59850 bf60: e000 c0a111e8 0006 0006 c0a10678 7fc2ce37 bf80: c07824cc bfa0: c07824d4 c00090b0 bfc0: bfe0: 0013 [] (sysfs_do_create_link_sd) from [] (drm_connector_register.part.1+0x40/0xa0) [] (drm_connector_register.part.1) from [] (drm_connector_register_all+0x90/0xb8) [] (drm_connector_register_all) from [] (drm_modeset_register_all+0x44/0x6c) [] (drm_modeset_register_all) from [] (drm_dev_register+0x15c/0x1c0) [] (drm_dev_register) from [] (pl111_amba_probe+0x2e0/0x4ac) [] (pl111_amba_probe) from [] (amba_probe+0x9c/0x118) [] (amba_probe) from [] (really_probe+0x1c0/0x2bc) [] (really_probe) from [] (driver_probe_device+0x5c/0x170) [] (driver_probe_device) from [] (device_driver_attach+0x58/0x60) [] (device_driver_attach) from [] (__driver_attach+0x84/0xc0) [] (__driver_attach) from [] (bus_for_each_dev+0x70/0xb4) [] (bus_for_each_dev) from [] (bus_add_driver+0x154/0x1e0) [] (bus_add_driver) from [] (driver_register+0x74/0x108) [] (driver_register) from [] (do_one_initcall+0x84/0x2e4) [] (do_one_initcall) from [] (kernel_init_freeable+0x2bc/0x394) [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [] (kernel_init) from [] (ret_from_fork+0x14/0x24) Exception stack(0xc783bfb0 to 0xc783bff8) bfa0: bfc0: bfe0: 0013 Code: e59f00a0 e1a09003 e1a08002 eb176e54 (e5955018) ---[ end trace f503b374936886c5 ]--- Bisect log attached. Guenter --- # bad: [3880be629e26f6c407593602398c6651860d5fae] Add linux-next specific files for 20190807 # good: [e21a712a9685488f5ce80495b37b9fdbe96c230d] Linux 5.3-rc3 git bisect start 'HEAD' 'v5.3-rc3' # good: [83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa] Merge remote-tracking branch 'crypto/master' git bisect good 83d74da9e6d2ca78b32e9e794c6bcbd433d5efaa # bad: [3add021bff629f1792a5e4268afe13b3047b5523] Merge remote-tracking branch 'sound/for-next' git bisect bad 3add021bff629f1792a5e4268afe13b3047b5523 # good: [4ef58ee18a654b1992d00281501d6eff051a0c5e] Merge remote-tracking branch 'amd
Re: [Intel-gfx] [PATCH 00/34] put_user_pages(): miscellaneous call sites
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> > On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > > > > > On Thu 01-08-19 19:19:31, john.hubb...@gmail.com wrote:
> > > > > > > [...]
> > > > > > > > 2) Convert all of the call sites for get_user_pages*(), to
> > > > > > > > invoke put_user_page*(), instead of put_page(). This involves
> > > > > > > > dozens of
> > > > > > > > call sites, and will take some time.
> > > > > > >
> > > > > > > How do we make sure this is the case and it will remain the case
> > > > > > > in the
> > > > > > > future? There must be some automagic to enforce/check that. It is
> > > > > > > simply
> > > > > > > not manageable to do it every now and then because then 3) will
> > > > > > > simply
> > > > > > > be never safe.
> > > > > > >
> > > > > > > Have you considered coccinele or some other scripted way to do the
> > > > > > > transition? I have no idea how to deal with future changes that
> > > > > > > would
> > > > > > > break the balance though.
> > >
> > > Hi Michal,
> > >
> > > Yes, I've thought about it, and coccinelle falls a bit short (it's not
> > > smart
> > > enough to know which put_page()'s to convert). However, there is a debug
> > > option planned: a yet-to-be-posted commit [1] uses struct page extensions
> > > (obviously protected by CONFIG_DEBUG_GET_USER_PAGES_REFERENCES) to add
> > > a redundant counter. That allows:
> > >
> > > void __put_page(struct page *page)
> > > {
> > > ...
> > > /* Someone called put_page() instead of put_user_page() */
> > > WARN_ON_ONCE(atomic_read(_ext->pin_count) > 0);
> > >
> > > > > >
> > > > > > Yeah, that's why I've been suggesting at LSF/MM that we may need to
> > > > > > create
> > > > > > a gup wrapper - say vaddr_pin_pages() - and track which sites
> > > > > > dropping
> > > > > > references got converted by using this wrapper instead of gup. The
> > > > > > counterpart would then be more logically named as unpin_page() or
> > > > > > whatever
> > > > > > instead of put_user_page(). Sure this is not completely foolproof
> > > > > > (you can
> > > > > > create new callsite using vaddr_pin_pages() and then just drop refs
> > > > > > using
> > > > > > put_page()) but I suppose it would be a high enough barrier for
> > > > > > missed
> > > > > > conversions... Thoughts?
> > >
> > > The debug option above is still a bit simplistic in its implementation
> > > (and maybe not taking full advantage of the data it has), but I think
> > > it's preferable, because it monitors the "core" and WARNs.
> > >
> > > Instead of the wrapper, I'm thinking: documentation and the passage of
> > > time, plus the debug option (perhaps enhanced--probably once I post it
> > > someone will notice opportunities), yes?
> >
> > So I think your debug option and my suggested renaming serve a bit
> > different purposes (and thus both make sense). If you do the renaming, you
> > can just grep to see unconverted sites. Also when someone merges new GUP
> > user (unaware of the new rules) while you switch GUP to use pins instead of
> > ordinary references, you'll get compilation error in case of renaming
> > instead of hard to debug refcount leak without the renaming. And such
> > conflict is almost bound to happen given the size of GUP patch set... Also
> > the renaming serves against the "coding inertia" - i.e., GUP is around for
> > ages so people just use it without checking any documentation or comments.
> > After switching how GUP works, what used to be correct isn't anymore so
> > renaming the function serves as a warning that something has really
> > changed.
>
> Fully agreed!
Ok Prior to this I've been basing all my work for the RDMA/FS DAX stuff in
Johns put_user_pages()... (Including when I proposed failing truncate with a
lease in June [1])
However, based on the suggestions in that thread it became clear that a new
interface was going to need to be added to pass in the "RDMA file" information
to GUP to associate file pins with the correct processes...
I have many drawings on my white board with "a whole lot of lines" on them to
make sure that if a process opens a file, mmaps it, pins it with RDMA, _closes_
it, and ummaps it; that the resulting file pin can still be traced back to the
RDMA context and all the processes which may have access to it No matter
where the original context may have come from. I believe I have accomplished
that.
Before I go on, I would like to say that the "imbalance" of get_user_pages()
and put_page() bothers me from a purist standpoint... However, since this
discussion cropped up I went ahead and ported my work to Linus' current master
(5.3-rc3+) and in doing so I only had to steal a bit of Johns
[Intel-gfx] ✓ Fi.CI.BAT: success for Display uncore (rev3)
== Series Details ==
Series: Display uncore (rev3)
URL : https://patchwork.freedesktop.org/series/61735/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6652 -> Patchwork_13910
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/
Known issues
Here are the changes found in Patchwork_13910 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload-no-display:
- fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] ([k.org#202361])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-bwr-2160/igt@i915_module_l...@reload-no-display.html
* igt@prime_vgem@basic-wait-default:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-u3/igt@prime_v...@basic-wait-default.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-icl-u3/igt@prime_v...@basic-wait-default.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload-no-display:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6700k2: [INCOMPLETE][9] ([fdo#107807]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- {fi-icl-guc}: [INCOMPLETE][11] ([fdo#107713]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-guc/igt@i915_selftest@live_execlists.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-icl-guc/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [WARN][13] ([fdo#109380]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][15] ([fdo#109483]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [SKIP][17] ([fdo#109271]) -> [PASS][18] +23 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13910/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109380]: https://bugs.freedesktop.org/show_bug.cgi?id=109380
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[k.org#202361]: https://bugzilla.kernel.org/show_bug.cgi?id=202361
Participating hosts (55 -> 47)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6652 -> Patchwork_13910
CI-20190529: 20190529
CI_DRM_6652:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Display uncore (rev3)
== Series Details == Series: Display uncore (rev3) URL : https://patchwork.freedesktop.org/series/61735/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: split out uncore_mmio_debug +drivers/gpu/drm/i915/intel_uncore.c:1231:1: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1231:1: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1231:1: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1231:1: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1232:1: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1232:1: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1232:1: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1232:1: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1233:1: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1233:1: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1233:1: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1233:1: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1296:1: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1297:1: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1298:1: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1322:1: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1322:1: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1322:1: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1323:1: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1323:1: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1323:1: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1324:1: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1324:1: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +drivers/gpu/drm/i915/intel_uncore.c:1324:1: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block Commit: drm/i915: introduce display_uncore Okay! Commit: drm/i915: convert a couple of registers to _DE_MMIO Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Display uncore (rev3)
== Series Details ==
Series: Display uncore (rev3)
URL : https://patchwork.freedesktop.org/series/61735/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a5d4c467f066 drm/i915: split out uncore_mmio_debug
b11140f433d2 drm/i915: introduce display_uncore
-:21: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#21:
new file mode 100644
-:36: WARNING:NEW_TYPEDEFS: do not add new typedefs
#36: FILE: drivers/gpu/drm/i915/display/intel_display_reg.h:11:
+typedef struct {
total: 0 errors, 2 warnings, 0 checks, 169 lines checked
3dcca3c2b243 drm/i915: convert a couple of registers to _DE_MMIO
-:22: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#22: FILE: drivers/gpu/drm/i915/display/intel_display_reg.h:26:
+ * of the infoframe structure specified by CEA-861. */
total: 0 errors, 1 warnings, 0 checks, 189 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/3] drm/i915: convert a couple of registers to _DE_MMIO
As an example of usage of the new accessors
Signed-off-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/display/intel_display_reg.h | 44 +++
drivers/gpu/drm/i915/display/intel_hdmi.c | 32 +++---
drivers/gpu/drm/i915/i915_reg.h | 44 ---
3 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_reg.h
b/drivers/gpu/drm/i915/display/intel_display_reg.h
index ac0c6975271d..2b61d4fd12e3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_reg.h
+++ b/drivers/gpu/drm/i915/display/intel_display_reg.h
@@ -19,4 +19,48 @@ static inline i915_reg_t intel_de_reg_to_mmio(intel_de_reg_t
reg)
return reg.reg;
}
+/* Video Data Island Packet control */
+#define VIDEO_DIP_DATA _DE_MMIO(0x61178)
+/* Read the description of VIDEO_DIP_DATA (before Haswell) or VIDEO_DIP_ECC
+ * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
byte
+ * of the infoframe structure specified by CEA-861. */
+#define VIDEO_DIP_DATA_SIZE 32
+#define VIDEO_DIP_VSC_DATA_SIZE 36
+#define VIDEO_DIP_PPS_DATA_SIZE 132
+#define VIDEO_DIP_CTL _DE_MMIO(0x61170)
+/* Pre HSW: */
+#define VIDEO_DIP_ENABLE (1 << 31)
+#define VIDEO_DIP_PORT(port) ((port) << 29)
+#define VIDEO_DIP_PORT_MASK (3 << 29)
+#define VIDEO_DIP_ENABLE_GCP (1 << 25) /* ilk+ */
+#define VIDEO_DIP_ENABLE_AVI (1 << 21)
+#define VIDEO_DIP_ENABLE_VENDOR (2 << 21)
+#define VIDEO_DIP_ENABLE_GAMUT (4 << 21) /* ilk+ */
+#define VIDEO_DIP_ENABLE_SPD (8 << 21)
+#define VIDEO_DIP_SELECT_AVI (0 << 19)
+#define VIDEO_DIP_SELECT_VENDOR (1 << 19)
+#define VIDEO_DIP_SELECT_GAMUT (2 << 19)
+#define VIDEO_DIP_SELECT_SPD (3 << 19)
+#define VIDEO_DIP_SELECT_MASK(3 << 19)
+#define VIDEO_DIP_FREQ_ONCE (0 << 16)
+#define VIDEO_DIP_FREQ_VSYNC (1 << 16)
+#define VIDEO_DIP_FREQ_2VSYNC(2 << 16)
+#define VIDEO_DIP_FREQ_MASK (3 << 16)
+/* HSW and later: */
+#define VIDEO_DIP_ENABLE_DRM_GLK (1 << 28)
+#define PSR_VSC_BIT_7_SET(1 << 27)
+#define VSC_SELECT_MASK (0x3 << 25)
+#define VSC_SELECT_SHIFT 25
+#define VSC_DIP_HW_HEA_DATA (0 << 25)
+#define VSC_DIP_HW_HEA_SW_DATA (1 << 25)
+#define VSC_DIP_HW_DATA_SW_HEA (2 << 25)
+#define VSC_DIP_SW_HEA_DATA (3 << 25)
+#define VDIP_ENABLE_PPS (1 << 24)
+#define VIDEO_DIP_ENABLE_VSC_HSW (1 << 20)
+#define VIDEO_DIP_ENABLE_GCP_HSW (1 << 16)
+#define VIDEO_DIP_ENABLE_AVI_HSW (1 << 12)
+#define VIDEO_DIP_ENABLE_VS_HSW (1 << 8)
+#define VIDEO_DIP_ENABLE_GMP_HSW (1 << 4)
+#define VIDEO_DIP_ENABLE_SPD_HSW (1 << 0)
+
#endif
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index b1ca8e5bdb56..64666d9dfb49 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -208,7 +208,7 @@ static void g4x_write_infoframe(struct intel_encoder
*encoder,
{
const u32 *data = frame;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u32 val = I915_READ(VIDEO_DIP_CTL);
+ u32 val = intel_de_read(dev_priv, VIDEO_DIP_CTL);
int i;
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
@@ -218,22 +218,22 @@ static void g4x_write_infoframe(struct intel_encoder
*encoder,
val &= ~g4x_infoframe_enable(type);
- I915_WRITE(VIDEO_DIP_CTL, val);
+ intel_de_write(dev_priv, VIDEO_DIP_CTL, val);
for (i = 0; i < len; i += 4) {
- I915_WRITE(VIDEO_DIP_DATA, *data);
+ intel_de_write(dev_priv, VIDEO_DIP_DATA, *data);
data++;
}
/* Write every possible data byte to force correct ECC calculation. */
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
- I915_WRITE(VIDEO_DIP_DATA, 0);
+ intel_de_write(dev_priv, VIDEO_DIP_DATA, 0);
val |= g4x_infoframe_enable(type);
val &= ~VIDEO_DIP_FREQ_MASK;
val |= VIDEO_DIP_FREQ_VSYNC;
- I915_WRITE(VIDEO_DIP_CTL, val);
- POSTING_READ(VIDEO_DIP_CTL);
+ intel_de_write(dev_priv, VIDEO_DIP_CTL, val);
+ intel_de_posting_read(dev_priv, VIDEO_DIP_CTL);
}
static void g4x_read_infoframe(struct intel_encoder *encoder,
@@ -245,22 +245,22 @@ static void g4x_read_infoframe(struct intel_encoder
*encoder,
u32 val, *data = frame;
int i;
- val = I915_READ(VIDEO_DIP_CTL);
+ val = intel_de_read(dev_priv, VIDEO_DIP_CTL);
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
val |= g4x_infoframe_index(type);
- I915_WRITE(VIDEO_DIP_CTL, val);
+ intel_de_write(dev_priv, VIDEO_DIP_CTL, val);
[Intel-gfx] [RFC 2/3] drm/i915: introduce display_uncore
A forcewake-less uncore to be used to decouple GT accesses from display
ones to avoid serializing them when there is no need.
New accessors that implicitly use the new uncore have also been added.
To avoid accessing the same register from 2 different uncores (which
could cause hard hangs), the new accessors expect registers to be
defined with the new _DE_MMIO macro.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_display_reg.h | 22 +
drivers/gpu/drm/i915/i915_drv.c | 17 --
drivers/gpu/drm/i915/i915_drv.h | 31 +++
drivers/gpu/drm/i915/intel_uncore.c | 9 +-
4 files changed, 76 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_display_reg.h
diff --git a/drivers/gpu/drm/i915/display/intel_display_reg.h
b/drivers/gpu/drm/i915/display/intel_display_reg.h
new file mode 100644
index ..ac0c6975271d
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_display_reg.h
@@ -0,0 +1,22 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef _INTEL_DISPLAY_REG_H_
+#define _INTEL_DISPLAY_REG_H_
+
+#include "i915_reg.h"
+
+typedef struct {
+ const i915_reg_t reg;
+} intel_de_reg_t;
+
+#define _DE_MMIO(r) ((const intel_de_reg_t){ .reg = _MMIO(r) })
+
+static inline i915_reg_t intel_de_reg_to_mmio(intel_de_reg_t reg)
+{
+ return reg.reg;
+}
+
+#endif
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fbbff4a133ba..af015ecf3dcc 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -746,6 +746,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
intel_uncore_init_early(_priv->uncore, dev_priv);
+ intel_uncore_init_early(_priv->de_uncore, dev_priv);
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->gpu_error.lock);
@@ -841,6 +842,10 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
goto err_bridge;
+ ret = intel_uncore_init_mmio(_priv->de_uncore);
+ if (ret < 0)
+ goto err_uncore;
+
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
@@ -852,14 +857,16 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
ret = intel_engines_init_mmio(dev_priv);
if (ret)
- goto err_uncore;
+ goto err_mchbar;
i915_gem_init_mmio(dev_priv);
return 0;
-err_uncore:
+err_mchbar:
intel_teardown_mchbar(dev_priv);
+ intel_uncore_fini_mmio(_priv->de_uncore);
+err_uncore:
intel_uncore_fini_mmio(_priv->uncore);
err_bridge:
pci_dev_put(dev_priv->bridge_dev);
@@ -875,6 +882,7 @@ static void i915_driver_mmio_release(struct
drm_i915_private *dev_priv)
{
intel_engines_cleanup(dev_priv);
intel_teardown_mchbar(dev_priv);
+ intel_uncore_fini_mmio(_priv->de_uncore);
intel_uncore_fini_mmio(_priv->uncore);
pci_dev_put(dev_priv->bridge_dev);
}
@@ -2010,6 +2018,7 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
i915_gem_suspend_late(dev_priv);
+ intel_uncore_suspend(_priv->de_uncore);
intel_uncore_suspend(_priv->uncore);
intel_power_domains_suspend(dev_priv,
@@ -2199,6 +2208,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
ret);
intel_uncore_resume_early(_priv->uncore);
+ intel_uncore_resume_early(_priv->de_uncore);
intel_gt_check_and_clear_faults(_priv->gt);
@@ -2764,6 +2774,7 @@ static int intel_runtime_suspend(struct device *kdev)
intel_runtime_pm_disable_interrupts(dev_priv);
+ intel_uncore_suspend(_priv->de_uncore);
intel_uncore_suspend(_priv->uncore);
intel_display_power_suspend(dev_priv);
@@ -2774,6 +2785,7 @@ static int intel_runtime_suspend(struct device *kdev)
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_uncore_runtime_resume(_priv->uncore);
+ intel_uncore_runtime_resume(_priv->de_uncore);
intel_runtime_pm_enable_interrupts(dev_priv);
@@ -2851,6 +2863,7 @@ static int intel_runtime_resume(struct device *kdev)
ret = vlv_resume_prepare(dev_priv, true);
intel_uncore_runtime_resume(_priv->uncore);
+ intel_uncore_runtime_resume(_priv->de_uncore);
intel_runtime_pm_enable_interrupts(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 13c27a75dca8..015b490c14d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -66,6 +66,7 @@
#include "display/intel_bios.h"
[Intel-gfx] [RFC 1/3] drm/i915: split out uncore_mmio_debug
Multiple uncore structures will share the debug infrastructure, so
move it to a common place and add extra locking around it.
Also, since we now have a separate object, it is cleaner to have
dedicated functions working on the object to stop and restart the
mmio debug. Apart from the cosmetic changes, this patch introduces
2 functional updates:
- All calls to check_for_unclaimed_mmio will now return false when
the debug is suspended, not just the ones that are active only when
i915_modparams.mmio_debug is set. If we don't trust the result of the
check while a user is doing mmio access then we shouldn't attempt the
check anywhere.
- i915_modparams.mmio_debug is not save/restored anymore around user
access. The value is now never touched by the kernel while debug is
disabled so no need for save/restore.
v2: squash mmio_debug patches, restrict mmio_debug lock usage (Chris)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_uncore.c | 91 -
drivers/gpu/drm/i915/intel_uncore.h | 18 +++---
5 files changed, 79 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3b15266c54fd..2310512111ab 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1129,7 +1129,7 @@ static int i915_forcewake_domains(struct seq_file *m,
void *data)
unsigned int tmp;
seq_printf(m, "user.bypass_count = %u\n",
- uncore->user_forcewake.count);
+ uncore->user_forcewake_count);
for_each_fw_domain(fw_domain, uncore, tmp)
seq_printf(m, "%s.wake_count = %u\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3480db36b63f..fbbff4a133ba 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -744,6 +744,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_device_info_subplatform_init(dev_priv);
+ intel_uncore_mmio_debug_init_early(_priv->mmio_debug);
intel_uncore_init_early(_priv->uncore, dev_priv);
spin_lock_init(_priv->irq_lock);
@@ -2044,7 +2045,7 @@ static int i915_drm_suspend_late(struct drm_device *dev,
bool hibernation)
out:
enable_rpm_wakeref_asserts(rpm);
- if (!dev_priv->uncore.user_forcewake.count)
+ if (!dev_priv->uncore.user_forcewake_count)
intel_runtime_pm_driver_release(rpm);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9476f24f5c1..13c27a75dca8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1346,6 +1346,7 @@ struct drm_i915_private {
resource_size_t stolen_usable_size; /* Total size minus reserved
ranges */
struct intel_uncore uncore;
+ struct intel_uncore_mmio_debug mmio_debug;
struct i915_virtual_gpu vgpu;
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 39e8710afdd9..9e583f13a9e4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -34,6 +34,32 @@
#define __raw_posting_read(...) ((void)__raw_uncore_read32(__VA_ARGS__))
+void
+intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug)
+{
+ spin_lock_init(_debug->lock);
+ mmio_debug->unclaimed_mmio_check = 1;
+}
+
+static void mmio_debug_suspend(struct intel_uncore_mmio_debug *mmio_debug)
+{
+ lockdep_assert_held(_debug->lock);
+
+ /* Save and disable mmio debugging for the user bypass */
+ if (!mmio_debug->suspend_count++) {
+ mmio_debug->saved_mmio_check = mmio_debug->unclaimed_mmio_check;
+ mmio_debug->unclaimed_mmio_check = 0;
+ }
+}
+
+static void mmio_debug_resume(struct intel_uncore_mmio_debug *mmio_debug)
+{
+ lockdep_assert_held(_debug->lock);
+
+ if (!--mmio_debug->suspend_count)
+ mmio_debug->unclaimed_mmio_check = mmio_debug->saved_mmio_check;
+}
+
static const char * const forcewake_domain_names[] = {
"render",
"blitter",
@@ -476,6 +502,11 @@ check_for_unclaimed_mmio(struct intel_uncore *uncore)
{
bool ret = false;
+ lockdep_assert_held(>debug->lock);
+
+ if (uncore->debug->suspend_count)
+ return false;
+
if (intel_uncore_has_fpga_dbg_unclaimed(uncore))
ret |= fpga_check_for_unclaimed_mmio(uncore);
@@ -608,17 +639,11 @@ void intel_uncore_forcewake_get(struct intel_uncore
*uncore,
void intel_uncore_forcewake_user_get(struct intel_uncore *uncore)
{
spin_lock_irq(>lock);
- if (!uncore->user_forcewake.count++) {
+ if (!uncore->user_forcewake_count++) {
[Intel-gfx] [RFC 0/3] Display uncore
I've been trying to identify MMIO ranges to clearly define what belongs to display_uncore to do a check on access, but there are lots of exceptions and differences across gens (with a few more coming with TGL), so I don't think that's a viable way. The alternative option implemented here is to differentiate the register by type, which should ensure we never mix them up, but at the cost of a more complex transition. Thoughts? I'm very open to (and I actually hope for) better ideas. Cc: Ville Syrjälä Cc: Chris Wilson Cc: Jani Nikula Cc: Lucas De Marchi Daniele Ceraolo Spurio (3): drm/i915: split out uncore_mmio_debug drm/i915: introduce display_uncore drm/i915: convert a couple of registers to _DE_MMIO .../gpu/drm/i915/display/intel_display_reg.h | 66 drivers/gpu/drm/i915/display/intel_hdmi.c | 32 +++--- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 20 +++- drivers/gpu/drm/i915/i915_drv.h | 32 ++ drivers/gpu/drm/i915/i915_reg.h | 44 drivers/gpu/drm/i915/intel_uncore.c | 100 +- drivers/gpu/drm/i915/intel_uncore.h | 18 ++-- 8 files changed, 215 insertions(+), 99 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_display_reg.h -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote: > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: > > Though personally I'm averse to managing "f"objects through > > "m"interfaces, which can get ridiculous (notably, MADV_HUGEPAGE works > > on the virtual address of a mapping, but the huge-or-not alignment of > > that mapping must have been decided previously). In Google we do use > > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis - > > one day I'll get to upstreaming those. > > Such an interface seems very useful, although the two fcntls seem a bit > odd. > > But I think the point here is that the i915 has its own somewhat odd > instance of tmpfs. If we could pass the equivalent of the huge=* > options to shmem_file_setup all that garbage (including the > shmem_file_setup_with_mnt function) could go away. ... or follow shmem_file_super() with whatever that fcntl maps to internally. I would really love to get rid of that i915 kludge. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote: > that mapping must have been decided previously). In Google we do use > fcntls F_HUGEPAGE and F_NOHUGEPAGE to override on a per-file basis - > one day I'll get to upstreaming those. That'd be nice - we could kill the i915 wierd private shmem instance, along with some kludges in mm/shmem.c. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915: Get transcoder power domain before reading its register
== Series Details ==
Series: series starting with [v4,1/2] drm/i915: Get transcoder power domain
before reading its register
URL : https://patchwork.freedesktop.org/series/64877/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6652 -> Patchwork_13909
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/
Known issues
Here are the changes found in Patchwork_13909 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_cpu_reloc@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-u3/igt@gem_cpu_re...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-icl-u3/igt@gem_cpu_re...@basic.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#109483])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-kbl-7500u/igt@kms_chamel...@hdmi-edid-read.html
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: [PASS][5] -> [DMESG-WARN][6] ([fdo#106387]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-ilk-650/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload-no-display:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +2
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6700k2: [INCOMPLETE][11] ([fdo#107807]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-skl-6700k2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- {fi-icl-guc}: [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-guc/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-icl-guc/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [WARN][15] ([fdo#109380]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][17] ([fdo#109483]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [SKIP][19] ([fdo#109271]) -> [PASS][20] +23 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6652/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13909/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/vlv: allocate Gunit s0ix state on demand
== Series Details == Series: drm/i915/vlv: allocate Gunit s0ix state on demand URL : https://patchwork.freedesktop.org/series/64844/ State : success == Summary == CI Bug Log - changes from CI_DRM_6648_full -> Patchwork_13902_full Summary --- **WARNING** Minor unknown changes coming with Patchwork_13902_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13902_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_13902_full: ### IGT changes ### Warnings * igt@gem_mocs_settings@mocs-reset-bsd2: - shard-iclb: [SKIP][1] ([fdo#109276]) -> [FAIL][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-iclb7/igt@gem_mocs_setti...@mocs-reset-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-iclb1/igt@gem_mocs_setti...@mocs-reset-bsd2.html Known issues Here are the changes found in Patchwork_13902_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108] / [fdo#107807]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-skl9/igt@i915_pm_...@system-suspend-execbuf.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-skl2/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-iclb3/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-iclb7/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#109507]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-skl1/igt@kms_f...@flip-vs-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-skl4/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-snb: [PASS][9] -> [INCOMPLETE][10] ([fdo#105411]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-snb6/igt@kms_f...@flip-vs-suspend-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-snb1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +7 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108566]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-apl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-kbl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [fdo#110403]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276])
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/tgl: Fix the read of the DDI that transcoder is attached to
On Wed, Aug 07, 2019 at 05:49:35PM -0700, Jose Souza wrote:
On TGL this register do not map directly to port, it was already
handled when setting it(TGL_TRANS_DDI_SELECT_PORT()) but not when
reading it.
To make it consisntent adding a macro for the older gens too.
v2:
Adding TGL_PORT_TRANS_DDI_SELECT() so all future users can reuse it
(Lucas)
v3:
Missed parentheses arround val (Jose)
v4:
Renamed TGL_PORT_TRANS_DDI_SELECT to TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT
(Lucas)
Added TRANS_DDI_FUNC_CTL_VAL_TO_PORT (Lucas)
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 5 ++---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 935aec7660af..0a31d9113699 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10354,10 +10354,9 @@ static void haswell_get_ddi_port_state(struct
intel_crtc *crtc,
tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe_config->cpu_transcoder));
if (INTEL_GEN(dev_priv) >= 12)
- port = (tmp & TGL_TRANS_DDI_PORT_MASK) >>
- TGL_TRANS_DDI_PORT_SHIFT;
+ port = TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
else
- port = (tmp & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT;
+ port = TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
if (INTEL_GEN(dev_priv) >= 11)
icelake_get_ddi_pll(dev_priv, port, pipe_config);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d760830cfd7b..3d1c30a82302 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9432,6 +9432,8 @@ enum skl_power_gate {
#define TGL_TRANS_DDI_PORT_MASK(0xf << TGL_TRANS_DDI_PORT_SHIFT)
#define TRANS_DDI_SELECT_PORT(x) ((x) << TRANS_DDI_PORT_SHIFT)
#define TGL_TRANS_DDI_SELECT_PORT(x) (((x) + 1) << TGL_TRANS_DDI_PORT_SHIFT)
+#define TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val)(((val) & TRANS_DDI_PORT_MASK)
>> TRANS_DDI_PORT_SHIFT)
+#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) (((val) & TGL_TRANS_DDI_PORT_MASK
>> TGL_TRANS_DDI_PORT_SHIFT) - 1)
#define TRANS_DDI_MODE_SELECT_MASK (7 << 24)
#define TRANS_DDI_MODE_SELECT_HDMI (0 << 24)
#define TRANS_DDI_MODE_SELECT_DVI (1 << 24)
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915: Get transcoder power domain before reading its register
== Series Details == Series: series starting with [v4,1/2] drm/i915: Get transcoder power domain before reading its register URL : https://patchwork.freedesktop.org/series/64877/ State : warning == Summary == $ dim checkpatch origin/drm-tip d586d972be03 drm/i915: Get transcoder power domain before reading its register -:44: WARNING:LONG_LINE: line over 100 characters #44: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:2021: + POWER_DOMAIN_TRANSCODER(cpu_transcoder)); total: 0 errors, 1 warnings, 0 checks, 20 lines checked 0cb08a8b0ffc drm/i915/tgl: Fix the read of the DDI that transcoder is attached to -:56: WARNING:LONG_LINE: line over 100 characters #56: FILE: drivers/gpu/drm/i915/i915_reg.h:9435: +#define TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val)(((val) & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT) -:57: WARNING:LONG_LINE: line over 100 characters #57: FILE: drivers/gpu/drm/i915/i915_reg.h:9436: +#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) (((val) & TGL_TRANS_DDI_PORT_MASK >> TGL_TRANS_DDI_PORT_SHIFT) - 1) total: 0 errors, 2 warnings, 0 checks, 20 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/2] drm/i915: Get transcoder power domain before reading its register
When getting the pipes attached to encoder if it is not a eDP encoder
it iterates over all pipes and read a transcoder register.
But it should not read a transcoder register before get its power
domain.
It was not a issue in gens older than 12 because if it only had
port A connected it would be attached to EDP and it would skip all
the transcoders readout, if it had more than one port connected,
pipe B would cause PG3 to be on and it contains all other
transcoders.
But on gen 12 there is no EDP transcoder so it is always iterating
over all pipes and if only one sink is connected, PG3 is kept off
and reading other transcoders registers would cause a
unclaimed read warning.
So here getting the power domain of the transcoder only if it is
enabled, otherwise it is not connected to the DDI.
Reviewed-by: Lucas De Marchi
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index aa5b2440513c..647ba5140656 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2015,6 +2015,12 @@ static void intel_ddi_get_encoder_pipes(struct
intel_encoder *encoder,
for_each_pipe(dev_priv, p) {
enum transcoder cpu_transcoder = (enum transcoder)p;
unsigned int port_mask, ddi_select;
+ intel_wakeref_t trans_wakeref;
+
+ trans_wakeref = intel_display_power_get_if_enabled(dev_priv,
+
POWER_DOMAIN_TRANSCODER(cpu_transcoder));
+ if (!trans_wakeref)
+ continue;
if (INTEL_GEN(dev_priv) >= 12) {
port_mask = TGL_TRANS_DDI_PORT_MASK;
@@ -2025,6 +2031,8 @@ static void intel_ddi_get_encoder_pipes(struct
intel_encoder *encoder,
}
tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
+ intel_display_power_put(dev_priv,
POWER_DOMAIN_TRANSCODER(cpu_transcoder),
+ trans_wakeref);
if ((tmp & port_mask) != ddi_select)
continue;
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/2] drm/i915/tgl: Fix the read of the DDI that transcoder is attached to
On TGL this register do not map directly to port, it was already
handled when setting it(TGL_TRANS_DDI_SELECT_PORT()) but not when
reading it.
To make it consisntent adding a macro for the older gens too.
v2:
Adding TGL_PORT_TRANS_DDI_SELECT() so all future users can reuse it
(Lucas)
v3:
Missed parentheses arround val (Jose)
v4:
Renamed TGL_PORT_TRANS_DDI_SELECT to TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT
(Lucas)
Added TRANS_DDI_FUNC_CTL_VAL_TO_PORT (Lucas)
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 5 ++---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 935aec7660af..0a31d9113699 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10354,10 +10354,9 @@ static void haswell_get_ddi_port_state(struct
intel_crtc *crtc,
tmp = I915_READ(TRANS_DDI_FUNC_CTL(pipe_config->cpu_transcoder));
if (INTEL_GEN(dev_priv) >= 12)
- port = (tmp & TGL_TRANS_DDI_PORT_MASK) >>
- TGL_TRANS_DDI_PORT_SHIFT;
+ port = TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
else
- port = (tmp & TRANS_DDI_PORT_MASK) >> TRANS_DDI_PORT_SHIFT;
+ port = TRANS_DDI_FUNC_CTL_VAL_TO_PORT(tmp);
if (INTEL_GEN(dev_priv) >= 11)
icelake_get_ddi_pll(dev_priv, port, pipe_config);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d760830cfd7b..3d1c30a82302 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9432,6 +9432,8 @@ enum skl_power_gate {
#define TGL_TRANS_DDI_PORT_MASK (0xf << TGL_TRANS_DDI_PORT_SHIFT)
#define TRANS_DDI_SELECT_PORT(x) ((x) << TRANS_DDI_PORT_SHIFT)
#define TGL_TRANS_DDI_SELECT_PORT(x) (((x) + 1) << TGL_TRANS_DDI_PORT_SHIFT)
+#define TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val)(((val) & TRANS_DDI_PORT_MASK)
>> TRANS_DDI_PORT_SHIFT)
+#define TGL_TRANS_DDI_FUNC_CTL_VAL_TO_PORT(val) (((val) &
TGL_TRANS_DDI_PORT_MASK >> TGL_TRANS_DDI_PORT_SHIFT) - 1)
#define TRANS_DDI_MODE_SELECT_MASK(7 << 24)
#define TRANS_DDI_MODE_SELECT_HDMI(0 << 24)
#define TRANS_DDI_MODE_SELECT_DVI (1 << 24)
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Isolate i915_getparam_ioctl()
== Series Details == Series: drm/i915: Isolate i915_getparam_ioctl() URL : https://patchwork.freedesktop.org/series/64840/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6648_full -> Patchwork_13901_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13901_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13901_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_13901_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@preempt-queue-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-iclb5/igt@gem_exec_sched...@preempt-queue-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-iclb4/igt@gem_exec_sched...@preempt-queue-bsd.html * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-kbl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-kbl2/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-kbl1/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html Warnings * igt@gem_mocs_settings@mocs-settings-bsd2: - shard-iclb: [SKIP][5] ([fdo#109276]) -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-iclb5/igt@gem_mocs_setti...@mocs-settings-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-iclb4/igt@gem_mocs_setti...@mocs-settings-bsd2.html Known issues Here are the changes found in Patchwork_13901_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@i2c: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#104097]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-hsw4/igt@i915_pm_...@i2c.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-hsw6/igt@i915_pm_...@i2c.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108] / [fdo#107807]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-skl10/igt@i915_pm_...@system-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-skl4/igt@i915_pm_...@system-suspend.html * igt@i915_pm_rps@reset: - shard-kbl: [PASS][11] -> [FAIL][12] ([fdo#102250]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-kbl2/igt@i915_pm_...@reset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-kbl1/igt@i915_pm_...@reset.html - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#102250]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-glk7/igt@i915_pm_...@reset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-glk8/igt@i915_pm_...@reset.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-apl3/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-onscreen: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-iclb3/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-iclb7/igt@kms_cursor_...@pipe-a-cursor-256x85-onscreen.html * igt@kms_cursor_legacy@pipe-c-forked-move: - shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([fdo#103540]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-hsw6/igt@kms_cursor_leg...@pipe-c-forked-move.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-hsw4/igt@kms_cursor_leg...@pipe-c-forked-move.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#105363]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/shard-skl2/igt@kms_f...@flip-vs-expired-vblank.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#109507]) [23]:
Re: [Intel-gfx] [PATCH] drm/i915: Flush any deferred RCU cleanup before switching off GEM
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v5.3-rc3 next-20190807]
[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/Chris-Wilson/drm-i915-Flush-any-deferred-RCU-cleanup-before-switching-off-GEM/20190802-232023
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_init':
>> drivers/gpu/drm/i915/i915_gem.c:1606:28: error: 'struct drm_i915_private'
>> has no member named 'rq'; did you mean 'wq'?
flush_workqueue(dev_priv->rq);
^~
wq
vim +1606 drivers/gpu/drm/i915/i915_gem.c
1425
1426 int i915_gem_init(struct drm_i915_private *dev_priv)
1427 {
1428 int ret;
1429
1430 /* We need to fallback to 4K pages if host doesn't support huge
gtt. */
1431 if (intel_vgpu_active(dev_priv) &&
!intel_vgpu_has_huge_gtt(dev_priv))
1432 mkwrite_device_info(dev_priv)->page_sizes =
1433 I915_GTT_PAGE_SIZE_4K;
1434
1435 dev_priv->mm.unordered_timeline = dma_fence_context_alloc(1);
1436
1437 intel_timelines_init(dev_priv);
1438
1439 ret = i915_gem_init_userptr(dev_priv);
1440 if (ret)
1441 return ret;
1442
1443 intel_uc_fetch_firmwares(_priv->gt.uc);
1444
1445 ret = intel_wopcm_init(_priv->wopcm);
1446 if (ret)
1447 goto err_uc_fw;
1448
1449 /* This is just a security blanket to placate dragons.
1450 * On some systems, we very sporadically observe that the first
TLBs
1451 * used by the CS may be stale, despite us poking the TLB
reset. If
1452 * we hold the forcewake during initialisation these problems
1453 * just magically go away.
1454 */
1455 mutex_lock(_priv->drm.struct_mutex);
1456 intel_uncore_forcewake_get(_priv->uncore, FORCEWAKE_ALL);
1457
1458 ret = i915_init_ggtt(dev_priv);
1459 if (ret) {
1460 GEM_BUG_ON(ret == -EIO);
1461 goto err_unlock;
1462 }
1463
1464 ret = i915_gem_init_scratch(dev_priv,
1465 IS_GEN(dev_priv, 2) ? SZ_256K :
PAGE_SIZE);
1466 if (ret) {
1467 GEM_BUG_ON(ret == -EIO);
1468 goto err_ggtt;
1469 }
1470
1471 ret = intel_engines_setup(dev_priv);
1472 if (ret) {
1473 GEM_BUG_ON(ret == -EIO);
1474 goto err_unlock;
1475 }
1476
1477 ret = i915_gem_contexts_init(dev_priv);
1478 if (ret) {
1479 GEM_BUG_ON(ret == -EIO);
1480 goto err_scratch;
1481 }
1482
1483 ret = intel_engines_init(dev_priv);
1484 if (ret) {
1485 GEM_BUG_ON(ret == -EIO);
1486 goto err_context;
1487 }
1488
1489 intel_init_gt_powersave(dev_priv);
1490
1491 ret = intel_uc_init(_priv->gt.uc);
1492 if (ret)
1493 goto err_pm;
1494
1495 ret = i915_gem_init_hw(dev_priv);
1496 if (ret)
1497 goto err_uc_init;
1498
1499 /* Only when the HW is re-initialised, can we replay the
requests */
1500 ret = intel_gt_resume(_priv->gt);
1501 if (ret)
1502 goto err_init_hw;
1503
1504 /*
1505 * Despite its name intel_init_clock_gating applies both display
1506 * clock gating workarounds; GT mmio workarounds and the
occasional
1507 * GT power context workaround. Worse, sometimes it includes a
context
1508 * register workaround which we need to apply before we record
the
1509 * default HW state for all contexts.
1510 *
1511 * FIXME: break up the workarounds and apply them at the right
time!
1512 */
1513 intel_init_clock_gating(dev_priv);
1514
1515 ret = intel_engines_verify_workarounds(dev_priv);
1516 if (ret)
1517 goto err_gt;
1518
1519 ret = __intel_engines_record_defaults(dev_priv);
1520 if (ret)
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
On Thu, 2019-08-08 at 00:12 +0100, Chris Wilson wrote:
> Quoting Stuart Summers (2019-08-08 00:00:17)
> > On Wed, 2019-08-07 at 23:01 +0100, Chris Wilson wrote:
> > > Quoting Stuart Summers (2019-08-07 22:48:55)
> > > > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> > > > > Quoting Stuart Summers (2019-08-07 21:55:55)
> > > > > > User applications might need to verify hardware
> > > > > > configuration
> > > > > > of the MOCS entries. To facilitate this debug, add a new
> > > > > > debugfs
> > > > > > entry to allow a dump of the MOCS state to verify expected
> > > > > > values
> > > > > > are set by i915.
> > > > >
> > > > > User applications + debugfs? It's not an avenue for ABI.
> > > > >
> > > > > If you really want to provide the settings back to userspace,
> > > > > look at
> > > > > something like an i915_query or sysfs.
> > > > >
> > > > > Or if you just mean igt, then add a Testcase:
> > > > >
> > > > > If you just need to validate that we are setting and
> > > > > restoring
> > > > > them,
> > > > > selftests.
> > > > >
> > > > > If you need them for debugging errors, add them to the error
> > > > > state.
> > > >
> > > > This was probably poorly worded, you're right. I'll update the
> > > > commit
> > > > message to be more specific.
> > > >
> > > > I do want this for debugging, but not sure error state is the
> > > > right
> > > > place. This is for debugging performance issues, so no specific
> > > > failures. If you feel sysfs or i915_query are more correct
> > > > here, I
> > > > can
> > > > look at adding this there instead. Is there a reason we don't
> > > > want
> > > > this
> > > > in debugfs specifically?
> > >
> > > No, it was just the wording implied to me you had a use case for
> > > clients, not just debugging the kernel.
> > >
> > > Adding it to the error state (see i915_gpu_info) is not too bad
> > > an
> > > idea
> > > if you need a sledgehammer to inspect the GPU state while a batch
> > > is
> > > executing, but really it just sounds like you want to automate
> > > checking
> > > the mocs registers against "ideal" state. They should be static,
> > > so
> > > once
> > > they are set, so long as we are confident and check that they do
> > > not
> > > change nor can be scribbled over by userspace, you only need to
> > > scan
> > > the
> > > source :)
> > >
> > > I will add that I wish we took a more complete snapshot of
> > > interesting
> > > registers for the error state.
> >
> > I guess my question is about intent of the error state. I can add
> > it
> > there, but do we want this to indicate any register state we might
> > want
> > to investigate, even if the registers are "correct", but just need
> > review based on current behavior?
>
> It was created for debugging userspace batches (later added to hang
> detection as a means of automatically grabbing the hopefully relevant
> batch). As such it's a motley collection of information that at some
> point proved useful. If you can make use of it, and find it more
> useful
> to have the mocs registers in the same snapshot as the user batch,
> please do include it. (Fwiw, I would like to extend the error state
> with
> a bunch of { offset:0xfoo, value:0xbar } given a set of tables
> listing
> the interesting regs. There just hasn't been an urgent need. Also on
> that wishlist is devcoredump.)
Ok perfect, thanks for the history here! I'll rework this into the
error state. If the intent is a catch-all where we can easily see the
state of the GPU at any given time, I agree having a large list of
registers we dump here for review would be really interesting.
Thanks,
Stuart
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
Quoting Stuart Summers (2019-08-08 00:00:17)
> On Wed, 2019-08-07 at 23:01 +0100, Chris Wilson wrote:
> > Quoting Stuart Summers (2019-08-07 22:48:55)
> > > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote:
> > > > Quoting Stuart Summers (2019-08-07 21:55:55)
> > > > > User applications might need to verify hardware configuration
> > > > > of the MOCS entries. To facilitate this debug, add a new
> > > > > debugfs
> > > > > entry to allow a dump of the MOCS state to verify expected
> > > > > values
> > > > > are set by i915.
> > > >
> > > > User applications + debugfs? It's not an avenue for ABI.
> > > >
> > > > If you really want to provide the settings back to userspace,
> > > > look at
> > > > something like an i915_query or sysfs.
> > > >
> > > > Or if you just mean igt, then add a Testcase:
> > > >
> > > > If you just need to validate that we are setting and restoring
> > > > them,
> > > > selftests.
> > > >
> > > > If you need them for debugging errors, add them to the error
> > > > state.
> > >
> > > This was probably poorly worded, you're right. I'll update the
> > > commit
> > > message to be more specific.
> > >
> > > I do want this for debugging, but not sure error state is the right
> > > place. This is for debugging performance issues, so no specific
> > > failures. If you feel sysfs or i915_query are more correct here, I
> > > can
> > > look at adding this there instead. Is there a reason we don't want
> > > this
> > > in debugfs specifically?
> >
> > No, it was just the wording implied to me you had a use case for
> > clients, not just debugging the kernel.
> >
> > Adding it to the error state (see i915_gpu_info) is not too bad an
> > idea
> > if you need a sledgehammer to inspect the GPU state while a batch is
> > executing, but really it just sounds like you want to automate
> > checking
> > the mocs registers against "ideal" state. They should be static, so
> > once
> > they are set, so long as we are confident and check that they do not
> > change nor can be scribbled over by userspace, you only need to scan
> > the
> > source :)
> >
> > I will add that I wish we took a more complete snapshot of
> > interesting
> > registers for the error state.
>
> I guess my question is about intent of the error state. I can add it
> there, but do we want this to indicate any register state we might want
> to investigate, even if the registers are "correct", but just need
> review based on current behavior?
It was created for debugging userspace batches (later added to hang
detection as a means of automatically grabbing the hopefully relevant
batch). As such it's a motley collection of information that at some
point proved useful. If you can make use of it, and find it more useful
to have the mocs registers in the same snapshot as the user batch,
please do include it. (Fwiw, I would like to extend the error state with
a bunch of { offset:0xfoo, value:0xbar } given a set of tables listing
the interesting regs. There just hasn't been an urgent need. Also on
that wishlist is devcoredump.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
On Wed, 2019-08-07 at 23:01 +0100, Chris Wilson wrote: > Quoting Stuart Summers (2019-08-07 22:48:55) > > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote: > > > Quoting Stuart Summers (2019-08-07 21:55:55) > > > > User applications might need to verify hardware configuration > > > > of the MOCS entries. To facilitate this debug, add a new > > > > debugfs > > > > entry to allow a dump of the MOCS state to verify expected > > > > values > > > > are set by i915. > > > > > > User applications + debugfs? It's not an avenue for ABI. > > > > > > If you really want to provide the settings back to userspace, > > > look at > > > something like an i915_query or sysfs. > > > > > > Or if you just mean igt, then add a Testcase: > > > > > > If you just need to validate that we are setting and restoring > > > them, > > > selftests. > > > > > > If you need them for debugging errors, add them to the error > > > state. > > > > This was probably poorly worded, you're right. I'll update the > > commit > > message to be more specific. > > > > I do want this for debugging, but not sure error state is the right > > place. This is for debugging performance issues, so no specific > > failures. If you feel sysfs or i915_query are more correct here, I > > can > > look at adding this there instead. Is there a reason we don't want > > this > > in debugfs specifically? > > No, it was just the wording implied to me you had a use case for > clients, not just debugging the kernel. > > Adding it to the error state (see i915_gpu_info) is not too bad an > idea > if you need a sledgehammer to inspect the GPU state while a batch is > executing, but really it just sounds like you want to automate > checking > the mocs registers against "ideal" state. They should be static, so > once > they are set, so long as we are confident and check that they do not > change nor can be scribbled over by userspace, you only need to scan > the > source :) > > I will add that I wish we took a more complete snapshot of > interesting > registers for the error state. I guess my question is about intent of the error state. I can add it there, but do we want this to indicate any register state we might want to investigate, even if the registers are "correct", but just need review based on current behavior? Thanks, Stuart > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Add function to determine if a slice has a subslice
Quoting Stuart Summers (2019-08-07 17:58:29)
> Add a new function to determine whether a particular slice
> has a given subslice.
> +static inline bool
> +intel_sseu_has_subslice(const struct sseu_dev_info *sseu, int slice,
> + int subslice)
> +{
> + u8 mask = sseu->subslice_mask[slice * sseu->ss_stride +
> + subslice / BITS_PER_BYTE];
> +
> + return mask & BIT(subslice % BITS_PER_BYTE);
One might ask why haven't we switched to bitmap.h by this point?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
Quoting Stuart Summers (2019-08-07 22:48:55) > On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote: > > Quoting Stuart Summers (2019-08-07 21:55:55) > > > User applications might need to verify hardware configuration > > > of the MOCS entries. To facilitate this debug, add a new debugfs > > > entry to allow a dump of the MOCS state to verify expected values > > > are set by i915. > > > > User applications + debugfs? It's not an avenue for ABI. > > > > If you really want to provide the settings back to userspace, look at > > something like an i915_query or sysfs. > > > > Or if you just mean igt, then add a Testcase: > > > > If you just need to validate that we are setting and restoring them, > > selftests. > > > > If you need them for debugging errors, add them to the error state. > > This was probably poorly worded, you're right. I'll update the commit > message to be more specific. > > I do want this for debugging, but not sure error state is the right > place. This is for debugging performance issues, so no specific > failures. If you feel sysfs or i915_query are more correct here, I can > look at adding this there instead. Is there a reason we don't want this > in debugfs specifically? No, it was just the wording implied to me you had a use case for clients, not just debugging the kernel. Adding it to the error state (see i915_gpu_info) is not too bad an idea if you need a sledgehammer to inspect the GPU state while a batch is executing, but really it just sounds like you want to automate checking the mocs registers against "ideal" state. They should be static, so once they are set, so long as we are confident and check that they do not change nor can be scribbled over by userspace, you only need to scan the source :) I will add that I wish we took a more complete snapshot of interesting registers for the error state. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
On Wed, 2019-08-07 at 22:29 +0100, Chris Wilson wrote: > Quoting Stuart Summers (2019-08-07 21:55:55) > > User applications might need to verify hardware configuration > > of the MOCS entries. To facilitate this debug, add a new debugfs > > entry to allow a dump of the MOCS state to verify expected values > > are set by i915. > > User applications + debugfs? It's not an avenue for ABI. > > If you really want to provide the settings back to userspace, look at > something like an i915_query or sysfs. > > Or if you just mean igt, then add a Testcase: > > If you just need to validate that we are setting and restoring them, > selftests. > > If you need them for debugging errors, add them to the error state. This was probably poorly worded, you're right. I'll update the commit message to be more specific. I do want this for debugging, but not sure error state is the right place. This is for debugging performance issues, so no specific failures. If you feel sysfs or i915_query are more correct here, I can look at adding this there instead. Is there a reason we don't want this in debugfs specifically? Thanks, Stuart > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
On Wed, Aug 07, 2019 at 01:55:55PM -0700, Stuart Summers wrote:
> User applications might need to verify hardware configuration
> of the MOCS entries. To facilitate this debug, add a new debugfs
> entry to allow a dump of the MOCS state to verify expected values
> are set by i915.
>
> Signed-off-by: Stuart Summers
Acked-by: Prathap Kumar Valsan
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 50
> drivers/gpu/drm/i915/gt/intel_mocs.h | 3 ++
> drivers/gpu/drm/i915/i915_debugfs.c | 12 +++
> 3 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 728704bbbe18..fea8ef2fd2aa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -625,6 +625,56 @@ int intel_mocs_emit(struct i915_request *rq)
> return 0;
> }
>
> +static void
> +intel_mocs_dump_l3cc_table(struct intel_gt *gt, struct drm_printer *p)
> +{
> + struct intel_uncore *uncore = gt->uncore;
> + struct drm_i915_mocs_table table;
> + unsigned int i;
> +
> + if (!get_mocs_settings(gt, ))
> + return;
> +
> + drm_printf(p, "l3cc:\n");
> +
> + for (i = 0; i < table.n_entries / 2; i++) {
> + u32 reg = intel_uncore_read(uncore, GEN9_LNCFCMOCS(i));
> +
> + drm_printf(p, " MOCS[%d]: 0x%x\n", i * 2, reg & 0x);
> + drm_printf(p, " MOCS[%d]: 0x%x\n", i * 2 + 1, reg >> 16);
> + }
> +}
> +
> +static void
> +intel_mocs_dump_global(struct intel_gt *gt, struct drm_printer *p)
> +{
> + struct intel_uncore *uncore = gt->uncore;
> + struct drm_i915_mocs_table table;
> + unsigned int i;
> +
> + GEM_BUG_ON(!HAS_GLOBAL_MOCS_REGISTERS(gt->i915));
> +
> + if (!get_mocs_settings(gt, ))
> + return;
> +
> + if (GEM_DEBUG_WARN_ON(table.size > table.n_entries))
> + return;
> +
> + drm_printf(p, "global:\n");
> +
> + for (i = 0; i < table.n_entries; i++)
> + drm_printf(p, " MOCS[%d]: 0x%x\n",
> +i, intel_uncore_read(uncore, GEN12_GLOBAL_MOCS(i)));
> +}
> +
> +void intel_mocs_show_info(struct intel_gt *gt, struct drm_printer *p)
> +{
> + intel_mocs_dump_l3cc_table(gt, p);
> +
> + if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
> + intel_mocs_dump_global(gt, p);
> +}
> +
> void intel_mocs_init(struct intel_gt *gt)
> {
> intel_mocs_init_l3cc_table(gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h
> b/drivers/gpu/drm/i915/gt/intel_mocs.h
> index 2ae816b7ca19..0ef95ce818d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
> @@ -24,6 +24,8 @@
> #ifndef INTEL_MOCS_H
> #define INTEL_MOCS_H
>
> +#include
> +
> /**
> * DOC: Memory Objects Control State (MOCS)
> *
> @@ -55,6 +57,7 @@ struct intel_gt;
>
> void intel_mocs_init(struct intel_gt *gt);
> void intel_mocs_init_engine(struct intel_engine_cs *engine);
> +void intel_mocs_show_info(struct intel_gt *gt, struct drm_printer *p);
>
> int intel_mocs_emit(struct i915_request *rq);
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3b15266c54fd..1aa022eb2c3d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -41,6 +41,7 @@
>
> #include "gem/i915_gem_context.h"
> #include "gt/intel_reset.h"
> +#include "gt/intel_mocs.h"
> #include "gt/uc/intel_guc_submission.h"
>
> #include "i915_debugfs.h"
> @@ -76,6 +77,16 @@ static int i915_capabilities(struct seq_file *m, void
> *data)
> return 0;
> }
>
> +static int show_mocs_info(struct seq_file *m, void *data)
> +{
> + struct drm_i915_private *i915 = node_to_i915(m->private);
> + struct drm_printer p = drm_seq_file_printer(m);
> +
> + intel_mocs_show_info(>gt, );
> +
> + return 0;
> +}
> +
> static char get_pin_flag(struct drm_i915_gem_object *obj)
> {
> return obj->pin_global ? 'p' : ' ';
> @@ -4352,6 +4363,7 @@ static const struct drm_info_list i915_debugfs_list[] =
> {
> {"i915_sseu_status", i915_sseu_status, 0},
> {"i915_drrs_status", i915_drrs_status, 0},
> {"i915_rps_boost_info", i915_rps_boost_info, 0},
> + {"i915_mocs_info", show_mocs_info, 0},
> };
> #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
>
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
Quoting Stuart Summers (2019-08-07 21:55:55) > User applications might need to verify hardware configuration > of the MOCS entries. To facilitate this debug, add a new debugfs > entry to allow a dump of the MOCS state to verify expected values > are set by i915. User applications + debugfs? It's not an avenue for ABI. If you really want to provide the settings back to userspace, look at something like an i915_query or sysfs. Or if you just mean igt, then add a Testcase: If you just need to validate that we are setting and restoring them, selftests. If you need them for debugging errors, add them to the error state. -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 series starting with [1/2] drm/i915: Add MOCS state dump to debugfs
== Series Details == Series: series starting with [1/2] drm/i915: Add MOCS state dump to debugfs URL : https://patchwork.freedesktop.org/series/64868/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6651 -> Patchwork_13908 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13908 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13908, 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_13908/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13908: ### IGT changes ### Possible regressions * igt@debugfs_test@read_all_entries: - fi-kbl-guc: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-kbl-guc/igt@debugfs_test@read_all_entries.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-guc/igt@debugfs_test@read_all_entries.html - fi-kbl-8809g: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-8809g/igt@debugfs_test@read_all_entries.html * igt@runner@aborted: - fi-kbl-8809g: NOTRUN -> [FAIL][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-8809g/igt@run...@aborted.html - fi-kbl-guc: NOTRUN -> [FAIL][6] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-guc/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_13908 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap_gtt@basic-read: - fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-icl-u3/igt@gem_mmap_...@basic-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-icl-u3/igt@gem_mmap_...@basic-read.html * igt@i915_selftest@live_client: - fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([fdo#110943]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-skl-guc/igt@i915_selftest@live_client.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-skl-guc/igt@i915_selftest@live_client.html * igt@i915_selftest@live_reset: - fi-icl-u2: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-icl-u2/igt@i915_selftest@live_reset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-icl-u2/igt@i915_selftest@live_reset.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7567u: [PASS][13] -> [WARN][14] ([fdo#109380]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc-pipe-c: - fi-kbl-7567u: [PASS][15] -> [SKIP][16] ([fdo#109271]) +23 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html * igt@prime_vgem@basic-fence-flip: - fi-kbl-7500u: [PASS][17] -> [SKIP][18] ([fdo#109271]) +23 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@i915_selftest@live_execlists: - fi-skl-gvtdvm: [DMESG-FAIL][19] ([fdo#08]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html * igt@kms_busy@basic-flip-a: - fi-kbl-7567u: [SKIP][21] ([fdo#109271] / [fdo#109278]) -> [PASS][22] +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6651/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13908/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: [SKIP][23] ([fdo#109271] / [fdo#109278]) -> [PASS][24] +2 similar issues [23]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: split out intel_pch.[ch] from i915_drv.[ch]
== Series Details == Series: drm/i915: split out intel_pch.[ch] from i915_drv.[ch] URL : https://patchwork.freedesktop.org/series/64833/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6646_full -> Patchwork_13899_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13899_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13899_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_13899_full: ### IGT changes ### Possible regressions * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-kbl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-kbl7/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-kbl3/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html * igt@prime_busy@wait-hang-blt: - shard-apl: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-apl4/igt@prime_b...@wait-hang-blt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-apl3/igt@prime_b...@wait-hang-blt.html Known issues Here are the changes found in Patchwork_13899_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-kbl4/igt@gem_ctx_isolat...@bcs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-kbl7/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_tiled_swapping@non-threaded: - shard-hsw: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-hsw6/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-hsw7/igt@gem_tiled_swapp...@non-threaded.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_6646/shard-skl7/igt@i915_susp...@fence-restore-untiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-skl2/igt@i915_susp...@fence-restore-untiled.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-skl: [PASS][13] -> [DMESG-WARN][14] ([fdo#105541]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl2/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-skl7/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-wf_vblank-interruptible: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#100368]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl7/igt@kms_flip@flip-vs-wf_vblank-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-skl8/igt@kms_flip@flip-vs-wf_vblank-interruptible.html * igt@kms_flip@modeset-vs-vblank-race: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#107713]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb4/igt@kms_f...@modeset-vs-vblank-race.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13899/shard-iclb1/igt@kms_f...@modeset-vs-vblank-race.html * igt@kms_frontbuffer_tracking@fbcpsr-stridechange: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-stridechange.html [22]:
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v13
On Wed, Jul 31, 2019 at 10:55:02AM +0200, Daniel Vetter wrote: > On Thu, Jun 27, 2019 at 09:28:11AM +0200, Christian König wrote: > > Hi Daniel, > > > > those fails look like something random to me and not related to my patch > > set. Correct? > > First one I looked at has the reservation_obj all over: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-cml-u/igt@gem_exec_fe...@basic-busy-default.html > > So 5 second guees is ... probably real? > > Note that with the entire lmem stuff going on right now there's massive > discussions about how we're doing resv_obj vs obj->mm.lock the wrong way > round in i915, so I'm not surprised at all that you managed to trip this. > > The way I see it right now is that obj->mm.lock needs to be limited to > dealing with the i915 shrinker interactions only, and only for i915 native > objects. And for dma-bufs we need to make sure it's not anywhere in the > callchain. Unfortunately that's a massive refactor I guess ... Thought about this some more, aside from just breaking i915 or waiting until it's refactored (Both not awesome) I think the only option is get back to the original caching. And figure out whether we really need to take the direction into account for that, or whether upgrading to bidirectional unconditionally won't be ok. I think there's only really two cases where this matters: - display drivers using the cma/dma_alloc helpers. Everything is allocated fully coherent, cpu side wc, no flushing. - Everyone else (on platforms where there's actually some flushing going on) is for rendering gpus, and those always map bidirectional and want the mapping cached for as long as possible. With that we could go back to creating the cached mapping at attach time and avoid inflicting the reservation object lock to places that would keel over. Thoughts? -Daniel > -Daniel > > > > > Christian. > > > > Am 26.06.19 um 15:32 schrieb Patchwork: > > > == Series Details == > > > > > > Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling > > > v13 > > > URL : https://patchwork.freedesktop.org/series/62777/ > > > State : failure > > > > > > == Summary == > > > > > > CI Bug Log - changes from CI_DRM_6358 -> Patchwork_13438 > > > > > > > > > Summary > > > --- > > > > > >**FAILURE** > > > > > >Serious unknown changes coming with Patchwork_13438 absolutely need to > > > be > > >verified manually. > > >If you think the reported changes have nothing to do with the changes > > >introduced in Patchwork_13438, 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_13438/ > > > > > > Possible new issues > > > --- > > > > > >Here are the unknown changes that may have been introduced in > > > Patchwork_13438: > > > > > > ### IGT changes ### > > > > > > Possible regressions > > > > > >* igt@i915_selftest@live_contexts: > > > - fi-kbl-7567u: [PASS][1] -> [INCOMPLETE][2] > > > [1]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-kbl-7567u/igt@i915_selftest@live_contexts.html > > > [2]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-kbl-7567u/igt@i915_selftest@live_contexts.html > > > > > >* igt@i915_selftest@live_hugepages: > > > - fi-skl-gvtdvm: [PASS][3] -> [INCOMPLETE][4] > > > [3]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html > > > [4]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-skl-gvtdvm/igt@i915_selftest@live_hugepages.html > > > > > > Known issues > > > > > > > > >Here are the changes found in Patchwork_13438 that come from known > > > issues: > > > > > > ### IGT changes ### > > > > > > Issues hit > > > > > >* igt@gem_basic@create-close: > > > - fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) > > > [5]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-u3/igt@gem_ba...@create-close.html > > > [6]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-u3/igt@gem_ba...@create-close.html > > > > > >* igt@gem_ctx_switch@basic-default: > > > - fi-icl-guc: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / > > > [fdo#108569]) > > > [7]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6358/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html > > > [8]: > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13438/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html > > > > > >* igt@gem_exec_create@basic: > > > - fi-icl-u2: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713]) > > > [9]: > > >
Re: [Intel-gfx] [PATCH] dma-buf: make dma_fence structure a bit smaller
On Wed, Aug 07, 2019 at 03:01:59PM +0100, Chris Wilson wrote: > Quoting Christian König (2019-08-07 14:54:05) > > The ruc and cb_list are never used at the same time. > > This smal change is actually making the structure 16% smaller. > (Trivial pair of typos) > > Yes. We clear the callback list on kref_put so that by the time we > release the fence it is unused. No one should be adding to the cb_list > that they don't themselves hold a reference for, this only now makes for > a much more spectacular use-after-free. :) ^^ stuff the above as an inline kerneldoc comment into the patch? And into the commit message too pls. We need better docs for all this scorcery :-) Thanks, Daniel > > > Signed-off-by: Christian König > Reviewed-by: Chris Wilson > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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 v3 0/3] Send a hotplug when edid changes
On Wed, Aug 07, 2019 at 07:43:18AM +, Lisovskiy, Stanislav wrote: > On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote: > > On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav > > wrote: > > > > > > On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote: > > > > On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy > > > > wrote: > > > > > This series introduce to drm a way to determine if something > > > > > else > > > > > except connection_status had changed during probing, which > > > > > can be used by other drivers as well. Another i915 specific > > > > > part > > > > > uses this approach to determine if edid had changed without > > > > > changing the connection status and send a hotplug event. > > > > > > > > Did you read through the entire huge thread on all this (with I > > > > think > > > > Paul, Pekka, Ram and some others)? I feel like this is mostly > > > > taking > > > > that > > > > idea, but not taking a lot of the details we've discussed there. > > > > Specifically I'm not sure how userspace should handle this > > > > without > > > > also > > > > exposing the epoch counter, or at least generating a hotplug > > > > event > > > > for the > > > > specific connector. All that and more we discussed there. > > > > > > > > And then there's the follow-up question: What's the userspace for > > > > this? > > > > Existing expectations are a minefield here, so even if you don't > > > > plan > > > > to > > > > change userspace we need to know what this is aimed for, and see > > > > above I > > > > don't think this is possible to use without userspace changes ... > > > > > > Yes, sure I agree about userspace. However I guess we must start > > > from > > > something at least. > > > I think I have seen some discussion regarding exposing this epoch > > > counter as a property. Was even implementing this at some point but > > > didn't dare to send to mailing list :) > > > > > > My idea was just to expose this epoch counter as a drm property, to > > > let > > > userspace then to figure out, what has happened, as imho adding > > > different events for this and that is a bit of an overkill and > > > brings > > > additional complexity.. > > > > Adding Ram and link to the (warning, huge!) thread: > > > > https://patchwork.freedesktop.org/patch/303905/?series=57232=9 > > > > > However, please let me know, what do you think we should do for > > > userspace. > > > > That seems backwards, since this is an uapi change I'd expect you're > > solving some specific issue in some specific userspace? If we're > > doing > > this just because I'm not really following. > > Specifically, I'm solving an issue of changed edid during suspend, like > we for example have in kms_chamelium hotplug tests(some of which now > fail because of that). > So even if connection status hasn't changed, we still need to send > hotplug event and userspace needs to be able to understand that > something had changed and whether we need to do a full reprobe or not. > Epoch counter property would be responsible for this. > As I understand in general there might be other connector updates, > except edid which we need propagate in a similar way. So igt isn't valid userspace (it's just good testcases). Can we repro the same on real userspace? Does this work with real userspace? We've had userspace which tries to be clever and filters out what looks like redundant hotplug events. And then gets it wrong in cases like this. Also, we've had forever an unconditional uevent on resume, exactly because anything could have changed. Did we loose this one on the way somewhere? Or maybe I misremember ... If all we care about is resume re-adding that uncondtional uevent on resume is going to be a lot easier than this here. -Daniel > > -Stanislav > > > > > Cheers, Daniel > > > > > > > > > > > -Stanislav > > > > > > > > > > -Daniel > > > > > > > > > > > > > > Stanislav Lisovskiy (3): > > > > > drm: Add helper to compare edids. > > > > > drm: Introduce change counter to drm_connector > > > > > drm/i915: Send hotplug event if edid had changed. > > > > > > > > > > drivers/gpu/drm/drm_connector.c | 1 + > > > > > drivers/gpu/drm/drm_edid.c | 33 > > > > > > > > > > drivers/gpu/drm/drm_probe_helper.c | 29 > > > > > +++- > > > > > - > > > > > drivers/gpu/drm/i915/display/intel_dp.c | 16 +- > > > > > drivers/gpu/drm/i915/display/intel_hdmi.c| 16 -- > > > > > drivers/gpu/drm/i915/display/intel_hotplug.c | 21 ++ > > > > > --- > > > > > include/drm/drm_connector.h | 3 ++ > > > > > include/drm/drm_edid.h | 9 ++ > > > > > 8 files changed, 117 insertions(+), 11 deletions(-) > > > > > > > > > > -- > > > > > 2.17.1 > > > > > > > > > > > > > > > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 2/2] drm/i915: Return true by default in mocs settings
Reduce code by defaulting to true in the MOCS settings
initialization function. Set to false for unexpected
platforms.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index fea8ef2fd2aa..ffd105c53ff4 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -291,31 +291,28 @@ static bool get_mocs_settings(struct intel_gt *gt,
struct drm_i915_mocs_table *table)
{
struct drm_i915_private *i915 = gt->i915;
- bool result = false;
+ bool result = true;
if (INTEL_GEN(i915) >= 12) {
table->size = ARRAY_SIZE(tigerlake_mocs_table);
table->table = tigerlake_mocs_table;
table->n_entries = GEN11_NUM_MOCS_ENTRIES;
- result = true;
} else if (IS_GEN(i915, 11)) {
table->size = ARRAY_SIZE(icelake_mocs_table);
table->table = icelake_mocs_table;
table->n_entries = GEN11_NUM_MOCS_ENTRIES;
- result = true;
} else if (IS_GEN9_BC(i915) || IS_CANNONLAKE(i915)) {
table->size = ARRAY_SIZE(skylake_mocs_table);
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = skylake_mocs_table;
- result = true;
} else if (IS_GEN9_LP(i915)) {
table->size = ARRAY_SIZE(broxton_mocs_table);
table->n_entries = GEN9_NUM_MOCS_ENTRIES;
table->table = broxton_mocs_table;
- result = true;
} else {
WARN_ONCE(INTEL_GEN(i915) >= 9,
"Platform that should have a MOCS table does not.\n");
+ result = false;
}
/* WaDisableSkipCaching:skl,bxt,kbl,glk */
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Add MOCS state dump to debugfs
User applications might need to verify hardware configuration
of the MOCS entries. To facilitate this debug, add a new debugfs
entry to allow a dump of the MOCS state to verify expected values
are set by i915.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 50
drivers/gpu/drm/i915/gt/intel_mocs.h | 3 ++
drivers/gpu/drm/i915/i915_debugfs.c | 12 +++
3 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 728704bbbe18..fea8ef2fd2aa 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -625,6 +625,56 @@ int intel_mocs_emit(struct i915_request *rq)
return 0;
}
+static void
+intel_mocs_dump_l3cc_table(struct intel_gt *gt, struct drm_printer *p)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ struct drm_i915_mocs_table table;
+ unsigned int i;
+
+ if (!get_mocs_settings(gt, ))
+ return;
+
+ drm_printf(p, "l3cc:\n");
+
+ for (i = 0; i < table.n_entries / 2; i++) {
+ u32 reg = intel_uncore_read(uncore, GEN9_LNCFCMOCS(i));
+
+ drm_printf(p, " MOCS[%d]: 0x%x\n", i * 2, reg & 0x);
+ drm_printf(p, " MOCS[%d]: 0x%x\n", i * 2 + 1, reg >> 16);
+ }
+}
+
+static void
+intel_mocs_dump_global(struct intel_gt *gt, struct drm_printer *p)
+{
+ struct intel_uncore *uncore = gt->uncore;
+ struct drm_i915_mocs_table table;
+ unsigned int i;
+
+ GEM_BUG_ON(!HAS_GLOBAL_MOCS_REGISTERS(gt->i915));
+
+ if (!get_mocs_settings(gt, ))
+ return;
+
+ if (GEM_DEBUG_WARN_ON(table.size > table.n_entries))
+ return;
+
+ drm_printf(p, "global:\n");
+
+ for (i = 0; i < table.n_entries; i++)
+ drm_printf(p, " MOCS[%d]: 0x%x\n",
+ i, intel_uncore_read(uncore, GEN12_GLOBAL_MOCS(i)));
+}
+
+void intel_mocs_show_info(struct intel_gt *gt, struct drm_printer *p)
+{
+ intel_mocs_dump_l3cc_table(gt, p);
+
+ if (HAS_GLOBAL_MOCS_REGISTERS(gt->i915))
+ intel_mocs_dump_global(gt, p);
+}
+
void intel_mocs_init(struct intel_gt *gt)
{
intel_mocs_init_l3cc_table(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.h
b/drivers/gpu/drm/i915/gt/intel_mocs.h
index 2ae816b7ca19..0ef95ce818d3 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.h
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.h
@@ -24,6 +24,8 @@
#ifndef INTEL_MOCS_H
#define INTEL_MOCS_H
+#include
+
/**
* DOC: Memory Objects Control State (MOCS)
*
@@ -55,6 +57,7 @@ struct intel_gt;
void intel_mocs_init(struct intel_gt *gt);
void intel_mocs_init_engine(struct intel_engine_cs *engine);
+void intel_mocs_show_info(struct intel_gt *gt, struct drm_printer *p);
int intel_mocs_emit(struct i915_request *rq);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3b15266c54fd..1aa022eb2c3d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -41,6 +41,7 @@
#include "gem/i915_gem_context.h"
#include "gt/intel_reset.h"
+#include "gt/intel_mocs.h"
#include "gt/uc/intel_guc_submission.h"
#include "i915_debugfs.h"
@@ -76,6 +77,16 @@ static int i915_capabilities(struct seq_file *m, void *data)
return 0;
}
+static int show_mocs_info(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *i915 = node_to_i915(m->private);
+ struct drm_printer p = drm_seq_file_printer(m);
+
+ intel_mocs_show_info(>gt, );
+
+ return 0;
+}
+
static char get_pin_flag(struct drm_i915_gem_object *obj)
{
return obj->pin_global ? 'p' : ' ';
@@ -4352,6 +4363,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_sseu_status", i915_sseu_status, 0},
{"i915_drrs_status", i915_drrs_status, 0},
{"i915_rps_boost_info", i915_rps_boost_info, 0},
+ {"i915_mocs_info", show_mocs_info, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 36/39] drm/i915: Use reservation_object to coordinate userptr get_pages()
On Fri, Jun 14, 2019 at 08:10:20AM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
Not sure this works, 2 thoughts way down ...
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 27 +--
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 -
> drivers/gpu/drm/i915/gem/i915_gem_internal.c | 30 +--
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 11 +-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 137 ++-
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 33 ++-
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 30 +--
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 25 +-
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 221 --
> .../drm/i915/gem/selftests/huge_gem_object.c | 17 +-
> .../gpu/drm/i915/gem/selftests/huge_pages.c | 45 ++--
> drivers/gpu/drm/i915/gvt/dmabuf.c | 17 +-
> drivers/gpu/drm/i915/i915_drv.h | 9 +-
> drivers/gpu/drm/i915/i915_gem.c | 5 +-
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 14 +-
> 15 files changed, 300 insertions(+), 324 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 84992d590da5..a44d6d2ef7ed 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -225,33 +225,24 @@ struct dma_buf *i915_gem_prime_export(struct drm_device
> *dev,
> return drm_gem_dmabuf_export(dev, _info);
> }
>
> -static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
> +static struct sg_table *
> +dmabuf_get_pages(struct i915_gem_object_get_pages_context *ctx,
> + unsigned int *sizes)
> {
> - struct sg_table *pages;
> - unsigned int sg_page_sizes;
> -
> - pages = dma_buf_map_attachment(obj->base.import_attach,
> -DMA_BIDIRECTIONAL);
> - if (IS_ERR(pages))
> - return PTR_ERR(pages);
> -
> - sg_page_sizes = i915_sg_page_sizes(pages->sgl);
> -
> - __i915_gem_object_set_pages(obj, pages, sg_page_sizes);
> -
> - return 0;
> + return dma_buf_map_attachment(ctx->object->base.import_attach,
> + DMA_BIDIRECTIONAL);
> }
>
> -static void i915_gem_object_put_pages_dmabuf(struct drm_i915_gem_object *obj,
> - struct sg_table *pages)
> +static void dmabuf_put_pages(struct drm_i915_gem_object *obj,
> + struct sg_table *pages)
> {
> dma_buf_unmap_attachment(obj->base.import_attach, pages,
>DMA_BIDIRECTIONAL);
> }
>
> static const struct drm_i915_gem_object_ops i915_gem_object_dmabuf_ops = {
> - .get_pages = i915_gem_object_get_pages_dmabuf,
> - .put_pages = i915_gem_object_put_pages_dmabuf,
> + .get_pages = dmabuf_get_pages,
> + .put_pages = dmabuf_put_pages,
> };
>
> struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 44bcb681c168..68faf1a71c97 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -1784,9 +1784,6 @@ static noinline int eb_relocate_slow(struct
> i915_execbuffer *eb)
> goto out;
> }
>
> - /* A frequent cause for EAGAIN are currently unavailable client pages */
> - flush_workqueue(eb->i915->mm.userptr_wq);
> -
> err = i915_mutex_lock_interruptible(dev);
> if (err) {
> mutex_lock(>struct_mutex);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
> b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
> index 0c41e04ab8fa..aa0bd5de313b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
> @@ -32,11 +32,14 @@ static void internal_free_pages(struct sg_table *st)
> kfree(st);
> }
>
> -static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object
> *obj)
> +static struct sg_table *
> +internal_get_pages(struct i915_gem_object_get_pages_context *ctx,
> +unsigned int *sizes)
> {
> + struct drm_i915_gem_object *obj = ctx->object;
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> - struct sg_table *st;
> struct scatterlist *sg;
> + struct sg_table *st;
> unsigned int sg_page_sizes;
> unsigned int npages;
> int max_order;
> @@ -66,12 +69,12 @@ static int i915_gem_object_get_pages_internal(struct
> drm_i915_gem_object *obj)
> create_st:
> st = kmalloc(sizeof(*st), GFP_KERNEL);
> if (!st)
> - return -ENOMEM;
> + return ERR_PTR(-ENOMEM);
>
> npages = obj->base.size / PAGE_SIZE;
> if (sg_alloc_table(st, npages, GFP_KERNEL)) {
> kfree(st);
> - return -ENOMEM;
> + return
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Hardening firmware fetch (rev2)
Quoting Patchwork (2019-08-07 20:42:47)
> == Series Details ==
>
> Series: Hardening firmware fetch (rev2)
> URL : https://patchwork.freedesktop.org/series/64856/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13907
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
None found, but still some worrying warnings for me. Oh well, pushed with
one minor edit for a compile warning,
static void __force_fw_fetch_failures(struct intel_uc_fw *uc_fw,
- struct drm_i915_private *i915, bool user)
+ struct drm_i915_private *i915,
+ int e)
{
- int e = user ? -EINVAL : -ESTALE;
+ bool user = e == -EINVAL;
if (i915_inject_load_error(i915, e)) {
/* non-existing blob */
@@ -267,8 +268,8 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
if (err)
return err;
- __force_fw_fetch_failures(uc_fw, i915, true);
- __force_fw_fetch_failures(uc_fw, i915, false);
+ __force_fw_fetch_failures(uc_fw, i915, -EINVAL);
+ __force_fw_fetch_failures(uc_fw, i915, -ESTALE);
-Chris
___
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: Include the DRIVER_DATE in the error state
== Series Details == Series: drm/i915: Include the DRIVER_DATE in the error state URL : https://patchwork.freedesktop.org/series/64832/ State : success == Summary == CI Bug Log - changes from CI_DRM_6646_full -> Patchwork_13898_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13898_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: - shard-glk: [PASS][1] -> [FAIL][2] ([fdo#104873]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-glk9/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-glk3/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][3] -> [FAIL][4] ([fdo#105363]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-skl3/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-kbl4/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt: - shard-iclb: [PASS][7] -> [FAIL][8] ([fdo#103167]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl8/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [fdo#110403]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_suspend: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb2/igt@kms_psr@psr2_suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-iclb8/igt@kms_psr@psr2_suspend.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-apl1/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-apl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl3/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-skl8/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html Possible fixes * igt@gem_exec_balancer@smoke: - shard-iclb: [SKIP][19] ([fdo#110854]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb7/igt@gem_exec_balan...@smoke.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-iclb1/igt@gem_exec_balan...@smoke.html * igt@i915_pm_rps@reset: - shard-apl: [FAIL][21] ([fdo#102250]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-apl4/igt@i915_pm_...@reset.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-apl6/igt@i915_pm_...@reset.html - shard-skl: [FAIL][23] ([fdo#102250]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl2/igt@i915_pm_...@reset.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13898/shard-skl9/igt@i915_pm_...@reset.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-apl: [DMESG-WARN][25] ([fdo#108566]) -> [PASS][26] +2 similar issues
Re: [Intel-gfx] [PATCH 2/7] drm/i915/uc: HuC firmware can't be supported without GuC
On Wed, 07 Aug 2019 22:21:29 +0200, Kumar Valsan, Prathap wrote: On Wed, Aug 07, 2019 at 05:00:29PM +, Michal Wajdeczko wrote: There is no point in selecting HuC firmware if GuC is unsupported or it was already disabled, as we need GuC to authenticate HuC. We are calling intel_uc_init() irrespctive of intel_uc_fetch_firmwares() is successful. Is this ok? No need to change this, as intel_guc_init (and intel_huc_init) will call intel_uc_fw_init() which will with -ENOEXEC if firmware is not available (aka fetched) Michal Thanks, Prathap While around, make uc_fw_init_early work without direct access to whole i915, pass only needed platform/rev info. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/uc: HuC firmware can't be supported without GuC
On Wed, Aug 07, 2019 at 05:00:29PM +, Michal Wajdeczko wrote: > There is no point in selecting HuC firmware if GuC is unsupported > or it was already disabled, as we need GuC to authenticate HuC. > We are calling intel_uc_init() irrespctive of intel_uc_fetch_firmwares() is successful. Is this ok? Thanks, Prathap > While around, make uc_fw_init_early work without direct access > to whole i915, pass only needed platform/rev info. > > Signed-off-by: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Chris Wilson > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Hardening firmware fetch (rev2)
== Series Details ==
Series: Hardening firmware fetch (rev2)
URL : https://patchwork.freedesktop.org/series/64856/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13907
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/
Known issues
Here are the changes found in Patchwork_13907 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-skl-6600u: [PASS][3] -> [INCOMPLETE][4] ([fdo#104108])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-skl-6600u/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-skl-6600u/igt@i915_module_l...@reload.html
* igt@i915_module_load@reload-with-fault-injection:
- fi-snb-2600:[PASS][5] -> [DMESG-WARN][6] ([fdo#110684] /
[fdo#15])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-snb-2600/igt@i915_module_l...@reload-with-fault-injection.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-snb-2600/igt@i915_module_l...@reload-with-fault-injection.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][7] -> [WARN][8] ([fdo#109380])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][9] -> [FAIL][10] ([fdo#103167])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [PASS][13] -> [SKIP][14] ([fdo#109271]) +23 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
* igt@prime_vgem@basic-write:
- fi-icl-u3: [PASS][15] -> [DMESG-WARN][16] ([fdo#107724])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@prime_v...@basic-write.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-icl-u3/igt@prime_v...@basic-write.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [INCOMPLETE][17] ([fdo#110566]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
* igt@gem_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][19] ([fdo#107724]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_tiled_bl...@basic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-icl-u3/igt@gem_tiled_bl...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][21] ([fdo#109485]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_vgem@basic-wait-default:
- {fi-icl-dsi}: [DMESG-WARN][23] ([fdo#106107]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13907/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
Re: [Intel-gfx] [PATCH] drm/i915/perf: Refactor oa object to better manage resources
Quoting Umesh Nerlige Ramappa (2019-08-07 00:30:02) > The oa object manages the oa buffer and must be allocated when the user > intends to read performance counter snapshots. This can be achieved by > making the oa object part of the stream object which is allocated when a > stream is opened by the user. > > Attributes in the oa object that are gen-specific are moved to the perf > object so that they can be initialized on driver load. > > The split provides a better separation of the objects used in perf > implementation of i915 driver so that resources are allocated and > initialized only when needed. > > v2: Fix checkpatch warnings > v3: Addressed Lionel's review comment > v4: Rebase > v5: Fix rebase/merge issue with ratelimit_state_init > > Signed-off-by: Umesh Nerlige Ramappa > Reviewed-by: Lionel Landwerlin Pushed. Thanks, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Always request completion before marking an error
== Series Details ==
Series: drm/i915/execlists: Always request completion before marking an error
URL : https://patchwork.freedesktop.org/series/64859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13906
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/
Known issues
Here are the changes found in Patchwork_13906 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_module_load@reload:
- fi-kbl-8809g: [PASS][3] -> [INCOMPLETE][4] ([fdo#103665])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-8809g/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-kbl-8809g/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6260u: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-skl-6260u/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-skl-6260u/igt@i915_pm_...@module-reload.html
- fi-skl-6600u: [PASS][7] -> [FAIL][8] ([fdo#107707])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-skl-6600u/igt@i915_pm_...@module-reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-skl-6600u/igt@i915_pm_...@module-reload.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][9] -> [WARN][10] ([fdo#109380])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [PASS][13] -> [SKIP][14] ([fdo#109271]) +23 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [INCOMPLETE][15] ([fdo#110566]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
* igt@gem_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][17] ([fdo#107724]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_tiled_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-icl-u3/igt@gem_tiled_bl...@basic.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][19] ([fdo#109271] / [fdo#109278]) ->
[PASS][20] +2 similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@prime_vgem@basic-wait-default:
- {fi-icl-dsi}: [DMESG-WARN][21] ([fdo#106107]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13906/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#109271]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v3] drm/i915: Rename engines to match their user interface (rev3)
== Series Details == Series: series starting with [v3] drm/i915: Rename engines to match their user interface (rev3) URL : https://patchwork.freedesktop.org/series/64824/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6646_full -> Patchwork_13897_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13897_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13897_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_13897_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] +8 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: - shard-kbl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-kbl7/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-kbl6/igt@kms_atomic_transit...@1x-modeset-transitions-nonblocking-fencing.html Warnings * igt@gem_mocs_settings@mocs-reset-bsd2: - shard-iclb: [SKIP][5] ([fdo#109276]) -> [FAIL][6] +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb4/igt@gem_mocs_setti...@mocs-reset-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-iclb1/igt@gem_mocs_setti...@mocs-reset-bsd2.html New tests - New tests have been introduced between CI_DRM_6646_full and Patchwork_13897_full: ### New IGT tests (2) ### * igt@i915_selftest@live_gt_engines: - Statuses : 7 pass(s) - Exec time: [0.35, 1.95] s * igt@i915_selftest@live_gt_timelines: - Statuses : 7 pass(s) - Exec time: [3.50, 19.37] s Known issues Here are the changes found in Patchwork_13897_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_reuse@contexts: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#109100]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb3/igt@gem_exec_re...@contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-iclb7/igt@gem_exec_re...@contexts.html * igt@gem_exec_schedule@semaphore-noskip: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#110946]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb2/igt@gem_exec_sched...@semaphore-noskip.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-iclb2/igt@gem_exec_sched...@semaphore-noskip.html * igt@i915_pm_rps@reset: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#102250] / [fdo#108059]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb7/igt@i915_pm_...@reset.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-iclb1/igt@i915_pm_...@reset.html * igt@i915_selftest@live_hangcheck: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#108569]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-iclb6/igt@i915_selftest@live_hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-iclb7/igt@i915_selftest@live_hangcheck.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#110741]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][17] -> [INCOMPLETE][18] ([fdo#103665]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-kbl7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-kbl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-snb: [PASS][19] -> [INCOMPLETE][20] ([fdo#105411]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6646/shard-snb1/igt@kms_f...@flip-vs-suspend-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13897/shard-snb1/igt@kms_f...@flip-vs-suspend-interruptible.html
[Intel-gfx] ✓ Fi.CI.BAT: success for Refactor to expand subslice mask (rev 2)
== Series Details ==
Series: Refactor to expand subslice mask (rev 2)
URL : https://patchwork.freedesktop.org/series/64858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13905
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/
Known issues
Here are the changes found in Patchwork_13905 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-wait-default:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_exec_fe...@basic-wait-default.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-icl-u3/igt@gem_exec_fe...@basic-wait-default.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-blb-e6850/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][5] -> [DMESG-WARN][6] ([fdo#102614])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
- fi-icl-u2: [PASS][7] -> [FAIL][8] ([fdo#103167])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [PASS][9] -> [SKIP][10] ([fdo#109271]) +23 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [INCOMPLETE][11] ([fdo#110566]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
* igt@gem_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_tiled_bl...@basic.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-icl-u3/igt@gem_tiled_bl...@basic.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [SKIP][15] ([fdo#109271] / [fdo#109278]) ->
[PASS][16] +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][17] ([fdo#109485]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_vgem@basic-wait-default:
- {fi-icl-dsi}: [DMESG-WARN][19] ([fdo#106107]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13905/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
Participating hosts (55 -> 47)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI:
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Hardening firmware fetch
Quoting Michal Wajdeczko (2019-08-07 19:37:59) > Insert few more failure points into firmware fetch procedure to check > use of the wrong blob name or use of the mismatched firmware versions. > > Also update some messages (remove ptr, duplicated infos) and stop > treating all fetch errors as missing firmware case. > > v2: update log levels (Chris) > > Signed-off-by: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/uc: Hardening firmware fetch
Insert few more failure points into firmware fetch procedure to check
use of the wrong blob name or use of the mismatched firmware versions.
Also update some messages (remove ptr, duplicated infos) and stop
treating all fetch errors as missing firmware case.
v2: update log levels (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 142 +++
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +
2 files changed, 98 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3a3803bfa5a8..a8007d622f57 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -153,20 +153,23 @@ static const char *__override_huc_firmware_path(void)
return "";
}
-static bool
-__uc_fw_override(struct intel_uc_fw *uc_fw)
+static void __uc_fw_user_override(struct intel_uc_fw *uc_fw)
{
+ const char *path = NULL;
+
switch (uc_fw->type) {
case INTEL_UC_FW_TYPE_GUC:
- uc_fw->path = __override_guc_firmware_path();
+ path = __override_guc_firmware_path();
break;
case INTEL_UC_FW_TYPE_HUC:
- uc_fw->path = __override_huc_firmware_path();
+ path = __override_huc_firmware_path();
break;
}
- uc_fw->user_overridden = uc_fw->path;
- return uc_fw->user_overridden;
+ if (unlikely(path)) {
+ uc_fw->path = path;
+ uc_fw->user_overridden = true;
+ }
}
/**
@@ -194,8 +197,10 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
uc_fw->type = type;
- if (supported && likely(!__uc_fw_override(uc_fw)))
+ if (supported) {
__uc_fw_auto_select(uc_fw, platform, rev);
+ __uc_fw_user_override(uc_fw);
+ }
if (uc_fw->path && *uc_fw->path)
uc_fw->status = INTEL_UC_FIRMWARE_SELECTED;
@@ -203,6 +208,41 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
uc_fw->status = INTEL_UC_FIRMWARE_NOT_SUPPORTED;
}
+static void __force_fw_fetch_failures(struct intel_uc_fw *uc_fw,
+ struct drm_i915_private *i915, bool user)
+{
+ int e = user ? -EINVAL : -ESTALE;
+
+ if (i915_inject_load_error(i915, e)) {
+ /* non-existing blob */
+ uc_fw->path = "";
+ uc_fw->user_overridden = user;
+ } else if (i915_inject_load_error(i915, e)) {
+ /* require next major version */
+ uc_fw->major_ver_wanted += 1;
+ uc_fw->minor_ver_wanted = 0;
+ uc_fw->user_overridden = user;
+ } else if (i915_inject_load_error(i915, e)) {
+ /* require next minor version */
+ uc_fw->minor_ver_wanted += 1;
+ uc_fw->user_overridden = user;
+ } else if (uc_fw->major_ver_wanted && i915_inject_load_error(i915, e)) {
+ /* require prev major version */
+ uc_fw->major_ver_wanted -= 1;
+ uc_fw->minor_ver_wanted = 0;
+ uc_fw->user_overridden = user;
+ } else if (uc_fw->minor_ver_wanted && i915_inject_load_error(i915, e)) {
+ /* require prev minor version - hey, this should work! */
+ uc_fw->minor_ver_wanted -= 1;
+ uc_fw->user_overridden = user;
+ } else if (user && i915_inject_load_error(i915, e)) {
+ /* officially unsupported platform */
+ uc_fw->major_ver_wanted = 0;
+ uc_fw->minor_ver_wanted = 0;
+ uc_fw->user_overridden = true;
+ }
+}
+
/**
* intel_uc_fw_fetch - fetch uC firmware
* @uc_fw: uC firmware
@@ -214,6 +254,7 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
*/
int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct drm_i915_private *i915)
{
+ struct device *dev = i915->drm.dev;
struct drm_i915_gem_object *obj;
const struct firmware *fw = NULL;
struct uc_css_header *css;
@@ -222,17 +263,21 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
GEM_BUG_ON(!intel_uc_fw_supported(uc_fw));
- err = request_firmware(, uc_fw->path, i915->drm.dev);
+ err = i915_inject_load_error(i915, -ENXIO);
if (err)
- goto fail;
+ return err;
- DRM_DEBUG_DRIVER("%s fw size %zu ptr %p\n",
-intel_uc_fw_type_repr(uc_fw->type), fw->size, fw);
+ __force_fw_fetch_failures(uc_fw, i915, true);
+ __force_fw_fetch_failures(uc_fw, i915, false);
+
+ err = request_firmware(, uc_fw->path, dev);
+ if (err)
+ goto fail;
/* Check the size of the blob before examining buffer contents */
- if (fw->size < sizeof(struct uc_css_header)) {
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Refactor oa object to better manage resources (rev6)
== Series Details ==
Series: drm/i915/perf: Refactor oa object to better manage resources (rev6)
URL : https://patchwork.freedesktop.org/series/60176/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13904
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/
Known issues
Here are the changes found in Patchwork_13904 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#103167])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [PASS][3] -> [SKIP][4] ([fdo#109271]) +23 similar
issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [INCOMPLETE][5] ([fdo#110566]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
* igt@gem_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_tiled_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/fi-icl-u3/igt@gem_tiled_bl...@basic.html
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: [SKIP][9] ([fdo#109271] / [fdo#109278]) -> [PASS][10]
+2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
* igt@prime_vgem@basic-wait-default:
- {fi-icl-dsi}: [DMESG-WARN][11] ([fdo#106107]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
Participating hosts (55 -> 46)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6649 -> Patchwork_13904
CI-20190529: 20190529
CI_DRM_6649: 47b76298b3b6a5240d37f4e3f0182a2d47069d42 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5125: 35d81d01b1599b4bc4df0e09e25f6f531eed4f8a @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_13904: ae33771060e0462c2b49a81d2945d24d7db2d9b9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ae33771060e0 drm/i915/perf: Refactor oa object to better manage resources
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13904/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Hardening firmware fetch
== Series Details ==
Series: Hardening firmware fetch
URL : https://patchwork.freedesktop.org/series/64856/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6649 -> Patchwork_13903
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_13903 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_13903, 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_13903/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13903:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- fi-skl-6260u: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-skl-6260u/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-skl-6260u/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_13903 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@bad-close:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_ba...@bad-close.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-icl-u3/igt@gem_ba...@bad-close.html
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_selftest@live_reset:
- fi-icl-u2: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u2/igt@i915_selftest@live_reset.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-icl-u2/igt@i915_selftest@live_reset.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][9] -> [WARN][10] ([fdo#109380])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][11] -> [FAIL][12] ([fdo#103167])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][13] -> [SKIP][14] ([fdo#109271]) +23 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Possible fixes
* igt@gem_ctx_create@basic-files:
- fi-cml-u: [INCOMPLETE][15] ([fdo#110566]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-cml-u/igt@gem_ctx_cre...@basic-files.html
* igt@gem_tiled_blits@basic:
- fi-icl-u3: [DMESG-WARN][17] ([fdo#107724]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-u3/igt@gem_tiled_bl...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-icl-u3/igt@gem_tiled_bl...@basic.html
* igt@prime_vgem@basic-wait-default:
- {fi-icl-dsi}: [DMESG-WARN][19] ([fdo#106107]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6649/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13903/fi-icl-dsi/igt@prime_v...@basic-wait-default.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109271]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Refactor to expand subslice mask (rev 2)
== Series Details == Series: Refactor to expand subslice mask (rev 2) URL : https://patchwork.freedesktop.org/series/64858/ State : warning == Summary == $ dim checkpatch origin/drm-tip 98fa1b8ef9ca drm/i915: Use variable for debugfs device status 73dd1f518679 drm/i915: Add function to set SSEU info per platform 617a23ac375f drm/i915: Add subslice stride runtime parameter 73a23ff180b7 drm/i915: Add EU stride runtime parameter 07e06271d0c6 drm/i915: Add function to set subslices 4f88b7577d6e drm/i915: Add function to determine if a slice has a subslice f03d0837a0de drm/i915: Refactor instdone loops on new subslice functions -:60: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'subslice__' - possible side-effects? #60: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:551: +#define instdone_has_subslice(dev_priv__, sseu__, slice__, subslice__) \ + (IS_GEN(dev_priv__, 7) ? (1 & BIT(subslice__)) : \ +intel_sseu_has_subslice(sseu__, 0, subslice__)) -:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv_' - possible side-effects? #64: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:555: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) -:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'sseu_' - possible side-effects? #64: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:555: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) -:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'slice_' - possible side-effects? #64: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:555: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) -:64: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'subslice_' - possible side-effects? #64: FILE: drivers/gpu/drm/i915/gt/intel_engine_types.h:555: +#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \ + for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \ +(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \ +(slice_) += ((subslice_) == 0)) \ + for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \ + (instdone_has_subslice(dev_priv_, sseu_, slice_, \ + subslice_))) total: 0 errors, 0 warnings, 5 checks, 106 lines checked 62bc8cbde24b drm/i915: Add new function to copy subslices for a slice f0790c8c27fc drm/i915: Expand subslice mask ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: split out intel_pch.[ch] from i915_drv.[ch]
On Wed, 2019-08-07 at 15:04 +0300, Jani Nikula wrote:
> Abstract the rather self-contained piece of code from i915_drv.[ch].
> No
> functional changes.
>
Reviewed-by: José Roberto de Souza
> Cc: José Roberto de Souza
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/i915_drv.c | 194 -
> drivers/gpu/drm/i915/i915_drv.h | 60 +
> drivers/gpu/drm/i915/intel_pch.c | 201
> +++
> drivers/gpu/drm/i915/intel_pch.h | 73 +++
> 5 files changed, 276 insertions(+), 253 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_pch.c
> create mode 100644 drivers/gpu/drm/i915/intel_pch.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> index 8fe157f71617..7f710415a525 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -48,6 +48,7 @@ i915-y += i915_drv.o \
> i915_sysfs.o \
> intel_csr.o \
> intel_device_info.o \
> + intel_pch.o \
> intel_pm.o \
> intel_runtime_pm.o \
> intel_sideband.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c
> b/drivers/gpu/drm/i915/i915_drv.c
> index 535209ee4741..5807c1a0dab1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -150,200 +150,6 @@ __i915_printk(struct drm_i915_private
> *dev_priv, const char *level,
> }
> }
>
> -/* Map PCH device id to PCH type, or PCH_NONE if unknown. */
> -static enum intel_pch
> -intel_pch_type(const struct drm_i915_private *dev_priv, unsigned
> short id)
> -{
> - switch (id) {
> - case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> - WARN_ON(!IS_GEN(dev_priv, 5));
> - return PCH_IBX;
> - case INTEL_PCH_CPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found CougarPoint PCH\n");
> - WARN_ON(!IS_GEN(dev_priv, 6) &&
> !IS_IVYBRIDGE(dev_priv));
> - return PCH_CPT;
> - case INTEL_PCH_PPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found PantherPoint PCH\n");
> - WARN_ON(!IS_GEN(dev_priv, 6) &&
> !IS_IVYBRIDGE(dev_priv));
> - /* PantherPoint is CPT compatible */
> - return PCH_CPT;
> - case INTEL_PCH_LPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found LynxPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
> - return PCH_LPT;
> - case INTEL_PCH_LPT_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) &&
> !IS_BDW_ULT(dev_priv));
> - return PCH_LPT;
> - case INTEL_PCH_WPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
> - /* WildcatPoint is LPT compatible */
> - return PCH_LPT;
> - case INTEL_PCH_WPT_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) &&
> !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) &&
> !IS_BDW_ULT(dev_priv));
> - /* WildcatPoint is LPT compatible */
> - return PCH_LPT;
> - case INTEL_PCH_SPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) &&
> !IS_KABYLAKE(dev_priv));
> - return PCH_SPT;
> - case INTEL_PCH_SPT_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) &&
> !IS_KABYLAKE(dev_priv));
> - return PCH_SPT;
> - case INTEL_PCH_KBP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv)
> &&
> - !IS_COFFEELAKE(dev_priv));
> - /* KBP is SPT compatible */
> - return PCH_SPT;
> - case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> - WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> !IS_COFFEELAKE(dev_priv));
> - return PCH_CNP;
> - case INTEL_PCH_CNP_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> - WARN_ON(!IS_CANNONLAKE(dev_priv) &&
> !IS_COFFEELAKE(dev_priv));
> - return PCH_CNP;
> - case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> - WARN_ON(!IS_COFFEELAKE(dev_priv));
> - /* CometPoint is CNP Compatible */
> -
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: Refactor oa object to better manage resources (rev6)
== Series Details == Series: drm/i915/perf: Refactor oa object to better manage resources (rev6) URL : https://patchwork.freedesktop.org/series/60176/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/perf: Refactor oa object to better manage resources +drivers/gpu/drm/i915/i915_perf.c:1435:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1494:15: warning: memset with byte count of 16777216 -O:drivers/gpu/drm/i915/i915_perf.c:1430:15: warning: memset with byte count of 16777216 -O:drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 ___ 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/perf: Refactor oa object to better manage resources (rev6)
== Series Details ==
Series: drm/i915/perf: Refactor oa object to better manage resources (rev6)
URL : https://patchwork.freedesktop.org/series/60176/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ae33771060e0 drm/i915/perf: Refactor oa object to better manage resources
-:523: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around
'stream->oa_buffer.last_ctx_id ==
stream->specific_ctx_id'
#523: FILE: drivers/gpu/drm/i915/i915_perf.c:791:
+ if (!dev_priv->perf.exclusive_stream->ctx ||
+ stream->specific_ctx_id == ctx_id ||
+ (stream->oa_buffer.last_ctx_id ==
+ stream->specific_ctx_id) ||
reason & OAREPORT_REASON_CTX_SWITCH) {
-:876: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON &
recovery code rather than BUG() or BUG_ON()
#876: FILE: drivers/gpu/drm/i915/i915_perf.c:1366:
+ BUG_ON(stream != dev_priv->perf.exclusive_stream);
-:1387: ERROR:CODE_INDENT: code indent should use tabs where possible
#1387: FILE: drivers/gpu/drm/i915/i915_perf.c:2438:
+^I^I poll_check_timer);$
-:1556: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#1556: FILE: drivers/gpu/drm/i915/i915_perf.c:3613:
+ dev_priv->perf.gen8_valid_ctx_bit = (1<<25);
^
-:1564: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#1564: FILE: drivers/gpu/drm/i915/i915_perf.c:3618:
+ dev_priv->perf.gen8_valid_ctx_bit = (1<<16);
^
-:1594: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#1594: FILE: drivers/gpu/drm/i915/i915_perf.c:3638:
+ dev_priv->perf.gen8_valid_ctx_bit = (1<<16);
^
-:1615: ERROR:CODE_INDENT: code indent should use tabs where possible
#1615: FILE: drivers/gpu/drm/i915/i915_perf.c:3653:
+ ^I^I/* We set up some ratelimit state to potentially throttle any$
-:1615: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1615: FILE: drivers/gpu/drm/i915/i915_perf.c:3653:
+ ^I^I/* We set up some ratelimit state to potentially throttle any$
-:1615: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#1615: FILE: drivers/gpu/drm/i915/i915_perf.c:3653:
+ ^I^I/* We set up some ratelimit state to potentially throttle any$
-:1616: ERROR:CODE_INDENT: code indent should use tabs where possible
#1616: FILE: drivers/gpu/drm/i915/i915_perf.c:3654:
+ ^I^I * _NOTES about spurious, invalid OA reports which we don't$
-:1616: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1616: FILE: drivers/gpu/drm/i915/i915_perf.c:3654:
+ ^I^I * _NOTES about spurious, invalid OA reports which we don't$
-:1617: ERROR:CODE_INDENT: code indent should use tabs where possible
#1617: FILE: drivers/gpu/drm/i915/i915_perf.c:3655:
+ ^I^I * forward to userspace.$
-:1617: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1617: FILE: drivers/gpu/drm/i915/i915_perf.c:3655:
+ ^I^I * forward to userspace.$
-:1618: ERROR:CODE_INDENT: code indent should use tabs where possible
#1618: FILE: drivers/gpu/drm/i915/i915_perf.c:3656:
+ ^I^I *$
-:1618: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1618: FILE: drivers/gpu/drm/i915/i915_perf.c:3656:
+ ^I^I *$
-:1619: ERROR:CODE_INDENT: code indent should use tabs where possible
#1619: FILE: drivers/gpu/drm/i915/i915_perf.c:3657:
+ ^I^I * We print a _NOTE about any throttling when closing the$
-:1619: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1619: FILE: drivers/gpu/drm/i915/i915_perf.c:3657:
+ ^I^I * We print a _NOTE about any throttling when closing the$
-:1620: ERROR:CODE_INDENT: code indent should use tabs where possible
#1620: FILE: drivers/gpu/drm/i915/i915_perf.c:3658:
+ ^I^I * stream instead of waiting until driver _fini which no one$
-:1620: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1620: FILE: drivers/gpu/drm/i915/i915_perf.c:3658:
+ ^I^I * stream instead of waiting until driver _fini which no one$
-:1621: ERROR:CODE_INDENT: code indent should use tabs where possible
#1621: FILE: drivers/gpu/drm/i915/i915_perf.c:3659:
+ ^I^I * would ever see.$
-:1621: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1621: FILE: drivers/gpu/drm/i915/i915_perf.c:3659:
+ ^I^I * would ever see.$
-:1622: ERROR:CODE_INDENT: code indent should use tabs where possible
#1622: FILE: drivers/gpu/drm/i915/i915_perf.c:3660:
+ ^I^I *$
-:1622: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1622: FILE: drivers/gpu/drm/i915/i915_perf.c:3660:
+ ^I^I *$
-:1623: ERROR:CODE_INDENT: code indent should use tabs where possible
#1623: FILE: drivers/gpu/drm/i915/i915_perf.c:3661:
+ ^I^I * Using the same limiting factors as printk_ratelimit()$
-:1623: WARNING:SPACE_BEFORE_TAB: please, no space before
Re: [Intel-gfx] [PATCH 7/7] drm/i915/uc: Hardening firmware fetch
Quoting Michal Wajdeczko (2019-08-07 18:00:34)
> Insert few more failure points into firmware fetch procedure to check
> use of the wrong blob name or use of the mismatched firmware versions.
>
> Also update some messages (remove ptr, duplicated infos) and stop
> treating all fetch errors as missing firmware case.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 137 ---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +
> 2 files changed, 97 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> index 3a3803bfa5a8..4faff1010398 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
> @@ -153,20 +153,23 @@ static const char *__override_huc_firmware_path(void)
> return "";
> }
>
> -static bool
> -__uc_fw_override(struct intel_uc_fw *uc_fw)
> +static void __uc_fw_user_override(struct intel_uc_fw *uc_fw)
> {
> + const char *path = NULL;
> +
> switch (uc_fw->type) {
> case INTEL_UC_FW_TYPE_GUC:
> - uc_fw->path = __override_guc_firmware_path();
> + path = __override_guc_firmware_path();
> break;
> case INTEL_UC_FW_TYPE_HUC:
> - uc_fw->path = __override_huc_firmware_path();
> + path = __override_huc_firmware_path();
> break;
> }
>
> - uc_fw->user_overridden = uc_fw->path;
> - return uc_fw->user_overridden;
> + if (unlikely(path)) {
> + uc_fw->path = path;
> + uc_fw->user_overridden = true;
> + }
The code got longer for no real improvement in clarity?
Oh, because now uc_fw->path may be non-NULL on entry due to call
reordering.
> }
>
> /**
> @@ -194,8 +197,10 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
>
> uc_fw->type = type;
>
> - if (supported && likely(!__uc_fw_override(uc_fw)))
> + if (supported) {
> __uc_fw_auto_select(uc_fw, platform, rev);
> + __uc_fw_user_override(uc_fw);
> + }
>
> if (uc_fw->path && *uc_fw->path)
> uc_fw->status = INTEL_UC_FIRMWARE_SELECTED;
> @@ -203,6 +208,41 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
> uc_fw->status = INTEL_UC_FIRMWARE_NOT_SUPPORTED;
> }
>
> +static void __force_fw_fetch_failures(struct intel_uc_fw *uc_fw,
> + struct drm_i915_private *i915, bool
> user)
> +{
> + int e = user ? -EINVAL : -ESTALE;
> +
> + if (i915_inject_load_error(i915, e)) {
> + /* non-existing blob */
> + uc_fw->path = "";
> + uc_fw->user_overridden = user;
> + } else if (i915_inject_load_error(i915, e)) {
> + /* require next major version */
> + uc_fw->major_ver_wanted += 1;
> + uc_fw->minor_ver_wanted = 0;
> + uc_fw->user_overridden = user;
> + } else if (i915_inject_load_error(i915, e)) {
> + /* require next minor version */
> + uc_fw->minor_ver_wanted += 1;
> + uc_fw->user_overridden = user;
> + } else if (uc_fw->major_ver_wanted && i915_inject_load_error(i915,
> e)) {
> + /* require prev major version */
> + uc_fw->major_ver_wanted -= 1;
> + uc_fw->minor_ver_wanted = 0;
> + uc_fw->user_overridden = user;
> + } else if (uc_fw->minor_ver_wanted && i915_inject_load_error(i915,
> e)) {
> + /* require prev minor version - hey, this should work! */
> + uc_fw->minor_ver_wanted -= 1;
> + uc_fw->user_overridden = user;
> + } else if (user && i915_inject_load_error(i915, e)) {
> + /* officially unsupported platform */
> + uc_fw->major_ver_wanted = 0;
> + uc_fw->minor_ver_wanted = 0;
> + uc_fw->user_overridden = true;
> + }
Taking self-abuse to a whole new level :)
> +}
> +
> /**
> * intel_uc_fw_fetch - fetch uC firmware
> * @uc_fw: uC firmware
> @@ -222,17 +262,22 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
> drm_i915_private *i915)
>
> GEM_BUG_ON(!intel_uc_fw_supported(uc_fw));
>
> + err = i915_inject_load_error(i915, -ENXIO);
> + if (err)
> + return err;
> +
> + __force_fw_fetch_failures(uc_fw, i915, true);
> + __force_fw_fetch_failures(uc_fw, i915, false);
Ok. The set of major/minor/user_override make some sort of sense to me,
but I couldn't say if that's a complete set or not.
> @@ -292,29 +343,22 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
> drm_i915_private *i915)
> break;
> }
>
> - DRM_DEBUG_DRIVER("%s fw version %u.%u (wanted %u.%u)\n",
Re: [Intel-gfx] [PATCH 6/7] drm/i915/uc: WOPCM programming errors are not always real
Quoting Michal Wajdeczko (2019-08-07 18:00:33) > WOPCM programming error might be due to inserted earlier probe > failure that could affects HuC firmware loading and thus impacts > result of WOPCM partitioning that would be now incompatible with > previously programmed values. > > Signed-off-by: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Chris Wilson Reviewed-by: Chris Wilson Look, I made no comments regarding whether the errors were real anyway. Oops. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make wopcm_to_i915() private
Quoting Michal Wajdeczko (2019-08-07 18:00:32) > No need to define it globally as we're only using it in wopcm.c > > Signed-off-by: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Don't try to partition WOPCM without GuC firmware
Quoting Michal Wajdeczko (2019-08-07 18:00:31) > For meaningful WOPCM partitioning we need GuC (and optionally HuC) > firmware size(s) and we shouldn't just rely on GuC support flag, > as we might fail to fetch GuC firmware and it's size will be 0 > and all calculations will be just wrong/useless. > > Signed-off-by: Michal Wajdeczko > Cc: Daniele Ceraolo Spurio > Cc: Chris Wilson > --- > drivers/gpu/drm/i915/intel_wopcm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_wopcm.c > b/drivers/gpu/drm/i915/intel_wopcm.c > index 4c22143ee84f..5e5c3fd3472d 100644 > --- a/drivers/gpu/drm/i915/intel_wopcm.c > +++ b/drivers/gpu/drm/i915/intel_wopcm.c > @@ -170,7 +170,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm) > u32 guc_wopcm_rsvd; > int err; > > - if (!USES_GUC(i915)) > + if (!guc_fw_size) > return; It looks like the calculations with huc_fw_size=0 are fine, just hope the fw agrees. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915/uc: Don't fetch HuC fw if GuC fw fetch already failed
Quoting Michal Wajdeczko (2019-08-07 18:00:30)
> When we failed to fetch GuC firmware there is no point in fetching
> HuC firmware as we will not be able to use it without working GuC.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc.c| 5 -
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +---
> drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +--
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index 3c007e0e1a20..c40eab290342 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -283,11 +283,14 @@ static void guc_disable_communication(struct intel_guc
> *guc)
> void intel_uc_fetch_firmwares(struct intel_uc *uc)
> {
> struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
> + int err;
>
> if (!intel_uc_supports_guc(uc))
> return;
>
> - intel_uc_fw_fetch(>guc.fw, i915);
> + err = intel_uc_fw_fetch(>guc.fw, i915);
> + if (err)
> + return;
We still don't care about the err, just that it exists.
if (intel_uc_fw_fetch() return; ?
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/7] drm/i915/uc: HuC firmware can't be supported without GuC
Quoting Michal Wajdeczko (2019-08-07 18:00:29)
> There is no point in selecting HuC firmware if GuC is unsupported
> or it was already disabled, as we need GuC to authenticate HuC.
Makes sense.
> While around, make uc_fw_init_early work without direct access
> to whole i915, pass only needed platform/rev info.
Hmm. When I've been briefly thinking about this, I've contemplated
passing around the *{ intel_device_info, intel_runtime_info }
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
Looks ok, but I wouldn't be surprised if we came up with an alternative
approach to passing the feature flags around later (on a wider scale).
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915/uc: Prefer dev_info for reporting options
Quoting Michal Wajdeczko (2019-08-07 18:00:28)
> While modparams are global for the i915 module, we are reporting
> status of the params applied against specific device instance.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> index e87b7904ab7a..3c007e0e1a20 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> @@ -59,11 +59,14 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
>
> static void __confirm_options(struct intel_uc *uc)
> {
> - DRM_DEBUG_DRIVER("enable_guc=%d (guc:%s submission:%s huc:%s)\n",
> -i915_modparams.enable_guc,
> -yesno(intel_uc_supports_guc(uc)),
> -yesno(intel_uc_supports_guc_submission(uc)),
> -yesno(intel_uc_supports_huc(uc)));
> + struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
> +
> + DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
> +"enable_guc=%d (guc:%s submission:%s huc:%s)\n",
> +i915_modparams.enable_guc,
> +yesno(intel_uc_supports_guc(uc)),
> +yesno(intel_uc_supports_guc_submission(uc)),
> +yesno(intel_uc_supports_huc(uc)));
DDD_DRIVER()? :)
> if (i915_modparams.enable_guc == -1)
> return;
> @@ -76,22 +79,26 @@ static void __confirm_options(struct intel_uc *uc)
> }
>
> if (!intel_uc_supports_guc(uc))
> - DRM_INFO("Incompatible option enable_guc=%d - %s\n",
> + dev_info(i915->drm.dev,
> +"Incompatible option enable_guc=%d - %s\n",
> i915_modparams.enable_guc, "GuC is not supported!");
>
> if (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC &&
> !intel_uc_supports_huc(uc))
> - DRM_INFO("Incompatible option enable_guc=%d - %s\n",
> + dev_info(i915->drm.dev,
> +"Incompatible option enable_guc=%d - %s\n",
> i915_modparams.enable_guc, "HuC is not supported!");
>
> if (i915_modparams.enable_guc & ENABLE_GUC_SUBMISSION &&
> !intel_uc_supports_guc_submission(uc))
> - DRM_INFO("Incompatible option enable_guc=%d - %s\n",
> + dev_info(i915->drm.dev,
> +"Incompatible option enable_guc=%d - %s\n",
> i915_modparams.enable_guc, "GuC submission is N/A");
>
> if (i915_modparams.enable_guc & ~(ENABLE_GUC_SUBMISSION |
> ENABLE_GUC_LOAD_HUC))
> - DRM_INFO("Incompatible option enable_guc=%d - %s\n",
> + dev_info(i915->drm.dev,
> +"Incompatible option enable_guc=%d - %s\n",
> i915_modparams.enable_guc, "undocumented flag");
Yes, "confirm_options" fits the device model, as opposed to the old
sanitize that adjusted the global parameter.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Always request completion before marking an error
Due to fun and games in our preempt-to-busy, it is possible for a
request to be completed in the background. Be vigilant and avoid setting
an error on already signaled request, as dma_fence_set_error() throws a
warning.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 2b97641feac3..abdb3e8fd19f 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -224,6 +224,13 @@ static void execlists_init_reg_state(u32 *reg_state,
struct intel_engine_cs *engine,
struct intel_ring *ring);
+static void mark_eio(struct i915_request *rq)
+{
+ if (!i915_request_signaled(rq))
+ dma_fence_set_error(>fence, -EIO);
+ i915_request_mark_complete(rq);
+}
+
static inline u32 intel_hws_preempt_address(struct intel_engine_cs *engine)
{
return (i915_ggtt_offset(engine->status_page.vma) +
@@ -2396,12 +2403,8 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
__execlists_reset(engine, true);
/* Mark all executing requests as skipped. */
- list_for_each_entry(rq, >active.requests, sched.link) {
- if (!i915_request_signaled(rq))
- dma_fence_set_error(>fence, -EIO);
-
- i915_request_mark_complete(rq);
- }
+ list_for_each_entry(rq, >active.requests, sched.link)
+ mark_eio(rq);
/* Flush the queued requests to the timeline list (for retiring). */
while ((rb = rb_first_cached(>queue))) {
@@ -2411,8 +2414,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
priolist_for_each_request_consume(rq, rn, p, i) {
list_del_init(>sched.link);
__i915_request_submit(rq);
- dma_fence_set_error(>fence, -EIO);
- i915_request_mark_complete(rq);
+ mark_eio(rq);
}
rb_erase_cached(>node, >queue);
@@ -2431,8 +2433,7 @@ static void execlists_cancel_requests(struct
intel_engine_cs *engine)
if (ve->request) {
ve->request->engine = engine;
__i915_request_submit(ve->request);
- dma_fence_set_error(>request->fence, -EIO);
- i915_request_mark_complete(ve->request);
+ mark_eio(ve->request);
ve->base.execlists.queue_priority_hint = INT_MIN;
ve->request = NULL;
}
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
> -Original Message-
> From: Chris Wilson
> Sent: Wednesday, August 7, 2019 9:51 AM
> To: Bloomfield, Jon ; intel-
> g...@lists.freedesktop.org
> Cc: Joonas Lahtinen ; Winiarski, Michal
>
> Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
>
> Quoting Bloomfield, Jon (2019-08-07 16:29:55)
> > > -Original Message-
> > > From: Chris Wilson
> > > Sent: Wednesday, August 7, 2019 8:08 AM
> > > To: Bloomfield, Jon ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Joonas Lahtinen ; Winiarski, Michal
> > >
> > > Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
> > >
> > > Quoting Bloomfield, Jon (2019-08-07 15:33:51)
> > > [skip to end]
> > > > We didn't explore the idea of terminating orphaned contexts though
> > > (where none of their resources are referenced by any other contexts). Is
> > > there a reason why this is not feasible? In the case of compute (certainly
> > > HPC) workloads, there would be no compositor taking the output so this
> > > might be a solution.
> > >
> > > Sounds easier said than done. We have to go through each request and
> > > determine it if has an external reference (or if the object holding the
> > > reference has an external reference) to see if the output would be
> > > visible to a third party. Sounds like a conservative GC :|
> > > (Coming to that conclusion suggests that we should structure the request
> > > tracking to make reparenting easier.)
> > >
> > > We could take a pid-1 approach and move all the orphan timelines over to
> > > a new parent purely responsible for them. That honestly doesn't seem to
> > > achieve anything. (We are still stuck with tasks on the GPU and no way
> > > to kill them.)
> > >
> > > In comparison, persistence is a rarely used "feature" and cleaning up on
> > > context close fits in nicely with the process model. It just works as
> > > most users/clients would expect. (Although running in non-persistent
> > > by default hasn't show anything to explode on the desktop, it's too easy
> > > to construct scenarios where persistence turns out to be an advantage,
> > > particularly with chains of clients (the compositor model).) Between the
> > > two modes, we should have most bases covered, it's hard to argue for a
> > > third way (that is until someone has a usecase!)
> > > -Chris
> >
> > Ok, makes sense. Thanks.
> >
> > But have we converged on a decision :-)
> >
> > As I said, requiring compute umd optin should be ok for the immediate HPC
> issue, but I'd personally argue that it's valid to change the contract for
> hangcheck=0 and switch the default to non-persistent.
>
> Could you tender
>
> diff --git a/runtime/os_interface/linux/drm_neo.cpp
> b/runtime/os_interface/linux/drm_neo.cpp
> index 31deb68b..8a9af363 100644
> --- a/runtime/os_interface/linux/drm_neo.cpp
> +++ b/runtime/os_interface/linux/drm_neo.cpp
> @@ -141,11 +141,22 @@ void Drm::setLowPriorityContextParam(uint32_t
> drmContextId) {
> UNRECOVERABLE_IF(retVal != 0);
> }
>
> +void setNonPersistent(uint32_t drmContextId) {
> +drm_i915_gem_context_param gcp = {};
> +gcp.ctx_id = drmContextId;
> +gcp.param = 0xb; /* I915_CONTEXT_PARAM_PERSISTENCE; */
> +
> +ioctl(DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> +}
> +
> uint32_t Drm::createDrmContext() {
> drm_i915_gem_context_create gcc = {};
> auto retVal = ioctl(DRM_IOCTL_I915_GEM_CONTEXT_CREATE, );
> UNRECOVERABLE_IF(retVal != 0);
>
> +/* enable cleanup of resources on process termination */
> +setNonPersistent(gcc.ctx_id);
> +
> return gcc.ctx_id;
> }
>
> to interested parties?
> -Chris
Yes, that's exactly what I had in mind. I think it's enough to resolve the HPC
challenges.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/9] drm/i915: Add EU stride runtime parameter
Add a new SSEU runtime parameter, eu_stride, which is
used to mirror the userspace concept of a range of EUs
per subslice.
This patch simply adds the parameter and updates usage
in the QUERY_TOPOLOGY_INFO handler.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 1 +
drivers/gpu/drm/i915/gt/intel_sseu.h | 1 +
drivers/gpu/drm/i915/i915_query.c| 5 ++---
drivers/gpu/drm/i915/intel_device_info.c | 9 -
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 2d9e6fa4ee46..71abf0c9a46b 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -16,6 +16,7 @@ void intel_sseu_set_info(struct sseu_dev_info *sseu, u8
max_slices,
sseu->max_eus_per_subslice = max_eus_per_subslice;
sseu->ss_stride = GEN_SSEU_STRIDE(sseu->max_subslices);
+ sseu->eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
}
unsigned int
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index b0101e1c69bd..fe22d5b18e67 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -34,6 +34,7 @@ struct sseu_dev_info {
u8 max_eus_per_subslice;
u8 ss_stride;
+ u8 eu_stride;
/* We don't have more than 8 eus per subslice at the moment and as we
* store eus enabled using bits, no need to multiply by eus per
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index d8e25dcf5f0b..abac5042da2b 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -37,7 +37,6 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
- u8 eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
int ret;
if (query_item->flags != 0)
@@ -50,7 +49,7 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
slice_length = sizeof(sseu->slice_mask);
subslice_length = sseu->max_slices * sseu->ss_stride;
- eu_length = sseu->max_slices * sseu->max_subslices * eu_stride;
+ eu_length = sseu->max_slices * sseu->max_subslices * sseu->eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
@@ -70,7 +69,7 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.subslice_offset = slice_length;
topo.subslice_stride = sseu->ss_stride;
topo.eu_offset = slice_length + subslice_length;
- topo.eu_stride = eu_stride;
+ topo.eu_stride = sseu->eu_stride;
if (__copy_to_user(u64_to_user_ptr(query_item->data_ptr),
, sizeof(topo)))
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 9a79d9d547c5..7de7b7b540cb 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -118,10 +118,9 @@ void intel_device_info_dump_runtime(const struct
intel_runtime_info *info,
static int sseu_eu_idx(const struct sseu_dev_info *sseu, int slice,
int subslice)
{
- int subslice_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
- int slice_stride = sseu->max_subslices * subslice_stride;
+ int slice_stride = sseu->max_subslices * sseu->eu_stride;
- return slice * slice_stride + subslice * subslice_stride;
+ return slice * slice_stride + subslice * sseu->eu_stride;
}
static u16 sseu_get_eus(const struct sseu_dev_info *sseu, int slice,
@@ -130,7 +129,7 @@ static u16 sseu_get_eus(const struct sseu_dev_info *sseu,
int slice,
int i, offset = sseu_eu_idx(sseu, slice, subslice);
u16 eu_mask = 0;
- for (i = 0; i < GEN_SSEU_STRIDE(sseu->max_eus_per_subslice); i++) {
+ for (i = 0; i < sseu->eu_stride; i++) {
eu_mask |= ((u16)sseu->eu_mask[offset + i]) <<
(i * BITS_PER_BYTE);
}
@@ -143,7 +142,7 @@ static void sseu_set_eus(struct sseu_dev_info *sseu, int
slice, int subslice,
{
int i, offset = sseu_eu_idx(sseu, slice, subslice);
- for (i = 0; i < GEN_SSEU_STRIDE(sseu->max_eus_per_subslice); i++) {
+ for (i = 0; i < sseu->eu_stride; i++) {
sseu->eu_mask[offset + i] =
(eu_mask >> (BITS_PER_BYTE * i)) & 0xff;
}
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/9] Refactor to expand subslice mask (rev 2)
Currently, the subslice_mask runtime parameter is stored as an array of subslices per slice. Expand the subslice mask array to better match what is presented to userspace through the I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is then calculated: slice * subslice stride + subslice index / 8 Note this is the second iteration of an original patch to implement the same. There are a couple of minor code changes based on changes since the first series was posted. Additionally, the original patch has been split into several smaller patches with more isolated changes based on review feedback in that first series. Link to the original series: https://patchwork.freedesktop.org/series/59742/ v2: Fix 32-bit build v3: Fix typo in haswell sseu info routine and fix SSEU workaround print v4: Merge patch to HSW in previous revision with patch to set subslice_mask for each platform and address feedback from Chris Stuart Summers (9): drm/i915: Use variable for debugfs device status drm/i915: Add function to set SSEU info per platform drm/i915: Add subslice stride runtime parameter drm/i915: Add EU stride runtime parameter drm/i915: Add function to set subslices drm/i915: Add function to determine if a slice has a subslice drm/i915: Refactor instdone loops on new subslice functions drm/i915: Add new function to copy subslices for a slice drm/i915: Expand subslice mask drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 31 +++-- drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 48 +++- drivers/gpu/drm/i915/gt/intel_sseu.h | 24 +++- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +- drivers/gpu/drm/i915/i915_debugfs.c | 49 +--- drivers/gpu/drm/i915/i915_gpu_error.c| 5 +- drivers/gpu/drm/i915/i915_query.c| 10 +- drivers/gpu/drm/i915/intel_device_info.c | 122 +-- 10 files changed, 185 insertions(+), 113 deletions(-) -- 2.21.0.5.gaeb582a983 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 9/9] drm/i915: Expand subslice mask
Currently, the subslice_mask runtime parameter is stored as an
array of subslices per slice. Expand the subslice mask array to
better match what is presented to userspace through the
I915_QUERY_TOPOLOGY_INFO ioctl. The index into this array is
then calculated:
slice * subslice stride + subslice index / 8
v2: Fix 32-bit build
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c| 27 -
drivers/gpu/drm/i915/gt/intel_sseu.h| 5 +++-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +--
drivers/gpu/drm/i915/i915_debugfs.c | 5 +++-
drivers/gpu/drm/i915/intel_device_info.c| 8 +++---
5 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 607c1447287c..e426f34b4dd6 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -30,6 +30,31 @@ intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
return total;
}
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice)
+{
+ int i, offset = slice * sseu->ss_stride;
+ u32 mask = 0;
+
+ if (slice >= sseu->max_slices) {
+ DRM_ERROR("%s: invalid slice %d, max: %d\n",
+ __func__, slice, sseu->max_slices);
+ return 0;
+ }
+
+ if (sseu->ss_stride > sizeof(mask)) {
+ DRM_ERROR("%s: invalid subslice stride %d, max: %u\n",
+ __func__, sseu->ss_stride,
+(unsigned int)sizeof(mask));
+ return 0;
+ }
+
+ for (i = 0; i < sseu->ss_stride; i++)
+ mask |= (u32)sseu->subslice_mask[offset + i] <<
+ i * BITS_PER_BYTE;
+
+ return mask;
+}
+
void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
u32 ss_mask)
{
@@ -43,7 +68,7 @@ void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int
slice,
unsigned int
intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
{
- return hweight8(sseu->subslice_mask[slice]);
+ return hweight32(intel_sseu_get_subslices(sseu, slice));
}
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 0ecc1c35a7a1..2291764b7db5 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -15,10 +15,11 @@ struct drm_i915_private;
#define GEN_MAX_SLICES (6) /* CNL upper bound */
#define GEN_MAX_SUBSLICES (8) /* ICL upper bound */
#define GEN_SSEU_STRIDE(max_entries) DIV_ROUND_UP(max_entries, BITS_PER_BYTE)
+#define GEN_MAX_SUBSLICE_STRIDE GEN_SSEU_STRIDE(GEN_MAX_SUBSLICES)
struct sseu_dev_info {
u8 slice_mask;
- u8 subslice_mask[GEN_MAX_SLICES];
+ u8 subslice_mask[GEN_MAX_SLICES * GEN_MAX_SUBSLICE_STRIDE];
u16 eu_total;
u8 eu_per_subslice;
u8 min_eu_in_pool;
@@ -85,6 +86,8 @@ intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
unsigned int
intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice);
+u32 intel_sseu_get_subslices(const struct sseu_dev_info *sseu, u8 slice);
+
void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
u32 ss_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 704ace01e7f5..7ec60435d871 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -794,8 +794,7 @@ wa_init_mcr(struct drm_i915_private *i915, struct
i915_wa_list *wal)
}
slice = fls(sseu->slice_mask) - 1;
- GEM_BUG_ON(slice >= ARRAY_SIZE(sseu->subslice_mask));
- subslice = fls(l3_en & sseu->subslice_mask[slice]);
+ subslice = fls(l3_en & intel_sseu_get_subslices(sseu, slice));
if (!subslice) {
DRM_WARN("No common index found between subslice mask %x and L3
bank mask %x!\n",
sseu->subslice_mask[slice], l3_en);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a64cd181051f..88eb3ac47a2c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3879,13 +3879,16 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
+ u8 ss_idx = s * info->sseu.ss_stride +
+ ss / BITS_PER_BYTE;
if (IS_GEN9_LP(dev_priv)) {
if (!(s_reg[s] & (GEN9_PGCTL_SS_ACK(ss
/* skip disabled subslice */
continue;
-
[Intel-gfx] [PATCH 6/9] drm/i915: Add function to determine if a slice has a subslice
Add a new function to determine whether a particular slice
has a given subslice.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.h | 10 ++
drivers/gpu/drm/i915/intel_device_info.c | 9 -
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 2261d4e7d98b..0ecc1c35a7a1 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -66,6 +66,16 @@ intel_sseu_from_device_info(const struct sseu_dev_info *sseu)
return value;
}
+static inline bool
+intel_sseu_has_subslice(const struct sseu_dev_info *sseu, int slice,
+ int subslice)
+{
+ u8 mask = sseu->subslice_mask[slice * sseu->ss_stride +
+ subslice / BITS_PER_BYTE];
+
+ return mask & BIT(subslice % BITS_PER_BYTE);
+}
+
void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
u8 max_subslices, u8 max_eus_per_subslice);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 2320613a51ac..ff3d6508fd17 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -210,10 +210,9 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
intel_sseu_set_subslices(sseu, s, (ss_en >> ss_idx) &
ss_en_mask);
- for (ss = 0; ss < sseu->max_subslices; ss++) {
- if (sseu->subslice_mask[s] & BIT(ss))
+ for (ss = 0; ss < sseu->max_subslices; ss++)
+ if (intel_sseu_has_subslice(sseu, s, ss))
sseu_set_eus(sseu, s, ss, eu_en);
- }
}
}
sseu->eu_per_subslice = hweight8(eu_en);
@@ -395,7 +394,7 @@ static void gen9_sseu_info_init(struct drm_i915_private
*dev_priv)
int eu_per_ss;
u8 eu_disabled_mask;
- if (!(sseu->subslice_mask[s] & BIT(ss)))
+ if (!intel_sseu_has_subslice(sseu, s, ss))
/* skip disabled subslice */
continue;
@@ -501,7 +500,7 @@ static void broadwell_sseu_info_init(struct
drm_i915_private *dev_priv)
u8 eu_disabled_mask;
u32 n_disabled;
- if (!(sseu->subslice_mask[s] & BIT(ss)))
+ if (!intel_sseu_has_subslice(sseu, s, ss))
/* skip disabled subslice */
continue;
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/9] drm/i915: Add function to set SSEU info per platform
Add a new function to allow each platform to set maximum
slice, subslice, and EU information to reduce code duplication.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 8 +
drivers/gpu/drm/i915/gt/intel_sseu.h | 3 ++
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++--
drivers/gpu/drm/i915/intel_device_info.c | 39 +---
4 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index a0756f006f5f..08b74ae40739 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -8,6 +8,14 @@
#include "intel_lrc_reg.h"
#include "intel_sseu.h"
+void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
+u8 max_subslices, u8 max_eus_per_subslice)
+{
+ sseu->max_slices = max_slices;
+ sseu->max_subslices = max_subslices;
+ sseu->max_eus_per_subslice = max_eus_per_subslice;
+}
+
unsigned int
intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index b50d0401a4e2..64e47dad07be 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -63,6 +63,9 @@ intel_sseu_from_device_info(const struct sseu_dev_info *sseu)
return value;
}
+void intel_sseu_set_info(struct sseu_dev_info *sseu, u8 max_slices,
+u8 max_subslices, u8 max_eus_per_subslice);
+
unsigned int
intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c31b141656d6..94637ff1e8db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3965,9 +3965,9 @@ static int i915_sseu_status(struct seq_file *m, void
*unused)
seq_puts(m, "SSEU Device Status\n");
memset(, 0, sizeof(sseu));
- sseu.max_slices = info->sseu.max_slices;
- sseu.max_subslices = info->sseu.max_subslices;
- sseu.max_eus_per_subslice = info->sseu.max_eus_per_subslice;
+ intel_sseu_set_info(, info->sseu.max_slices,
+ info->sseu.max_subslices,
+ info->sseu.max_eus_per_subslice);
with_intel_runtime_pm(_priv->runtime_pm, wakeref) {
if (IS_CHERRYVIEW(dev_priv))
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index f99c9fd497b2..9a79d9d547c5 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -191,15 +191,10 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
u8 eu_en;
int s;
- if (IS_ELKHARTLAKE(dev_priv)) {
- sseu->max_slices = 1;
- sseu->max_subslices = 4;
- sseu->max_eus_per_subslice = 8;
- } else {
- sseu->max_slices = 1;
- sseu->max_subslices = 8;
- sseu->max_eus_per_subslice = 8;
- }
+ if (IS_ELKHARTLAKE(dev_priv))
+ intel_sseu_set_info(sseu, 1, 4, 8);
+ else
+ intel_sseu_set_info(sseu, 1, 8, 8);
s_en = I915_READ(GEN11_GT_SLICE_ENABLE) & GEN11_GT_S_ENA_MASK;
ss_en = ~I915_READ(GEN11_GT_SUBSLICE_DISABLE);
@@ -236,11 +231,10 @@ static void gen10_sseu_info_init(struct drm_i915_private
*dev_priv)
const int eu_mask = 0xff;
u32 subslice_mask, eu_en;
+ intel_sseu_set_info(sseu, 6, 4, 8);
+
sseu->slice_mask = (fuse2 & GEN10_F2_S_ENA_MASK) >>
GEN10_F2_S_ENA_SHIFT;
- sseu->max_slices = 6;
- sseu->max_subslices = 4;
- sseu->max_eus_per_subslice = 8;
subslice_mask = (1 << 4) - 1;
subslice_mask &= ~((fuse2 & GEN10_F2_SS_DIS_MASK) >>
@@ -314,9 +308,7 @@ static void cherryview_sseu_info_init(struct
drm_i915_private *dev_priv)
fuse = I915_READ(CHV_FUSE_GT);
sseu->slice_mask = BIT(0);
- sseu->max_slices = 1;
- sseu->max_subslices = 2;
- sseu->max_eus_per_subslice = 8;
+ intel_sseu_set_info(sseu, 1, 2, 8);
if (!(fuse & CHV_FGT_DISABLE_SS0)) {
u8 disabled_mask =
@@ -372,9 +364,8 @@ static void gen9_sseu_info_init(struct drm_i915_private
*dev_priv)
sseu->slice_mask = (fuse2 & GEN8_F2_S_ENA_MASK) >> GEN8_F2_S_ENA_SHIFT;
/* BXT has a single slice and at most 3 subslices. */
- sseu->max_slices = IS_GEN9_LP(dev_priv) ? 1 : 3;
- sseu->max_subslices = IS_GEN9_LP(dev_priv) ? 3 : 4;
- sseu->max_eus_per_subslice = 8;
+ intel_sseu_set_info(sseu, IS_GEN9_LP(dev_priv) ? 1 : 3,
+ IS_GEN9_LP(dev_priv) ? 3 : 4, 8);
/*
* The subslice disable field is global, i.e. it applies
@@ -473,9 +464,7 @@ static void broadwell_sseu_info_init(struct
[Intel-gfx] [PATCH 5/9] drm/i915: Add function to set subslices
Add a new function to set a range of subslices for a
specified slice based on a given mask.
v2: Use local variable for subslice_mask on HSW and
clean up a few other subslice_mask local variable
changes
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 10
drivers/gpu/drm/i915/gt/intel_sseu.h | 3 ++
drivers/gpu/drm/i915/intel_device_info.c | 59 +---
3 files changed, 46 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 71abf0c9a46b..607c1447287c 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -30,6 +30,16 @@ intel_sseu_subslice_total(const struct sseu_dev_info *sseu)
return total;
}
+void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
+ u32 ss_mask)
+{
+ int i, offset = slice * sseu->ss_stride;
+
+ for (i = 0; i < sseu->ss_stride; i++)
+ sseu->subslice_mask[offset + i] =
+ (ss_mask >> (BITS_PER_BYTE * i)) & 0xff;
+}
+
unsigned int
intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index fe22d5b18e67..2261d4e7d98b 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -75,6 +75,9 @@ intel_sseu_subslice_total(const struct sseu_dev_info *sseu);
unsigned int
intel_sseu_subslices_per_slice(const struct sseu_dev_info *sseu, u8 slice);
+void intel_sseu_set_subslices(struct sseu_dev_info *sseu, int slice,
+ u32 ss_mask);
+
u32 intel_sseu_make_rpcs(struct drm_i915_private *i915,
const struct intel_sseu *req_sseu);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 7de7b7b540cb..2320613a51ac 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -206,7 +206,10 @@ static void gen11_sseu_info_init(struct drm_i915_private
*dev_priv)
int ss;
sseu->slice_mask |= BIT(s);
- sseu->subslice_mask[s] = (ss_en >> ss_idx) & ss_en_mask;
+
+ intel_sseu_set_subslices(sseu, s, (ss_en >> ss_idx) &
+ ss_en_mask);
+
for (ss = 0; ss < sseu->max_subslices; ss++) {
if (sseu->subslice_mask[s] & BIT(ss))
sseu_set_eus(sseu, s, ss, eu_en);
@@ -235,18 +238,6 @@ static void gen10_sseu_info_init(struct drm_i915_private
*dev_priv)
sseu->slice_mask = (fuse2 & GEN10_F2_S_ENA_MASK) >>
GEN10_F2_S_ENA_SHIFT;
- subslice_mask = (1 << 4) - 1;
- subslice_mask &= ~((fuse2 & GEN10_F2_SS_DIS_MASK) >>
- GEN10_F2_SS_DIS_SHIFT);
-
- /*
-* Slice0 can have up to 3 subslices, but there are only 2 in
-* slice1/2.
-*/
- sseu->subslice_mask[0] = subslice_mask;
- for (s = 1; s < sseu->max_slices; s++)
- sseu->subslice_mask[s] = subslice_mask & 0x3;
-
/* Slice0 */
eu_en = ~I915_READ(GEN8_EU_DISABLE0);
for (ss = 0; ss < sseu->max_subslices; ss++)
@@ -270,14 +261,25 @@ static void gen10_sseu_info_init(struct drm_i915_private
*dev_priv)
eu_en = ~I915_READ(GEN10_EU_DISABLE3);
sseu_set_eus(sseu, 5, 1, eu_en & eu_mask);
- /* Do a second pass where we mark the subslices disabled if all their
-* eus are off.
-*/
+ subslice_mask = (1 << 4) - 1;
+ subslice_mask &= ~((fuse2 & GEN10_F2_SS_DIS_MASK) >>
+ GEN10_F2_SS_DIS_SHIFT);
+
for (s = 0; s < sseu->max_slices; s++) {
+ u32 subslice_mask_with_eus = subslice_mask;
+
for (ss = 0; ss < sseu->max_subslices; ss++) {
if (sseu_get_eus(sseu, s, ss) == 0)
- sseu->subslice_mask[s] &= ~BIT(ss);
+ subslice_mask_with_eus &= ~BIT(ss);
}
+
+ /*
+* Slice0 can have up to 3 subslices, but there are only 2 in
+* slice1/2.
+*/
+ intel_sseu_set_subslices(sseu, s, s == 0 ?
+ subslice_mask_with_eus :
+ subslice_mask_with_eus & 0x3);
}
sseu->eu_total = compute_eu_total(sseu);
@@ -303,6 +305,7 @@ static void cherryview_sseu_info_init(struct
drm_i915_private *dev_priv)
{
struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
u32 fuse;
+ u8 subslice_mask = 0;
fuse = I915_READ(CHV_FUSE_GT);
@@ -316,7 +319,7 @@ static void
[Intel-gfx] [PATCH 3/9] drm/i915: Add subslice stride runtime parameter
Add a new parameter, ss_stride, to the runtime info
structure. This is used to mirror the userspace concept
of subslice stride, which is a range of subslices per slice.
This patch simply adds the definition and updates usage
in the QUERY_TOPOLOGY_INFO handler.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 ++
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 ++
drivers/gpu/drm/i915/i915_query.c| 5 ++---
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 08b74ae40739..2d9e6fa4ee46 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -14,6 +14,8 @@ void intel_sseu_set_info(struct sseu_dev_info *sseu, u8
max_slices,
sseu->max_slices = max_slices;
sseu->max_subslices = max_subslices;
sseu->max_eus_per_subslice = max_eus_per_subslice;
+
+ sseu->ss_stride = GEN_SSEU_STRIDE(sseu->max_subslices);
}
unsigned int
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.h
b/drivers/gpu/drm/i915/gt/intel_sseu.h
index 64e47dad07be..b0101e1c69bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.h
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.h
@@ -33,6 +33,8 @@ struct sseu_dev_info {
u8 max_subslices;
u8 max_eus_per_subslice;
+ u8 ss_stride;
+
/* We don't have more than 8 eus per subslice at the moment and as we
* store eus enabled using bits, no need to multiply by eus per
* subslice.
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index ad9240a0817a..d8e25dcf5f0b 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -37,7 +37,6 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
struct drm_i915_query_topology_info topo;
u32 slice_length, subslice_length, eu_length, total_length;
- u8 subslice_stride = GEN_SSEU_STRIDE(sseu->max_subslices);
u8 eu_stride = GEN_SSEU_STRIDE(sseu->max_eus_per_subslice);
int ret;
@@ -50,7 +49,7 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
BUILD_BUG_ON(sizeof(u8) != sizeof(sseu->slice_mask));
slice_length = sizeof(sseu->slice_mask);
- subslice_length = sseu->max_slices * subslice_stride;
+ subslice_length = sseu->max_slices * sseu->ss_stride;
eu_length = sseu->max_slices * sseu->max_subslices * eu_stride;
total_length = sizeof(topo) + slice_length + subslice_length +
eu_length;
@@ -69,7 +68,7 @@ static int query_topology_info(struct drm_i915_private
*dev_priv,
topo.max_eus_per_subslice = sseu->max_eus_per_subslice;
topo.subslice_offset = slice_length;
- topo.subslice_stride = subslice_stride;
+ topo.subslice_stride = sseu->ss_stride;
topo.eu_offset = slice_length + subslice_length;
topo.eu_stride = eu_stride;
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/9] drm/i915: Refactor instdone loops on new subslice functions
Refactor instdone loops to use the new intel_sseu_has_subslice
function.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +-
drivers/gpu/drm/i915/gt/intel_engine_types.h | 31 ++--
drivers/gpu/drm/i915/gt/intel_hangcheck.c| 3 +-
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++--
drivers/gpu/drm/i915/i915_gpu_error.c| 5 ++--
5 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 86247eeb6f2b..4ad779500dd9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -944,6 +944,7 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
struct intel_instdone *instdone)
{
struct drm_i915_private *i915 = engine->i915;
+ const struct sseu_dev_info *sseu = _INFO(i915)->sseu;
struct intel_uncore *uncore = engine->uncore;
u32 mmio_base = engine->mmio_base;
int slice;
@@ -961,7 +962,7 @@ void intel_engine_get_instdone(struct intel_engine_cs
*engine,
instdone->slice_common =
intel_uncore_read(uncore, GEN7_SC_INSTDONE);
- for_each_instdone_slice_subslice(i915, slice, subslice) {
+ for_each_instdone_slice_subslice(i915, sseu, slice, subslice) {
instdone->sampler[slice][subslice] =
read_subslice_reg(engine, slice, subslice,
GEN7_SAMPLER_INSTDONE);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index dacaa707c797..b680e05767fd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -544,20 +544,19 @@ intel_engine_is_virtual(const struct intel_engine_cs
*engine)
return engine->flags & I915_ENGINE_IS_VIRTUAL;
}
-#define instdone_slice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.slice_mask)
-
-#define instdone_subslice_mask(dev_priv__) \
- (IS_GEN(dev_priv__, 7) ? \
-1 : RUNTIME_INFO(dev_priv__)->sseu.subslice_mask[0])
-
-#define for_each_instdone_slice_subslice(dev_priv__, slice__, subslice__) \
- for ((slice__) = 0, (subslice__) = 0; \
-(slice__) < I915_MAX_SLICES; \
-(subslice__) = ((subslice__) + 1) < I915_MAX_SUBSLICES ?
(subslice__) + 1 : 0, \
- (slice__) += ((subslice__) == 0)) \
- for_each_if((BIT(slice__) & instdone_slice_mask(dev_priv__)) &&
\
- (BIT(subslice__) &
instdone_subslice_mask(dev_priv__)))
-
+#define instdone_has_slice(dev_priv___, sseu___, slice___) \
+ ((IS_GEN(dev_priv___, 7) ? 1 : ((sseu___)->slice_mask)) & \
+ BIT(slice___))
+
+#define instdone_has_subslice(dev_priv__, sseu__, slice__, subslice__) \
+ (IS_GEN(dev_priv__, 7) ? (1 & BIT(subslice__)) : \
+intel_sseu_has_subslice(sseu__, 0, subslice__))
+
+#define for_each_instdone_slice_subslice(dev_priv_, sseu_, slice_, subslice_) \
+ for ((slice_) = 0, (subslice_) = 0; (slice_) < I915_MAX_SLICES; \
+(subslice_) = ((subslice_) + 1) % I915_MAX_SUBSLICES, \
+(slice_) += ((subslice_) == 0)) \
+ for_each_if((instdone_has_slice(dev_priv_, sseu_, slice_)) && \
+ (instdone_has_subslice(dev_priv_, sseu_, slice_, \
+ subslice_)))
#endif /* __INTEL_ENGINE_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
index 05d042cdefe2..40f62f780be5 100644
--- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
@@ -53,6 +53,7 @@ static bool instdone_unchanged(u32 current_instdone, u32
*old_instdone)
static bool subunits_stuck(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
+ const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
struct intel_instdone instdone;
struct intel_instdone *accu_instdone = >hangcheck.instdone;
bool stuck;
@@ -71,7 +72,7 @@ static bool subunits_stuck(struct intel_engine_cs *engine)
stuck &= instdone_unchanged(instdone.slice_common,
_instdone->slice_common);
- for_each_instdone_slice_subslice(dev_priv, slice, subslice) {
+ for_each_instdone_slice_subslice(dev_priv, sseu, slice, subslice) {
stuck &= instdone_unchanged(instdone.sampler[slice][subslice],
_instdone->sampler[slice][subslice]);
stuck &= instdone_unchanged(instdone.row[slice][subslice],
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index
[Intel-gfx] [PATCH 1/9] drm/i915: Use variable for debugfs device status
Use a local variable to find SSEU runtime information
in various debugfs functions.
v2: Remove extra line breaks per feedback from Chris
Signed-off-by: Stuart Summers
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3b15266c54fd..c31b141656d6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3864,8 +3864,7 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
if (IS_GEN9_BC(dev_priv))
- sseu->subslice_mask[s] =
- RUNTIME_INFO(dev_priv)->sseu.subslice_mask[s];
+ sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
@@ -3892,25 +3891,22 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
static void broadwell_sseu_device_status(struct drm_i915_private *dev_priv,
struct sseu_dev_info *sseu)
{
+ const struct intel_runtime_info *info = RUNTIME_INFO(dev_priv);
u32 slice_info = I915_READ(GEN8_GT_SLICE_INFO);
int s;
sseu->slice_mask = slice_info & GEN8_LSLICESTAT_MASK;
if (sseu->slice_mask) {
- sseu->eu_per_subslice =
- RUNTIME_INFO(dev_priv)->sseu.eu_per_subslice;
- for (s = 0; s < fls(sseu->slice_mask); s++) {
- sseu->subslice_mask[s] =
- RUNTIME_INFO(dev_priv)->sseu.subslice_mask[s];
- }
+ sseu->eu_per_subslice = info->sseu.eu_per_subslice;
+ for (s = 0; s < fls(sseu->slice_mask); s++)
+ sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
sseu->eu_total = sseu->eu_per_subslice *
intel_sseu_subslice_total(sseu);
/* subtract fused off EU(s) from enabled slice(s) */
for (s = 0; s < fls(sseu->slice_mask); s++) {
- u8 subslice_7eu =
- RUNTIME_INFO(dev_priv)->sseu.subslice_7eu[s];
+ u8 subslice_7eu = info->sseu.subslice_7eu[s];
sseu->eu_total -= hweight8(subslice_7eu);
}
@@ -3957,6 +3953,7 @@ static void i915_print_sseu_info(struct seq_file *m, bool
is_available_info,
static int i915_sseu_status(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ const struct intel_runtime_info *info = RUNTIME_INFO(dev_priv);
struct sseu_dev_info sseu;
intel_wakeref_t wakeref;
@@ -3964,14 +3961,13 @@ static int i915_sseu_status(struct seq_file *m, void
*unused)
return -ENODEV;
seq_puts(m, "SSEU Device Info\n");
- i915_print_sseu_info(m, true, _INFO(dev_priv)->sseu);
+ i915_print_sseu_info(m, true, >sseu);
seq_puts(m, "SSEU Device Status\n");
memset(, 0, sizeof(sseu));
- sseu.max_slices = RUNTIME_INFO(dev_priv)->sseu.max_slices;
- sseu.max_subslices = RUNTIME_INFO(dev_priv)->sseu.max_subslices;
- sseu.max_eus_per_subslice =
- RUNTIME_INFO(dev_priv)->sseu.max_eus_per_subslice;
+ sseu.max_slices = info->sseu.max_slices;
+ sseu.max_subslices = info->sseu.max_subslices;
+ sseu.max_eus_per_subslice = info->sseu.max_eus_per_subslice;
with_intel_runtime_pm(_priv->runtime_pm, wakeref) {
if (IS_CHERRYVIEW(dev_priv))
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/9] drm/i915: Add new function to copy subslices for a slice
Add a new function to copy subslices for a specified slice
between intel_sseu structures for the purpose of determining
power-gate status.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_debugfs.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1cb03909e615..a64cd181051f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3741,6 +3741,15 @@ i915_cache_sharing_set(void *data, u64 val)
return 0;
}
+static void
+intel_sseu_copy_subslices(const struct sseu_dev_info *sseu, int slice,
+ u8 *to_mask)
+{
+ int offset = slice * sseu->ss_stride;
+
+ memcpy(_mask[offset], >subslice_mask[offset], sseu->ss_stride);
+}
+
DEFINE_SIMPLE_ATTRIBUTE(i915_cache_sharing_fops,
i915_cache_sharing_get, i915_cache_sharing_set,
"%llu\n");
@@ -3814,7 +3823,7 @@ static void gen10_sseu_device_status(struct
drm_i915_private *dev_priv,
continue;
sseu->slice_mask |= BIT(s);
- sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
+ intel_sseu_copy_subslices(>sseu, s, sseu->subslice_mask);
for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
@@ -3865,7 +3874,8 @@ static void gen9_sseu_device_status(struct
drm_i915_private *dev_priv,
sseu->slice_mask |= BIT(s);
if (IS_GEN9_BC(dev_priv))
- sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
+ intel_sseu_copy_subslices(>sseu, s,
+ sseu->subslice_mask);
for (ss = 0; ss < info->sseu.max_subslices; ss++) {
unsigned int eu_cnt;
@@ -3901,7 +3911,8 @@ static void broadwell_sseu_device_status(struct
drm_i915_private *dev_priv,
if (sseu->slice_mask) {
sseu->eu_per_subslice = info->sseu.eu_per_subslice;
for (s = 0; s < fls(sseu->slice_mask); s++)
- sseu->subslice_mask[s] = info->sseu.subslice_mask[s];
+ intel_sseu_copy_subslices(>sseu, s,
+ sseu->subslice_mask);
sseu->eu_total = sseu->eu_per_subslice *
intel_sseu_subslice_total(sseu);
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915/uc: Hardening firmware fetch
Insert few more failure points into firmware fetch procedure to check
use of the wrong blob name or use of the mismatched firmware versions.
Also update some messages (remove ptr, duplicated infos) and stop
treating all fetch errors as missing firmware case.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 137 ---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +
2 files changed, 97 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 3a3803bfa5a8..4faff1010398 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -153,20 +153,23 @@ static const char *__override_huc_firmware_path(void)
return "";
}
-static bool
-__uc_fw_override(struct intel_uc_fw *uc_fw)
+static void __uc_fw_user_override(struct intel_uc_fw *uc_fw)
{
+ const char *path = NULL;
+
switch (uc_fw->type) {
case INTEL_UC_FW_TYPE_GUC:
- uc_fw->path = __override_guc_firmware_path();
+ path = __override_guc_firmware_path();
break;
case INTEL_UC_FW_TYPE_HUC:
- uc_fw->path = __override_huc_firmware_path();
+ path = __override_huc_firmware_path();
break;
}
- uc_fw->user_overridden = uc_fw->path;
- return uc_fw->user_overridden;
+ if (unlikely(path)) {
+ uc_fw->path = path;
+ uc_fw->user_overridden = true;
+ }
}
/**
@@ -194,8 +197,10 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
uc_fw->type = type;
- if (supported && likely(!__uc_fw_override(uc_fw)))
+ if (supported) {
__uc_fw_auto_select(uc_fw, platform, rev);
+ __uc_fw_user_override(uc_fw);
+ }
if (uc_fw->path && *uc_fw->path)
uc_fw->status = INTEL_UC_FIRMWARE_SELECTED;
@@ -203,6 +208,41 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
uc_fw->status = INTEL_UC_FIRMWARE_NOT_SUPPORTED;
}
+static void __force_fw_fetch_failures(struct intel_uc_fw *uc_fw,
+ struct drm_i915_private *i915, bool user)
+{
+ int e = user ? -EINVAL : -ESTALE;
+
+ if (i915_inject_load_error(i915, e)) {
+ /* non-existing blob */
+ uc_fw->path = "";
+ uc_fw->user_overridden = user;
+ } else if (i915_inject_load_error(i915, e)) {
+ /* require next major version */
+ uc_fw->major_ver_wanted += 1;
+ uc_fw->minor_ver_wanted = 0;
+ uc_fw->user_overridden = user;
+ } else if (i915_inject_load_error(i915, e)) {
+ /* require next minor version */
+ uc_fw->minor_ver_wanted += 1;
+ uc_fw->user_overridden = user;
+ } else if (uc_fw->major_ver_wanted && i915_inject_load_error(i915, e)) {
+ /* require prev major version */
+ uc_fw->major_ver_wanted -= 1;
+ uc_fw->minor_ver_wanted = 0;
+ uc_fw->user_overridden = user;
+ } else if (uc_fw->minor_ver_wanted && i915_inject_load_error(i915, e)) {
+ /* require prev minor version - hey, this should work! */
+ uc_fw->minor_ver_wanted -= 1;
+ uc_fw->user_overridden = user;
+ } else if (user && i915_inject_load_error(i915, e)) {
+ /* officially unsupported platform */
+ uc_fw->major_ver_wanted = 0;
+ uc_fw->minor_ver_wanted = 0;
+ uc_fw->user_overridden = true;
+ }
+}
+
/**
* intel_uc_fw_fetch - fetch uC firmware
* @uc_fw: uC firmware
@@ -222,17 +262,22 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
GEM_BUG_ON(!intel_uc_fw_supported(uc_fw));
+ err = i915_inject_load_error(i915, -ENXIO);
+ if (err)
+ return err;
+
+ __force_fw_fetch_failures(uc_fw, i915, true);
+ __force_fw_fetch_failures(uc_fw, i915, false);
+
err = request_firmware(, uc_fw->path, i915->drm.dev);
if (err)
goto fail;
- DRM_DEBUG_DRIVER("%s fw size %zu ptr %p\n",
-intel_uc_fw_type_repr(uc_fw->type), fw->size, fw);
-
/* Check the size of the blob before examining buffer contents */
- if (fw->size < sizeof(struct uc_css_header)) {
- DRM_WARN("%s: Unexpected firmware size (%zu, min %zu)\n",
-intel_uc_fw_type_repr(uc_fw->type),
+ if (unlikely(fw->size < sizeof(struct uc_css_header))) {
+ dev_warn(i915->drm.dev,
+"%s firmware %s: invalid size: %zu < %zu\n",
+intel_uc_fw_type_repr(uc_fw->type), uc_fw->path,
fw->size, sizeof(struct
[Intel-gfx] [PATCH 5/7] drm/i915: Make wopcm_to_i915() private
No need to define it globally as we're only using it in wopcm.c
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 5 -
drivers/gpu/drm/i915/intel_wopcm.c | 5 +
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9476f24f5c1..d516e9099d15 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1907,11 +1907,6 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
return pci_get_drvdata(pdev);
}
-static inline struct drm_i915_private *wopcm_to_i915(struct intel_wopcm *wopcm)
-{
- return container_of(wopcm, struct drm_i915_private, wopcm);
-}
-
/* Simple iterator over all initialised engines */
#define for_each_engine(engine__, dev_priv__, id__) \
for ((id__) = 0; \
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 5e5c3fd3472d..2bda24200498 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -64,6 +64,11 @@
#define GEN9_GUC_FW_RESERVED SZ_128K
#define GEN9_GUC_WOPCM_OFFSET (GUC_WOPCM_RESERVED + GEN9_GUC_FW_RESERVED)
+static inline struct drm_i915_private *wopcm_to_i915(struct intel_wopcm *wopcm)
+{
+ return container_of(wopcm, struct drm_i915_private, wopcm);
+}
+
/**
* intel_wopcm_init_early() - Early initialization of the WOPCM.
* @wopcm: pointer to intel_wopcm.
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Don't try to partition WOPCM without GuC firmware
For meaningful WOPCM partitioning we need GuC (and optionally HuC) firmware size(s) and we shouldn't just rely on GuC support flag, as we might fail to fetch GuC firmware and it's size will be 0 and all calculations will be just wrong/useless. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_wopcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 4c22143ee84f..5e5c3fd3472d 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -170,7 +170,7 @@ void intel_wopcm_init(struct intel_wopcm *wopcm) u32 guc_wopcm_rsvd; int err; - if (!USES_GUC(i915)) + if (!guc_fw_size) return; GEM_BUG_ON(!wopcm->size); -- 2.19.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/7] drm/i915/uc: HuC firmware can't be supported without GuC
There is no point in selecting HuC firmware if GuC is unsupported
or it was already disabled, as we need GuC to authenticate HuC.
While around, make uc_fw_init_early work without direct access
to whole i915, pass only needed platform/rev info.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 -
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 13 +++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 5 +++--
4 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 28735c14b9a0..11765cfb0498 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -39,7 +39,10 @@
*/
void intel_guc_fw_init_early(struct intel_guc *guc)
{
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC,
guc_to_gt(guc)->i915);
+ struct drm_i915_private *i915 = guc_to_gt(guc)->i915;
+
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_GUC, HAS_GT_UC(i915),
+ INTEL_INFO(i915)->platform, INTEL_REVID(i915));
}
static void guc_prepare_xfer(struct intel_uncore *uncore)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
index 0e885859c828..88dfed837827 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c
@@ -31,7 +31,13 @@
*/
void intel_huc_fw_init_early(struct intel_huc *huc)
{
- intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC,
huc_to_gt(huc)->i915);
+ struct intel_gt *gt = huc_to_gt(huc);
+ struct intel_uc *uc = >uc;
+ struct drm_i915_private *i915 = gt->i915;
+
+ intel_uc_fw_init_early(>fw, INTEL_UC_FW_TYPE_HUC,
+ intel_uc_supports_guc(uc),
+ INTEL_INFO(i915)->platform, INTEL_REVID(i915));
}
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index a3a22a26016c..00235cac84aa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -171,16 +171,18 @@ __uc_fw_override(struct intel_uc_fw *uc_fw)
/**
* intel_uc_fw_init_early - initialize the uC object and select the firmware
- * @i915: device private
* @uc_fw: uC firmware
* @type: type of uC
+ * @supported: is uC support possible
+ * @platform: platform identifier
+ * @rev: hardware revision
*
* Initialize the state of our uC object and relevant tracking and select the
* firmware to fetch and load.
*/
void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
- enum intel_uc_fw_type type,
- struct drm_i915_private *i915)
+ enum intel_uc_fw_type type, bool supported,
+ enum intel_platform platform, u8 rev)
{
/*
* we use FIRMWARE_UNINITIALIZED to detect checks against uc_fw->status
@@ -192,9 +194,8 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
uc_fw->type = type;
- if (HAS_GT_UC(i915) && likely(!__uc_fw_override(uc_fw)))
- __uc_fw_auto_select(uc_fw, INTEL_INFO(i915)->platform,
- INTEL_REVID(i915));
+ if (supported && likely(!__uc_fw_override(uc_fw)))
+ __uc_fw_auto_select(uc_fw, platform, rev);
if (uc_fw->path && *uc_fw->path)
uc_fw->status = INTEL_UC_FIRMWARE_SELECTED;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index bfe3614613b7..7a858710d446 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -27,6 +27,7 @@
#include
#include "intel_uc_fw_abi.h"
+#include "intel_device_info.h"
#include "i915_gem.h"
struct drm_printer;
@@ -170,8 +171,8 @@ static inline u32 intel_uc_fw_get_upload_size(struct
intel_uc_fw *uc_fw)
}
void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
- enum intel_uc_fw_type type,
- struct drm_i915_private *i915);
+ enum intel_uc_fw_type type, bool supported,
+ enum intel_platform platform, u8 rev);
void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw,
struct drm_i915_private *i915);
void intel_uc_fw_cleanup_fetch(struct intel_uc_fw *uc_fw);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915/uc: WOPCM programming errors are not always real
WOPCM programming error might be due to inserted earlier probe
failure that could affects HuC firmware loading and thus impacts
result of WOPCM partitioning that would be now incompatible with
previously programmed values.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index c40eab290342..32aa4509ba1d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -415,11 +415,13 @@ static int uc_init_wopcm(struct intel_uc *uc)
return 0;
err_out:
- DRM_ERROR("Failed to init uC WOPCM registers:\n");
- DRM_ERROR("DMA_GUC_WOPCM_OFFSET=%#x\n",
- intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
- DRM_ERROR("GUC_WOPCM_SIZE=%#x\n",
- intel_uncore_read(uncore, GUC_WOPCM_SIZE));
+ i915_probe_error(gt->i915, "Failed to init uC WOPCM registers!\n");
+ i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "DMA_GUC_WOPCM_OFFSET",
+i915_mmio_reg_offset(DMA_GUC_WOPCM_OFFSET),
+intel_uncore_read(uncore, DMA_GUC_WOPCM_OFFSET));
+ i915_probe_error(gt->i915, "%s(%#x)=%#x\n", "GUC_WOPCM_SIZE",
+i915_mmio_reg_offset(GUC_WOPCM_SIZE),
+intel_uncore_read(uncore, GUC_WOPCM_SIZE));
return err;
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915/uc: Prefer dev_info for reporting options
While modparams are global for the i915 module, we are reporting
status of the params applied against specific device instance.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index e87b7904ab7a..3c007e0e1a20 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -59,11 +59,14 @@ static int __intel_uc_reset_hw(struct intel_uc *uc)
static void __confirm_options(struct intel_uc *uc)
{
- DRM_DEBUG_DRIVER("enable_guc=%d (guc:%s submission:%s huc:%s)\n",
-i915_modparams.enable_guc,
-yesno(intel_uc_supports_guc(uc)),
-yesno(intel_uc_supports_guc_submission(uc)),
-yesno(intel_uc_supports_huc(uc)));
+ struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+
+ DRM_DEV_DEBUG_DRIVER(i915->drm.dev,
+"enable_guc=%d (guc:%s submission:%s huc:%s)\n",
+i915_modparams.enable_guc,
+yesno(intel_uc_supports_guc(uc)),
+yesno(intel_uc_supports_guc_submission(uc)),
+yesno(intel_uc_supports_huc(uc)));
if (i915_modparams.enable_guc == -1)
return;
@@ -76,22 +79,26 @@ static void __confirm_options(struct intel_uc *uc)
}
if (!intel_uc_supports_guc(uc))
- DRM_INFO("Incompatible option enable_guc=%d - %s\n",
+ dev_info(i915->drm.dev,
+"Incompatible option enable_guc=%d - %s\n",
i915_modparams.enable_guc, "GuC is not supported!");
if (i915_modparams.enable_guc & ENABLE_GUC_LOAD_HUC &&
!intel_uc_supports_huc(uc))
- DRM_INFO("Incompatible option enable_guc=%d - %s\n",
+ dev_info(i915->drm.dev,
+"Incompatible option enable_guc=%d - %s\n",
i915_modparams.enable_guc, "HuC is not supported!");
if (i915_modparams.enable_guc & ENABLE_GUC_SUBMISSION &&
!intel_uc_supports_guc_submission(uc))
- DRM_INFO("Incompatible option enable_guc=%d - %s\n",
+ dev_info(i915->drm.dev,
+"Incompatible option enable_guc=%d - %s\n",
i915_modparams.enable_guc, "GuC submission is N/A");
if (i915_modparams.enable_guc & ~(ENABLE_GUC_SUBMISSION |
ENABLE_GUC_LOAD_HUC))
- DRM_INFO("Incompatible option enable_guc=%d - %s\n",
+ dev_info(i915->drm.dev,
+"Incompatible option enable_guc=%d - %s\n",
i915_modparams.enable_guc, "undocumented flag");
}
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915/uc: Don't fetch HuC fw if GuC fw fetch already failed
When we failed to fetch GuC firmware there is no point in fetching
HuC firmware as we will not be able to use it without working GuC.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 5 -
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 3 +--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 3c007e0e1a20..c40eab290342 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -283,11 +283,14 @@ static void guc_disable_communication(struct intel_guc
*guc)
void intel_uc_fetch_firmwares(struct intel_uc *uc)
{
struct drm_i915_private *i915 = uc_to_gt(uc)->i915;
+ int err;
if (!intel_uc_supports_guc(uc))
return;
- intel_uc_fw_fetch(>guc.fw, i915);
+ err = intel_uc_fw_fetch(>guc.fw, i915);
+ if (err)
+ return;
if (intel_uc_supports_huc(uc))
intel_uc_fw_fetch(>huc.fw, i915);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 00235cac84aa..3a3803bfa5a8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -205,13 +205,14 @@ void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
/**
* intel_uc_fw_fetch - fetch uC firmware
- *
* @uc_fw: uC firmware
* @i915: device private
*
* Fetch uC firmware into GEM obj.
+ *
+ * Return: 0 on success, a negative errno code on failure.
*/
-void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct drm_i915_private
*i915)
+int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct drm_i915_private *i915)
{
struct drm_i915_gem_object *obj;
const struct firmware *fw = NULL;
@@ -322,7 +323,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
uc_fw->status = INTEL_UC_FIRMWARE_AVAILABLE;
release_firmware(fw);
- return;
+ return 0;
fail:
uc_fw->status = INTEL_UC_FIRMWARE_MISSING;
@@ -333,6 +334,7 @@ void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct
drm_i915_private *i915)
intel_uc_fw_type_repr(uc_fw->type), INTEL_UC_FIRMWARE_URL);
release_firmware(fw); /* OK even if fw is NULL */
+ return err;
}
static u32 uc_fw_ggtt_offset(struct intel_uc_fw *uc_fw, struct i915_ggtt *ggtt)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
index 7a858710d446..fae45bc16bc7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h
@@ -173,8 +173,7 @@ static inline u32 intel_uc_fw_get_upload_size(struct
intel_uc_fw *uc_fw)
void intel_uc_fw_init_early(struct intel_uc_fw *uc_fw,
enum intel_uc_fw_type type, bool supported,
enum intel_platform platform, u8 rev);
-void intel_uc_fw_fetch(struct intel_uc_fw *uc_fw,
- struct drm_i915_private *i915);
+int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw, struct drm_i915_private
*i915);
void intel_uc_fw_cleanup_fetch(struct intel_uc_fw *uc_fw);
int intel_uc_fw_upload(struct intel_uc_fw *uc_fw, struct intel_gt *gt,
u32 wopcm_offset, u32 dma_flags);
--
2.19.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] Hardening firmware fetch
More probe failures inside uc loading path. Michal Wajdeczko (7): drm/i915/uc: Prefer dev_info for reporting options drm/i915/uc: HuC firmware can't be supported without GuC drm/i915/uc: Don't fetch HuC fw if GuC fw fetch already failed drm/i915: Don't try to partition WOPCM without GuC firmware drm/i915: Make wopcm_to_i915() private drm/i915/uc: WOPCM programming errors are not always real drm/i915/uc: Hardening firmware fetch drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 5 +- drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 8 +- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 42 +++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 156 +++--- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 11 +- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/intel_wopcm.c| 7 +- 7 files changed, 156 insertions(+), 78 deletions(-) -- 2.19.2 ___ 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: Drop expectations of VM_IO from our GGTT mmappings
== Series Details == Series: drm/i915: Drop expectations of VM_IO from our GGTT mmappings URL : https://patchwork.freedesktop.org/series/64828/ State : success == Summary == CI Bug Log - changes from CI_DRM_6644_full -> Patchwork_13896_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13896_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-apl3/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_balancer@smoke: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110854]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-iclb1/igt@gem_exec_balan...@smoke.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-iclb7/igt@gem_exec_balan...@smoke.html * igt@i915_pm_rps@reset: - shard-glk: [PASS][5] -> [FAIL][6] ([fdo#102250]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-glk9/igt@i915_pm_...@reset.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-glk3/igt@i915_pm_...@reset.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-kbl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103665]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#109507]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: - shard-snb: [PASS][13] -> [SKIP][14] ([fdo#109271]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-snb1/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-snb2/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-kbl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-skl1/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13896/shard-skl10/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6644/shard-iclb2/igt@kms_psr2_su@page_flip.html [24]:
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
Quoting Bloomfield, Jon (2019-08-07 16:29:55)
> > -Original Message-
> > From: Chris Wilson
> > Sent: Wednesday, August 7, 2019 8:08 AM
> > To: Bloomfield, Jon ; intel-
> > g...@lists.freedesktop.org
> > Cc: Joonas Lahtinen ; Winiarski, Michal
> >
> > Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
> >
> > Quoting Bloomfield, Jon (2019-08-07 15:33:51)
> > [skip to end]
> > > We didn't explore the idea of terminating orphaned contexts though
> > (where none of their resources are referenced by any other contexts). Is
> > there a reason why this is not feasible? In the case of compute (certainly
> > HPC) workloads, there would be no compositor taking the output so this
> > might be a solution.
> >
> > Sounds easier said than done. We have to go through each request and
> > determine it if has an external reference (or if the object holding the
> > reference has an external reference) to see if the output would be
> > visible to a third party. Sounds like a conservative GC :|
> > (Coming to that conclusion suggests that we should structure the request
> > tracking to make reparenting easier.)
> >
> > We could take a pid-1 approach and move all the orphan timelines over to
> > a new parent purely responsible for them. That honestly doesn't seem to
> > achieve anything. (We are still stuck with tasks on the GPU and no way
> > to kill them.)
> >
> > In comparison, persistence is a rarely used "feature" and cleaning up on
> > context close fits in nicely with the process model. It just works as
> > most users/clients would expect. (Although running in non-persistent
> > by default hasn't show anything to explode on the desktop, it's too easy
> > to construct scenarios where persistence turns out to be an advantage,
> > particularly with chains of clients (the compositor model).) Between the
> > two modes, we should have most bases covered, it's hard to argue for a
> > third way (that is until someone has a usecase!)
> > -Chris
>
> Ok, makes sense. Thanks.
>
> But have we converged on a decision :-)
>
> As I said, requiring compute umd optin should be ok for the immediate HPC
> issue, but I'd personally argue that it's valid to change the contract for
> hangcheck=0 and switch the default to non-persistent.
Could you tender
diff --git a/runtime/os_interface/linux/drm_neo.cpp
b/runtime/os_interface/linux/drm_neo.cpp
index 31deb68b..8a9af363 100644
--- a/runtime/os_interface/linux/drm_neo.cpp
+++ b/runtime/os_interface/linux/drm_neo.cpp
@@ -141,11 +141,22 @@ void Drm::setLowPriorityContextParam(uint32_t
drmContextId) {
UNRECOVERABLE_IF(retVal != 0);
}
+void setNonPersistent(uint32_t drmContextId) {
+drm_i915_gem_context_param gcp = {};
+gcp.ctx_id = drmContextId;
+gcp.param = 0xb; /* I915_CONTEXT_PARAM_PERSISTENCE; */
+
+ioctl(DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
+}
+
uint32_t Drm::createDrmContext() {
drm_i915_gem_context_create gcc = {};
auto retVal = ioctl(DRM_IOCTL_I915_GEM_CONTEXT_CREATE, );
UNRECOVERABLE_IF(retVal != 0);
+/* enable cleanup of resources on process termination */
+setNonPersistent(gcc.ctx_id);
+
return gcc.ctx_id;
}
to interested parties?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] dma-buf: further relax reservation_object_add_shared_fence
Quoting Christian König (2019-08-07 14:53:11)
> Other cores don't busy wait any more and we removed the last user of checking
> the seqno for changes. Drop updating the number for shared fences altogether.
>
> Signed-off-by: Christian König
Reviewed-by: Chris Wilson
> ---
> drivers/dma-buf/reservation.c| 6 --
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 +--
> 2 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index 8fcaddffd5d4..90bc6ef03598 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -237,9 +237,6 @@ void reservation_object_add_shared_fence(struct
> reservation_object *obj,
> fobj = reservation_object_get_list(obj);
> count = fobj->shared_count;
>
> - preempt_disable();
> - write_seqcount_begin(>seq);
> -
> for (i = 0; i < count; ++i) {
>
> old = rcu_dereference_protected(fobj->shared[i],
> @@ -257,9 +254,6 @@ void reservation_object_add_shared_fence(struct
> reservation_object *obj,
> RCU_INIT_POINTER(fobj->shared[i], fence);
> /* pointer update must be visible before we extend the shared_count */
> smp_store_mb(fobj->shared_count, count);
> -
> - write_seqcount_end(>seq);
> - preempt_enable();
> dma_fence_put(old);
> }
> EXPORT_SYMBOL(reservation_object_add_shared_fence);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index fe062b76ec91..a4640ddc24d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -251,12 +251,7 @@ static int amdgpu_amdkfd_remove_eviction_fence(struct
> amdgpu_bo *bo,
> new->shared_max = old->shared_max;
> new->shared_count = k;
>
> - /* Install the new fence list, seqcount provides the barriers */
> - preempt_disable();
> - write_seqcount_begin(>seq);
> - RCU_INIT_POINTER(resv->fence, new);
> - write_seqcount_end(>seq);
> - preempt_enable();
> + rcu_assign_pointer(resv->fence, new);
but you'll probably want a local ack for amdgpu/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: use new reservation_object_fences helper
Quoting Christian König (2019-08-07 14:53:10) > Instead of open coding the sequence loop use the new helper. > > Signed-off-by: Christian König Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] dma-buf: add reservation_object_fences helper
Quoting Christian König (2019-08-07 14:53:09) > Add a new helper to get a consistent set of pointers from the reservation > object. While at it group all access helpers together in the header file. > > v2: correctly return shared_count as well > > Signed-off-by: Christian König Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vlv: allocate Gunit s0ix state on demand
== Series Details ==
Series: drm/i915/vlv: allocate Gunit s0ix state on demand
URL : https://patchwork.freedesktop.org/series/64844/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6648 -> Patchwork_13902
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/
Known issues
Here are the changes found in Patchwork_13902 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_busy@busy-all:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u3/igt@gem_b...@busy-all.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-icl-u3/igt@gem_b...@busy-all.html
* igt@kms_busy@basic-flip-a:
- fi-kbl-7567u: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278])
+2 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-7567u/igt@kms_b...@basic-flip-a.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][5] -> [WARN][6] ([fdo#109380])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-7500u: [PASS][7] -> [WARN][8] ([fdo#109483])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.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_6648/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][11] -> [SKIP][12] ([fdo#109271]) +23 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][13] ([fdo#08]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_busy@basic-flip-c:
- fi-kbl-7500u: [SKIP][15] ([fdo#109271] / [fdo#109278]) ->
[PASS][16] +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [FAIL][17] ([fdo#110627]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][19] ([fdo#109483]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@vgem_basic@unload:
- fi-icl-u3: [DMESG-WARN][21] ([fdo#107724]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u3/igt@vgem_ba...@unload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-icl-u3/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [FAIL][23] ([fdo#107707]) -> [SKIP][24] ([fdo#109271])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13902/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107707]: https://bugs.freedesktop.org/show_bug.cgi?id=107707
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Isolate i915_getparam_ioctl()
== Series Details ==
Series: drm/i915: Isolate i915_getparam_ioctl()
URL : https://patchwork.freedesktop.org/series/64840/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6648 -> Patchwork_13901
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_13901:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_chamelium@hdmi-crc-fast:
- {fi-icl-u4}:[DMESG-FAIL][1] ([fdo#105602]) -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u4/igt@kms_chamel...@hdmi-crc-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-icl-u4/igt@kms_chamel...@hdmi-crc-fast.html
Known issues
Here are the changes found in Patchwork_13901 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_client:
- fi-skl-guc: [PASS][3] -> [DMESG-WARN][4] ([fdo#110943])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-skl-guc/igt@i915_selftest@live_client.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-skl-guc/igt@i915_selftest@live_client.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7567u: [PASS][5] -> [WARN][6] ([fdo#109380])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-kbl-7567u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#109485])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@read-crc-pipe-c:
- fi-kbl-7567u: [PASS][9] -> [SKIP][10] ([fdo#109271]) +23 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-kbl-7567u/igt@kms_pipe_crc_ba...@read-crc-pipe-c.html
* igt@prime_vgem@basic-fence-flip:
- fi-icl-u3: [PASS][11] -> [DMESG-WARN][12] ([fdo#107724])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
Possible fixes
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][13] ([fdo#08]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-cml-u2: [FAIL][15] ([fdo#110627]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][17] ([fdo#109483]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-7500u: [SKIP][19] ([fdo#109271]) -> [PASS][20] +23 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-kbl-7500u/igt@prime_v...@basic-fence-flip.html
* igt@vgem_basic@unload:
- fi-icl-u3: [DMESG-WARN][21] ([fdo#107724]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-icl-u3/igt@vgem_ba...@unload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-icl-u3/igt@vgem_ba...@unload.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [FAIL][23] ([fdo#107707]) -> [SKIP][24] ([fdo#109271])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6648/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13901/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed.
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
Quoting Bloomfield, Jon (2019-08-07 16:29:55) > > -Original Message- > > From: Chris Wilson > > Sent: Wednesday, August 7, 2019 8:08 AM > > To: Bloomfield, Jon ; intel- > > g...@lists.freedesktop.org > > Cc: Joonas Lahtinen ; Winiarski, Michal > > > > Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close > > > > Quoting Bloomfield, Jon (2019-08-07 15:33:51) > > [skip to end] > > > We didn't explore the idea of terminating orphaned contexts though > > (where none of their resources are referenced by any other contexts). Is > > there a reason why this is not feasible? In the case of compute (certainly > > HPC) workloads, there would be no compositor taking the output so this > > might be a solution. > > > > Sounds easier said than done. We have to go through each request and > > determine it if has an external reference (or if the object holding the > > reference has an external reference) to see if the output would be > > visible to a third party. Sounds like a conservative GC :| > > (Coming to that conclusion suggests that we should structure the request > > tracking to make reparenting easier.) > > > > We could take a pid-1 approach and move all the orphan timelines over to > > a new parent purely responsible for them. That honestly doesn't seem to > > achieve anything. (We are still stuck with tasks on the GPU and no way > > to kill them.) > > > > In comparison, persistence is a rarely used "feature" and cleaning up on > > context close fits in nicely with the process model. It just works as > > most users/clients would expect. (Although running in non-persistent > > by default hasn't show anything to explode on the desktop, it's too easy > > to construct scenarios where persistence turns out to be an advantage, > > particularly with chains of clients (the compositor model).) Between the > > two modes, we should have most bases covered, it's hard to argue for a > > third way (that is until someone has a usecase!) > > -Chris > > Ok, makes sense. Thanks. > > But have we converged on a decision :-) > > As I said, requiring compute umd optin should be ok for the immediate HPC > issue, but I'd personally argue that it's valid to change the contract for > hangcheck=0 and switch the default to non-persistent. I don't have to like it, but I think that's what we have to do for the interim 10 years or so. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
> -Original Message- > From: Chris Wilson > Sent: Wednesday, August 7, 2019 8:08 AM > To: Bloomfield, Jon ; intel- > g...@lists.freedesktop.org > Cc: Joonas Lahtinen ; Winiarski, Michal > > Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close > > Quoting Bloomfield, Jon (2019-08-07 15:33:51) > [skip to end] > > We didn't explore the idea of terminating orphaned contexts though > (where none of their resources are referenced by any other contexts). Is > there a reason why this is not feasible? In the case of compute (certainly > HPC) workloads, there would be no compositor taking the output so this > might be a solution. > > Sounds easier said than done. We have to go through each request and > determine it if has an external reference (or if the object holding the > reference has an external reference) to see if the output would be > visible to a third party. Sounds like a conservative GC :| > (Coming to that conclusion suggests that we should structure the request > tracking to make reparenting easier.) > > We could take a pid-1 approach and move all the orphan timelines over to > a new parent purely responsible for them. That honestly doesn't seem to > achieve anything. (We are still stuck with tasks on the GPU and no way > to kill them.) > > In comparison, persistence is a rarely used "feature" and cleaning up on > context close fits in nicely with the process model. It just works as > most users/clients would expect. (Although running in non-persistent > by default hasn't show anything to explode on the desktop, it's too easy > to construct scenarios where persistence turns out to be an advantage, > particularly with chains of clients (the compositor model).) Between the > two modes, we should have most bases covered, it's hard to argue for a > third way (that is until someone has a usecase!) > -Chris Ok, makes sense. Thanks. But have we converged on a decision :-) As I said, requiring compute umd optin should be ok for the immediate HPC issue, but I'd personally argue that it's valid to change the contract for hangcheck=0 and switch the default to non-persistent. Jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Defer final intel_wakeref_put to process context
Quoting Mika Kuoppala (2019-08-07 16:04:56)
> Chris Wilson writes:
> > -static int intel_gt_park(struct intel_wakeref *wf)
> > +static int __gt_park(struct intel_wakeref *wf)
> > {
> > struct drm_i915_private *i915 =
> > container_of(wf, typeof(*i915), gt.wakeref);
> > @@ -74,22 +67,25 @@ static int intel_gt_park(struct intel_wakeref *wf)
> > if (INTEL_GEN(i915) >= 6)
> > gen6_rps_idle(i915);
> >
> > + /* Everything switched off, flush any residual interrupt just in case
> > */
> > + intel_synchronize_irq(i915);
>
> Do we detect it gracefully if we get one extra afer this flush?
If we make a mistake, we get unclaimed mmio from the interrupt handler.
Given the structure of engine_pm/gt_pm, we should not be generating
either user interrupts nor CS interrupts by this point. The potential is
for the guc/pm interrupts, but I felt it was more prudent to document
this is the final point for GT interrupts of any type.
> > + GEM_BUG_ON(intel_gt_pm_is_awake(gt));
> > + for_each_engine(engine, gt->i915, id) {
> > + const typeof(*igt_atomic_phases) *p;
> > +
> > + for (p = igt_atomic_phases; p->name; p++) {
> > + /*
> > + * Acquisition is always synchronous, except if we
> > + * know that the engine is already awale, in which
>
> s/awale/awake
a whale
> in which case?
Avast ye blows!
Moby Dick!
> > static long
> > wait_for_timelines(struct drm_i915_private *i915,
> > unsigned int flags, long timeout)
> > @@ -954,27 +941,20 @@ int i915_gem_wait_for_idle(struct drm_i915_private
> > *i915,
> > unsigned int flags, long timeout)
> > {
> > /* If the device is asleep, we have no requests outstanding */
> > - if (!READ_ONCE(i915->gt.awake))
> > + if (!intel_gt_pm_is_awake(>gt))
> > return 0;
> >
> > - GEM_TRACE("flags=%x (%s), timeout=%ld%s, awake?=%s\n",
> > + GEM_TRACE("flags=%x (%s), timeout=%ld%s\n",
> > flags, flags & I915_WAIT_LOCKED ? "locked" : "unlocked",
> > - timeout, timeout == MAX_SCHEDULE_TIMEOUT ? " (forever)" :
> > "",
> > - yesno(i915->gt.awake));
> > + timeout, timeout == MAX_SCHEDULE_TIMEOUT ? " (forever)" :
> > "");
> >
> > timeout = wait_for_timelines(i915, flags, timeout);
> > if (timeout < 0)
> > return timeout;
> >
> > if (flags & I915_WAIT_LOCKED) {
> > - int err;
> > -
> > lockdep_assert_held(>drm.struct_mutex);
> >
> > - err = wait_for_engines(>gt);
> > - if (err)
> > - return err;
> > -
>
> Hmm where does the implicit wait for idle come from now?
Instead of having the wait here, we moved it into the engine/gt pm
tracking and added an intel_gt_pm_wait_for_idle().
> > -int __intel_wakeref_put_last(struct intel_runtime_pm *rpm,
> > - struct intel_wakeref *wf,
> > - int (*fn)(struct intel_wakeref *wf))
> > +static void intel_wakeref_put_last(struct intel_wakeref *wf)
> > {
> > - int err;
> > + if (!atomic_dec_and_test(>count))
> > + goto unlock;
> > +
> > + if (likely(!wf->ops->put(wf))) {
> > + rpm_put(wf);
> > + wake_up_var(>wakeref);
> > + } else {
> > + /* ops->put() must schedule its own release on deferral */
> > + atomic_set_release(>count, 1);
>
> I lose track here. On async call to gt_park we end up leaving
> with a count 1.
So we know wf->count is 0 and that we hold the lock preventing anyone
else raising wf->count back to 1. If we fail in our cleanup task,
knowing that we have exclusive control over the counter, we simply mark
it as 1 again (using _release to unlock anyone concurrently trying to
acquire the wakeref for themselves).
> > + /* Assume we are not in process context and so cannot sleep. */
> > + if (wf->ops->flags & INTEL_WAKEREF_PUT_ASYNC ||
> > + !mutex_trylock(>mutex)) {
>
> Didn't found anything in trylock that would prevent you
> from shooting you on your own leg.
Yup. It's immorally equivalent to spin_trylock.
> So it is up to caller (and eventually lockdep spam) if
> the async usage fails to follow the rules?
Not the caller, the fault lies in the wakeref. We either mark it that is
has to use the worker (process context) or fix it such that it is quick
and can run in atomic context. engine_pm was simple enough to make
atomic, gt_pm is promising but I needed to make rps waitfree (done) and
make the display pm truly async (which I baulked at!).
>
> > + schedule_work(>work);
> > + return;
> > + }
> > +
> > + intel_wakeref_put_last(wf);
> > }
> >
> > -void __intel_wakeref_init(struct intel_wakeref *wf, struct lock_class_key
> > *key)
> > +static void
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
Quoting Bloomfield, Jon (2019-08-07 15:33:51) [skip to end] > We didn't explore the idea of terminating orphaned contexts though (where > none of their resources are referenced by any other contexts). Is there a > reason why this is not feasible? In the case of compute (certainly HPC) > workloads, there would be no compositor taking the output so this might be a > solution. Sounds easier said than done. We have to go through each request and determine it if has an external reference (or if the object holding the reference has an external reference) to see if the output would be visible to a third party. Sounds like a conservative GC :| (Coming to that conclusion suggests that we should structure the request tracking to make reparenting easier.) We could take a pid-1 approach and move all the orphan timelines over to a new parent purely responsible for them. That honestly doesn't seem to achieve anything. (We are still stuck with tasks on the GPU and no way to kill them.) In comparison, persistence is a rarely used "feature" and cleaning up on context close fits in nicely with the process model. It just works as most users/clients would expect. (Although running in non-persistent by default hasn't show anything to explode on the desktop, it's too easy to construct scenarios where persistence turns out to be an advantage, particularly with chains of clients (the compositor model).) Between the two modes, we should have most bases covered, it's hard to argue for a third way (that is until someone has a usecase!) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Defer final intel_wakeref_put to process context
Chris Wilson writes:
> As we need to acquire a mutex to serialise the final
> intel_wakeref_put, we need to ensure that we are in process context at
> that time. However, we want to allow operation on the intel_wakeref from
> inside timer and other hardirq context, which means that need to defer
> that final put to a workqueue.
>
> Inside the final wakeref puts, we are safe to operate in any context, as
> we are simply marking up the HW and state tracking for the potential
> sleep. It's only the serialisation with the potential sleeping getting
> that requires careful wait avoidance. This allows us to retain the
> immediate processing as before (we only need to sleep over the same
> races as the current mutex_lock).
>
> v2: Add a selftest to ensure we exercise the code while lockdep watches.
> v3: That test was extremely loud and complained about many things!
>
Loud is good if it did found out something, did it? :)
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111295
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111245
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111256
> Fixes: 18398904ca9e ("drm/i915: Only recover active engines")
> Fixes: 51fbd8de87dc ("drm/i915/pmu: Atomically acquire the gt_pm wakeref")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_pm.c| 13 +--
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 38 +++--
> drivers/gpu/drm/i915/gt/intel_engine_pm.h | 18 ++--
> drivers/gpu/drm/i915/gt/intel_gt_pm.c | 28 +++
> drivers/gpu/drm/i915/gt/intel_gt_pm.h | 22 -
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +-
> drivers/gpu/drm/i915/gt/selftest_engine.c | 28 +++
> drivers/gpu/drm/i915/gt/selftest_engine.h | 14
> drivers/gpu/drm/i915/gt/selftest_engine_pm.c | 83 +++
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 +
> drivers/gpu/drm/i915/i915_gem.c | 26 +-
> drivers/gpu/drm/i915/intel_wakeref.c | 82 +-
> drivers/gpu/drm/i915/intel_wakeref.h | 62 +-
> .../drm/i915/selftests/i915_live_selftests.h | 5 +-
> 16 files changed, 301 insertions(+), 131 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine.c
> create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine.h
> create mode 100644 drivers/gpu/drm/i915/gt/selftest_engine_pm.c
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> index 72922703af49..17e3618241c5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
> @@ -130,7 +130,9 @@ static bool switch_to_kernel_context_sync(struct intel_gt
> *gt)
> }
> } while (i915_retire_requests(gt->i915) && result);
>
> - GEM_BUG_ON(gt->awake);
> + if (intel_gt_pm_wait_for_idle(gt))
> + result = false;
> +
> return result;
> }
>
> @@ -161,13 +163,6 @@ void i915_gem_suspend(struct drm_i915_private *i915)
>
> mutex_unlock(>drm.struct_mutex);
>
> - /*
> - * Assert that we successfully flushed all the work and
> - * reset the GPU back to its idle, low power state.
> - */
> - GEM_BUG_ON(i915->gt.awake);
> - flush_work(>gem.idle_work);
> -
> cancel_delayed_work_sync(>gt.hangcheck.work);
>
> i915_gem_drain_freed_objects(i915);
> @@ -244,8 +239,6 @@ void i915_gem_resume(struct drm_i915_private *i915)
> {
> GEM_TRACE("\n");
>
> - WARN_ON(i915->gt.awake);
> -
> mutex_lock(>drm.struct_mutex);
> intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index d38c114b0964..b57adc973e2a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1568,5 +1568,6 @@ intel_engine_find_active_request(struct intel_engine_cs
> *engine)
> }
>
> #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> +#include "selftest_engine.c"
> #include "selftest_engine_cs.c"
> #endif
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 0336204988d6..6b15e3335dd6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -37,28 +37,6 @@ static int __engine_unpark(struct intel_wakeref *wf)
> return 0;
> }
>
> -void intel_engine_pm_get(struct intel_engine_cs *engine)
> -{
> - intel_wakeref_get(>i915->runtime_pm, >wakeref,
> __engine_unpark);
> -}
> -
> -void intel_engine_park(struct intel_engine_cs *engine)
> -{
> - /*
> - * We are committed now to parking this engine, make sure there
> - * will be no more interrupts arriving later
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Isolate i915_getparam_ioctl()
== Series Details == Series: drm/i915: Isolate i915_getparam_ioctl() URL : https://patchwork.freedesktop.org/series/64840/ State : warning == Summary == $ dim checkpatch origin/drm-tip 73c89b65070d drm/i915: Isolate i915_getparam_ioctl() -:232: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #232: new file mode 100644 -:237: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #237: FILE: drivers/gpu/drm/i915/i915_getparam.c:1: +/* -:238: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use line 1 instead #238: FILE: drivers/gpu/drm/i915/i915_getparam.c:2: + * SPDX-License-Identifier: MIT total: 0 errors, 3 warnings, 0 checks, 369 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/22] drm/i915: Extract intel_frontbuffer active tracking
Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [cannot apply to v5.3-rc3 next-20190807] [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/Chris-Wilson/drm-i915-gem-Make-caps-scheduler-static/20190807-004738 base: git://anongit.freedesktop.org/drm-intel for-linux-next reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' include/linux/w1.h:272: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' lib/genalloc.c:1: warning: 'gen_pool_add_virt' not found lib/genalloc.c:1: warning: 'gen_pool_alloc' not found lib/genalloc.c:1: warning: 'gen_pool_free' not found lib/genalloc.c:1: warning: 'gen_pool_alloc_algo' not found fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found include/linux/input/sparse-keymap.h:43: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/clk.h:381: warning: Function parameter or member 'num_clks' not described in 'devm_clk_bulk_get_optional' mm/util.c:1: warning: 'get_user_pages_fast' not found mm/slab.c:4215: warning: Function parameter or member 'objp' not described in '__ksize' >> drivers/gpu/drm/i915/i915_gem.c:1: warning: 'i915_gem_track_fb' not found drivers/gpu/drm/i915/display/intel_dpll_mgr.h:158: warning: Enum value 'DPLL_ID_TGL_MGPLL5' not described in enum 'intel_dpll_id' drivers/gpu/drm/i915/display/intel_dpll_mgr.h:158: warning: Enum value 'DPLL_ID_TGL_MGPLL6' not described in enum 'intel_dpll_id' drivers/gpu/drm/i915/display/intel_dpll_mgr.h:158: warning: Excess enum value 'DPLL_ID_TGL_TCPLL6' description in 'intel_dpll_id' drivers/gpu/drm/i915/display/intel_dpll_mgr.h:158: warning: Excess enum value 'DPLL_ID_TGL_TCPLL5' description in 'intel_dpll_id' drivers/gpu/drm/i915/display/intel_dpll_mgr.h:342: warning: Function parameter or member 'wakeref' not described in 'intel_shared_dpll' Error: Cannot open file drivers/gpu/drm/i915/i915_gem_batch_pool.c Error: Cannot open file drivers/gpu/drm/i915/i915_gem_batch_pool.c Error: Cannot open file drivers/gpu/drm/i915/i915_gem_batch_pool.c drivers/gpu/drm/mcde/mcde_drv.c:1: warning: 'ST-Ericsson MCDE DRM Driver' not found include/linux/skbuff.h:893: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'head_frag' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'e
[Intel-gfx] [RFC] drm/i915/vlv: allocate Gunit s0ix state on demand
Valleyview is the only platform that requires the Gunit s0ix save
state. Allocate it dynamically instead of burdening all platforms with
it in drm_i915_private.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 79 -
drivers/gpu/drm/i915/i915_drv.h | 64 +-
2 files changed, 79 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index efe904626bf5..c1483cd8e76c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2559,11 +2559,81 @@ static int i915_pm_restore(struct device *kdev)
* a black-box for the driver. Further investigation is needed to reduce the
* saved/restored registers even further, by following the same 3 criteria.
*/
+
+struct vlv_s0ix_state {
+ /* GAM */
+ u32 wr_watermark;
+ u32 gfx_prio_ctrl;
+ u32 arb_mode;
+ u32 gfx_pend_tlb0;
+ u32 gfx_pend_tlb1;
+ u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
+ u32 media_max_req_count;
+ u32 gfx_max_req_count;
+ u32 render_hwsp;
+ u32 ecochk;
+ u32 bsd_hwsp;
+ u32 blt_hwsp;
+ u32 tlb_rd_addr;
+
+ /* MBC */
+ u32 g3dctl;
+ u32 gsckgctl;
+ u32 mbctl;
+
+ /* GCP */
+ u32 ucgctl1;
+ u32 ucgctl3;
+ u32 rcgctl1;
+ u32 rcgctl2;
+ u32 rstctl;
+ u32 misccpctl;
+
+ /* GPM */
+ u32 gfxpause;
+ u32 rpdeuhwtc;
+ u32 rpdeuc;
+ u32 ecobus;
+ u32 pwrdwnupctl;
+ u32 rp_down_timeout;
+ u32 rp_deucsw;
+ u32 rcubmabdtmr;
+ u32 rcedata;
+ u32 spare2gh;
+
+ /* Display 1 CZ domain */
+ u32 gt_imr;
+ u32 gt_ier;
+ u32 pm_imr;
+ u32 pm_ier;
+ u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
+
+ /* GT SA CZ domain */
+ u32 tilectl;
+ u32 gt_fifoctl;
+ u32 gtlc_wake_ctrl;
+ u32 gtlc_survive;
+ u32 pmwgicz;
+
+ /* Display 2 CZ domain */
+ u32 gu_ctl0;
+ u32 gu_ctl1;
+ u32 pcbr;
+ u32 clock_gate_dis2;
+};
+
static void vlv_save_gunit_s0ix_state(struct drm_i915_private *dev_priv)
{
- struct vlv_s0ix_state *s = _priv->vlv_s0ix_state;
+ struct vlv_s0ix_state *s = dev_priv->vlv_s0ix_state;
int i;
+ if (!s) {
+ s = devm_kmalloc(dev_priv->drm.dev, sizeof(*s), GFP_KERNEL);
+ if (!s)
+ return;
+ dev_priv->vlv_s0ix_state = s;
+ }
+
/* GAM 0x4000-0x4770 */
s->wr_watermark = I915_READ(GEN7_WR_WATERMARK);
s->gfx_prio_ctrl= I915_READ(GEN7_GFX_PRIO_CTRL);
@@ -2642,10 +2712,15 @@ static void vlv_save_gunit_s0ix_state(struct
drm_i915_private *dev_priv)
static void vlv_restore_gunit_s0ix_state(struct drm_i915_private *dev_priv)
{
- struct vlv_s0ix_state *s = _priv->vlv_s0ix_state;
+ struct vlv_s0ix_state *s = dev_priv->vlv_s0ix_state;
u32 val;
int i;
+ if (!s) {
+ DRM_DEBUG_KMS("gunit restore without save state\n");
+ return;
+ }
+
/* GAM 0x4000-0x4770 */
I915_WRITE(GEN7_WR_WATERMARK, s->wr_watermark);
I915_WRITE(GEN7_GFX_PRIO_CTRL, s->gfx_prio_ctrl);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d424ddd3523..30e33103b845 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -580,67 +580,7 @@ struct i915_suspend_saved_registers {
u16 saveGCDGMBUS;
};
-struct vlv_s0ix_state {
- /* GAM */
- u32 wr_watermark;
- u32 gfx_prio_ctrl;
- u32 arb_mode;
- u32 gfx_pend_tlb0;
- u32 gfx_pend_tlb1;
- u32 lra_limits[GEN7_LRA_LIMITS_REG_NUM];
- u32 media_max_req_count;
- u32 gfx_max_req_count;
- u32 render_hwsp;
- u32 ecochk;
- u32 bsd_hwsp;
- u32 blt_hwsp;
- u32 tlb_rd_addr;
-
- /* MBC */
- u32 g3dctl;
- u32 gsckgctl;
- u32 mbctl;
-
- /* GCP */
- u32 ucgctl1;
- u32 ucgctl3;
- u32 rcgctl1;
- u32 rcgctl2;
- u32 rstctl;
- u32 misccpctl;
-
- /* GPM */
- u32 gfxpause;
- u32 rpdeuhwtc;
- u32 rpdeuc;
- u32 ecobus;
- u32 pwrdwnupctl;
- u32 rp_down_timeout;
- u32 rp_deucsw;
- u32 rcubmabdtmr;
- u32 rcedata;
- u32 spare2gh;
-
- /* Display 1 CZ domain */
- u32 gt_imr;
- u32 gt_ier;
- u32 pm_imr;
- u32 pm_ier;
- u32 gt_scratch[GEN7_GT_SCRATCH_REG_NUM];
-
- /* GT SA CZ domain */
- u32 tilectl;
- u32 gt_fifoctl;
- u32 gtlc_wake_ctrl;
- u32 gtlc_survive;
- u32 pmwgicz;
-
- /* Display 2 CZ domain */
- u32 gu_ctl0;
- u32 gu_ctl1;
- u32 pcbr;
- u32 clock_gate_dis2;
-};
+struct vlv_s0ix_state;
struct intel_rps_ei {
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close
> -Original Message- > From: Chris Wilson > Sent: Wednesday, August 7, 2019 7:14 AM > To: Bloomfield, Jon ; intel- > g...@lists.freedesktop.org > Cc: Joonas Lahtinen ; Winiarski, Michal > > Subject: RE: [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close > > Quoting Bloomfield, Jon (2019-08-07 15:04:16) > > Ok, so your concern is supporting non-persistence on older non-preempting, > engine-reset capable, hardware. Why is that strictly required? Can't we simply > make it dependent on the features needed to do it well, and if your hardware > cannot, then the advice is not to disable hangcheck? I'm doubtful that anyone > would attempt a HPC type workload on n IVB. > > Our advice was not to disable hangcheck :) > > With the cat out of the bag, my concern is dotting the Is and crossing > the Ts. Fixing up the error handling path to the reset isn't all that > bad. But I'm not going to advertise the persistence-parameter support > unless we have a clean solution, and we can advise that compute > workloads are better handled with new hardware. > > > I'm not sure I understand your "survives hangcheck" idea. You mean instead > of simply disabling hangcheck, just opt in to persistence and have that also > prevent hangcheck? Isn't that the wrong way around, since persistence is what > is happening today? > > Persistence is the clear-and-present danger. I'm just trying to sketch a > path for endless support, trying to ask myself questions such as: Is the > persistence parameter still required? What other parameters make sense? > Does anything less than CPU-esque isolation make sense? :) > -Chris I personally liked your persistence idea :-) Isolation doesn't really solve the problem in this case. So, customer enables isolation for a HPC workload. That workload hangs, and user hits ctrl-C. We still have a hung workload and the next job in the queue still can't run. Also, Isolation is kind of meaningless when there is only one engine that's capable of running your workload. On Gen9, pretty much every type of workload requires some RCS involvement, and RCS is where the compute workloads need to run. So isolation hasn't helped us. I'd settle for umd opting in to non-persistence and not providing the automatic association with hangcheck. That at least ensures well behaved umd's don't kill the system. We didn't explore the idea of terminating orphaned contexts though (where none of their resources are referenced by any other contexts). Is there a reason why this is not feasible? In the case of compute (certainly HPC) workloads, there would be no compositor taking the output so this might be a solution. Jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] drm/i915: Isolate i915_getparam_ioctl()
On Wed, Aug 07, 2019 at 03:20:41PM +0100, Chris Wilson wrote:
> This giant switch has tendrils all other the struct and does not fit
> into the rest of the driver bring up and control of i915_drv.c. Push it
> to one side so that it can grow in peace.
>
> Signed-off-by: Chris Wilson
> Acked-by: Tvrtko Ursulin
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/i915_drv.c | 167 --
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> drivers/gpu/drm/i915/i915_getparam.c | 168 +++
> 4 files changed, 172 insertions(+), 167 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/i915_getparam.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8fe157f71617..d9f1b23bdf77 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -41,6 +41,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
> # core driver code
> i915-y += i915_drv.o \
> i915_irq.o \
> + i915_getparam.o \
> i915_params.o \
> i915_pci.o \
> i915_scatterlist.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index efe904626bf5..3480db36b63f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -62,17 +62,12 @@
>
> #include "gem/i915_gem_context.h"
> #include "gem/i915_gem_ioctls.h"
> -#include "gt/intel_engine_user.h"
> #include "gt/intel_gt.h"
> #include "gt/intel_gt_pm.h"
> -#include "gt/intel_reset.h"
> -#include "gt/intel_workarounds.h"
> -#include "gt/uc/intel_uc.h"
>
> #include "i915_debugfs.h"
> #include "i915_drv.h"
> #include "i915_irq.h"
> -#include "i915_pmu.h"
> #include "i915_query.h"
> #include "i915_trace.h"
> #include "i915_vgpu.h"
> @@ -344,168 +339,6 @@ static void intel_detect_pch(struct drm_i915_private
> *dev_priv)
> pci_dev_put(pch);
> }
>
> -static int i915_getparam_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct pci_dev *pdev = dev_priv->drm.pdev;
> - const struct sseu_dev_info *sseu = _INFO(dev_priv)->sseu;
> - drm_i915_getparam_t *param = data;
> - int value;
> -
> - switch (param->param) {
> - case I915_PARAM_IRQ_ACTIVE:
> - case I915_PARAM_ALLOW_BATCHBUFFER:
> - case I915_PARAM_LAST_DISPATCH:
> - case I915_PARAM_HAS_EXEC_CONSTANTS:
> - /* Reject all old ums/dri params. */
> - return -ENODEV;
> - case I915_PARAM_CHIPSET_ID:
> - value = pdev->device;
> - break;
> - case I915_PARAM_REVISION:
> - value = pdev->revision;
> - break;
> - case I915_PARAM_NUM_FENCES_AVAIL:
> - value = dev_priv->ggtt.num_fences;
> - break;
> - case I915_PARAM_HAS_OVERLAY:
> - value = dev_priv->overlay ? 1 : 0;
> - break;
> - case I915_PARAM_HAS_BSD:
> - value = !!intel_engine_lookup_user(dev_priv,
> -I915_ENGINE_CLASS_VIDEO, 0);
> - break;
> - case I915_PARAM_HAS_BLT:
> - value = !!intel_engine_lookup_user(dev_priv,
> -I915_ENGINE_CLASS_COPY, 0);
> - break;
> - case I915_PARAM_HAS_VEBOX:
> - value = !!intel_engine_lookup_user(dev_priv,
> -
> I915_ENGINE_CLASS_VIDEO_ENHANCE, 0);
> - break;
> - case I915_PARAM_HAS_BSD2:
> - value = !!intel_engine_lookup_user(dev_priv,
> -I915_ENGINE_CLASS_VIDEO, 1);
> - break;
> - case I915_PARAM_HAS_LLC:
> - value = HAS_LLC(dev_priv);
> - break;
> - case I915_PARAM_HAS_WT:
> - value = HAS_WT(dev_priv);
> - break;
> - case I915_PARAM_HAS_ALIASING_PPGTT:
> - value = INTEL_PPGTT(dev_priv);
> - break;
> - case I915_PARAM_HAS_SEMAPHORES:
> - value = !!(dev_priv->caps.scheduler &
> I915_SCHEDULER_CAP_SEMAPHORES);
> - break;
> - case I915_PARAM_HAS_SECURE_BATCHES:
> - value = capable(CAP_SYS_ADMIN);
> - break;
> - case I915_PARAM_CMD_PARSER_VERSION:
> - value = i915_cmd_parser_get_version(dev_priv);
> - break;
> - case I915_PARAM_SUBSLICE_TOTAL:
> - value = intel_sseu_subslice_total(sseu);
> - if (!value)
> - return -ENODEV;
> - break;
> - case I915_PARAM_EU_TOTAL:
> - value = sseu->eu_total;
> - if (!value)
> - return -ENODEV;
> - break;
> - case I915_PARAM_HAS_GPU_RESET:
> - value = i915_modparams.enable_hangcheck &&
> -
Re: [Intel-gfx] [PATCH] drm/i915: split out intel_pch.[ch] from i915_drv.[ch]
On Wed, Aug 07, 2019 at 03:04:15PM +0300, Jani Nikula wrote:
> Abstract the rather self-contained piece of code from i915_drv.[ch]. No
> functional changes.
>
> Cc: José Roberto de Souza
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Jani Nikula
Acked-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile| 1 +
> drivers/gpu/drm/i915/i915_drv.c | 194 -
> drivers/gpu/drm/i915/i915_drv.h | 60 +
> drivers/gpu/drm/i915/intel_pch.c | 201 +++
> drivers/gpu/drm/i915/intel_pch.h | 73 +++
> 5 files changed, 276 insertions(+), 253 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_pch.c
> create mode 100644 drivers/gpu/drm/i915/intel_pch.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 8fe157f71617..7f710415a525 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -48,6 +48,7 @@ i915-y += i915_drv.o \
> i915_sysfs.o \
> intel_csr.o \
> intel_device_info.o \
> + intel_pch.o \
> intel_pm.o \
> intel_runtime_pm.o \
> intel_sideband.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 535209ee4741..5807c1a0dab1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -150,200 +150,6 @@ __i915_printk(struct drm_i915_private *dev_priv, const
> char *level,
> }
> }
>
> -/* Map PCH device id to PCH type, or PCH_NONE if unknown. */
> -static enum intel_pch
> -intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
> -{
> - switch (id) {
> - case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> - WARN_ON(!IS_GEN(dev_priv, 5));
> - return PCH_IBX;
> - case INTEL_PCH_CPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found CougarPoint PCH\n");
> - WARN_ON(!IS_GEN(dev_priv, 6) && !IS_IVYBRIDGE(dev_priv));
> - return PCH_CPT;
> - case INTEL_PCH_PPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found PantherPoint PCH\n");
> - WARN_ON(!IS_GEN(dev_priv, 6) && !IS_IVYBRIDGE(dev_priv));
> - /* PantherPoint is CPT compatible */
> - return PCH_CPT;
> - case INTEL_PCH_LPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found LynxPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
> - return PCH_LPT;
> - case INTEL_PCH_LPT_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) && !IS_BDW_ULT(dev_priv));
> - return PCH_LPT;
> - case INTEL_PCH_WPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found WildcatPoint PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> - WARN_ON(IS_HSW_ULT(dev_priv) || IS_BDW_ULT(dev_priv));
> - /* WildcatPoint is LPT compatible */
> - return PCH_LPT;
> - case INTEL_PCH_WPT_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found WildcatPoint LP PCH\n");
> - WARN_ON(!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv));
> - WARN_ON(!IS_HSW_ULT(dev_priv) && !IS_BDW_ULT(dev_priv));
> - /* WildcatPoint is LPT compatible */
> - return PCH_LPT;
> - case INTEL_PCH_SPT_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv));
> - return PCH_SPT;
> - case INTEL_PCH_SPT_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv));
> - return PCH_SPT;
> - case INTEL_PCH_KBP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Kaby Lake PCH (KBP)\n");
> - WARN_ON(!IS_SKYLAKE(dev_priv) && !IS_KABYLAKE(dev_priv) &&
> - !IS_COFFEELAKE(dev_priv));
> - /* KBP is SPT compatible */
> - return PCH_SPT;
> - case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> - WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> - return PCH_CNP;
> - case INTEL_PCH_CNP_LP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Cannon Lake LP PCH (CNP-LP)\n");
> - WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> - return PCH_CNP;
> - case INTEL_PCH_CMP_DEVICE_ID_TYPE:
> - DRM_DEBUG_KMS("Found Comet Lake PCH (CMP)\n");
> - WARN_ON(!IS_COFFEELAKE(dev_priv));
> - /* CometPoint is CNP Compatible */
> - return PCH_CNP;
> - case
