Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs
On Sun, 01 May 2022 23:22:02 -0700, Andrzej Hajda wrote:
> On 29.04.2022 06:25, Dixit, Ashutosh wrote:
> > On Thu, 28 Apr 2022 07:36:14 -0700, Andrzej Hajda wrote:
> >> See [1], it is quite old, so maybe it is not valid anymore, but I see no
> >> code proving sth has changed.
> > Hi Andrzej,
> >
> > A lot has changed since that article from 2003 (for 2.5 kernel). For
> > instance there is kernfs (as I mention above):
> >
> > https://lwn.net/Articles/571590/
> >
> > A process having a sysfs file open today in my view will result in the
> > following:
> > * It will take a reference on kernfs_node (not on kobject as was the case
> >in kernel 2.5 in [1])
> > * An open file will prevent the module from being unloaded (not the kernel
> >crashing as in 2.5 in [1])
>
> Thats nice, but kernfs_node->priv still points to kobject so their
> lifetimes are bounded.
Yes, of course there has to be some connection between the kernfs and kobject.
> > So this is what I would expect with today's kernel. I am not seeing
> > anything we've done here which violates anything in [1] or [2].
> >> Also current doc says also [2] similar things, especially:
> >> "Once you registered your kobject via kobject_add(), you must never use
> >> kfree() to free it directly"
> > Correct, we are using kobject_put(), not kfree'ing the kobject.
>
> That I wouldn't agree. kobject_put is called, then the object in which
> kobject is embedded is kfree'd somewhere later on driver removal, without
> awareness of this kobject. According to your analysis it should have 0
> refs, but this is analysis of the current code, even if it is true now it
> could change in the future.
Yes but we cannot anticipate all changes which can happen in the future,
(though we should handle and make any changes which we can anticipate at
present). This is also basically what the kernel philosophy is, don't make
unnecessary generalizations and try to handle unforseen situations which
can happen in the future.
Let me add some explanations about the patch before addressing your next
point.
1. We are adding 'struct kobject sysfs_gt' to 'struct intel_gt'. We are
adding the kobject directly, not pointer to kobject. This allows us to
"reach" 'struct intel_gt' from the kobject using a simple container_of:
see kobj_to_gt().
2. Because the kobject is not kmalloc'd it cannot be kfree'd so the release
method has to be empty (or NULL). 'struct intel_gt' is kmalloc'd
separately elsewhere and memory for the kobject will be freed as part of
intel_gt.
3. To provide a NULL or empty release method we need to provide a 'struct
kobj_type kobj_gt_type' associated with the sysfs_gt kobject. This works
nicely because we were anyway need one for .default_groups (we may add
other attributes to 'id_groups' in the future). Note that the kobject is
initialized and added to sysfs using kobject_init_and_add().
4. The only reason for providing an empty release method rather than a NULL
release method is the following pr_debug in kobject_cleanup():
if (t && !t->release)
pr_debug("kobject: '%s' (%p): does not have a release()
function, it is broken and must be fixed. See
Documentation/core-api/kobject.rst.\n",
kobject_name(kobj), kobj);
This statement could possibly be removed because the release method is
not needed in the case I just described above, maybe I'll send a patch to
suggest removing it. Though I think what they will say is that since NULL
release methods are uncommon maybe just provide an empty release method
when you need a NULL release method (which is what I have done in the
patch).
Also note that, as described below, there are several other cases in the
kernel which either have NULL or an empty release methods. See below.
> And IMO it is against docs[2]:
> - "One important point cannot be overstated: every kobject must have a
> release() method, and the kobject must persist (in a consistent state)
> until that method is called. If these constraints are not met, the code is
> flawed." - empty release method means clearly it is against the docs.
> -"The end result is that a structure protected by a kobject cannot be freed
> before its reference count goes to zero. The reference count is not under
> the direct control of the code which created the kobject.".
>
> So either docs and part of kobject code were not updated to reflect
> changes you are assuming, either your assumption is incorrect.
In my view the doc is a general introduction to kobjects and simplifies
things. As shown below there are numerous examples in the kernel of both
NULL and empty release methods. I just went with the empty method because
of the reason mentioned above.
> Looking at other users of kobject it seems they follow docs, their
> release method either frees memory directly either kref_put on containing
> struct, it was just quick scan so I could overlooked sth.
>
> >> [1]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm/i915/display: Allow DRRS to be enabled during driver load
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display: Allow DRRS to be
enabled during driver load
URL : https://patchwork.freedesktop.org/series/103458/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_103458v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103458v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103458v1_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 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103458v1_full:
### IGT changes ###
Possible regressions
* igt@i915_suspend@forcewake:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-skl4/igt@i915_susp...@forcewake.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/shard-skl10/igt@i915_susp...@forcewake.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@reset-stress:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/shard-rkl-5/igt@gem_...@reset-stress.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}:[FAIL][4] ([i915#2842]) -> [FAIL][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-rkl-5/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/shard-rkl-2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_suspend@basic-s0@smem:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][6] +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/shard-dg1-12/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/shard-tglu-1/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
Known issues
Here are the changes found in Patchwork_103458v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([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],
[FAIL][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], [PASS][52], [PASS][53],
[PASS][54], [PASS][55], [PASS][56], [PASS][57]) ([i915#4392])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk9/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk9/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk8/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk8/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk7/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk7/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk7/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk6/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk6/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk5/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk5/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk5/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk4/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk4/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk4/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-glk3/boot.html
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Flat-CCS eviction enhancements (rev4)
On 2022-05-02 at 21:39:56 +, Patchwork wrote:
> == Series Details ==
>
> Series: Flat-CCS eviction enhancements (rev4)
> URL : https://patchwork.freedesktop.org/series/102916/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_102916v4_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_102916v4_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_102916v4_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 -> 13)
> --
>
> No changes in participating hosts
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_102916v4_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_eio@wait-wedge-10ms:
> - shard-snb: [PASS][1] -> [INCOMPLETE][2]
This is not related to the change in discussion. Proceeding with the
committing the patches, which(2/3) are ready.
Ram
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-snb5/igt@gem_...@wait-wedge-10ms.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-snb6/igt@gem_...@wait-wedge-10ms.html
>
>
> Warnings
>
> * igt@kms_psr2_su@page_flip-nv12:
> - shard-iclb: [SKIP][3] ([fdo#109642] / [fdo#111068] /
> [i915#658]) -> [FAIL][4] +1 similar issue
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb4/igt@kms_psr2_su@page_flip-nv12.html
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-iclb2/igt@kms_psr2_su@page_flip-nv12.html
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * igt@i915_pm_rpm@system-suspend-devices:
> - {shard-dg1}:NOTRUN -> [INCOMPLETE][5] +1 similar issue
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-dg1-16/igt@i915_pm_...@system-suspend-devices.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_102916v4_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@feature_discovery@display-4x:
> - shard-tglb: NOTRUN -> [SKIP][6] ([i915#1839])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-tglb5/igt@feature_discov...@display-4x.html
>
> * igt@gem_exec_balancer@parallel-keep-in-fence:
> - shard-kbl: NOTRUN -> [DMESG-WARN][7] ([i915#5076] /
> [i915#5614])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-kbl3/igt@gem_exec_balan...@parallel-keep-in-fence.html
>
> * igt@gem_exec_fair@basic-pace-solo@rcs0:
> - shard-kbl: NOTRUN -> [FAIL][8] ([i915#2842])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-kbl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
>
> * igt@gem_exec_fair@basic-pace@vcs0:
> - shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar
> issue
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-iclb5/igt@gem_exec_fair@basic-p...@vcs0.html
>
> * igt@gem_huc_copy@huc-copy:
> - shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190])
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-tglb3/igt@gem_huc_c...@huc-copy.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-tglb6/igt@gem_huc_c...@huc-copy.html
>
> * igt@gem_lmem_swapping@parallel-random:
> - shard-kbl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-kbl3/igt@gem_lmem_swapp...@parallel-random.html
>
> * igt@gem_lmem_swapping@parallel-random-engines:
> - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
> +1 similar issue
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-apl4/igt@gem_lmem_swapp...@parallel-random-engines.html
>
> * igt@gem_softpin@full:
> - shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-skl7/igt@gem_soft...@full.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-skl4/igt@gem_soft...@full.html
>
> * igt@gem_softpin@noreloc-s3:
> - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1
> similar issue
>[17]:
>
[Intel-gfx] ✓ Fi.CI.IGT: success for Make the rest of the VFIO driver interface use vfio_device (rev4)
== Series Details ==
Series: Make the rest of the VFIO driver interface use vfio_device (rev4)
URL : https://patchwork.freedesktop.org/series/102606/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_102606v4_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (13 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102606v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@system-suspend-modeset:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-dg1-12/igt@i915_pm_...@system-suspend-modeset.html
Known issues
Here are the changes found in Patchwork_102606v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_buddy@all@buddy_alloc_smoke:
- shard-skl: [PASS][2] -> [INCOMPLETE][3] ([i915#5800])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-skl9/igt@drm_buddy@all@buddy_alloc_smoke.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-skl7/igt@drm_buddy@all@buddy_alloc_smoke.html
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][4] ([i915#1839])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-tglb6/igt@feature_discov...@display-4x.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][5] ([i915#5076] / [i915#5614])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-kbl6/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-none-rrul@rcs0:
- shard-kbl: [PASS][6] -> [FAIL][7] ([i915#2842])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-kbl1/igt@gem_exec_fair@basic-none-r...@rcs0.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-kbl7/igt@gem_exec_fair@basic-none-r...@rcs0.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_11588/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-apl3/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar
issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-snb: [PASS][12] -> [SKIP][13] ([fdo#109271]) +3 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-snb4/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-snb6/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][14] -> [SKIP][15] ([i915#2190])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-tglb3/igt@gem_huc_c...@huc-copy.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-tglb7/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random:
- shard-kbl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-kbl3/igt@gem_lmem_swapp...@parallel-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-apl8/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_userptr_blits@coherency-unsync:
- shard-tglb: NOTRUN -> [SKIP][18] ([i915#3297])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-tglb6/igt@gem_userptr_bl...@coherency-unsync.html
* igt@gem_userptr_blits@input-checking:
- shard-skl: NOTRUN -> [DMESG-WARN][19] ([i915#4991])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-skl1/igt@gem_userptr_bl...@input-checking.html
* igt@gen7_exec_parse@basic-rejected:
- shard-tglb: NOTRUN -> [SKIP][20] ([fdo#109289])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/shard-tglb6/igt@gen7_exec_pa...@basic-rejected.html
* igt@gen9_exec_parse@allowed-single:
-
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: remove superfluous string helper include (rev4)
== Series Details ==
Series: drm/i915: remove superfluous string helper include (rev4)
URL : https://patchwork.freedesktop.org/series/103086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_103086v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103086v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103086v4_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 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103086v4_full:
### IGT changes ###
Possible regressions
* igt@i915_selftest@mock@requests:
- shard-skl: [PASS][1] -> [INCOMPLETE][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-skl7/igt@i915_selftest@m...@requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-skl1/igt@i915_selftest@m...@requests.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_flush@basic-uc-pro-default:
- {shard-rkl}:[PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-rkl-1/igt@gem_exec_fl...@basic-uc-pro-default.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-rkl-5/igt@gem_exec_fl...@basic-uc-pro-default.html
* igt@gem_exec_suspend@basic-s0@smem:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][5] +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-dg1-13/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_flink_race@flink_close:
- {shard-tglu}: [PASS][6] -> [FAIL][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-tglu-5/igt@gem_flink_race@flink_close.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-tglu-2/igt@gem_flink_race@flink_close.html
* igt@i915_pm_rc6_residency@rc6-idle:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-rkl-5/igt@i915_pm_rc6_reside...@rc6-idle.html
* igt@i915_selftest@mock@memory_region:
- {shard-rkl}:[PASS][9] -> [DMESG-FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-rkl-1/igt@i915_selftest@mock@memory_region.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-rkl-5/igt@i915_selftest@mock@memory_region.html
Known issues
Here are the changes found in Patchwork_103086v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#1839])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-tglb5/igt@feature_discov...@display-4x.html
* igt@gem_ctx_persistence@many-contexts:
- shard-tglb: [PASS][12] -> [FAIL][13] ([i915#2410])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-tglb3/igt@gem_ctx_persiste...@many-contexts.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][14] ([i915#5076] / [i915#5614])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-kbl6/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][15] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-kbl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][18] -> [FAIL][19] ([i915#2849])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/shard-iclb6/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-snb: [PASS][20] -> [SKIP][21] ([fdo#109271]) +2 similar
issues
[20]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
== Series Details ==
Series: drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
URL : https://patchwork.freedesktop.org/series/103461/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11589 -> Patchwork_103461v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103461v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103461v1, 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_103461v1/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-pnv-d510
Missing(2): fi-bsw-cyan bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103461v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@memory_region:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2] +29 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-cfl-8109u/igt@i915_selftest@live@memory_region.html
Known issues
Here are the changes found in Patchwork_103461v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][3] -> [DMESG-FAIL][4] ([i915#62])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_lrc:
- fi-bsw-n3050: [PASS][5] -> [DMESG-FAIL][6] ([i915#2373])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-bsw-n3050/igt@i915_selftest@live@gt_lrc.html
* igt@i915_selftest@live@gtt:
- fi-bdw-5557u: [PASS][7] -> [DMESG-FAIL][8] ([i915#3674])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#62]) +15 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11589/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
* igt@prime_vgem@basic-userptr:
- fi-pnv-d510:NOTRUN -> [SKIP][11] ([fdo#109271]) +40 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/fi-pnv-d510/igt@prime_v...@basic-userptr.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#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2373]: https://gitlab.freedesktop.org/drm/intel/issues/2373
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3674]: https://gitlab.freedesktop.org/drm/intel/issues/3674
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
Build changes
-
* Linux: CI_DRM_11589 -> Patchwork_103461v1
CI-20190529: 20190529
CI_DRM_11589: 1edbec0199f3254f1bcf585b3865452d4c931c3d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6464: eddc67c5c85b8ee6eb4d13752ca43da5073dc985 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_103461v1: 1edbec0199f3254f1bcf585b3865452d4c931c3d @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
934af673eb23 drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103461v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
== Series Details == Series: drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend URL : https://patchwork.freedesktop.org/series/103461/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 10/11] drm/i915/pvc: skip all copy engines from aux table invalidate
On Mon, May 02, 2022 at 09:34:16AM -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> As we have more copy engines now, mask all of them from aux table
> invalidate.
>
> Cc: Prathap Kumar Valsan
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 0de17b568b41..f262aed94ef3 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -275,7 +275,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
> mode)
> if (!HAS_FLAT_CCS(rq->engine->i915) &&
> (rq->engine->class == VIDEO_DECODE_CLASS ||
>rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
> - aux_inv = rq->engine->mask & ~BIT(BCS0);
> + aux_inv = rq->engine->mask & ~GENMASK(BCS8, BCS0);
If we had defined I915_MAX_BCS earlier.
We use ~GENMASK(BCS0 + I915_MAX_BCS - 1, BCS0), so we don't need to
change this with the number of instances.
Otherwise looks good to me.
Reviewed-by: Prathap Kumar Valsan
> if (aux_inv)
> cmd += 4;
> }
> --
> 2.35.1
>
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Introduce Ponte Vecchio
== Series Details ==
Series: i915: Introduce Ponte Vecchio
URL : https://patchwork.freedesktop.org/series/103443/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_103443v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103443v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103443v1_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 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103443v1_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@system-suspend-modeset:
- shard-kbl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-kbl4/igt@i915_pm_...@system-suspend-modeset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-kbl6/igt@i915_pm_...@system-suspend-modeset.html
* {igt@kms_concurrent@pipe-b@hdmi-a-3} (NEW):
- {shard-dg1}:NOTRUN -> [CRASH][3] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-dg1-18/igt@kms_concurrent@pip...@hdmi-a-3.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw:
- shard-tglb: [PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-tglb8/igt@kms_frontbuffer_track...@fbcpsr-1p-pri-indfb-multidraw.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@gem-evict-pwrite:
- {shard-rkl}:[PASS][6] -> [INCOMPLETE][7] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-rkl-5/igt@i915_pm_...@gem-evict-pwrite.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-rkl-5/igt@i915_pm_...@gem-evict-pwrite.html
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][8] +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-dg1-18/igt@i915_pm_...@system-suspend-devices.html
* igt@i915_selftest@live:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-rkl-5/igt@i915_selft...@live.html
New tests
-
New tests have been introduced between CI_DRM_11588_full and
Patchwork_103443v1_full:
### New IGT tests (2) ###
* igt@kms_concurrent@pipe-a@hdmi-a-3:
- Statuses : 1 crash(s)
- Exec time: [0.03] s
* igt@kms_concurrent@pipe-b@hdmi-a-3:
- Statuses : 1 crash(s)
- Exec time: [0.04] s
Known issues
Here are the changes found in Patchwork_103443v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@blit-reloc-keep-cache:
- shard-skl: [PASS][10] -> [DMESG-WARN][11] ([i915#1982])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-skl7/igt@api_intel...@blit-reloc-keep-cache.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-skl6/igt@api_intel...@blit-reloc-keep-cache.html
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][12] ([i915#1839])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-tglb1/igt@feature_discov...@display-4x.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][13] ([i915#5076] / [i915#5614])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-kbl4/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-apl1/igt@gem_exec_fair@basic-n...@vecs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2842]) +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_flush@basic-batch-kernel-default-uc:
- shard-snb: [PASS][18] -> [SKIP][19] ([fdo#109271]) +3
Re: [Intel-gfx] [PATCH 02/11] drm/i915/pvc: Add forcewake support
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> Add PVC's forcewake ranges.
>
> Bspec: 67609
> Cc: Daniele Ceraolo Spurio
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 150
> +-
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +
> 2 files changed, 151 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 83517a703eb6..3352065635e8 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1080,6 +1080,45 @@ static const struct i915_range
> dg2_shadowed_regs[] = {
> { .start = 0x1F8510, .end = 0x1F8550 },
> };
>
> +static const struct i915_range pvc_shadowed_regs[] = {
> + { .start = 0x2030, .end = 0x2030 },
> + { .start = 0x2510, .end = 0x2550 },
> + { .start = 0xA008, .end = 0xA00C },
> + { .start = 0xA188, .end = 0xA188 },
> + { .start = 0xA278, .end = 0xA278 },
> + { .start = 0xA540, .end = 0xA56C },
> + { .start = 0xC4C8, .end = 0xC4C8 },
> + { .start = 0xC4E0, .end = 0xC4E0 },
> + { .start = 0xC600, .end = 0xC600 },
> + { .start = 0xC658, .end = 0xC658 },
> + { .start = 0x22030, .end = 0x22030 },
> + { .start = 0x22510, .end = 0x22550 },
> + { .start = 0x1C0030, .end = 0x1C0030 },
> + { .start = 0x1C0510, .end = 0x1C0550 },
> + { .start = 0x1C4030, .end = 0x1C4030 },
> + { .start = 0x1C4510, .end = 0x1C4550 },
> + { .start = 0x1C8030, .end = 0x1C8030 },
> + { .start = 0x1C8510, .end = 0x1C8550 },
> + { .start = 0x1D0030, .end = 0x1D0030 },
> + { .start = 0x1D0510, .end = 0x1D0550 },
> + { .start = 0x1D4030, .end = 0x1D4030 },
> + { .start = 0x1D4510, .end = 0x1D4550 },
> + { .start = 0x1D8030, .end = 0x1D8030 },
> + { .start = 0x1D8510, .end = 0x1D8550 },
> + { .start = 0x1E0030, .end = 0x1E0030 },
> + { .start = 0x1E0510, .end = 0x1E0550 },
> + { .start = 0x1E4030, .end = 0x1E4030 },
> + { .start = 0x1E4510, .end = 0x1E4550 },
> + { .start = 0x1E8030, .end = 0x1E8030 },
> + { .start = 0x1E8510, .end = 0x1E8550 },
> + { .start = 0x1F0030, .end = 0x1F0030 },
> + { .start = 0x1F0510, .end = 0x1F0550 },
> + { .start = 0x1F4030, .end = 0x1F4030 },
> + { .start = 0x1F4510, .end = 0x1F4550 },
> + { .start = 0x1F8030, .end = 0x1F8030 },
> + { .start = 0x1F8510, .end = 0x1F8550 },
> +};
> +
> static int mmio_range_cmp(u32 key, const struct i915_range *range)
> {
> if (key < range->start)
> @@ -1490,6 +1529,111 @@ static const struct intel_forcewake_range
> __dg2_fw_ranges[] = {
> XEHP_FWRANGES(FORCEWAKE_RENDER)
> };
>
> +/*
> + * *Must* be sorted by offset ranges! See intel_fw_table_check().
> + *
> + * Note that the spec lists several reserved/unused ranges that
> don't actually
> + * contain any registers. In the table below we'll combine those
> reserved
> + * ranges with either the preceding or following range to keep the
> table small
Looks like not just the reserved ranges are being used here. Maybe add
"combine all ranges with preceding or following range with similar FW
unit" or something similar.
Thanks,
Stuart
> + * and lookups fast.
> + */
> +static const struct intel_forcewake_range __pvc_fw_ranges[] = {
> + GEN_FW_RANGE(0x0, 0xaff, 0),
> + GEN_FW_RANGE(0xb00, 0xbff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0xc00, 0xfff, 0),
> + GEN_FW_RANGE(0x1000, 0x1fff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0x2000, 0x26ff, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x2700, 0x2fff, FORCEWAKE_GT),
> + GEN_FW_RANGE(0x3000, 0x3fff, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x4000, 0x813f, FORCEWAKE_GT), /*
> + 0x4000 - 0x4aff: gt
> + 0x4b00 - 0x4fff: reserved
> + 0x5000 - 0x51ff: gt
> + 0x5200 - 0x52ff: reserved
> + 0x5300 - 0x53ff: gt
> + 0x5400 - 0x7fff: reserved
> + 0x8000 - 0x813f: gt */
> + GEN_FW_RANGE(0x8140, 0x817f, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x8180, 0x81ff, 0),
> + GEN_FW_RANGE(0x8200, 0x94cf, FORCEWAKE_GT), /*
> + 0x8200 - 0x82ff: gt
> + 0x8300 - 0x84ff: reserved
> + 0x8500 - 0x887f: gt
> + 0x8880 - 0x8a7f: reserved
> + 0x8a80 - 0x8aff: gt
> + 0x8b00 - 0x8fff: reserved
> + 0x9000 - 0x947f: gt
> + 0x9480 - 0x94cf: reserved */
> + GEN_FW_RANGE(0x94d0, 0x955f, FORCEWAKE_RENDER),
> + GEN_FW_RANGE(0x9560, 0x967f, 0), /*
> + 0x9560 - 0x95ff: always on
> + 0x9600 - 0x967f: reserved */
> + GEN_FW_RANGE(0x9680, 0x97ff, FORCEWAKE_RENDER), /*
> + 0x9680 - 0x96ff: render
> + 0x9700 - 0x97ff: reserved */
> + GEN_FW_RANGE(0x9800, 0xcfff, FORCEWAKE_GT), /*
> + 0x9800 - 0xb4ff: gt
> + 0xb500 - 0xbfff: reserved
> +
Re: [Intel-gfx] [PATCH 08/11] drm/i915/pvc: Interrupt support for new copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote: > This patch adds the interrupt handler support for Imperative: Add the interrupt support for... Otherwise: Reviewed-by: Stuart Summers > new copy engines. > > Bspec: 54030 > Original-author: CQ Tang > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_gt_irq.c | 16 > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 > 2 files changed, 20 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c > b/drivers/gpu/drm/i915/gt/intel_gt_irq.c > index 88b4becfcb17..3a72d4fd0214 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c > @@ -193,6 +193,14 @@ void gen11_gt_irq_reset(struct intel_gt *gt) > /* Restore masks irqs on RCS, BCS, VCS and VECS engines. */ > intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~0); > intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK,~0); > + if (HAS_ENGINE(gt, BCS1) || HAS_ENGINE(gt, BCS2)) > + intel_uncore_write(uncore, XEHPC_BCS1_BCS2_INTR_MASK, > ~0); > + if (HAS_ENGINE(gt, BCS3) || HAS_ENGINE(gt, BCS4)) > + intel_uncore_write(uncore, XEHPC_BCS3_BCS4_INTR_MASK, > ~0); > + if (HAS_ENGINE(gt, BCS5) || HAS_ENGINE(gt, BCS6)) > + intel_uncore_write(uncore, XEHPC_BCS5_BCS6_INTR_MASK, > ~0); > + if (HAS_ENGINE(gt, BCS7) || HAS_ENGINE(gt, BCS8)) > + intel_uncore_write(uncore, XEHPC_BCS7_BCS8_INTR_MASK, > ~0); > intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~0); > intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~0); > if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5)) > @@ -248,6 +256,14 @@ void gen11_gt_irq_postinstall(struct intel_gt > *gt) > /* Unmask irqs on RCS, BCS, VCS and VECS engines. */ > intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask); > intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK, ~smask); > + if (HAS_ENGINE(gt, BCS1) || HAS_ENGINE(gt, BCS2)) > + intel_uncore_write(uncore, XEHPC_BCS1_BCS2_INTR_MASK, > ~dmask); > + if (HAS_ENGINE(gt, BCS3) || HAS_ENGINE(gt, BCS4)) > + intel_uncore_write(uncore, XEHPC_BCS3_BCS4_INTR_MASK, > ~dmask); > + if (HAS_ENGINE(gt, BCS5) || HAS_ENGINE(gt, BCS6)) > + intel_uncore_write(uncore, XEHPC_BCS5_BCS6_INTR_MASK, > ~dmask); > + if (HAS_ENGINE(gt, BCS7) || HAS_ENGINE(gt, BCS8)) > + intel_uncore_write(uncore, XEHPC_BCS7_BCS8_INTR_MASK, > ~dmask); > intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~dmask); > intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~dmask); > if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5)) > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index aa2c0974b02c..fe09288a3145 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -1529,6 +1529,10 @@ > #define GEN11_GUNIT_CSME_INTR_MASK _MMIO(0x1900f4) > #define GEN12_CCS0_CCS1_INTR_MASK_MMIO(0x190100) > #define GEN12_CCS2_CCS3_INTR_MASK_MMIO(0x190104) > +#define XEHPC_BCS1_BCS2_INTR_MASK_MMIO(0x190110) > +#define XEHPC_BCS3_BCS4_INTR_MASK_MMIO(0x190114) > +#define XEHPC_BCS5_BCS6_INTR_MASK_MMIO(0x190118) > +#define XEHPC_BCS7_BCS8_INTR_MASK_MMIO(0x19011c) > > #define GEN12_SFC_DONE(n)_MMIO(0x1cc000 + (n) * > 0x1000) >
Re: [Intel-gfx] [PATCH 09/11] drm/i915/pvc: Reset support for new copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the reset support for new copy engines
> in PVC.
>
> Bspec: 52549
> Original-author: CQ Tang
> Signed-off-by: Matt Roper
Reviewed-by: Stuart Summers
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 44 +--
>
> 2 files changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 4532c3ea9ace..c6e93db134b1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -390,6 +390,14 @@ static u32 get_reset_domain(u8 ver, enum
> intel_engine_id id)
> static const u32 engine_reset_domains[] = {
> [RCS0] = GEN11_GRDOM_RENDER,
> [BCS0] = GEN11_GRDOM_BLT,
> + [BCS1] = XEHPC_GRDOM_BLT1,
> + [BCS2] = XEHPC_GRDOM_BLT2,
> + [BCS3] = XEHPC_GRDOM_BLT3,
> + [BCS4] = XEHPC_GRDOM_BLT4,
> + [BCS5] = XEHPC_GRDOM_BLT5,
> + [BCS6] = XEHPC_GRDOM_BLT6,
> + [BCS7] = XEHPC_GRDOM_BLT7,
> + [BCS8] = XEHPC_GRDOM_BLT8,
> [VCS0] = GEN11_GRDOM_MEDIA,
> [VCS1] = GEN11_GRDOM_MEDIA2,
> [VCS2] = GEN11_GRDOM_MEDIA3,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index fe09288a3145..98ede9c93f00 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -597,24 +597,32 @@
> /* GEN11 changed all bit defs except for FULL & RENDER */
> #define GEN11_GRDOM_FULL GEN6_GRDOM_FULL
> #define GEN11_GRDOM_RENDER GEN6_GRDOM_RENDER
> -#define GEN11_GRDOM_BLT(1 << 2)
> -#define GEN11_GRDOM_GUC(1 << 3)
> -#define GEN11_GRDOM_MEDIA (1 << 5)
> -#define GEN11_GRDOM_MEDIA2 (1 << 6)
> -#define GEN11_GRDOM_MEDIA3 (1 << 7)
> -#define GEN11_GRDOM_MEDIA4 (1 << 8)
> -#define GEN11_GRDOM_MEDIA5 (1 << 9)
> -#define GEN11_GRDOM_MEDIA6 (1 << 10)
> -#define GEN11_GRDOM_MEDIA7 (1 << 11)
> -#define GEN11_GRDOM_MEDIA8 (1 << 12)
> -#define GEN11_GRDOM_VECS (1 << 13)
> -#define GEN11_GRDOM_VECS2 (1 << 14)
> -#define GEN11_GRDOM_VECS3 (1 << 15)
> -#define GEN11_GRDOM_VECS4 (1 << 16)
> -#define GEN11_GRDOM_SFC0 (1 << 17)
> -#define GEN11_GRDOM_SFC1 (1 << 18)
> -#define GEN11_GRDOM_SFC2 (1 << 19)
> -#define GEN11_GRDOM_SFC3 (1 << 20)
> +#define XEHPC_GRDOM_BLT8 REG_BIT(31)
> +#define XEHPC_GRDOM_BLT7 REG_BIT(30)
> +#define XEHPC_GRDOM_BLT6 REG_BIT(29)
> +#define XEHPC_GRDOM_BLT5 REG_BIT(28)
> +#define XEHPC_GRDOM_BLT4 REG_BIT(27)
> +#define XEHPC_GRDOM_BLT3 REG_BIT(26)
> +#define XEHPC_GRDOM_BLT2 REG_BIT(25)
> +#define XEHPC_GRDOM_BLT1 REG_BIT(24)
> +#define GEN11_GRDOM_SFC3 REG_BIT(20)
> +#define GEN11_GRDOM_SFC2 REG_BIT(19)
> +#define GEN11_GRDOM_SFC1 REG_BIT(18)
> +#define GEN11_GRDOM_SFC0 REG_BIT(17)
> +#define GEN11_GRDOM_VECS4 REG_BIT(16)
> +#define GEN11_GRDOM_VECS3 REG_BIT(15)
> +#define GEN11_GRDOM_VECS2 REG_BIT(14)
> +#define GEN11_GRDOM_VECS REG_BIT(13)
> +#define GEN11_GRDOM_MEDIA8 REG_BIT(12)
> +#define GEN11_GRDOM_MEDIA7 REG_BIT(11)
> +#define GEN11_GRDOM_MEDIA6 REG_BIT(10)
> +#define GEN11_GRDOM_MEDIA5 REG_BIT(9)
> +#define GEN11_GRDOM_MEDIA4 REG_BIT(8)
> +#define GEN11_GRDOM_MEDIA3 REG_BIT(7)
> +#define GEN11_GRDOM_MEDIA2 REG_BIT(6)
> +#define GEN11_GRDOM_MEDIA REG_BIT(5)
> +#define GEN11_GRDOM_GUCREG_BIT(3)
> +#define GEN11_GRDOM_BLTREG_BIT(2)
> #define GEN11_VCS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 <<
> ((instance) >> 1))
> #define GEN11_VECS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 <<
> (instance))
>
[Intel-gfx] [PATCH] drm/i915/reset: Add Wa_22011802037 for gen11 and execlist backend
Current implementation of Wa_22011802037 is limited to the GuC backend
and gen12. Add support for execlist backend and gen11 as well.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine.h| 2 +
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 81 ++-
.../drm/i915/gt/intel_execlists_submission.c | 7 ++
.../gpu/drm/i915/gt/intel_ring_submission.c | 7 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 4 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 81 ++-
6 files changed, 103 insertions(+), 79 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 1431f1e9dbee..04e435bce79b 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -201,6 +201,8 @@ int intel_ring_submission_setup(struct intel_engine_cs
*engine);
int intel_engine_stop_cs(struct intel_engine_cs *engine);
void intel_engine_cancel_stop_cs(struct intel_engine_cs *engine);
+void intel_engine_wait_for_pending_mi_fw(struct intel_engine_cs *engine);
+
void intel_engine_set_hwsp_writemask(struct intel_engine_cs *engine, u32 mask);
u64 intel_engine_get_active_head(const struct intel_engine_cs *engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 14c6ddbbfde8..0bda665a407c 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1282,10 +1282,10 @@ static int __intel_engine_stop_cs(struct
intel_engine_cs *engine,
intel_uncore_write_fw(uncore, mode, _MASKED_BIT_ENABLE(STOP_RING));
/*
-* Wa_22011802037 : gen12, Prior to doing a reset, ensure CS is
+* Wa_22011802037 : gen11, gen12, Prior to doing a reset, ensure CS is
* stopped, set ring stop bit and prefetch disable bit to halt CS
*/
- if (GRAPHICS_VER(engine->i915) == 12)
+ if (GRAPHICS_VER(engine->i915) == 11 || GRAPHICS_VER(engine->i915) ==
12)
intel_uncore_write_fw(uncore, RING_MODE_GEN7(engine->mmio_base),
_MASKED_BIT_ENABLE(GEN12_GFX_PREFETCH_DISABLE));
@@ -1308,6 +1308,14 @@ int intel_engine_stop_cs(struct intel_engine_cs *engine)
return -ENODEV;
ENGINE_TRACE(engine, "\n");
+ /*
+* TODO: Occasionally trying to stop the cs times out, but does not
+* adversely affect functionality. The timeout is set as a config
+* parameter that defaults to 100ms. Assuming that this timeout is
+* sufficient for any pending MI_FORCEWAKEs to complete. Once root
+* caused, the caller must check and handler the return from this
+* function.
+*/
if (__intel_engine_stop_cs(engine, 1000, stop_timeout(engine))) {
ENGINE_TRACE(engine,
"timed out on STOP_RING -> IDLE; HEAD:%04x,
TAIL:%04x\n",
@@ -1334,6 +1342,75 @@ void intel_engine_cancel_stop_cs(struct intel_engine_cs
*engine)
ENGINE_WRITE_FW(engine, RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
}
+static u32 __cs_pending_mi_force_wakes(struct intel_engine_cs *engine)
+{
+ static const i915_reg_t _reg[I915_NUM_ENGINES] = {
+ [RCS0] = MSG_IDLE_CS,
+ [BCS0] = MSG_IDLE_BCS,
+ [VCS0] = MSG_IDLE_VCS0,
+ [VCS1] = MSG_IDLE_VCS1,
+ [VCS2] = MSG_IDLE_VCS2,
+ [VCS3] = MSG_IDLE_VCS3,
+ [VCS4] = MSG_IDLE_VCS4,
+ [VCS5] = MSG_IDLE_VCS5,
+ [VCS6] = MSG_IDLE_VCS6,
+ [VCS7] = MSG_IDLE_VCS7,
+ [VECS0] = MSG_IDLE_VECS0,
+ [VECS1] = MSG_IDLE_VECS1,
+ [VECS2] = MSG_IDLE_VECS2,
+ [VECS3] = MSG_IDLE_VECS3,
+ [CCS0] = MSG_IDLE_CS,
+ [CCS1] = MSG_IDLE_CS,
+ [CCS2] = MSG_IDLE_CS,
+ [CCS3] = MSG_IDLE_CS,
+ };
+ u32 val;
+
+ if (!_reg[engine->id].reg)
+ return 0;
+
+ val = intel_uncore_read(engine->uncore, _reg[engine->id]);
+
+ /* bits[29:25] & bits[13:9] >> shift */
+ return (val & (val >> 16) & MSG_IDLE_FW_MASK) >> MSG_IDLE_FW_SHIFT;
+}
+
+static void __gpm_wait_for_fw_complete(struct intel_gt *gt, u32 fw_mask)
+{
+ int ret;
+
+ /* Ensure GPM receives fw up/down after CS is stopped */
+ udelay(1);
+
+ /* Wait for forcewake request to complete in GPM */
+ ret = __intel_wait_for_register_fw(gt->uncore,
+ GEN9_PWRGT_DOMAIN_STATUS,
+ fw_mask, fw_mask, 5000, 0, NULL);
+
+ /* Ensure CS receives fw ack from GPM */
+ udelay(1);
+
+ if (ret)
+ GT_TRACE(gt, "Failed to complete pending forcewake %d\n", ret);
+}
+
+/*
+ * Wa_22011802037:gen12: In addition to stopping the cs, we need to wait
[Intel-gfx] ✗ Fi.CI.IGT: failure for Flat-CCS eviction enhancements (rev4)
== Series Details ==
Series: Flat-CCS eviction enhancements (rev4)
URL : https://patchwork.freedesktop.org/series/102916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11588_full -> Patchwork_102916v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102916v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102916v4_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 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102916v4_full:
### IGT changes ###
Possible regressions
* igt@gem_eio@wait-wedge-10ms:
- shard-snb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-snb5/igt@gem_...@wait-wedge-10ms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-snb6/igt@gem_...@wait-wedge-10ms.html
Warnings
* igt@kms_psr2_su@page_flip-nv12:
- shard-iclb: [SKIP][3] ([fdo#109642] / [fdo#111068] / [i915#658])
-> [FAIL][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb4/igt@kms_psr2_su@page_flip-nv12.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-iclb2/igt@kms_psr2_su@page_flip-nv12.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][5] +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-dg1-16/igt@i915_pm_...@system-suspend-devices.html
Known issues
Here are the changes found in Patchwork_102916v4_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-tglb: NOTRUN -> [SKIP][6] ([i915#1839])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-tglb5/igt@feature_discov...@display-4x.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][7] ([i915#5076] / [i915#5614])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-kbl3/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-kbl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-iclb5/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-tglb: [PASS][11] -> [SKIP][12] ([i915#2190])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-tglb3/igt@gem_huc_c...@huc-copy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-tglb6/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random:
- shard-kbl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-kbl3/igt@gem_lmem_swapp...@parallel-random.html
* igt@gem_lmem_swapping@parallel-random-engines:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1
similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-apl4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_softpin@full:
- shard-skl: [PASS][15] -> [DMESG-WARN][16] ([i915#1982])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-skl7/igt@gem_soft...@full.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-skl4/igt@gem_soft...@full.html
* igt@gem_softpin@noreloc-s3:
- shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/shard-apl7/igt@gem_soft...@noreloc-s3.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-apl3/igt@gem_soft...@noreloc-s3.html
* igt@gem_userptr_blits@coherency-unsync:
- shard-tglb: NOTRUN -> [SKIP][19] ([i915#3297])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/shard-tglb5/igt@gem_userptr_bl...@coherency-unsync.html
*
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/display: Allow DRRS to be enabled during driver load
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display: Allow DRRS to be
enabled during driver load
URL : https://patchwork.freedesktop.org/series/103458/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11588 -> Patchwork_103458v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/index.html
Participating hosts (44 -> 42)
--
Additional (1): bat-dg2-8
Missing(3): bat-rpls-1 bat-adlm-1 fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103458v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html
Known issues
Here are the changes found in Patchwork_103458v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][2] ([fdo#109271] / [fdo#111827])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][4] ([i915#5122]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [DMESG-FAIL][6] -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][8] ([i915#4785]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[INCOMPLETE][10] ([i915#3921]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- {fi-tgl-dsi}: [INCOMPLETE][12] -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/fi-tgl-dsi/igt@i915_selftest@l...@migrate.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_11588/bat-adlp-6/igt@kms_busy@ba...@modeset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103458v1/bat-adlp-6/igt@kms_busy@ba...@modeset.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#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[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#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[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]:
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 02:03:28PM -0700, Lucas De Marchi wrote:
> On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
> > From: Ayaz A Siddiqui
...
> > @@ -2002,11 +2002,18 @@ engine_fake_wa_init(struct intel_engine_cs *engine,
> > struct i915_wa_list *wal)
> > * Streamers on Gen12 onward platforms.
> > */
> > if (GRAPHICS_VER(engine->i915) >= 12) {
> > - mocs = engine->gt->mocs.uc_index;
> > + if (HAS_L3_CCS_READ(engine->i915) &&
> > + engine->class == COMPUTE_CLASS)
> > + mocs_r = engine->gt->mocs.wb_index;
> > + else
> > + mocs_r = engine->gt->mocs.uc_index;
>
> shouldn't we add a warning in get_mocs_settings() if
> HAS_L3_CCS_READ(engine->i915)
> and mocs.wb_index is 0 (since index 0 shouldn't really be used in latest
> platforms)?
We should be careful about that assumption...index 0 is valid on DG2
today, although HAS_L3_CCS_READ() doesn't apply there. And a couple
platforms in the future we're also going to have index 0 being valid on
a platform where HAS_L3_CCS_READ() is true (bspec 71582). Index 0 would
still be the wrong entry to pick for WB behavior there, but it is a
legitimate entry in general.
Matt
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
From: Ayaz A Siddiqui
Bspec: 45101, 72161
Signed-off-by: Ayaz A Siddiqui
Signed-off-by: Fei Yang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h| 1 +
6 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index b06611c1d4ad..7853ea194ea6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -221,6 +221,7 @@ struct intel_gt {
struct {
u8 uc_index;
+ u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
I don't like much writting the bspec in code like this. For commit
message it's acceptable/desired, but for code I think it's not great as
1) it's not something generally available and 2) it will likely get
outdated so one would have to rely on git log/blame to see when this was
actually valid.
} mocs;
struct intel_pxp pxp;
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index c4c37585ae8c..265812589f87 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
unsigned int n_entries;
const struct drm_i915_mocs_entry *table;
u8 uc_index;
+ u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
u8 unused_entries_index;
};
@@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
+#define PVC_NUM_MOCS_ENTRIES 3
/* (e)LLC caching options */
/*
@@ -394,6 +396,17 @@ static const struct drm_i915_mocs_entry
dg2_mocs_table_g10_ax[] = {
MOCS_ENTRY(3, 0, L3_3_WB | L3_LKUP(1)),
};
+static const struct drm_i915_mocs_entry pvc_mocs_table[] = {
+ /* Error */
+ MOCS_ENTRY(0, 0, L3_3_WB),
+
+ /* UC */
+ MOCS_ENTRY(1, 0, L3_1_UC),
+
+ /* WB */
+ MOCS_ENTRY(2, 0, L3_3_WB),
+};
+
enum {
HAS_GLOBAL_MOCS = BIT(0),
HAS_ENGINE_MOCS = BIT(1),
@@ -423,7 +436,14 @@ static unsigned int get_mocs_settings(const struct
drm_i915_private *i915,
memset(table, 0, sizeof(struct drm_i915_mocs_table));
table->unused_entries_index = I915_MOCS_PTE;
- if (IS_DG2(i915)) {
+ if (IS_PONTEVECCHIO(i915)) {
+ table->size = ARRAY_SIZE(pvc_mocs_table);
+ table->table = pvc_mocs_table;
+ table->n_entries = PVC_NUM_MOCS_ENTRIES;
+ table->uc_index = 1;
+ table->wb_index = 2;
+ table->unused_entries_index = 2;
+ } else if (IS_DG2(i915)) {
if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0)) {
table->size = ARRAY_SIZE(dg2_mocs_table_g10_ax);
table->table = dg2_mocs_table_g10_ax;
@@ -622,6 +642,8 @@ void intel_set_mocs_index(struct intel_gt *gt)
get_mocs_settings(gt->i915, );
gt->mocs.uc_index = table.uc_index;
+ if (HAS_L3_CCS_READ(gt->i915))
+ gt->mocs.wb_index = table.wb_index;
}
void intel_mocs_init(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a05c4b99b3fb..a656d9c2ca2b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1994,7 +1994,7 @@ void intel_engine_apply_whitelist(struct intel_engine_cs
*engine)
static void
engine_fake_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
{
- u8 mocs;
+ u8 mocs_w, mocs_r;
/*
* RING_CMD_CCTL are need to be programed to un-cached
@@ -2002,11 +2002,18 @@ engine_fake_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
* Streamers on Gen12 onward platforms.
*/
if (GRAPHICS_VER(engine->i915) >= 12) {
- mocs = engine->gt->mocs.uc_index;
+ if (HAS_L3_CCS_READ(engine->i915) &&
+ engine->class == COMPUTE_CLASS)
+ mocs_r = engine->gt->mocs.wb_index;
+ else
+ mocs_r = engine->gt->mocs.uc_index;
shouldn't we add a warning in get_mocs_settings() if
HAS_L3_CCS_READ(engine->i915)
and mocs.wb_index is 0 (since index 0 shouldn't really be used in latest
platforms)?
Lucas De Marchi
+
+ mocs_w = engine->gt->mocs.uc_index;
+
wa_masked_field_set(wal,
RING_CMD_CCTL(engine->mmio_base),
Re: [Intel-gfx] [PATCH 01/11] drm/i915/pvc: add initial Ponte Vecchio definitions
On Mon, May 02, 2022 at 09:34:07AM -0700, Matt Roper wrote: From: Stuart Summers Additional blitter and media engines will be enabled later. Bspec: 44481, 44482 Signed-off-by: Stuart Summers Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Lucas De Marchi
[Intel-gfx] [PATCH v2 2/3] drm/i915/display/dp: Try to fallback to previous link config if modeset is not allowed
When an atomic commit has changes that allows it to go to a lower DP
link configuration it will require a modeset but userspace might not
want it, so it would not set the modeset allowed flag causing
commit to fail.
Here in such case it tries to keep previous and trained link
configuration for the new state.
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_dp.c | 86 -
1 file changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index e4a79c11fd255..cc9be82e128f4 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1596,6 +1596,16 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
return ret;
}
+ return 0;
+}
+
+static void
+intel_dp_print_link_config(struct intel_crtc_state *pipe_config)
+{
+ struct drm_i915_private *i915 = to_i915(pipe_config->uapi.crtc->dev);
+ const struct drm_display_mode *adjusted_mode =
+ _config->hw.adjusted_mode;
+
if (pipe_config->dsc.compression_enable) {
drm_dbg_kms(>drm,
"DP lane count %d clock %d Input bpp %d Compressed
bpp %d\n",
@@ -1621,7 +1631,6 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
intel_dp_max_data_rate(pipe_config->port_clock,
pipe_config->lane_count));
}
- return 0;
}
bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
@@ -1915,6 +1924,72 @@ static bool intel_dp_has_audio(struct intel_encoder
*encoder,
return intel_conn_state->force_audio == HDMI_AUDIO_ON;
}
+/*
+ * If modeset is not allowed it checks for link computed state and if different
+ * it checks if is possible to fallback to previous configuration.
+ *
+ * Returns 0 if modeset is allowed, link computed states matches or fallback is
+ * possible otherwise returns a errno.
+ */
+static int
+intel_dp_compute_link_config_no_modeset_fallback(struct intel_crtc_state
*crtc_state)
+{
+ struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
+ struct drm_display_mode *adjusted_mode = _state->hw.adjusted_mode;
+ const struct intel_crtc_state *old_crtc_state;
+ int output_bpp, mode_rate, old_link_avail;
+ struct intel_crtc *crtc;
+
+ if (state->base.allow_modeset)
+ return 0;
+
+ crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
+
+ /* Check if both states matches */
+ if (crtc_state->output_format == old_crtc_state->output_format &&
+ crtc_state->port_clock == old_crtc_state->port_clock &&
+ crtc_state->lane_count == old_crtc_state->lane_count &&
+ crtc_state->pipe_bpp == old_crtc_state->pipe_bpp &&
+ crtc_state->dsc.compression_enable ==
old_crtc_state->dsc.compression_enable &&
+ crtc_state->dsc.compressed_bpp ==
old_crtc_state->dsc.compressed_bpp &&
+ crtc_state->dsc.slice_count == old_crtc_state->dsc.slice_count &&
+ crtc_state->bigjoiner_pipes == old_crtc_state->bigjoiner_pipes)
+ return 0;
+
+ /*
+* Modeset will be required if any of this changed, there is no way
+* around it
+*/
+ if (crtc_state->output_format != old_crtc_state->output_format ||
+ crtc_state->bigjoiner_pipes != old_crtc_state->bigjoiner_pipes ||
+ crtc_state->dsc.compression_enable !=
old_crtc_state->dsc.compression_enable)
+ return -EINVAL;
+
+ /* TODO: Not supporting DSC fallback but it might be possible */
+ if (crtc_state->dsc.compression_enable)
+ return -EINVAL;
+
+ output_bpp = intel_dp_output_bpp(crtc_state->output_format,
+old_crtc_state->pipe_bpp);
+ mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+ output_bpp);
+
+ old_link_avail = intel_dp_max_data_rate(old_crtc_state->port_clock,
+ old_crtc_state->lane_count);
+
+ /* Check if old link configuration has enough bandwidth for new mode */
+ if (mode_rate > old_link_avail)
+ return -EINVAL;
+
+ /* Fallback is possible */
+ crtc_state->lane_count = old_crtc_state->lane_count;
+ crtc_state->pipe_bpp = old_crtc_state->pipe_bpp;
+ crtc_state->port_clock = old_crtc_state->port_clock;
+
+ return 0;
+}
+
static int
intel_dp_compute_output_format(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
@@ -1950,8 +2025,17 @@ intel_dp_compute_output_format(struct intel_encoder
*encoder,
[Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless mode switch
So far the i915's DRRS feature was automatically changing between
preferred panel mode and downclock mode based on idleness but ChromeOS
compositor team is asking to be in control of the mode switch.
So for certain types of content it can switch to a mode with a lower
refresh rate without the user noticing a thing and saving more power.
This seamless mode switch will be triggered when user-space dispatches
an atomic commit with the new mode and clears the
DRM_MODE_ATOMIC_ALLOW_MODESET flag.
The main steps to acomplish that are:
- as mode changed in atomic state drm_atomic_helper_check_modeset()
will set mode_changed and it will trigger the crtc state computation
so intel_dp_compute_config() will be called and dp_m_n will be
computed for the new mode
- then intel_dp_drrs_compute_config() will check for the necessary
conditions to do a seamless mode switch, if possible
crtc_state->seamless_mode_switch will be set and has_drrs will not
be set, so i915 will not automatically switch between modes
- then intel_crtc_compute_config() will call
intel_crtc_compute_pixel_rate() that will take the hint that it is
trying to do a seamless mode switch and set pixel_rate to the
pixel_rate of the old state
- then if nothing else changed in the state intel_crtc_check_fastset()
will be able to set mode_changed to false and i915 can do fastset
otherwise the commit will fail during the check phase
- now on the atomic commit phase, intel_ddi_update_pipe_dp()
will be called and will program the new dp_m_n
- nothing else is different in the commit phase until the step to
verify programmed state, the most important change here is that need
to save the pixel_rate in DRRS global state as there is no other
way to get that from hardware or atomic state
v2:
- not overwritten dp_m_n values in intel_crtc_copy_fastset() when
doing a seamless_mode_switch
Cc: Vidya Srinivas
Cc: Sean Paul
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10 +++
drivers/gpu/drm/i915/display/intel_display.c | 61 ---
.../drm/i915/display/intel_display_debugfs.c | 3 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/display/intel_dp.c | 56 ++---
drivers/gpu/drm/i915/display/intel_drrs.c | 38 +---
drivers/gpu/drm/i915/display/intel_drrs.h | 3 +
7 files changed, 151 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9e6fa59eabba7..732e5d425412e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -46,6 +46,7 @@
#include "intel_dp_link_training.h"
#include "intel_dp_mst.h"
#include "intel_dpio_phy.h"
+#include "intel_drrs.h"
#include "intel_dsi.h"
#include "intel_fdi.h"
#include "intel_fifo_underrun.h"
@@ -3010,6 +3011,14 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_backlight_update(state, encoder, crtc_state, conn_state);
drm_connector_update_privacy_screen(conn_state);
+
+ if (crtc_state->seamless_mode_switch) {
+ struct intel_crtc *intel_crtc =
to_intel_crtc(crtc_state->uapi.crtc);
+
+ intel_cpu_transcoder_set_m1_n1(intel_crtc,
+ crtc_state->cpu_transcoder,
+ _state->dp_m_n);
+ }
}
void intel_ddi_update_pipe(struct intel_atomic_state *state,
@@ -3484,6 +3493,7 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
intel_psr_get_config(encoder, pipe_config);
+ intel_drrs_get_config(encoder, pipe_config);
}
void intel_ddi_get_clock(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 17d0cad9e1686..e54fbe3b1d394 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2629,6 +2629,44 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
else
crtc_state->pixel_rate =
ilk_pipe_pixel_rate(crtc_state);
+
+ /*
+* Do not change pixel_rate when doing seamless mode switch, otherwise
+* it will change port_clock and other stuff that will need a modeset
+* to be programmed
+*/
+ if (crtc_state->seamless_mode_switch) {
+ struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ const struct intel_crtc_state *old_crtc_state;
+
+ old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
+
+ /*
+* It can only seamless switch if pixel rate of the new mode is
+
[Intel-gfx] [PATCH v2 1/3] drm/i915/display: Allow DRRS to be enabled during driver load
When driver takes over display from firmware it does some checks and
if possible it tries to avoid a modeset to improve user boot
experience.
But even if DRRS is supported it was being left disabled as
intel_crtc_copy_fastset() was overwritten new state with the old one
(hardware readout).
So here checking if platform has only one set of m_n registers that
can change on the fly between high and low clock, if yes we can keep
DRRS enabled.
Cc: Vidya Srinivas
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 7 --
drivers/gpu/drm/i915/display/intel_drrs.c| 24
drivers/gpu/drm/i915/display/intel_drrs.h| 2 ++
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0decf3d242372..17d0cad9e1686 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7086,8 +7086,11 @@ static void intel_crtc_copy_fastset(const struct
intel_crtc_state *old_crtc_stat
*/
new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
- new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
- new_crtc_state->has_drrs = old_crtc_state->has_drrs;
+
+ if (!intel_drrs_crtc_copy_fastset(old_crtc_state, new_crtc_state)) {
+ new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
+ new_crtc_state->has_drrs = old_crtc_state->has_drrs;
+ }
}
static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 166caf293f7bc..d266fad83a086 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -300,3 +300,27 @@ void intel_crtc_drrs_init(struct intel_crtc *crtc)
mutex_init(>drrs.mutex);
crtc->drrs.cpu_transcoder = INVALID_TRANSCODER;
}
+
+/**
+ * intel_drrs_crtc_copy_fastset - Handles crtc state copy during fastsets when
+ * new state has DRRS.
+ * @old_crtc_state: old crtc state
+ * @new_crtc_state: new crtc state
+ *
+ * Handle crtc state copy during fastsets trying to keep DRRS enabled.
+ * That can be done in platforms that supports change the dp_m_n register on
+ * the fly between high and low clocks.
+ *
+ * Returns true if crtc copy was already handled otherwise returns false.
+ */
+bool intel_drrs_crtc_copy_fastset(const struct intel_crtc_state
*old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(old_crtc_state->uapi.crtc->dev);
+
+ /* m2_n2 register needs to already be set */
+ if (intel_cpu_transcoder_has_m2_n2(i915,
new_crtc_state->cpu_transcoder))
+ return false;
+
+ return true;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.h
b/drivers/gpu/drm/i915/display/intel_drrs.h
index 3ad1be1ad9c13..749ac717db063 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.h
+++ b/drivers/gpu/drm/i915/display/intel_drrs.h
@@ -24,5 +24,7 @@ void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
void intel_drrs_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits);
void intel_crtc_drrs_init(struct intel_crtc *crtc);
+bool intel_drrs_crtc_copy_fastset(const struct intel_crtc_state
*old_crtc_state,
+ struct intel_crtc_state *new_crtc_state);
#endif /* __INTEL_DRRS_H__ */
--
2.36.0
Re: [Intel-gfx] [PATCH] i915/guc/reset: Make __guc_reset_context aware of guilty engines
On Thu, Apr 28, 2022 at 09:13:57AM -0700, Teres Alexis, Alan Previn wrote:
At a high level, this change looks good and simple.
However, inside __guc_reset_context, i think there might be
an observed change in behavior for parallel submission.
(or perhaps this change is part the intent?):
Unless my understanding is incorrect, assuming a
parallel submission comes in with virtual engines that
repeat the same kinds of workloads across multiple
physical engines (which i assume would be the typical
end-user usage of this UAPI feature), we would end up
marking the parent content (and other children contexts
that use the same engine) as guilty but not children
contexts that are running on a different engine.
I'm not sure if this would be an expected UAPI response
for parallel submission. (i.e. one or more children
get a re-run on other engines? I havent checked if
the replay is revoked later if the parent's or sibling's
'request' was reset and marked as -EIO ... this marking
of req->force_error as -EIO or -EAGAIN is part of the
call to __i915_request_reset where the guilty param
value sees this change i am referring to).
Is this intended / expected?
Expectation: For virtual engine, only the virtual context must be marked
guilty. For parallel engines, parent/child contexts must be marked as
guilty.
Looking into the code, I see the expected behavior is already taken care
of.
For virtual engines, only one context is created with a mask of engines
that can be used by GuC. This context is registered with GuC and the
workloads are run on any one of these engines. When a reset occurs, the
G2H notification points to this context. When the __guc_reset_context
executes, it will only mark this context as guilty.
fwiu, for parallel submission, if N engines can run in parallel, then N
contexts are submitted. If there are no siblings, then there is only one
parent and the below reset logic works fine because G2H has only the
parent context.
If there are more than 1 siblings in parallel submission, then the
execution between siblings is just treated like virtual engines where
the parent has the mask of engines used. In this case, G2H points to
parent context and parent has a mask of all sibling engines, so this
works as expected too (in __guc_reset_context).
Thanks,
Umesh
...alan
On Mon, 2022-04-25 at 17:30 -0700, Umesh Nerlige Ramappa wrote:
There are 2 ways an engine can get reset in i915 and the method of reset
affects how KMD labels a context as guilty/innocent.
(1) GuC initiated engine-reset: GuC resets a hung engine and notifies
KMD. The context that hung on the engine is marked guilty and all other
contexts are innocent. The innocent contexts are resubmitted.
(2) GT based reset: When an engine heartbeat fails to tick, KMD
initiates a gt/chip reset. All active contexts are marked as guilty and
discarded.
In order to correctly mark the contexts as guilty/innocent, pass a mask
of engines that were reset to __guc_reset_context.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_reset.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc.h| 2 +-
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 5422a3b84bd4..a5338c3fde7a 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -808,7 +808,7 @@ static int gt_reset(struct intel_gt *gt,
intel_engine_mask_t stalled_mask)
__intel_engine_reset(engine, stalled_mask & engine->mask);
local_bh_enable();
- intel_uc_reset(>uc, true);
+ intel_uc_reset(>uc, ALL_ENGINES);
intel_ggtt_restore_fences(gt->ggtt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 3f3373f68123..966e69a8b1c1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -443,7 +443,7 @@ int intel_guc_global_policies_update(struct intel_guc *guc);
void intel_guc_context_ban(struct intel_context *ce, struct i915_request *rq);
void intel_guc_submission_reset_prepare(struct intel_guc *guc);
-void intel_guc_submission_reset(struct intel_guc *guc, bool stalled);
+void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
stalled);
void intel_guc_submission_reset_finish(struct intel_guc *guc);
void intel_guc_submission_cancel_requests(struct intel_guc *guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 61a6f2424e24..1fbf7b6c2740 100644
---
[Intel-gfx] i915 Updates: DG2 DMC v2.06
The following changes since commit c3624ebd67c68722e0fabc9cae01397b15310239: Merge branch 'ath10k-20220423' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/linux-firmware into main (2022-05-02 08:31:40 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.06_rebase for you to fetch changes up to b8bd6ccd9c409508a0b424492981721b45c55127: i915: Add DMC v2.06 for DG2 (2022-05-02 22:53:23 +0530) Madhumitha Tolakanahalli Pradeep (1): i915: Add DMC v2.06 for DG2 WHENCE | 3 +++ i915/dg2_dmc_ver2_06.bin | Bin 0 -> 22416 bytes 2 files changed, 3 insertions(+) create mode 100644 i915/dg2_dmc_ver2_06.bin
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 12:27:29PM -0700, Lucas De Marchi wrote:
> On Mon, May 02, 2022 at 11:50:22AM -0700, Matt Roper wrote:
> > On Mon, May 02, 2022 at 11:39:48AM -0700, Lucas De Marchi wrote:
> > > On Mon, May 02, 2022 at 09:50:23AM -0700, Matt Roper wrote:
> > > > On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
> > > > > From: Ayaz A Siddiqui
> > > > >
> > > > > Bspec: 45101, 72161
> > > > > Signed-off-by: Ayaz A Siddiqui
> > > > > Signed-off-by: Fei Yang
> > > > > Signed-off-by: Matt Roper
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > > > > drivers/gpu/drm/i915/gt/intel_mocs.c| 24
> > > > > -
> > > > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
> > > > > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > > > > drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> > > > > drivers/gpu/drm/i915/intel_device_info.h| 1 +
> > > > > 6 files changed, 39 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > > > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > > > index b06611c1d4ad..7853ea194ea6 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > > > @@ -221,6 +221,7 @@ struct intel_gt {
> > > > >
> > > > > struct {
> > > > > u8 uc_index;
> > > > > + u8 wb_index; /* Only for platforms listed in Bspec:
> > > > > 72161 */
> > > > > } mocs;
> > > > >
> > > > > struct intel_pxp pxp;
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > index c4c37585ae8c..265812589f87 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > > > @@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
> > > > > unsigned int n_entries;
> > > > > const struct drm_i915_mocs_entry *table;
> > > > > u8 uc_index;
> > > > > + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> > > > > u8 unused_entries_index;
> > > > > };
> > > > >
> > > > > @@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
> > > > >
> > > > > /* Helper defines */
> > > > > #define GEN9_NUM_MOCS_ENTRIES64 /* 63-64 are reserved, but
> > > > > configured. */
> > > > > +#define PVC_NUM_MOCS_ENTRIES 3
> > > >
> > > > Should this be 4? The value here should reflect the number of entries
> > > > that can defined in hardware rather than the size of the table we're
> > > > asked to program. Since there are two registers (each with a high and a
> > > > low entry), that would imply we should set 4 here to ensure that the
> > > > fourth entry is initialized according to unused_entries_index rather
> > > > than left at whatever the hardware defaults might be.
> > >
> > > not sure I understand what you mean here. The n_entries specifies, as
> > > you said, the number of entries we can have. Bspec 45101 shows entries
> > > for indexes 0, 1 and 2. As does the pvc_mocs_table below.
> > >
> > > Also, from bspec 44509:
> > > "For PVC, only 3 MOCS states are supported. The allowed index values are
> > > in range [0, 2]..."
> > >
> > > So, I don't think we want to program any fourth entry.
> >
> > We don't have a choice; the fourth entry lives in the same register as
> > the third entry, so no matter what we're writing _something_ to those
> > bits. The question is whether we should write all 0's or whether we
> > should treat it like other platforms and ensure it's initialized to the
> > unused entry values. Entry #4 isn't supposed to be used, but if buggy
> > userspace tries to use it, we probably still want well-defined behavior,
> > just like it an invalid entry gets used on any other platform.
>
> Now I understand what you were talking about: each register houses 2
> entries. For PVC we have LNCFCMOCS0 and LNCFCMOCS1. Humn... looking at
> for_each_l3cc(), that is actually handled and the rest of the register
> is initialized with the value pointed by unused_entries_index.
Yep, you're right. It looks like we still do a get_entry_l3cc() for the
upper entry of the final register, and that will return the unused_entry
value if it's out of bounds. In that case I don't have any concerns
here.
Matt
>
> Such situation would only happen for the last entry, which implies the
> handling for odd size works for this as well.
>
> Lucas De Marchi
>
> >
> >
> > Matt
> >
> > >
> > > Lucas De Marchi
> >
> > --
> > Matt Roper
> > Graphics Software Engineer
> > VTT-OSGC Platform Enablement
> > Intel Corporation
> > (916) 356-2795
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 11:50:22AM -0700, Matt Roper wrote:
On Mon, May 02, 2022 at 11:39:48AM -0700, Lucas De Marchi wrote:
On Mon, May 02, 2022 at 09:50:23AM -0700, Matt Roper wrote:
> On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
> > From: Ayaz A Siddiqui
> >
> > Bspec: 45101, 72161
> > Signed-off-by: Ayaz A Siddiqui
> > Signed-off-by: Fei Yang
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
> > drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> > drivers/gpu/drm/i915/intel_device_info.h| 1 +
> > 6 files changed, 39 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > index b06611c1d4ad..7853ea194ea6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > @@ -221,6 +221,7 @@ struct intel_gt {
> >
> > struct {
> > u8 uc_index;
> > + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> > } mocs;
> >
> > struct intel_pxp pxp;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > index c4c37585ae8c..265812589f87 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > @@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
> > unsigned int n_entries;
> > const struct drm_i915_mocs_entry *table;
> > u8 uc_index;
> > + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> > u8 unused_entries_index;
> > };
> >
> > @@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
> >
> > /* Helper defines */
> > #define GEN9_NUM_MOCS_ENTRIES64 /* 63-64 are reserved, but
configured. */
> > +#define PVC_NUM_MOCS_ENTRIES 3
>
> Should this be 4? The value here should reflect the number of entries
> that can defined in hardware rather than the size of the table we're
> asked to program. Since there are two registers (each with a high and a
> low entry), that would imply we should set 4 here to ensure that the
> fourth entry is initialized according to unused_entries_index rather
> than left at whatever the hardware defaults might be.
not sure I understand what you mean here. The n_entries specifies, as
you said, the number of entries we can have. Bspec 45101 shows entries
for indexes 0, 1 and 2. As does the pvc_mocs_table below.
Also, from bspec 44509:
"For PVC, only 3 MOCS states are supported. The allowed index values are
in range [0, 2]..."
So, I don't think we want to program any fourth entry.
We don't have a choice; the fourth entry lives in the same register as
the third entry, so no matter what we're writing _something_ to those
bits. The question is whether we should write all 0's or whether we
should treat it like other platforms and ensure it's initialized to the
unused entry values. Entry #4 isn't supposed to be used, but if buggy
userspace tries to use it, we probably still want well-defined behavior,
just like it an invalid entry gets used on any other platform.
Now I understand what you were talking about: each register houses 2
entries. For PVC we have LNCFCMOCS0 and LNCFCMOCS1. Humn... looking at
for_each_l3cc(), that is actually handled and the rest of the register
is initialized with the value pointed by unused_entries_index.
Such situation would only happen for the last entry, which implies the
handling for odd size works for this as well.
Lucas De Marchi
Matt
Lucas De Marchi
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
On 2022-05-02 10:29, Harry Wentland wrote: > > > On 2022-05-02 10:27, Modem, Bhanuprakash wrote: >> On Mon-02-05-2022 07:08 pm, Harry Wentland wrote: >>> >>> >>> On 2022-05-02 09:28, Modem, Bhanuprakash wrote: On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote: > > >> -Original Message- >> From: Intel-gfx On Behalf Of >> Bhanuprakash Modem >> Sent: Monday, April 11, 2022 3:21 PM >> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >> amd- >> g...@lists.freedesktop.org; jani.nik...@linux.intel.com; >> ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2 >> >> Cc: Rodrigo Siqueira >> Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector >> debugfs to >> drm >> >> As drm_connector already have the display_info, instead of creating >> "output_bpc" debugfs in vendor specific driver, move the logic to the >> drm >> layer. >> >> This patch will also move "Current" bpc to the crtc debugfs from >> connector >> debugfs, since we are getting this info from crtc_state. >> >> Cc: Harry Wentland >> Cc: Rodrigo Siqueira >> Signed-off-by: Bhanuprakash Modem >> Reported-by: kernel test robot >> --- > Reviewed-by: Arun R Murthy Thanks Arun, @Harry/@Rodrigo, If this change sounds good to you, can you please help to push it? >>> >>> This changes the output_bpc debugfs behavior on amdgpu and breaks >>> the amd_max_bpc IGT test. I don't think we should merge this as-is. >> >> Yeah, I have floated the IGT changes to support this series: >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F102387%2Fdata=05%7C01%7Charry.wentland%40amd.com%7C8cb627c63b194b3b82f808da2c4839b0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637870985961376064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kn26Et7wc9IUkYhSG3R%2FXVKIJoqyKlQ1%2FNcduVh9Fuo%3Dreserved=0 >> >> >> With this IGT change, we can merge this series as-is. I would like to >> request you to review IGT patches too. >> >>> >>> This patch also seems dependent on patch 1 of the series. Shouldn't >>> they be merged together (please don't merge them as-is, though)? >> >> Yes, as other patches in this series are already reviewed, I think we >> need to plan to merge all patches in this series together (If above IGT >> & this patch looks good to you). >> > > Thanks for the context again and apologies I haven't had the time to > have a closer look so far. I'll go over these and the IGT patches today > and get back to you. > 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 > Harry > >> - Bhanu >> >>> >>> Harry >>> - Bhanu > > Thanks and Regards, > Arun R Murthy > >>
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 11:39:48AM -0700, Lucas De Marchi wrote:
> On Mon, May 02, 2022 at 09:50:23AM -0700, Matt Roper wrote:
> > On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
> > > From: Ayaz A Siddiqui
> > >
> > > Bspec: 45101, 72161
> > > Signed-off-by: Ayaz A Siddiqui
> > > Signed-off-by: Fei Yang
> > > Signed-off-by: Matt Roper
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> > > drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
> > > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > > drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> > > drivers/gpu/drm/i915/intel_device_info.h| 1 +
> > > 6 files changed, 39 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > index b06611c1d4ad..7853ea194ea6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> > > @@ -221,6 +221,7 @@ struct intel_gt {
> > >
> > > struct {
> > > u8 uc_index;
> > > + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> > > } mocs;
> > >
> > > struct intel_pxp pxp;
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > index c4c37585ae8c..265812589f87 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > > @@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
> > > unsigned int n_entries;
> > > const struct drm_i915_mocs_entry *table;
> > > u8 uc_index;
> > > + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> > > u8 unused_entries_index;
> > > };
> > >
> > > @@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
> > >
> > > /* Helper defines */
> > > #define GEN9_NUM_MOCS_ENTRIES64 /* 63-64 are reserved, but
> > > configured. */
> > > +#define PVC_NUM_MOCS_ENTRIES 3
> >
> > Should this be 4? The value here should reflect the number of entries
> > that can defined in hardware rather than the size of the table we're
> > asked to program. Since there are two registers (each with a high and a
> > low entry), that would imply we should set 4 here to ensure that the
> > fourth entry is initialized according to unused_entries_index rather
> > than left at whatever the hardware defaults might be.
>
> not sure I understand what you mean here. The n_entries specifies, as
> you said, the number of entries we can have. Bspec 45101 shows entries
> for indexes 0, 1 and 2. As does the pvc_mocs_table below.
>
> Also, from bspec 44509:
> "For PVC, only 3 MOCS states are supported. The allowed index values are
> in range [0, 2]..."
>
> So, I don't think we want to program any fourth entry.
We don't have a choice; the fourth entry lives in the same register as
the third entry, so no matter what we're writing _something_ to those
bits. The question is whether we should write all 0's or whether we
should treat it like other platforms and ensure it's initialized to the
unused entry values. Entry #4 isn't supposed to be used, but if buggy
userspace tries to use it, we probably still want well-defined behavior,
just like it an invalid entry gets used on any other platform.
Matt
>
> Lucas De Marchi
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
Re: [Intel-gfx] [PATCH 11/11] drm/i915/pvc: read fuses for link copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> The new Link Copy engines in PVC may be fused off according to the
> mslice_mask. Each bit of the MEML3_EN_MASK we read from the
> GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
Reviewed-by: José Roberto de Souza
>
> Bspec: 44483
> Cc: Matt Roper
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index c6e93db134b1..d10cdeff5072 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -686,6 +686,33 @@ static void engine_mask_apply_compute_fuses(struct
> intel_gt *gt)
> }
> }
>
> +static void engine_mask_apply_copy_fuses(struct intel_gt *gt)
> +{
> + struct drm_i915_private *i915 = gt->i915;
> + struct intel_gt_info *info = >info;
> + unsigned long meml3_mask;
> + u8 quad;
> +
> + meml3_mask = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
> + meml3_mask = REG_FIELD_GET(GEN12_MEML3_EN_MASK, meml3_mask);
> +
> + /*
> + * Link Copy engines may be fused off according to meml3_mask. Each
> + * bit is a quad that houses 2 Link Copy and two Sub Copy engines.
> + */
> + for_each_clear_bit(quad, _mask, GEN12_MAX_MSLICES) {
> + intel_engine_mask_t mask = GENMASK(BCS1 + quad * 2 + 1,
> +BCS1 + quad * 2);
> +
> + if (mask & info->engine_mask) {
> + drm_dbg(>drm, "bcs%u fused off\n", quad * 2 + 1);
> + drm_dbg(>drm, "bcs%u fused off\n", quad * 2 + 2);
> +
> + info->engine_mask &= ~mask;
> + }
> + }
> +}
> +
> /*
> * Determine which engines are fused off in our particular hardware.
> * Note that we have a catch-22 situation where we need to be able to access
> @@ -768,6 +795,7 @@ static intel_engine_mask_t init_engine_mask(struct
> intel_gt *gt)
> GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
>
> engine_mask_apply_compute_fuses(gt);
> + engine_mask_apply_copy_fuses(gt);
>
> return info->engine_mask;
> }
Re: [Intel-gfx] [PATCH 06/11] drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter engine
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: John Harrison
>
> PVC adds extra blitter engines (in the following patch). The reset
> selftest has a local array on the stack which is sized by the number
> of engines. The increase pushes the size of this array to the point
> where it trips the 'stack too large' compile warning. This patch takes
> the allocation of the stack and makes it dynamic instead.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: John Harrison
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> index 83ff4c2e57c5..3b9d82276db2 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
> @@ -979,6 +979,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
> enum intel_engine_id id, tmp;
> struct hang h;
> int err = 0;
> + struct active_engine *threads;
>
> /* Check that issuing a reset on one engine does not interfere
>* with any other engine.
> @@ -996,8 +997,11 @@ static int __igt_reset_engines(struct intel_gt *gt,
> h.ctx->sched.priority = 1024;
> }
>
> + threads = kzalloc(sizeof(*threads) * I915_NUM_ENGINES, GFP_KERNEL);
> + if (!threads)
> + return -ENOMEM;
> +
> for_each_engine(engine, gt, id) {
> - struct active_engine threads[I915_NUM_ENGINES] = {};
> unsigned long device = i915_reset_count(global);
> unsigned long count = 0, reported;
> bool using_guc = intel_engine_uses_guc(engine);
> @@ -1016,7 +1020,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
> break;
> }
>
> - memset(threads, 0, sizeof(threads));
> + memset(threads, 0, sizeof(*threads) * I915_NUM_ENGINES);
> for_each_engine(other, gt, tmp) {
> struct task_struct *tsk;
>
> @@ -1236,6 +1240,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
> break;
> }
> }
> + kfree(threads);
>
> if (intel_gt_is_wedged(gt))
> err = -EIO;
Re: [Intel-gfx] [PATCH 07/11] drm/i915/pvc: Engines definitions for new copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the basic definitions needed to support
> new copy engines. Also updating the cmd_info to accommodate
> new engines, as the engine id's of legacy engines have been
> changed.
Reviewed-by: José Roberto de Souza
>
> Original-author: CQ Tang
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 56
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +++-
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +++
> drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 8 +++
> 5 files changed, 82 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 14c6ddbbfde8..4532c3ea9ace 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -71,6 +71,62 @@ static const struct engine_info intel_engines[] = {
> { .graphics_ver = 6, .base = BLT_RING_BASE }
> },
> },
> + [BCS1] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 1,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS1_RING_BASE }
> + },
> + },
> + [BCS2] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 2,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS2_RING_BASE }
> + },
> + },
> + [BCS3] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 3,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS3_RING_BASE }
> + },
> + },
> + [BCS4] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 4,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS4_RING_BASE }
> + },
> + },
> + [BCS5] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 5,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS5_RING_BASE }
> + },
> + },
> + [BCS6] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 6,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS6_RING_BASE }
> + },
> + },
> + [BCS7] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 7,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS7_RING_BASE }
> + },
> + },
> + [BCS8] = {
> + .class = COPY_ENGINE_CLASS,
> + .instance = 8,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = XEHPC_BCS8_RING_BASE }
> + },
> + },
> [VCS0] = {
> .class = VIDEO_DECODE_CLASS,
> .instance = 0,
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 298f2cc7a879..356c15cdccf0 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -35,7 +35,7 @@
> #define OTHER_CLASS 4
> #define COMPUTE_CLASS5
> #define MAX_ENGINE_CLASS 5
> -#define MAX_ENGINE_INSTANCE 7
> +#define MAX_ENGINE_INSTANCE 8
>
> #define I915_MAX_SLICES 3
> #define I915_MAX_SUBSLICES 8
> @@ -107,6 +107,14 @@ struct i915_ctx_workarounds {
> enum intel_engine_id {
> RCS0 = 0,
> BCS0,
> + BCS1,
> + BCS2,
> + BCS3,
> + BCS4,
> + BCS5,
> + BCS6,
> + BCS7,
> + BCS8,
> VCS0,
> VCS1,
> VCS2,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index a0a49c16babd..aa2c0974b02c 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1476,6 +1476,14 @@
> #define GEN11_KCR (19)
> #define GEN11_GTPM (16)
> #define GEN11_BCS (15)
> +#define XEHPC_BCS1 (14)
> +#define XEHPC_BCS2 (13)
> +#define XEHPC_BCS3 (12)
> +#define XEHPC_BCS4 (11)
> +#define XEHPC_BCS5 (10)
> +#define XEHPC_BCS6 (9)
> +#define XEHPC_BCS7 (8)
> +#define XEHPC_BCS8 (23)
> #define GEN12_CCS3 (7)
> #define GEN12_CCS2 (6)
> #define GEN12_CCS1 (5)
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index
Re: [Intel-gfx] [PATCH 09/11] drm/i915/pvc: Reset support for new copy engines
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the reset support for new copy engines
> in PVC.
Reviewed-by: José Roberto de Souza
>
> Bspec: 52549
> Original-author: CQ Tang
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 44 +--
> 2 files changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 4532c3ea9ace..c6e93db134b1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -390,6 +390,14 @@ static u32 get_reset_domain(u8 ver, enum intel_engine_id
> id)
> static const u32 engine_reset_domains[] = {
> [RCS0] = GEN11_GRDOM_RENDER,
> [BCS0] = GEN11_GRDOM_BLT,
> + [BCS1] = XEHPC_GRDOM_BLT1,
> + [BCS2] = XEHPC_GRDOM_BLT2,
> + [BCS3] = XEHPC_GRDOM_BLT3,
> + [BCS4] = XEHPC_GRDOM_BLT4,
> + [BCS5] = XEHPC_GRDOM_BLT5,
> + [BCS6] = XEHPC_GRDOM_BLT6,
> + [BCS7] = XEHPC_GRDOM_BLT7,
> + [BCS8] = XEHPC_GRDOM_BLT8,
> [VCS0] = GEN11_GRDOM_MEDIA,
> [VCS1] = GEN11_GRDOM_MEDIA2,
> [VCS2] = GEN11_GRDOM_MEDIA3,
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index fe09288a3145..98ede9c93f00 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -597,24 +597,32 @@
> /* GEN11 changed all bit defs except for FULL & RENDER */
> #define GEN11_GRDOM_FULL GEN6_GRDOM_FULL
> #define GEN11_GRDOM_RENDER GEN6_GRDOM_RENDER
> -#define GEN11_GRDOM_BLT(1 << 2)
> -#define GEN11_GRDOM_GUC(1 << 3)
> -#define GEN11_GRDOM_MEDIA (1 << 5)
> -#define GEN11_GRDOM_MEDIA2 (1 << 6)
> -#define GEN11_GRDOM_MEDIA3 (1 << 7)
> -#define GEN11_GRDOM_MEDIA4 (1 << 8)
> -#define GEN11_GRDOM_MEDIA5 (1 << 9)
> -#define GEN11_GRDOM_MEDIA6 (1 << 10)
> -#define GEN11_GRDOM_MEDIA7 (1 << 11)
> -#define GEN11_GRDOM_MEDIA8 (1 << 12)
> -#define GEN11_GRDOM_VECS (1 << 13)
> -#define GEN11_GRDOM_VECS2 (1 << 14)
> -#define GEN11_GRDOM_VECS3 (1 << 15)
> -#define GEN11_GRDOM_VECS4 (1 << 16)
> -#define GEN11_GRDOM_SFC0 (1 << 17)
> -#define GEN11_GRDOM_SFC1 (1 << 18)
> -#define GEN11_GRDOM_SFC2 (1 << 19)
> -#define GEN11_GRDOM_SFC3 (1 << 20)
> +#define XEHPC_GRDOM_BLT8 REG_BIT(31)
> +#define XEHPC_GRDOM_BLT7 REG_BIT(30)
> +#define XEHPC_GRDOM_BLT6 REG_BIT(29)
> +#define XEHPC_GRDOM_BLT5 REG_BIT(28)
> +#define XEHPC_GRDOM_BLT4 REG_BIT(27)
> +#define XEHPC_GRDOM_BLT3 REG_BIT(26)
> +#define XEHPC_GRDOM_BLT2 REG_BIT(25)
> +#define XEHPC_GRDOM_BLT1 REG_BIT(24)
> +#define GEN11_GRDOM_SFC3 REG_BIT(20)
> +#define GEN11_GRDOM_SFC2 REG_BIT(19)
> +#define GEN11_GRDOM_SFC1 REG_BIT(18)
> +#define GEN11_GRDOM_SFC0 REG_BIT(17)
> +#define GEN11_GRDOM_VECS4 REG_BIT(16)
> +#define GEN11_GRDOM_VECS3 REG_BIT(15)
> +#define GEN11_GRDOM_VECS2 REG_BIT(14)
> +#define GEN11_GRDOM_VECS REG_BIT(13)
> +#define GEN11_GRDOM_MEDIA8 REG_BIT(12)
> +#define GEN11_GRDOM_MEDIA7 REG_BIT(11)
> +#define GEN11_GRDOM_MEDIA6 REG_BIT(10)
> +#define GEN11_GRDOM_MEDIA5 REG_BIT(9)
> +#define GEN11_GRDOM_MEDIA4 REG_BIT(8)
> +#define GEN11_GRDOM_MEDIA3 REG_BIT(7)
> +#define GEN11_GRDOM_MEDIA2 REG_BIT(6)
> +#define GEN11_GRDOM_MEDIA REG_BIT(5)
> +#define GEN11_GRDOM_GUCREG_BIT(3)
> +#define GEN11_GRDOM_BLTREG_BIT(2)
> #define GEN11_VCS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 <<
> ((instance) >> 1))
> #define GEN11_VECS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 << (instance))
>
Re: [Intel-gfx] [PATCH 10/11] drm/i915/pvc: skip all copy engines from aux table invalidate
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> As we have more copy engines now, mask all of them from aux table
> invalidate.
Reviewed-by: José Roberto de Souza
>
> Cc: Prathap Kumar Valsan
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> index 0de17b568b41..f262aed94ef3 100644
> --- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
> @@ -275,7 +275,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32
> mode)
> if (!HAS_FLAT_CCS(rq->engine->i915) &&
> (rq->engine->class == VIDEO_DECODE_CLASS ||
>rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
> - aux_inv = rq->engine->mask & ~BIT(BCS0);
> + aux_inv = rq->engine->mask & ~GENMASK(BCS8, BCS0);
> if (aux_inv)
> cmd += 4;
> }
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 09:50:23AM -0700, Matt Roper wrote:
On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
From: Ayaz A Siddiqui
Bspec: 45101, 72161
Signed-off-by: Ayaz A Siddiqui
Signed-off-by: Fei Yang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h| 1 +
6 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index b06611c1d4ad..7853ea194ea6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -221,6 +221,7 @@ struct intel_gt {
struct {
u8 uc_index;
+ u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
} mocs;
struct intel_pxp pxp;
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index c4c37585ae8c..265812589f87 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
unsigned int n_entries;
const struct drm_i915_mocs_entry *table;
u8 uc_index;
+ u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
u8 unused_entries_index;
};
@@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
+#define PVC_NUM_MOCS_ENTRIES 3
Should this be 4? The value here should reflect the number of entries
that can defined in hardware rather than the size of the table we're
asked to program. Since there are two registers (each with a high and a
low entry), that would imply we should set 4 here to ensure that the
fourth entry is initialized according to unused_entries_index rather
than left at whatever the hardware defaults might be.
not sure I understand what you mean here. The n_entries specifies, as
you said, the number of entries we can have. Bspec 45101 shows entries
for indexes 0, 1 and 2. As does the pvc_mocs_table below.
Also, from bspec 44509:
"For PVC, only 3 MOCS states are supported. The allowed index values are
in range [0, 2]..."
So, I don't think we want to program any fourth entry.
Lucas De Marchi
[Intel-gfx] ✓ Fi.CI.BAT: success for Make the rest of the VFIO driver interface use vfio_device (rev4)
== Series Details ==
Series: Make the rest of the VFIO driver interface use vfio_device (rev4)
URL : https://patchwork.freedesktop.org/series/102606/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11588 -> Patchwork_102606v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/index.html
Participating hosts (44 -> 42)
--
Additional (2): bat-dg2-8 bat-dg1-5
Missing(4): fi-bsw-cyan bat-rpls-1 fi-hsw-4770 fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102606v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@client:
- {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg2-8/igt@i915_selftest@l...@client.html
* igt@i915_selftest@live@gt_mocs:
- {bat-adlm-1}: NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-adlm-1/igt@i915_selftest@live@gt_mocs.html
Known issues
Here are the changes found in Patchwork_102606v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@fbdev@write:
- bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#2582]) +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@fb...@write.html
* igt@gem_mmap@basic:
- bat-dg1-5: NOTRUN -> [SKIP][4] ([i915#4083])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@gem_m...@basic.html
* igt@gem_tiled_fence_blits@basic:
- bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#4077]) +2 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@gem_tiled_fence_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-5: NOTRUN -> [SKIP][6] ([i915#4079]) +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#1155])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: NOTRUN -> [DMESG-FAIL][8] ([i915#4418])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][9] ([i915#4215])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_addfb_basic@tile-pitch-mismatch:
- bat-dg1-5: NOTRUN -> [SKIP][10] ([i915#4212]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_addfb_ba...@tile-pitch-mismatch.html
* igt@kms_busy@basic:
- bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#4303])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_b...@basic.html
* igt@kms_chamelium@hdmi-hpd-fast:
- bat-dg1-5: NOTRUN -> [SKIP][12] ([fdo#111827]) +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#4103] / [i915#4213]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-flip-vs-dpms:
- bat-dg1-5: NOTRUN -> [SKIP][14] ([i915#4078]) +23 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-5: NOTRUN -> [SKIP][15] ([fdo#109285])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- bat-dg1-5: NOTRUN -> [SKIP][16] ([i915#1072] / [i915#4078]) +3
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-5: NOTRUN -> [SKIP][17] ([i915#3555])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102606v4/bat-dg1-5/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-mmap:
- bat-dg1-5: NOTRUN ->
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions
On Fri, Apr 29, 2022 at 01:49:37PM -0700, Lucas De Marchi wrote:
On Fri, Apr 29, 2022 at 01:39:03PM -0700, Anusha Srivatsa wrote:
-Original Message-
From: De Marchi, Lucas
Sent: Tuesday, April 26, 2022 10:42 PM
To: Srivatsa, Anusha
Cc: intel-gfx@lists.freedesktop.org; sta...@vger.kernel.org
Subject: Re: [PATCH] drm/i915/dmc: Add MMIO range restrictions
On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
BSpec: 49193
Cc:
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 48 ---
drivers/gpu/drm/i915/display/intel_dmc_regs.h | 31
2 files changed, 72 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 257cf662f9f4..ac7896835bfa 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -97,13 +97,6 @@ MODULE_FIRMWARE(SKL_DMC_PATH);
#define BXT_DMC_MAX_FW_SIZE 0x3000
MODULE_FIRMWARE(BXT_DMC_PATH);
-#define DMC_DEFAULT_FW_OFFSET 0x
-#define PACKAGE_MAX_FW_INFO_ENTRIES20
-#define PACKAGE_V2_MAX_FW_INFO_ENTRIES 32
-#define DMC_V1_MAX_MMIO_COUNT 8
-#define DMC_V3_MAX_MMIO_COUNT 20
-#define DMC_V1_MMIO_START_RANGE0x8
-
struct intel_css_header {
/* 0x09 for DMC */
u32 module_type;
@@ -374,6 +367,43 @@ static void dmc_set_fw_offset(struct intel_dmc
*dmc,
}
}
+static bool dmc_mmio_addr_sanity_check(struct intel_dmc *dmc, const
u32 *mmioaddr,
+ u32 mmio_count, int header_ver, u8
dmc_id) {
+ struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
dmc);
+ int i;
+
+ if (header_ver == 1) {
+ for (i = 0; i < mmio_count; i++) {
+ if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
mmioaddr[i] > DMC_MMIO_END_RANGE)
+ return false;
+ }
return missing here
+ }
+
+ /* Main DMC MMIO check */
+ if (dmc_id == DMC_FW_MAIN) {
+ for (i = 0; i < mmio_count; i++) {
+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
|| mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
+ return false;
+ }
+ }
+
+ /* Pipe DMC MMIO check */
+ if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
+ for (i = 0; i < mmio_count; i++) {
+ if (mmioaddr[i] < ADLP_PIPE_MMIO_START &&
mmioaddr[i] > ADLP_PIPE_MMIO_END)
+ return false;
+ }
for DG2, main should use TGL_DMC_MMIO_START? and then fail here
because of another missing return above?
+ } else if (IS_TIGERLAKE(i915) || IS_DG1(i915) ||
IS_ALDERLAKE_S(i915)) {
+ for (i = 0; i < mmio_count; i++) {
+ if (mmioaddr[i] < TGL_DMC_MMIO_START(dmc_id)
|| mmioaddr[i] > TGL_DMC_MMIO_END(dmc_id))
+ return false;
this is handling DMC_FW_MAIN twice.
Maybe something like this:
u32 start, end;
if (header_ver == 1) {
start = DMC_MMIO_START_RANGE;
end = DMC_MMIO_END_RANGE;
} else if (dmc_id == DMC_FW_MAIN || IS_TIGERLAKE(i915) ||
IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
start = TGL_DMC_MMIO_START(dmc_id);
end = TGL_DMC_MMIO_END(dmc_id);
} else if (IS_DG2(i915) || IS_ALDERLAKE_P(i915)) {
start = ADLP_PIPE_MMIO_START;
end = ADLP_PIPE_MMIO_END;
} else {
drm_warn(>drm, "Unknown mmio range for sanity
check");
return false;
}
for (i = 0; i < mmio_count; i++)
if (mmioaddr[i] < start || mmioaddr[i] > end)
return false;
return true;
... untested, and may need tweaks depending on the answer to the question
above on what range to use for ADL-P/DG2 on main DMC.
The above approach is definitely neater.
The main DMC offset is the same for all platforms.
+ }
+ }
+
+ return true;
+}
+
static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
const struct intel_dmc_header_base
*dmc_header,
size_t rem_size, u8 dmc_id)
@@ -443,6 +473,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc
*dmc,
return 0;
}
+ if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count,
dmc_header->header_ver, dmc_id))
+ drm_err(>drm, "DMC firmware has Wrong MMIO
Addresses\n");
+ return 0;
you don't like DMC and decided to fail
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 02/05/2022 20:58, Abodunrin, Akeem G wrote:
-Original Message-
From: Landwerlin, Lionel G
Sent: Monday, May 2, 2022 12:55 AM
To: Auld, Matthew ; intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
; Bloomfield, Jon
; Daniel Vetter ; Justen,
Jordan L ; Kenneth Graunke
; Abodunrin, Akeem G
; mesa-...@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 20/04/2022 20:13, 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)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190
+++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 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 ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * 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 _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;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 = unknown)
*/
+ __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.
+*/
+ __u64 probed_cpu_visible_size;
+ };
Trying to implement userspace support in Vulkan for this, I have an additional
question about the value of probed_cpu_visible_size.
When is it set to -1?
I believe it is set to -1 if it is unknown, and/or not cpu accessible...
Cheers!
~Akeem
So what should I expect on system memory?
What value is returned when all of probed_size is CPU visible on local
memory?
Thanks,
-Lionel
I'm guessing before there is support for this value it'll be 0 (MBZ).
After after it should either be the entire lmem or something smaller.
-Lionel
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour,
+with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the
+stuff that
+ * is immutable. Previously we would have two ioctls, one to create
+the object
+ * with gem_create, and another to apply various parameters, however
+this
+ * creates some ambiguity for the params which are considered
+immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*
+* Note that for some devices we have might have further minimum
+* page-size restrictions(larger than 4K), like for device local-memory.
+* However in general the final size here should always reflect any
+* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+* extension to place the object in device local-memory.
+*/
+ __u64 size;
+ /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+ __u32 handle;
+ /**
+* @flags: Optional flags.
+*
+* Supported values:
+*
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the
kernel that
+* the object will need to be accessed via the CPU.
+*
+* Only valid when placing objects in I915_MEMORY_CLASS_DEVICE,
and
+* only strictly required on platforms where only some of the device
+* memory is directly
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Make the rest of the VFIO driver interface use vfio_device (rev4)
== Series Details == Series: Make the rest of the VFIO driver interface use vfio_device (rev4) URL : https://patchwork.freedesktop.org/series/102606/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/find.h:40:31: warning: shift count is negative (-448)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Make the rest of the VFIO driver interface use vfio_device (rev4)
== Series Details ==
Series: Make the rest of the VFIO driver interface use vfio_device (rev4)
URL : https://patchwork.freedesktop.org/series/102606/
State : warning
== Summary ==
Error: dim checkpatch failed
ec715bc61dd4 vfio: Make vfio_(un)register_notifier accept a vfio_device
-:227: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#227: FILE: include/linux/vfio.h:181:
+extern int vfio_register_notifier(struct vfio_device *dev,
-:232: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#232: FILE: include/linux/vfio.h:185:
+extern int vfio_unregister_notifier(struct vfio_device *dev,
-:235: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 2 checks, 187 lines checked
9cfaa7606a96 vfio/ccw: Remove mdev from struct channel_program
-:167: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#167: FILE: drivers/s390/cio/vfio_ccw_cp.c:659:
+ dev_warn(
-:210: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#210: FILE: drivers/s390/cio/vfio_ccw_cp.h:44:
+extern int cp_init(struct channel_program *cp, union orb *orb);
-:227: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 2 checks, 186 lines checked
27e583abb3bf vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()
-:214: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#214: FILE: include/linux/vfio.h:153:
+extern int vfio_pin_pages(struct vfio_device *vdev, unsigned long *user_pfn,
-:217: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#217: FILE: include/linux/vfio.h:155:
+extern int vfio_unpin_pages(struct vfio_device *vdev, unsigned long *user_pfn,
-:220: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 2 checks, 170 lines checked
efd6d6610a35 vfio/mdev: Pass in a struct vfio_device * to vfio_dma_rw()
-:102: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files
#102: FILE: include/linux/vfio.h:164:
+extern int vfio_dma_rw(struct vfio_device *vdev, dma_addr_t user_iova,
-:105: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 1 checks, 73 lines checked
7e63fc25c93d drm/i915/gvt: Change from vfio_group_(un)pin_pages to
vfio_(un)pin_pages
-:111: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 0 checks, 80 lines checked
064082b3990b vfio: Remove dead code
-:225: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 0 checks, 195 lines checked
10da62464092 vfio: Remove calls to vfio_group_add_container_user()
-:244: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Jason Gunthorpe ' != 'Signed-off-by: Jason
Gunthorpe '
total: 0 errors, 1 warnings, 0 checks, 194 lines checked
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
> -Original Message-
> From: Landwerlin, Lionel G
> Sent: Monday, May 2, 2022 12:55 AM
> To: Auld, Matthew ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
> ; Bloomfield, Jon
> ; Daniel Vetter ; Justen,
> Jordan L ; Kenneth Graunke
> ; Abodunrin, Akeem G
> ; mesa-...@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/doc: add rfc section for small BAR uapi
>
> On 20/04/2022 20:13, 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)
> >
> > Signed-off-by: Matthew Auld
> > Cc: Thomas Hellström
> > Cc: Lionel Landwerlin
> > Cc: Jon Bloomfield
> > Cc: Daniel Vetter
> > Cc: Jordan Justen
> > Cc: Kenneth Graunke
> > Cc: Akeem G Abodunrin
> > Cc: mesa-...@lists.freedesktop.org
> > ---
> > Documentation/gpu/rfc/i915_small_bar.h | 190
> +++
> > Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
> > Documentation/gpu/rfc/index.rst | 4 +
> > 3 files changed, 252 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 ..7bfd0cf44d35
> > --- /dev/null
> > +++ b/Documentation/gpu/rfc/i915_small_bar.h
> > @@ -0,0 +1,190 @@
> > +/**
> > + * 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 _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;
> > +
> > + /** @unallocated_size: Estimate of memory remaining (-1 = unknown)
> */
> > + __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.
> > +*/
> > + __u64 probed_cpu_visible_size;
> > + };
>
>
> Trying to implement userspace support in Vulkan for this, I have an additional
> question about the value of probed_cpu_visible_size.
>
> When is it set to -1?
I believe it is set to -1 if it is unknown, and/or not cpu accessible...
Cheers!
~Akeem
>
> I'm guessing before there is support for this value it'll be 0 (MBZ).
>
> After after it should either be the entire lmem or something smaller.
>
>
> -Lionel
>
>
> > + };
> > +};
> > +
> > +/**
> > + * struct __drm_i915_gem_create_ext - Existing gem_create behaviour,
> > +with added
> > + * extension support using struct i915_user_extension.
> > + *
> > + * Note that new buffer flags should be added here, at least for the
> > +stuff that
> > + * is immutable. Previously we would have two ioctls, one to create
> > +the object
> > + * with gem_create, and another to apply various parameters, however
> > +this
> > + * creates some ambiguity for the params which are considered
> > +immutable. Also in
> > + * general we're phasing out the various SET/GET ioctls.
> > + */
> > +struct __drm_i915_gem_create_ext {
> > + /**
> > +* @size: Requested size for the object.
> > +*
> > +* The (page-aligned) allocated size for the object will be returned.
> > +*
> > +* Note that for some devices we have might have further minimum
> > +* page-size restrictions(larger than 4K), like for device local-memory.
> > +* However in general the final size here should always reflect any
> > +* rounding up, if for example using the
> I915_GEM_CREATE_EXT_MEMORY_REGIONS
> > +* extension to place the object in device local-memory.
> > +*/
> > + __u64 size;
> > + /**
> > +* @handle: Returned handle for the object.
> > +*
> > +* Object handles are nonzero.
> > +*/
> > + __u32 handle;
> > + /**
> > +* @flags: Optional flags.
> > +*
> > +* Supported values:
> > +*
> > +*
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: remove superfluous string helper include (rev4)
== Series Details ==
Series: drm/i915: remove superfluous string helper include (rev4)
URL : https://patchwork.freedesktop.org/series/103086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11588 -> Patchwork_103086v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/index.html
Participating hosts (44 -> 43)
--
Additional (1): bat-dg2-8
Missing(2): bat-adlm-1 fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103086v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@client:
- {bat-dg2-8}:NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/bat-dg2-8/igt@i915_selftest@l...@client.html
Known issues
Here are the changes found in Patchwork_103086v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][2] ([fdo#109271] / [i915#4312] /
[i915#5594])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [DMESG-FAIL][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- {fi-tgl-dsi}: [INCOMPLETE][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- {bat-adlp-6}: [DMESG-WARN][7] ([i915#3576]) -> [PASS][8] +2 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/bat-adlp-6/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103086v4/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#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[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]: 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#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4873]: https://gitlab.freedesktop.org/drm/intel/issues/4873
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5274]: https://gitlab.freedesktop.org/drm/intel/issues/5274
[i915#5275]: https://gitlab.freedesktop.org/drm/intel/issues/5275
[i915#5338]: https://gitlab.freedesktop.org/drm/intel/issues/5338
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#5763]: https://gitlab.freedesktop.org/drm/intel/issues/5763
Build changes
-
* Linux: CI_DRM_11588 -> Patchwork_103086v4
CI-20190529: 20190529
CI_DRM_11588: 68f638d8e33ee3d6110a6798b823f88e07eaef1f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6464: eddc67c5c85b8ee6eb4d13752ca43da5073dc985 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_103086v4:
[Intel-gfx] ✗ Fi.CI.IGT: failure for uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
== Series Details ==
Series: uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
URL : https://patchwork.freedesktop.org/series/103434/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11586_full -> Patchwork_103434v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_103434v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103434v1_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 -> 13)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103434v1_full:
### IGT changes ###
Possible regressions
* igt@syncobj_timeline@wait-all-for-submit-snapshot:
- shard-skl: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-skl7/igt@syncobj_timel...@wait-all-for-submit-snapshot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/shard-skl4/igt@syncobj_timel...@wait-all-for-submit-snapshot.html
Warnings
* igt@kms_color@pipe-d-ctm-red-to-blue:
- shard-kbl: [SKIP][3] ([fdo#109271]) -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-kbl4/igt@kms_co...@pipe-d-ctm-red-to-blue.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/shard-kbl6/igt@kms_co...@pipe-d-ctm-red-to-blue.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_flink_race@flink_close:
- {shard-rkl}:[PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-6/igt@gem_flink_race@flink_close.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/shard-rkl-6/igt@gem_flink_race@flink_close.html
- {shard-tglu}: [PASS][7] -> [FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-tglu-8/igt@gem_flink_race@flink_close.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/shard-tglu-2/igt@gem_flink_race@flink_close.html
* igt@i915_pm_rpm@system-suspend-modeset:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/shard-dg1-13/igt@i915_pm_...@system-suspend-modeset.html
Known issues
Here are the changes found in Patchwork_103434v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- {shard-rkl}:([PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [FAIL][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
[FAIL][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], [PASS][46], [PASS][47], [PASS][48], [PASS][49])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-1/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-1/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-1/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-1/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-1/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-1/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-6/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-4/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/shard-rkl-5/boot.html
[28]:
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Introduce Ponte Vecchio
== Series Details ==
Series: i915: Introduce Ponte Vecchio
URL : https://patchwork.freedesktop.org/series/103443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11588 -> Patchwork_103443v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/index.html
Participating hosts (44 -> 39)
--
Missing(5): bat-adlm-1 fi-bsw-cyan fi-icl-u2 fi-hsw-4770 bat-rpls-1
Known issues
Here are the changes found in Patchwork_103443v1 that come from known issues:
### IGT changes ###
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- {fi-tgl-dsi}: [DMESG-FAIL][1] -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/fi-tgl-dsi/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@migrate:
- {fi-tgl-dsi}: [INCOMPLETE][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][5] ([i915#3576]) -> [PASS][6] +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/bat-adlp-6/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/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#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
Build changes
-
* Linux: CI_DRM_11588 -> Patchwork_103443v1
CI-20190529: 20190529
CI_DRM_11588: 68f638d8e33ee3d6110a6798b823f88e07eaef1f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6464: eddc67c5c85b8ee6eb4d13752ca43da5073dc985 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_103443v1: 68f638d8e33ee3d6110a6798b823f88e07eaef1f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
2457c0586595 drm/i915/pvc: read fuses for link copy engines
fbf8f67a5b81 drm/i915/pvc: skip all copy engines from aux table invalidate
403c5c3cb3fa drm/i915/pvc: Reset support for new copy engines
edbc69443095 drm/i915/pvc: Interrupt support for new copy engines
ffedff71e172 drm/i915/pvc: Engines definitions for new copy engines
90aa5bdf2927 drm/i915/pvc: Reduce stack usage in reset selftest with extra
blitter engine
ccc0b833b47d drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL
8884d54705d6 drm/i915/pvc: Read correct RP_STATE_CAP register
fb521a51c11d drm/i915/pvc: Define MOCS table for PVC
3869419391e1 drm/i915/pvc: Add forcewake support
7276e365a5ed drm/i915/pvc: add initial Ponte Vecchio definitions
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103443v1/index.html
Re: [Intel-gfx] [CI] PR for DG2 DMC v2.06
Hi Timo, Sincere apologies! This slipped through the cracks, I'll be sending the PR request to linux-firmware in the next couple of minutes. Thanks, - Madhumitha On Mon, 2022-05-02 at 16:51 +0300, Timo Aaltonen wrote: > Timo Aaltonen kirjoitti 13.4.2022 klo 13.48: > > Tolakanahalli Pradeep, Madhumitha kirjoitti 23.3.2022 klo 20.23: > > > The following changes since commit > > > 681281e49fb6778831370e5d94e6e1d97f0752d6: > > > > > > amdgpu: update PSP 13.0.8 firmware (2022-03-18 07:35:54 -0400) > > > > > > are available in the Git repository at: > > > > > > git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.06 > > > > > > for you to fetch changes up to > > > ecc28070ea5edd4733b78550326c1d56858181af: > > > > > > i915: Add DMC v2.06 for DG2 (2022-03-23 11:15:12 -0700) > > > > > > > > > Madhumitha Tolakanahalli Pradeep (1): > > > i915: Add DMC v2.06 for DG2 > > > > > > WHENCE | 3 +++ > > > i915/dg2_dmc_ver2_06.bin | Bin 0 -> 22416 bytes > > > 2 files changed, 3 insertions(+) > > > create mode 100644 i915/dg2_dmc_ver2_06.bin > > > > > > > Hi, when will this be sent upstream? > > > > > > Ping? GuC got applied there, what's blocking DMC for DG2? > > >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Introduce Ponte Vecchio
== Series Details == Series: i915: Introduce Ponte Vecchio URL : https://patchwork.freedesktop.org/series/103443/ 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: Introduce Ponte Vecchio
== Series Details == Series: i915: Introduce Ponte Vecchio URL : https://patchwork.freedesktop.org/series/103443/ State : warning == Summary == Error: dim checkpatch failed f0fb02e3d246 drm/i915/pvc: add initial Ponte Vecchio definitions 9db154eb1285 drm/i915/pvc: Add forcewake support -:83: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #83: FILE: drivers/gpu/drm/i915/intel_uncore.c:1549: + GEN_FW_RANGE(0x4000, 0x813f, FORCEWAKE_GT), /* + 0x4000 - 0x4aff: gt -:89: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #89: FILE: drivers/gpu/drm/i915/intel_uncore.c:1555: + 0x8000 - 0x813f: gt */ -:93: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #93: FILE: drivers/gpu/drm/i915/intel_uncore.c:1559: + GEN_FW_RANGE(0x8200, 0x94cf, FORCEWAKE_GT), /* + 0x8200 - 0x82ff: gt -:100: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #100: FILE: drivers/gpu/drm/i915/intel_uncore.c:1566: + 0x9480 - 0x94cf: reserved */ -:103: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #103: FILE: drivers/gpu/drm/i915/intel_uncore.c:1569: + GEN_FW_RANGE(0x9560, 0x967f, 0), /* + 0x9560 - 0x95ff: always on -:104: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #104: FILE: drivers/gpu/drm/i915/intel_uncore.c:1570: + 0x9600 - 0x967f: reserved */ -:106: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #106: FILE: drivers/gpu/drm/i915/intel_uncore.c:1572: + GEN_FW_RANGE(0x9680, 0x97ff, FORCEWAKE_RENDER), /* + 0x9680 - 0x96ff: render -:107: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #107: FILE: drivers/gpu/drm/i915/intel_uncore.c:1573: + 0x9700 - 0x97ff: reserved */ -:109: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #109: FILE: drivers/gpu/drm/i915/intel_uncore.c:1575: + GEN_FW_RANGE(0x9800, 0xcfff, FORCEWAKE_GT), /* + 0x9800 - 0xb4ff: gt -:111: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #111: FILE: drivers/gpu/drm/i915/intel_uncore.c:1577: + 0xc000 - 0xcfff: gt */ -:116: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #116: FILE: drivers/gpu/drm/i915/intel_uncore.c:1582: + GEN_FW_RANGE(0xdd00, 0xde7f, FORCEWAKE_GT), /* + 0xdd00 - 0xddff: gt -:117: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #117: FILE: drivers/gpu/drm/i915/intel_uncore.c:1583: + 0xde00 - 0xde7f: reserved */ -:119: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #119: FILE: drivers/gpu/drm/i915/intel_uncore.c:1585: + GEN_FW_RANGE(0xde80, 0xe8ff, FORCEWAKE_RENDER), /* + 0xde80 - 0xdeff: render -:122: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #122: FILE: drivers/gpu/drm/i915/intel_uncore.c:1588: + 0xe800 - 0xe8ff: reserved */ -:124: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #124: FILE: drivers/gpu/drm/i915/intel_uncore.c:1590: + GEN_FW_RANGE(0xe900, 0x11fff, FORCEWAKE_GT), /* +0xe900 - 0xe9ff: gt -:127: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #127: FILE: drivers/gpu/drm/i915/intel_uncore.c:1593: + 0x1 - 0x11fff: reserved */ -:129: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #129: FILE: drivers/gpu/drm/i915/intel_uncore.c:1595: + GEN_FW_RANGE(0x12000, 0x12fff, 0), /* + 0x12000 - 0x127ff: always on -:130: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #130: FILE: drivers/gpu/drm/i915/intel_uncore.c:1596: + 0x12800 - 0x12fff: reserved */ -:132: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #132: FILE: drivers/gpu/drm/i915/intel_uncore.c:1598: + GEN_FW_RANGE(0x13000, 0x23fff, FORCEWAKE_GT), /* + 0x13000 - 0x135ff: gt -:138: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #138: FILE: drivers/gpu/drm/i915/intel_uncore.c:1604: + 0x22000 - 0x23fff: gt */ -:140: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #140: FILE: drivers/gpu/drm/i915/intel_uncore.c:1606: + GEN_FW_RANGE(0x24000, 0x2417f, 0), /* + 24000 - 0x2407f: always on -:141: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #141: FILE: drivers/gpu/drm/i915/intel_uncore.c:1607: + 24080 - 0x2417f: reserved */ -:143: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines #143: FILE: drivers/gpu/drm/i915/intel_uncore.c:1609: + GEN_FW_RANGE(0x24180, 0x3,
Re: [Intel-gfx] [PATCH 04/11] drm/i915/pvc: Read correct RP_STATE_CAP register
On Mon, May 02, 2022 at 09:34:10AM -0700, Matt Roper wrote: > The SoC registers, including RP_STATE_CAP, have moved to a new location > in GTTMMADR on Ponte Vecchio. We need to update the register offset > accordingly. > > Cc: Rodrigo Vivi > Signed-off-by: Matt Roper Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/gt/intel_rps.c | 4 +++- > drivers/gpu/drm/i915/i915_reg.h | 1 + > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c > b/drivers/gpu/drm/i915/gt/intel_rps.c > index 3476a11f294c..3bd8415a0f1b 100644 > --- a/drivers/gpu/drm/i915/gt/intel_rps.c > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c > @@ -1075,7 +1075,9 @@ static u32 intel_rps_read_state_cap(struct intel_rps > *rps) > struct drm_i915_private *i915 = rps_to_i915(rps); > struct intel_uncore *uncore = rps_to_uncore(rps); > > - if (IS_XEHPSDV(i915)) > + if (IS_PONTEVECCHIO(i915)) > + return intel_uncore_read(uncore, PVC_RP_STATE_CAP); > + else if (IS_XEHPSDV(i915)) > return intel_uncore_read(uncore, XEHPSDV_RP_STATE_CAP); > else if (IS_GEN9_LP(i915)) > return intel_uncore_read(uncore, BXT_RP_STATE_CAP); > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 9ccb67eec1bd..4a3d7b96ef43 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1846,6 +1846,7 @@ > #define BXT_RP_STATE_CAP_MMIO(0x138170) > #define GEN9_RP_STATE_LIMITS _MMIO(0x138148) > #define XEHPSDV_RP_STATE_CAP _MMIO(0x250014) > +#define PVC_RP_STATE_CAP _MMIO(0x281014) > > #define GT0_PERF_LIMIT_REASONS _MMIO(0x1381a8) > #define GT0_PERF_LIMIT_REASONS_MASK0xde3 > -- > 2.35.1 >
[Intel-gfx] ✓ Fi.CI.BAT: success for Flat-CCS eviction enhancements (rev4)
== Series Details ==
Series: Flat-CCS eviction enhancements (rev4)
URL : https://patchwork.freedesktop.org/series/102916/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11588 -> Patchwork_102916v4
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_102916v4 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102916v4, 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_102916v4/index.html
Participating hosts (44 -> 41)
--
Missing(3): fi-bsw-cyan bat-adlm-1 fi-icl-u2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102916v4:
### IGT changes ###
Warnings
* igt@debugfs_test@read_all_entries:
- fi-apl-guc: [DMESG-WARN][1] ([i915#5595]) -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-apl-guc/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/fi-apl-guc/igt@debugfs_test@read_all_entries.html
Known issues
Here are the changes found in Patchwork_102916v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][3] ([fdo#109271] / [fdo#111827])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][4] ([fdo#109271] / [i915#4312] /
[i915#5594])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][5] ([i915#3921]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- {fi-tgl-dsi}: [INCOMPLETE][7] -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/fi-tgl-dsi/igt@i915_selftest@l...@migrate.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][9] ([i915#3576]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11588/bat-adlp-6/igt@kms_busy@ba...@flip.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#3576]: https://gitlab.freedesktop.org/drm/intel/issues/3576
[i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#5595]: https://gitlab.freedesktop.org/drm/intel/issues/5595
Build changes
-
* Linux: CI_DRM_11588 -> Patchwork_102916v4
CI-20190529: 20190529
CI_DRM_11588: 68f638d8e33ee3d6110a6798b823f88e07eaef1f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6464: eddc67c5c85b8ee6eb4d13752ca43da5073dc985 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_102916v4: 68f638d8e33ee3d6110a6798b823f88e07eaef1f @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
9bcd414b466b drm/i915/gt: Document the eviction of the Flat-CCS objects
2d206911060d drm/i915/gt: optimize the ccs_sz calculation per chunk
87550b1771fa drm/i915/gt: BUG_ON unexpected NULL at scatterlist walking
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102916v4/index.html
Re: [Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
On Mon, May 02, 2022 at 09:34:09AM -0700, Matt Roper wrote:
> From: Ayaz A Siddiqui
>
> Bspec: 45101, 72161
> Signed-off-by: Ayaz A Siddiqui
> Signed-off-by: Fei Yang
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
> drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> drivers/gpu/drm/i915/intel_device_info.h| 1 +
> 6 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> index b06611c1d4ad..7853ea194ea6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> @@ -221,6 +221,7 @@ struct intel_gt {
>
> struct {
> u8 uc_index;
> + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> } mocs;
>
> struct intel_pxp pxp;
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
> b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index c4c37585ae8c..265812589f87 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
> unsigned int n_entries;
> const struct drm_i915_mocs_entry *table;
> u8 uc_index;
> + u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
> u8 unused_entries_index;
> };
>
> @@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
>
> /* Helper defines */
> #define GEN9_NUM_MOCS_ENTRIES64 /* 63-64 are reserved, but
> configured. */
> +#define PVC_NUM_MOCS_ENTRIES 3
Should this be 4? The value here should reflect the number of entries
that can defined in hardware rather than the size of the table we're
asked to program. Since there are two registers (each with a high and a
low entry), that would imply we should set 4 here to ensure that the
fourth entry is initialized according to unused_entries_index rather
than left at whatever the hardware defaults might be.
Matt
>
> /* (e)LLC caching options */
> /*
> @@ -394,6 +396,17 @@ static const struct drm_i915_mocs_entry
> dg2_mocs_table_g10_ax[] = {
> MOCS_ENTRY(3, 0, L3_3_WB | L3_LKUP(1)),
> };
>
> +static const struct drm_i915_mocs_entry pvc_mocs_table[] = {
> + /* Error */
> + MOCS_ENTRY(0, 0, L3_3_WB),
> +
> + /* UC */
> + MOCS_ENTRY(1, 0, L3_1_UC),
> +
> + /* WB */
> + MOCS_ENTRY(2, 0, L3_3_WB),
> +};
> +
> enum {
> HAS_GLOBAL_MOCS = BIT(0),
> HAS_ENGINE_MOCS = BIT(1),
> @@ -423,7 +436,14 @@ static unsigned int get_mocs_settings(const struct
> drm_i915_private *i915,
> memset(table, 0, sizeof(struct drm_i915_mocs_table));
>
> table->unused_entries_index = I915_MOCS_PTE;
> - if (IS_DG2(i915)) {
> + if (IS_PONTEVECCHIO(i915)) {
> + table->size = ARRAY_SIZE(pvc_mocs_table);
> + table->table = pvc_mocs_table;
> + table->n_entries = PVC_NUM_MOCS_ENTRIES;
> + table->uc_index = 1;
> + table->wb_index = 2;
> + table->unused_entries_index = 2;
> + } else if (IS_DG2(i915)) {
> if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0)) {
> table->size = ARRAY_SIZE(dg2_mocs_table_g10_ax);
> table->table = dg2_mocs_table_g10_ax;
> @@ -622,6 +642,8 @@ void intel_set_mocs_index(struct intel_gt *gt)
>
> get_mocs_settings(gt->i915, );
> gt->mocs.uc_index = table.uc_index;
> + if (HAS_L3_CCS_READ(gt->i915))
> + gt->mocs.wb_index = table.wb_index;
> }
>
> void intel_mocs_init(struct intel_gt *gt)
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index a05c4b99b3fb..a656d9c2ca2b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1994,7 +1994,7 @@ void intel_engine_apply_whitelist(struct
> intel_engine_cs *engine)
> static void
> engine_fake_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
> {
> - u8 mocs;
> + u8 mocs_w, mocs_r;
>
> /*
>* RING_CMD_CCTL are need to be programed to un-cached
> @@ -2002,11 +2002,18 @@ engine_fake_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
>* Streamers on Gen12 onward platforms.
>*/
> if (GRAPHICS_VER(engine->i915) >= 12) {
> - mocs = engine->gt->mocs.uc_index;
> + if (HAS_L3_CCS_READ(engine->i915) &&
> + engine->class == COMPUTE_CLASS)
> + mocs_r = engine->gt->mocs.wb_index;
> + else
> + mocs_r = engine->gt->mocs.uc_index;
> +
> + mocs_w = engine->gt->mocs.uc_index;
> +
> wa_masked_field_set(wal,
>
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915/gt: BUG_ON unexpected NULL at scatterlist walking
On Mon, 02 May 2022, Ramalingam C wrote:
> While locating the start of ccs scatterlist in smem scatterlist, that has
> to be the size of lmem obj size + corresponding ccs data size, report bug
> if scatterlist terminate before that length.
>
> v2:
> s/GEM_BUG_ON/BUG_ON with more commenting [Matt]
> v3:
> Converted GEM_BUG_ON into BUG_ON with more documentation [Matt]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Matthew Auld (v1)
> ---
> drivers/gpu/drm/i915/gt/intel_migrate.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 9d552f30b627..168d17b6f48a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -687,6 +687,16 @@ static void get_ccs_sg_sgt(struct sgt_dma *it, u32
> bytes_to_cpy)
> bytes_to_cpy -= len;
>
> it->sg = __sg_next(it->sg);
> +
> + /*
> + * On Flat-CCS capable platform when we back the lmem pages with
> + * smem pages we add extra pages at the end of the smem
> + * scatterlist, to store the ccs data corresponding to the lmem
> + * pages. get_ccs_sg_sgt() is called to get the pointer for the
> + * start of the extra pages added at the end of smem
> scatterlist.
> + * So scatterlist can't end at or before bytes_to_cpy.
> + */
> + BUG_ON(!it->sg);
Why would you have to bring the entire kernel down in this case? Why not
just let it oops on the NULL pointer dereference?
I'd prefer nuking *all* of the current BUG/BUG_ON in the driver, and not
add any single one back.
BR,
Jani.
> it->dma = sg_dma_address(it->sg);
> it->max = it->dma + sg_dma_len(it->sg);
> } while (bytes_to_cpy);
> @@ -748,8 +758,10 @@ intel_context_migrate_copy(struct intel_context *ce,
>* Need to fix it.
>*/
> ccs_bytes_to_cpy = src_sz != dst_sz ? GET_CCS_BYTES(i915,
> bytes_to_cpy) : 0;
> - if (ccs_bytes_to_cpy)
> + if (ccs_bytes_to_cpy) {
> + WARN_ON(abs(src_sz - dst_sz) < ccs_bytes_to_cpy);
> get_ccs_sg_sgt(_ccs, bytes_to_cpy);
> + }
> }
>
> src_offset = 0;
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 11/11] drm/i915/pvc: read fuses for link copy engines
From: Lucas De Marchi
The new Link Copy engines in PVC may be fused off according to the
mslice_mask. Each bit of the MEML3_EN_MASK we read from the
GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
Bspec: 44483
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c6e93db134b1..d10cdeff5072 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -686,6 +686,33 @@ static void engine_mask_apply_compute_fuses(struct
intel_gt *gt)
}
}
+static void engine_mask_apply_copy_fuses(struct intel_gt *gt)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_gt_info *info = >info;
+ unsigned long meml3_mask;
+ u8 quad;
+
+ meml3_mask = intel_uncore_read(gt->uncore, GEN10_MIRROR_FUSE3);
+ meml3_mask = REG_FIELD_GET(GEN12_MEML3_EN_MASK, meml3_mask);
+
+ /*
+* Link Copy engines may be fused off according to meml3_mask. Each
+* bit is a quad that houses 2 Link Copy and two Sub Copy engines.
+*/
+ for_each_clear_bit(quad, _mask, GEN12_MAX_MSLICES) {
+ intel_engine_mask_t mask = GENMASK(BCS1 + quad * 2 + 1,
+ BCS1 + quad * 2);
+
+ if (mask & info->engine_mask) {
+ drm_dbg(>drm, "bcs%u fused off\n", quad * 2 + 1);
+ drm_dbg(>drm, "bcs%u fused off\n", quad * 2 + 2);
+
+ info->engine_mask &= ~mask;
+ }
+ }
+}
+
/*
* Determine which engines are fused off in our particular hardware.
* Note that we have a catch-22 situation where we need to be able to access
@@ -768,6 +795,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
GEM_BUG_ON(vebox_mask != VEBOX_MASK(gt));
engine_mask_apply_compute_fuses(gt);
+ engine_mask_apply_copy_fuses(gt);
return info->engine_mask;
}
--
2.35.1
[Intel-gfx] [PATCH 08/11] drm/i915/pvc: Interrupt support for new copy engines
This patch adds the interrupt handler support for new copy engines. Bspec: 54030 Original-author: CQ Tang Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_irq.c | 16 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 2 files changed, 20 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c b/drivers/gpu/drm/i915/gt/intel_gt_irq.c index 88b4becfcb17..3a72d4fd0214 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c @@ -193,6 +193,14 @@ void gen11_gt_irq_reset(struct intel_gt *gt) /* Restore masks irqs on RCS, BCS, VCS and VECS engines. */ intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~0); intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK,~0); + if (HAS_ENGINE(gt, BCS1) || HAS_ENGINE(gt, BCS2)) + intel_uncore_write(uncore, XEHPC_BCS1_BCS2_INTR_MASK, ~0); + if (HAS_ENGINE(gt, BCS3) || HAS_ENGINE(gt, BCS4)) + intel_uncore_write(uncore, XEHPC_BCS3_BCS4_INTR_MASK, ~0); + if (HAS_ENGINE(gt, BCS5) || HAS_ENGINE(gt, BCS6)) + intel_uncore_write(uncore, XEHPC_BCS5_BCS6_INTR_MASK, ~0); + if (HAS_ENGINE(gt, BCS7) || HAS_ENGINE(gt, BCS8)) + intel_uncore_write(uncore, XEHPC_BCS7_BCS8_INTR_MASK, ~0); intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~0); intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~0); if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5)) @@ -248,6 +256,14 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt) /* Unmask irqs on RCS, BCS, VCS and VECS engines. */ intel_uncore_write(uncore, GEN11_RCS0_RSVD_INTR_MASK, ~smask); intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK, ~smask); + if (HAS_ENGINE(gt, BCS1) || HAS_ENGINE(gt, BCS2)) + intel_uncore_write(uncore, XEHPC_BCS1_BCS2_INTR_MASK, ~dmask); + if (HAS_ENGINE(gt, BCS3) || HAS_ENGINE(gt, BCS4)) + intel_uncore_write(uncore, XEHPC_BCS3_BCS4_INTR_MASK, ~dmask); + if (HAS_ENGINE(gt, BCS5) || HAS_ENGINE(gt, BCS6)) + intel_uncore_write(uncore, XEHPC_BCS5_BCS6_INTR_MASK, ~dmask); + if (HAS_ENGINE(gt, BCS7) || HAS_ENGINE(gt, BCS8)) + intel_uncore_write(uncore, XEHPC_BCS7_BCS8_INTR_MASK, ~dmask); intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~dmask); intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~dmask); if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5)) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index aa2c0974b02c..fe09288a3145 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1529,6 +1529,10 @@ #define GEN11_GUNIT_CSME_INTR_MASK _MMIO(0x1900f4) #define GEN12_CCS0_CCS1_INTR_MASK _MMIO(0x190100) #define GEN12_CCS2_CCS3_INTR_MASK _MMIO(0x190104) +#define XEHPC_BCS1_BCS2_INTR_MASK _MMIO(0x190110) +#define XEHPC_BCS3_BCS4_INTR_MASK _MMIO(0x190114) +#define XEHPC_BCS5_BCS6_INTR_MASK _MMIO(0x190118) +#define XEHPC_BCS7_BCS8_INTR_MASK _MMIO(0x19011c) #define GEN12_SFC_DONE(n) _MMIO(0x1cc000 + (n) * 0x1000) -- 2.35.1
[Intel-gfx] [PATCH 10/11] drm/i915/pvc: skip all copy engines from aux table invalidate
From: Lucas De Marchi
As we have more copy engines now, mask all of them from aux table
invalidate.
Cc: Prathap Kumar Valsan
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 0de17b568b41..f262aed94ef3 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -275,7 +275,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (!HAS_FLAT_CCS(rq->engine->i915) &&
(rq->engine->class == VIDEO_DECODE_CLASS ||
rq->engine->class == VIDEO_ENHANCEMENT_CLASS)) {
- aux_inv = rq->engine->mask & ~BIT(BCS0);
+ aux_inv = rq->engine->mask & ~GENMASK(BCS8, BCS0);
if (aux_inv)
cmd += 4;
}
--
2.35.1
[Intel-gfx] [PATCH 01/11] drm/i915/pvc: add initial Ponte Vecchio definitions
From: Stuart Summers
Additional blitter and media engines will be enabled later.
Bspec: 44481, 44482
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 21 +
drivers/gpu/drm/i915/intel_device_info.c | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 1 +
4 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 24111bf42ce0..2dddc27a1b0e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1062,6 +1062,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define IS_ALDERLAKE_P(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_P)
#define IS_XEHPSDV(dev_priv) IS_PLATFORM(dev_priv, INTEL_XEHPSDV)
#define IS_DG2(dev_priv) IS_PLATFORM(dev_priv, INTEL_DG2)
+#define IS_PONTEVECCHIO(dev_priv) IS_PLATFORM(dev_priv, INTEL_PONTEVECCHIO)
+
#define IS_DG2_G10(dev_priv) \
IS_SUBPLATFORM(dev_priv, INTEL_DG2, INTEL_SUBPLATFORM_G10)
#define IS_DG2_G11(dev_priv) \
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7739d6c33481..498708b33924 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1074,6 +1074,27 @@ static const struct intel_device_info ats_m_info = {
.require_force_probe = 1,
};
+#define XE_HPC_FEATURES \
+ XE_HP_FEATURES, \
+ .dma_mask_size = 52
+
+__maybe_unused
+static const struct intel_device_info pvc_info = {
+ XE_HPC_FEATURES,
+ XE_HPM_FEATURES,
+ DGFX_FEATURES,
+ .graphics.rel = 60,
+ .media.rel = 60,
+ PLATFORM(INTEL_PONTEVECCHIO),
+ .display = { 0 },
+ .has_flat_ccs = 0,
+ .platform_engine_mask =
+ BIT(BCS0) |
+ BIT(VCS0) |
+ BIT(CCS0) | BIT(CCS1) | BIT(CCS2) | BIT(CCS3),
+ .require_force_probe = 1,
+};
+
#undef PLATFORM
/*
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 63e05cd15a90..f0bf23726ed8 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -72,6 +72,7 @@ static const char * const platform_names[] = {
PLATFORM_NAME(ALDERLAKE_P),
PLATFORM_NAME(XEHPSDV),
PLATFORM_NAME(DG2),
+ PLATFORM_NAME(PONTEVECCHIO),
};
#undef PLATFORM_NAME
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 20c351c8d5bd..e7d2cf7d65c8 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -88,6 +88,7 @@ enum intel_platform {
INTEL_ALDERLAKE_P,
INTEL_XEHPSDV,
INTEL_DG2,
+ INTEL_PONTEVECCHIO,
INTEL_MAX_PLATFORMS
};
--
2.35.1
[Intel-gfx] [PATCH 09/11] drm/i915/pvc: Reset support for new copy engines
This patch adds the reset support for new copy engines
in PVC.
Bspec: 52549
Original-author: CQ Tang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 44 +--
2 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4532c3ea9ace..c6e93db134b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -390,6 +390,14 @@ static u32 get_reset_domain(u8 ver, enum intel_engine_id
id)
static const u32 engine_reset_domains[] = {
[RCS0] = GEN11_GRDOM_RENDER,
[BCS0] = GEN11_GRDOM_BLT,
+ [BCS1] = XEHPC_GRDOM_BLT1,
+ [BCS2] = XEHPC_GRDOM_BLT2,
+ [BCS3] = XEHPC_GRDOM_BLT3,
+ [BCS4] = XEHPC_GRDOM_BLT4,
+ [BCS5] = XEHPC_GRDOM_BLT5,
+ [BCS6] = XEHPC_GRDOM_BLT6,
+ [BCS7] = XEHPC_GRDOM_BLT7,
+ [BCS8] = XEHPC_GRDOM_BLT8,
[VCS0] = GEN11_GRDOM_MEDIA,
[VCS1] = GEN11_GRDOM_MEDIA2,
[VCS2] = GEN11_GRDOM_MEDIA3,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index fe09288a3145..98ede9c93f00 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -597,24 +597,32 @@
/* GEN11 changed all bit defs except for FULL & RENDER */
#define GEN11_GRDOM_FULL GEN6_GRDOM_FULL
#define GEN11_GRDOM_RENDER GEN6_GRDOM_RENDER
-#define GEN11_GRDOM_BLT (1 << 2)
-#define GEN11_GRDOM_GUC (1 << 3)
-#define GEN11_GRDOM_MEDIA(1 << 5)
-#define GEN11_GRDOM_MEDIA2 (1 << 6)
-#define GEN11_GRDOM_MEDIA3 (1 << 7)
-#define GEN11_GRDOM_MEDIA4 (1 << 8)
-#define GEN11_GRDOM_MEDIA5 (1 << 9)
-#define GEN11_GRDOM_MEDIA6 (1 << 10)
-#define GEN11_GRDOM_MEDIA7 (1 << 11)
-#define GEN11_GRDOM_MEDIA8 (1 << 12)
-#define GEN11_GRDOM_VECS (1 << 13)
-#define GEN11_GRDOM_VECS2(1 << 14)
-#define GEN11_GRDOM_VECS3(1 << 15)
-#define GEN11_GRDOM_VECS4(1 << 16)
-#define GEN11_GRDOM_SFC0 (1 << 17)
-#define GEN11_GRDOM_SFC1 (1 << 18)
-#define GEN11_GRDOM_SFC2 (1 << 19)
-#define GEN11_GRDOM_SFC3 (1 << 20)
+#define XEHPC_GRDOM_BLT8 REG_BIT(31)
+#define XEHPC_GRDOM_BLT7 REG_BIT(30)
+#define XEHPC_GRDOM_BLT6 REG_BIT(29)
+#define XEHPC_GRDOM_BLT5 REG_BIT(28)
+#define XEHPC_GRDOM_BLT4 REG_BIT(27)
+#define XEHPC_GRDOM_BLT3 REG_BIT(26)
+#define XEHPC_GRDOM_BLT2 REG_BIT(25)
+#define XEHPC_GRDOM_BLT1 REG_BIT(24)
+#define GEN11_GRDOM_SFC3 REG_BIT(20)
+#define GEN11_GRDOM_SFC2 REG_BIT(19)
+#define GEN11_GRDOM_SFC1 REG_BIT(18)
+#define GEN11_GRDOM_SFC0 REG_BIT(17)
+#define GEN11_GRDOM_VECS4REG_BIT(16)
+#define GEN11_GRDOM_VECS3REG_BIT(15)
+#define GEN11_GRDOM_VECS2REG_BIT(14)
+#define GEN11_GRDOM_VECS REG_BIT(13)
+#define GEN11_GRDOM_MEDIA8 REG_BIT(12)
+#define GEN11_GRDOM_MEDIA7 REG_BIT(11)
+#define GEN11_GRDOM_MEDIA6 REG_BIT(10)
+#define GEN11_GRDOM_MEDIA5 REG_BIT(9)
+#define GEN11_GRDOM_MEDIA4 REG_BIT(8)
+#define GEN11_GRDOM_MEDIA3 REG_BIT(7)
+#define GEN11_GRDOM_MEDIA2 REG_BIT(6)
+#define GEN11_GRDOM_MEDIAREG_BIT(5)
+#define GEN11_GRDOM_GUC REG_BIT(3)
+#define GEN11_GRDOM_BLT REG_BIT(2)
#define GEN11_VCS_SFC_RESET_BIT(instance)(GEN11_GRDOM_SFC0 <<
((instance) >> 1))
#define GEN11_VECS_SFC_RESET_BIT(instance) (GEN11_GRDOM_SFC0 << (instance))
--
2.35.1
[Intel-gfx] [PATCH 05/11] drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL
From: Stuart Summers
Although we already strip 3D-specific flags from PIPE_CONTROL
instructions when submitting to a compute engine, there are some
additional flags that need to be removed when the platform as a whole
lacks a 3D pipeline. Add those restrictions here.
Bspec: 47112
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 18 --
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 12 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 3 ++-
5 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 9529c5455bc3..0de17b568b41 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -196,8 +196,10 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
- if (engine->class == COMPUTE_CLASS)
- flags &= ~PIPE_CONTROL_3D_FLAGS;
+ if (LACKS_3D_PIPELINE(engine->i915))
+ flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+ else if (engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
cs = intel_ring_begin(rq, 6);
if (IS_ERR(cs))
@@ -226,8 +228,10 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
flags |= PIPE_CONTROL_CS_STALL;
- if (engine->class == COMPUTE_CLASS)
- flags &= ~PIPE_CONTROL_3D_FLAGS;
+ if (LACKS_3D_PIPELINE(engine->i915))
+ flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+ else if (engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
if (!HAS_FLAT_CCS(rq->engine->i915))
count = 8 + 4;
@@ -662,8 +666,10 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs)
/* Wa_1409600907 */
flags |= PIPE_CONTROL_DEPTH_STALL;
- if (rq->engine->class == COMPUTE_CLASS)
- flags &= ~PIPE_CONTROL_3D_FLAGS;
+ if (LACKS_3D_PIPELINE(rq->engine->i915))
+ flags &= ~PIPE_CONTROL_3D_ARCH_FLAGS;
+ else if (rq->engine->class == COMPUTE_CLASS)
+ flags &= ~PIPE_CONTROL_3D_ENGINE_FLAGS;
cs = gen12_emit_ggtt_write_rcs(cs,
rq->fence.seqno,
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index e52718a87f14..5eaf54e72635 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -286,8 +286,8 @@
#define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1<<0)
#define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */
-/* 3D-related flags can't be set on compute engine */
-#define PIPE_CONTROL_3D_FLAGS (\
+/* 3D-related flags that can't be set on _engines_ that lack a 3D pipeline */
+#define PIPE_CONTROL_3D_ENGINE_FLAGS (\
PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH | \
PIPE_CONTROL_DEPTH_CACHE_FLUSH | \
PIPE_CONTROL_TILE_CACHE_FLUSH | \
@@ -298,6 +298,14 @@
PIPE_CONTROL_VF_CACHE_INVALIDATE | \
PIPE_CONTROL_GLOBAL_SNAPSHOT_RESET)
+/* 3D-related flags that can't be set on _platforms_ that lack a 3D pipeline */
+#define PIPE_CONTROL_3D_ARCH_FLAGS ( \
+ PIPE_CONTROL_3D_ENGINE_FLAGS | \
+ PIPE_CONTROL_INDIRECT_STATE_DISABLE | \
+ PIPE_CONTROL_FLUSH_ENABLE | \
+ PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE | \
+ PIPE_CONTROL_DC_FLUSH_ENABLE)
+
#define MI_MATH(x) MI_INSTR(0x1a, (x) - 1)
#define MI_MATH_INSTR(opcode, op1, op2) ((opcode) << 20 | (op1) << 10 | (op2))
/* Opcodes for MI_MATH_INSTR */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8c8e7308502b..55c6b9c4e476 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1402,6 +1402,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_MBUS_JOINING(i915) (IS_ALDERLAKE_P(i915))
+#define LACKS_3D_PIPELINE(i915)(INTEL_INFO(i915)->lacks_3d_pipeline)
+
/* i915_gem.c */
void i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_cleanup_early(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 07722cdf63ac..14e0e8225324 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1077,7 +1077,8 @@ static const struct intel_device_info ats_m_info = {
#define XE_HPC_FEATURES \
XE_HP_FEATURES, \
.dma_mask_size =
[Intel-gfx] [PATCH 03/11] drm/i915/pvc: Define MOCS table for PVC
From: Ayaz A Siddiqui
Bspec: 45101, 72161
Signed-off-by: Ayaz A Siddiqui
Signed-off-by: Fei Yang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/intel_mocs.c| 24 -
drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 ---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h| 1 +
6 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index b06611c1d4ad..7853ea194ea6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -221,6 +221,7 @@ struct intel_gt {
struct {
u8 uc_index;
+ u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
} mocs;
struct intel_pxp pxp;
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index c4c37585ae8c..265812589f87 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -23,6 +23,7 @@ struct drm_i915_mocs_table {
unsigned int n_entries;
const struct drm_i915_mocs_entry *table;
u8 uc_index;
+ u8 wb_index; /* Only for platforms listed in Bspec: 72161 */
u8 unused_entries_index;
};
@@ -47,6 +48,7 @@ struct drm_i915_mocs_table {
/* Helper defines */
#define GEN9_NUM_MOCS_ENTRIES 64 /* 63-64 are reserved, but configured. */
+#define PVC_NUM_MOCS_ENTRIES 3
/* (e)LLC caching options */
/*
@@ -394,6 +396,17 @@ static const struct drm_i915_mocs_entry
dg2_mocs_table_g10_ax[] = {
MOCS_ENTRY(3, 0, L3_3_WB | L3_LKUP(1)),
};
+static const struct drm_i915_mocs_entry pvc_mocs_table[] = {
+ /* Error */
+ MOCS_ENTRY(0, 0, L3_3_WB),
+
+ /* UC */
+ MOCS_ENTRY(1, 0, L3_1_UC),
+
+ /* WB */
+ MOCS_ENTRY(2, 0, L3_3_WB),
+};
+
enum {
HAS_GLOBAL_MOCS = BIT(0),
HAS_ENGINE_MOCS = BIT(1),
@@ -423,7 +436,14 @@ static unsigned int get_mocs_settings(const struct
drm_i915_private *i915,
memset(table, 0, sizeof(struct drm_i915_mocs_table));
table->unused_entries_index = I915_MOCS_PTE;
- if (IS_DG2(i915)) {
+ if (IS_PONTEVECCHIO(i915)) {
+ table->size = ARRAY_SIZE(pvc_mocs_table);
+ table->table = pvc_mocs_table;
+ table->n_entries = PVC_NUM_MOCS_ENTRIES;
+ table->uc_index = 1;
+ table->wb_index = 2;
+ table->unused_entries_index = 2;
+ } else if (IS_DG2(i915)) {
if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_A0, STEP_B0)) {
table->size = ARRAY_SIZE(dg2_mocs_table_g10_ax);
table->table = dg2_mocs_table_g10_ax;
@@ -622,6 +642,8 @@ void intel_set_mocs_index(struct intel_gt *gt)
get_mocs_settings(gt->i915, );
gt->mocs.uc_index = table.uc_index;
+ if (HAS_L3_CCS_READ(gt->i915))
+ gt->mocs.wb_index = table.wb_index;
}
void intel_mocs_init(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index a05c4b99b3fb..a656d9c2ca2b 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1994,7 +1994,7 @@ void intel_engine_apply_whitelist(struct intel_engine_cs
*engine)
static void
engine_fake_wa_init(struct intel_engine_cs *engine, struct i915_wa_list *wal)
{
- u8 mocs;
+ u8 mocs_w, mocs_r;
/*
* RING_CMD_CCTL are need to be programed to un-cached
@@ -2002,11 +2002,18 @@ engine_fake_wa_init(struct intel_engine_cs *engine,
struct i915_wa_list *wal)
* Streamers on Gen12 onward platforms.
*/
if (GRAPHICS_VER(engine->i915) >= 12) {
- mocs = engine->gt->mocs.uc_index;
+ if (HAS_L3_CCS_READ(engine->i915) &&
+ engine->class == COMPUTE_CLASS)
+ mocs_r = engine->gt->mocs.wb_index;
+ else
+ mocs_r = engine->gt->mocs.uc_index;
+
+ mocs_w = engine->gt->mocs.uc_index;
+
wa_masked_field_set(wal,
RING_CMD_CCTL(engine->mmio_base),
CMD_CCTL_MOCS_MASK,
- CMD_CCTL_MOCS_OVERRIDE(mocs, mocs));
+ CMD_CCTL_MOCS_OVERRIDE(mocs_w, mocs_r));
}
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2dddc27a1b0e..8c8e7308502b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1369,6 +1369,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_LSPCON(dev_priv) (IS_DISPLAY_VER(dev_priv, 9, 10))
[Intel-gfx] [PATCH 02/11] drm/i915/pvc: Add forcewake support
Add PVC's forcewake ranges.
Bspec: 67609
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_uncore.c | 150 +-
drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +
2 files changed, 151 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 83517a703eb6..3352065635e8 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1080,6 +1080,45 @@ static const struct i915_range dg2_shadowed_regs[] = {
{ .start = 0x1F8510, .end = 0x1F8550 },
};
+static const struct i915_range pvc_shadowed_regs[] = {
+ { .start = 0x2030, .end = 0x2030 },
+ { .start = 0x2510, .end = 0x2550 },
+ { .start = 0xA008, .end = 0xA00C },
+ { .start = 0xA188, .end = 0xA188 },
+ { .start = 0xA278, .end = 0xA278 },
+ { .start = 0xA540, .end = 0xA56C },
+ { .start = 0xC4C8, .end = 0xC4C8 },
+ { .start = 0xC4E0, .end = 0xC4E0 },
+ { .start = 0xC600, .end = 0xC600 },
+ { .start = 0xC658, .end = 0xC658 },
+ { .start = 0x22030, .end = 0x22030 },
+ { .start = 0x22510, .end = 0x22550 },
+ { .start = 0x1C0030, .end = 0x1C0030 },
+ { .start = 0x1C0510, .end = 0x1C0550 },
+ { .start = 0x1C4030, .end = 0x1C4030 },
+ { .start = 0x1C4510, .end = 0x1C4550 },
+ { .start = 0x1C8030, .end = 0x1C8030 },
+ { .start = 0x1C8510, .end = 0x1C8550 },
+ { .start = 0x1D0030, .end = 0x1D0030 },
+ { .start = 0x1D0510, .end = 0x1D0550 },
+ { .start = 0x1D4030, .end = 0x1D4030 },
+ { .start = 0x1D4510, .end = 0x1D4550 },
+ { .start = 0x1D8030, .end = 0x1D8030 },
+ { .start = 0x1D8510, .end = 0x1D8550 },
+ { .start = 0x1E0030, .end = 0x1E0030 },
+ { .start = 0x1E0510, .end = 0x1E0550 },
+ { .start = 0x1E4030, .end = 0x1E4030 },
+ { .start = 0x1E4510, .end = 0x1E4550 },
+ { .start = 0x1E8030, .end = 0x1E8030 },
+ { .start = 0x1E8510, .end = 0x1E8550 },
+ { .start = 0x1F0030, .end = 0x1F0030 },
+ { .start = 0x1F0510, .end = 0x1F0550 },
+ { .start = 0x1F4030, .end = 0x1F4030 },
+ { .start = 0x1F4510, .end = 0x1F4550 },
+ { .start = 0x1F8030, .end = 0x1F8030 },
+ { .start = 0x1F8510, .end = 0x1F8550 },
+};
+
static int mmio_range_cmp(u32 key, const struct i915_range *range)
{
if (key < range->start)
@@ -1490,6 +1529,111 @@ static const struct intel_forcewake_range
__dg2_fw_ranges[] = {
XEHP_FWRANGES(FORCEWAKE_RENDER)
};
+/*
+ * *Must* be sorted by offset ranges! See intel_fw_table_check().
+ *
+ * Note that the spec lists several reserved/unused ranges that don't actually
+ * contain any registers. In the table below we'll combine those reserved
+ * ranges with either the preceding or following range to keep the table small
+ * and lookups fast.
+ */
+static const struct intel_forcewake_range __pvc_fw_ranges[] = {
+ GEN_FW_RANGE(0x0, 0xaff, 0),
+ GEN_FW_RANGE(0xb00, 0xbff, FORCEWAKE_GT),
+ GEN_FW_RANGE(0xc00, 0xfff, 0),
+ GEN_FW_RANGE(0x1000, 0x1fff, FORCEWAKE_GT),
+ GEN_FW_RANGE(0x2000, 0x26ff, FORCEWAKE_RENDER),
+ GEN_FW_RANGE(0x2700, 0x2fff, FORCEWAKE_GT),
+ GEN_FW_RANGE(0x3000, 0x3fff, FORCEWAKE_RENDER),
+ GEN_FW_RANGE(0x4000, 0x813f, FORCEWAKE_GT), /*
+ 0x4000 - 0x4aff: gt
+ 0x4b00 - 0x4fff: reserved
+ 0x5000 - 0x51ff: gt
+ 0x5200 - 0x52ff: reserved
+ 0x5300 - 0x53ff: gt
+ 0x5400 - 0x7fff: reserved
+ 0x8000 - 0x813f: gt */
+ GEN_FW_RANGE(0x8140, 0x817f, FORCEWAKE_RENDER),
+ GEN_FW_RANGE(0x8180, 0x81ff, 0),
+ GEN_FW_RANGE(0x8200, 0x94cf, FORCEWAKE_GT), /*
+ 0x8200 - 0x82ff: gt
+ 0x8300 - 0x84ff: reserved
+ 0x8500 - 0x887f: gt
+ 0x8880 - 0x8a7f: reserved
+ 0x8a80 - 0x8aff: gt
+ 0x8b00 - 0x8fff: reserved
+ 0x9000 - 0x947f: gt
+ 0x9480 - 0x94cf: reserved */
+ GEN_FW_RANGE(0x94d0, 0x955f, FORCEWAKE_RENDER),
+ GEN_FW_RANGE(0x9560, 0x967f, 0), /*
+ 0x9560 - 0x95ff: always on
+ 0x9600 - 0x967f: reserved */
+ GEN_FW_RANGE(0x9680, 0x97ff, FORCEWAKE_RENDER), /*
+ 0x9680 - 0x96ff: render
+ 0x9700 - 0x97ff: reserved */
+ GEN_FW_RANGE(0x9800, 0xcfff, FORCEWAKE_GT), /*
+ 0x9800 - 0xb4ff: gt
+ 0xb500 - 0xbfff: reserved
+ 0xc000 - 0xcfff: gt */
+ GEN_FW_RANGE(0xd000, 0xd3ff, 0),
+ GEN_FW_RANGE(0xd400, 0xdbff, FORCEWAKE_GT),
+ GEN_FW_RANGE(0xdc00, 0xdcff, FORCEWAKE_RENDER),
+ GEN_FW_RANGE(0xdd00, 0xde7f, FORCEWAKE_GT), /*
+ 0xdd00 - 0xddff: gt
+ 0xde00 - 0xde7f: reserved */
+
[Intel-gfx] [PATCH 07/11] drm/i915/pvc: Engines definitions for new copy engines
This patch adds the basic definitions needed to support
new copy engines. Also updating the cmd_info to accommodate
new engines, as the engine id's of legacy engines have been
changed.
Original-author: CQ Tang
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 56
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +++-
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 8 +++
drivers/gpu/drm/i915/gvt/cmd_parser.c| 2 +-
drivers/gpu/drm/i915/i915_reg.h | 8 +++
5 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 14c6ddbbfde8..4532c3ea9ace 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -71,6 +71,62 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 6, .base = BLT_RING_BASE }
},
},
+ [BCS1] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 1,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS1_RING_BASE }
+ },
+ },
+ [BCS2] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 2,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS2_RING_BASE }
+ },
+ },
+ [BCS3] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 3,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS3_RING_BASE }
+ },
+ },
+ [BCS4] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 4,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS4_RING_BASE }
+ },
+ },
+ [BCS5] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 5,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS5_RING_BASE }
+ },
+ },
+ [BCS6] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 6,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS6_RING_BASE }
+ },
+ },
+ [BCS7] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 7,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS7_RING_BASE }
+ },
+ },
+ [BCS8] = {
+ .class = COPY_ENGINE_CLASS,
+ .instance = 8,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHPC_BCS8_RING_BASE }
+ },
+ },
[VCS0] = {
.class = VIDEO_DECODE_CLASS,
.instance = 0,
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 298f2cc7a879..356c15cdccf0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -35,7 +35,7 @@
#define OTHER_CLASS4
#define COMPUTE_CLASS 5
#define MAX_ENGINE_CLASS 5
-#define MAX_ENGINE_INSTANCE7
+#define MAX_ENGINE_INSTANCE8
#define I915_MAX_SLICES3
#define I915_MAX_SUBSLICES 8
@@ -107,6 +107,14 @@ struct i915_ctx_workarounds {
enum intel_engine_id {
RCS0 = 0,
BCS0,
+ BCS1,
+ BCS2,
+ BCS3,
+ BCS4,
+ BCS5,
+ BCS6,
+ BCS7,
+ BCS8,
VCS0,
VCS1,
VCS2,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index a0a49c16babd..aa2c0974b02c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1476,6 +1476,14 @@
#define GEN11_KCR(19)
#define GEN11_GTPM (16)
#define GEN11_BCS(15)
+#define XEHPC_BCS1 (14)
+#define XEHPC_BCS2 (13)
+#define XEHPC_BCS3 (12)
+#define XEHPC_BCS4 (11)
+#define XEHPC_BCS5 (10)
+#define XEHPC_BCS6 (9)
+#define XEHPC_BCS7 (8)
+#define XEHPC_BCS8 (23)
#define GEN12_CCS3 (7)
#define GEN12_CCS2 (6)
#define GEN12_CCS1 (5)
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index b9eb75a2b400..0ba2a3455d99 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -428,7 +428,7 @@ struct cmd_info {
#define R_VECS BIT(VECS0)
#define
[Intel-gfx] [PATCH 06/11] drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter engine
From: John Harrison
PVC adds extra blitter engines (in the following patch). The reset
selftest has a local array on the stack which is sized by the number
of engines. The increase pushes the size of this array to the point
where it trips the 'stack too large' compile warning. This patch takes
the allocation of the stack and makes it dynamic instead.
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 83ff4c2e57c5..3b9d82276db2 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -979,6 +979,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
enum intel_engine_id id, tmp;
struct hang h;
int err = 0;
+ struct active_engine *threads;
/* Check that issuing a reset on one engine does not interfere
* with any other engine.
@@ -996,8 +997,11 @@ static int __igt_reset_engines(struct intel_gt *gt,
h.ctx->sched.priority = 1024;
}
+ threads = kzalloc(sizeof(*threads) * I915_NUM_ENGINES, GFP_KERNEL);
+ if (!threads)
+ return -ENOMEM;
+
for_each_engine(engine, gt, id) {
- struct active_engine threads[I915_NUM_ENGINES] = {};
unsigned long device = i915_reset_count(global);
unsigned long count = 0, reported;
bool using_guc = intel_engine_uses_guc(engine);
@@ -1016,7 +1020,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
break;
}
- memset(threads, 0, sizeof(threads));
+ memset(threads, 0, sizeof(*threads) * I915_NUM_ENGINES);
for_each_engine(other, gt, tmp) {
struct task_struct *tsk;
@@ -1236,6 +1240,7 @@ static int __igt_reset_engines(struct intel_gt *gt,
break;
}
}
+ kfree(threads);
if (intel_gt_is_wedged(gt))
err = -EIO;
--
2.35.1
[Intel-gfx] [PATCH 04/11] drm/i915/pvc: Read correct RP_STATE_CAP register
The SoC registers, including RP_STATE_CAP, have moved to a new location in GTTMMADR on Ponte Vecchio. We need to update the register offset accordingly. Cc: Rodrigo Vivi Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_rps.c | 4 +++- drivers/gpu/drm/i915/i915_reg.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c b/drivers/gpu/drm/i915/gt/intel_rps.c index 3476a11f294c..3bd8415a0f1b 100644 --- a/drivers/gpu/drm/i915/gt/intel_rps.c +++ b/drivers/gpu/drm/i915/gt/intel_rps.c @@ -1075,7 +1075,9 @@ static u32 intel_rps_read_state_cap(struct intel_rps *rps) struct drm_i915_private *i915 = rps_to_i915(rps); struct intel_uncore *uncore = rps_to_uncore(rps); - if (IS_XEHPSDV(i915)) + if (IS_PONTEVECCHIO(i915)) + return intel_uncore_read(uncore, PVC_RP_STATE_CAP); + else if (IS_XEHPSDV(i915)) return intel_uncore_read(uncore, XEHPSDV_RP_STATE_CAP); else if (IS_GEN9_LP(i915)) return intel_uncore_read(uncore, BXT_RP_STATE_CAP); diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9ccb67eec1bd..4a3d7b96ef43 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -1846,6 +1846,7 @@ #define BXT_RP_STATE_CAP_MMIO(0x138170) #define GEN9_RP_STATE_LIMITS _MMIO(0x138148) #define XEHPSDV_RP_STATE_CAP _MMIO(0x250014) +#define PVC_RP_STATE_CAP _MMIO(0x281014) #define GT0_PERF_LIMIT_REASONS _MMIO(0x1381a8) #define GT0_PERF_LIMIT_REASONS_MASK 0xde3 -- 2.35.1
[Intel-gfx] [PATCH 00/11] i915: Introduce Ponte Vecchio
Ponte Vecchio (PVC) is a new GPU based on the Xe_HPC architecture. As a compute-focused platform, PVC has compute engines and enhanced copy engines, but no render engine (there is no geometry pipeline) and no display. This is just a handful of early enablement patches, including some initial support for the new copy engines (although we're not yet adding those to the platform's engine list or exposing them to userspace just yet). Ayaz A Siddiqui (1): drm/i915/pvc: Define MOCS table for PVC John Harrison (1): drm/i915/pvc: Reduce stack usage in reset selftest with extra blitter engine Lucas De Marchi (2): drm/i915/pvc: skip all copy engines from aux table invalidate drm/i915/pvc: read fuses for link copy engines Matt Roper (5): drm/i915/pvc: Add forcewake support drm/i915/pvc: Read correct RP_STATE_CAP register drm/i915/pvc: Engines definitions for new copy engines drm/i915/pvc: Interrupt support for new copy engines drm/i915/pvc: Reset support for new copy engines Stuart Summers (2): drm/i915/pvc: add initial Ponte Vecchio definitions drm/i915/pvc: Remove additional 3D flags from PIPE_CONTROL drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 20 ++- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 92 +++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 +- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 12 +- drivers/gpu/drm/i915/gt/intel_gt_irq.c| 16 ++ drivers/gpu/drm/i915/gt/intel_gt_regs.h | 56 --- drivers/gpu/drm/i915/gt/intel_gt_types.h | 1 + drivers/gpu/drm/i915/gt/intel_mocs.c | 24 ++- drivers/gpu/drm/i915/gt/intel_rps.c | 4 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 13 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 9 +- drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 6 + drivers/gpu/drm/i915/i915_pci.c | 23 +++ drivers/gpu/drm/i915/i915_reg.h | 9 ++ drivers/gpu/drm/i915/intel_device_info.c | 1 + drivers/gpu/drm/i915/intel_device_info.h | 5 +- drivers/gpu/drm/i915/intel_uncore.c | 150 +- drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 + 19 files changed, 417 insertions(+), 38 deletions(-) -- 2.35.1
Re: [Intel-gfx] [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu
On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam wrote: > > > > On 5/2/2022 8:41 PM, Mike Lothian wrote: > > On Wed, 27 Apr 2022 at 12:55, Mike Lothian wrote: > >> On Tue, 26 Apr 2022 at 17:36, Christian König > >> wrote: > >>> Hi Mike, > >>> > >>> sounds like somehow stitching together the SG table for PRIME doesn't > >>> work any more with this patch. > >>> > >>> Can you try with P2P DMA disabled? > >> -CONFIG_PCI_P2PDMA=y > >> +# CONFIG_PCI_P2PDMA is not set > >> > >> If that's what you're meaning, then there's no difference, I'll upload > >> my dmesg to the gitlab issue > >> > >>> Apart from that can you take a look Arun? > >>> > >>> Thanks, > >>> Christian. > > Hi > > > > Have you had any success in replicating this? > Hi Mike, > I couldn't replicate on my Raven APU machine. I see you have 2 cards > initialized, one is Renoir > and the other is Navy Flounder. Could you give some more details, are > you running Gravity Mark > on Renoir and what is your system RAM configuration? > > > > Cheers > > > > Mike > Hi It's a PRIME laptop, it failed on the RENOIR too, it caused a lockup, but systemd managed to capture it, I'll attach it to the issue I've got 64GB RAM, the 6800M has 12GB VRAM Cheers Mike
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Flat-CCS eviction enhancements (rev4)
== Series Details == Series: Flat-CCS eviction enhancements (rev4) URL : https://patchwork.freedesktop.org/series/102916/ State : warning == Summary == Error: dim checkpatch failed 848866286442 drm/i915/gt: BUG_ON unexpected NULL at scatterlist walking -:35: WARNING:AVOID_BUG: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON() #35: FILE: drivers/gpu/drm/i915/gt/intel_migrate.c:699: + BUG_ON(!it->sg); total: 0 errors, 1 warnings, 0 checks, 27 lines checked 84bf61a5d04c drm/i915/gt: optimize the ccs_sz calculation per chunk d7a232332a41 drm/i915/gt: Document the eviction of the Flat-CCS objects
[Intel-gfx] ✗ Fi.CI.IGT: failure for lrc selftest fixes (rev6)
== Series Details ==
Series: lrc selftest fixes (rev6)
URL : https://patchwork.freedesktop.org/series/101353/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11585_full -> Patchwork_101353v6_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_101353v6_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_101353v6_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 13)
--
Additional (3): pig-skl-6260u pig-kbl-iris pig-glk-j5005
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_101353v6_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@fences-dpms:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-iclb3/igt@i915_pm_...@fences-dpms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-iclb4/igt@i915_pm_...@fences-dpms.html
Warnings
* igt@kms_psr2_su@page_flip-nv12:
- shard-iclb: [SKIP][3] ([fdo#109642] / [fdo#111068] / [i915#658])
-> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-iclb4/igt@kms_psr2_su@page_flip-nv12.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-iclb2/igt@kms_psr2_su@page_flip-nv12.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@coherency:
- {shard-rkl}:[PASS][5] -> [INCOMPLETE][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-rkl-1/igt@i915_selftest@l...@coherency.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-rkl-5/igt@i915_selftest@l...@coherency.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-dg1-17/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-d.html
Known issues
Here are the changes found in Patchwork_101353v6_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ccs@block-copy-compressed:
- shard-iclb: NOTRUN -> [SKIP][8] ([i915#5327])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-iclb4/igt@gem_...@block-copy-compressed.html
* igt@gem_eio@in-flight-contexts-1us:
- shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#3063])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-tglb8/igt@gem_...@in-flight-contexts-1us.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-tglb1/igt@gem_...@in-flight-contexts-1us.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-kbl: NOTRUN -> [DMESG-WARN][11] ([i915#5076] /
[i915#5614]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-kbl4/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_balancer@parallel-keep-submit-fence:
- shard-iclb: NOTRUN -> [DMESG-WARN][12] ([i915#5614])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-iclb4/igt@gem_exec_balan...@parallel-keep-submit-fence.html
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-iclb: [PASS][13] -> [FAIL][14] ([i915#2842])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][15] -> [FAIL][16] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][17] -> [FAIL][18] ([i915#2842])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [PASS][19] -> [FAIL][20] ([i915#2842]) +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
[20]:
Re: [Intel-gfx] [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu
On Wed, 27 Apr 2022 at 12:55, Mike Lothian wrote: > > On Tue, 26 Apr 2022 at 17:36, Christian König > wrote: > > > > Hi Mike, > > > > sounds like somehow stitching together the SG table for PRIME doesn't > > work any more with this patch. > > > > Can you try with P2P DMA disabled? > > -CONFIG_PCI_P2PDMA=y > +# CONFIG_PCI_P2PDMA is not set > > If that's what you're meaning, then there's no difference, I'll upload > my dmesg to the gitlab issue > > > > > Apart from that can you take a look Arun? > > > > Thanks, > > Christian. Hi Have you had any success in replicating this? Cheers Mike
[Intel-gfx] ✓ Fi.CI.BAT: success for uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
== Series Details ==
Series: uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
URL : https://patchwork.freedesktop.org/series/103434/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11586 -> Patchwork_103434v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/index.html
Participating hosts (40 -> 42)
--
Additional (3): bat-rpls-1 bat-dg2-9 bat-dg1-6
Missing(1): fi-bsw-cyan
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103434v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {bat-dg2-8}:[PASS][1] -> [DMESG-FAIL][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg2-8/igt@i915_selftest@live@gem_contexts.html
* igt@kms_addfb_basic@bo-too-small:
- {bat-dg2-9}:NOTRUN -> [SKIP][3] +72 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg2-9/igt@kms_addfb_ba...@bo-too-small.html
* igt@kms_chamelium@common-hpd-after-suspend:
- {bat-rpls-1}: NOTRUN -> [INCOMPLETE][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-rpls-1/igt@kms_chamel...@common-hpd-after-suspend.html
Known issues
Here are the changes found in Patchwork_103434v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap@basic:
- bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#4083])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@gem_m...@basic.html
* igt@gem_tiled_blits@basic:
- bat-dg1-6: NOTRUN -> [SKIP][6] ([i915#4077]) +2 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@gem_tiled_bl...@basic.html
* igt@gem_tiled_pread_basic:
- bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4079]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#1155])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][9] ([i915#4418])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gtt:
- fi-bdw-5557u: [PASS][10] -> [DMESG-FAIL][11] ([i915#3674])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11586/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html
* igt@kms_addfb_basic@addfb25-x-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][12] ([i915#4212]) +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_addfb_ba...@addfb25-x-tiled-legacy.html
* igt@kms_addfb_basic@basic-y-tiled-legacy:
- bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#4215])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html
* igt@kms_chamelium@hdmi-edid-read:
- bat-dg1-6: NOTRUN -> [SKIP][14] ([fdo#111827]) +7 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- bat-dg1-6: NOTRUN -> [SKIP][15] ([i915#4103] / [i915#4213]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-load-detect:
- bat-dg1-6: NOTRUN -> [SKIP][16] ([fdo#109285])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@sprite_plane_onoff:
- bat-dg1-6: NOTRUN -> [SKIP][17] ([i915#1072] / [i915#4078]) +3
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-dg1-6: NOTRUN -> [SKIP][18] ([i915#3555])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103434v1/bat-dg1-6/igt@kms_setm...@basic-clone-single-crtc.html
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix race in __i915_vma_remove_closed
friendly ping.
I am not even myself completely convinced that this is the correct
patch and it might just workaround some issues, but list_debug.c does
check if a list was already deleted and throws an error if it was and
this patch indeed fixes this one issue as multiple threads could enter
__i915_vma_remove_closed on the same vma.
On Wed, Apr 20, 2022 at 11:57 AM Karol Herbst wrote:
>
> i915_vma_reopen checked if the vma is closed before without taking the
> lock. So multiple threads could attempt removing the vma.
>
> Instead the lock needs to be taken before actually checking.
>
> v2: move struct declaration
>
> Cc: Chris Wilson
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5732
> Signed-off-by: Karol Herbst
> ---
> drivers/gpu/drm/i915/i915_vma.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 162e8d83691b..2efdad2b43fa 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -1615,17 +1615,17 @@ void i915_vma_close(struct i915_vma *vma)
>
> static void __i915_vma_remove_closed(struct i915_vma *vma)
> {
> - struct intel_gt *gt = vma->vm->gt;
> -
> - spin_lock_irq(>closed_lock);
> list_del_init(>closed_link);
> - spin_unlock_irq(>closed_lock);
> }
>
> void i915_vma_reopen(struct i915_vma *vma)
> {
> + struct intel_gt *gt = vma->vm->gt;
> +
> + spin_lock_irq(>closed_lock);
> if (i915_vma_is_closed(vma))
> __i915_vma_remove_closed(vma);
> + spin_unlock_irq(>closed_lock);
> }
>
> static void force_unbind(struct i915_vma *vma)
> @@ -1641,6 +1641,7 @@ static void force_unbind(struct i915_vma *vma)
> static void release_references(struct i915_vma *vma, bool vm_ddestroy)
> {
> struct drm_i915_gem_object *obj = vma->obj;
> + struct intel_gt *gt = vma->vm->gt;
>
> GEM_BUG_ON(i915_vma_is_active(vma));
>
> @@ -1651,7 +1652,9 @@ static void release_references(struct i915_vma *vma,
> bool vm_ddestroy)
>
> spin_unlock(>vma.lock);
>
> + spin_lock_irq(>closed_lock);
> __i915_vma_remove_closed(vma);
> + spin_unlock_irq(>closed_lock);
>
> if (vm_ddestroy)
> i915_vm_resv_put(vma->vm);
> --
> 2.35.1
>
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
On 2022-05-02 10:27, Modem, Bhanuprakash wrote: > On Mon-02-05-2022 07:08 pm, Harry Wentland wrote: >> >> >> On 2022-05-02 09:28, Modem, Bhanuprakash wrote: >>> On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote: > -Original Message- > From: Intel-gfx On Behalf Of > Bhanuprakash Modem > Sent: Monday, April 11, 2022 3:21 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > amd- > g...@lists.freedesktop.org; jani.nik...@linux.intel.com; > ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2 > > Cc: Rodrigo Siqueira > Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector > debugfs to > drm > > As drm_connector already have the display_info, instead of creating > "output_bpc" debugfs in vendor specific driver, move the logic to the > drm > layer. > > This patch will also move "Current" bpc to the crtc debugfs from > connector > debugfs, since we are getting this info from crtc_state. > > Cc: Harry Wentland > Cc: Rodrigo Siqueira > Signed-off-by: Bhanuprakash Modem > Reported-by: kernel test robot > --- Reviewed-by: Arun R Murthy >>> >>> Thanks Arun, >>> >>> @Harry/@Rodrigo, If this change sounds good to you, can you please help >>> to push it? >>> >> >> This changes the output_bpc debugfs behavior on amdgpu and breaks >> the amd_max_bpc IGT test. I don't think we should merge this as-is. > > Yeah, I have floated the IGT changes to support this series: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.freedesktop.org%2Fseries%2F102387%2Fdata=05%7C01%7Charry.wentland%40amd.com%7C61d4e4a755a5449ec58308da2c47dd89%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637870984414230229%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=kge5PgzzX81hsFLBKyPfyv7vQpb1Gse72FWuiGtyoAQ%3Dreserved=0 > > > With this IGT change, we can merge this series as-is. I would like to > request you to review IGT patches too. > >> >> This patch also seems dependent on patch 1 of the series. Shouldn't >> they be merged together (please don't merge them as-is, though)? > > Yes, as other patches in this series are already reviewed, I think we > need to plan to merge all patches in this series together (If above IGT > & this patch looks good to you). > Thanks for the context again and apologies I haven't had the time to have a closer look so far. I'll go over these and the IGT patches today and get back to you. Harry > - Bhanu > >> >> Harry >> >>> - Bhanu >>> Thanks and Regards, Arun R Murthy >>> >
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
== Series Details == Series: uapi/drm/i915: Document memory residency and Flat-CCS capability of obj URL : https://patchwork.freedesktop.org/series/103434/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
On Mon-02-05-2022 07:08 pm, Harry Wentland wrote: On 2022-05-02 09:28, Modem, Bhanuprakash wrote: On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote: -Original Message- From: Intel-gfx On Behalf Of Bhanuprakash Modem Sent: Monday, April 11, 2022 3:21 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; amd- g...@lists.freedesktop.org; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2 Cc: Rodrigo Siqueira Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm As drm_connector already have the display_info, instead of creating "output_bpc" debugfs in vendor specific driver, move the logic to the drm layer. This patch will also move "Current" bpc to the crtc debugfs from connector debugfs, since we are getting this info from crtc_state. Cc: Harry Wentland Cc: Rodrigo Siqueira Signed-off-by: Bhanuprakash Modem Reported-by: kernel test robot --- Reviewed-by: Arun R Murthy Thanks Arun, @Harry/@Rodrigo, If this change sounds good to you, can you please help to push it? This changes the output_bpc debugfs behavior on amdgpu and breaks the amd_max_bpc IGT test. I don't think we should merge this as-is. Yeah, I have floated the IGT changes to support this series: https://patchwork.freedesktop.org/series/102387/ With this IGT change, we can merge this series as-is. I would like to request you to review IGT patches too. This patch also seems dependent on patch 1 of the series. Shouldn't they be merged together (please don't merge them as-is, though)? Yes, as other patches in this series are already reviewed, I think we need to plan to merge all patches in this series together (If above IGT & this patch looks good to you). - Bhanu Harry - Bhanu Thanks and Regards, Arun R Murthy
[Intel-gfx] [PATCH v3 3/3] drm/i915/gt: Document the eviction of the Flat-CCS objects
Capture the eviction details for Flat-CCS capable, lmem objects.
v2:
Fix the Flat-ccs capbility of lmem obj with smem residency
possibility [Thomas]
v3:
Fixed the suggestions [Matt]
Signed-off-by: Ramalingam C
cc: Thomas Hellstrom
cc: Matthew Auld
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index fc6975e55fae..509955885b93 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -485,16 +485,21 @@ static bool wa_1209644611_applies(int ver, u32 size)
* And CCS data can be copied in and out of CCS region through
* XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
*
- * When we exhaust the lmem, if the object's placements support smem, then we
can
- * directly decompress the compressed lmem object into smem and start using it
- * from smem itself.
+ * I915 supports Flat-CCS on lmem only objects. When an objects has smem in
+ * its preference list, on memory pressure, i915 needs to migrate the lmem
+ * content into smem. If the lmem object is Flat-CCS compressed by userspace,
+ * then i915 needs to decompress it. But I915 lack the required information
+ * for such decompression. Hence I915 supports Flat-CCS only on lmem only
objects.
*
- * But when we need to swapout the compressed lmem object into a smem region
- * though objects' placement doesn't support smem, then we copy the lmem
content
- * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
- * When the object is referred, lmem content will be swaped in along with
- * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresponding
- * location.
+ * When we exhaust the lmem, Flat-CCS capable objects' lmem backing memory can
+ * be temporarily evicted to smem, along with the auxiliary CCS state, where
+ * it can be potentially swapped-out at a later point, if required.
+ * If userspace later touches the evicted pages, then we always move
+ * the backing memory back to lmem, which includes restoring the saved CCS
state,
+ * and potentially performing any required swap-in.
+ *
+ * For the migration of the lmem objects with smem in placement list, such as
+ * {lmem, smem}, objects are treated as non Flat-CCS capable objects.
*/
static inline u32 *i915_flush_dw(u32 *cmd, u32 flags)
--
2.20.1
[Intel-gfx] [PATCH v3 2/3] drm/i915/gt: optimize the ccs_sz calculation per chunk
Calculate the ccs_sz that needs to be emitted based on the src
and dst pages emitted per chunk. And handle the return value of emit_pte
for the ccs pages.
v2:
ccs_sz moved to the reduced scope [Matt]
Signed-off-by: Ramalingam C
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 36 +
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 168d17b6f48a..fc6975e55fae 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -647,17 +647,9 @@ static int scatter_list_length(struct scatterlist *sg)
static void
calculate_chunk_sz(struct drm_i915_private *i915, bool src_is_lmem,
- int *src_sz, int *ccs_sz, u32 bytes_to_cpy,
- u32 ccs_bytes_to_cpy)
+ int *src_sz, u32 bytes_to_cpy, u32 ccs_bytes_to_cpy)
{
if (ccs_bytes_to_cpy) {
- /*
-* We can only copy the ccs data corresponding to
-* the CHUNK_SZ of lmem which is
-* GET_CCS_BYTES(i915, CHUNK_SZ))
-*/
- *ccs_sz = min_t(int, ccs_bytes_to_cpy, GET_CCS_BYTES(i915,
CHUNK_SZ));
-
if (!src_is_lmem)
/*
* When CHUNK_SZ is passed all the pages upto CHUNK_SZ
@@ -717,10 +709,10 @@ intel_context_migrate_copy(struct intel_context *ce,
struct drm_i915_private *i915 = ce->engine->i915;
u32 ccs_bytes_to_cpy = 0, bytes_to_cpy;
enum i915_cache_level ccs_cache_level;
- int src_sz, dst_sz, ccs_sz;
u32 src_offset, dst_offset;
u8 src_access, dst_access;
struct i915_request *rq;
+ int src_sz, dst_sz;
bool ccs_is_src;
int err;
@@ -803,7 +795,7 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
- calculate_chunk_sz(i915, src_is_lmem, _sz, _sz,
+ calculate_chunk_sz(i915, src_is_lmem, _sz,
bytes_to_cpy, ccs_bytes_to_cpy);
len = emit_pte(rq, _src, src_cache_level, src_is_lmem,
@@ -837,37 +829,35 @@ intel_context_migrate_copy(struct intel_context *ce,
bytes_to_cpy -= len;
if (ccs_bytes_to_cpy) {
+ int ccs_sz;
+
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
+ ccs_sz = GET_CCS_BYTES(i915, len);
err = emit_pte(rq, _ccs, ccs_cache_level, false,
ccs_is_src ? src_offset : dst_offset,
ccs_sz);
+ if (err < 0)
+ goto out_rq;
+ if (err < ccs_sz) {
+ err = -EINVAL;
+ goto out_rq;
+ }
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
- /*
-* Using max of src_sz and dst_sz, as we need to
-* pass the lmem size corresponding to the ccs
-* blocks we need to handle.
-*/
- ccs_sz = max_t(int, ccs_is_src ? ccs_sz : src_sz,
- ccs_is_src ? dst_sz : ccs_sz);
-
err = emit_copy_ccs(rq, dst_offset, dst_access,
- src_offset, src_access, ccs_sz);
+ src_offset, src_access, len);
if (err)
goto out_rq;
err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
if (err)
goto out_rq;
-
- /* Converting back to ccs bytes */
- ccs_sz = GET_CCS_BYTES(rq->engine->i915, ccs_sz);
ccs_bytes_to_cpy -= ccs_sz;
}
--
2.20.1
[Intel-gfx] [PATCH v3 1/3] drm/i915/gt: BUG_ON unexpected NULL at scatterlist walking
While locating the start of ccs scatterlist in smem scatterlist, that has
to be the size of lmem obj size + corresponding ccs data size, report bug
if scatterlist terminate before that length.
v2:
s/GEM_BUG_ON/BUG_ON with more commenting [Matt]
v3:
Converted GEM_BUG_ON into BUG_ON with more documentation [Matt]
Signed-off-by: Ramalingam C
Reviewed-by: Matthew Auld (v1)
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9d552f30b627..168d17b6f48a 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -687,6 +687,16 @@ static void get_ccs_sg_sgt(struct sgt_dma *it, u32
bytes_to_cpy)
bytes_to_cpy -= len;
it->sg = __sg_next(it->sg);
+
+ /*
+* On Flat-CCS capable platform when we back the lmem pages with
+* smem pages we add extra pages at the end of the smem
+* scatterlist, to store the ccs data corresponding to the lmem
+* pages. get_ccs_sg_sgt() is called to get the pointer for the
+* start of the extra pages added at the end of smem
scatterlist.
+* So scatterlist can't end at or before bytes_to_cpy.
+*/
+ BUG_ON(!it->sg);
it->dma = sg_dma_address(it->sg);
it->max = it->dma + sg_dma_len(it->sg);
} while (bytes_to_cpy);
@@ -748,8 +758,10 @@ intel_context_migrate_copy(struct intel_context *ce,
* Need to fix it.
*/
ccs_bytes_to_cpy = src_sz != dst_sz ? GET_CCS_BYTES(i915,
bytes_to_cpy) : 0;
- if (ccs_bytes_to_cpy)
+ if (ccs_bytes_to_cpy) {
+ WARN_ON(abs(src_sz - dst_sz) < ccs_bytes_to_cpy);
get_ccs_sg_sgt(_ccs, bytes_to_cpy);
+ }
}
src_offset = 0;
--
2.20.1
[Intel-gfx] [PATCH v3 0/3] Flat-CCS eviction enhancements
Flat-CCS eviction enhancements v3: Incorporated the review suggestions [Matt] Ramalingam C (3): drm/i915/gt: BUG_ON unexpected NULL at scatterlist walking drm/i915/gt: optimize the ccs_sz calculation per chunk drm/i915/gt: Document the eviction of the Flat-CCS objects drivers/gpu/drm/i915/gt/intel_migrate.c | 73 ++--- 1 file changed, 40 insertions(+), 33 deletions(-) -- 2.20.1
[Intel-gfx] [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj
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 _i915_gem_create_ext.handle,
* along with the final object size in _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.
*/
struct drm_i915_gem_create_ext_memory_regions {
/** @base: Extension link. See struct i915_user_extension. */
--
2.20.1
Re: [Intel-gfx] [CI] PR for DG2 DMC v2.06
Timo Aaltonen kirjoitti 13.4.2022 klo 13.48: Tolakanahalli Pradeep, Madhumitha kirjoitti 23.3.2022 klo 20.23: The following changes since commit 681281e49fb6778831370e5d94e6e1d97f0752d6: amdgpu: update PSP 13.0.8 firmware (2022-03-18 07:35:54 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_v2.06 for you to fetch changes up to ecc28070ea5edd4733b78550326c1d56858181af: i915: Add DMC v2.06 for DG2 (2022-03-23 11:15:12 -0700) Madhumitha Tolakanahalli Pradeep (1): i915: Add DMC v2.06 for DG2 WHENCE | 3 +++ i915/dg2_dmc_ver2_06.bin | Bin 0 -> 22416 bytes 2 files changed, 3 insertions(+) create mode 100644 i915/dg2_dmc_ver2_06.bin Hi, when will this be sent upstream? Ping? GuC got applied there, what's blocking DMC for DG2? -- t
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
On 2022-05-02 09:28, Modem, Bhanuprakash wrote: > On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote: >> >> >>> -Original Message- >>> From: Intel-gfx On Behalf Of >>> Bhanuprakash Modem >>> Sent: Monday, April 11, 2022 3:21 PM >>> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >>> amd- >>> g...@lists.freedesktop.org; jani.nik...@linux.intel.com; >>> ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2 >>> >>> Cc: Rodrigo Siqueira >>> Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to >>> drm >>> >>> As drm_connector already have the display_info, instead of creating >>> "output_bpc" debugfs in vendor specific driver, move the logic to the >>> drm >>> layer. >>> >>> This patch will also move "Current" bpc to the crtc debugfs from >>> connector >>> debugfs, since we are getting this info from crtc_state. >>> >>> Cc: Harry Wentland >>> Cc: Rodrigo Siqueira >>> Signed-off-by: Bhanuprakash Modem >>> Reported-by: kernel test robot >>> --- >> Reviewed-by: Arun R Murthy > > Thanks Arun, > > @Harry/@Rodrigo, If this change sounds good to you, can you please help > to push it? > This changes the output_bpc debugfs behavior on amdgpu and breaks the amd_max_bpc IGT test. I don't think we should merge this as-is. This patch also seems dependent on patch 1 of the series. Shouldn't they be merged together (please don't merge them as-is, though)? Harry > - Bhanu > >> >> Thanks and Regards, >> Arun R Murthy >> >
Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm
On Fri-29-04-2022 08:02 pm, Murthy, Arun R wrote: -Original Message- From: Intel-gfx On Behalf Of Bhanuprakash Modem Sent: Monday, April 11, 2022 3:21 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; amd- g...@lists.freedesktop.org; jani.nik...@linux.intel.com; ville.syrj...@linux.intel.com; harry.wentl...@amd.com; Sharma, Swati2 Cc: Rodrigo Siqueira Subject: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm As drm_connector already have the display_info, instead of creating "output_bpc" debugfs in vendor specific driver, move the logic to the drm layer. This patch will also move "Current" bpc to the crtc debugfs from connector debugfs, since we are getting this info from crtc_state. Cc: Harry Wentland Cc: Rodrigo Siqueira Signed-off-by: Bhanuprakash Modem Reported-by: kernel test robot --- Reviewed-by: Arun R Murthy Thanks Arun, @Harry/@Rodrigo, If this change sounds good to you, can you please help to push it? - Bhanu Thanks and Regards, Arun R Murthy
Re: [Intel-gfx] [PATCH 3/8] drm/i915/pcode: Extend pcode functions for multiple gt's
On Fri, Apr 29, 2022 at 12:56:24PM -0700, Ashutosh Dixit wrote:
> Each gt contains an independent instance of pcode. Extend pcode functions
> to interface with pcode on different gt's. To avoid creating dependency of
> display functionality on intel_gt, pcode function interfaces are exposed in
> terms of uncore rather than intel_gt. Callers have been converted to pass
> in the appropritate (i915 or intel_gt) uncore to the pcode functions.
>
> v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
> v3: Retain previous function names to eliminate needless #defines (Rodrigo)
>
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Cc: Andi Shyti
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/hsw_ips.c| 4 +-
> drivers/gpu/drm/i915/display/intel_bw.c | 6 +-
> drivers/gpu/drm/i915/display/intel_cdclk.c| 16 ++---
> .../drm/i915/display/intel_display_power.c| 2 +-
> .../i915/display/intel_display_power_well.c | 4 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_llc.c | 3 +-
> drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_rps.c | 4 +-
> drivers/gpu/drm/i915/gt/selftest_llc.c| 2 +-
> drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +-
> drivers/gpu/drm/i915/i915_driver.c| 20 ++-
> drivers/gpu/drm/i915/intel_dram.c | 2 +-
> drivers/gpu/drm/i915/intel_pcode.c| 60 +--
> drivers/gpu/drm/i915/intel_pcode.h| 14 ++---
> drivers/gpu/drm/i915/intel_pm.c | 10 ++--
> 17 files changed, 86 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
> b/drivers/gpu/drm/i915/display/hsw_ips.c
> index 38014e0cc9ad..861dcd2eb890 100644
> --- a/drivers/gpu/drm/i915/display/hsw_ips.c
> +++ b/drivers/gpu/drm/i915/display/hsw_ips.c
> @@ -28,7 +28,7 @@ static void hsw_ips_enable(const struct intel_crtc_state
> *crtc_state)
>
> if (IS_BROADWELL(i915)) {
> drm_WARN_ON(>drm,
> - snb_pcode_write(i915, DISPLAY_IPS_CONTROL,
> + snb_pcode_write(>uncore, DISPLAY_IPS_CONTROL,
> IPS_ENABLE | IPS_PCODE_CONTROL));
> /*
>* Quoting Art Runyan: "its not safe to expect any particular
> @@ -62,7 +62,7 @@ bool hsw_ips_disable(const struct intel_crtc_state
> *crtc_state)
>
> if (IS_BROADWELL(i915)) {
> drm_WARN_ON(>drm,
> - snb_pcode_write(i915, DISPLAY_IPS_CONTROL, 0));
> + snb_pcode_write(>uncore, DISPLAY_IPS_CONTROL,
> 0));
> /*
>* Wait for PCODE to finish disabling IPS. The BSpec specified
>* 42ms timeout value leads to occasional timeouts so use 100ms
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 37bd7b17f3d0..79269d2c476b 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -78,7 +78,7 @@ static int icl_pcode_read_qgv_point_info(struct
> drm_i915_private *dev_priv,
> u16 dclk;
> int ret;
>
> - ret = snb_pcode_read(dev_priv, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
> + ret = snb_pcode_read(_priv->uncore, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
>ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point),
>, );
> if (ret)
> @@ -104,7 +104,7 @@ static int adls_pcode_read_psf_gv_point_info(struct
> drm_i915_private *dev_priv,
> int ret;
> int i;
>
> - ret = snb_pcode_read(dev_priv, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
> + ret = snb_pcode_read(_priv->uncore, ICL_PCODE_MEM_SUBSYSYSTEM_INFO |
>ADL_PCODE_MEM_SS_READ_PSF_GV_INFO, , NULL);
> if (ret)
> return ret;
> @@ -123,7 +123,7 @@ int icl_pcode_restrict_qgv_points(struct drm_i915_private
> *dev_priv,
> int ret;
>
> /* bspec says to keep retrying for at least 1 ms */
> - ret = skl_pcode_request(dev_priv, ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> + ret = skl_pcode_request(_priv->uncore,
> ICL_PCODE_SAGV_DE_MEM_SS_CONFIG,
> points_mask,
> ICL_PCODE_REP_QGV_MASK |
> ADLS_PCODE_REP_PSF_MASK,
> ICL_PCODE_REP_QGV_SAFE |
> ADLS_PCODE_REP_PSF_SAFE,
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index b2017d8161b4..6e80162632dd 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -800,7 +800,7 @@ static void bdw_set_cdclk(struct drm_i915_private
> *dev_priv,
>"trying to change cdclk frequency
Re: [Intel-gfx] [PATCH v4 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
On 2022-05-02 at 16:40:00 +0530, Ramalingam C wrote:
> From: Chris Wilson
>
> Even though the initial protocontext we load onto HW has the register
> cleared, by the time we save it into the default image, BB_OFFSET has
> had the enable bit set. Reclear BB_OFFSET for each new context.
>
> Testcase: igt/i915_selftests/gt_lrc
>
> v2:
> Extend it for gen8.
> v3:
> BB_OFFSET is recorded per engine from Gen9 onwards
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Signed-off-by: Ramalingam C
> Reviewed-by: Thomas Hellstrom
Thomas,
Could you please reconfirm your R-b for v3? This R-b was given for v1.
Ram
> ---
> drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 20
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 5 +
> 3 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> index 75a0c55c5aa5..8c65f3a7acfb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
> @@ -109,6 +109,7 @@
> #define RING_SBBSTATE(base) _MMIO((base) + 0x118) /* hsw+ */
> #define RING_SBBADDR_UDW(base) _MMIO((base) + 0x11c)
> /* gen8+ */
> #define RING_BBADDR(base)_MMIO((base) + 0x140)
> +#define RING_BB_OFFSET(base) _MMIO((base) + 0x158)
> #define RING_BBADDR_UDW(base)_MMIO((base) + 0x168)
> /* gen8+ */
> #define CCID(base) _MMIO((base) + 0x180)
> #define CCID_ENBIT(0)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index eec73c66406c..ee8ab7470a62 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -662,6 +662,21 @@ static int lrc_ring_mi_mode(const struct intel_engine_cs
> *engine)
> return -1;
> }
>
> +static int lrc_ring_bb_offset(const struct intel_engine_cs *engine)
> +{
> + if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
> + return 0x80;
> + else if (GRAPHICS_VER(engine->i915) >= 12)
> + return 0x70;
> + else if (GRAPHICS_VER(engine->i915) >= 9)
> + return 0x64;
> + else if (GRAPHICS_VER(engine->i915) >= 8 &&
> + engine->class == RENDER_CLASS)
> + return 0xc4;
> + else
> + return -1;
> +}
> +
> static int lrc_ring_gpr0(const struct intel_engine_cs *engine)
> {
> if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
> @@ -768,6 +783,7 @@ static void init_common_regs(u32 * const regs,
>bool inhibit)
> {
> u32 ctl;
> + int loc;
>
> ctl = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
> ctl |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
> @@ -779,6 +795,10 @@ static void init_common_regs(u32 * const regs,
> regs[CTX_CONTEXT_CONTROL] = ctl;
>
> regs[CTX_TIMESTAMP] = ce->stats.runtime.last;
> +
> + loc = lrc_ring_bb_offset(engine);
> + if (loc != -1)
> + regs[loc + 1] = 0;
> }
>
> static void init_wa_bb_regs(u32 * const regs,
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> index 8b2c11dbe354..c4bd4e1ac5ef 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
> @@ -357,6 +357,11 @@ static int live_lrc_fixed(void *arg)
> lrc_ring_cmd_buf_cctl(engine),
> "RING_CMD_BUF_CCTL"
> },
> + {
> +
> i915_mmio_reg_offset(RING_BB_OFFSET(engine->mmio_base)),
> + lrc_ring_bb_offset(engine),
> + "RING_BB_OFFSET"
> + },
> { },
> }, *t;
> u32 *hw;
> --
> 2.20.1
>
Re: [Intel-gfx] PR for new GuC v70.1.2 for DG2
On Thu, Apr 28, 2022 at 3:07 PM wrote: > > The following changes since commit ac21ab5d1de0de34201c90d32eee436f873d1e5b: > > Mellanox: Add lc_ini_bundle for xx.2010.1006 (2022-04-25 07:36:16 -0400) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.2_dg2 > > for you to fetch changes up to 89ae5eb20f65752db6a3e38b9a69144f19540567: > > i915: Add GuC v70.1.2 for DG2 (2022-04-26 13:27:47 -0700) Pulled and pushed out. josh > > > John Harrison (1): > i915: Add GuC v70.1.2 for DG2 > > WHENCE | 3 +++ > i915/dg2_guc_70.1.2.bin | Bin 0 -> 365568 bytes > 2 files changed, 3 insertions(+) > create mode 100644 i915/dg2_guc_70.1.2.bin
[Intel-gfx] ✓ Fi.CI.BAT: success for lrc selftest fixes (rev6)
== Series Details ==
Series: lrc selftest fixes (rev6)
URL : https://patchwork.freedesktop.org/series/101353/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11585 -> Patchwork_101353v6
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/index.html
Participating hosts (41 -> 39)
--
Additional (2): bat-rpls-1 fi-rkl-11600
Missing(4): fi-bsw-cyan bat-rpls-2 bat-jsl-2 bat-dg2-9
Known issues
Here are the changes found in Patchwork_101353v6 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-kbl-soraka: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-kbl-soraka/igt@debugfs_test@read_all_entries.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/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_101353v6/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3282])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3012])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][7] -> [INCOMPLETE][8] ([i915#4785])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-bdw-5557u: [PASS][9] -> [INCOMPLETE][10] ([i915#5692])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11585/fi-bdw-5557u/igt@i915_selftest@l...@requests.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-bdw-5557u/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-snb-2600:NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-snb-2600/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([fdo#111827]) +8 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4070] / [i915#4103]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4070] / [i915#533])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][17] ([i915#3555] / [i915#4098])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#3301] / [i915#3708])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- fi-rkl-11600: NOTRUN -> [SKIP][19] ([i915#3291] / [i915#3708]) +2
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_101353v6/fi-rkl-11600/igt@prime_v...@basic-write.html
Possible fixes
* igt@i915_selftest@live@gt_lrc:
- {fi-tgl-dsi}:
Re: [Intel-gfx] [V2 1/3] drm/debug: Expose connector's max supported bpc via debugfs
On Fri, 29 Apr 2022, "Murthy, Arun R" wrote:
>> +static int output_bpc_show(struct seq_file *m, void *data) {
>
> Can we have a meaningful name instead of 'm' ?
> Upon changing this parameter name, you can have my
> Reviewed-By: Arun R Murthy
Please keep 'm'. It's by far the most common name for struct seq_file *
in the kernel:
$ git grep -o "struct seq_file \*[a-zA-Z0-9_]\+" | sed 's/^.*:struct seq_file
\*//' | sort | uniq -c | sort -rn | head -5
2212 m
1219 seq
1126 s
135 sf
121 file
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for lrc selftest fixes (rev6)
== Series Details == Series: lrc selftest fixes (rev6) URL : https://patchwork.freedesktop.org/series/101353/ 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/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:28:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:33:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:51:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:57:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1391:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-24) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/find.h:40:31: warning: shift count is negative (-448) +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:404:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block
[Intel-gfx] [PATCH v4 3/4] drm/i915/selftest: Always cancel semaphore on error
From: Chris Wilson
Ensure that we always signal the semaphore when timing out, so that if it
happens to be stuck waiting for the semaphore we will quickly recover
without having to wait for a reset.
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 3271f01fe7db..e4d5d74489bf 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1460,18 +1460,17 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
}
err = poison_registers(B, poison, sema);
- if (err) {
- WRITE_ONCE(*sema, -1);
- i915_request_put(rq);
- goto err_result1;
- }
-
- if (i915_request_wait(rq, 0, HZ / 2) < 0) {
- i915_request_put(rq);
+ if (err == 0 && i915_request_wait(rq, 0, HZ / 2) < 0) {
+ pr_err("%s(%s): wait for results timed out\n",
+ __func__, engine->name);
err = -ETIME;
- goto err_result1;
}
+
+ /* Always cancel the semaphore wait, just in case the GPU gets stuck */
+ WRITE_ONCE(*sema, -1);
i915_request_put(rq);
+ if (err)
+ goto err_result1;
err = compare_isolation(engine, ref, result, A, poison);
--
2.20.1
[Intel-gfx] [PATCH v4 4/4] drm/i915/selftest: Clear the output buffers before GPU writes
From: Chris Wilson
When testing whether we can get the GPU to leak information about
non-privileged state, we first need to ensure that the output buffer is
set to a known value as the HW may opt to skip the write into memory for
a non-privileged read of a sensitive register. We chose POISON_INUSE (0x5a)
so that is both non-zero and distinct from the poison values used during
the test.
v2:
Use i915_gem_object_pin_map_unlocked
Reported-by: CQ Tang
Signed-off-by: Chris Wilson
Cc: CQ Tang
cc: Joonas Lahtinen
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 32 ++
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index e4d5d74489bf..d04d08d9d92e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -1395,6 +1395,30 @@ static int compare_isolation(struct intel_engine_cs
*engine,
return err;
}
+static struct i915_vma *
+create_result_vma(struct i915_address_space *vm, unsigned long sz)
+{
+ struct i915_vma *vma;
+ void *ptr;
+
+ vma = create_user_vma(vm, sz);
+ if (IS_ERR(vma))
+ return vma;
+
+ /* Set the results to a known value distinct from the poison */
+ ptr = i915_gem_object_pin_map_unlocked(vma->obj, I915_MAP_WC);
+ if (IS_ERR(ptr)) {
+ i915_vma_put(vma);
+ return ERR_CAST(ptr);
+ }
+
+ memset(ptr, POISON_INUSE, vma->size);
+ i915_gem_object_flush_map(vma->obj);
+ i915_gem_object_unpin_map(vma->obj);
+
+ return vma;
+}
+
static int __lrc_isolation(struct intel_engine_cs *engine, u32 poison)
{
u32 *sema = memset32(engine->status_page.addr + 1000, 0, 1);
@@ -1413,13 +1437,13 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
goto err_A;
}
- ref[0] = create_user_vma(A->vm, SZ_64K);
+ ref[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[0])) {
err = PTR_ERR(ref[0]);
goto err_B;
}
- ref[1] = create_user_vma(A->vm, SZ_64K);
+ ref[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(ref[1])) {
err = PTR_ERR(ref[1]);
goto err_ref0;
@@ -1441,13 +1465,13 @@ static int __lrc_isolation(struct intel_engine_cs
*engine, u32 poison)
}
i915_request_put(rq);
- result[0] = create_user_vma(A->vm, SZ_64K);
+ result[0] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[0])) {
err = PTR_ERR(result[0]);
goto err_ref1;
}
- result[1] = create_user_vma(A->vm, SZ_64K);
+ result[1] = create_result_vma(A->vm, SZ_64K);
if (IS_ERR(result[1])) {
err = PTR_ERR(result[1]);
goto err_result0;
--
2.20.1
[Intel-gfx] [PATCH v4 2/4] drm/i915/selftests: Check for incomplete LRI from the context image
From: Chris Wilson
In order to keep the context image parser simple, we assume that all
commands follow a similar format. A few, especially not MI commands on
the render engines, have fixed lengths not encoded in a length field.
This caused us to incorrectly skip over 3D state commands, and start
interpreting context data as instructions. Eventually, as Daniele
discovered, this would lead us to find addition LRI as part of the data
and mistakenly add invalid LRI commands to the context probes.
Stop parsing after we see the first !MI command, as we know we will have
seen all the context registers by that point. (Mostly true for all gen
so far, though the render context does have LRI after the first page
that we have been ignoring so far. It would be useful to extract those
as well so that we have the full list of user accessible registers.)
Similarly, emit a warning if we do try to emit an invalid zero-length
LRI.
Reported-by: Daniele Ceraolo Spurio
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Signed-off-by: Ramalingam C
Acked-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 61 +++---
1 file changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index c4bd4e1ac5ef..3271f01fe7db 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -27,6 +27,9 @@
#define NUM_GPR 16
#define NUM_GPR_DW (NUM_GPR * 2) /* each GPR is 2 dwords */
+#define LRI_HEADER MI_INSTR(0x22, 0)
+#define LRI_LENGTH_MASK GENMASK(7, 0)
+
static struct i915_vma *create_scratch(struct intel_gt *gt)
{
return __vm_create_scratch_for_read_pinned(>ggtt->vm, PAGE_SIZE);
@@ -202,7 +205,7 @@ static int live_lrc_layout(void *arg)
continue;
}
- if ((lri & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((lri & GENMASK(31, 23)) != LRI_HEADER) {
pr_err("%s: Expected LRI command at dword %d,
found %08x\n",
engine->name, dw, lri);
err = -EINVAL;
@@ -992,18 +995,40 @@ store_context(struct intel_context *ce, struct i915_vma
*scratch)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
- u32 len = hw[dw] & 0x7f;
+ u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+ /*
+* Keep it simple, skip parsing complex commands
+*
+* At present, there are no more MI_LOAD_REGISTER_IMM
+* commands after the first 3D state command. Rather
+* than include a table (see i915_cmd_parser.c) of all
+* the possible commands and their instruction lengths
+* (or mask for variable length instructions), assume
+* we have gathered the complete list of registers and
+* bail out.
+*/
+ if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+ break;
if (hw[dw] == 0) {
dw++;
continue;
}
- if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
+ /* Assume all other MI commands match LRI length mask */
dw += len + 2;
continue;
}
+ if (!len) {
+ pr_err("%s: invalid LRI found in context image\n",
+ ce->engine->name);
+ igt_hexdump(defaults, PAGE_SIZE);
+ break;
+ }
+
dw++;
len = (len + 1) / 2;
while (len--) {
@@ -1155,18 +1180,29 @@ static struct i915_vma *load_context(struct
intel_context *ce, u32 poison)
hw = defaults;
hw += LRC_STATE_OFFSET / sizeof(*hw);
do {
- u32 len = hw[dw] & 0x7f;
+ u32 len = hw[dw] & LRI_LENGTH_MASK;
+
+ /* For simplicity, break parsing at the first complex command */
+ if ((hw[dw] >> INSTR_CLIENT_SHIFT) != INSTR_MI_CLIENT)
+ break;
if (hw[dw] == 0) {
dw++;
continue;
}
- if ((hw[dw] & GENMASK(31, 23)) != MI_INSTR(0x22, 0)) {
+ if ((hw[dw] & GENMASK(31, 23)) != LRI_HEADER) {
dw += len + 2;
continue;
}
+ if (!len) {
+ pr_err("%s: invalid LRI found in context image\n",
+ ce->engine->name);
+ igt_hexdump(defaults, PAGE_SIZE);
+
[Intel-gfx] [PATCH v4 1/4] drm/i915/gt: Explicitly clear BB_OFFSET for new contexts
From: Chris Wilson
Even though the initial protocontext we load onto HW has the register
cleared, by the time we save it into the default image, BB_OFFSET has
had the enable bit set. Reclear BB_OFFSET for each new context.
Testcase: igt/i915_selftests/gt_lrc
v2:
Extend it for gen8.
v3:
BB_OFFSET is recorded per engine from Gen9 onwards
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Ramalingam C
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 20
drivers/gpu/drm/i915/gt/selftest_lrc.c | 5 +
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
index 75a0c55c5aa5..8c65f3a7acfb 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_regs.h
@@ -109,6 +109,7 @@
#define RING_SBBSTATE(base)_MMIO((base) + 0x118) /* hsw+ */
#define RING_SBBADDR_UDW(base) _MMIO((base) + 0x11c) /* gen8+
*/
#define RING_BBADDR(base) _MMIO((base) + 0x140)
+#define RING_BB_OFFSET(base) _MMIO((base) + 0x158)
#define RING_BBADDR_UDW(base) _MMIO((base) + 0x168) /* gen8+
*/
#define CCID(base) _MMIO((base) + 0x180)
#define CCID_EN BIT(0)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index eec73c66406c..ee8ab7470a62 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -662,6 +662,21 @@ static int lrc_ring_mi_mode(const struct intel_engine_cs
*engine)
return -1;
}
+static int lrc_ring_bb_offset(const struct intel_engine_cs *engine)
+{
+ if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
+ return 0x80;
+ else if (GRAPHICS_VER(engine->i915) >= 12)
+ return 0x70;
+ else if (GRAPHICS_VER(engine->i915) >= 9)
+ return 0x64;
+ else if (GRAPHICS_VER(engine->i915) >= 8 &&
+engine->class == RENDER_CLASS)
+ return 0xc4;
+ else
+ return -1;
+}
+
static int lrc_ring_gpr0(const struct intel_engine_cs *engine)
{
if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 50))
@@ -768,6 +783,7 @@ static void init_common_regs(u32 * const regs,
bool inhibit)
{
u32 ctl;
+ int loc;
ctl = _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH);
ctl |= _MASKED_BIT_DISABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
@@ -779,6 +795,10 @@ static void init_common_regs(u32 * const regs,
regs[CTX_CONTEXT_CONTROL] = ctl;
regs[CTX_TIMESTAMP] = ce->stats.runtime.last;
+
+ loc = lrc_ring_bb_offset(engine);
+ if (loc != -1)
+ regs[loc + 1] = 0;
}
static void init_wa_bb_regs(u32 * const regs,
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 8b2c11dbe354..c4bd4e1ac5ef 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -357,6 +357,11 @@ static int live_lrc_fixed(void *arg)
lrc_ring_cmd_buf_cctl(engine),
"RING_CMD_BUF_CCTL"
},
+ {
+
i915_mmio_reg_offset(RING_BB_OFFSET(engine->mmio_base)),
+ lrc_ring_bb_offset(engine),
+ "RING_BB_OFFSET"
+ },
{ },
}, *t;
u32 *hw;
--
2.20.1
[Intel-gfx] [PATCH v4 0/4] lrc selftest fixes
Few bug fixes for lrc selftest. v4: Gen8 don't have per engine recording of BB_OFFSET [Chris] Chris Wilson (4): drm/i915/gt: Explicitly clear BB_OFFSET for new contexts drm/i915/selftests: Check for incomplete LRI from the context image drm/i915/selftest: Always cancel semaphore on error drm/i915/selftest: Clear the output buffers before GPU writes drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_lrc.c | 20 drivers/gpu/drm/i915/gt/selftest_lrc.c | 115 3 files changed, 116 insertions(+), 20 deletions(-) -- 2.20.1
Re: [Intel-gfx] [PATCH] drm/i915: move tons of power well initializers to rodata
On Fri, 29 Apr 2022, Imre Deak wrote:
> On Fri, Apr 29, 2022 at 05:21:40PM +0300, Jani Nikula wrote:
>> Using compound literals for initialization can be tricky. Lacking a
>> const qualifier, they won't end up in rodata, which is probably not
>> expected or intended. Add const to move a whopping 136 initializers to
>> rodata.
>>
>> Compare:
>>
>> $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o |
>> grep "\.rodata.*__compound_literal"
>> $ objdump --syms drivers/gpu/drm/i915/display/intel_display_power_map.o |
>> grep "\.data.*__compound_literal"
>>
>> Before and after the change.
>>
>> Fixes: c32ffce42aa5 ("drm/i915: Convert the power well descriptor domain
>> mask to an array of domains")
>> Fixes: 4a845ff0c0d4 ("drm/i915: Simplify power well definitions by adding
>> power well instances")
>> Cc: Imre Deak
>> Cc: Jouni Högander
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Imre Deak
Thanks, pushed to drm-intel-next.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/intel_display_power_map.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
>> b/drivers/gpu/drm/i915/display/intel_display_power_map.c
>> index af6f54a26a35..97b367f39f35 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
>> @@ -21,7 +21,7 @@
>>
>> #define I915_PW_DOMAINS(...) \
>> (const struct i915_power_domain_list) \
>> -__LIST(__LIST_INLINE_ELEMS(enum intel_display_power_domain,
>> __VA_ARGS__))
>> +__LIST(__LIST_INLINE_ELEMS(const enum
>> intel_display_power_domain, __VA_ARGS__))
>>
>> #define I915_DECL_PW_DOMAINS(__name, ...) \
>> static const struct i915_power_domain_list __name =
>> I915_PW_DOMAINS(__VA_ARGS__)
>> @@ -32,7 +32,7 @@
>>
>> #define I915_PW_INSTANCES(...) \
>> (const struct i915_power_well_instance_list) \
>> -__LIST(__LIST_INLINE_ELEMS(struct i915_power_well_instance,
>> __VA_ARGS__))
>> +__LIST(__LIST_INLINE_ELEMS(const struct
>> i915_power_well_instance, __VA_ARGS__))
>>
>> #define I915_PW(_name, _domain_list, ...) \
>> { .name = _name, .domain_list = _domain_list, ## __VA_ARGS__ }
>> --
>> 2.30.2
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 02/05/2022 10:54, Lionel Landwerlin wrote:
On 20/04/2022 20:13, 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)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190 +++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 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 ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * 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 _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;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 =
unknown) */
+ __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.
+ */
+ __u64 probed_cpu_visible_size;
+ };
Trying to implement userspace support in Vulkan for this, I have an
additional question about the value of probed_cpu_visible_size.
When is it set to -1?
I'm guessing before there is support for this value it'll be 0 (MBZ).
After after it should either be the entire lmem or something smaller.
-Lionel
Other pain point of this new uAPI, previously we could query the
unallocated size for each heap.
Now lmem is effectively divided into 2 heaps, but unallocated_size is
tracking allocation from both parts of lmem.
Is adding new I915_MEMORY_CLASS_DEVICE_NON_MAPPABLE out of question?
-Lionel
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour,
with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the
stuff that
+ * is immutable. Previously we would have two ioctls, one to create
the object
+ * with gem_create, and another to apply various parameters, however
this
+ * creates some ambiguity for the params which are considered
immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be
returned.
+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), like for device
local-memory.
+ * However in general the final size here should always reflect any
+ * rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+ * extension to place the object in device local-memory.
+ */
+ __u64 size;
+ /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+ /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the
kernel that
+ * the object will need to be accessed via the CPU.
+ *
+ * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+ * only strictly required on platforms where only some of the
device
+ * memory is directly visible or mappable through the CPU, like
on DG2+.
+ *
+ * One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+ * ensure we can always spill the allocation to system memory,
if we
+ * can't place the object in the mappable part of
+ * I915_MEMORY_CLASS_DEVICE.
+ *
+ * Note that since the kernel only supports flat-CCS on
Re: [Intel-gfx] [PATCH] drm/i915: use IOMEM_ERR_PTR() directly
On Mon, 02 May 2022, Kefeng Wang wrote:
> Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR().
>
> Signed-off-by: Kefeng Wang
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_vma.c | 4 ++--
> drivers/gpu/drm/i915/i915_vma.h | 1 -
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 94fcdb7bd21d..639605c89b7b 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -541,7 +541,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> int err;
>
> if (WARN_ON_ONCE(vma->obj->flags & I915_BO_ALLOC_GPU_ONLY))
> - return IO_ERR_PTR(-EINVAL);
> + return IOMEM_ERR_PTR(-EINVAL);
>
> if (!i915_gem_object_is_lmem(vma->obj)) {
> if (GEM_WARN_ON(!i915_vma_is_map_and_fenceable(vma))) {
> @@ -594,7 +594,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> err_unpin:
> __i915_vma_unpin(vma);
> err:
> - return IO_ERR_PTR(err);
> + return IOMEM_ERR_PTR(err);
> }
>
> void i915_vma_flush_writes(struct i915_vma *vma)
> diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
> index 67ae7341c7e0..8e74972fdca3 100644
> --- a/drivers/gpu/drm/i915/i915_vma.h
> +++ b/drivers/gpu/drm/i915/i915_vma.h
> @@ -331,7 +331,6 @@ static inline bool i915_node_color_differs(const struct
> drm_mm_node *node,
> * Returns a valid iomapped pointer or ERR_PTR.
> */
> void __iomem *i915_vma_pin_iomap(struct i915_vma *vma);
> -#define IO_ERR_PTR(x) ((void __iomem *)ERR_PTR(x))
>
> /**
> * i915_vma_unpin_iomap - unpins the mapping returned from i915_vma_iomap
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 20/04/2022 20:13, 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)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190 +++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 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 ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * 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 _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;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */
+ __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.
+*/
+ __u64 probed_cpu_visible_size;
+ };
Trying to implement userspace support in Vulkan for this, I have an
additional question about the value of probed_cpu_visible_size.
When is it set to -1?
I'm guessing before there is support for this value it'll be 0 (MBZ).
After after it should either be the entire lmem or something smaller.
-Lionel
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the stuff that
+ * is immutable. Previously we would have two ioctls, one to create the object
+ * with gem_create, and another to apply various parameters, however this
+ * creates some ambiguity for the params which are considered immutable. Also
in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+* @size: Requested size for the object.
+*
+* The (page-aligned) allocated size for the object will be returned.
+*
+* Note that for some devices we have might have further minimum
+* page-size restrictions(larger than 4K), like for device local-memory.
+* However in general the final size here should always reflect any
+* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+* extension to place the object in device local-memory.
+*/
+ __u64 size;
+ /**
+* @handle: Returned handle for the object.
+*
+* Object handles are nonzero.
+*/
+ __u32 handle;
+ /**
+* @flags: Optional flags.
+*
+* Supported values:
+*
+* I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the kernel that
+* the object will need to be accessed via the CPU.
+*
+* Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and
+* only strictly required on platforms where only some of the device
+* memory is directly visible or mappable through the CPU, like on DG2+.
+*
+* One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+* ensure we can always spill the allocation to system memory, if we
+* can't place the object in the mappable part of
+* I915_MEMORY_CLASS_DEVICE.
+*
+* Note that since the kernel only supports flat-CCS on objects that can
+* *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore don't
+*
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915 private writeback framework
== Series Details == Series: i915 private writeback framework URL : https://patchwork.freedesktop.org/series/103417/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11584 -> Patchwork_103417v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103417v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103417v1, 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_103417v1/index.html Participating hosts (44 -> 40) -- Additional (1): fi-rkl-11600 Missing(5): bat-adlm-1 fi-bsw-cyan fi-kbl-guc fi-kbl-8809g fi-bsw-nick Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103417v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@hangcheck: - fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11584/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html Known issues Here are the changes found in Patchwork_103417v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/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_103417v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3282]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3012]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gtt: - fi-bdw-5557u: [PASS][7] -> [INCOMPLETE][8] ([i915#5685]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11584/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-bdw-5557u/igt@i915_selftest@l...@gtt.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][9] -> [INCOMPLETE][10] ([i915#3921]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11584/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-rkl-11600: NOTRUN -> [SKIP][11] ([fdo#111827]) +8 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#4070] / [i915#4103]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#4070] / [i915#533]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_mmap_gtt: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([i915#3301] / [i915#3708]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103417v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html * igt@prime_vgem@basic-write: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#3291] / [i915#3708]) +2 similar issues
Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs
On 29.04.2022 06:25, Dixit, Ashutosh wrote:
On Thu, 28 Apr 2022 07:36:14 -0700, Andrzej Hajda wrote:
On 27.04.2022 22:46, Dixit, Ashutosh wrote:
On Sun, 24 Apr 2022 15:36:23 -0700, Andi Shyti wrote:
Hi Andrzej and Ashutosh,
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 937b2e1a305e..4c72b4f983a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -222,6 +222,9 @@ struct intel_gt {
} mocs;
struct intel_pxp pxp;
+
+ /* gt/gtN sysfs */
+ struct kobject sysfs_gtn;
If you put kobject as a part of intel_gt what assures you that lifetime of
kobject is shorter than intel_gt? Ie its refcounter is 0 on removal of
intel_gt?
Because we are explicitly doing a kobject_put() in
intel_gt_sysfs_unregister(). Which is exactly what we are *not* doing in
the previous code.
Let me explain a bit about the previous code (but feel free to skip since
the patch should speak for itself):
* Previously we kzalloc a 'struct kobj_gt'
* But we don't save a pointer to the 'struct kobj_gt' so we don't have the
pointer to the kobject to be able to do a kobject_put() on it later
* Therefore we need to store the pointer in 'struct intel_gt'
* But if we have to put the pointer in 'struct intel_gt' we might as well
put the kobject as part of 'struct intel_gt' and that also removes the
need to have a 'struct kobj_gt' (kobj_to_gt() can just use container_of()
to get gt from kobj).
* So I think this patch simpler/cleaner than the original code if you take
the requirement for kobject_put() into account.
This is my oversight. This was something I completely forgot to
fix but it was my intention to do and actually I had some fixes
ongoing. But because this patch took too long to get in I
completely forgot about it (Sujaritha was actually the first who
pointed this out).
Thanks, Ashutosh for taking this.
I fully agree that previous code is incorrect but I am not convinced current
code is correct.
If some objects are kref-counted it means usually they can have multiple
concurrent users and kobject_put does not work as traditional
destructor/cleanup/unregister.
So in this particular case after calling kobject_init_and_add sysfs core can
get multiple references on the object. Later, during driver unregistration
kobject_put is called, but if the object is still in use by sysfs core, the
object will not be destroyed/released. If the driver unregistration
continues memory will be freed, leaving sysfs-core (or other users) with
dangling pointers. Unless there is some additional synchronization mechanism
I am not aware of.
Thanks Andrzej for summarizing this and what you said is actually
what happens. I had a similar solution developed and I had wrong
pointer reference happening.
Hi Andrzej/Andi,
I did do some research into kobject's and such before writing this patch
and based on that I believe the patch is correct. Presenting some evidence
below.
The patch is verified by:
a. Putting a printk in the release() method when it exists (it does for
sysfs_gtn kobject)
b. Enabling dynamic prints for lib/kobject.c
For example, with the following:
# echo 'file kobject.c +p' > /sys/kernel/debug/dynamic_debug/control
# echo -n ":03:00.0" > /sys/bus/pci/drivers/i915/unbind
We see this in dmesg (see kobject_cleanup() called from kobject_put()):
[ 1034.930007] kobject: '.defaults' (88817130a640): kobject_cleanup, parent
8882262b5778
[ 1034.930020] kobject: '.defaults' (88817130a640): auto cleanup kobject_del
[ 1034.930336] kobject: '.defaults' (88817130a640): calling ktype release
[ 1034.930340] kobject: (88817130a640): dynamic_kobj_release
[ 1034.930354] kobject: '.defaults': free name
[ 1034.930366] kobject: 'gt0' (8882262b5778): kobject_cleanup, parent
88817130a240
[ 1034.930371] kobject: 'gt0' (8882262b5778): auto cleanup kobject_del
[ 1034.931930] kobject: 'gt0' (8882262b5778): calling ktype release
[ 1034.931936] kobject: 'gt0': free name
[ 1034.958004] kobject: 'i915__03_00.0' (88810e1f8800): fill_kobj_path:
path = '/devices/i915__03_00.0'
[ 1034.958155] kobject: 'i915__03_00.0' (88810e1f8800):
kobject_cleanup, parent
[ 1034.958162] kobject: 'i915__03_00.0' (88810e1f8800): calling ktype
release
[ 1034.958188] kobject: 'i915__03_00.0': free name
[ 1034.958729] kobject: 'gt' (88817130a240): kobject_cleanup, parent
8881160c5000
[ 1034.958736] kobject: 'gt' (88817130a240): auto cleanup kobject_del
[ 1034.958762] kobject: 'gt' (88817130a240): calling ktype release
[ 1034.958767] kobject: (88817130a240): dynamic_kobj_release
[ 1034.958778] kobject: 'gt': free name
We have the following directory structure (one of the patches is creating
/sys/class/drm/card0/gt/gt0/.defaults):
/sys/class/drm/card0/gt
|-gt0
|-.defaults
And we see from dmesg
