Re: [Intel-gfx] [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
On 2022-05-13 at 14:06:11 -0700, Jordan Justen wrote:
> On 2022-05-13 05:31:00, Lionel Landwerlin wrote:
> > On 02/05/2022 17:15, Ramalingam C wrote:
> > > Capture the impact of memory region preference list of the objects, on
> > > their memory residency and Flat-CCS capability.
> > >
> > > v2:
> > >Fix the Flat-CCS capability of an obj with {lmem, smem} preference
> > >list [Thomas]
> > > v3:
> > >Reworded the doc [Matt]
> > >
> > > Signed-off-by: Ramalingam C
> > > cc: Matthew Auld
> > > cc: Thomas Hellstrom
> > > cc: Daniel Vetter
> > > cc: Jon Bloomfield
> > > cc: Lionel Landwerlin
> > > cc: Kenneth Graunke
> > > cc: mesa-...@lists.freedesktop.org
> > > cc: Jordan Justen
> > > cc: Tony Ye
> > > Reviewed-by: Matthew Auld
> > > ---
> > > include/uapi/drm/i915_drm.h | 16
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > index a2def7b27009..b7e1c2fe08dc 100644
> > > --- a/include/uapi/drm/i915_drm.h
> > > +++ b/include/uapi/drm/i915_drm.h
> > > @@ -3443,6 +3443,22 @@ struct drm_i915_gem_create_ext {
> > >* At which point we get the object handle in
> > > &drm_i915_gem_create_ext.handle,
> > >* along with the final object size in &drm_i915_gem_create_ext.size,
> > > which
> > >* should account for any rounding up, if required.
> > > + *
> > > + * Note that userspace has no means of knowing the current backing region
> > > + * for objects where @num_regions is larger than one. The kernel will
> > > only
> > > + * ensure that the priority order of the @regions array is honoured,
> > > either
> > > + * when initially placing the object, or when moving memory around due to
> > > + * memory pressure
> > > + *
> > > + * On Flat-CCS capable HW, compression is supported for the objects
> > > residing
> > > + * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
> > > + * memory class in @regions and migrated (by I915, due to memory
> > > + * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915
> > > needs to
> > > + * decompress the content. But I915 dosen't have the required
> > > information to
> > > + * decompress the userspace compressed objects.
> > > + *
> > > + * So I915 supports Flat-CCS, only on the objects which can reside only
> > > on
> > > + * I915_MEMORY_CLASS_DEVICE regions.
> >
> > I think it's fine to assume Flat-CSS surface will always be in lmem.
> >
> > I see no issue for the Anv Vulkan driver.
> >
> > Maybe Nanley or Ken can speak for the Iris GL driver?
> >
>
> Acked-by: Jordan Justen
Thank you Jordan for the Ack!
Ram
>
> I think Nanley has accounted for this on iris with:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8
>
> -Jordan
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
On Mon-16-05-2022 02:09 pm, Jani Nikula wrote: On Mon, 02 May 2022, Harry Wentland wrote: Both the kernel and IGT series look good to me. I recommend you merge the entire kernel set as one into drm-next. We can pull it into amd-staging-drm-next so as not to break our CI once the IGT patches land. @Harry Can we have your Ack-by to merge this series via drm-misc-next? IGT patches are already landed. :-) - Bhanu Can we read that as an ack to merge via drm-misc-next? :) BR, Jani.
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Add workaround 22014600077 (rev2)
== Series Details == Series: drm/i915/dg2: Add workaround 22014600077 (rev2) URL : https://patchwork.freedesktop.org/series/104097/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11668_full -> Patchwork_104097v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104097v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104097v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104097v2_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-contexts-10ms: - shard-glk: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-glk9/igt@gem_...@in-flight-contexts-10ms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-glk1/igt@gem_...@in-flight-contexts-10ms.html * igt@kms_dither@fb-8bpc-vs-panel-6bpc@edp-1-pipe-a: - shard-iclb: NOTRUN -> [SKIP][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-iclb6/igt@kms_dither@fb-8bpc-vs-panel-6...@edp-1-pipe-a.html Known issues Here are the changes found in Patchwork_104097v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ccs@ctrl-surf-copy: - shard-iclb: NOTRUN -> [SKIP][4] ([i915#5327]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-iclb6/igt@gem_...@ctrl-surf-copy.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][5] ([i915#3354]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-snb4/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-iclb2/igt@gem_exec_fair@basic-p...@bcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-iclb2/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_lmem_swapping@parallel-multi: - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-apl3/igt@gem_lmem_swapp...@parallel-multi.html * igt@gem_lmem_swapping@verify-random: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-skl8/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap_wc@coherency: - shard-snb: [PASS][14] -> [SKIP][15] ([fdo#109271]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-snb2/igt@gem_mmap...@coherency.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-snb6/igt@gem_mmap...@coherency.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][16] ([i915#768]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-iclb6/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html * igt@gem_spin_batch@spin-each: - shard-apl: [PASS][17] -> [FAIL][18] ([i915#2898]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl7/igt@gem_spin_ba...@spin-each.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-apl2/igt@gem_spin_ba...@spin-each.html * igt@gem_userptr_blits@dmabuf-sync: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#3323]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-iclb6/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#3297]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/shard-iclb6/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@vma-merge: - s
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12
== Series Details == Series: drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12 URL : https://patchwork.freedesktop.org/series/104104/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11668_full -> Patchwork_104104v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104104v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104104v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104104v1_full: ### IGT changes ### Possible regressions * igt@kms_dither@fb-8bpc-vs-panel-6bpc@edp-1-pipe-a: - shard-iclb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-iclb7/igt@kms_dither@fb-8bpc-vs-panel-6...@edp-1-pipe-a.html * igt@prime_vgem@coherency-blt: - shard-tglb: [PASS][2] -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-tglb8/igt@prime_v...@coherency-blt.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-tglb3/igt@prime_v...@coherency-blt.html Known issues Here are the changes found in Patchwork_104104v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ccs@ctrl-surf-copy: - shard-iclb: NOTRUN -> [SKIP][4] ([i915#5327]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-iclb7/igt@gem_...@ctrl-surf-copy.html * igt@gem_ccs@suspend-resume: - shard-kbl: NOTRUN -> [SKIP][5] ([fdo#109271]) +27 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-kbl6/igt@gem_...@suspend-resume.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][6] ([i915#3354]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-glk6/igt@gem_exec_f...@basic-deadline.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-glk9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl8/igt@gem_exec_fair@basic-none-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-apl8/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-kbl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-kbl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_flush@basic-batch-kernel-default-wb: - shard-snb: [PASS][13] -> [SKIP][14] ([fdo#109271]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-snb4/igt@gem_exec_fl...@basic-batch-kernel-default-wb.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-wb.html * igt@gem_exec_suspend@basic-s0@smem: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([i915#4831]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-kbl7/igt@gem_exec_suspend@basic...@smem.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-kbl6/igt@gem_exec_suspend@basic...@smem.html * igt@gem_lmem_swapping@verify-random: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-skl6/igt@gem_lmem_swapp...@verify-random.html * igt@gem_render_copy@y-tiled-mc-ccs-to-vebox-y-tiled: - shard-iclb: NOTRUN -> [SKIP][18] ([i915#768]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-iclb7/igt@gem_render_c...@y-tiled-mc-ccs-to-vebox-y-tiled.html * igt@gem_userptr_blits@dmabuf-sync: - shard-iclb: NOTRUN -> [SKIP][19] ([i915#3323]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/shard-iclb7/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-iclb: NOTRUN -> [SKIP][20] ([i915#3297]) [20]: https://intel-gfx-ci.01.or
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for i915: SSEU handling updates (rev4)
On Wed, May 18, 2022 at 12:34:11AM +, Patchwork wrote: > == Series Details == > > Series: i915: SSEU handling updates (rev4) > URL : https://patchwork.freedesktop.org/series/103244/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11666_full -> Patchwork_103244v4_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_103244v4_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_103244v4_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (11 -> 11) > -- > > No changes in participating hosts > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_103244v4_full: > > ### IGT changes ### > > Possible regressions > > * igt@kms_flip@flip-vs-panning-interruptible@c-edp1: > - shard-iclb: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-iclb3/igt@kms_flip@flip-vs-panning-interrupti...@c-edp1.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-iclb8/igt@kms_flip@flip-vs-panning-interrupti...@c-edp1.html <3> [607.307030] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: <3> [607.307121] rcu: 3-...!: (159 GPs behind) idle=834/0/0x0 softirq=27765/27765 fqs=1 (false positive?) <3> [607.307825] rcu: 7-...!: (172 GPs behind) idle=abc/0/0x0 softirq=23642/23643 fqs=1 (false positive?) <4> [607.307934](detected by 0, t=65002 jiffies, g=64137, q=5840) <6> [607.307942] Sending NMI from CPU 0 to CPUs 3: <4> [607.308032] NMI backtrace for cpu 3 skipped: idling at intel_idle+0x67/0xc0 <6> [607.308950] Sending NMI from CPU 0 to CPUs 7: <4> [607.309045] NMI backtrace for cpu 7 skipped: idling at intel_idle+0x67/0xc0 <3> [607.309957] rcu: rcu_preempt kthread timer wakeup didn't happen for 64995 jiffies! g64137 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 <3> [607.310053] rcu: Possible timer handling issue on cpu=3 timer-softirq=16787 <3> [607.310110] rcu: rcu_preempt kthread starved for 64998 jiffies! g64137 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3 <3> [607.310195] rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior. <3> [607.310267] rcu: RCU grace-period kthread stack dump: <6> [607.310310] task:rcu_preempt state:I stack:14472 pid: 13 ppid: 2 flags:0x4000 <6> [607.310326] Call Trace: <6> [607.310330] <6> [607.310339] __schedule+0x483/0xb50 <6> [607.310353] ? schedule_timeout+0x1b9/0x2e0 <6> [607.310367] schedule+0x3f/0xa0 <6> [607.310376] schedule_timeout+0x1be/0x2e0 <6> [607.310386] ? del_timer_sync+0xb0/0xb0 <6> [607.310398] ? 0x8100 <6> [607.310408] ? rcu_gp_cleanup+0x440/0x440 <6> [607.310413] rcu_gp_fqs_loop+0x273/0x3b0 <6> [607.310427] rcu_gp_kthread+0xb8/0x120 <6> [607.310436] kthread+0xed/0x120 <6> [607.310443] ? kthread_complete_and_exit+0x20/0x20 <6> [607.310452] ret_from_fork+0x1f/0x30 <6> [607.310478] <3> [607.310481] rcu: Stack dump where RCU GP kthread last ran: <6> [607.310527] Sending NMI from CPU 0 to CPUs 3: <4> [607.310602] NMI backtrace for cpu 3 skipped: idling at intel_idle+0x67/0xc0 It's not clear what this is from (no indication it's even related to the graphics driver). Definitely not the kind of thing that the SSEU rework in this series could cause to happen during a display test. Matt > > > Known issues > > > Here are the changes found in Patchwork_103244v4_full that come from known > issues: > > ### CI changes ### > > Possible fixes > > * boot: > - shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], > [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], > [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], > [PASS][19], [FAIL][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], > [PASS][25], [PASS][26]) ([i915#5032]) -> ([PASS][27], [PASS][28], [PASS][29], > [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], > [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], > [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], > [PASS][48], [PASS][49]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html >[8]: >
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3)
== Series Details == Series: drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3) URL : https://patchwork.freedesktop.org/series/93447/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11668_full -> Patchwork_93447v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_93447v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_93447v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_93447v3_full: ### IGT changes ### Possible regressions * igt@kms_dither@fb-8bpc-vs-panel-6bpc@edp-1-pipe-a: - shard-iclb: NOTRUN -> [SKIP][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-iclb8/igt@kms_dither@fb-8bpc-vs-panel-6...@edp-1-pipe-a.html Known issues Here are the changes found in Patchwork_93447v3_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-apl: ([PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [FAIL][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51]) ([i915#4386]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl8/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl8/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl8/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl7/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl7/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl7/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl6/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl4/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl4/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl2/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/shard-apl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl8/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl8/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl8/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl6/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/shard-apl6/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: SSEU handling updates (rev4)
== Series Details == Series: i915: SSEU handling updates (rev4) URL : https://patchwork.freedesktop.org/series/103244/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11666_full -> Patchwork_103244v4_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103244v4_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103244v4_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103244v4_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-panning-interruptible@c-edp1: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-iclb3/igt@kms_flip@flip-vs-panning-interrupti...@c-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-iclb8/igt@kms_flip@flip-vs-panning-interrupti...@c-edp1.html Known issues Here are the changes found in Patchwork_103244v4_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [FAIL][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26]) ([i915#5032]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl1/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl3/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl4/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl4/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl6/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/shard-skl6/boot.html [36]: https://intel-gfx-ci.01.org/tr
[Intel-gfx] [linux-next:master] BUILD REGRESSION 47c1c54d1bcd0a69a56b49473bc20f17b70e5242
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 47c1c54d1bcd0a69a56b49473bc20f17b70e5242 Add linux-next specific files for 20220517 Error/Warning reports: https://lore.kernel.org/linux-mm/202204181931.klac6fwo-...@intel.com https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https://lore.kernel.org/linux-mm/202205030636.lyggelhv-...@intel.com https://lore.kernel.org/linux-mm/202205041248.wgcwpcev-...@intel.com https://lore.kernel.org/linux-mm/202205150051.3rzuooag-...@intel.com https://lore.kernel.org/linux-mm/202205150117.sd6hzbvm-...@intel.com https://lore.kernel.org/linux-mm/202205172305.y8xobeeg-...@intel.com https://lore.kernel.org/linux-mm/202205172344.3gfeaum1-...@intel.com https://lore.kernel.org/llvm/202205052057.2tyesxsl-...@intel.com https://lore.kernel.org/llvm/202205162125.zhvoofzf-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arm/mach-versatile/versatile.c:56:14: warning: no previous prototype for function 'mmc_status' [-Wmissing-prototypes] arch/riscv/include/asm/pgtable.h:695:9: error: call to undeclared function 'pud_leaf'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] arch/x86/kvm/pmu.h:20:32: warning: 'vmx_icl_pebs_cpu' defined but not used [-Wunused-const-variable=] csky-linux-ld: drivers/nvme/host/fc.c:1915: undefined reference to `blkcg_get_fc_appid' drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1364:5: warning: no previous prototype for 'amdgpu_discovery_get_mall_info' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/soc21.c:171:6: warning: no previous prototype for 'soc21_grbm_select' [-Wmissing-prototypes] drivers/gpu/drm/solomon/ssd130x-spi.c:154:35: warning: 'ssd130x_spi_table' defined but not used [-Wunused-const-variable=] drivers/nvme/host/fc.c:1914: undefined reference to `blkcg_get_fc_appid' drivers/video/fbdev/omap/hwa742.c:492:5: warning: no previous prototype for 'hwa742_update_window_async' [-Wmissing-prototypes] fs/buffer.c:2254:5: warning: stack frame size (2152) exceeds limit (1024) in 'block_read_full_folio' [-Wframe-larger-than] fs/ntfs/aops.c:378:12: warning: stack frame size (2216) exceeds limit (1024) in 'ntfs_read_folio' [-Wframe-larger-than] kernel/trace/fgraph.c:37:12: warning: no previous prototype for 'ftrace_enable_ftrace_graph_caller' [-Wmissing-prototypes] kernel/trace/fgraph.c:37:12: warning: no previous prototype for function 'ftrace_enable_ftrace_graph_caller' [-Wmissing-prototypes] kernel/trace/fgraph.c:46:12: warning: no previous prototype for 'ftrace_disable_ftrace_graph_caller' [-Wmissing-prototypes] kernel/trace/fgraph.c:46:12: warning: no previous prototype for function 'ftrace_disable_ftrace_graph_caller' [-Wmissing-prototypes] powerpc64-linux-ld: drivers/nfc/nxp-nci/firmware.o:(.bss+0x0): multiple definition of `cacheline_aligned'; drivers/nfc/nxp-nci/core.o:(.bss+0x40): first defined here powerpc64-linux-ld: drivers/nfc/s3fwrn5/nci.o:(.bss+0x0): multiple definition of `cacheline_aligned'; drivers/nfc/s3fwrn5/firmware.o:(.bss+0x40): first defined here powerpc64-linux-ld: drivers/nvme/target/discovery.o:(.bss+0x40): multiple definition of `cacheline_aligned'; drivers/nvme/target/fabrics-cmd.o:(.bss+0x0): first defined here powerpc64-linux-ld: fs/ntfs/attrib.o:(.bss+0x0): multiple definition of `cacheline_aligned'; fs/ntfs/aops.o:(.bss+0x0): first defined here powerpc64-linux-ld: net/mac80211/he.o:(.bss+0x0): multiple definition of `cacheline_aligned'; net/mac80211/aead_api.o:(.bss+0x0): first defined here powerpc64-linux-ld: net/nfc/nci/ntf.o:(.bss+0x0): multiple definition of `cacheline_aligned'; net/nfc/nci/data.o:(.bss+0x0): first defined here powerpc64-linux-ld: net/nfc/rawsock.o:(.bss+0x40): multiple definition of `cacheline_aligned'; net/nfc/af_nfc.o:(.bss+0x40): first defined here powerpc64-linux-ld: net/wireless/sysfs.o:(.bss+0x40): multiple definition of `cacheline_aligned'; net/wireless/core.o:(.bss+0x1c0): first defined here powerpc64-linux-ld: sound/pci/ac97/ac97_pcm.o:(.bss+0x0): multiple definition of `cacheline_aligned'; sound/pci/ac97/ac97_codec.o:(.bss+0x40): first defined here Unverified Error/Warning (likely false positive, please contact us if interested): Makefile:686: arch/h8300/Makefile: No such file or directory arch/Kconfig:10: can't open file "arch/h8300/Kconfig" drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5102:14: warning: variable 'allow_lttpr_non_transparent_mode' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5147:6: warning: no previous prototype for 'dp_parse_lttpr_mode
Re: [Intel-gfx] [PATCH 11/11] drm/i915: Fix undefined behavior due to shift overflowing the constant
On 4/5/22 08:15, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Fix:
>
> In file included from :0:0:
> drivers/gpu/drm/i915/gt/uc/intel_guc.c: In function ‘intel_guc_send_mmio’:
> ././include/linux/compiler_types.h:352:38: error: call to
> ‘__compiletime_assert_1047’ \
> declared with attribute error: FIELD_PREP: mask is not constant
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
>
> and other build errors due to shift overflowing values.
>
> See https://lore.kernel.org/r/ykwq6%2btih8gqp...@zn.tnic for the gory
> details as to why it triggers with older gccs only.
>
Acked-by: Randy Dunlap
Tested-by: Randy Dunlap
Is this merged anywhere?
It could/should at least be in linux-next so that other people
don't waste time on it.
thanks.
> Signed-off-by: Borislav Petkov
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> ---
> .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 2 +-
> .../i915/gt/uc/abi/guc_communication_ctb_abi.h | 2 +-
> .../gpu/drm/i915/gt/uc/abi/guc_messages_abi.h | 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 2 +-
> drivers/gpu/drm/i915/i915_reg.h| 18 +-
> 5 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> index 7afdadc7656f..e835f28c0020 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> @@ -50,7 +50,7 @@
>
> #define HOST2GUC_SELF_CFG_REQUEST_MSG_LEN
> (GUC_HXG_REQUEST_MSG_MIN_LEN + 3u)
> #define HOST2GUC_SELF_CFG_REQUEST_MSG_0_MBZ
> GUC_HXG_REQUEST_MSG_0_DATA0
> -#define HOST2GUC_SELF_CFG_REQUEST_MSG_1_KLV_KEY (0x << 16)
> +#define HOST2GUC_SELF_CFG_REQUEST_MSG_1_KLV_KEY (0xU << 16)
> #define HOST2GUC_SELF_CFG_REQUEST_MSG_1_KLV_LEN (0x << 0)
> #define HOST2GUC_SELF_CFG_REQUEST_MSG_2_VALUE32
> GUC_HXG_REQUEST_MSG_n_DATAn
> #define HOST2GUC_SELF_CFG_REQUEST_MSG_3_VALUE64
> GUC_HXG_REQUEST_MSG_n_DATAn
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> index c9086a600bce..df83c1cc7c7a 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h
> @@ -82,7 +82,7 @@ static_assert(sizeof(struct guc_ct_buffer_desc) == 64);
> #define GUC_CTB_HDR_LEN 1u
> #define GUC_CTB_MSG_MIN_LEN GUC_CTB_HDR_LEN
> #define GUC_CTB_MSG_MAX_LEN 256u
> -#define GUC_CTB_MSG_0_FENCE (0x << 16)
> +#define GUC_CTB_MSG_0_FENCE (0xU << 16)
> #define GUC_CTB_MSG_0_FORMAT (0xf << 12)
> #define GUC_CTB_FORMAT_HXG 0u
> #define GUC_CTB_MSG_0_RESERVED (0xf << 8)
> diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> index 29ac823acd4c..7d5ba4d97d70 100644
> --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_messages_abi.h
> @@ -40,7 +40,7 @@
> */
>
> #define GUC_HXG_MSG_MIN_LEN 1u
> -#define GUC_HXG_MSG_0_ORIGIN (0x1 << 31)
> +#define GUC_HXG_MSG_0_ORIGIN (0x1U << 31)
> #define GUC_HXG_ORIGIN_HOST0u
> #define GUC_HXG_ORIGIN_GUC 1u
> #define GUC_HXG_MSG_0_TYPE (0x7 << 28)
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> index 66027a42cda9..ad570fa002a6 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h
> @@ -28,7 +28,7 @@
> #define GS_MIA_HALT_REQUESTED(0x02 << GS_MIA_SHIFT)
> #define GS_MIA_ISR_ENTRY (0x04 << GS_MIA_SHIFT)
> #define GS_AUTH_STATUS_SHIFT 30
> -#define GS_AUTH_STATUS_MASK (0x03 << GS_AUTH_STATUS_SHIFT)
> +#define GS_AUTH_STATUS_MASK (0x03U <<
> GS_AUTH_STATUS_SHIFT)
> #define GS_AUTH_STATUS_BAD (0x01 << GS_AUTH_STATUS_SHIFT)
> #define GS_AUTH_STATUS_GOOD (0x02 << GS_AUTH_STATUS_SHIFT)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3c87d77d2cf6..f3ba3d0a430b 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7555,19 +7555,19 @@ enum skl_power_gate {
> #define PORT_CLK_SEL_LCPLL_810 (2 << 29)
> #define PORT_CLK_SEL_SPLL (3 << 29)
> #define PORT_CLK_SEL_W
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Add workaround 22014600077 (rev2)
== Series Details ==
Series: drm/i915/dg2: Add workaround 22014600077 (rev2)
URL : https://patchwork.freedesktop.org/series/104097/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11668 -> Patchwork_104097v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/index.html
Participating hosts (40 -> 40)
--
Additional (2): fi-kbl-soraka bat-dg2-8
Missing(2): bat-jsl-2 bat-dg2-9
Known issues
Here are the changes found in Patchwork_104097v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][4] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@gem_contexts:
- fi-bdw-5557u: [PASS][5] -> [INCOMPLETE][6] ([i915#5502] /
[i915#5801])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-bdw-5557u/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][8] -> [INCOMPLETE][9] ([i915#3921])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +7
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-kbl-soraka/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#533])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][13] ([i915#4785]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][17] ([fdo#103375]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][19] ([i915#3576]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v2/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bug
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: Add workaround 22014600077
== Series Details == Series: drm/i915/dg2: Add workaround 22014600077 URL : https://patchwork.freedesktop.org/series/104097/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11666_full -> Patchwork_104097v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104097v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104097v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104097v1_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@wide@vecs0: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-kbl6/igt@gem_exec_schedule@w...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-kbl7/igt@gem_exec_schedule@w...@vecs0.html Known issues Here are the changes found in Patchwork_104097v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [FAIL][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26]) ([i915#5032]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl10/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl8/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl8/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl7/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl7/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/shard-skl7/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Add workaround 22014600077 (rev2)
== Series Details == Series: drm/i915/dg2: Add workaround 22014600077 (rev2) URL : https://patchwork.freedesktop.org/series/104097/ State : warning == Summary == Error: dim checkpatch failed c6ced9357337 drm/i915/dg2: Add workaround 22014600077 -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:34: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #34: FILE: drivers/gpu/drm/i915/gt/intel_workarounds.c:2187: + 0 /* Wa_14012342262 :write-only reg, so skip + verification */, total: 0 errors, 2 warnings, 0 checks, 23 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for Replace shmem memory region and object backend
== Series Details == Series: Replace shmem memory region and object backend URL : https://patchwork.freedesktop.org/series/104105/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11668 -> Patchwork_104105v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104105v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104105v1, 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_104105v1/index.html Participating hosts (40 -> 43) -- Additional (3): fi-kbl-soraka bat-dg2-8 bat-adls-5 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104105v1: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-process: - fi-ilk-650: [PASS][1] -> [FAIL][2] +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-ilk-650/igt@gem_close_r...@basic-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-ilk-650/igt@gem_close_r...@basic-process.html - fi-bsw-kefka: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bsw-kefka/igt@gem_close_r...@basic-process.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-bsw-kefka/igt@gem_close_r...@basic-process.html * igt@gem_close_race@basic-threads: - fi-bwr-2160:[PASS][5] -> [FAIL][6] +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bwr-2160/igt@gem_close_r...@basic-threads.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-bwr-2160/igt@gem_close_r...@basic-threads.html - fi-bsw-nick:[PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bsw-nick/igt@gem_close_r...@basic-threads.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-bsw-nick/igt@gem_close_r...@basic-threads.html - fi-bsw-n3050: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bsw-n3050/igt@gem_close_r...@basic-threads.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-bsw-n3050/igt@gem_close_r...@basic-threads.html * igt@gem_exec_create@basic@smem: - fi-blb-e6850: [PASS][11] -> [FAIL][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-blb-e6850/igt@gem_exec_create@ba...@smem.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-blb-e6850/igt@gem_exec_create@ba...@smem.html * igt@gem_exec_fence@basic-await@rcs0: - fi-blb-e6850: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-blb-e6850/igt@gem_exec_fence@basic-aw...@rcs0.html * igt@gem_exec_fence@basic-await@vcs0: - fi-elk-e7500: [PASS][15] -> [FAIL][16] +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@vcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-elk-e7500/igt@gem_exec_fence@basic-aw...@vcs0.html * igt@gem_exec_fence@nb-await@vcs0: - fi-ilk-650: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-ilk-650/igt@gem_exec_fence@nb-aw...@vcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-ilk-650/igt@gem_exec_fence@nb-aw...@vcs0.html * igt@gem_exec_parallel@engines@basic: - fi-elk-e7500: [PASS][19] -> [INCOMPLETE][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-elk-e7500/igt@gem_exec_parallel@engi...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-elk-e7500/igt@gem_exec_parallel@engi...@basic.html * igt@gem_exec_suspend@basic-s0@smem: - fi-glk-j4005: [PASS][21] -> [FAIL][22] +13 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-glk-j4005/igt@gem_exec_suspend@basic...@smem.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bxt-dsi: [PASS][23] -> [FAIL][24] +6 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104105v1/fi-bxt-dsi/igt@gem_exec_suspend@basic...@smem.html * igt@gem_render_linear_bl
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Replace shmem memory region and object backend
== Series Details == Series: Replace shmem memory region and object backend URL : https://patchwork.freedesktop.org/series/104105/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Replace shmem memory region and object backend
== Series Details ==
Series: Replace shmem memory region and object backend
URL : https://patchwork.freedesktop.org/series/104105/
State : warning
== Summary ==
Error: dim checkpatch failed
a310d6e73af3 drm/i915: Replace shmem memory region and object backend with TTM
-:41: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"obj->base.import_attach"
#41: FILE: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:101:
+ GEM_BUG_ON(obj->base.import_attach != NULL);
-:67: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"obj->base.import_attach"
#67: FILE: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:231:
+ GEM_BUG_ON(obj->base.import_attach != NULL);
-:98: CHECK:BRACES: Unbalanced braces around else statement
#98: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:90:
+ else {
-:201: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"obj->base.import_attach"
#201: FILE: drivers/gpu/drm/i915/gem/i915_gem_phys.c:33:
+ GEM_BUG_ON(obj->base.import_attach != NULL);
-:217: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!filp"
#217: FILE: drivers/gpu/drm/i915/gem/i915_gem_phys.c:115:
+ if (GEM_WARN_ON(filp == NULL))
-:650: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!file"
#650: FILE: drivers/gpu/drm/i915/gem/i915_gem_shmem.c:316:
+ GEM_WARN_ON(file == NULL);
-:781: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'caching
!= ttm_write_combined'
#781: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:333:
+ if (i915_gem_object_is_shrinkable(obj) && (caching !=
ttm_write_combined)) {
-:832: CHECK:BRACES: braces {} should be used on all arms of this statement
#832: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:912:
+ if (likely(i915_gem_object_has_struct_page(obj))) {
[...]
+ } else
[...]
-:842: CHECK:BRACES: Unbalanced braces around else statement
#842: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:922:
+ } else
total: 0 errors, 0 warnings, 9 checks, 1116 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12
== Series Details ==
Series: drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12
URL : https://patchwork.freedesktop.org/series/104104/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11668 -> Patchwork_104104v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/index.html
Participating hosts (40 -> 41)
--
Additional (2): fi-kbl-soraka bat-dg2-8
Missing(1): bat-rpls-2
Known issues
Here are the changes found in Patchwork_104104v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][4] ([i915#1886])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +7
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-kbl-soraka/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][10] ([i915#4785]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s3-without-i915:
- {bat-dg2-9}:[DMESG-WARN][12] ([i915#5763]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/bat-dg2-9/igt@i915_susp...@basic-s3-without-i915.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/bat-dg2-9/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_busy@basic@modeset:
- {bat-adlp-6}: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/bat-adlp-6/igt@kms_busy@ba...@modeset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/bat-adlp-6/igt@kms_busy@ba...@modeset.html
Warnings
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: [FAIL][16] ([fdo#103375]) -> [INCOMPLETE][17]
([i915#5982])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104104v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/iss
Re: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory region and object backend with TTM
>-Original Message-
>From: Intel-gfx On Behalf Of
>Adrian Larumbe
>Sent: Tuesday, May 17, 2022 4:45 PM
>To: dan...@ffwll.ch; intel-gfx@lists.freedesktop.org
>Cc: adrian.laru...@collabora.com
>Subject: [Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory
>region and object backend with TTM
>
>Remove shmem region and object backend code as they are now
>unnecessary.
>In the case of objects placed in SMEM and backed by kernel shmem files, the
>file pointer has to be retrieved from the ttm_tt structure, so change this
>as well. This means accessing an shmem-backed BO's file pointer requires
>getting its pages beforehand, unlike in the old shmem backend.
>
>Expand TTM BO creation by handling devices with no LLC so that their
>caching and coherency properties are set accordingly.
>
>Adapt phys backend to put pages of original shmem object in a 'TTM way',
>also making sure its pages are put when a TTM shmem object has no struct
>page.
>
>Signed-off-by: Adrian Larumbe
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +-
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +--
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 -
> drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +-
> drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
> drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
> 10 files changed, 398 insertions(+), 422 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..de04ce4210b3 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -12,6 +12,7 @@
> #include
>
> #include "gem/i915_gem_dmabuf.h"
>+#include "gem/i915_gem_ttm.h"
> #include "i915_drv.h"
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
>@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf
>*dma_buf, struct vm_area_struct *
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
>+ struct file *filp = i915_gem_ttm_get_filep(obj);
> int ret;
>
>+ GEM_BUG_ON(obj->base.import_attach != NULL);
>+
> if (obj->base.size < vma->vm_end - vma->vm_start)
> return -EINVAL;
>
> if (HAS_LMEM(i915))
> return drm_gem_prime_mmap(&obj->base, vma);
Since all of the devices that will have device memory will be true for HAS_LMEM,
won't your code path always go to drm_gem_prime_mmap()?
>- if (!obj->base.filp)
>+ if (!filp)
> return -ENODEV;
>
>- ret = call_mmap(obj->base.filp, vma);
>+ ret = call_mmap(filp, vma);
> if (ret)
> return ret;
>
>- vma_set_file(vma, obj->base.filp);
>+ vma_set_file(vma, filp);
>
> return 0;
> }
>@@ -224,6 +228,8 @@ struct dma_buf *i915_gem_prime_export(struct
>drm_gem_object *gem_obj, int flags)
> exp_info.priv = gem_obj;
> exp_info.resv = obj->base.resv;
>
>+ GEM_BUG_ON(obj->base.import_attach != NULL);
>+
> if (obj->ops->dmabuf_export) {
> int ret = obj->ops->dmabuf_export(obj);
> if (ret)
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>index 0c5c43852e24..d963cf35fdc9 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
>@@ -64,7 +64,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
>*data,
> struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_mmap *args = data;
> struct drm_i915_gem_object *obj;
>+ struct file *filp;
> unsigned long addr;
>+ int ret;
>
> /*
>* mmap ioctl is disallowed for all discrete platforms,
>@@ -83,12 +85,20 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void
>*data,
> if (!obj)
> return -ENOENT;
>
>- /* prime objects have no backing filp to GEM mmap
>- * pages from.
>- */
>- if (!obj->base.filp) {
>- addr = -ENXIO;
>- goto err;
>+ if (obj->base.import_attach)
>+ filp = obj->base.filp;
Why is this now ok? This is the imported object. And it used to give an error.
If you are importing from a different device, (i.e. an amd device is exporting
the object, and you are i915 here), can you even do this?
My understanding was that mmaping was only for the exported object.
Has this changed?
Thanks,
Mike
>+ else {
>+ ret = i915_gem_object_pin_pages_unlocked(obj);
>+ if (ret) {
>+ addr = ret;
>+ goto err_pin;
>+ }
>+
>+ filp = i915_gem_ttm_get_filep(obj);
>+
[Intel-gfx] [PATCH v2] drm/i915/dg2: Add workaround 22014600077
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 98ede9c93f00..2063c8758934 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1068,6 +1068,7 @@
#define GEN9_ENABLE_GPGPU_PREEMPTION REG_BIT(2)
#define GEN10_CACHE_MODE_SS_MMIO(0xe420)
+#define ENABLE_EU_COUNT_FOR_TDL_FLUSHREG_BIT(10)
#define ENABLE_PREFETCH_INTO_IC REG_BIT(3)
#define FLOAT_BLEND_OPTIMIZATION_ENABLE REG_BIT(4)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 756807c4b405..73b59ea6fd3b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2178,6 +2178,16 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
}
+ if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_B0, STEP_FOREVER) ||
+ IS_DG2_G10(i915)) {
+ /* Wa_22014600077:dg2 */
+ wa_add(wal, GEN10_CACHE_MODE_SS, 0,
+ _MASKED_BIT_ENABLE(ENABLE_EU_COUNT_FOR_TDL_FLUSH),
+ 0 /* Wa_14012342262 :write-only reg, so skip
+ verification */,
+ true);
+ }
+
if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
IS_TGL_UY_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) {
/*
--
2.20.1
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12
== Series Details == Series: drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12 URL : https://patchwork.freedesktop.org/series/104104/ State : warning == Summary == Error: dim checkpatch failed f3e4cba7117c drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12 -:7: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one total: 0 errors, 1 warnings, 0 checks, 13 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3)
== Series Details ==
Series: drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3)
URL : https://patchwork.freedesktop.org/series/93447/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11668 -> Patchwork_93447v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/index.html
Participating hosts (40 -> 40)
--
Additional (2): fi-kbl-soraka bat-dg2-8
Missing(2): fi-rkl-11600 bat-dg2-9
Known issues
Here are the changes found in Patchwork_93447v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@basic-busy@bcs0:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][4] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@gem_migrate:
- fi-bdw-5557u: [PASS][5] -> [INCOMPLETE][6] ([i915#5716])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-bdw-5557u/igt@i915_selftest@live@gem_migrate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-bdw-5557u/igt@i915_selftest@live@gem_migrate.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-edid-read:
- fi-kbl-soraka: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +7
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-kbl-soraka/igt@kms_chamel...@dp-edid-read.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-kbl-soraka/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [DMESG-FAIL][11] ([i915#4494] / [i915#4957]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-4770:[INCOMPLETE][13] ([i915#4785]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_flip@basic-flip-vs-modeset@a-edp1:
- {bat-adlp-6}: [DMESG-WARN][17] ([i915#3576]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11668/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_93447v3/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
[i915#2190]: https://gitlab.f
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM
== Series Details == Series: series starting with [1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM URL : https://patchwork.freedesktop.org/series/104101/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/104101/revisions/1/mbox/ not applied Applying: vfio: remove VFIO_GROUP_NOTIFY_SET_KVM error: sha1 information is lacking or useless (drivers/vfio/vfio.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 vfio: remove VFIO_GROUP_NOTIFY_SET_KVM When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3)
== Series Details == Series: drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3) URL : https://patchwork.freedesktop.org/series/93447/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3)
== Series Details == Series: drm/doc/rfc: i915 VM_BIND feature design + uapi (rev3) URL : https://patchwork.freedesktop.org/series/93447/ State : warning == Summary == Error: dim checkpatch failed b4f01b5605b4 drm/doc/rfc: VM_BIND feature design document -:27: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #27: new file mode 100644 -:32: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #32: FILE: Documentation/gpu/rfc/i915_vm_bind.rst:1: +== total: 0 errors, 2 warnings, 0 checks, 319 lines checked 50b7adcbd762 drm/i915: Update i915 uapi documentation e72771b5018c drm/doc/rfc: VM_BIND uapi definition Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:15: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #15: new file mode 100644 -:83: WARNING:LONG_LINE: line length of 126 exceeds 100 columns #83: FILE: Documentation/gpu/rfc/i915_vm_bind.h:64: +#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind) -:84: WARNING:LONG_LINE: line length of 128 exceeds 100 columns #84: FILE: Documentation/gpu/rfc/i915_vm_bind.h:65: +#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind) -:85: WARNING:LONG_LINE: line length of 142 exceeds 100 columns #85: FILE: Documentation/gpu/rfc/i915_vm_bind.h:66: +#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence) -:184: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #184: FILE: Documentation/gpu/rfc/i915_vm_bind.h:165: +#define I915_VM_BIND_FENCE_WAIT(1<<0) ^ -:185: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #185: FILE: Documentation/gpu/rfc/i915_vm_bind.h:166: +#define I915_VM_BIND_FENCE_SIGNAL (1<<1) ^ -:252: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #252: FILE: Documentation/gpu/rfc/i915_vm_bind.h:233: +#define I915_VM_BIND_USER_FENCE_WAIT(1<<0) ^ -:253: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #253: FILE: Documentation/gpu/rfc/i915_vm_bind.h:234: +#define I915_VM_BIND_USER_FENCE_SIGNAL (1<<1) ^ total: 0 errors, 4 warnings, 4 checks, 399 lines checked
[Intel-gfx] [RFC PATCH v2 0/1] Replace shmem memory region and object backend
This patch is a second attempt at eliminating the old shmem memory region and GEM object backend, in favour of a TTM-based one that is able to manage objects placed on both system and local memory. Questions addressed since previous revision: * Creating an anonymous vfs mount for shmem files in TTM * Fixing LLC caching properties and bit 17 swizzling before setting a TTM bo's pages when calling get_pages * Added handling of phys backend from TTM functions * Added pread callback to TTM gem object backend * In shmem_create_from_object, ensuring an shmem object we just got a filp for has its pages marked dirty and accessed. Otherwise, the engine won't be able to read the initial state and a GPU hung will ensue However, one of the issues persists: Many GPU hungs in machines of GEN <= 5. My assumption is this has something to do with a caching pitfall, but everywhere across the TTM backend code I've tried to handle object creation and getting its pages with the same set of caching and coherency properties as in the old shmem backend. Adrian Larumbe (1): drm/i915: Replace shmem memory region and object backend with TTM drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +-- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 - drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +- drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++- drivers/gpu/drm/i915/intel_memory_region.c | 7 +- 10 files changed, 398 insertions(+), 422 deletions(-) -- 2.35.1
[Intel-gfx] [RFC PATCH v2 1/1] drm/i915: Replace shmem memory region and object backend with TTM
Remove shmem region and object backend code as they are now unnecessary.
In the case of objects placed in SMEM and backed by kernel shmem files, the
file pointer has to be retrieved from the ttm_tt structure, so change this
as well. This means accessing an shmem-backed BO's file pointer requires
getting its pages beforehand, unlike in the old shmem backend.
Expand TTM BO creation by handling devices with no LLC so that their
caching and coherency properties are set accordingly.
Adapt phys backend to put pages of original shmem object in a 'TTM way',
also making sure its pages are put when a TTM shmem object has no struct
page.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 32 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 390 +--
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 267 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 +-
drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
10 files changed, 398 insertions(+), 422 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..de04ce4210b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,7 @@
#include
#include "gem/i915_gem_dmabuf.h"
+#include "gem/i915_gem_ttm.h"
#include "i915_drv.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct file *filp = i915_gem_ttm_get_filep(obj);
int ret;
+ GEM_BUG_ON(obj->base.import_attach != NULL);
+
if (obj->base.size < vma->vm_end - vma->vm_start)
return -EINVAL;
if (HAS_LMEM(i915))
return drm_gem_prime_mmap(&obj->base, vma);
- if (!obj->base.filp)
+ if (!filp)
return -ENODEV;
- ret = call_mmap(obj->base.filp, vma);
+ ret = call_mmap(filp, vma);
if (ret)
return ret;
- vma_set_file(vma, obj->base.filp);
+ vma_set_file(vma, filp);
return 0;
}
@@ -224,6 +228,8 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object
*gem_obj, int flags)
exp_info.priv = gem_obj;
exp_info.resv = obj->base.resv;
+ GEM_BUG_ON(obj->base.import_attach != NULL);
+
if (obj->ops->dmabuf_export) {
int ret = obj->ops->dmabuf_export(obj);
if (ret)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 0c5c43852e24..d963cf35fdc9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -64,7 +64,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_mmap *args = data;
struct drm_i915_gem_object *obj;
+ struct file *filp;
unsigned long addr;
+ int ret;
/*
* mmap ioctl is disallowed for all discrete platforms,
@@ -83,12 +85,20 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
if (!obj)
return -ENOENT;
- /* prime objects have no backing filp to GEM mmap
-* pages from.
-*/
- if (!obj->base.filp) {
- addr = -ENXIO;
- goto err;
+ if (obj->base.import_attach)
+ filp = obj->base.filp;
+ else {
+ ret = i915_gem_object_pin_pages_unlocked(obj);
+ if (ret) {
+ addr = ret;
+ goto err_pin;
+ }
+
+ filp = i915_gem_ttm_get_filep(obj);
+ if (!filp) {
+ addr = -ENXIO;
+ goto err;
+ }
}
if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
@@ -96,7 +106,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
goto err;
}
- addr = vm_mmap(obj->base.filp, 0, args->size,
+ addr = vm_mmap(filp, 0, args->size,
PROT_READ | PROT_WRITE, MAP_SHARED,
args->offset);
if (IS_ERR_VALUE(addr))
@@ -111,7 +121,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
goto err;
}
vma = find_vma(mm, addr);
- if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
+ if (vma &&
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev4)
Since it's bat failure, I have filed a new issue
https://gitlab.freedesktop.org/drm/intel/-/issues/6025
igt@prime_vgem@basic-fence-read - incomplete - No warnings/errors
Thanks,
Lakshmi.
-Original Message-
From: Roper, Matthew D
Sent: Tuesday, May 17, 2022 12:20 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev4)
On Tue, May 17, 2022 at 07:08:08PM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: SSEU handling updates (rev4)
> URL : https://patchwork.freedesktop.org/series/103244/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11666 -> Patchwork_103244v4
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_103244v4 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_103244v4, 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_103244v4/index.html
>
> Participating hosts (41 -> 41)
> --
>
> Additional (1): fi-skl-guc
> Missing(1): bat-rpls-2
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_103244v4:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@prime_vgem@basic-fence-read:
> - fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-kbl-sor
> aka/igt@prime_v...@basic-fence-read.html
The results link shows 'SUCCESS' so I'm not sure why this was marked as
INCOMPLETE here?
Doesn't appear to be related to this series.
Matt
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_103244v4 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@basic:
> - fi-skl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
> similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc
> /igt@gem_lmem_swapp...@basic.html
>
> * igt@i915_selftest@live@execlists:
> - fi-bsw-kefka: [PASS][4] -> [INCOMPLETE][5] ([i915#2940] /
> [i915#5801])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kef
> ka/igt@i915_selftest@l...@execlists.html
>
> * igt@i915_selftest@live@gem:
> - fi-pnv-d510:NOTRUN -> [DMESG-FAIL][6] ([i915#4528])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d51
> 0/igt@i915_selftest@l...@gem.html
>
> * igt@i915_selftest@live@hangcheck:
> - fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-snb-260
> 0/igt@i915_selftest@l...@hangcheck.html
>
> * igt@kms_chamelium@dp-crc-fast:
> - fi-skl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
> +8 similar issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc
> /igt@kms_chamel...@dp-crc-fast.html
>
> * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
> - fi-skl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc
> /igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
>
> * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
> - fi-skl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc
> /igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
>
> * igt@runner@aborted:
> - fi-bsw-kefka: NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#3428] /
> [i915#4312])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kef
> ka/igt@run...@aborted.html
>
>
> Possible fixes
>
> * igt@i915_selftest@live@objects:
> - {bat-dg2-9}:[DMESG-WARN][13] ([i915#5763]) -> [PASS][14] +1
> similar issue
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-dg2-9/igt@i915_selftest@l...@objects.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/bat-dg2-9/
> igt@i915_selftest@l...@objects.html
>
> * igt@i915_selftest@live@requ
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12
On Tue, May 17, 2022 at 01:13:38PM -0700, Swathi Dhanavanthri wrote:
> Signed-off-by: Swathi Dhanavanthri
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ee0047fdc95d..d0e0d6a324ee 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7513,10 +7513,9 @@ static void xehpsdv_init_clock_gating(struct
> drm_i915_private *dev_priv)
>
> static void dg2_init_clock_gating(struct drm_i915_private *i915)
> {
> - /* Wa_22010954014:dg2_g10 */
> - if (IS_DG2_G10(i915))
> - intel_uncore_rmw(&i915->uncore, XEHP_CLOCK_GATE_DIS, 0,
> - SGSI_SIDECLK_DIS);
> + /* Wa_22010954014:dg2 */
> + intel_uncore_rmw(&i915->uncore, XEHP_CLOCK_GATE_DIS, 0,
> + SGSI_SIDECLK_DIS);
>
> /*
>* Wa_14010733611:dg2_g10
> --
> 2.20.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH] drm/i915/dg2: Add workaround 22014600077
On Tue, May 17, 2022 at 11:02:01AM -0700, Swathi Dhanavanthri wrote:
> Bspec: 45810,54077,68173
>
> Signed-off-by: Swathi Dhanavanthri
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 98ede9c93f00..2063c8758934 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1068,6 +1068,7 @@
> #define GEN9_ENABLE_GPGPU_PREEMPTION REG_BIT(2)
>
> #define GEN10_CACHE_MODE_SS _MMIO(0xe420)
> +#define ENABLE_EU_COUNT_FOR_TDL_FLUSH REG_BIT(10)
I think this line has some spaces before REG_BIT(). We should only be
using tabs between the variable name and the 'REG_BIT.'
> #define ENABLE_PREFETCH_INTO_ICREG_BIT(3)
> #define FLOAT_BLEND_OPTIMIZATION_ENABLEREG_BIT(4)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 756807c4b405..c647a9e48389 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -2178,6 +2178,15 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
> }
>
> + if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_B0, STEP_FOREVER) ||
> + IS_DG2_G10(i915)) {
> + /* Wa_22014600077:dg2 */
> + wa_add(wal, GEN10_CACHE_MODE_SS, 0,
> +_MASKED_BIT_ENABLE(ENABLE_EU_COUNT_FOR_TDL_FLUSH),
> +0 /* write-only, so skip validation */,
The fact that this register is WO is itself a different workaround, so
you may want to reference that in the comment. E.g.,
0 /* Wa_14012342262: write-only reg, skip verification */
Matt
> +true);
> + }
> +
> if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
> IS_TGL_UY_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) {
> /*
> --
> 2.20.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: SSEU handling updates (rev4)
== Series Details ==
Series: i915: SSEU handling updates (rev4)
URL : https://patchwork.freedesktop.org/series/103244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11666 -> Patchwork_103244v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/index.html
Participating hosts (41 -> 41)
--
Additional (1): fi-skl-guc
Missing(1): bat-rpls-2
Known issues
Here are the changes found in Patchwork_103244v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-skl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][2] -> [INCOMPLETE][3] ([i915#2940] /
[i915#5801])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][4] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#3921])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +11 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#533])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@prime_vgem@basic-fence-read:
- fi-kbl-soraka: [PASS][10] -> [INCOMPLETE][11] ([i915#6025])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#3428] /
[i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kefka/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@objects:
- {bat-dg2-9}:[DMESG-WARN][13] ([i915#5763]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-dg2-9/igt@i915_selftest@l...@objects.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/bat-dg2-9/igt@i915_selftest@l...@objects.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {fi-jsl-1}: [INCOMPLETE][17] -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-jsl-1/igt@i915_selftest@l...@reset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-jsl-1/igt@i915_selftest@l...@reset.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][19] ([i915#3576]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-adlp-6/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/bat-adlp-6/igt@kms_busy@ba...@flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?i
[Intel-gfx] [PATCH] drm/i915/dg2: Extend Wa_22010954014 to DG2-G11 and DG2-G12
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/intel_pm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee0047fdc95d..d0e0d6a324ee 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7513,10 +7513,9 @@ static void xehpsdv_init_clock_gating(struct
drm_i915_private *dev_priv)
static void dg2_init_clock_gating(struct drm_i915_private *i915)
{
- /* Wa_22010954014:dg2_g10 */
- if (IS_DG2_G10(i915))
- intel_uncore_rmw(&i915->uncore, XEHP_CLOCK_GATE_DIS, 0,
-SGSI_SIDECLK_DIS);
+ /* Wa_22010954014:dg2 */
+ intel_uncore_rmw(&i915->uncore, XEHP_CLOCK_GATE_DIS, 0,
+SGSI_SIDECLK_DIS);
/*
* Wa_14010733611:dg2_g10
--
2.20.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Add workaround 22014600077
== Series Details ==
Series: drm/i915/dg2: Add workaround 22014600077
URL : https://patchwork.freedesktop.org/series/104097/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11666 -> Patchwork_104097v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/index.html
Participating hosts (41 -> 41)
--
Additional (2): fi-skl-guc bat-adlm-1
Missing(2): bat-rpls-2 fi-rkl-11600
Known issues
Here are the changes found in Patchwork_104097v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-skl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gem:
- fi-blb-e6850: NOTRUN -> [DMESG-FAIL][2] ([i915#4528])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-blb-e6850/igt@i915_selftest@l...@gem.html
* igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][4] ([fdo#109271]) +11 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#533])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][6] ([i915#5122]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][8] ([i915#4494] / [i915#4957]) ->
[PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][10] ([i915#4528]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {fi-jsl-1}: [INCOMPLETE][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-jsl-1/igt@i915_selftest@l...@reset.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/fi-jsl-1/igt@i915_selftest@l...@reset.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][14] ([i915#3576]) -> [PASS][15] +2
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104097v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3547]: https://gitlab.freedesktop.org/drm/intel/issues/3547
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev4)
On Tue, May 17, 2022 at 07:08:08PM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: SSEU handling updates (rev4)
> URL : https://patchwork.freedesktop.org/series/103244/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11666 -> Patchwork_103244v4
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_103244v4 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_103244v4, 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_103244v4/index.html
>
> Participating hosts (41 -> 41)
> --
>
> Additional (1): fi-skl-guc
> Missing(1): bat-rpls-2
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_103244v4:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@prime_vgem@basic-fence-read:
> - fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
The results link shows 'SUCCESS' so I'm not sure why this was marked as
INCOMPLETE here?
Doesn't appear to be related to this series.
Matt
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_103244v4 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@basic:
> - fi-skl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
> similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
>
> * igt@i915_selftest@live@execlists:
> - fi-bsw-kefka: [PASS][4] -> [INCOMPLETE][5] ([i915#2940] /
> [i915#5801])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
>
> * igt@i915_selftest@live@gem:
> - fi-pnv-d510:NOTRUN -> [DMESG-FAIL][6] ([i915#4528])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d510/igt@i915_selftest@l...@gem.html
>
> * igt@i915_selftest@live@hangcheck:
> - fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
>
> * igt@kms_chamelium@dp-crc-fast:
> - fi-skl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
> +8 similar issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
>
> * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
> - fi-skl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
>
> * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
> - fi-skl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
>
> * igt@runner@aborted:
> - fi-bsw-kefka: NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#3428] /
> [i915#4312])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kefka/igt@run...@aborted.html
>
>
> Possible fixes
>
> * igt@i915_selftest@live@objects:
> - {bat-dg2-9}:[DMESG-WARN][13] ([i915#5763]) -> [PASS][14] +1
> similar issue
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-dg2-9/igt@i915_selftest@l...@objects.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/bat-dg2-9/igt@i915_selftest@l...@objects.html
>
> * igt@i915_selftest@live@requests:
> - fi-pnv-d510:[DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-pnv-d510/igt@i915_selftest@l...@requests.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d510/igt@i915_selftest@l...@requests.html
>
> * igt@i915_selftest@live@reset:
> - {fi-jsl-1}: [INCOMPLETE][17] -> [PASS][18]
>[17]:
> https://intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev4)
== Series Details ==
Series: i915: SSEU handling updates (rev4)
URL : https://patchwork.freedesktop.org/series/103244/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11666 -> Patchwork_103244v4
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103244v4 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103244v4, 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_103244v4/index.html
Participating hosts (41 -> 41)
--
Additional (1): fi-skl-guc
Missing(1): bat-rpls-2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103244v4:
### IGT changes ###
Possible regressions
* igt@prime_vgem@basic-fence-read:
- fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-kbl-soraka/igt@prime_v...@basic-fence-read.html
Known issues
Here are the changes found in Patchwork_103244v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-skl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][4] -> [INCOMPLETE][5] ([i915#2940] /
[i915#5801])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][6] ([i915#4528])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][10] ([fdo#109271]) +11 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][12] ([fdo#109271] / [i915#3428] /
[i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-bsw-kefka/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@objects:
- {bat-dg2-9}:[DMESG-WARN][13] ([i915#5763]) -> [PASS][14] +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-dg2-9/igt@i915_selftest@l...@objects.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/bat-dg2-9/igt@i915_selftest@l...@objects.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][15] ([i915#4528]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- {fi-jsl-1}: [INCOMPLETE][17] -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-jsl-1/igt@i915_selftest@l...@reset.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103244v4/fi-jsl-1/igt@i915_selftest@l...@reset.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][19] ([i915#3576]) -> [PASS][20] +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-adlp-6/igt@kms_busy@ba...@flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
== Series Details == Series: drm/kms: Stop registering multiple /sys/class/backlight devs for a single display URL : https://patchwork.freedesktop.org/series/104084/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/104084/revisions/1/mbox/ not applied Applying: ACPI: video: Add a native function parameter to acpi_video_get_backlight_type() Applying: drm/i915: Don't register backlight when another backlight should be used Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/display/intel_backlight.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/display/intel_backlight.c Applying: drm/amdgpu: Don't register backlight when another backlight should be used Using index info to reconstruct a base tree... M drivers/gpu/drm/Kconfig M drivers/gpu/drm/amd/amdgpu/atombios_encoders.c M drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c Auto-merging drivers/gpu/drm/amd/amdgpu/atombios_encoders.c Auto-merging drivers/gpu/drm/Kconfig CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 drm/amdgpu: Don't register backlight when another backlight should be used When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: SSEU handling updates (rev4)
== Series Details == Series: i915: SSEU handling updates (rev4) URL : https://patchwork.freedesktop.org/series/103244/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates (rev4)
== Series Details ==
Series: i915: SSEU handling updates (rev4)
URL : https://patchwork.freedesktop.org/series/103244/
State : warning
== Summary ==
Error: dim checkpatch failed
887126b08a62 drm/i915/xehp: Use separate sseu init function
913cf54798d2 drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
2ee6de43eff7 drm/i915/sseu: Simplify gen11+ SSEU handling
616556780612 drm/i915/sseu: Don't try to store EU mask internally in UAPI format
982793037c15 drm/i915/sseu: Disassociate internal subslice mask representation
from uapi
-:481: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#481: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:846:
+void intel_sseu_print_ss_info(const char* type,
-:565: WARNING:NEW_TYPEDEFS: do not add new typedefs
#565: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:59:
+typedef union {
-:661: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#661: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:174:
+void intel_sseu_print_ss_info(const char* type,
total: 2 errors, 1 warnings, 0 checks, 779 lines checked
a1f8cbcba917 drm/i915/pvc: Add SSEU changes
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Individualize fences before adding to dma_resv obj
== Series Details ==
Series: drm/i915: Individualize fences before adding to dma_resv obj
URL : https://patchwork.freedesktop.org/series/104074/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11666 -> Patchwork_104074v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/index.html
Participating hosts (41 -> 41)
--
Additional (1): fi-skl-guc
Missing(1): bat-dg2-9
Known issues
Here are the changes found in Patchwork_104074v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-skl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/fi-skl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][2] -> [INCOMPLETE][3] ([i915#4418])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gtt:
- fi-bdw-5557u: [PASS][4] -> [DMESG-FAIL][5] ([i915#3674])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
* igt@kms_chamelium@dp-crc-fast:
- fi-skl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/fi-skl-guc/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-skl-guc: NOTRUN -> [SKIP][7] ([fdo#109271]) +11 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/fi-skl-guc/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#533])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/fi-skl-guc/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@i915_selftest@live@reset:
- {fi-jsl-1}: [INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/fi-jsl-1/igt@i915_selftest@l...@reset.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/fi-jsl-1/igt@i915_selftest@l...@reset.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][11] ([i915#3576]) -> [PASS][12] +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11666/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104074v1/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]: https://gitlab.freedesktop.org/drm/intel/issues/1155
[i915#1759]: https://gitlab.freedesktop.org/drm/intel/issues/1759
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3547]: https://gitlab.freedesktop.org/drm/intel/issues/3547
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#3674]: https://gitlab.freedesktop.org/drm/intel/issues/3674
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#4215]: https://gitlab.freedesktop.org/drm/intel/issues/4215
[i915#4391]: https://gitlab.freedesktop.org/drm/intel/issues/4391
[i915#4418]: https://gitlab.freedesktop.org/drm/intel/issu
[Intel-gfx] [RFC v3 2/3] drm/i915: Update i915 uapi documentation
Add some missing i915 upai documentation which the new
i915 VM_BIND feature documentation will be refer to.
Signed-off-by: Niranjana Vishwanathapura
---
include/uapi/drm/i915_drm.h | 153 +++-
1 file changed, 116 insertions(+), 37 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a2def7b27009..8c834a31b56f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -751,9 +751,16 @@ typedef struct drm_i915_irq_wait {
/* Must be kept compact -- no holes and well documented */
+/**
+ * typedef drm_i915_getparam_t - Driver parameter query structure.
+ */
typedef struct drm_i915_getparam {
+ /** @param: Driver parameter to query. */
__s32 param;
- /*
+
+ /**
+* @value: Address of memory where queried value should be put.
+*
* WARNING: Using pointers instead of fixed-size u64 means we need to
write
* compat32 code. Don't repeat this mistake.
*/
@@ -1239,76 +1246,114 @@ struct drm_i915_gem_exec_object2 {
__u64 rsvd2;
};
+/**
+ * struct drm_i915_gem_exec_fence - An input or output fence for the execbuff
+ * ioctl.
+ *
+ * The request will wait for input fence to signal before submission.
+ *
+ * The returned output fence will be signaled after the completion of the
+ * request.
+ */
struct drm_i915_gem_exec_fence {
- /**
-* User's handle for a drm_syncobj to wait on or signal.
-*/
+ /** @handle: User's handle for a drm_syncobj to wait on or signal. */
__u32 handle;
+ /**
+* @flags: Supported flags are,
+*
+* I915_EXEC_FENCE_WAIT:
+* Wait for the input fence before request submission.
+*
+* I915_EXEC_FENCE_SIGNAL:
+* Return request completion fence as output
+*/
+ __u32 flags;
#define I915_EXEC_FENCE_WAIT(1<<0)
#define I915_EXEC_FENCE_SIGNAL (1<<1)
#define __I915_EXEC_FENCE_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SIGNAL << 1))
- __u32 flags;
};
-/*
- * See drm_i915_gem_execbuffer_ext_timeline_fences.
- */
-#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
-
-/*
+/**
+ * struct drm_i915_gem_execbuffer_ext_timeline_fences - Timeline fences
+ * for execbuff.
+ *
* This structure describes an array of drm_syncobj and associated points for
* timeline variants of drm_syncobj. It is invalid to append this structure to
* the execbuf if I915_EXEC_FENCE_ARRAY is set.
*/
struct drm_i915_gem_execbuffer_ext_timeline_fences {
+#define DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES 0
+ /** @base: Extension link. See struct i915_user_extension. */
struct i915_user_extension base;
/**
-* Number of element in the handles_ptr & value_ptr arrays.
+* @fence_count: Number of element in the @handles_ptr & @value_ptr
+* arrays.
*/
__u64 fence_count;
/**
-* Pointer to an array of struct drm_i915_gem_exec_fence of length
-* fence_count.
+* @handles_ptr: Pointer to an array of struct drm_i915_gem_exec_fence
+* of length @fence_count.
*/
__u64 handles_ptr;
/**
-* Pointer to an array of u64 values of length fence_count. Values
-* must be 0 for a binary drm_syncobj. A Value of 0 for a timeline
-* drm_syncobj is invalid as it turns a drm_syncobj into a binary one.
+* @values_ptr: Pointer to an array of u64 values of length
+* @fence_count.
+* Values must be 0 for a binary drm_syncobj. A Value of 0 for a
+* timeline drm_syncobj is invalid as it turns a drm_syncobj into a
+* binary one.
*/
__u64 values_ptr;
};
+/**
+ * struct drm_i915_gem_execbuffer2 - Structure for execbuff submission
+ */
struct drm_i915_gem_execbuffer2 {
- /**
-* List of gem_exec_object2 structs
-*/
+ /** @buffers_ptr: Pointer to a list of gem_exec_object2 structs */
__u64 buffers_ptr;
+
+ /** @buffer_count: Number of elements in @buffers_ptr array */
__u32 buffer_count;
- /** Offset in the batchbuffer to start execution from. */
+ /**
+* @batch_start_offset: Offset in the batchbuffer to start execution
+* from.
+*/
__u32 batch_start_offset;
- /** Bytes used in batchbuffer from batch_start_offset */
+
+ /** @batch_len: Bytes used in batchbuffer from batch_start_offset */
__u32 batch_len;
+
+ /** @DR1: deprecated */
__u32 DR1;
+
+ /** @DR4: deprecated */
__u32 DR4;
+
+ /** @num_cliprects: See @cliprects_ptr */
__u32 num_cliprects;
+
/**
-* This is a struct drm_clip_rect *cliprects if I915_EXEC_FENCE_ARRAY
-* & I915_EXEC_USE_EXTENSIONS are not set.
+* @cliprects_ptr: Kernel clipping was a DRI1 misfeature.
+*
+* It is invalid to use this
[Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
VM_BIND and related uapi definitions
v2: Ensure proper kernel-doc formatting with cross references.
Also add new uapi and documentation as per review comments
from Daniel.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
1 file changed, 399 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..589c0a009107
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,399 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * A VM in VM_BIND mode will not support the older execbuff mode of binding.
+ * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
+ * &drm_i915_gem_execbuffer2.buffer_count must be 0).
+ * Also, &drm_i915_gem_execbuffer2.batch_start_offset and
+ * &drm_i915_gem_execbuffer2.batch_len must be 0.
+ * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
+ * to pass in the batch buffer addresses.
+ *
+ * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
+ * I915_EXEC_BATCH_FIRST of &drm_i915_gem_execbuffer2.flags must be 0
+ * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always be
+ * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
+ * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
+ * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
+ */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_OUT (See &drm_i915_gem_execbuffer2.flags and
+ * I915_EXEC_FENCE_SIGNAL (See &drm_i915_gem_exec_fence.flags) are expected
+ * to be not used.
+ *
+ * DRM_I915_GEM_WAIT ioctl call is also not supported for objects mapped
+ * to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind)
+#define DRM_IOCTL_I915_GEM_WAIT_USER_FENCE DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_WAIT_USER_FENCE, struct drm_i915_gem_wait_user_fence)
+
+/**
+ * struct drm_i915_gem_vm_bind - VA to object mapping to bind.
+ *
+ * This structure is passed to VM_BIND ioctl and specifies the mapping of GPU
+ * virtual address (VA) range to the section of an object that should be bound
+ * in the device page table of the specified address space (VM).
+ * The VA range specified must be unique (ie., not currently bound) and can
+ * be mapped to whole object or a section of the object (partial binding).
+ * Multiple VA mappings can be created to the same section of the object
+ * (aliasing).
+ */
+struct drm_i915_gem_vm_bind {
+ /** @vm_id: VM (address space) id to bind */
+ __u32 vm_id;
+
+ /** @handle: Object handle */
+ __u32 handle;
+
+ /** @start: Virtual Address start to bind */
+ __u64 start;
+
+ /** @offset: Offset in object to bind */
+ __u64 offset;
+
+ /** @length: Length of mapping to bind */
+ __u64 length;
+
+ /**
+* @flags: Supported flags are,
+*
+* I915_GEM_VM_BIND_READONLY:
+* Mapping is read-only.
+*
+* I915_GEM_VM_BIND_CAPTURE:
+* Capture this mapping in the dump upon GPU error.
+*/
+ __u64 flags;
+#define I915_GEM_VM_BIND_READONLY(1 << 0)
+#define I915_GEM_VM_BIND_CAPTURE (1 << 1)
+
+ /** @extensions: 0-terminated chain of extensions for this mapping. */
+ __u64 extensions;
+};
+
+/**
+ * struct drm_i915_gem_vm_unbind - VA to object mapping to unbind.
+ *
+ * This structure is passed to VM_UNBIND ioct
[Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
VM_BIND design document with description of intended use cases. v2: Add more documentation and format as per review comments from Daniel. Signed-off-by: Niranjana Vishwanathapura --- Documentation/driver-api/dma-buf.rst | 2 + Documentation/gpu/rfc/i915_vm_bind.rst | 304 + Documentation/gpu/rfc/index.rst| 4 + 3 files changed, 310 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 36a76cbe9095..64cb924ec5bb 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -200,6 +200,8 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: +.. _indefinite_dma_fences: + Indefinite DMA Fences ~ diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..f1be560d313c --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,304 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuff calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuff mode). + +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace +to specify how the binding/unbinding should sync with other operations +like the GPU job submission. These fences will be timeline 'drm_syncobj's +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences). +For Compute contexts, they will be user/memory fences (See struct +drm_i915_vm_bind_ext_user_fence). + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. Batching of TLB flushes in some + use cases will be helpful. +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. +* Support for userptr gem objects (no special uapi is required for this). + +Execbuff ioctl in VM_BIND mode +--- +The execbuff ioctl handling in VM_BIND mode differs significantly from the +older method. A VM in VM_BIND mode will not support older execbuff mode of +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence, +no support for implicit sync. It is expected that the below work will be able +to support requirements of object dependency setting in all use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) + +This also means, we need an execbuff extension to pass in the batch +buffer addresses (See struct drm_i915_gem_execbuffer_ext_batch_addresses). + +If at all execlist support in execbuff ioctl is deemed necessary for +implicit sync in certain use cases, then support can be added later. + +In VM_BIND mode, VA allocation is completely managed by the user instead of +the i915 driver. Hence all VA assignment, eviction are not applicable in +VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not +be using the i915_vma active reference tracking. It will instead use dma-resv +object for that (See `VM_BIND dma_resv usage`_). + +So, a lot of existing code in the execbuff path like relocations, VA evictions, +vma lookup table, implicit sync, vma active reference tracking etc., are not +applicable in VM_BIND mode. Hence, the execbuff path needs to be cleaned up +by clearly separating out the functionalities where the VM_BIND mode differs +from older method and they should be moved to separate files. + +VM_PRIVATE objects +--- +By default, BOs can be mapped on multiple VMs and can also be dma-buf +exporte
[Intel-gfx] [RFC v3 0/3] drm/doc/rfc: i915 VM_BIND feature design + uapi
This is the i915 driver VM_BIND feature design RFC patch series along with the required uapi definition and description of intended use cases. v2: Updated design and uapi, more documentation. v3: Add more documentation and proper kernel-doc formatting with cross references (including missing i915_drm uapi kernel-docs which are required) as per review comments from Daniel. Signed-off-by: Niranjana Vishwanathapura Niranjana Vishwanathapura (3): drm/doc/rfc: VM_BIND feature design document drm/i915: Update i915 uapi documentation drm/doc/rfc: VM_BIND uapi definition Documentation/driver-api/dma-buf.rst | 2 + Documentation/gpu/rfc/i915_vm_bind.h | 399 + Documentation/gpu/rfc/i915_vm_bind.rst | 304 +++ Documentation/gpu/rfc/index.rst| 4 + include/uapi/drm/i915_drm.h| 153 +++--- 5 files changed, 825 insertions(+), 37 deletions(-) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst -- 2.21.0.rc0.32.g243a4c7e27
Re: [Intel-gfx] [PATCH v2] drm/i915/display: Add a separate crtc_enable hook for SKL+
Jani, I have cleaned up the hsw_crtc_enable now removing the unused
function calls.
Could you please take a look?
Regards
Manasi
On Thu, May 12, 2022 at 12:52:04PM -0700, Manasi Navare wrote:
> Currently we reuse hsw_crtc_enable for SKL+ platforms.
> But this has added a lot of platform checks for SKL+ platforms.
> So its time to move the code to a separate crtc_enable hook
> for SKL+ platforms.
>
> No functional changes here.
>
> v2: Cleanup hsw_crtc_enable (Jani N)
>
> Suggested-by: Jani Nikula
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 64
> 1 file changed, 52 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 806d50b302ab..70cde34aca10 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1895,13 +1895,13 @@ static void hsw_configure_cpu_transcoder(const struct
> intel_crtc_state *crtc_sta
> hsw_set_transconf(crtc_state);
> }
>
> -static void hsw_crtc_enable(struct intel_atomic_state *state,
> +static void skl_crtc_enable(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> const struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> - enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
> + enum pipe pipe = crtc->pipe;
> enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> bool psl_clkgate_wa;
>
> @@ -1925,8 +1925,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> intel_uncompressed_joiner_enable(new_crtc_state);
>
> intel_set_pipe_src_size(new_crtc_state);
> - if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
> - bdw_set_pipemisc(new_crtc_state);
> + bdw_set_pipemisc(new_crtc_state);
>
> if (!intel_crtc_is_bigjoiner_slave(new_crtc_state) &&
> !transcoder_is_dsi(cpu_transcoder))
> @@ -1940,10 +1939,7 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> if (psl_clkgate_wa)
> glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, true);
>
> - if (DISPLAY_VER(dev_priv) >= 9)
> - skl_pfit_enable(new_crtc_state);
> - else
> - ilk_pfit_enable(new_crtc_state);
> + skl_pfit_enable(new_crtc_state);
>
> /*
>* On ILK+ LUT must be loaded before the pipe is running but with
> @@ -1952,9 +1948,6 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> intel_color_load_luts(new_crtc_state);
> intel_color_commit_noarm(new_crtc_state);
> intel_color_commit_arm(new_crtc_state);
> - /* update DSPCNTR to configure gamma/csc for pipe bottom color */
> - if (DISPLAY_VER(dev_priv) < 9)
> - intel_disable_primary_plane(new_crtc_state);
>
> hsw_set_linetime_wm(new_crtc_state);
>
> @@ -1972,6 +1965,53 @@ static void hsw_crtc_enable(struct intel_atomic_state
> *state,
> intel_crtc_wait_for_next_vblank(crtc);
> glk_pipe_scaler_clock_gating_wa(dev_priv, pipe, false);
> }
> +}
> +
> +static void hsw_crtc_enable(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + enum pipe hsw_workaround_pipe;
> + enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
> +
> + if (drm_WARN_ON(&dev_priv->drm, crtc->active))
> + return;
> +
> + intel_encoders_pre_pll_enable(state, crtc);
> +
> + if (new_crtc_state->shared_dpll)
> + intel_enable_shared_dpll(new_crtc_state);
> +
> + intel_encoders_pre_enable(state, crtc);
> +
> + intel_set_pipe_src_size(new_crtc_state);
> + if (IS_BROADWELL(dev_priv))
> + bdw_set_pipemisc(new_crtc_state);
> +
> + if (!transcoder_is_dsi(cpu_transcoder))
> + hsw_configure_cpu_transcoder(new_crtc_state);
> +
> + crtc->active = true;
> +
> + ilk_pfit_enable(new_crtc_state);
> +
> + /*
> + * On ILK+ LUT must be loaded before the pipe is running but with
> + * clocks enabled
> + */
> + intel_color_load_luts(new_crtc_state);
> + intel_color_commit_noarm(new_crtc_state);
> + intel_color_commit_arm(new_crtc_state);
> + /* update DSPCNTR to configure gamma/csc for pipe bottom color */
> + intel_disable_primary_plane(new_crtc_state);
> +
> + hsw_set_linetime_wm(new_crtc_state);
> +
> + intel_initial_watermarks(state, crtc);
> +
> + intel_encoders_enable(state, crtc);
>
> /* If we change the relative orde
Re: [Intel-gfx] linux-next: Tree for May 16 (drm/i915/gt/intel_gt_sysfs_pm.c)
On 5/17/22 00:35, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 16/05/2022 22:22, Randy Dunlap wrote:
>>
>>
>> On 5/16/22 03:57, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20220513:
>>>
>>
>> on i386:
>>
>> CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
>> ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function
>> ‘act_freq_mhz_show’:
>> ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:276:20: error: implicit
>> declaration of function ‘sysfs_gt_attribute_r_max_func’
>> [-Werror=implicit-function-declaration]
>> u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr,
>> ^
>> ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function
>> ‘boost_freq_mhz_store’:
>> ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:327:9: error: implicit
>> declaration of function ‘sysfs_gt_attribute_w_func’
>> [-Werror=implicit-function-declaration]
>> return sysfs_gt_attribute_w_func(dev, attr,
>> ^
>> ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function
>> ‘min_freq_mhz_show’:
>> ../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:416:17: error: implicit
>> declaration of function ‘sysfs_gt_attribute_r_min_func’
>> [-Werror=implicit-function-declaration]
>> u32 min_freq = sysfs_gt_attribute_r_min_func(dev, attr,
>> ^
>> cc1: some warnings being treated as errors
>>
>>
>> Full randconfig file is attached.
>
> There is a fix for this in 09708b6d82ef ("drm/i915/gt: Fix build error
> without CONFIG_PM") queued up, waiting for the next pull request, which the
> plan was to send out next week or so. Is that okay?
When will it be in linux-next?
thanks.
--
~Randy
Re: [Intel-gfx] [PATCH v4] drm/doc: add rfc section for small BAR uapi
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Tuesday, May 17, 2022 6:49 AM
> To: Auld, Matthew ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
> ; Landwerlin, Lionel G
> ; Bloomfield, Jon ;
> Daniel Vetter ; Justen, Jordan L
> ; Kenneth Graunke ;
> Abodunrin, Akeem G ; mesa-
> d...@lists.freedesktop.org
> Subject: Re: [PATCH v4] drm/doc: add rfc section for small BAR uapi
>
>
> On 17/05/2022 11:52, Matthew Auld wrote:
> > Add an entry for the new uapi needed for small BAR on DG2+.
> >
> > v2:
> >- Some spelling fixes and other small tweaks. (Akeem & Thomas)
> >- Rework error capture interactions, including no longer needing
> > NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
> >- Add probed_cpu_visible_size. (Lionel)
> > v3:
> >- Drop the vma query for now.
> >- Add unallocated_cpu_visible_size as part of the region query.
> >- Improve the docs some more, including documenting the expected
> > behaviour on older kernels, since this came up in some offline
> > discussion.
> > v4:
> >- Various improvements all over. (Tvrtko)
>
> You can ignore my previous reply, the clarifications from v4 read good to me.
>
> Acked-by: Tvrtko Ursulin
The patch looks good to me as well...
Acked-by: Akeem G Abodunrin
>
> Regards,
>
> Tvrtko
>
> >
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Lionel Landwerlin
> > Cc: Tvrtko Ursulin
> > Cc: Jon Bloomfield
> > Cc: Daniel Vetter
> > Cc: Jon Bloomfield
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: Akeem G Abodunrin
> > Cc: mesa-...@lists.freedesktop.org
> > ---
> > Documentation/gpu/rfc/i915_small_bar.h | 189
> +++
> > Documentation/gpu/rfc/i915_small_bar.rst | 47 ++
> > Documentation/gpu/rfc/index.rst | 4 +
> > 3 files changed, 240 insertions(+)
> > create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
> > create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
> >
> > diff --git a/Documentation/gpu/rfc/i915_small_bar.h
> > b/Documentation/gpu/rfc/i915_small_bar.h
> > new file mode 100644
> > index ..c676640b23ef
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/i915_small_bar.h
> > @@ -0,0 +1,189 @@
> > +/**
> > + * struct __drm_i915_memory_region_info - Describes one region as
> > +known to the
> > + * driver.
> > + *
> > + * Note this is using both struct drm_i915_query_item and struct
> drm_i915_query.
> > + * For this new query we are adding the new query id
> > +DRM_I915_QUERY_MEMORY_REGIONS
> > + * at &drm_i915_query_item.query_id.
> > + */
> > +struct __drm_i915_memory_region_info {
> > + /** @region: The class:instance pair encoding */
> > + struct drm_i915_gem_memory_class_instance region;
> > +
> > + /** @rsvd0: MBZ */
> > + __u32 rsvd0;
> > +
> > + /**
> > +* @probed_size: Memory probed by the driver (-1 = unknown)
> > +*
> > +* Note that it should not be possible to ever encounter a zero value
> > +* here, also note that no current region type will ever return -1 here.
> > +* Although for future region types, this might be a possibility. The
> > +* same applies to the other size fields.
> > +*/
> > + __u64 probed_size;
> > +
> > + /**
> > +* @unallocated_size: Estimate of memory remaining (-1 = unknown)
> > +*
> > +* Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable
> accounting.
> > +* Without this (or if this is an older kernel) the value here will
> > +* always equal the @probed_size. Note this is only currently tracked
> > +* for I915_MEMORY_CLASS_DEVICE regions (for other types the value
> here
> > +* will always equal the @probed_size).
> > +*/
> > + __u64 unallocated_size;
> > +
> > + union {
> > + /** @rsvd1: MBZ */
> > + __u64 rsvd1[8];
> > + struct {
> > + /**
> > +* @probed_cpu_visible_size: Memory probed by the
> driver
> > +* that is CPU accessible. (-1 = unknown).
> > +*
> > +* This will be always be <= @probed_size, and the
> > +* remainder (if there is any) will not be CPU
> > +* accessible.
> > +*
> > +* On systems without small BAR, the @probed_size will
> > +* always equal the @probed_cpu_visible_size, since all
> > +* of it will be CPU accessible.
> > +*
> > +* Note this is only tracked for
> > +* I915_MEMORY_CLASS_DEVICE regions (for other
> types the
> > +* value here will always equal the @probed_size).
> > +*
> > +* Note that if the value returned here is zero, then
> > +* this must be an old kernel which lacks the relevant
> > +* smal
[Intel-gfx] [PATCH] drm/i915/dg2: Add workaround 22014600077
Bspec: 45810,54077,68173
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 98ede9c93f00..2063c8758934 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1068,6 +1068,7 @@
#define GEN9_ENABLE_GPGPU_PREEMPTION REG_BIT(2)
#define GEN10_CACHE_MODE_SS_MMIO(0xe420)
+#define ENABLE_EU_COUNT_FOR_TDL_FLUSHREG_BIT(10)
#define ENABLE_PREFETCH_INTO_IC REG_BIT(3)
#define FLOAT_BLEND_OPTIMIZATION_ENABLE REG_BIT(4)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 756807c4b405..c647a9e48389 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2178,6 +2178,15 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
}
+ if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_B0, STEP_FOREVER) ||
+ IS_DG2_G10(i915)) {
+ /* Wa_22014600077:dg2 */
+ wa_add(wal, GEN10_CACHE_MODE_SS, 0,
+ _MASKED_BIT_ENABLE(ENABLE_EU_COUNT_FOR_TDL_FLUSH),
+ 0 /* write-only, so skip validation */,
+ true);
+ }
+
if (IS_DG1_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) ||
IS_TGL_UY_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) {
/*
--
2.20.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/doc: add rfc section for small BAR uapi (rev3)
== Series Details == Series: drm/doc: add rfc section for small BAR uapi (rev3) URL : https://patchwork.freedesktop.org/series/102875/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11665_full -> Patchwork_102875v3_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_102875v3_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_102875v3_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (13 -> 11) -- Missing(2): shard-rkl shard-dg1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_102875v3_full: ### IGT changes ### Possible regressions * igt@kms_universal_plane@universal-plane-pipe-b-functional: - shard-skl: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-skl4/igt@kms_universal_pl...@universal-plane-pipe-b-functional.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-skl8/igt@kms_universal_pl...@universal-plane-pipe-b-functional.html * igt@perf_pmu@multi-client@rcs0: - shard-skl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-skl4/igt@perf_pmu@multi-cli...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-skl8/igt@perf_pmu@multi-cli...@rcs0.html Known issues Here are the changes found in Patchwork_102875v3_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_mm@all@insert: - shard-skl: NOTRUN -> [INCOMPLETE][5] ([i915#4547]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-skl3/igt@drm_mm@a...@insert.html * igt@feature_discovery@display-4x: - shard-tglb: NOTRUN -> [SKIP][6] ([i915#1839]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-tglb1/igt@feature_discov...@display-4x.html * igt@feature_discovery@psr2: - shard-iclb: NOTRUN -> [SKIP][7] ([i915#658]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-iclb6/igt@feature_discov...@psr2.html * igt@gem_ccs@suspend-resume: - shard-tglb: NOTRUN -> [SKIP][8] ([i915#5325]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-tglb5/igt@gem_...@suspend-resume.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2410]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-tglb1/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_eio@in-flight-contexts-immediate: - shard-apl: [PASS][11] -> [TIMEOUT][12] ([i915#3063]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-apl8/igt@gem_...@in-flight-contexts-immediate.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-apl2/igt@gem_...@in-flight-contexts-immediate.html * igt@gem_exec_balancer@parallel-balancer: - shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-iclb1/igt@gem_exec_balan...@parallel-balancer.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-iclb6/igt@gem_exec_balan...@parallel-balancer.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-iclb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-tglb7/igt@gem_exec_fair@basic-none-sh...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-tglb2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][19] -> [FAIL][20] ([i915#2842]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_flush@basic-batch-kernel-default-uc: - shard-snb: [PASS][21] -> [SKIP][22] ([fdo#109271]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/shard-snb4/igt@gem_exec_fl...@basic-batch-ke
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc: add rfc section for small BAR uapi (rev3)
== Series Details == Series: drm/doc: add rfc section for small BAR uapi (rev3) URL : https://patchwork.freedesktop.org/series/102875/ State : success == Summary == CI Bug Log - changes from CI_DRM_11665 -> Patchwork_102875v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/index.html Participating hosts (38 -> 41) -- Additional (4): fi-kbl-soraka bat-adlm-1 fi-rkl-11600 bat-dg2-9 Missing(1): fi-hsw-4770 Known issues Here are the changes found in Patchwork_102875v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@bcs0: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-kbl-soraka/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#3012]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_engines: - bat-dg1-5: [PASS][8] -> [INCOMPLETE][9] ([i915#4418]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/bat-dg1-5/igt@i915_selftest@live@gt_engines.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/bat-dg1-5/igt@i915_selftest@live@gt_engines.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#1886]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@mman: - fi-bdw-5557u: [PASS][11] -> [INCOMPLETE][12] ([i915#5704]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/fi-bdw-5557u/igt@i915_selftest@l...@mman.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-bdw-5557u/igt@i915_selftest@l...@mman.html * igt@i915_selftest@live@requests: - fi-pnv-d510:[PASS][13] -> [DMESG-FAIL][14] ([i915#4528]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11665/fi-pnv-d510/igt@i915_selftest@l...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-pnv-d510/igt@i915_selftest@l...@requests.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: NOTRUN -> [INCOMPLETE][15] ([i915#5982]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-ivb-3770:NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-ivb-3770/igt@kms_chamel...@common-hpd-after-suspend.html - fi-snb-2600:NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#111827]) +7 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@dp-edid-read: - fi-kbl-soraka: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-kbl-soraka/igt@kms_chamel...@dp-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-rkl-11600: NOTRUN -> [SKIP][20] ([i915#4070] / [i915#4103]) +1 similar issue [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102875v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_co
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/doc: add rfc section for small BAR uapi (rev3)
== Series Details == Series: drm/doc: add rfc section for small BAR uapi (rev3) URL : https://patchwork.freedesktop.org/series/102875/ State : warning == Summary == Error: dim checkpatch failed 9a6a6e3a4d2e drm/doc: add rfc section for small BAR uapi -:31: WARNING:BAD_SIGN_OFF: Duplicate signature #31: Cc: Jon Bloomfield -:39: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #39: new file mode 100644 -:44: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #44: FILE: Documentation/gpu/rfc/i915_small_bar.h:1: +/** -:239: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #239: FILE: Documentation/gpu/rfc/i915_small_bar.rst:1: +== total: 0 errors, 4 warnings, 0 checks, 243 lines checked
[Intel-gfx] [PATCH 14/14] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when radeon skips
registering its own backlight device because of e.g. the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the radeon drm_device gets registered with userspace.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 46549d5179ee..c1cbebb51be1 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -30,6 +30,8 @@
#include
#include
+#include
+
#include "radeon.h"
#include "radeon_atombios.h"
#include "radeon_legacy_encoders.h"
@@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct
radeon_encoder *radeon_encoder,
return;
if (radeon_backlight == 0) {
- return;
+ use_bl = false;
} else if (radeon_backlight == 1) {
use_bl = true;
} else if (radeon_backlight == -1) {
@@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct
radeon_encoder *radeon_encoder,
else
radeon_legacy_backlight_init(radeon_encoder, connector);
}
+
+ /*
+* If there is no native backlight device (which may happen even when
+* use_bl==true) try registering an ACPI video backlight device instead.
+*/
+ if (!rdev->mode_info.bl_encoder)
+ acpi_video_register_backlight();
}
void
--
2.36.0
[Intel-gfx] [PATCH 13/14] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 9 +++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index f9c62cd84a18..26f638ab7a5f 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -186,11 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
return;
if (!(adev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
- return;
+ goto register_acpi_backlight;
if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
- return;
+ goto register_acpi_backlight;
}
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
@@ -227,6 +227,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
error:
kfree(pdata);
return;
+
+register_acpi_backlight:
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
+ return;
}
void
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a838c7b5d942..06baa4f27680 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4083,6 +4083,8 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_display_manager *dm)
if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
DRM_INFO("Skipping amdgpu DM backlight registration\n");
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
return;
}
--
2.36.0
[Intel-gfx] [PATCH 12/14] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails
Typically the acpi_video driver will initialize before nouveau, which used to cause /sys/class/backlight/acpi_video0 to get registered and then nouveau would register its own nv_backlight device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when native backlight device registration has failed / was skipped to ensure that there is a backlight device available before the drm_device gets registered with userspace. Signed-off-by: Hans de Goede --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index f56ff797c78c..0ae8793357a4 100644 --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -436,6 +436,13 @@ nouveau_backlight_init(struct drm_connector *connector) fail_alloc: kfree(bl); + /* +* If we get here we have an internal panel, but no nv_backlight, +* try registering an ACPI video backlight device instead. +*/ + if (ret == 0) + acpi_video_register_backlight(); + return ret; } -- 2.36.0
[Intel-gfx] [PATCH 11/14] drm/i915: Call acpi_video_register_backlight()
On machins without an i915 opregion the acpi_video driver immediately probes the ACPI video bus and used to also immediately register acpi_video# backlight devices when supported. Once the drm/kms driver then loaded later and possibly registered a native backlight device then the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices (when acpi_video_get_backlight_type()==native). This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() after the i915 calls acpi_video_register() (after setting up the i915 opregion) so that the acpi_video backlight devices get registered on systems where the i915 native backlight device is not registered. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/display/intel_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 85fbf59e0f58..500659c51e8d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -10672,6 +10672,7 @@ void intel_display_driver_register(struct drm_i915_private *i915) /* Must be done after probing outputs */ intel_opregion_register(i915); acpi_video_register(); + acpi_video_register_backlight(); intel_audio_init(i915); -- 2.36.0
[Intel-gfx] [PATCH 10/14] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer necessary to monitor for a
native (BACKLIGHT_RAW) device showing up later and to then unregister
the acpi_video backlight device(s).
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 2 --
drivers/acpi/video_detect.c | 36
2 files changed, 38 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 79e75dc86243..20a2638f0ef1 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -89,7 +89,6 @@ static void acpi_video_bus_notify(struct acpi_device *device,
u32 event);
static void acpi_video_bus_register_backlight_work(struct work_struct
*ignored);
static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
acpi_video_bus_register_backlight_work);
-void acpi_video_detect_exit(void);
/*
* Indices in the _BCL method response: the first two items are special,
@@ -2345,7 +2344,6 @@ static int __init acpi_video_init(void)
static void __exit acpi_video_exit(void)
{
- acpi_video_detect_exit();
acpi_video_unregister();
}
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 6caabdf189c9..3fa79584981e 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -39,10 +39,6 @@
void acpi_video_unregister_backlight(void);
-static bool backlight_notifier_registered;
-static struct notifier_block backlight_nb;
-static struct work_struct backlight_notify_work;
-
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -516,26 +512,6 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
{ },
};
-/* This uses a workqueue to avoid various locking ordering issues */
-static void acpi_video_backlight_notify_work(struct work_struct *work)
-{
- if (acpi_video_get_backlight_type(false) != acpi_backlight_video)
- acpi_video_unregister_backlight();
-}
-
-static int acpi_video_backlight_notify(struct notifier_block *nb,
- unsigned long val, void *bd)
-{
- struct backlight_device *backlight = bd;
-
- /* A raw bl registering may change video -> native */
- if (backlight->props.type == BACKLIGHT_RAW &&
- val == BACKLIGHT_REGISTERED)
- schedule_work(&backlight_notify_work);
-
- return NOTIFY_OK;
-}
-
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
@@ -565,12 +541,6 @@ enum acpi_backlight_type
acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
- INIT_WORK(&backlight_notify_work,
- acpi_video_backlight_notify_work);
- backlight_nb.notifier_call = acpi_video_backlight_notify;
- backlight_nb.priority = 0;
- if (backlight_register_notifier(&backlight_nb) == 0)
- backlight_notifier_registered = true;
init_done = true;
}
if (native)
@@ -606,9 +576,3 @@ void acpi_video_set_dmi_backlight_type(enum
acpi_backlight_type type)
acpi_video_unregister_backlight();
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
-
-void __exit acpi_video_detect_exit(void)
-{
- if (backlight_notifier_registered)
- backlight_unregister_notifier(&backlight_nb);
-}
--
2.36.0
[Intel-gfx] [PATCH 08/14] ACPI: video: Simplify acpi_video_unregister_backlight()
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 7f48352840bb..95d4868f6a8c 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2259,14 +2259,10 @@ void acpi_video_unregister_backlight(void)
{
struct acpi_video_bus *video;
- mutex_lock(®ister_count_mutex);
- if (register_count) {
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
- }
- mutex_unlock(®ister_count_mutex);
+ mutex_lock(&video_list_lock);
+ list_for_each_entry(video, &video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(&video_list_lock);
}
bool acpi_video_handles_brightness_key_presses(void)
--
2.36.0
[Intel-gfx] [PATCH 09/14] ACPI: video: Make backlight class device registration a separate step
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video0 device (when acpi_video_get_backlight_type()==native).
This means that userspace briefly sees 2 devices and the disappearing of
acpi_video0 after a brief time confuses the systemd backlight level
save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this make backlight class device registration a separate step
done by a new acpi_video_register_backlight() function. The intend is for
this to be called by the drm/kms driver *after* it is done setting up its
own native backlight device. So that acpi_video_get_backlight_type() knows
if a native backlight will be available or not at acpi_video backlight
registration time, avoiding the add + remove dance.
Note the new acpi_video_register_backlight() function is also called from
a delayed work to ensure that the acpi_video backlight devices does get
registered if necessary even if there is no drm/kms driver or when it is
disabled.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 45 ---
include/acpi/video.h | 2 ++
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 95d4868f6a8c..79e75dc86243 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -31,6 +31,12 @@
#define ACPI_VIDEO_BUS_NAME"Video Bus"
#define ACPI_VIDEO_DEVICE_NAME "Video Device"
+/*
+ * Display probing is known to take up to 5 seconds, so delay the fallback
+ * backlight registration by 5 seconds + 3 seconds for some extra margin.
+ */
+#define ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY(8 * HZ)
+
#define MAX_NAME_LEN 20
MODULE_AUTHOR("Bruno Ducrot");
@@ -80,6 +86,9 @@ static LIST_HEAD(video_bus_head);
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static void acpi_video_bus_register_backlight_work(struct work_struct
*ignored);
+static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
+ acpi_video_bus_register_backlight_work);
void acpi_video_detect_exit(void);
/*
@@ -1862,8 +1871,6 @@ static int acpi_video_bus_register_backlight(struct
acpi_video_bus *video)
if (video->backlight_registered)
return 0;
- acpi_video_run_bcl_for_osi(video);
-
if (acpi_video_get_backlight_type(false) != acpi_backlight_video)
return 0;
@@ -2089,7 +2096,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
list_add_tail(&video->entry, &video_bus_head);
mutex_unlock(&video_list_lock);
- acpi_video_bus_register_backlight(video);
+ /*
+* The userspace visible backlight_device gets registered separately
+* from acpi_video_register_backlight().
+*/
+ acpi_video_run_bcl_for_osi(video);
acpi_video_bus_add_notify_handler(video);
return 0;
@@ -2128,6 +2139,11 @@ static int acpi_video_bus_remove(struct acpi_device
*device)
return 0;
}
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
+{
+ acpi_video_register_backlight();
+}
+
static int __init is_i740(struct pci_dev *dev)
{
if (dev->device == 0x00D1)
@@ -2238,6 +2254,17 @@ int acpi_video_register(void)
*/
register_count = 1;
+ /*
+* acpi_video_bus_add() skips registering the userspace visible
+* backlight_device. The intend is for this to be registered by the
+* drm/kms driver calling acpi_video_register_backlight() *after* it is
+* done setting up its own native backlight device. The delayed work
+* ensures that acpi_video_register_backlight() always gets called
+* eventually, in case there is no drm/kms driver or it is disabled.
+*/
+ schedule_delayed_work(&video_bus_register_backlight_work,
+ ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY);
+
leave:
mutex_unlock(®ister_count_mutex);
return ret;
@@ -2248,6 +2275,7 @@ void acpi_video_unregister(void)
{
mutex_lock(®ister_count_mutex);
if (register_count) {
+ cancel_delayed_work_sync(&video_bus_register_backlight_work);
acpi_bus_unregister_driver(&acpi_video_bus);
register_count = 0;
}
@@ -2255,6 +2283,17 @@ void acpi_video_unregister(void)
}
EXPORT_SYMBOL(acpi_video_unregister);
+void acpi_video_register_backlight(void)
+{
+ struct acpi_video_bus *video;
+
+ mutex_lock(&video_list_lock);
+ list_for_each_entry(video, &video_bus_he
[Intel-gfx] [PATCH 07/14] ACPI: video: Remove acpi_video_bus from list before tearing it down
Move the list_del removing an acpi_video_bus from video_bus_head on teardown to before the teardown is done, to avoid code iterating over the video_bus_head list seeing acpi_video_bus objects on there which are (partly) torn down already. Signed-off-by: Hans de Goede --- drivers/acpi/acpi_video.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c index cebef3403620..7f48352840bb 100644 --- a/drivers/acpi/acpi_video.c +++ b/drivers/acpi/acpi_video.c @@ -2114,14 +2114,14 @@ static int acpi_video_bus_remove(struct acpi_device *device) video = acpi_driver_data(device); - acpi_video_bus_remove_notify_handler(video); - acpi_video_bus_unregister_backlight(video); - acpi_video_bus_put_devices(video); - mutex_lock(&video_list_lock); list_del(&video->entry); mutex_unlock(&video_list_lock); + acpi_video_bus_remove_notify_handler(video); + acpi_video_bus_unregister_backlight(video); + acpi_video_bus_put_devices(video); + kfree(video->attached_array); kfree(video); -- 2.36.0
[Intel-gfx] [PATCH 06/14] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()
Now that all kms drivers which register native/BACKLIGHT_RAW type backlight devices on x86/ACPI boards call acpi_video_get_backlight_type(true), with the native=true value getting cached, there no longer is a need to call backlight_device_get_by_type(BACKLIGHT_RAW) to see if a native backlight device is available. Relying on the cached native_available value not only is simpler, it will also work correctly in cases where then native backlight registration was skipped because of the acpi_video_get_backlight_type() return value. Signed-off-by: Hans de Goede --- drivers/acpi/video_detect.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0a06f0edd298..6caabdf189c9 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -586,8 +586,7 @@ enum acpi_backlight_type acpi_video_get_backlight_type(bool native) if (!(video_caps & ACPI_VIDEO_BACKLIGHT)) return acpi_backlight_vendor; - if (acpi_osi_is_win8() && - (native_available || backlight_device_get_by_type(BACKLIGHT_RAW))) + if (acpi_osi_is_win8() && native_available) return acpi_backlight_native; return acpi_backlight_video; -- 2.36.0
[Intel-gfx] [PATCH 04/14] drm/radeon: Don't register backlight when another backlight should be used
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/radeon/atombios_encoders.c | 7 +++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index ddbeb2124df7..37205953056b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -258,6 +258,7 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ select ACPI_VIDEO if ACPI && X86 && INPUT
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 70bd84b7ef2b..f82577dc25e8 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -32,6 +32,8 @@
#include
#include
+#include
+
#include "atom.h"
#include "radeon_atombios.h"
#include "radeon.h"
@@ -211,6 +213,11 @@ void radeon_atom_backlight_init(struct radeon_encoder
*radeon_encoder,
if (!(rdev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
+ DRM_INFO("Skipping radeon atom DIG backlight registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 7fdb77d48d6a..d2180f5c80fa 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -33,6 +33,8 @@
#include
#include
+#include
+
#include "radeon.h"
#include "radeon_asic.h"
#include "radeon_legacy_encoders.h"
@@ -389,6 +391,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder
*radeon_encoder,
return;
#endif
+ if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
+ DRM_INFO("Skipping radeon legacy LVDS backlight
registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
--
2.36.0
[Intel-gfx] [PATCH 03/14] drm/amdgpu: Don't register backlight when another backlight should be used
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7 +++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
3 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index f1422bee3dcc..ddbeb2124df7 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -280,6 +280,7 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ select ACPI_VIDEO if ACPI && X86 && INPUT
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index a92d86e12718..f9c62cd84a18 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -26,6 +26,8 @@
#include
+#include
+
#include
#include
#include "amdgpu.h"
@@ -186,6 +188,11 @@ void amdgpu_atombios_encoder_init_backlight(struct
amdgpu_encoder *amdgpu_encode
if (!(adev->mode_info.firmware_flags &
ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
+ DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 62139ff35476..a838c7b5d942 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -83,6 +83,8 @@
#include
#include
+#include
+
#if defined(CONFIG_DRM_AMD_DC_DCN)
#include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
@@ -4079,6 +4081,11 @@ amdgpu_dm_register_backlight_device(struct
amdgpu_display_manager *dm)
amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
+ if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
+ DRM_INFO("Skipping amdgpu DM backlight registration\n");
+ return;
+ }
+
props.max_brightness = AMDGPU_MAX_BL_LEVEL;
props.brightness = AMDGPU_MAX_BL_LEVEL;
props.type = BACKLIGHT_RAW;
--
2.36.0
[Intel-gfx] [PATCH 02/14] drm/i915: Don't register backlight when another backlight should be used
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 98f7ea44042f..582d7f48575d 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -6,6 +6,8 @@
#include
#include
+#include
+
#include "intel_backlight.h"
#include "intel_connector.h"
#include "intel_de.h"
@@ -948,6 +950,11 @@ int intel_backlight_device_register(struct intel_connector
*connector)
WARN_ON(panel->backlight.max == 0);
+ if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
+ DRM_INFO("Skipping intel_backlight registration\n");
+ return 0;
+ }
+
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
--
2.36.0
[Intel-gfx] [PATCH 05/14] drm/nouveau: Don't register backlight when another backlight should be used
Before this commit when we want userspace to use the acpi_video backlight
device we register both the GPU's native backlight device and acpi_video's
firmware acpi_video# backlight device. This relies on userspace preferring
firmware type backlight devices over native ones.
Registering 2 backlight devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index daf9f87477ba..f56ff797c78c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -34,6 +34,8 @@
#include
#include
+#include
+
#include "nouveau_drv.h"
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
@@ -404,6 +406,11 @@ nouveau_backlight_init(struct drm_connector *connector)
goto fail_alloc;
}
+ if (acpi_video_get_backlight_type(true) != acpi_backlight_native) {
+ NV_INFO(drm, "Skipping nv_backlight registration\n");
+ goto fail_alloc;
+ }
+
if (!nouveau_get_backlight_name(backlight_name, bl)) {
NV_ERROR(drm, "Failed to retrieve a unique name for the
backlight interface\n");
goto fail_alloc;
--
2.36.0
[Intel-gfx] [PATCH 01/14] ACPI: video: Add a native function parameter to acpi_video_get_backlight_type()
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight devices over native ones, but
registering 2 backlight devices for a single display really is undesirable.
On x86 laptops where the native GPU backlight device should be used,
the registering of other backlight devices is avoided by their drivers
using acpi_video_get_backlight_type() and only registering their backlight
if the return value matches their type.
acpi_video_get_backlight_type() uses
backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native
driver is available and will never return native if this returns
false. This means that the GPU's native backlight registering code
cannot just call acpi_video_get_backlight_type() to determine if it
should register its backlight, since acpi_video_get_backlight_type() will
never return native until the native backlight has already registered.
To fix this add a native function parameter to
acpi_video_get_backlight_type(), which when set to true will make
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.
Note that all current callers are updated to pass false for the new
parameter, so this change in itself causes no functional changes.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 2 +-
drivers/acpi/video_detect.c | 20 ---
drivers/gpu/drm/i915/display/intel_opregion.c | 2 +-
drivers/platform/x86/acer-wmi.c | 2 +-
drivers/platform/x86/asus-laptop.c| 2 +-
drivers/platform/x86/asus-wmi.c | 4 ++--
drivers/platform/x86/compal-laptop.c | 2 +-
drivers/platform/x86/dell/dell-laptop.c | 2 +-
drivers/platform/x86/eeepc-laptop.c | 2 +-
drivers/platform/x86/fujitsu-laptop.c | 4 ++--
drivers/platform/x86/ideapad-laptop.c | 2 +-
drivers/platform/x86/intel/oaktrail.c | 2 +-
drivers/platform/x86/msi-laptop.c | 2 +-
drivers/platform/x86/msi-wmi.c| 2 +-
drivers/platform/x86/samsung-laptop.c | 2 +-
drivers/platform/x86/sony-laptop.c| 2 +-
drivers/platform/x86/thinkpad_acpi.c | 4 ++--
drivers/platform/x86/toshiba_acpi.c | 2 +-
include/acpi/video.h | 6 +++---
19 files changed, 36 insertions(+), 30 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 990ff5b0aeb8..cebef3403620 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -1864,7 +1864,7 @@ static int acpi_video_bus_register_backlight(struct
acpi_video_bus *video)
acpi_video_run_bcl_for_osi(video);
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
+ if (acpi_video_get_backlight_type(false) != acpi_backlight_video)
return 0;
mutex_lock(&video->device_list_lock);
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index becc198e4c22..0a06f0edd298 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,12 +17,14 @@
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * Backlight drivers can use acpi_video_get_backlight_type() to determine which
+ * driver should handle the backlight. RAW/GPU-driver backlight drivers must
+ * pass true for the native function argument, other drivers must pass false.
*
* If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module (m)
* this file will not be compiled and acpi_video_get_backlight_type() will
- * always return acpi_backlight_vendor.
+ * return acpi_backlight_native when its native argument is true and
+ * acpi_backlight_vendor when it is false.
*/
#include
@@ -517,7 +519,7 @@ static const struct dmi_system_id video_detect_dmi_table[]
= {
/* This uses a workqueue to avoid various locking ordering issues */
static void acpi_video_backlight_notify_work(struct work_struct *work)
{
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
+ if (acpi_video_get_backlight_type(false) != acpi_backlight_video)
acpi_video_unregister_backlight();
}
@@ -548,9 +550,10 @@ static int acpi_video_backlight_notify(struct
notifier_block *nb,
* Arguably the native on win8 check should be done first, but that would
* be a behavior change, which may causes issues.
*/
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+enum acpi_backlight_type acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool native_available;
[Intel-gfx] [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
Hi All, As mentioned in my RFC titled "drm/kms: control display brightness through drm_connector properties": https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ The first step towards this is to deal with some existing technical debt in backlight handling on x86/ACPI boards, specifically we need to stop registering multiple /sys/class/backlight devs for a single display. This series implements my RFC describing my plan for these cleanups: https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/ Specifically patches 1-6 implement the "Fixing kms driver unconditionally register their "native" backlight dev" part. And patches 7-14 implement the "Fixing acpi_video0 getting registered for a brief time" time. Note this series does not deal yet with the "Other issues" part, I plan to do a follow up series for that. The changes in this series are good to have regardless of the further "drm/kms: control display brightness through drm_connector properties" plans. So I plan to push these upstream once they are ready (once reviewed). Since this crosses various subsystems / touches multiple kms drivers my plan is to provide an immutable branch based on say 5.19-rc1 and then have that get merged into all the relevant trees. Please review. Regards, Hans Hans de Goede (14): ACPI: video: Add a native function parameter to acpi_video_get_backlight_type() drm/i915: Don't register backlight when another backlight should be used drm/amdgpu: Don't register backlight when another backlight should be used drm/radeon: Don't register backlight when another backlight should be used drm/nouveau: Don't register backlight when another backlight should be used ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() ACPI: video: Remove acpi_video_bus from list before tearing it down ACPI: video: Simplify acpi_video_unregister_backlight() ACPI: video: Make backlight class device registration a separate step ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers drm/i915: Call acpi_video_register_backlight() drm/nouveau: Register ACPI video backlight when nv_backlight registration fails drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration drm/radeon: Register ACPI video backlight when skipping radeon backlight registration drivers/acpi/acpi_video.c | 69 ++- drivers/acpi/video_detect.c | 53 +++--- drivers/gpu/drm/Kconfig | 2 + .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +++- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++ .../gpu/drm/i915/display/intel_backlight.c| 7 ++ drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/intel_opregion.c | 2 +- drivers/gpu/drm/nouveau/nouveau_backlight.c | 14 drivers/gpu/drm/radeon/atombios_encoders.c| 7 ++ drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++- .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 ++ drivers/platform/x86/acer-wmi.c | 2 +- drivers/platform/x86/asus-laptop.c| 2 +- drivers/platform/x86/asus-wmi.c | 4 +- drivers/platform/x86/compal-laptop.c | 2 +- drivers/platform/x86/dell/dell-laptop.c | 2 +- drivers/platform/x86/eeepc-laptop.c | 2 +- drivers/platform/x86/fujitsu-laptop.c | 4 +- drivers/platform/x86/ideapad-laptop.c | 2 +- drivers/platform/x86/intel/oaktrail.c | 2 +- drivers/platform/x86/msi-laptop.c | 2 +- drivers/platform/x86/msi-wmi.c| 2 +- drivers/platform/x86/samsung-laptop.c | 2 +- drivers/platform/x86/sony-laptop.c| 2 +- drivers/platform/x86/thinkpad_acpi.c | 4 +- drivers/platform/x86/toshiba_acpi.c | 2 +- include/acpi/video.h | 8 ++- 28 files changed, 156 insertions(+), 84 deletions(-) -- 2.36.0
[Intel-gfx] [PATCH v3 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose between the old "hsw-style" subslice masks or the newer xehp
mask. HSW-style masks will be stored in an array of u8's, indexed by
slice (there's never more than 6 subslices per slice on older
platforms). For Xe_HP and beyond where slices no longer exist, we only
need a single bitmask. However we already know that this mask is
eventually going to grow too large for a simple u64 to hold, so we'll
represent it in a manner that can be operated on by the utilities in
linux/bitmap.h.
v3:
- Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 246 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 78 +++---
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_getparam.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 8 +-
9 files changed, 226 insertions(+), 184 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..a3bb73f5d53b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
{
const struct sseu_dev_info *device = >->info.sseu;
struct drm_i915_private *i915 = gt->i915;
+ unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
0);
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
if (user->slice_mask & ~device->slice_mask)
return -EINVAL;
- if (user->subslice_mask & ~device->subslice_mask[0])
+ if (user->subslice_mask & ~dev_subslice_mask)
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
/* Part specific restrictions. */
if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
- unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
+ unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
unsigned int req_s = hweight8(context->slice_mask);
unsigned int req_ss = hweight8(context->subslice_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1adbf34c3632..f0acf8518a51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct intel_gt
*gt)
if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
return;
- ccs_mask =
intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(&info->sseu),
- ss_per_ccs);
+ ccs_mask =
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
+ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
* engine is not available for use.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 034182f85501..2921f510642f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -133,13 +133,6 @@ static const struct intel_mmio_range
dg2_lncf_steering_table[] = {
{},
};
-static u16 slicemask(struct intel_gt *gt, int count)
-{
- u64 dss_mask = intel_sseu_get_subslices(>->info.sseu, 0);
-
- return intel_slicemask_from_dssmask(dss_mask, count);
-}
-
int intel_gt_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -155,9 +148,12 @@ int intel_gt_init_mmio(struct intel_gt *gt)
*/
if (HAS_MSLICES(i915)) {
gt->info.mslice_mask =
- slicemask(gt, GEN_DSS_PER_MSLICE) |
+
intel_slicemask_from_xehp_dssmask(gt->info.sseu.subslice_mask,
+ GEN_DSS_PER_MSLICE);
+ gt->info.mslice_mask |=
(intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3) &
GEN12_MEML3_EN_MASK);
+
if (!gt->info.mslice_m
Re: [Intel-gfx] [PATCH v4] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 11:52, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
v4:
- Various improvements all over. (Tvrtko)
You can ignore my previous reply, the clarifications from v4 read good
to me.
Acked-by: Tvrtko Ursulin
Regards,
Tvrtko
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 189 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 ++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 240 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..c676640b23ef
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,189 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /**
+* @probed_size: Memory probed by the driver (-1 = unknown)
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
+ __u64 probed_size;
+
+ /**
+* @unallocated_size: Estimate of memory remaining (-1 = unknown)
+*
+* Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.
+* Without this (or if this is an older kernel) the value here will
+* always equal the @probed_size. Note this is only currently tracked
+* for I915_MEMORY_CLASS_DEVICE regions (for other types the value here
+* will always equal the @probed_size).
+*/
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible. (-1 = unknown).
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+* I915_MEMORY_CLASS_DEVICE regions (for other types the
+* value here will always equal the @probed_size).
+*
+* Note that if the value returned here is zero, then
+* this must be an old kernel which lacks the relevant
+* small-bar uAPI support (including
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+* such systems we should never actually end up with a
+* small BAR configuration, assuming we are able to load
+* the kernel module. Hence it should be safe to treat
+* this the same as when @probed_cpu_visible_size ==
+* @probed_size.
+*/
+ __u64 probed_cpu_visible_size;
+
+ /**
+* @unallocated_cpu_visible_size: Estimate of CPU
+* visible memory remaining (-1 = unknown).
+*
+
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 10:12, Matthew Auld wrote:
On 17/05/2022 09:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it appears
zeroes are returned today so that has to stay I think. Does it
effectively mean userspace has to consider both 0 and -1 as unknown is
the question.
It looks like it just returns the totalram_pages(). So at the moment
nothing ever currently returns -1 or 0. Maybe that was a mistake for
I915_MEMORY_SYSTEM.
Yes I figured out my confusion later.
+
+ /**
+ * @unallocated_size: Estimate of memory remaining (-1 = unknown)
+ *
+ * Note this is only currently tracked for I915_MEMORY_CLASS_DEVICE
+ * regions, and also requires CAP_PERFMON or CAP_SYS_ADMIN to get
+ * reliable accounting. Without this(or if this an older kernel)
the
s/if this an/if this is an/
Also same question as above about -1.
This should be the same as above, since this will give the same value as
probed_size, or give the real avail value for lmem.
+ * value here will always match the @probed_size.
+ */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
Also question about -1. In this case this could be done since the
field is yet to be added but I am curious if it ever can be -1.
I was just going to make this the same as probed_size for system memory.
But we could use -1 here instead. What do you think? Same for
unallocated below.
I don't completely follow the instead part, when you already have
documented it?
-1 will start appearing with changes that require CAP_SYS_PERFMON right?
Regards,
Tvrtko
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ *
+ * On systems without small BAR, the @probed_size will
+ * always equal the @probed_cpu_visible_size, since all
+ * of it will be CPU accessible.
+ *
+ * Note that if the value returned here is zero, then
+ * this must be an old kernel which lacks the relevant
+ * small-bar uAPI support(including
I have noticed you prefer no space before parentheses throughout the
text so I guess it's just my preference to have it. Very nitpicky even
if I am right so up to you.
Ok, will change :)
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+ * such systems we should never actually end up with a
+ * small BAR configuration, assuming we are able to load
+ * the kernel module. Hence it should be safe to treat
+ * this the same as when @probed_cpu_visible_size ==
+ * @probed_size.
+ *
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 10:39, Lionel Landwerlin wrote:
On 17/05/2022 12:23, Tvrtko Ursulin wrote:
On 17/05/2022 09:55, Lionel Landwerlin wrote:
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164
+++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it
appears zeroes are returned today so that has to stay I think. Does
it effectively mean userspace has to consider both 0 and -1 as
unknown is the question.
I raised this on v2. As far as I can tell there are no situation
where we would get -1.
Is it really probed_size=0 on smem?? It's not the case on the
internal branch.
My bad, I misread the arguments to intel_memory_region_create while
grepping:
struct intel_memory_region *i915_gem_shmem_setup(struct
drm_i915_private *i915,
u16 type, u16 instance)
{
return intel_memory_region_create(i915, 0,
totalram_pages() << PAGE_SHIFT,
PAGE_SIZE, 0, 0,
type, instance,
&shmem_region_ops);
I saw "0, 0" and wrongly assumed that would be the data, since it
matched with my mental model and the comment against unallocated_size
saying it's only tracked for device memory.
Although I'd say it is questionable for i915 to return this data. I
wonder it use case is possible where it would even be wrong but don't
know. I guess the cat is out of the bag now.
Not sure how questionable that is. There are a bunch of tools reporting
the amount of memory available (free, top, htop, etc...).
It might not be totalram_pages() but probably something close to it.
Questionable as it being a resource driver does not own so it reporting
it is a pure userspace convenience and maintenance burden for the
driver. :) Not sure I understand why userspace even wants to know? Only
reliable use could be to decide whether to even try and run a workload?
But in that case too perhaps users wants to run it with swapping so let
them.
There is also the question memory accounting and a process could be
running in a container with a limited view of the world (totalram_pages
would be wrong). Although granted, we bypass memory accounting at the
moment. Not sure what was the discussion on that before. Probably
because one process can create an object and another can instantiate the
backing store. Whether or not we could, or should, therefore account
against the real creator is the question. But if we one day did, then
we'd have to fiddle with the memory query to stop returning
totalram_pages() and that would potentially be complicated. Well
"would".. we probably will since this is already shipping.
Regards,
Tvrtko
Having a non 0 & non -1 value is useful.
-Lionel
If the situation is -1 for unknown and some valid size (not zero) I
don't think there is a problem here.
Regards,
Tvrtko
Anv is not currently handling that case.
I would very much like to not deal with 0 for smem.
It really makes it eas
[Intel-gfx] [PATCH] drm/i915: Individualize fences before adding to dma_resv obj
_i915_vma_move_to_active() can receive > 1 fences for
multiple batch buffers submission. Because dma_resv_add_fence()
can only accept one fence at a time, change _i915_vma_move_to_active()
to be aware of multiple fences so that it can add individual
fences to the dma resv object.
v2: make sure to reserve enough fence slots before adding.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5614
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_vma.c | 47 +++--
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4f6db539571a..19bb661e6f3b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include
#include "display/intel_frontbuffer.h"
@@ -1823,6 +1824,20 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
if (unlikely(err))
return err;
+ /* Reserve fences slot early to prevent an allocation after preparing
+* the workload and associating fences with dma_resv.
+*/
+ if (fence && !(flags & __EXEC_OBJECT_NO_RESERVE)) {
+ struct dma_fence *curr;
+ int idx;
+
+ dma_fence_array_for_each(curr, idx, fence) {
+ err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
+ if (unlikely(err))
+ return err;
+ }
+ }
+
if (flags & EXEC_OBJECT_WRITE) {
struct intel_frontbuffer *front;
@@ -1832,31 +1847,23 @@ int _i915_vma_move_to_active(struct i915_vma *vma,
i915_active_add_request(&front->write, rq);
intel_frontbuffer_put(front);
}
+ }
- if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
- if (unlikely(err))
- return err;
- }
+ if (fence) {
+ struct dma_fence *curr;
+ enum dma_resv_usage usage;
+ int idx;
- if (fence) {
- dma_resv_add_fence(vma->obj->base.resv, fence,
- DMA_RESV_USAGE_WRITE);
+ obj->read_domains = 0;
+ if (flags & EXEC_OBJECT_WRITE) {
+ usage = DMA_RESV_USAGE_WRITE;
obj->write_domain = I915_GEM_DOMAIN_RENDER;
- obj->read_domains = 0;
- }
- } else {
- if (!(flags & __EXEC_OBJECT_NO_RESERVE)) {
- err = dma_resv_reserve_fences(vma->obj->base.resv, 1);
- if (unlikely(err))
- return err;
+ } else {
+ usage = DMA_RESV_USAGE_READ;
}
- if (fence) {
- dma_resv_add_fence(vma->obj->base.resv, fence,
- DMA_RESV_USAGE_READ);
- obj->write_domain = 0;
- }
+ dma_fence_array_for_each(curr, idx, fence)
+ dma_resv_add_fence(vma->obj->base.resv, curr, usage);
}
if (flags & EXEC_OBJECT_NEEDS_FENCE && vma->fence)
--
2.35.1
[Intel-gfx] [PATCH v4] drm/doc: add rfc section for small BAR uapi
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
v4:
- Various improvements all over. (Tvrtko)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 189 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 ++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 240 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..c676640b23ef
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,189 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /**
+* @probed_size: Memory probed by the driver (-1 = unknown)
+*
+* Note that it should not be possible to ever encounter a zero value
+* here, also note that no current region type will ever return -1 here.
+* Although for future region types, this might be a possibility. The
+* same applies to the other size fields.
+*/
+ __u64 probed_size;
+
+ /**
+* @unallocated_size: Estimate of memory remaining (-1 = unknown)
+*
+* Requires CAP_PERFMON or CAP_SYS_ADMIN to get reliable accounting.
+* Without this (or if this is an older kernel) the value here will
+* always equal the @probed_size. Note this is only currently tracked
+* for I915_MEMORY_CLASS_DEVICE regions (for other types the value here
+* will always equal the @probed_size).
+*/
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible. (-1 = unknown).
+*
+* This will be always be <= @probed_size, and the
+* remainder (if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note this is only tracked for
+* I915_MEMORY_CLASS_DEVICE regions (for other types the
+* value here will always equal the @probed_size).
+*
+* Note that if the value returned here is zero, then
+* this must be an old kernel which lacks the relevant
+* small-bar uAPI support (including
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+* such systems we should never actually end up with a
+* small BAR configuration, assuming we are able to load
+* the kernel module. Hence it should be safe to treat
+* this the same as when @probed_cpu_visible_size ==
+* @probed_size.
+*/
+ __u64 probed_cpu_visible_size;
+
+ /**
+* @unallocated_cpu_visible_size: Estimate of CPU
+* visible memory remaining (-1 = unknown).
+*
+* Note this is only tracked for
+* I915_MEMORY_CLASS_DEVICE regions (for other types the
+* value here will always equal the
+
Re: [Intel-gfx] [PATCH v4 2/5] drm: Add HPD state to drm_connector_oob_hotplug_event()
On Mon, May 02, 2022 at 09:53:13AM -0700, Bjorn Andersson wrote:
> In some implementations, such as the Qualcomm platforms, the display
> driver has no way to query the current HPD state and as such it's
> impossible to distinguish between disconnect and attention events.
>
> Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
> state.
>
> Also push the test for unchanged state in the displayport altmode driver
> into the i915 driver, to allow other drivers to act upon each update.
>
> Signed-off-by: Bjorn Andersson
Acked-by: Heikki Krogerus
> ---
>
> Changes since v3:
> - Transition to drm_connector_status instead of custom hpd_state
>
> drivers/gpu/drm/drm_connector.c | 6 --
> drivers/gpu/drm/i915/display/intel_dp.c | 17 ++---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/usb/typec/altmodes/displayport.c | 10 +++---
> include/drm/drm_connector.h | 6 --
> 5 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1c48d162c77e..e86c69f0640f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -2794,6 +2794,7 @@ struct drm_connector
> *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> /**
> * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to
> connector
> * @connector_fwnode: fwnode_handle to report the event on
> + * @status: hot plug detect logical state
> *
> * On some hardware a hotplug event notification may come from outside the
> display
> * driver / device. An example of this is some USB Type-C setups where the
> hardware
> @@ -2803,7 +2804,8 @@ struct drm_connector
> *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * This function can be used to report these out-of-band events after
> obtaining
> * a drm_connector reference through calling drm_connector_find_by_fwnode().
> */
> -void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
> +void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> + enum drm_connector_status status)
> {
> struct drm_connector *connector;
>
> @@ -2812,7 +2814,7 @@ void drm_connector_oob_hotplug_event(struct
> fwnode_handle *connector_fwnode)
> return;
>
> if (connector->funcs->oob_hotplug_event)
> - connector->funcs->oob_hotplug_event(connector);
> + connector->funcs->oob_hotplug_event(connector, status);
>
> drm_connector_put(connector);
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index e4a79c11fd25..56cc023f7bbd 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4951,15 +4951,26 @@ static int intel_dp_connector_atomic_check(struct
> drm_connector *conn,
> return intel_modeset_synced_crtcs(state, conn);
> }
>
> -static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
> +static void intel_dp_oob_hotplug_event(struct drm_connector *connector,
> +enum drm_connector_status hpd_state)
> {
> struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> struct drm_i915_private *i915 = to_i915(connector->dev);
> + bool hpd_high = hpd_state == connector_status_connected;
> + unsigned int hpd_pin = encoder->hpd_pin;
> + bool need_work = false;
>
> spin_lock_irq(&i915->irq_lock);
> - i915->hotplug.event_bits |= BIT(encoder->hpd_pin);
> + if (hpd_high != test_bit(hpd_pin,
> &i915->hotplug.oob_hotplug_last_state)) {
> + i915->hotplug.event_bits |= BIT(hpd_pin);
> +
> + __assign_bit(hpd_pin, &i915->hotplug.oob_hotplug_last_state,
> hpd_high);
> + need_work = true;
> + }
> spin_unlock_irq(&i915->irq_lock);
> - queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
> +
> + if (need_work)
> + queue_delayed_work(system_wq, &i915->hotplug.hotplug_work, 0);
> }
>
> static const struct drm_connector_funcs intel_dp_connector_funcs = {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 24111bf42ce0..96c088bb5522 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -135,6 +135,9 @@ struct i915_hotplug {
> /* Whether or not to count short HPD IRQs in HPD storms */
> u8 hpd_short_storm_enabled;
>
> + /* Last state reported by oob_hotplug_event for each encoder */
> + unsigned long oob_hotplug_last_state;
> +
> /*
>* if we get a HPD irq from DP and a HPD irq from non-DP
>* the non-DP HPD could block the workqueue on a mode config
> diff --git a/drivers/usb/typec/altmodes/displayport.c
> b/drivers/usb/typec/altmodes/displayport.c
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 12:23, Tvrtko Ursulin wrote:
On 17/05/2022 09:55, Lionel Landwerlin wrote:
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164
+++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it
appears zeroes are returned today so that has to stay I think. Does
it effectively mean userspace has to consider both 0 and -1 as
unknown is the question.
I raised this on v2. As far as I can tell there are no situation
where we would get -1.
Is it really probed_size=0 on smem?? It's not the case on the
internal branch.
My bad, I misread the arguments to intel_memory_region_create while
grepping:
struct intel_memory_region *i915_gem_shmem_setup(struct
drm_i915_private *i915,
u16 type, u16 instance)
{
return intel_memory_region_create(i915, 0,
totalram_pages() << PAGE_SHIFT,
PAGE_SIZE, 0, 0,
type, instance,
&shmem_region_ops);
I saw "0, 0" and wrongly assumed that would be the data, since it
matched with my mental model and the comment against unallocated_size
saying it's only tracked for device memory.
Although I'd say it is questionable for i915 to return this data. I
wonder it use case is possible where it would even be wrong but don't
know. I guess the cat is out of the bag now.
Not sure how questionable that is. There are a bunch of tools reporting
the amount of memory available (free, top, htop, etc...).
It might not be totalram_pages() but probably something close to it.
Having a non 0 & non -1 value is useful.
-Lionel
If the situation is -1 for unknown and some valid size (not zero) I
don't think there is a problem here.
Regards,
Tvrtko
Anv is not currently handling that case.
I would very much like to not deal with 0 for smem.
It really makes it easier for userspace rather than having to fish
information from 2 different places and on top of dealing with
multiple kernel versions.
-Lionel
+
+ /**
+ * @unallocated_size: Estimate of memory remaining (-1 = unknown)
+ *
+ * Note this is only currently tracked for
I915_MEMORY_CLASS_DEVICE
+ * regions, and also requires CAP_PERFMON or CAP_SYS_ADMIN to get
+ * reliable accounting. Without this(or if this an older
kernel) the
s/if this an/if this is an/
Also same question as above about -1.
+ * value here will always match the @probed_size.
+ */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
Also question about -1. In this case this could be done since the
field is yet to be added but I am curious if it ever can be -1.
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 09:55, Lionel Landwerlin wrote:
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it appears
zeroes are returned today so that has to stay I think. Does it
effectively mean userspace has to consider both 0 and -1 as unknown is
the question.
I raised this on v2. As far as I can tell there are no situation where
we would get -1.
Is it really probed_size=0 on smem?? It's not the case on the internal
branch.
My bad, I misread the arguments to intel_memory_region_create while grepping:
struct intel_memory_region *i915_gem_shmem_setup(struct drm_i915_private *i915,
u16 type, u16 instance)
{
return intel_memory_region_create(i915, 0,
totalram_pages() << PAGE_SHIFT,
PAGE_SIZE, 0, 0,
type, instance,
&shmem_region_ops);
I saw "0, 0" and wrongly assumed that would be the data, since it matched with
my mental model and the comment against unallocated_size saying it's only tracked for
device memory.
Although I'd say it is questionable for i915 to return this data. I wonder it
use case is possible where it would even be wrong but don't know. I guess the
cat is out of the bag now.
If the situation is -1 for unknown and some valid size (not zero) I don't think
there is a problem here.
Regards,
Tvrtko
Anv is not currently handling that case.
I would very much like to not deal with 0 for smem.
It really makes it easier for userspace rather than having to fish
information from 2 different places and on top of dealing with multiple
kernel versions.
-Lionel
+
+ /**
+ * @unallocated_size: Estimate of memory remaining (-1 = unknown)
+ *
+ * Note this is only currently tracked for I915_MEMORY_CLASS_DEVICE
+ * regions, and also requires CAP_PERFMON or CAP_SYS_ADMIN to get
+ * reliable accounting. Without this(or if this an older kernel)
the
s/if this an/if this is an/
Also same question as above about -1.
+ * value here will always match the @probed_size.
+ */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
Also question about -1. In this case this could be done since the
field is yet to be added but I am curious if it ever can be -1.
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ *
+ * On systems without small BAR, the @probed_size will
+ * always equal the @probed_cpu_visible_size, since all
+
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 09:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it appears
zeroes are returned today so that has to stay I think. Does it
effectively mean userspace has to consider both 0 and -1 as unknown is
the question.
It looks like it just returns the totalram_pages(). So at the moment
nothing ever currently returns -1 or 0. Maybe that was a mistake for
I915_MEMORY_SYSTEM.
+
+ /**
+ * @unallocated_size: Estimate of memory remaining (-1 = unknown)
+ *
+ * Note this is only currently tracked for I915_MEMORY_CLASS_DEVICE
+ * regions, and also requires CAP_PERFMON or CAP_SYS_ADMIN to get
+ * reliable accounting. Without this(or if this an older kernel) the
s/if this an/if this is an/
Also same question as above about -1.
This should be the same as above, since this will give the same value as
probed_size, or give the real avail value for lmem.
+ * value here will always match the @probed_size.
+ */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
Also question about -1. In this case this could be done since the field
is yet to be added but I am curious if it ever can be -1.
I was just going to make this the same as probed_size for system memory.
But we could use -1 here instead. What do you think? Same for
unallocated below.
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ *
+ * On systems without small BAR, the @probed_size will
+ * always equal the @probed_cpu_visible_size, since all
+ * of it will be CPU accessible.
+ *
+ * Note that if the value returned here is zero, then
+ * this must be an old kernel which lacks the relevant
+ * small-bar uAPI support(including
I have noticed you prefer no space before parentheses throughout the
text so I guess it's just my preference to have it. Very nitpicky even
if I am right so up to you.
Ok, will change :)
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+ * such systems we should never actually end up with a
+ * small BAR configuration, assuming we are able to load
+ * the kernel module. Hence it should be safe to treat
+ * this the same as when @probed_cpu_visible_size ==
+ * @probed_size.
+ */
+ __u64 probed_cpu_visible_size;
+
+ /**
+ * @unallocated_cpu_visible_size: Estimate of CPU
+ * visible memory remaining (-1 = unknown).
+ *
+ * Note this is only currently tracked for
+
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 17/05/2022 11:29, Tvrtko Ursulin wrote:
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it appears
zeroes are returned today so that has to stay I think. Does it
effectively mean userspace has to consider both 0 and -1 as unknown is
the question.
I raised this on v2. As far as I can tell there are no situation where
we would get -1.
Is it really probed_size=0 on smem?? It's not the case on the internal
branch.
Anv is not currently handling that case.
I would very much like to not deal with 0 for smem.
It really makes it easier for userspace rather than having to fish
information from 2 different places and on top of dealing with multiple
kernel versions.
-Lionel
+
+ /**
+ * @unallocated_size: Estimate of memory remaining (-1 = unknown)
+ *
+ * Note this is only currently tracked for I915_MEMORY_CLASS_DEVICE
+ * regions, and also requires CAP_PERFMON or CAP_SYS_ADMIN to get
+ * reliable accounting. Without this(or if this an older kernel)
the
s/if this an/if this is an/
Also same question as above about -1.
+ * value here will always match the @probed_size.
+ */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
Also question about -1. In this case this could be done since the
field is yet to be added but I am curious if it ever can be -1.
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ *
+ * On systems without small BAR, the @probed_size will
+ * always equal the @probed_cpu_visible_size, since all
+ * of it will be CPU accessible.
+ *
+ * Note that if the value returned here is zero, then
+ * this must be an old kernel which lacks the relevant
+ * small-bar uAPI support(including
I have noticed you prefer no space before parentheses throughout the
text so I guess it's just my preference to have it. Very nitpicky even
if I am right so up to you.
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+ * such systems we should never actually end up with a
+ * small BAR configuration, assuming we are able to load
+ * the kernel module. Hence it should be safe to treat
+ * this the same as when @probed_cpu_visible_size ==
+ * @probed_size.
+ */
+ __u64 probed_cpu_visible_size;
+
+ /**
+ * @unallocated_cpu_visible_size: Estimate of CPU
+ * visible memory remaining (-1 = unknown).
+ *
+ * Note this is only currently tracked for
+ * I915_MEMORY_CLASS_
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Expose max and current bpc via debugfs (rev8)
== Series Details == Series: Expose max and current bpc via debugfs (rev8) URL : https://patchwork.freedesktop.org/series/102502/ State : warning == Summary == Error: dim checkpatch failed edfa55bea7ad drm/debug: Expose connector's max supported bpc via debugfs -:21: WARNING:BAD_SIGN_OFF: 'Reviewed-by:' is the preferred signature form #21: Reviewed-By: Arun R Murthy total: 0 errors, 1 warnings, 0 checks, 33 lines checked af74b4c5e2e2 drm/i915/display/debug: Expose crtc current bpc via debugfs 01e20ae3a0d5 drm/amd/display: Move connector debugfs to drm
Re: [Intel-gfx] [PATCH v3] drm/doc: add rfc section for small BAR uapi
On 16/05/2022 19:11, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
v3:
- Drop the vma query for now.
- Add unallocated_cpu_visible_size as part of the region query.
- Improve the docs some more, including documenting the expected
behaviour on older kernels, since this came up in some offline
discussion.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jon Bloomfield
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 164 +++
Documentation/gpu/rfc/i915_small_bar.rst | 47 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 215 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..4079d287750b
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,164 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at &drm_i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
Is -1 possible today or when it will be? For system memory it appears
zeroes are returned today so that has to stay I think. Does it
effectively mean userspace has to consider both 0 and -1 as unknown is
the question.
+
+ /**
+* @unallocated_size: Estimate of memory remaining (-1 = unknown)
+*
+* Note this is only currently tracked for I915_MEMORY_CLASS_DEVICE
+* regions, and also requires CAP_PERFMON or CAP_SYS_ADMIN to get
+* reliable accounting. Without this(or if this an older kernel) the
s/if this an/if this is an/
Also same question as above about -1.
+* value here will always match the @probed_size.
+*/
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+* @probed_cpu_visible_size: Memory probed by the driver
+* that is CPU accessible. (-1 = unknown).
Also question about -1. In this case this could be done since the field
is yet to be added but I am curious if it ever can be -1.
+*
+* This will be always be <= @probed_size, and the
+* remainder(if there is any) will not be CPU
+* accessible.
+*
+* On systems without small BAR, the @probed_size will
+* always equal the @probed_cpu_visible_size, since all
+* of it will be CPU accessible.
+*
+* Note that if the value returned here is zero, then
+* this must be an old kernel which lacks the relevant
+* small-bar uAPI support(including
I have noticed you prefer no space before parentheses throughout the
text so I guess it's just my preference to have it. Very nitpicky even
if I am right so up to you.
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS), but on
+* such systems we should never actually end up with a
+* small BAR configuration, assuming we are able to load
+* the kernel module. Hence it should be safe to treat
+* this the same as when @probed_cpu_visible_size ==
+* @probed_size.
+*/
+ __u64 probed_cpu_visible_size;
+
+ /**
+* @unallocated_cpu_visible_size: Estimate of CPU
+* visible memory remaining (-1 = unknown).
+*
+* Note this is only currently tracked for
+* I915_MEMORY_CLASS_DEVICE regions, and also requires
+* CAP_PERFMON or CAP_SYS_ADMIN to get reliab
[Intel-gfx] ✗ Fi.CI.BAT: failure for Attach and Set vrr_enabled property (rev3)
== Series Details ==
Series: Attach and Set vrr_enabled property (rev3)
URL : https://patchwork.freedesktop.org/series/102978/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11662 -> Patchwork_102978v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102978v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102978v3, 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_102978v3/index.html
Participating hosts (43 -> 10)
--
ERROR: It appears as if the changes made in Patchwork_102978v3 prevented too
many machines from booting.
Additional (1): bat-dg2-8
Missing(34): fi-kbl-soraka fi-rkl-11600 fi-rkl-guc fi-bdw-gvtdvm
fi-apl-guc fi-snb-2520m fi-pnv-d510 fi-blb-e6850 fi-skl-6600u fi-snb-2600
fi-bxt-dsi fi-bdw-5557u fi-bsw-n3050 fi-adl-ddr5 fi-bwr-2160 fi-hsw-g3258
fi-ilk-650 fi-hsw-4770 fi-ivb-3770 fi-elk-e7500 fi-bsw-nick fi-skl-6700k2
fi-kbl-7567u fi-tgl-dsi fi-skl-guc fi-cfl-8700k fi-glk-j4005 fi-ehl-2 fi-jsl-1
fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc fi-cfl-8109u fi-bsw-kefka
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102978v3:
### IGT changes ###
Possible regressions
* igt@kms_force_connector_basic@force-connector-state:
- bat-dg1-5: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11662/bat-dg1-5/igt@kms_force_connector_ba...@force-connector-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-dg1-5/igt@kms_force_connector_ba...@force-connector-state.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_force_connector_basic@force-connector-state:
- {bat-dg2-8}:NOTRUN -> [DMESG-WARN][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-dg2-8/igt@kms_force_connector_ba...@force-connector-state.html
* igt@runner@aborted:
- {bat-rpls-2}: [FAIL][4] ([i915#4312]) -> [FAIL][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11662/bat-rpls-2/igt@run...@aborted.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-rpls-2/igt@run...@aborted.html
- {bat-adln-1}: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-adln-1/igt@run...@aborted.html
- {bat-adlp-6}: NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-adlp-6/igt@run...@aborted.html
- {bat-jsl-2}:NOTRUN -> [FAIL][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-jsl-2/igt@run...@aborted.html
- {bat-jsl-1}:NOTRUN -> [FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-jsl-1/igt@run...@aborted.html
- {bat-dg2-9}:NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-dg2-9/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_102978v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- bat-dg1-5: NOTRUN -> [SKIP][11] ([fdo#111827])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-dg1-5/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- bat-adlp-4: NOTRUN -> [FAIL][12] ([i915#5457])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-adlp-4/igt@run...@aborted.html
Warnings
* igt@runner@aborted:
- bat-dg1-6: [FAIL][13] ([i915#4312] / [i915#5257]) -> [FAIL][14]
([i915#5257])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11662/bat-dg1-6/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102978v3/bat-dg1-6/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3595]: https://gitlab.freedesktop.org/drm/intel/issues/3595
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: ht
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Attach and Set vrr_enabled property (rev3)
== Series Details == Series: Attach and Set vrr_enabled property (rev3) URL : https://patchwork.freedesktop.org/series/102978/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:314:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgp
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Attach and Set vrr_enabled property (rev3)
== Series Details == Series: Attach and Set vrr_enabled property (rev3) URL : https://patchwork.freedesktop.org/series/102978/ State : warning == Summary == Error: dim checkpatch failed ca69c64ffb44 drm/vrr: Attach vrr_enabled property to the drm crtc -:81: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #81: FILE: drivers/gpu/drm/drm_mode_config.c:327: + prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC, "VRR_ENABLED"); total: 0 errors, 0 warnings, 1 checks, 50 lines checked 3cebf977fa06 drm/i915/vrr: Set drm crtc vrr_enabled property -:13: WARNING:TYPO_SPELLING: 'alreay' may be misspelled - perhaps 'already'? #13: V3: Don't attach vrr_enabled prop, as it is alreay attached. ^^ total: 0 errors, 1 warnings, 0 checks, 20 lines checked
Re: [Intel-gfx] linux-next: Tree for May 16 (drm/i915/gt/intel_gt_sysfs_pm.c)
Hi,
On 16/05/2022 22:22, Randy Dunlap wrote:
On 5/16/22 03:57, Stephen Rothwell wrote:
Hi all,
Changes since 20220513:
on i386:
CC drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.o
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function ‘act_freq_mhz_show’:
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:276:20: error: implicit
declaration of function ‘sysfs_gt_attribute_r_max_func’
[-Werror=implicit-function-declaration]
u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr,
^
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function
‘boost_freq_mhz_store’:
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:327:9: error: implicit
declaration of function ‘sysfs_gt_attribute_w_func’
[-Werror=implicit-function-declaration]
return sysfs_gt_attribute_w_func(dev, attr,
^
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function ‘min_freq_mhz_show’:
../drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:416:17: error: implicit
declaration of function ‘sysfs_gt_attribute_r_min_func’
[-Werror=implicit-function-declaration]
u32 min_freq = sysfs_gt_attribute_r_min_func(dev, attr,
^
cc1: some warnings being treated as errors
Full randconfig file is attached.
There is a fix for this in 09708b6d82ef ("drm/i915/gt: Fix build error
without CONFIG_PM") queued up, waiting for the next pull request, which
the plan was to send out next week or so. Is that okay?
Regards,
Tvrtko
[Intel-gfx] [RFC V3 2/2] drm/i915/vrr: Set drm crtc vrr_enabled property
This function sets the vrr_enabled property for crtc based on the platform support and the request from userspace. V2: Check for platform support before updating the prop. V3: Don't attach vrr_enabled prop, as it is alreay attached. Cc: Ville Syrjälä Cc: Manasi Navare Signed-off-by: Bhanuprakash Modem --- drivers/gpu/drm/i915/display/intel_vrr.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c b/drivers/gpu/drm/i915/display/intel_vrr.c index 396f2f994fa0..7263b35550de 100644 --- a/drivers/gpu/drm/i915/display/intel_vrr.c +++ b/drivers/gpu/drm/i915/display/intel_vrr.c @@ -160,6 +160,10 @@ void intel_vrr_enable(struct intel_encoder *encoder, enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; u32 trans_vrr_ctl; + if (HAS_VRR(dev_priv)) + drm_mode_crtc_set_vrr_enabled_property(crtc_state->uapi.crtc, + crtc_state->vrr.enable); + if (!crtc_state->vrr.enable) return; @@ -211,6 +215,10 @@ void intel_vrr_disable(const struct intel_crtc_state *old_crtc_state) struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder; + if (HAS_VRR(dev_priv)) + drm_mode_crtc_set_vrr_enabled_property(old_crtc_state->uapi.crtc, + false); + if (!old_crtc_state->vrr.enable) return; -- 2.35.1
[Intel-gfx] [RFC V3 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces helpers to attach and set "vrr_enabled" property
on the crtc to allow userspace to query VRR enabled status on that crtc.
Atomic drivers should attach this property to crtcs those are capable of
driving variable refresh rates using
drm_mode_crtc_attach_vrr_enabled_property().
The value should be updated based on driver and hardware capability
by using drm_mode_crtc_set_vrr_enabled_property().
V2: Use property flag as atomic
V3: Drop helper to attach vrr_enabled prop, since it is already
attached (Manasi)
Cc: Ville Syrjälä
Cc: Nicholas Kazlauskas
Cc: Manasi Navare
Cc: Harry Wentland
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/drm_crtc.c| 26 ++
drivers/gpu/drm/drm_mode_config.c | 2 +-
include/drm/drm_crtc.h| 3 +++
3 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 26a77a735905..8bb8b4bf4199 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -239,6 +239,9 @@ struct dma_fence *drm_crtc_create_fence(struct drm_crtc
*crtc)
* Driver's default scaling filter
* Nearest Neighbor:
* Nearest Neighbor scaling filter
+ * VRR_ENABLED:
+ * Atomic property for setting the VRR state of the CRTC.
+ * To enable the VRR on CRTC, user-space must set this property to 1.
*/
__printf(6, 0)
@@ -883,3 +886,26 @@ int drm_crtc_create_scaling_filter_property(struct
drm_crtc *crtc,
return 0;
}
EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
+
+/**
+ * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
+ * a crtc.
+ * @crtc: drm CRTC
+ * @vrr_enabled: True to enable the VRR on CRTC
+ *
+ * Should be used by atomic drivers to update the VRR enabled status on a CRTC
+ */
+void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
+ bool vrr_enabled)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ if (!config->prop_vrr_enabled)
+ return;
+
+ drm_object_property_set_value(&crtc->base,
+ config->prop_vrr_enabled,
+ vrr_enabled);
+}
+EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 37b4b9f0e468..b7cde73d5586 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -323,7 +323,7 @@ static int drm_mode_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
- prop = drm_property_create_bool(dev, 0,
+ prop = drm_property_create_bool(dev, DRM_MODE_PROP_ATOMIC,
"VRR_ENABLED");
if (!prop)
return -ENOMEM;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a70baea0636c..906787398f40 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1333,4 +1333,7 @@ static inline struct drm_crtc *drm_crtc_find(struct
drm_device *dev,
int drm_crtc_create_scaling_filter_property(struct drm_crtc *crtc,
unsigned int supported_filters);
+void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
+ bool vrr_enabled);
+
#endif /* __DRM_CRTC_H__ */
--
2.35.1
[Intel-gfx] [RFC V3 0/2] Attach and Set vrr_enabled property
This series will add a support to set the vrr_enabled property for crtc based on the platform support and the request from userspace. And userspace can also query to get the status of "vrr_enabled". Test-with: 20220422075223.2792586-2-bhanuprakash.mo...@intel.com Bhanuprakash Modem (2): drm/vrr: Attach vrr_enabled property to the drm crtc drm/i915/vrr: Set drm crtc vrr_enabled property drivers/gpu/drm/drm_crtc.c | 26 drivers/gpu/drm/drm_mode_config.c| 2 +- drivers/gpu/drm/i915/display/intel_vrr.c | 8 include/drm/drm_crtc.h | 3 +++ 4 files changed, 38 insertions(+), 1 deletion(-) -- 2.35.1
